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: <CANP3RGfG=7nLFdL0wMUCS3W2qnD5e-m3CbV5kNyg_X2go1=MzQ@mail.gmail.com>
Date:   Fri, 18 Dec 2020 18:40:50 -0800
From:   Maciej Żenczykowski <maze@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Dmytro Shytyi <dmytro@...tyi.net>,
        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

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>
>
> The RFC mentions checking a flag in RA, but I don't see that in this
> patch, could you explain?

IMHO acceptance of this should *definitely* wait for the RFC to be
accepted/published/standardized (whatever is the right term).

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.

This sort of functionality will not be particularly useful without
widespread industry
adoption across *all* major operating systems (Windows, Mac/iOS,
Linux/Android, FreeBSD, etc.)
Additionally rollout will take years (due to need for OS updates), so
waiting a few
more months/quarters for the RFC to actually be agreed upon (assuming
it ever is),
will not hurt us.

An implementation that is incompatible with the published RFC will
hurt us more then help us.

Maciej Żenczykowski, Kernel Networking Developer @ Google