Re: [v6ops] Implementation Status of PREF64

[Lorenzo Colitti <[e-mail]>]

On Fri, Oct 1, 2021 at 2:15 PM David Farmer <farmer=[e-mail]>
wrote:

> So, is there a compromise somewhere between 1 and 2^64 addresses to be
> had? Isn't it possible to request multiple addresses, that is to request
> multiple IA_NA options? Then if the server returns a number of addresses
> below a threshold, then refuse the addresses?
>

Well, let's find out. :-)

Let's see if we get enough consensus to work on an RFC that says that all
general-purpose DHCPv6 clients are entitled to receive N addresses; that
any network that does not provide that number of addresses is in violation
of the RFC; and that any client disabling the IPv4 stack if it does not get
at least N addresses is in full compliance with all IETF specifications
including RFC 8415.

Personally I will be very surprised if you get consensus on any N even on
this thread (let alone the WG or the IETF). The reason for that 1 is
unacceptable to some folks, but any time you go beyond 1, then lots of
infrastructure needs to be changed. And that's the rub here: IMO, when
folks say they want DHCPv6, it's not because they want security or access
control or tracking or whatever else. It's because they want to run their
networks *in the same way as they do in IPv4*. That means an IPAM that maps
one MAC to one IP and one DNS name, for example. If you're an enterprise,
that's a legitimate desire: why pay costs that you don't think are
necessary? The problem is that the enterprise does not pay the costs of
NAT; device manufacturers, app developers, and users do. It would be good
for users to stop having to pay those costs when we upgrade to IPv6. This
is where we're stuck I think.

Another reason for not having a hard number is that TCAM is expensive and
that any number that would provide enough flexibiilty in the long term
(e.g., one IPv6 address per app on the device) would likely be too
expensive today. That's obviously easily solved with DHCPv6 PD, but the
problem with DHCPv6 PD is that it's not IA_NA, and requires infrastructure
to be changed. Same problem as above.

Anyway, we can try this out as a thought experiment. I'll start: how about
N=64?