Mission Possible: Disabling IPv4 on Google Enterprise Network#

Jen Linkova - Google

• What: Google's production rollout of "IPv6-mostly" networks (RFC 8925 DHCPv4 Option 108) across its enterprise network: clients that signal Option 108 receive no IPv4 address and run IPv6-only with NAT64, PREF64 signalled in Router Advertisements (RFC 8781/9872), DNS64, and CLAT (464XLAT, RFC 6877) for IPv4-literal and legacy apps. Rollout ran March–December 2023 (pilot → greenfields first → incremental 10%→100% of existing subnets). Results: no blocking issues; Apple/Android/ChromeOS devices went IPv6-only automatically; 75–80% of hosts became IPv6-only; DHCPv4 utilization dropped 3–4× on WiFi segments; 500K+ IPv4 addresses reclaimed (a /19 was downsized to /22). Documented pitfalls: devices with disabled/link-local-only IPv6, extension-header filtering breaking ESP (VPN, WiFi calling), APs blocking multiple IPv6 addresses (and multiple EVPN Type-2 routes), tethering/hosts-as-routers breaking, and Happy Eyeballs masking IPv6 bugs ("users do not report problems; network bugs remain unfixed").
• Why: IPv4 reclamation is a live operational problem everywhere; this is the most complete public deployment data on the IPv6-mostly pattern, and it's directly relevant to IPAM and enterprise addressing strategy.
• How: Standard-track mechanisms only — Option 108 in DHCPDISCOVER/REQUEST parameter list, NAT64 at site edge, RA-signalled PREF64, CLAT on the client; the dedicated IPv6-only SSID/VLAN approach is explicitly rejected (user confusion, higher IPv4 consumption, low issue visibility).
• Where applicable: Enterprise/campus wired + wireless with central DHCPv4 and SLAAC. The specific numbers are Google-scale, but the technique is deployable now wherever clients are Apple/Android/ChromeOS (they send Option 108 by default); Linux requires manual opt-in; Windows is the open gap. Prerequisite: IPv6 must already genuinely work.