Message-ID: <17aa131b2c0.ce91fad8967683.2218404148220256363@shytyi.net>
Date:   Tue, 13 Jul 2021 20:47:06 +0200
From:   Dmytro Shytyi <dmytro@...tyi.net>
To:     "Erik Kline" <ek@...gle.com>
Cc:     "Jakub Kicinski" <kuba@...nel.org>,
        "Maciej Żenczykowski" <maze@...gle.com>,
        "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

In this case, there is another possibility as well: in order to avoid
opening a race to the bottom condition, the VSLAAC code could be
modified to not permit IIDs of length shorter than 64.

What do you think about this possibility?
  
________________
Dmytro SHYTYI

---- 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. 
 > >  > 
 > > 
 > 

Powered by blists - more mailing lists