Message-ID: <1914270a012.d45a8060119038.8074454106507215168@shytyi.net>
Date: Sun, 11 Aug 2024 19:16:02 +0200
From: Dmytro Shytyi <dmytro@...tyi.net>
To: "ek" <ek@...n.com>, "ekietf" <ek.ietf@...il.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

[I received the message, that ek@...gle.com is not reachable, so other email addresses to reach Erik Kline were included in this message]

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"?
  
  We look forward for your reply.

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

Powered by blists - more mailing lists