Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Sep 29, 2021, at 22:53 , Lorenzo Colitti <lorenzo=[e-mail]> wrote:
> 
> On Wed, Sep 29, 2021 at 3:40 AM Gert Doering <[e-mail] <mailto:[e-mail]>> wrote:
> As a matter of fact, I know of at least one deployment in a "fortune 500"
> company that was seriously impaired due to lack of DHCPv6 support in
> Android.  They want control over address assignment, tracking of address
> assignments, and DHCP is the machinery they use for it (plus NAC, making
> sure that only assigned IPv6 addresses can be used).
> 
> But they want to support Android devices.
> 
> So, still no IPv6 today...
> 
> Is there any other way to break this logjam than to implement DHCPv6 IA_NA and accept one IPv6 address per device? What about DHCPv6 PD or /64-per-host? What about resurrecting draft-ietf-dhc-addr-registration <https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/>, so the device can inform the network of addresses it has created?

DHCPv6 PD is fine and environments where having the phone act like a router is desirable will probably be willing to do that.

That’s already there on the server side, but they’re still going to want IA_NA for the LAN connection side of it.

I don’t think there’s any way forward that doesn’t require implementing DHCPv6 IA_NA. There’s just too much momentum behind it in the enterprise from the IPv4-based expectations.

It also doesn’t help that any additional options in RA (which are mostly a bad idea anyway as RA was supposed to be very lightweight) wouldn’t be administered by the people who administer the DHCP servers in IPv4 in most enterprises.

The teams that normally administer the host configurations through DHCPv4 options aren’t going to want to have to open tickets with the networking team to get those options set up in RA, they’re going to want to administer them via DHCPv6 directly.

Owen