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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17a9b993042.b90afa5f896079.1270339649529299106@shytyi.net>
Date:   Mon, 12 Jul 2021 18:42:25 +0200
From:   Dmytro Shytyi <dmytro@...tyi.net>
To:     "Jakub Kicinski" <kuba@...nel.org>,
        "Maciej Żenczykowski" <maze@...gle.com>,
        "yoshfuji" <yoshfuji@...ux-ipv6.org>
Cc:     "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

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