In June 2012, an owner of a Samsung Galaxy Nexus running Android 4.0.2 opened a case in Google’s Issue Tracker requesting support for Dynamic Host Configuration Protocol for IPv6, otherwise known as DHCPv6, or RFC 3315, which allows for stateful address and connection configuration on devices joining an IPv6 network. DHCPv6, like DHCPv4, is commonly used in enterprise networks for connecting devices.
For the last six years — including through five new major versions of Android — that request has languished, when this week it was marked as “Won’t Fix (Intended Behavior)” by Google engineer Lorenzo Colitti. Android is effectively the only platform which lacks support for DHCPv6, making the IPv6 implementation on Android incomplete.
SEE: Mobile device security: A guide for business leaders (Tech Pro Research)
This is an IETF published standard, which is entirely uncontroversial. Support for the standard was implemented in Windows Vista, OS X 10.7 (Lion), Fedora 9, Ubuntu 11.04, iOS 4.3.1, BlackBerry 10, and Windows Phone 8. The point of having published standards is to promote interoperability. As noted in my previous coverage of this issue in September 2015, “A certain level of expectation — if not obligation — exists for vendors to support industry standards, at least to an extent that normal use cases are supported. Deploying an enterprise IPv6 network that relies on DHCPv6 is not in any way an edge case.”
Colitti, the engineer responsible for much of Android’s networking stack, offers a variety of workarounds and rationales for not supporting DHCPv6. By merit of being a workaround, implementing these on enterprise IPv6 Wi-Fi networks creates more work for network administrators. Among these include Recursive DNS Servers (RDNSS), which is classified as RFC 8106, as well as RFC 7934, of which the lead writer is Lorenzo Colitti.
In comments in the issue tracker, Colitti states that “those saying that Android should support DHCPv6 because it is an IETF standard, please note that networks that only provide IPv6 addresses via DHCPv6 address assignment are not recommended by the IETF.”
To be fair, RFC 7934 is considered the “best current practice,” though there are multiple extant enterprise Wi-Fi deployments which support only DHCPv6. As another comment in the issue tracker notes, “best practices are often trumped by real-world requirements.”
Colitti’s objection to DHCPv6 appear to revolve primarily around that standard breaking support for IPv6 tethering, an argument which principally only makes sense for mobile networks, not for Wi-Fi. (The likelihood that a user would, on a corporate Wi-Fi network, connect a second device via USB tethering is remote to nonexistent, and would feasibly be an explicitly prohibited practice due to security implications of connecting unauthorized devices to a network.) This might be a compelling argument against allowing DHCPv6 on cellular networks, but does not hold up in the context of Wi-Fi, though Colitti appears to make no distinction between the two.
There is no technical reason this cannot be implemented. Third party implementations of DHCPv6 exist for Android, though these require root, as manipulating low-level network behavior is not normally possible with the default set of grantable permissions. Presently, the only reason this standard is not supported in Android is due to the obstinance of seemingly one engineer responsible for the networking stack. Google operates a certification program for enterprise deployment of Android devices, though lacks support for common IPv6 deployments.
TechRepublic reached out to Lorenzo Colitti, but did not receive a response by press time.
