Re: [v6ops] Implementation Status of PREF64

[Lorenzo Colitti <[e-mail]>]

On Fri, Oct 1, 2021 at 12:59 AM Owen DeLong <owen=
[e-mail]> wrote:

> This is the problem, right here… There are networks where the
> administrators do NOT WANT this to be up to the user. They want control
> over certain policy aspects on their network. You are free to call them
> whatever names you want, but their networks are part of the target audience
> for IPv6 and they aren’t going to deploy it unless they have at least
> equivalent policy enforcement tools to what they have in IPv4 and they’re
> going to have to be implemented in a way that provides at least some
> familiarity or clear roadmap of the transition.
>

I don't think anybody disagrees (well, I certainly don't) that networks
should be able to limit what services devices can and cannot access on
their network. Let's take that as a given.

I think that what SLAAC advocates are saying is "IA_NA and one IPv6 address
per device" is not the right way to do that. IPv6 addresses are plentiful,
and there's no need to force devices to only have one. Just as an example:
DHCPv6 PD is strictly superior to DHCPv6 NA in terms of functionality. The
tracking and admission control ability are exactly the same, but PD doesn't
have the problem of limiting the number of addresses per device.

Proponents of DHCPv6 can say until the cows come home that "IA_NA and one
address per device" is more deployable because people are accustomed to
DHCPv4 and one IP address per device. That's true, but it does *not* make
it a superior technical solution. Why can't we do better? More importantly,
reading this thread - why aren't we *trying* to do better? The IETF is a
technical forum, not an IPv6 promotion organization. While it might be fun
to bash implementations for not implementing particular solutions, what we
should be doing here is looking for better technical solutions to this
problem that don't have the drawbacks that IA_NA has.