Android does not support DHCPv6 and Google 'Won't Fix' that

Since 2012 there has been a ticket open on Google's public 'Issue Tracker' requesting Android support DHCPv6. On 6th November the status of the issue was changed to 'Won't Fix (Intended Behavior)'.

The fact that Android does not support DHCPv6 may come as something of a surprise to those network engineers more familiar with IPv4. DHCP is a keystone of IP networks, one piece of network automation that has been widely adopted for years, and an important source of auditing by storing the IP and MAC address combination at the server.

Autoconfig baked-in

But hang on you 32-bit wranglers, we are talking v6 here and that protocol has host address generation baked in, in the form of Stateless Address Autoconfiguration, or SLAAC. In the v6 world, the local gateway acts as vital source of information for the attached end clients, issuing periodic Router Advertisements, or RAs. These advertisements can contain the local prefix, and if that is a /64 with the 'A' flag set, the end client can generate its own address; using the /64 as the network portion and making up the other 64 bits itself. Moreover, it allows clients to generate multiple, temporary prefixes to help prevent attacks and surveillance.

Not so fast

That's sorted then, no need for DHCPv6? Well, not quite. Some network admins after decades of using DHCP for, you know, administration of their networks aren't so willing to just hand over the controls to the end clients in this manner. While DHCPv6 doesn't offer the direct auditing that DHCPv4 does because there's no address-to-MAC stored on the server anymore, some admins wish to have control over end client addressing, and to at least be able to limit the client's number of addresses.

Resources to burn

One of the major challenges regarding new IPv6 deployments, and especially dual-stack, is gateway hardware resources. The switch or router, that acts as the Layer 3 gateway, only has a finite amount resources to use for entries in its tables. This applies to IPv4, with the ARP table, and to IPv6, with the Neighbour cache. If you check the datasheet for any such device you'll see a maximum number for these tables, exceed that and bad things happen; clients lose connectivity, skype calls drop and expensive lattes get spilt.
Also, these tables are shared between protocols, so dual-stack is particularly bad here, burning up v4 and v6 resources at the same time. I've personally heard a couple of stories from admins of dual-stack installs that hit the table size problem.
Lack of suitably sized switch resources can hinder IPv6 deployments by ruling out using the existing hardware, which quite probably was drawn up without v6 in mind, forcing admins to wait until new hardware is deployed.

Dual-Stack is not the end goal

Moreover, probably most importantly, there's the higher cost of kit with larger table sizes. Running a dual-stack network isn't the end goal, a full v6 network is, with dual-stack just a temporary measure while apps and services slowly migrate to IPv6.
These are just some of the very real problems that admins face today when deciding whether to deploy IPv6 today, and the result is they are just sticking with IPv4.

Fear of a NAT Planet ^[1]

Yet, there are those that argue limiting the number of addresses on an end client is a bad thing. Why? Fear that after all the work the IPv6 community has put into killing off NAT, after all the lecturing about restoring end-to-end connectivity, admins will nod along then sling the glossy v6 features catalogue in the trash and deploy their new shiny networks using the methods of the past: One address per client and translate at the gateway, the dreaded v6 to v6 address translation or NAT66!
Over the years since it was first opened, Issue 36949085 has become something of a fiery forum. At the risk of over-simplifying six years of comments, the basic playbook is that poster's request DHCPv6 with varying degrees of reasoning and an Android engineer, Lorenzo Colitti, responds with his arguments against. Over time, Colitti, provides various counter-arguments to DHCPv6 such as a single prefix to a device will break tethering (Comment #53) to the aforementioned wish to prevent widescale NAT66 (Comment #97). Posters then respond arguing back, sometimes losing their cool.

Pro IPv6, no DHCPv6

Now this isn't to say that Colitti is part of the anti-IPv6 crowd or someone that doesn’t have any vested interest in the new, twenty year old, protocol. Colitti is in fact a vocal advocate for IPv6, stating back in May 2008 in a Google IPv6 presentation; 'IPv6 is good for the Internet, and we want to help'.
Nor is he just ignoring the situation, going so far as to lead the composition of an IEFT Best Current Practice, RFC 7934, which lays out in detail the benefits of not restricting IPv6 clients to just one IP address.

However, I find some of the reasoning laid out in RFC 7934 against restricting addresses, and thus DHCPv6, somewhat specious. For example, Section 4 uses three reasons why admins may want to limit addresses and the problems of doing so:
1. Device hardware limitations, the finite resources of the gateway, are acknowledged in Section 4 but are dismissed with 'hardware limitations are expected to ease over time'. No effort is made to justify this comment.^[2]
2. Business models that charge for network usage based upon per-IP address are dismissed as 'counter-productive' and could increase support costs if NAT is deployed. If this is correct why do these business models exist in the IPv4 NAT world at all? No further reasoning or evidence is given.
3. Operational consistency with the current IPv4 model. This is mentioned but no counter-argument is even given.

