Re: [PATCH net-next V9] net: Variable SLAAC: SLAAC with prefixes of arbitrary length in PIO

[Dmytro Shytyi <dmytro@shytyi.net>]

Hello Maciej,


---- On Sat, 19 Dec 2020 03:40:50 +0100 Maciej Żenczykowski <maze@google.com> wrote ----

 > On Fri, Dec 18, 2020 at 6:03 PM Jakub Kicinski <kuba@kernel.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@shytyi.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.