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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKD1Yr3YrspL=4ZXCZVq7bPJuQOuBuFzLzc2Xyoa6uxnPshkOQ@mail.gmail.com>
Date: Sun, 18 Aug 2024 20:42:56 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: Erik Kline <ek.ietf@...il.com>
Cc: Dmytro Shytyi <dmytro@...tyi.net>, 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>
Subject: Re: [PATCH net-next V9] net: Variable SLAAC: SLAAC with prefixes of
 arbitrary length in PIO

On Sun, Aug 18, 2024 at 1:48 PM Erik Kline <ek.ietf@...il.com> wrote:
>
> 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.

In addition to what Erik and other have said, I would point out that
it's extremely unlikely that this will be an IETF standard anytime in
the foreseeable future. The IETF is a consensus-based organization,
and if you look at the discussions that happened in Vancouver in the
v6ops and 6man working groups, there was very strong opposition to the
plan from many working group participants. These participants were all
very concerned that this change cannot achieve its desired goal, and
would be harmful to the Internet's architecture. Such a level of
opposition, and the fact that the opposition is founded in legitimate
technical concerns, pretty much guarantee that the documents proposing
these changes will not reach consensus and thus will not be published.

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

Here's what "race to the bottom" means in this context. Today, many
ISPs make a business decision to assign to their customers the minimum
amount of space that their devices will accept. For residential users,
that is a /64 per user. The reason I say it's a business decision is:
- There is no technical reason to assign a /64 instead of a shorter
prefix such as a /60 or a /56. There is plenty of IPv6 address space;
all home routers support shorter prefix sizes; all industry standards
and best practices, including IETF standards, recommend shorter than
/64.
- There are plenty of technical downsides of a single /64 - for
example, stub networks such as Thread won't be able to access the
Internet; if the customer plugs in another IPv6 router, then that
router and all the devices behind it become IPv4-only.

The fact that this is an explicit business decision, not a technical
one, means that the decision will not change if this proposal gets
adopted. These ISPs will continue to make the same decision - assign
the minimum size that is accepted. The current proposal limits
variable length SLAAC to /80, and once all devices support /80, then
the minimum will be /80. The situation will be the same as it is today
(mix of prefix sizes), but the minimum will be /80. At that point
another proposal could come around - just like the current one - that
shortens /80 to, say, /96. And so on. It's called "race to the bottom"
because each time the amount of space available to users becomes less,
until we hit the "bottom".