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

[Tom Herbert <[e-mail]>]

On Tue, Jul 28, 2020 at 1:20 PM Fernando Gont <[e-mail]> wrote:
>
> 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...
>
Fernando,

We had an issue in Linux where the Flow Label can change when closing.
This was causing bad interaction with FW. We treated this as a bug and
fixed it promptly and now flow labels should be consistent for the
lifetime of the flow. Software implementation can have much faster
turnaround time to fix issues and I am still hoping, perhaps naively,
that with the emergence of SDN and programmable datapaths in devices
we can start to get that ability in other network devices and start to
address some long standing issues of protocol non-conformance.

>
>
>
> >> 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.
>
Yep, this has driven host implementations to support the least common
denominator in protocols. The only general workaround of protocol
ossification to date is encrypting as much of the packet as possible
like in QUIC, but when we do that networks visibility is reduced as is
the opportunities for hosts and network to work in concert to solve
users problems.

Tom

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