Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Sep 27, 2021, at 22:21 , Lorenzo Colitti <[e-mail]> wrote:
> 
> On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=[e-mail] <mailto:[e-mail]>> wrote:
> No… That’s not what it amounts to.
> 
> It amounts to a machine can only use the network _IF_ it completes 802.1x Authentication _AND_ the IP address(es) it is using match the DHCP server’s expectation of the address it issued to the MAC address in question.
> 
> Why would you want to do this? IPv6 addresses are plentiful and ephemeral. What does it matter to some server on the Internet (or, in general, off-link) if a given host uses 2001:db8:1:2:3::f00 or 2001:db8:1:2:3::b00 or both? Why take the privacy implications of using a fixed IID (because DHCPv6 can't seamlessly change IIDs) to talk to all off-link destinations all the time?

Because whether you like it or not, whether you approve of it or not, some enterprise policies require it.

It’s not a technical problem. It’s a policy problem.

>> This is better than the DHCP version above because it allows the client to use multiple IP addresses and does not need to be re-done when the IP address changes.
> Sometimes the network administrator doesn’t want the host using multiple IP addresses for a variety of reasons.
> 
> Ok, but that's also harmful for a variety of reasons, and for general purpose devices, it's not recommended by the IETF. That's exactly what RFC 7934 is about - explaining why it's harmful.

What you call harm, others call policy. It’s not your or the IETF’s job to tell enterprises what their network policy should be, let alone holdup IPv6 adoption because you can’t get it through
your head that no matter what the IETF or you or anyone else says, they have the capability in IPv4, they like the capability, and they won’d deploy IPv6 without it.

So which is the greater harm? Holding up IPv6 adoption by enterprises because you don’t like their policies, or the policies themselves?

IMHO, it’s the delay of IPv6 deployment that is the greater harm here.

> 
> I repeat… Your anti-DHCP religion is NOT HELPING.
> 
> Not helping with what? The transition to IPv6? But if so - why bother using IPv6 if it's just just 128-bit IPv4, with one address per host, no dynamic address changes (because DHCPv6 can't really support that) and NAT (because if you can't tell the host that its network configuration has changed, you need to ensure that the configuration *doesn't* change)? Why use IPv6 to do that, which requires hosts to implement all the associated complexities such as NAT traversal, NAT keepalives, etc.? That model works perfectly well today using IPv4, and I'm pretty sure that OS support for IPv4 isn't going anywhere any time soon.


Yes.

DHCPv6 can support dynamic address changes on pretty much the same terms as SLAAC.

You can tell the host that its network configuration changes just as well with DHCPv6 as you can with SLAAC, so no, this does not create a need for NAT.

DHCP has all the same timers that SLAAC does.

Owen