Your network is already running IPv6 — you just don’t know it yet

On June 6, 2012, the world’s largest internet companies launched World IPv6 Launch, permanently enabling IPv6 on their services. On July 26, 2026, Google measured 49.62% native IPv6 traffic across all its users — the symbolic 50% mark was crossed mid-year. Yet ask a network administrator today whether they’ve deployed IPv6 in their enterprise, and odds are they’ll tell you it’s “planned for next year.” The paradox is staggering: half of global traffic runs over IPv6, but only a tiny fraction of deployments are intentional.

Your network is almost certainly already dual-stack — your Windows 11 machine, your MacBook, your iPhone, and your network printer have been negotiating IPv6 addresses for years without you lifting a finger. The problem isn’t the absence of IPv6. The problem is that you don’t control it.

Half the internet migrated itself

Google’s numbers are unambiguous. As of July 26, 2026, native IPv6 adoption reached 49.62% — 6to4 and Teredo, the transition mechanisms from the 2000s, sit at exactly zero. Every byte of IPv6 traffic measured is native, delivered by ISPs that turned the protocol on across their access infrastructure.

APNIC data (30-day rolling average, June 28 — July 27, 2026, 937 million samples) tells a two-speed story. India leads major countries at 79.20% IPv6-capable clients; France follows at 83.53%. Germany is at 72.08%, the United States at 60.40%. Western Europe as a whole clocks 70.10%. At the other end, Africa is stuck at 6.13% and Eastern Europe at 12.14%.

What stands out is that IPv6 adoption is almost entirely driven by consumer ISPs and mobile networks. Reliance Jio in India, Free and Orange in France, Deutsche Telekom in Germany — these players moved their customers to IPv6 without anyone noticing, because CGNAT (Carrier-Grade NAT) running out of public IPv4 addresses becomes unsustainable beyond a few tens of millions of mobile subscribers. India’s mobile network is over 90% IPv6. French ISP boxes have been handing out /56 or /48 prefixes to every subscriber for nearly a decade.

Enterprise networks missed the train entirely.

Why nobody deploys IPv6 at work

Enterprise IPv6 deployment hits four obstacles that look harmless in isolation — and paralyze everything when combined.

The firewall blind spot. Virtually every enterprise firewall is configured with explicit IPv4 rules and… no IPv6 rules at all. Result: a dual-stack Windows machine that gets an IPv6 address via SLAAC silently bypasses the firewall for all outbound traffic. The firewall never even sees the packets, because the administrator never wrote a rule for ::/0. This is the nightmare scenario the SANS Institute has been documenting since 2021: enterprise networks that believe they’re protected because they filter 0.0.0.0/0, while leaving ::/0 wide open by default.

SLAAC vs. DHCPv6 — the religious war that won’t end. IPv6 offers two mutually incompatible address assignment mechanisms. SLAAC (Stateless Address Autoconfiguration, RFC 4862) lets the router advertise a prefix and the client generate its own address — no state, no central logging, no control. DHCPv6 (RFC 8415) mirrors the IPv4 model with a server assigning addresses and tracking leases. The problem: Android does not support DHCPv6 — a historic decision by Lorenzo Colitti at Google in 2012, never revisited. iOS supports it partially. Windows supports it. Result: a uniform enterprise network must choose between covering all clients (SLAAC, goodbye audit trail) or keeping control (DHCPv6, goodbye Android users).

Legacy applications that crash. An IPv6 address doesn’t fit in a varchar(15) database column. A socket hardcoded with AF_INET will never negotiate AF_INET6. A validation regex expecting \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} rejects 2001:db8::1. These bugs are trivial to fix one at a time — but in a two-decade-old IT estate with hundreds of internal applications, the global remediation cost freezes entire IT departments.

The /48 prefix as implicit delegation of power. An IPv6 /48 prefix contains 65,536 /64 subnets. A /64 contains 18 billion billion addresses. The RIPE NCC recommendation is to allocate a /48 to every site — which gives every network project lead near-unlimited addressing power. In an organization where a single IPv4 VLAN requires a change request approved by three committees, this abundance is culturally destabilizing. Many enterprises prefer not deploying at all over deploying without control.

Dual-stack: the Trojan horse already inside your walls

Dual-stack — IPv4 and IPv6 active simultaneously on the same interface — is the default operating mode of every modern operating system. Windows has enabled it since Vista (2007). macOS and iOS since 2010. Linux since kernel 2.6. Android since 2012. Your HP printer, your surveillance camera, and your Synology NAS all enable it too.

When a dual-stack client receives a Router Advertisement (RA) with an IPv6 prefix, it automatically configures an address and uses it in preference to IPv4. This is the behavior defined by RFC 6724 (Happy Eyeballs v2): if a DNS lookup returns both an A record (IPv4) and an AAAA record (IPv6), the browser tries IPv6 first, falling back to IPv4 only on failure after 300 ms.

Here’s what actually happens on a typical enterprise network in 2026:

