On Tue, Jun 9, 2015 at 12:14 PM, Paul B. Henson <henson@acm.org> wrote:
https://code.google.com/p/android/issues/detail?id=32621
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 translation. 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