Some DHCPv6 clients default to a /64 prefix so that this scenario works, and systems with those clients can and do interoperate. The obvious complete solution to this problem is to deliver the prefix length via DHCPv6
Right. Not doing that is a flaw in the DHCPv6 design, IMO.
at which point you may as well also deliver a default gateway, and complete the circle that starts the deprecation of RA.
Certainly not. The only one who (hopefully!) knows if a router is present and functioning is the router itself. Dead neighbor detection allows an IPv6 host to switch default gateways if one dies. Moving this functionality to DHCPv6 means that this is no longer possible and there will be more connectivity issues that must be debugged manually, like we have today with DHCPv4.
Link locals are not sufficient as they are unlikely to appear in DNS.
Works just fine with multicast DNS.
Welcome to the world of host configuration penumbra; the land of partial shadows cast by multiple overlapping lightsources and their obstructions.
I would rather move in the direction where we all implement RFC 5006 and DHCPv6 is only used to _register_ addresses that hosts select for themselves if central knowledge of which host has which address is desired.
(Perhaps MO = 11 could indicate this situation, like MO = 10 = initiate stateful DHCPv6 for address allocation and MO = 01 = initiate stateless DHCPv6 for other configuration.)
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
