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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 18 Dec 2020 18:40:50 -0800
From:   Maciej ┼╗enczykowski <>
To:     Jakub Kicinski <>
Cc:     Dmytro Shytyi <>,
        yoshfuji <>,
        liuhangbin <>, davem <>,
        netdev <>, David Ahern <>,
        Joel Scherpelz <>
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 <> 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 <>
> 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

Powered by blists - more mailing lists