Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Oct 10, 2021, at 20:35 , Lorenzo Colitti <lorenzo=[e-mail]> wrote:
> 
> On Mon, Oct 11, 2021 at 9:16 AM Owen DeLong <owen=[e-mail] <mailto:[e-mail]>> wrote:
> Agreed, but the device manufacturer, OTOH, is somewhat in control of what their device will or won’t do and if Lorenzo/Google want to impose that limitation on their implementation, the IETF shouldn’t be able to stop them any more than it should be able to dictate that they must do so.
> 
> Guess what, Lorenzo… That’s the current situation. The IETF is mute on how many devices must be provided via IA_NA or whether or not you can implement some minimum acceptable number or disable the IPv6 stack as a result.
> 
> Therefore, you are not prohibited from doing so.
> 
> Ok, but would that solve the issue in this thread?
> 
> Suppose an OS developer ships a DHCPv6 implementation that requires N addresses and does not enable the IPv6 stack unless it receives all of them. How does that do anything to address statements such as, "my network, my rules" that have been made on this thread? Any operator that wants to assign only one address per device still cannot use such hosts on their network, and can still criticise the implementation for not doing what they want.

At least it provides a possible way forward for networks that don’t want to assign addresses outside of IA_NA or IA_PD to provide addressing to android devices.

Surely a single IA_NA + a routed IA_PD would meet your requirements, right?

> What I think David was suggesting is: if we reach consensus on some reasonable value of N, then the IETF could write a BCP to that effect. That would help to some extent, because if an operator complains that the implementation does not work on a network that has N=1, the OS developer could point to the BCP as justification for why.

I don’t think that’s really necessary. I think there are already adequate documents about single-address is less than ideal in the existing RFCs/BCPs.

Owen