Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

[Fernando Gont <[e-mail]>]

On 28/7/20 16:18, Tom Herbert wrote:
> On Tue, Jul 28, 2020 at 1:36 AM Vasilenko Eduard
> <[e-mail]> wrote:
>>
>> Hi Tom,
>> Is APNIC a reliable source for you?
>> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/
>> RIPE has replicated it here: https://labs.ripe.net/Members/joel_jaeggli/ipv6-flow-label-misuse-in-hashing
>> "Cases have been observed where devices that connect to hashed endpoints do not in fact honour this behaviour. By in large, this flow label changing behaviour has been traced to IPv6 supporting CPE/firewalls, which change the flow label between the initial syn and the ack."
> 
> The rationale for this is: "The use of the flow label as a hash
> element for any stateful application requires that the flow label
> remain unchanged over the life of the flow.". This is really directed
> towards stateful intermediate nodes like stateful firewalls. 

IIRC, FreeBSD used to change the Flow Label during the TCP 3WHS vs data 
transfer phase...




>> They have disputable conclusion: "Avoid using the flow label as a hash component".
> 
> This guidance could just as easily be "Avoid fragmentation", "Avoid
> using any protocols other than UDP or TCP", "Avoid using extension
> headers", "Avoid ICMP", "Avoid using encapsulation", "Avoid using
> encryptions" as any of these can break some meddling device somewhere
> such that packet delivery becomes unreliable on the Internet. More
> generally, the guidance could simply be "Avoid doing anything that
> disrupts the status quo"!

Unfortunately, if one is in the "business" of getting data through, one 
would rather stick to whatever works.

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