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

Tom Herbert <> Thu, 03 December 2020 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 838683A0CDB for <>; Thu, 3 Dec 2020 12:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 DriJdaUVlRUL for <>; Thu, 3 Dec 2020 12:07:07 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF53B3A0D05 for <>; Thu, 3 Dec 2020 12:06:56 -0800 (PST)
Received: by with SMTP id 7so5391041ejm.0 for <>; Thu, 03 Dec 2020 12:06:56 -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=ndQFvwaUXmS8GuBoJIOycXq2OUb8TPic10DtRNt0Njo=; b=xJhti7Zb9pYkM2bf/S93YLdLpdrbFu6Lc0dPGMNtw+iJkJnlsp/3Jp7LNT8Xnh3B4I 0ZB5jl26Fm6G6vO+AMe1n35sYtWyfwSovChi0RH87zdwKWRDLP8dR8/wkTBgWfE06awX 5Qjj9LBifqwJkIOWCYxzrAk5c3eJcdrjc7mybgRULWftWmDKNix8dN9+R5mi/Q4Hc2aJ eZphh1PQnWIWtqo7K2Ie0VZNqn8j2oFlL8+duOq4GsX0QsrYfIE1TdltxUQuldKkcukz z0r3vXhxsxdIUAPTXEIJZfaco2o7u5kEklzGXTB4DBMJmiVKCfOBRVfchlKi+KY/4VVx 4XTQ==
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=ndQFvwaUXmS8GuBoJIOycXq2OUb8TPic10DtRNt0Njo=; b=stiQRAQ4FO0ARKLjrzJAu4nHXQlOwabcEO2hqDlKkJ5MLtB94s3mGzBHR+b5D/57mU YGfn6jRNbVc6vhtHe9iyJAM6T6s7BpNthom4mJLs6Nqi3y8H1QB0AduMLvCOJuamr6HV g5FSbLWZ6ZRETuexwL9BCkWq1mS2qOzGJfMiQfoK656FHzLsVTe9IP0i51PHhQaEkSKL joxC30+Iqm+nzzvml4wjGa9ASaEP/12l0U18BoHqKP8tJUt6xaFBJJACfRfcjUxGWXQU 57NJbLqOa2nDh296YUbygTaWetMJtakHLRYFCFjiV7V5sEK5E043VBXNW8yieWaUu8as r09g==
X-Gm-Message-State: AOAM532lii/zQRj7I6oRKgVNCH8Ux9uGrLVjjEPnem99NoVXPyEqVrWo ZljK20ussDNOAsTJ8bNITpiB8kLoAzr7003gDK0MLQ==
X-Google-Smtp-Source: ABdhPJwYz/layhzIvh4CvZ7th7UFO/Yc/NNmwyyO68M5/RIcjwHogbYbdKamvckXC7IgCwS3hbXkxux+i5UYhUbIFx8=
X-Received: by 2002:a17:906:26cc:: with SMTP id u12mr4181798ejc.295.1607026014894; Thu, 03 Dec 2020 12:06:54 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Thu, 3 Dec 2020 13:06:43 -0700
Message-ID: <>
To: Fernando Gont <>
Cc: Erik Kline <>, 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 20:07:17 -0000

On Thu, Dec 3, 2020 at 12:42 PM Fernando Gont <> wrote:
> On 3/12/20 14:30, Tom Herbert wrote:
> [....]
> >
> > 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
> > connection."
> >
> > 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.
> We don't need 1:1. We just need 1:N where N is how flows would be
> aggregated/grouped for the purpose of load-sharing.
> > 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.
> The above said, I would probably agree that if havinga non-stable FL
> breaks something, whatever it breaks is probably already broken, since


Not to belabor the point, but stable flow labels were never
guaranteed, so if some node has a problem with non-stable flow labels
then they are themselves broken because they are making an incorrect

> there's not even a checksum to try to detect whether the IPv6 header has
> been corrupted.
Neither is there checksum that covers the UDP port numbers when UDP
checksum is zero. A "stable" identifier that the network can use to
conclusively identify transport flows does not generally exist.

> > 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
> Problem is that if you have two systems that need a lot of banswitdth
> (e.g., they are transferring file via several TCP connections)< you
> wouldn't be able to load-share them -- since the result of the hash
> would be the sme for all TCP connections....
Use a different IP address per connection. This idea has already been
brought up in the context of security since it could make it harder
for malicious network observers to correlate different flows as having
the same source, and the same principle could be applied to load
balancers where each of the backends is assigned a block of IP
addresses (like a /64). After that, it's a matter of getting clients
to use some random address from the load balancer blocks (instead of
always using one). IIRC, Brian Carpenter once suggested that we really
didn't need port numbers any more since they could be part of the
address-- for load balancers there might be some merit to that.


> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492