[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANP3RGdeFFjL0OY1H-v6wg-iejDjsvHwBGF-DS_mwG21-sNw4g@mail.gmail.com>
Date: Mon, 12 Aug 2024 09:34:56 -0700
From: Maciej Żenczykowski <maze@...gle.com>
To: Dmytro Shytyi <dmytro@...tyi.net>
Cc: ek <ek@...n.com>, ekietf <ek.ietf@...il.com>, Jakub Kicinski <kuba@...nel.org>,
yoshfuji <yoshfuji@...ux-ipv6.org>, liuhangbin <liuhangbin@...il.com>,
davem <davem@...emloft.net>, netdev <netdev@...r.kernel.org>,
David Ahern <dsahern@...il.com>, Joel Scherpelz <jscherpelz@...gle.com>
Subject: Re: [PATCH net-next V9] net: Variable SLAAC: SLAAC with prefixes of
arbitrary length in PIO
On Sun, Aug 11, 2024 at 10:16 AM Dmytro Shytyi <dmytro@...tyi.net> wrote:
>
> Hello Erik Kline,
>
> You stated that, VSLAAC should not be accepted in large part because
> it enables a race to the bottom problem for which there is no solution
> in sight.
>
> We would like to hear more on this subject:
> 1. Would you be kind to send us the explanation of
> "race to the bottom problem" in IP context with examples.
>
> 2. Would you be kind to explain howt he possibility of configuration of
> prefix lengths longer that 64, enables "race to the bottom problem"?
This has been discussed multiple times in IETF (and not only), I don't
think this is the right spot for this sort of discussion.
>
> We look forward for your reply.
NAK: Maciej Żenczykowski <maze@...gle.com>
>
> Best regards,
> Dmytro SHYTYI, et Al.
>
> >
> >
> >
> > ---- On Mon, 12 Jul 2021 19:51:19 +0200 Erik Kline ek@...gle.com> wrote ---
> >
> > VSLAAC is indeed quite contentious in the IETF, in large part because
> > it enables a race to the bottom problem for which there is no solution
> > in sight.
> >
> > I don't think this should be accepted. It's not in the same category
> > of some other Y/N/M things where there are issues of kernel size,
> > absence of some underlying physical support or not, etc.
> >
> >
> > On Mon, Jul 12, 2021 at 9:42 AM Dmytro Shytyi dmytro@...tyi.net> wrote:
> > >
> > > Hello Jakub, Maciej, Yoshfuji and others,
> > >
> > > After discussion with co-authors about this particular point "Internet Draft/RFC" we think the following:
> > > Indeed RFC status shows large agreement among IETF members. And that is the best indicator of a maturity level.
> > > And that is the best to implement the feature in a stable mainline kernel.
> > >
> > > At this time VSLAAC is an individual proposal Internet Draft reflecting the opinion of all authors.
> > > It is not adopted by any IETF working group. At the same time we consider submission to 3GPP.
> > >
> > > The features in the kernel have optionally "Y/N/M" and status "EXPERIMENTAL/STABLE".
> > > One possibility could be VSLAAC as "N", "EXPERIMENTAL" on the linux-next branch.
> > >
> > > Could you consider this possibility more?
> > >
> > > If you doubt VSLAAC introducing non-64 bits IID lengths, then one might wonder whether linux supports IIDs of _arbitrary length_,
> > > as specified in the RFC 7217 with maturity level "Standards Track"?
> > >
> > > Best regards,
> > > Dmytro Shytyi et al.
> > >
> > > ---- On Mon, 12 Jul 2021 15:39:27 +0200 Dmytro Shytyi dmytro@...tyi.net> wrote ----
> > >
> > > > Hello Maciej,
> > > >
> > > >
> > > > ---- On Sat, 19 Dec 2020 03:40:50 +0100 Maciej Żenczykowski maze@...gle.com> wrote ----
> > > >
> > > > > On Fri, Dec 18, 2020 at 6:03 PM Jakub Kicinski kuba@...nel.org> wrote:
> > > > > >
> > > > > > It'd be great if someone more familiar with our IPv6 code could take a
> > > > > > look. Adding some folks to the CC.
> > > > > >
> > > > > > On Wed, 16 Dec 2020 23:01:29 +0100 Dmytro Shytyi wrote:
> > > > > > > Variable SLAAC [Can be activated via sysctl]:
> > > > > > > SLAAC with prefixes of arbitrary length in PIO (randomly
> > > > > > > generated hostID or stable privacy + privacy extensions).
> > > > > > > The main problem is that SLAAC RA or PD allocates a /64 by the Wireless
> > > > > > > carrier 4G, 5G to a mobile hotspot, however segmentation of the /64 via
> > > > > > > SLAAC is required so that downstream interfaces can be further subnetted.
> > > > > > > Example: uCPE device (4G + WI-FI enabled) receives /64 via Wireless, and
> > > > > > > assigns /72 to VNF-Firewall, /72 to WIFI, /72 to Load-Balancer
> > > > > > > and /72 to wired connected devices.
> > > > > > > IETF document that defines problem statement:
> > > > > > > draft-mishra-v6ops-variable-slaac-problem-stmt
> > > > > > > IETF document that specifies variable slaac:
> > > > > > > draft-mishra-6man-variable-slaac
> > > > > > >
> > > > > > > Signed-off-by: Dmytro Shytyi dmytro@...tyi.net>
> > > > > >
> > > >
> > > > > IMHO acceptance of this should *definitely* wait for the RFC to be
> > > > > accepted/published/standardized (whatever is the right term).
> > > >
> > > > [Dmytro]:
> > > > There is an implementation of Variable SLAAC in the OpenBSD Operating System.
> > > >
> > > > > I'm not at all convinced that will happen - this still seems like a
> > > > > very fresh *draft* of an rfc,
> > > > > and I'm *sure* it will be argued about.
> > > >
> > > > [Dmytro]
> > > > By default, VSLAAC is disabled, so there are _*no*_ impact on network behavior by default.
> > > >
> > > > > This sort of functionality will not be particularly useful without
> > > > > widespread industry
> > > >
> > > > [Dmytro]:
> > > > There are use-cases that can profit from radvd-like software and VSLAAC directly.
> > > >
> > > > > adoption across *all* major operating systems (Windows, Mac/iOS,
> > > > > Linux/Android, FreeBSD, etc.)
> > > >
> > > > [Dmytro]:
> > > > It should be considered to provide users an _*opportunity*_ to get the required feature.
> > > > Solution (as an option) present in linux is better, than _no solution_ in linux.
> > > >
> > > > > An implementation that is incompatible with the published RFC will
> > > > > hurt us more then help us.
> > > >
> > > > [Dmytro]:
> > > > Compatible implementation follows the recent version of document: https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ The sysctl usage described in the document is used in the implementation to activate/deactivate VSLAAC. By default it is disabled, so there is _*no*_ impact on network behavior by default.
> > > >
> > > > > Maciej Żenczykowski, Kernel Networking Developer @ Google
> > > > >
> > > >
> > > > Take care,
> > > > Dmytro.
> > > >
> > >
> >
> >
> >
>
--
Maciej Żenczykowski, Kernel Networking Developer @ Google
Powered by blists - more mailing lists