Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt

[Lorenzo Colitti <[e-mail]>]

On Mon, Nov 6, 2023 at 2:41 AM Martin Huněk <[e-mail]> wrote:

> If you have at least X+32 of IPv6, you can be in the same situation with
> IPv6 as you are in IPv4. Now, do we want to be in the same situation? Why
> migrate to IPv6, then?
>

It's not the same situation. As the draft explains, x+32 is 32 times better
than IPv4 if we never move beyond 2000::/3. If we move beyond 2000::/3,
it's 256 times better than IPv4. Whether any given network has enough space
for that is up to the operators and the RIRs. Based on your comments, it's
clearly not enough for your network. That's OK - whether a network uses
this model is up to the network, and it's pretty clear that there are some
networks, like home networks with only a /64 or a /60, that will never be
able to run this model due to lack of space.

FWIW, I think you said that in order to use this you'd need to assign a /49
to your Wi-Fi network? That doesn't seem unreasonable to me, or to other
operators that are part of this discussion.

Remember, what we are trying to do here is a compromise: provide to network
operators the control and tracking that they like to have via DHCPv6, while
ensuring that connected devices can support pretty much any use case,
including hosts forming unlimited addresses, plugging in routers, and doing
a moderate amount of network extension with end-to-end connectivity and
without NAT. We think this model has a lot of advantages, but it's
definitely not the only one.

I agree with Gert. You can have /80s all you want, but you are not getting
> /64s from me. If your implementation requires it, then it is NAT66 for you,
> ND proxy, or IPv4 only. You choose.
>

I hate to say it, but... network operators saying, "my network, my rules"
and insisting that devices will only have the amount of address space that
they think they need is precisely why host implementers don't trust
networks to do the right thing.

This is why we need a fixed boundary - otherwise we end up with a race to
the bottom that ends at /128. At the moment, the only possible fixed
boundary is /64, because once the device gets a /64, it can do whatever it
wants, and extend the network all it wants, using SLAAC. If we make SLAAC
run on longer prefixes, then maybe we'll all agree on one size. But who
knows if that will work. Just like you say, "you can have all the /80s you
want, but you're not getting /64s", some other operators saying, "you can
have all the /128s you want, but you're not getting /80s". One thing at a
time. If we make this model work with /64s, maybe it's possible to imagine
changing SLAAC.