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

[Martin Huněk <[e-mail]>]

Hi,

Dne pondělí 6. listopadu 2023 10:00:14 CET, Lorenzo Colitti napsal(a):
> 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.

I do have /16 of IPv4 and /48 of IPv6. By the formula presented in the draft I get the exact result:
X = 16
16 + 32 = 48
So I'm in precisely the same situation as I'm with IPv4. How is it any better than the address-space constraints of IPv4? I do not necessarily care who is to blame. I just know what I have, and even if I'm allowed to expand the address space, I would be forced to renumber. There would be almost zero gain for clients having /64 compared to /80 (when we do not allow network extension), so for me personally, having a strict /64 barrier is just a complication and a poor design choice, especially when a host is not informing how big a prefix it really needs.

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

It doesn't seem reasonable to me. It is half of my address space, and I won't be getting more; it is without reserves to expand, and I had to move several networks to clear it. If a host would have been fine with /80, I would be just fine with one /64 or /63 (or /60). I could manage just fine with what I have. It makes even more sense as we do not allow a network extension.
> 
> 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.

If any user is allowed to extend the network, how do I know who is the end user? Unsupported, not allowed things should be hard to get working. If someone tries to extend the network (while not allowed to do so), I want his/her attempt to fail. Then, the broken connectivity is desired.

Btw: Do you have any data about how big a share of a company allows the "bring your own router" policy in their corporate network? Network extension in corporate networks is not a common use case, in my opinion.
> 
> 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.

The implementers know less about the network the device is connected to than the admins running it. Quite frankly, you would not be able to know local restrictions, nor would you care.

Yes, we can make this mutual distrust basis to reconsider BYOD policies.
> 
> 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.
> 
Do you really think that? Yes, there will be some networks that will use IPv4 principles and try to conserve IP space so much that they try to give too little to clients. However, many more are adhering to recommendations made by IETF or RIR. At ISP, I give /56 to residential clients, /48 to companies (or upon request). I could give just /64 or /60, but I know what I would like to have at home and how many I can assign to maintain a reasonable addressing plan. It is up to me as a Network administrator to make the plan and configure my routers accordingly.

I'm not really in the camp of let's change an SLAAC prefix size as we would not see practical results in years to come. However, if it provides me with additional tools to manage my networks, then why not?

This draft is a bit different. If every device required a /64 and it would like to extend the network, I would be pushed around, and I hate that. Clients would push me to give them /64, SCO would push me on network security front, and RIPE policy and upstream addressing plan are constraining me with address space. Having an OS vendor pushing me with the substantial number of devices is the thing I need the least.

Regards,
Martin