Re: [v6ops] Flow Label Load Balancing

Fernando Gont <> Fri, 27 November 2020 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6B083A0E8B; Fri, 27 Nov 2020 12:52:26 -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 w4JRSMgJeH_P; Fri, 27 Nov 2020 12:52:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AB773A0DB2; Fri, 27 Nov 2020 12:52:24 -0800 (PST)
Received: from [IPv6:2800:810:464:8164:d564:510f:6fb3:4524] (unknown [IPv6:2800:810:464:8164:d564:510f:6fb3:4524]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5DB63283BC9; Fri, 27 Nov 2020 20:52:21 +0000 (UTC)
To: Alexander Azimov <>, Tom Herbert <>
Cc: IPv6 Operations <>, tcpm <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Fri, 27 Nov 2020 17:52:14 -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] 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: Fri, 27 Nov 2020 20:52:27 -0000

On 26/11/20 06:34, Alexander Azimov wrote:
> Dear colleagues,
> We started discussing an incorrect default behavior, and Tom has already 
> confirmed that it will be fixed.
> Later the thread turned into an argument if the flow label can be 
> changed during connection/flow lifetime according to current RFC 
> documents, though these documents can be updated. This looks a bit weird 
> for me because I always thought that it is the IETF community's 
> responsibility to document proper solutions. If something undocumented 
> but worthy happens in the industry - IETF should catch up. So, I would 
> like to get back to the discussion of reasons and their safety.
> The general idea of changing the routing path upon network 
> outage/degradation looks obvious. Getting kind of source-based routing 
> can significantly reduce the reaction time and improve end-user 
> experience. The flow label has a perfect match here: transparent for the 
> application, set by the source, not part of 5-tuple, while it can be 
> used in the load balancing. 

If you have two links, then, upon change of the FL, you have 50% change 
that the path will be different -- not good.  What would you do if the 
failure continues? -- keep changing the FL?

> Let say that the flow label is a hash of values from the IP packet's 
> 5-tuple and random number. Then
> 1. In the case of SYN or SYN-ACK retransmission flow label SHOULD be 
> recalculated.

This one MUST be switched of by default, too. (along with #2).

> 2. In the case of RTO timeout expiration in the established TCP session 
> the flow label MAY be recalculated. This setting MUST be switched off by 
> default.
> 3. Otherwise flow label SHOULD be preserved unchanged.
> The first point stands for redirecting connection from the degraded path 
> before the connection is established, and it looks safe. The second one 
> can also improve performance if it is set on the server-side. Please 
> comment if you see security flaws in such a design.

At the very least, one should analyze the case where in #1, a packet 
gets delayed, you change the FL and retransmit, and finally you get a 
response to the original packet (and/or to both packets).

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1