> ## Content Index > Fetch the complete content index at: https://articles.akadata.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # The Lunacy of IPv6 /64 and Google's Refusal to Support DHCPv6 - URL: https://articles.akadata.co.uk/the-lunacy-of-ipv6-64-and-googles-refusal-to-support-dhcpv6/ - Published: 2025-07-26T04:39:47.000Z - Updated: 2025-07-26T05:17:30.000Z - Author: AKADATA - Tags: ipv6, /64, /112, google, android, wifi7, zen internet, ac, ax, be ### 📌 Introduction In the grand design of IPv6, we were promised limitless address space, streamlined networking, and a clean break from the inefficiencies of IPv4\. Yet, in practice, we're staring down a paradox — we have trillions of addresses, but they're unusable in any sane way for hotspot providers, network designers, or anyone running a router with real-world constraints. This is the story of how an Android phone — due to deliberate design decisions — can unravel the supposed elegance of IPv6. --- ### 🌐 Our Setup: The Reality Check We're allocated a /48 IPv6 prefix from our ISP (Zen Internet, for example), delivered via a routed /64\. This sounds generous on paper: - A /48 contains **2^16 = 65,536** /64 networks - Each /64 contains **2^64 = 18,446,744,073,709,551,616** addresses ### IPv6 Topology: The Wasteful Cost of SLAAC and Google’s DHCPv6 Refusal ``` ISP (Zen, Routed: 2A02:8011:D017:CBA8::/64, 2A02:8012:BC57::/48) | |-- PPPoE Interface (ppp0) | -> Address: 2A02:8011:D017:CBA8::/64 (proto: RA) | Router (Receives 1x /64 via RA, routes full /48 from Zen) | |-- eth2 (Inbound PPPoE) VLAN 2A02:8011:D017:CBA8::1/64 | |-- eth3 (10G uplink) | -> 2a02:8012:BC57:3::/64 (proto: kernel) (Other IPv6 Networks) | |-- eth1 (2.5G uplink) | -> 2A02:8012:BC57:1::/64 (proto: kernel) (Other IPv6 Networks) | |-- eth0 (LAN core) -> 2a02:8012:BC57:0::1/64 | [Switch] ||||| |||\-- eth0 (LAN: breath) -> 2A02:8012:BC57:0::C0DE/64 ||| -> WIFI6 -> 2A02:8012:BC57:C0DE::1/64 ||| |||\-- wan0 (LAN: bpi-4-0) -> 2a02:8012:BC57:0::CACE/64 ||| -> LAN -> 2A02:8012:BC57:3A00::1/96 ||| -> WIFI7 -> 2A02:8012:BC57:CACE::1/80 (Other IPv6 Networks) ||| ||\-- wan0 (LAN: bpi-4-1) -> 2a02:8012:BC57:0::CA11/64 || -> LAN -> 2A02:8012:BC57:3B00::1/80 || -> WIFI7 -> 2A02:8012:BC57:CA11::1/64 (Other IPv6 Networks) || |\-- wan0 (LAN: bpi-4-2) -> 2a02:8012:BC57:0::BABE/64 | -> LAN -> 2A02:8012:BC57:3C00::1/112 | -> WIFI7 -> 2a02:8012:BC57:BABE::1/64 (Other IPv6 Networks) | |-- eth0 (LAN: gannah) -> 2A02:8012:BC57:0::2/64 -> wlan0 (WIFI6: gannah Hotspot output) -> 2A02:8012:BC57:CAFE::1/64 | |-- Any device (wlan client) -> Forced SLAAC-only if Google Android -> Refuses DHCPv6 -> 2A02:8012:BC57:CAFE:DEAF::BEEF:BABE/64 ``` Yes that is REAL IPv6 Address Space We may even allow connections to be made into the network when we publish our `nftables` article to show a real world fully routed IPv6 secure network. Honeypot anyone? We configure: - `dnsmasq` and `radvd` or `freeradius3 dhcp` and `kea` - Try handing out a small prefix, like /68 /80 /112 - Android refuses Why? Because Android only supports **SLAAC (Stateless Address Autoconfiguration)**, which requires a **/64 subnet**. That means: - No DHCPv6 - No address reservations - No handing out a specific IP like `2a02:8012:bc57:cafe::babe` or `2a02:8012:bc57:cafe::code` - No options like domain search or DNS unless hijacked into RA You're left with one option: > Give every phone a /64, or give up The RFC - We sure have a request for comments [https://datatracker.ietf.org/doc/html/rfc4862](https://datatracker.ietf.org/doc/html/rfc4862?ref=articles.akadata.co.uk) ### DHCPv6 Logs: Android Refusal to Connect A possible solution is under investigation and may be installable on a Samsung S25 Ultra: [**https://github.com/akadatalimited/DHCPv6-Client-Android**](https://github.com/akadatalimited/DHCPv6-Client-Android?ref=articles.akadata.co.uk) This client may allow Android to connect using DHCPv6 instead only SLAAC worked and only on a /64 network, the phone with **18,446,744,073,709,551,616** addresses should insanity prevail. ![](https://articles.akadata.co.uk/content/images/2025/07/image-35.png) --- ### Real Logs from Android (S25 Ultra) Failure to Connect via DHCPv6 ``` 07-26 04:19:56.813 2171 4408 D WifiClientModeImpl[1709351391:wlan0]: setSuspendOptimizationsNative: 1 true -want true stack:setSuspendOptimizationsNative - handlePostDhcpSetup - stopDhcpSetup - handleNetworkDisconnect 07-26 04:19:56.842 30141 21848 D WifiPickerTracker: ... NETWORK_SELECTION_DISABLED_DHCP_FAILURE=2 ... Obtaining IP address... / 6G 07-26 04:19:56.857 30141 21848 D WifiPickerTracker: ... NETWORK_SELECTION_DISABLED_DHCP_FAILURE=2 07-26 04:19:56.863 30141 21848 D WifiPickerTracker: ... Couldn't get IP address / 6G 07-26 04:19:59.695 2171 4408 D WifiNetworkSelector: "ipv6only":89 reason=NETWORK_SELECTION_DISABLED_DHCP_FAILURE, count=2; 07-26 04:19:59.696 2171 4408 V WifiLastResortWatchdog: "ipv6only" HasEverConnected: false, Failures: {Assoc: 0, Auth: 0, Dhcp: 3} 07-26 04:20:04.394 2171 4408 D WifiNetworkSelector: "ipv6only":89 reason=NETWORK_SELECTION_DISABLED_DHCP_FAILURE, count=2; 07-26 04:20:09.704 2171 4408 D WifiNetworkSelector: "ipv6only":89 reason=NETWORK_SELECTION_DISABLED_DHCP_FAILURE, count=2; 07-26 04:20:17.429 2171 4408 D WifiNetworkSelector: "ipv6only":89 reason=NETWORK_SELECTION_DISABLED_DHCP_FAILURE, count=2; ``` ### Summary - Multiple DHCPv6 failure entries across seconds - Android declares network as temporarily disabled due to DHCP\_FAILURE - Android never attempts SLAAC + DHCP fallback combo These logs illustrate precisely the systemic limitation. The stack fails, retries, logs failure, and disables the network based solely on **absence of DHCPv6 lease**—even though SLAAC was available and configured with /66 /68 /70 thru /112\. When we reconfigure back to a /64 the phone simply connects and we wont use Googles own ipv6 test site as it has no AAAA records as mentioned in a previous article. This behaviour leaves no room for flexible IPv6 subnet sizing or central IP address control. More updates to follow once the `DHCPv6-Client-Android` project is built and tested. --- ### 🤯 The Absurdity of the /64 Mandate One /64 = 18.4 quintillion addresses To visualize: - There are **7.8 billion humans** on Earth - A single /64 could assign **2.6 million addresses to each human being** Now scale up: - A /48 = 65,536 /64s - That's **1.2e24 addresses**, enough for more IPs than atoms in a grain of sand So when Android demands a /64 for SLAAC to work, it’s demanding a network that could house **more devices than all the transistors ever manufactured**, for a single phone. And we’re forced to waste it. --- ### 🤦‍♂️ Android, Google, and the Refusal of Progress Android (by Google) refuses to implement DHCPv6. Not a bug — a **policy**. Despite countless requests, Google has maintained the position that SLAAC is sufficient. But it is not. SLAAC has no: - Lease management - Address reservation - Central control - DNS updates - Logging or auditing - Device traceability by DUID or MAC Every ISP, enterprise, university, and public hotspot that dares use IPv6 has to: - Either **NAT6** everything - Or give a full **/64 per user** - Or bridge all clients into a flat space and firewall per MAC Meanwhile, routers cannot even assign useful addresses to phones. All because Google will not ship a DHCPv6 client. --- ### 📉 Comparing IPv6 to IPv4 Let’s put this into perspective: | Subnet | Hosts | | ------ | ------------------------------------------------- | | /28 | 16 usable | | /26 | 64 usable | | /24 | 254 usable | | /64 | 18,446,744,073,709,551,616 usable (theoretically) | This is not just over-provisioning — it’s lunacy. If IPv4 were like this, every user would get a Class A block. Imagine assigning `10.0.0.0/8` to every single iPhone connecting to a Starbucks Wi-Fi. That’s what we’re doing in IPv6. And the kicker? You can't give them less — **Android will reject it**. --- ### 🧮 IPv6 by the Numbers - IPv6 space: 2^128 = 340 undecillion addresses - Global unicast (2000::/3): 2^125 addresses - /64s available: 2^61 = 2.3e18 If every human got a /48: - 2^45 = 35,184,372,088,832 /48s - That’s over 4,000 /48s per person on Earth If every home device got a /64: - We’d still be at less than 1% of address space usage So… it won’t run out. But that’s not the point. --- ### 🧨 The Point is Design We are not running out of IPv6 — we are running out of **good design**. IPv6 could be elegant. But not if devices **refuse** to support basic tools like DHCPv6. What good is vast space if: - You can’t subnet it? - You can’t manage it? - You’re forced to burn 18 quintillion addresses just to assign 1 IP? This is not sustainable. This is not good stewardship. This is not sane engineering. --- ### ✅ Call to Action - 🧱 Router developers: continue to support DHCPv6 + prefix delegation - 🧪 Hotspot builders: consider dynamic /64 allocation per client with firewalling - 📣 Users: pressure Google to **enable DHCPv6** Even a toggle in Developer Mode would be enough. **If we don’t fix this now, IPv6 will remain the broken promise of modern networking.** > RFCs are "Requests for Comments", not commandments. This is that comment. Let it be heard. --- We welcome improvements, references, or proofs of working setups using DHCPv6 on Android. Until then, the /64 wasteland continues.