| 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
| ||
|
Message-ID: <CAMGpriVD6H4t9RSTBeVsLqPC5TGHoMkjOE1SE=MCMDgnxOK7ug@mail.gmail.com> Date: Sat, 17 Aug 2024 21:48:24 -0700 From: Erik Kline <ek.ietf@...il.com> To: Dmytro Shytyi <dmytro@...tyi.net> Cc: Maciej Żenczykowski <maze@...gle.com>, ek <ek@...n.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>, Lorenzo Colitti <lorenzo@...gle.com> Subject: Re: [PATCH net-next V9] net: Variable SLAAC: SLAAC with prefixes of arbitrary length in PIO Dmytro, Well, there are roughly 1,000,001 threads where this has been hashed out. It's not possible to point to a single document, nor should it be necessary IMHO. Furthermore, changing this doesn't solve the non-deployability of it in the general case. A general purpose network has no idea whether attached nodes support the non-default SLAAC configuration, and RAs so configured will just leave legacy hosts without IPv6 connectivity. There is still more that can be said, but a troll through the 6MAN working group archives will find numerous discussions. On Mon, Aug 12, 2024 at 10:55 AM Dmytro Shytyi <dmytro@...tyi.net> wrote: > > Dear Maciej, Erik, > > Thank you for your response and for highlighting that this topic > has been discussed multiple times within IETF and other forums. > > I understand that "race to the bottom" is a term that has been > used in various discussions, but I’ve noticed that a concrete > definition of "fundamental problem" (in ML, mail of EK, 2021-10-14 18:26:30) > "race to the bottom", particularly in the > context [2], has been somewhat elusive. > > The fundamental problem "race to the bottom" was > brought up as a issue in the current topic, > therefore, could Erik or you provide a more detailed explanation > or point me to specific documents or discussions where this > fundamental problem "race to the bottom" has been _clearly > defined_ and _well contextualized_ regarding these two questions? > [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 how the possibility of configuration of > prefix lengths longer that 64, enables > fundamental problem "race to the bottom"? > > Understanding this more concretely would > be very helpful as we continue to address the issues. > > Thank you for your guidance and support. > > Best regards, > Dmytro Shytyi et al. > > ---- On Mon, 12 Aug 2024 18:34:56 +0200 Maciej Żenczykowski wrote --- > > > 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