Android Phones Might Ask for /64 Delegated Prefix
I’m too old to be fighting with windmills, but sometimes I have to get a rant off my chest. This one was triggered by the latest episode of the hilarious1 “DHCPv6 on Android” soap opera
In a 720-degree turnaround, Android 11 supports DHCPv6, but only for prefix delegation purposes. Yes, you got it right, in a year or two, every phone might want to have a dedicated /64 prefix assigned to it on WiFi segments2.
Want more details? Well, there’s a high-level overview published on the Android Developers blog and a corresponding message sent to the v6ops mailing list. Let’s see how much sense that makes.
If you’re new to the DHCPv6-on-Android soap opera, please note that the blog post was authored by the same person who has been opposed to ever having the DHCPv6 client on Android for over a decade and made all sorts of ridiculous excuses to justify his position.
Also, I’m not saying that delegating a prefix to a host is a bad idea in principle. It’s just that most “arguments” in the feature announcement make no sense, including the concept of allocating a /64 prefix to a phone just so it could tether another device.
So, here’s the gist of that blog post:
- IPv4 is bad (OK, we know that)
- IPv4 is bad for batteries because phones need to keep NAT sessions alive. To me, this makes as much sense as my usual quip that copy-paste makes rockets explode, but maybe I’m missing something.
- We couldn’t solve that problem with IPv6 because the existing address assignment policies have limitations.
While I know that networks have already experienced the ND cache exhaustion, the root cause is usually a crappy implementation that grabs too many addresses and holds onto them due to long-lived TCP sessions, not the limitations of address assignment mechanisms. However, I think anyone with any operational experience in replacing IPv4 with IPv6 knows that ND cache exhaustion is not the leading cause of IPv4 persistence.
And then there’s this gem:
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.
Imagine the audacity of the lead crusader against DHCPv6 clients repeating the claims he’s been hearing from frustrated network operators for decades as an argument for why IPv6 hasn’t solved the problem yet. If the Android Core Networking team actually cared about users’ and operators’ concerns, they could have solved the problem ages ago. If this isn’t the pinnacle of hypocrisy, I don’t know what is.
So, what’s the solution to all these insurmountable problems? It’s a DHCPv6 client on Android (SURPRISE !!!), but not to get controlled IPv6 addresses, but to request a whole /64 prefix for every Android device. Why would anyone need that?
Here are the arguments from the blog post:
- In some future release, that delegated prefix would be shared with wearable devices or a hypothetical tablet tethered to an Android phone connected to WiFi3. Let me point out that you don’t need a delegated prefix for that. Mobile phones have supported tethering on IPv6 for ages; they simply extended the “outside” /64 prefix to the tethered network. There’s no need for a different mechanism from WiFi to Bluetooth/USB. Also, my Apple Watch connects to WiFi directly (just saying).
- This realizes the potential of IPv6… without requiring NAT. Meh. Allocating another “outside” IPv6 address with DHCPv6 IA_NA mechanisms gets you to the same goal. But even if you were using NAT in the Android device to hide tethered devices behind the same IPv6 address, there would be no need for keepalives because Android would have control over the expiration of the NAT sessions. The Android device must be active whenever that NAT session is used because it needs to forward packets anyway.
- Because the prefix is assigned by the network, network operators can use existing DHCPv6 logging infrastructure to track which device is using which prefix. Gee, thanks for the roses, but you don’t need IA_PD for that. Get off your crusade horse, implement a DHCPv6 client doing IA_NA like any other IPv6 implementation, and stop gaslighting us.
Without going into too many details, instead of using a reasonable number of IPv6 addresses on a WiFi network, the “solution”4 offered by the Android Core Networking team expects the network to allocate a /64 prefix to every Android device.
But the “new” approach reduces the ND cache, right? Isn’t that a good thing? Not so fast. Delegating a prefix to a device uses an ND entry and a routing table entry. Low-cost edge switches have always had fewer routing table entries (that use more expensive TCAM or similar hardware) than ND entries (that use simple hash tables). Depending on the hardware you use, going from multiple on-link addresses to prefix-per-host might exhaust the forwarding resources even sooner.
Even worse, the “delegated prefix” approach requires the edge switches to keep track of DHCPv6 prefix delegation state, synchronize it between multiple switches connected to the same segment, and fetch it from the DHCPv6 server on reloads (the gory details are in RFC 9663). None of that is needed if the network is using DHCPv6 IA_NA address delegation – the state is kept in the DHCPv6 server(s), and the edge switches build the ND cache in the same way as if the attached devices were using SLAAC (unless you deployed Source Address Validation).
To recap:
- The Android Core Networking team has yet again chosen to make their lives as simple as possible5 while offloading all the complexity and hard work onto everyone else.
- They implemented the DHCPv6 client on Android in the most useless way for people who just want to run their networks in a bit more controlled way. If they cared, they could have implemented address allocation (IA_NA) and prefix delegation (IA_PD). However, I’m pretty sure they will claim “they listened to the network operators and implemented DHCPv6 to help them track network devices”
- When this gets rolled out and the developers start using it, expect complaints if your network won’t support it.
- To implement this, you’ll likely have to request more IPv6 address space and rework your IPv6 addressing.
Finally, as a cherry on a cake, the Google blog post concludes with:
We hope this change encourages more networks to adopt IPv6, leading to improved battery life, reliability, and code simplicity in these complex networking scenarios.
One cannot make this stuff up.
-
If you’re privileged enough to watch it from a distance. ↩︎
-
Every mobile device was traditionally assigned a /64 prefix on mobile networks because the networks treated every network-to-device connection as a point-to-point link (yes, it’s tunnels all the way down). I have no idea whether 5G still uses that model, and I have no willpower to start figuring that out. A helpful comment would be much appreciated. ↩︎
-
Can you, please, try to find an example that isn’t so obviously mocking your audience’s intelligence? ↩︎
-
… in search of a problem ↩︎
-
There are alternate ways of solving the problem, but they require actual work, not writing RFCs and forcing your way through IETF working groups. ↩︎
Not to mention that if you embrace this new way of doing things, it kinda tears your address plan to shreds. The whole promise of answering "/64" to every "how big should this segment be?" question now goes out the window.
If you're running a sizable campus network and you assume the worst-case (every device is an android device), then we're back to playing "right sizing" games just with prefixes instead of addresses. Or you can just pretend that IPv6 addresses only has 64 bits and then re-adopt IPv4 thinking.
Looking at an example -- In your address plan, if you had assigned a /48 to each building and used 8 bits for "function" and 8 bits for an instance (in case you needed multiple VLANs to deal with broadcast domain size), then you can really only assume 250 devices for android in any given function, which isn't a lot.
Now realistically, most big networks I know of tunnel wireless traffic to a central controller cluster, which helps if had a big 'ol "reserved for future use" in the top level of your address plan that you can devote to Android.
My ranting aside, it really does necessitate that everyone re-examines address plans.
> IPv4 is bad for batteries because phones need to keep NAT sessions alive. To me, this makes as much sense as my usual quip that copy-paste makes rockets explode, but maybe I’m missing something.
This part is true, Ivan. Dating back to 2013 (or as early as 2011 IIRC, it's been a decade+ since I read it), there was a paper Cisco published (I can't find it now, but you may have better Google fu skills than me) that demonstrated/studied how CGNAT/NAT = battery expense due to NAT keep-alive traffic.
I think rfc6269 and rfc6887 also talked about batteries.
The apps running on the host keeps sending those packets every X seconds, which means a lot on mobile devices' battery runtime. Keep in mind, the mobile phone can have like 200 apps, and maybe 20-50 do “light” background NAT keep-alive every X second. VoWiFi alone in my testing sends keep-alive every 5–10 seconds — this is insane.
Anecdotally, I've run a lot of “tests” in my home lab (I have physical transit, public routed v4/v6 blocks, no NAT aka NAT-only for testing) over the past 4–5 years. Go to sleep with iPhone at 100% battery (verified by CoconutBattery), wake up to 10% drain with NAT (no IPv6) vs wake up to 1-2% or 0% drain with NAT+native IPv6 or native IPv4+native IPv6.
The “fair” compromise I found that worked best for real-world networking: 1. IPv4 CGNAT/NAT with EIM-EIF (hairpin too, because TURN). 2. Native IPv6. 3. Move on with life.
Yes, I'm obsessed with battery life on mobile computing devices, off-topic, but I recommend every tech person to read everything here: https://batteryuniversity.com/
Don't quote me on this one, just what I've heard/seen: Regarding LTE/5G, I believe the general practice is a /64 link-prefix per PDP/PDU(I think this is 5G terminology) context/session, the UE then generates /128s using SLAAC. However, some Telcos may already be doing /64 ia_pd for a long time.
Few folks in the consulting world have advocated for /63 ia_pd per UE in LTE/5G for a long-time, some I heard deployed this successfully in the past, but there's no public-facing docs or presentations/talks about this as far as I know.
But I recently had a chance to talk to an MVNO, and I asked about IPv6, turns out 3GPP world is a mess and not every EPC software maker implemented IPv6 specs the same way, so in this instance, the IPv6 UE Pool — nobody knows what it means ia_na? ia_pd? SLAAC? Something magical? No idea 🤷♂️ I just advised them on future proofing the subnet plan and moved on with my life, don't have bandwidth to learn that world of networking.
Thanks a million for the battery info -- that might explain my iPhone's battery drain when I'm roaming.
For a crash course in "what might be going on":
What about persistent connections behind stateful firewalls? Wouldn't a keepalive be required anyway in IPv6 networks with stateful firewalls and there is currently no way for a client device to know whether the current network has one?
Pssst... Don't spoil their beautiful fairy tale ;)
On a more serious note, there are mechanisms like Web Push that might be able to wake up a mobile device with an incoming packet. Obviously, that requires a persistent session, so a NAT state, but also a stateful firewall state, has to be maintained.
However (yet again, I don't know enough), it could be that there are no stateful firewalls in mobile networks, and radio is a much bigger power consumer than WiFi.
In properly done LTE/5G networks, the UE has native IPv6, without any stateful middle-box breaking the IPv6 P2P principle. Jio in India does this with 400mil+ subscribers on LTE/5G, even port 80 was open-able on IPv6 if you tried it in the past on your Android phone with root using a Jio LTE/5G SIM Card.
DPI does exist for legally-enforced censorship, but this isn't SPI. DPI doesn't break P2P. No keep-alive required.
Security oriented mobile OSes like GrapheneOS use eBPF IIRC for better battery performance. The “web push” is an issue of its own that's beyond my competence, but GrapheneOS team has discussed this extensively over the years. It's battery draining, that's for sure.
For home networks or “enterprise”: Stateful firewall on IPv6 != NAT. STUN keep-alive will still exist in such a case, but there's no TURN traffic for the end-user application, eliminating one layer of network traffic that would consume battery. Again, you can replicate this in your home lab, assuming you have native v4/v6 locally (no VPN tunnels which also consumes resources because of crypto) and run the battery tests overnight with the same phone/same apps etc, v6 is simply better if done correctly (even with SPI, which assumes is done correctly as well).
You mentioned extending the WiFi prefix to the tether as an option but that only works with SLAAC. It theoretically could be done with DHCPv6 but likely wouldn't be as there's no guarantee you can get multiple addresses. This in general gives me very mixed feelings about the Android policy. On the one hand I see the frustration but on the other hand I feel like the restrictions actually do benefit v6 usability from a users perspective.
> You mentioned extending the WiFi prefix to the tether as an option, but that only works with SLAAC.
How many realistic scenarios have you seen where a phone connected to a WiFi would offer a tethered IPv6 connection to... what? Over what?
There's a reason my Apple Watch has a WiFi interface -- I can use it even when I'm in another room than my phone.
> There's no guarantee you can get multiple addresses [with DHCPv6]
If you use different client identifiers for tethered devices, you'll get multiple addresses, right?
> This in general gives me very mixed feelings about the Android policy.
You say policy, I say crusade ;) No other major vendor has a problem with running a DHCPv6 client using IA_NA on their IPv6 hosts.
> How many realistic scenarios have you seen where a phone connected to a WiFi would offer a tethered IPv6 connection to... what? Over what?
They don't do this now...at least android doesn't much to my disappointment. They SHOULD offer it and currently do not. I think it's because for SLAAC this requires an NDP proxy and technically the way this works on cellular is different from that but I'm guessing.
> There's a reason my Apple Watch has a WiFi interface -- I can use it even when I'm in another room than my phone.
Why are you focused on smart watches? Those typically use a different system from tethering, at least on android. In fact my smart watch does some weird voodoo proxy non-sense and doesn't even count as a tether. I'm mainly focusing on connecting devices to a phone and then using the phone as a sort of WiFi proxy. For example connecting my laptop to my phone while my phone is on WiFi.
> If you use different client identifiers for tethered devices, you'll get multiple addresses, right?
Interesting point, what if they configure a policy such that each mac address can only have a single address? The reason I propose that is because if their goal is to restrict devices to 1 address then it becomes trivial to just use multiple DUIDs to bypass that restriction so it's not a very good way of enforcing that policy.
> You say policy, I say crusade ;) No other major vendor has a problem with running a DHCPv6 client using IA_NA on their IPv6 hosts.
To be clear I'm not entirely in support of android's "crusade" but I do see some concerns with DHCPv6. It's not that there's a problem with using IA_NA, it's more that it opens the door to less than ideal v6 deployments from a users perspective. With v4 (because of NAT) I can tether from my phone to other devices, I can't do that with v6 IA_NA if the network restricts addressing to 1 per device (or 2 for 464XLAT). The same goes for running virtual machines on a laptop which can be done with v4 NAT or with v6 using an NDP proxy with SLAAC. Basically I guess, TL;DR: I'm not against DHCP IA_NA, I'm against anything that has the potential to force people into using v6 NAT because NAT is the one thing I will crusade against.
Aside about my smart watch because I find it interesting: I have a moto 360 android wear smartwatch. It assigns itself an IPv4 address to a Linux ifb interface. The watch does not get an IPv6 address at all even when on cellular. I don't know exactly how it works but there is no corresponding tether interface on the phone and the watch cannot emit ICMP. My assumption is it seems to be some form of userspace proxy to the android wearOS app. It's not using bluetooth tethering as that can be disabled while the watch still has internet and bluetooth tethering creates a pan interface with dual stack addressing that the watch doesn't need or use. I suppose I should do a bit more digging to try to understand what's going on as it's a really odd setup. This whole fiasco has been a nuisance for my personal network since the watch doesn't support WPA3 and my network is WPA3 only and v6 only so my watch has no internet at home. The bleeding edge is...sharp and bloody lol.