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

[Tom Herbert <[e-mail]>]

On Mon, Jul 27, 2020 at 2:01 PM Brian E Carpenter
<[e-mail]> wrote:
>
> On 28-Jul-20 07:23, Tom Herbert wrote:
> > On Mon, Jul 27, 2020 at 11:05 AM Vasilenko Eduard
> > <[e-mail]> wrote:
> >>
> >> Hi Tom,
> >> I believe that risk still exist that some application would no use flow label properly.
> >
> > Exactly which applications are you concerned about?
>
> Given that the most widespread socket APIs (POSIX and WinSock) do not allow
> an application to set the flow label, I too have that question.
>
Brian,

Flow label is automatically set per flow. The easiest way to do this
is to save a hash value in the connection context, in Linux that's
simply intialized to a random number and when packets are sent the low
order twenty bits of the value are simply copied into the flow label.
In cases where we don't have a connection context, like when we're
forwarding and encapsulating in IPv6, we hash over the packet four
tuples and use bits from that hash value. In most cases we can either
use the saved context hash or get a suitable 4-tuple hash from the
receiving device for "free", but if those are not available then we
will do the work to compute the hash in the CPU (expensive operations
for CPU so we try to avoid that).

Generally, we really don't want individual applications setting the
flow label, it's just as easy to let the kernel do it as it can
guarantee a proper uniform distribution, good waterfall properties in
the hash, and consistent use of the same hash for the lifetime of the
connection. The one exception is if the flow label has more semantics
that just being an entropy identifier, in that case there are APIs
that can be used.

Tom

> And again: please read RFC7098 where these issues are discussed in some
> depth. If that RFC is now out of date due to changing reality (such
> as TLS 1.3), please let us know.
>
>     Brian
>
> >
> >> Hence, it is better on LB to deep dive into UDP/TCP. More predictable/reliable result.
> >
> > You seem to be assuming a very limited traffic profile that consists
> > only of plain UDP/TCP packets. Any use case that deviates from that
> > then breaks your LB (i.e. encapsulation, tunneled encryption, SCTP,
> > IPSec, etc.). Flow label is in all IPv6 packets and is mostly set
> > properly for the vast majority of packets on the Internet and
> > processing it is completely independent of the protocols, so when
> > taking the full scope of the problem into account it is actually more
> > generic and more predictable/reliable.
> >
> > Tom
> >
> >> Eduard
> >> -----Original Message-----
> >> From: Tom Herbert [mailto:[e-mail]]
> >> Sent: 27 июля 2020 г. 17:15
> >> To: Vasilenko Eduard <[e-mail]>
> >> Cc: Fernando Gont <[e-mail]>; IPv6 Operations <[e-mail]>; [e-mail]
> >> Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer
> >>
> >> On Mon, Jul 27, 2020 at 2:08 AM Vasilenko Eduard <[e-mail]> wrote:
> >>>
> >>> Hi Fernando,
> >>> Hence again, following the logic of this draft (the level of detalization that you have given to 5.1) - may be you need additional section 5.1.x: Load Balancer have to look into TCP/UDP ports. Moreover, it could not trust "Flow label" - it is not reliable practice for LB.
> >>
> >> Eduard,
> >>
> >> What exactly does "not reliable practice for LB" mean.? If this means that the flow label might change during the flow's lifetime then I will point out that UDP is equally unreliable for that reason (i.e.
> >> the UDP ports for a QUIC connection can change during the connection's lifetime). For that matter, a TCP header might be encrypted or in an encapsulation that the LB doesn't understand so the LB can't access the TCP ports at all-- in the this case the flow label is actually more reliable than TCP since it's never encrypted and is purposely designed to be consumed by intermediate nodes without the need for expensive DPI.
> >>
> >> Tom
> >>> Or alternatively you could say something about LB in section 5.1.2,
> >>> but because it is a little special case - may be better to have
> >>> separate 5.1.x
> >>>
> >>> Eduard
> >>> -----Original Message-----
> >>> From: v6ops [mailto:[e-mail]] On Behalf Of Fernando Gont
> >>> Sent: 26 июля 2020 г. 8:46
> >>> To: IPv6 Operations <[e-mail]>
> >>> Cc: [e-mail]
> >>> Subject: [v6ops] Operational Implications of IPv6 Packets with
> >>> Extension Headers (Fwd: New Version Notification for
> >>> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt)
> >>>
> >>> Folks,
> >>>
> >>> We have posted a rev of our IETF I-D "Operational Implications of IPv6 Packets with Extension Headers".
> >>>
> >>> The I-D is available at:
> >>> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-
> >>> drops-04.txt
> >>>
> >>> Your feedback will be appreciated.
> >>>
> >>> Thanks!
> >>>
> >>> Cheers,
> >>> Fernando
> >>>
> >>>
> >>>
> >>>
> >>> -------- Forwarded Message --------
> >>> Subject: New Version Notification for
> >>> draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> >>> Date: Sat, 25 Jul 2020 22:28:50 -0700
> >>> From: [e-mail]
> >>> To: Fernando Gont <[e-mail]>, Gert Doering
> >>> <[e-mail]>, Geoff Huston <[e-mail]>, Warren Kumari
> >>> <[e-mail]>, Nick Hilliard <[e-mail]>
> >>>
> >>>
> >>> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-04.txt
> >>> has been successfully submitted by Fernando Gont and posted to the IETF repository.
> >>>
> >>> Name:           draft-gont-v6ops-ipv6-ehs-packet-drops
> >>> Revision:       04
> >>> Title:          Operational Implications of IPv6 Packets with Extension Headers
> >>> Document date:  2020-07-25
> >>> Group:          Individual Submission
> >>> Pages:          15
> >>> URL:
> >>> https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-
> >>> drops-04.txt
> >>> Status:
> >>> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drop
> >>> s/
> >>> Htmlized:
> >>> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-04
> >>> Htmlized:
> >>> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet
> >>> -drops
> >>> Diff:
> >>> https://www.ietf.org/rfcdiff?url2=draft-gont-v6ops-ipv6-ehs-packet-dro
> >>> ps-04
> >>>
> >>> Abstract:
> >>>     This document summarizes the security and operational implications of
> >>>     IPv6 extension headers, and attempts to analyze reasons why packets
> >>>     with IPv6 extension headers may be dropped in the public Internet.
> >>>
> >>>
> >>>
> >>>
> >>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> >>>
> >>> The IETF Secretariat
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >>>
> >>> _______________________________________________
> >>> v6ops mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>