Android DHCPv6 Prefix Delegation Support Later This Year

IPv4 complicates app code and causes battery impact

Most of today’s Internet traffic still uses IPv4, which cannot provide transparent end-to-end connectivity to apps. IPv4 only provides 2³² addresses - much less than the number of devices on today’s Internet - so it’s not possible to assign a public IPv4 address to every Android device, let alone to individual apps or functions within a device. So most Internet users have private IPv4 addresses, and share a public IPv4 address with other users of the same network using Network Address Translation (NAT). NAT makes it difficult to build advanced networking apps such as video calling apps or VPNs, because these sorts of apps need to periodically send packets to keep NAT sessions alive (which hurts battery) and implement complex protocols such as STUN to allow devices to connect to each other through NAT.

Why IPv6 hasn’t solved this problem yet

The new version of the Internet protocol, IPv6 - now used by about half of all Google users - provides virtually unlimited address space and the ability for devices to use multiple addresses. When every device can get global IPv6 addresses, there is no need to use NAT for address sharing! But although the address space itself is no longer limited, the current IPv6 address assignment methods used on Wi-Fi, such as SLAAC and DHCPv6 IA_NA, still have limitations.

For one thing, both SLAAC and DHCPv6 IA_NA require the network to maintain state for each individual address, so assigning more than a few IPv6 addresses to every Android device can cause scaling issues on the network. This means it’s often not possible to assign IPv6 addresses to VMs or containers within the device, or to wearable devices and other tethered devices connected to it. For example, if your app is running on a wearable device connected to an Android phone,  or on a tablet tethered to an Android phone that’s connected to Wi-Fi, it likely won’t have IPv6 connectivity and will need to deal with the complexities and battery impact of NAT.

Additionally, we’ve heard feedback from some users and network operators that they desire more control over the IPv6 addresses used by Android devices. Until now, Android only supported SLAAC, which does not allow networks to assign predictable IPv6 addresses, and makes it more difficult to track the mapping between IPv6 addresses and the devices using them. This has limited the availability of IPv6 on Android devices on some networks.

The solution: dedicated IPv6 address blocks with DHCPv6 PD

To overcome these drawbacks, we have added support for DHCPv6 Prefix Delegation (PD) as defined in RFC 8415 and RFC 9762. The Android network stack can now request a dedicated prefix from the network, and if it obtains a prefix, it will use it to obtain IPv6 connectivity. In future releases, the device will be able to share the prefix with wearable devices, tethered devices, virtual machines, and stub networks such as Thread, providing all these devices with global IPv6 connectivity. This truly realizes the potential of IPv6 to allow end-to-end, scalable connectivity to an unlimited number of devices and functions, without requiring NAT. And because the prefix is assigned by the network, network operators can use existing DHCPv6 logging infrastructure to track which device is using which prefix (see RFC 9663 for guidance to network operators on deploying DHCPv6 PD).

This allows networks to fully realize the potential of IPv6: devices maintain the flexibility of SLAAC, such as the ability to use a nearly unlimited number of addresses, and the network maintains the manageability and accountability of a traditional DHCPv6 setup. We hope that this will allow more networks to transition to IPv6, providing apps with end-to-end IPv6 connectivity and reducing the need for NAT traversal and keepalives.