Re: [v6ops] [tcpm] Flow Label Load Balancing

Tom Herbert <> Thu, 03 December 2020 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CE2F3A09C9 for <>; Thu, 3 Dec 2020 09:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dfKK-bUi2hUW for <>; Thu, 3 Dec 2020 09:30:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A5BA3A09D7 for <>; Thu, 3 Dec 2020 09:30:58 -0800 (PST)
Received: by with SMTP id 7so4711688ejm.0 for <>; Thu, 03 Dec 2020 09:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5t9/bnLlHge8qv6Cj3rUOp3tZdHHx9aErFK3U8IONFI=; b=JsyTgtjwWqbesx9WmpkjHKhgm+A20C2FRZrslv20jOhSfGD9v2vSiM5ssw7IH+btCi BPOVnEe9AAD5Lq6MY5xysJrmWPNGfsaKZWTlVL2wdN0tU6K+f+M0iLyihjBy+6NlxcmI r3Ahhp118YqZzr1HZV803K/jvSvmTJVykGIwrrDluiQuIAXRty3iZnwfsI03SywftN23 DnQqzGVhlFfAVZRd3fuv4lXwotdDeOeLjrwNZajhWVhgih0XWGAydaJil7KPDXlrpgQ4 Y84qtHGNptq5hE9dn++XdVONsHAPIW+mgtFvPaxD9xv4zPVc5ZVjTrMptXvw0NZzHvzt aHWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5t9/bnLlHge8qv6Cj3rUOp3tZdHHx9aErFK3U8IONFI=; b=hWQ4TtC3/x7ffcM1wrcV8ZNtLYv/6sCmKi1Qt0kGnQx+kj1oTadRu/iNo8Vj402G2D fWWQ5CgI1dMX0THL26hIED5M4U2npwZ7cMe+omIF8b0zlE5I3lZxu761XYGNeUh922hM AoUR41YMkULB8/s3zHUzov6+Y7WL4xEVpwlEkxdkychnPyB0e7ZlDSLKKLzhLxkT3C1V IRln6+eXNYy1zY7htnIk3TfOZIC6S5ciuTe/Rgnrt1v26/ySEC9/wUorJq+xclRVtY8O d6vJq3HmaY2gGZ5It7CT+cpHD6uTXHho+g4C22oujVMyq5nPRu279Y2ubwE8jgd8j/5G /sGA==
X-Gm-Message-State: AOAM530xzD6aK2Wt+hzGgfHf5KFcG+QpboA9yvPdd6xBrr4PszApPXLI w5z9VamtRYPod+4dGF5pLGFKlJnvVwZHKrzzu9+UQg==
X-Google-Smtp-Source: ABdhPJyQO3nqK6zp3jU+YFnu28S5HOMBcOTffN700tu6Btr61fvvq3fnPN22roqyXMbpJ59WDubFfLf7xkrU4VCYgjA=
X-Received: by 2002:a17:906:26cc:: with SMTP id u12mr3590035ejc.295.1607016656907; Thu, 03 Dec 2020 09:30:56 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 3 Dec 2020 10:30:45 -0700
Message-ID: <>
To: Erik Kline <>
Cc: Fernando Gont <>, Fernando Gont <>, IPv6 Operations <>, tcpm <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2020 17:31:01 -0000

On Thu, Dec 3, 2020 at 8:43 AM Erik Kline <> wrote:
> > > Please include requirements for both hosts and network nodes. If there
> > > is going to the be a requirement that hosts MUST make a 1:1 mapping to
> > > a transport connection and the flow label MUST be consistent for the
> > > life of connection, then I would expect there to also be a requirement
> > > that the flow label MUST be immutable by all devices in the path-- in
> > > particular the requirement of RFC6437 would need to be updated: "A
> > > forwarding node MUST either leave a non-zero flow label value
> > > unchanged or change it only for compelling operational security
> > > reasons..."-- if hosts are not allowed to change a field they are
> > > primarily responsible for setting, then the network should not be
> > > allowed to modify it either.
> >
> > I don't recall _(of the top of my head) why we ended up making the field
> > mutable ("SHOULD NOT  be modified" rather than "MUST NOT.."). IIRC, it
> > had to do with allowing middle-boxes to mitigate FL-based covert
> > channels.  If that's the case (Brian CC'ed) then, in retrospective, that
> > seems to have been a bad idea.  -- I was part of the discussion, so I
> > take my share of blame. :-)
> My understanding/recollection is that since there were never any
> restrictions on modification of the flow label from the very beginning
> it wasn't super meaningful to try to close the barn door after all
> these years.


There are two apropos statements in RFC6437:

"There is no way to verify whether a flow label has been modified en
route or whether it belongs to a uniform distribution.  Therefore, no
Internet-wide mechanism can depend mathematically on unmodified and
uniformly distributed flow labels; they have a "best effort" quality."

"From an upper-layer viewpoint, a flow could consist of all packets in
one direction of a specific transport connection or media stream.
However, a flow is not necessarily 1:1 mapped to a transport

So building a load balancer, or any other intermediate network device,
that *depends* on the flow label to be consistent for the life of a
transport connection and 1:1 mapped to a transport connection is
contrary to this guidance. The ship has already sailed on this in
deployment, and even if the protocol requirements were to be
sufficiently tightened that would take years to reach full effect and
that would preclude other use cases where modifying the flow label is
useful. If a stable 1:1 mapped identifier for transport ports is
needed in the network layer, it might make sense to create a new HBH
option for that. Personally, if I were building a load balancer I'd
use neither the flow label nor transport ports for entropy, I'd look
at using the destination address since 128 bits allows plenty of bits
of entropy, it's consistent per transport flow and always set in an
IPv6 packet.