Re: the race to the bottom problem

[Lorenzo Colitti <[e-mail]>]

On Sat, 7 Nov 2020, 08:17 Mark Smith, <[e-mail]> wrote:

> The current bottom is a single /64.
>
> Any provider who is only giving out a single /64 to customers who might or
> will need more than one /64 has already raced to the current bottom.
>
> A "deeper bottom" or longer default allowed prefix length will just
> facilitate further racing to the deeper bottom. It won't encourage giving
> out more than one /64 for those who might need them; it'll do the opposite.
>

Exactly.

The fixed 64 bit boundary prevents this by defining the bottom in the
*only* way that actually matters: by ensuring that if a network goes below
the bottom, many hosts just won't work.

If it were possible to hand out less than a single /64 and have things work
acceptably for their customers, then someone, somewhere, would be doing it
already.

If we change the standards to make this technically possible but ask
operators not to do it, some will just do it anyway. After all - if it
works for them, why would they do otherwise? Because an RFC they maybe
haven't even read says they shouldn't?

The logical consequence is that we end up at /128. This is particularly
risky because any operator with lots of experience with IPv4 will find "one
/128 per host" obvious, expected and natural. One device has one IP
address, right? And once get to that point, we'll need to bring back NAT in
order to extend further. That would pretty much make the entire transition
to IPv6 pointless. We might as well have stayed with IPv4.

Personally I think that once there's more industry experience and IPv6 is
widely deployed in all network types (say, once we reach 80% of the
internet, and many networks are IPv6-only), we might be able to safely move
the bottom, once. But it's much too early for that.

>