Sign in Subscribe
ipv6

The Lunacy of IPv6 /64 and Google's Refusal to Support DHCPv6

AKADATA

• 6 min read
The Lunacy of IPv6 /64 and Google's Refusal to Support DHCPv6

📌 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

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

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.

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.