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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 810AE3A07B3; Thu, 3 Dec 2020 00:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cWWDoNBm4FvH; Thu, 3 Dec 2020 00:02:51 -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 62EA03A0D1C; Thu, 3 Dec 2020 00:02:43 -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 D0C1D280498; Thu, 3 Dec 2020 08:02:38 +0000 (UTC)
To: Tom Herbert <>, Fernando Gont <>
Cc: IPv6 Operations <>, tcpm <>, Mark Smith <>, Brian E Carpenter <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Thu, 3 Dec 2020 05:02:33 -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 08:02:58 -0000

Hi, Tom,

On 29/11/20 13:25, Tom Herbert wrote:
>> Modulo the comments I've already made, I'm afraid we might be in the
>> path of making the FL unusable...
> Fernanda,,
> I really don't understand how this makes the flow label "unusable", to
> the contrary this is a useful case with good effect and justifies the
> work in the host to set the field. In any case, it would be great if
> you could provide the draft with the normative requirements that would
> make the flow label "usable".

Have the FL identify a flow. packets RTO'ing does not imply that the 
retransmissions belong to a different flow.

FL changing for established sessions will break load-balancers. OTOH, 
one would still need to anylize what would happen if a SYN RTO-es, gets 
retransmitted, but both the original and the retransmitted SYN is delivered.

> 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. :-)

> Additionally, if the underlying design principle is that flow
> identification in a packet is immutable and persistent, then I'd like
> to see the discussion on how that rectifies with NAT where
> intermediate nodes routinely change IP addresses and transport port
> numbers without the host endpoints' knowledge-- unlike the flow label,
> port numbers are formally part of the transport connection
> identification, so changing them in flight is far more invasive and
> potentially harmful than changing the flow label (we've seen far more
> problems caused by NAT than flow label due to NAT state evictions,
> packets of a flow being re-routed to not hit the same NAT device,
> etc.).

You seem to be referring to IPv4 NAT, since IPv6 NPT does not modify the 
ports.   That said, even if IPv6 NAT did, then as long as the FL is 
consistent from the outside, that's fine. (i.e., the FL remains constant 
from both the "external realm" pov, and also from the "internal realm" pov).


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