On Wed, Jun 10, 2015 at 3:20 AM, Ray Soucy <rps@maine.edu> wrote:
Clients should support a verity of methods and let network operators choose the solution that fits the environment. The whole premise for not supporting DHCPv6 seems to be that mobile networks don't need it, but that totally ignores 802.11 which is equally important.
No, the premise is that from a user's point of view, DHCPv6-only networks cause regressions in functionality compared to IPv4-only or dual-stack networks. For example: IPv4 apps cannot be supported at all due because 464xlat cannot be made to work, and functions such as tethering cannot be implemented because there are no IP addresses to assign to downstream devices. Implementing IPv6 NAT can resolve some but not all of these regressions (for example, IPv4 apps still cannot be supported). Thus, attempting to operate on DHCPv6-only networks a) will create pressure to implement IPv6 NAT, which causes lots of issues like application complexity, battery life issues due to keepalives, etc. b) impose user-visible regressions even if we do implement IPv6 NAT.
From a user's point of view, that's just a bad deal, especially since IPv4-only networks, dual-stack networks, and IPv6-only networks using SLAAC do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD have none of those issues, either. If we really need stateful addressing, then we should statefully assign prefixes, not single addresses.
I understand that "stateful-one-address-per-device-DHCPv6-only" is easier for network operators, but SLAAC really isn't that much harder, and in the long run, we'll get more robust apps, better battery life, more innovation, and happier users.