# On a Windows 11 machine connected to the corporate network
ipconfig
# Ethernet adapter Ethernet0:
#    IPv4 Address. . . . . . . . . . . : 10.23.45.67
#    IPv6 Address . . . . . . . . . . . : 2001:db8:cafe:1:a1b2:c3d4:e5f6:7890

That IPv6 address was assigned automatically — without the IT team requesting it, without firewall rules covering it, and without SIEM logs monitoring it. The machine is sending IPv6 traffic to the internet — and to other LAN hosts — over a network stack that nobody administers.

NPTv6 (Network Prefix Translation, RFC 6296) adds another layer of complexity. Where IPv4 uses NAT to hide private addresses behind a public one (breaking end-to-end connectivity in the process), IPv6 doesn’t need NAT — every device gets a public address. But enterprises that want to hide their internal topology use NPTv6 to translate the source prefix on egress. The catch: NPTv6 breaks transport-layer checksums that include the source address, making network troubleshooting far harder than in IPv4.

IPv6-only: the target everyone is dodging

If dual-stack is a Trojan horse, IPv6-only is the only truly manageable state — and almost nobody is there.

An IPv6-only network has no IPv4 stack. No NAT. No RFC 1918. No address conflicts. No dual routing table. Every device has a unique public address, every flow is identifiable end to end, and the topology is radically simple. This is the end state the IETF has been promising since RFC 2460 (1998).

The problem is connectivity to residual IPv4. Mechanisms exist: NAT64 + DNS64 (RFC 6146/6147) let an IPv6-only client reach an IPv4-only server — the DNS resolver synthesizes an AAAA record from the A record by embedding it in a dedicated /96 prefix, and the NAT64 gateway translates the packets. 464XLAT (RFC 6877) does the same on the client side for applications that open raw IPv4 sockets.

These mechanisms work — T-Mobile US and Reliance Jio run IPv6-only with 464XLAT for hundreds of millions of subscribers. But deploying them in an enterprise requires a complete overhaul of the address plan, firewall rules, logging, monitoring, and team training. It’s an 18- to 36-month project for a mid-size organization — and the ROI isn’t immediate.

What to do right now

The risk isn’t that your network doesn’t support IPv6. The risk is that it does support it without your knowledge — and an attacker discovers it before you do.

First action: audit your involuntary IPv6 exposure. Scan your public IP ranges and look for responses on ports 80/443 over IPv6. Run curl -6 https://your-domain.com against every exposed service. If it responds, you have an undocumented attack surface.

# Check a domain's IPv6 exposure
curl -6 -sI https://ettayeb.fr | head -5
# If you get an HTTP response, the service is exposed over IPv6

Second action: verify your IPv6 firewall rules. If you manage an enterprise firewall, list the rules involving ::/0. If there are none, your network is wide open over IPv6. Explicitly block what you don’t want to allow — an allowlist model is the only defensible approach.

# On a Linux firewall with nftables: list IPv6 rules
nft list ruleset ip6
# If the output is empty, your firewall is not filtering IPv6

Third action: pick between SLAAC and DHCPv6. If you have a mixed fleet (Android + Windows + iOS), the answer is SLAAC — it’s the only common denominator. Compensate for the lost audit trail with switch-level logging (MAC → IPv6 address via Neighbor Discovery messages) and a SIEM capable of correlating temporary IPv6 addresses.

Fourth action: plan for IPv6-only. Even if you’re not doing it today, design your IPv6 addressing plan as if it were meant to be the only active protocol. Allocate a /48 per site, a /64 per VLAN, and document the mapping. Deploy NAT64+DNS64 in a test DMZ and validate that your critical applications work.

Verdict

If your organization has fewer than 500 endpoints and no in-house IPv6 expertise, your priority is simple: disable IPv6 cleanly on every host and every firewall. A properly filtered IPv4-only network is safer than an unmanaged dual-stack network. Use a GPO for Windows, an MDM profile for macOS/iOS, and ipv6.disable=1 at boot for Linux. It’s not glamorous, but it’s honest.

Beyond 500 endpoints, you don’t have a choice: dual-stack is already active on part of your fleet, whether you want it or not. Your IPv6 migration started without you. The only question is whether you’ll catch up before a security incident forces your hand.

References

1. Google IPv6 Statistics — https://www.google.com/intl/en/ipv6/statistics.html, accessed July 26, 2026
2. APNIC IPv6 Measurement Maps — https://stats.labs.apnic.net/ipv6 (30-day rolling average to July 27, 2026)
3. RFC 4862 — IPv6 Stateless Address Autoconfiguration, IETF, September 2007
4. RFC 8415 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6), IETF, November 2018
5. RFC 6296 — IPv6-to-IPv6 Network Prefix Translation (NPTv6), IETF, June 2011
6. RFC 6146 — Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, IETF, April 2011
7. RFC 6724 — Default Address Selection for IPv6 (Happy Eyeballs v2), IETF, September 2012
8. SANS Institute — “IPv6 Security: The Hidden Threat,” ISC Paper, 2021
9. RIPE NCC — “Best Current Operational Practice for IPv6 Address Assignment,” ripe-690, 2019
10. World IPv6 Launch — https://www.worldipv6launch.org/ (archived, redirects to Internet Society Pulse)