The RFC goes on to make the argument that NAT is not desirable, and states that 'Wide deployment of networks that provide a restricted number of addresses will cause proliferation of NAT66 implementations.' But the warnings against NAT66 already seen in the wild make me feel like the authors are reaching somewhat. NAT66 has been supported on Linux since 2012. Personally I'm not surprised, Linux supports a huge number of features, that doesn't mean, nor has resulted in, an explosion of NAT66 networks.

No DHCPv6 coz...VirtualBox??

According to RFC 7934, NAT66 is supported by hypervisors, VirtualBox is cited. Personally, it was this that really made me look into this situation to this level of detail and makes me think this RFC is over-reaching in its efforts to justify its arguments.
NAT is the default setting for new VirtualBox VMs but that strikes me more as a way to provide a simplest way for the VM to gain access to the host's network and it is a virtual networking decision on a single host that has no bearing on the wider network design. I usually just deactivate NAT by altering the VM adapter setting to 'Bridged', here the VM has its own IP address directly on the host network so I can SSH directly to it rather than bothering with port translation.
Moreover, this applies to desktop virtualization, hardly a first-class feature in today's networks, rather than Enterprise grade hypervisors such as ESXi or Hyper-V. Using VirtualBox as an example of the rising tide of NAT66 undermines the argument for me.

The RFC then makes the case for allowing clients to generate their own addresses so as not to have to incur the overhead of requesting an address, as with DHCPv6, and recommends SLAAC or even DHCPv6-Prefix Delegation. This latter point would result in each client receiving a prefix from a DHCPv6 server rather than a single address. Thus the client could generate multiple addresses from its prefix. I find this an interesting proposal but highly unrealistic in the real world. The idea would result not only in all of the current differences and nuances which have hindered large-scale deployment of v6 thus far, but make v4 to v6 differences more acute by throwing into the mix a completely different paradigm of addressing. That of end clients being assigned whole prefixes rather than single addresses and defining end clients as 'IPv6 routers'.

"A great man once said..."

Where the wheels really fall off for me though is that after this RFC was published, Lorenzo, in Comment #184, quotes RFC 7934 Section 8, 'best current practice is that general-purpose hosts should be able to use new addresses without requiring explicit requests for address space.' Stating that SLAAC and DHCPv6-PD fulfil this requirement and Android could support DHCPv6-PD in the future. Quoting from a document that you were the lead author of somewhat undermines the argument for me, especially when failing to acknowledge this as though your own words are consensus. This fact is not lost on subsequent posters.
Comment #184 is Lorenzo's last entry for a couple of years until a vulgar criticism of him recently, soon after which he moved the ticket to 'Status: Won't Fix (Intended Behavior)'. That change has led to another twenty or so comments requesting DHCPv6 be implemented.

N.B. As I was writing this blog, Lorenzo has commented further on the Issue. He's still quoting his own RFC but I find this line interesting, note the use of 'we':
We are aware that consistency with IPv4 could, on some networks, make it easier to deploy IPv6 with DHCPv6 instead of with SLAAC. But it's also true that that would lessen the value to users of such networks. As an operating system, Android has to make a choice on whether to support a deployment model that is not recommended by the IETF and has downsides for users. At the moment we believe our users are best served by not supporting that model.

Six years, 270 comments

So here we are, six years, over 270 comments and one RFC later with no change in Android's position regarding DHCPv6. Sure they might implement DHCPv6-PD but that isn't what anyone is asking for. While global IPv6 traffic hitting Google edges slowly above 25%, lead by mobile, Enterprise deployments are in the domain of the early-adopters, so much so that this year the UK IPv6 Council held a meeting especially for Enterprise to address the lack of movement in these networks. While I found Lorenzo's comments annoying to read, the personal name calling is simply wrong. It isn't just Lorenzo with an '@google.com' handle in the thread and Vint Cerf co-authored RFC 7934, which makes me think that this is not just Lorenzo's stubborn refusal to change his mind and others at Google back his decision.
While we engineers debate the technicalities, the network admin's I've spoken to recently have all expressed the same general wishes; they want simple, reliable and secure. Plus a healthy discount, that goes without saying. Persuading them to move to IPv6 is difficult enough of an argument as it is, without Android creating another caveat to be considered.

Silver, Gold or Space Grey?

Personally I believe people should be able to implement their networks as they choose and it isn't for a single handset OS to decide how Enterprise networks are designed. With all other popular client OS supporting DHCPv6, including rival iOS, Android's position appears illogical to me. Rather than Android acting as the valiant crusader against the threat of NAT, by being the odd one out, it has become a great excuse not to implement IPv6 in Enterprise. But rather than resorting to personal insults I think it will have to be large Enterprise, and their financial clout, that ultimately makes this decision. If one of Google's bigger Enterprise customers really cannot live without DHCPv6, that will be the deciding factor. As for me, researching all this has made me seriously think about owning my first iphone.

@joeneville_

EDIT: 14Aug2019

No change to the case. Comments are at 278, the ones this year are the same kind of thing. People asking for DHCPv6.