Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Sep 30, 2021, at 18:53 , Lorenzo Colitti <lorenzo=[e-mail]> wrote:
> 
> On Fri, Oct 1, 2021 at 9:35 AM Owen DeLong <owen=[e-mail] <mailto:[e-mail]>> wrote:
> That’s not what is being said. A lot of this has little to do with what they are accustomed to and a lot more to do with a combination of:
> 	+	Enterprise policies that they cannot conveniently change
> 	+	Government and other regulations that they cannot avoid
> 	+	Reporting requirements that they cannot subvert
> 	+	Limitations of the tools they have available to comply with the above.
> etc.
> 
> Ok, but many of these points can be addressed in other ways:
> For reporting: many vendor platforms support ND binding logging via syslog, and something like draft-ietf-dhc-addr-registration <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/> would likely make it much easier for networks that use DHCPv6 only for tracking/forensics (vs. for access control) to move away from IA_NA. Specifically, it would satisfy the reporting requirements and make it a lot easier for the tools to adapt because it's still using the DHCPv6 protocol.

But those tools aren’t readily available as already built-in enterprise management tools. IA_NA is.
> Enterprise policies and government regulations are not written in a vacuum, they're written to address business and legal requirements, and I really don't think you can credibly claim that DHCPv6 is a business or legal requirement. The legal requirements are things like tracking, access control, etc.

Sure, but the tools people have that do that today are based on DHCP and the path of least resistance (both bureaucratic and technical) is IA_NA.
>  
> In other words, you keep trying to suggest that there are alternative technical solutions, but you ignore the fact that this is NOT a technical problem.
> 
> Actually what I'm saying is that we (the IETF) do have a technical problem, regardless of the status of implementations, which the IETF doesn't have much of a say in anyway. The problem is: there is no IETF consensus that "IA_NA with one address per device" is a good technical solution. So: why aren't we looking for a way that's better for everyone involved (users, implementers, operators)? Even if you're 100% convinced that utimately all platforms will implement IA_NA with one address per device, isn't it a better outcome if that model is limited to a few networks, and networks with less stringent requirements or less dogmatic operators can use a technically better solution that we come up with in the meantime?

There’s also no consensus that it isn’t a viable solution that would allow enterprises to move forward. Virtually every other vendor has implemented it and android is the one standing in the way of progress here. While I realize we’re discussing this in the context of an IETF list at the moment, the reality is that this thread really is more about facilitating deployment than protocol development and IA_NA will accomplish that even if you don’t like it.

> Of course, there may still remain network operators that say, "my network, my rules; my one IA_NA way or the highway". But if your main concern is accelerating IPv6 adoption, then if we come up with a solution that's not IA_NA and satifies some (even if not all) enterprise requirements, then that's pretty likely to help adoption of IPv6 in enterprises that have a real business need for IPv6.

I think what you are not hearing is that there are already MANY enterprise operators that are saying “my network, my rules; my one IA_NA way or the highway”.

If you want to come up with other solutions in parallel, be my guest, but please make it possible for android to obtain an address via IA_NA.

Owen