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

Fernando Gont <> Thu, 03 December 2020 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 38D073A0EB2; Thu, 3 Dec 2020 08:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l-dL_QExK2jU; Thu, 3 Dec 2020 08:08:47 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10D833A0E29; Thu, 3 Dec 2020 08:08:46 -0800 (PST)
Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C0E242803C8; Thu, 3 Dec 2020 16:08:42 +0000 (UTC)
To: Erik Kline <>
Cc: Tom Herbert <>, Fernando Gont <>, IPv6 Operations <>, tcpm <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Thu, 3 Dec 2020 13:08:03 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 16:08:50 -0000

On 3/12/20 12:43, 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.

Well, yeah, but there was also no use of the FL, either ;-) . And for 
load-balancing among a group of servers, you need the FL to be stable 
for the life of the flow, or otherwise packet may end up ebig delivered 
to different servers.

Otherwise, the FL is likely to be inored, and we'll continue figuring 
out what to use those 20 bits for...

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492