Android (lack of) support for DHCPv6

Lorenzo Colitti lorenzo at
Wed Jun 10 02:48:38 UTC 2015

On Tue, Jun 9, 2015 at 12:14 PM, Paul B. Henson <henson at> wrote:

> It looks like one developer simply refuses to implement it because if he
> did there might be a scenario where somebody might not be able to tether
> 8-/?

That sounds pretty stupid even for me, so probably something got lost in

I think what I said is that supporting DHCPv6-only networks will eventually
force OS manufacturers to implement IPv6 NAT. This is because there are
many features inside a mobile OS that require multiple IP addresses. One
example is 464xlat. Another example is tethering (and no, much as network
admins would like that, users and product management will *not* accept that
tethering is "disabled because the network "does not provide enough IP
addresses" - they will just want the feature to work, even if it breaks
apps some of the time). Another example is any function that mostly lives
on a mobile device's baseband processor and needs to access networks that
are connected through the application processor (e.g., wifi calling, ePDG
access, etc.)

In IPv4 we use NAT for all that, and that's unavoidable due to lack of IPv4
space. That reason does not apply in IPv6 though. With SLAAC or DHCPv6 PD,
these functions can use their own IPv6 addresses. With stateful DHCPv6
addressing, we're back to using NAT again. That means application
flakiness, battery impact due to NAT keepalives, and so on.

It also means that things that don't work behind NAT (e.g., 464xlat, which
requires its own IPv6 address) cannot be made to work at all.

His attitude is that you have to use SLAAC and RDNSS, which we're
> just not going to do.

You don't "have to do" SLAAC and RDNSS. For as long as the network provides
IPv4, there won't be a problem for anyone. And I assume you're not planning
on turning off IPv4 tomorrow, because a whole lot of things will stop
working if you do that

More information about the NANOG mailing list