HN Debrief

Google Hits 50% IPv6

  • Infrastructure
  • Networking
  • Cloud
  • Security

The post is about a milestone that sounds cleaner than it is. Google now sees more than half of user access arriving over IPv6, but APNIC’s own measurements put worldwide IPv6 capability closer to 42%. The gap comes from how they measure. Google sees traffic reaching Google properties, which overweights places and services where IPv6 is already strong. APNIC measures broader client capability across the public internet. That led people to a sharper conclusion than the headline. IPv6 has clearly won enough share to matter, especially on mobile networks and in newer builds, but it is still not a completed transition.

Plan for a long world where IPv4 and IPv6 coexist. If you run products or infrastructure, enable and test IPv6 now, but do not assume you can drop IPv4 or that client reachability, routing quality, and operational tooling are already solved everywhere.

Discussion mood

Cautiously positive about the milestone, but frustrated that the transition is still unfinished after decades. The mood mixed recognition that IPv6 is already carrying a lot of real traffic with annoyance at ISP holdouts, corporate inertia, flaky implementations, and major services that still force IPv4 to stay forever.

Key insights

  1. 01

    GitHub remains a glaring IPv4 holdout

    GitHub came up as the simplest proof that 50% IPv6 usage does not mean the service side is ready. Even users on near-pure IPv6 setups still need NAT64 or other translation to reach it. That turns a milestone story about client adoption into a reminder that a few high-profile laggards can keep the whole ecosystem dual stack for years.

    Audit your own dependencies, not just your edge. If core developer tools or third-party APIs in your stack are still IPv4-only, your path to IPv6-only operation is blocked no matter how good your own network is.

      Attribution:
    • dapperdrake #1
    • axus #1
    • boredatoms #1
  2. 02

    Weekend spikes point to enterprise lag

    The repeated weekend peaks in Google’s chart are a useful signal, not chart noise. They imply IPv6 is stronger on home and mobile networks than on business and office networks, so the share rises when people leave corporate infrastructure behind. That makes the remaining gap look less like a consumer problem and more like a slow enterprise migration problem.

    If you run corporate networking, assume your estate is now the lagging segment. Measure IPv6 usage from employee devices and egress points, because public internet adoption stats can hide how far behind your internal environment is.

      Attribution:
    • throw0101a #1
    • lemagedurage #1
    • Scroll_Swe #1
    • AndrewDucker #1
  3. 03

    New networks adopt IPv6 because economics force it

    The strongest economic explanation was that IPv6 grows fastest where operators are building fresh networks or scaling fast in address-poor markets. Mobile providers and newer ISPs can avoid the cost and operational mess of acquiring scarce IPv4 space, while older incumbents can coast on legacy allocations. That also explains why APNIC and Google see very different global pictures depending on who their users are.

    Treat IPv6 as a cost and scale advantage for new infrastructure, not just a standards checkbox. If you are launching networks, products, or global services in growth markets, designing around IPv4 assumptions will age badly.

      Attribution:
    • lambdaone #1
    • tulio_ribeiro #1
    • anunay03 #1
  4. 04

    IPv6 is already essential inside large networks

    Several comments cut through the argument over whether IPv6 has 'replaced' IPv4 on the public internet. Big mobile operators and broadband providers use IPv6 because their internal and access networks hit scaling limits long before every destination on the public internet did. T-Mobile US and Comcast were cited as cases where IPv6 solved real address exhaustion and management problems even though translation to IPv4 still exists at the edge.

    Do not judge IPv6 only by whether you can turn off IPv4 at the application layer. For operators and large platforms, IPv6 can already be the cheaper and saner underlay even while user-facing compatibility remains dual stack.

      Attribution:
    • throw0101a #1 #2 #3
    • kay_o #1
  5. 05

    Operational pain now comes from uneven quality

    The most credible complaints were not that IPv6 is conceptually broken. They were that too many real deployments are half-good. People described broken CDN paths, bad IPv6 routing to package repositories, tunnel traffic that gets treated as suspicious, and consumer routers whose firmware tanks performance until replaced with OpenWrt. That explains why some teams still disable IPv6 when troubleshooting even though the protocol itself is mature.

    If you enable IPv6, invest in observability and path testing instead of assuming parity with IPv4. Track failures by address family, monitor routing quality, and test on real consumer hardware because that is where confidence gets lost.

      Attribution:
    • jck86 #1
    • toast0 #1
    • zinekeller #1
    • PacificSpecific #1
    • drewfax #1
  6. 06

    CGNAT pushes the internet toward centralization

    A deeper argument was that the cost of staying on IPv4 is not just technical debt. CGNAT and inbound reachability problems make direct host-to-host use cases harder, which nudges everything toward cloud relays, app-platform backups, and centralized services. People connected that to why home backup, game hosting, and peer-to-peer communication feel more dependent on big platforms than they needed to be.

    If your product depends on direct device connectivity, assume IPv4-era constraints are shaping your architecture and business model. Supporting IPv6 well can lower relay costs and widen the design space for peer-to-peer features, even if it does not remove every firewall hurdle.

      Attribution:
    • dijit #1
    • lotsofpulp #1
    • inigyou #1
  7. 07

    NAT is still being mistaken for security

    The discussion on home networking landed on a practical point. NAT blocks some inbound traffic as a side effect, but that is not the same thing as a firewall policy. The useful comparison is between accidental protection from address translation and an explicit default-deny rule that you can selectively open. That framing matters because a lot of IPv6 resistance still leans on the idea that private IPv4 addresses are themselves a security boundary.

    Review your security guidance and tooling for language that treats NAT as protection. On both home and enterprise networks, the safer model is explicit filtering plus patching, not hoping address translation keeps vulnerable services invisible.

      Attribution:
    • mlyle #1
    • throw0101a #1
    • TheDong #1

Against the grain

  1. 01

    IPv6 may never be more than a supplement

    A blunt minority view was that the transition has already failed on its original terms. After decades, dual stack remains the norm, IPv4-only services still matter, and some organizations actively disable IPv6 because operating two families adds complexity without enough business gain. From that angle, 50% does not mark victory. It marks a permanent coexistence regime.

    Do not build roadmaps that depend on IPv4 disappearing soon. Budget for translation, dual-stack operations, and vendor gaps as durable costs rather than temporary migration noise.

      Attribution:
    • hdgvhicv #1
    • tgma #1
    • heresie-dabord #1
  2. 02

    Stateful firewalls limit the P2P upside

    Some commenters rejected the common pitch that IPv6 automatically restores a more direct internet. Consumer routers usually block unsolicited inbound IPv6 by default, and for many use cases that is the right default. They also argued that exposing home IPs to strangers in gaming or ad hoc file sharing can create harassment and abuse risks, so relays and hosted services are often still the better tradeoff.

    Do not justify IPv6 adoption solely with an abstract end-to-end story. For consumer products, you still need a clear plan for consent, firewall traversal, abuse handling, and when to prefer relays over direct connectivity.

      Attribution:
    • kortilla #1
    • crote #1 #2
  3. 03

    Tunnel brokers are no longer a clean fallback

    Hurricane Electric tunnels were described as increasingly second-class citizenship on the modern web. Users reported more captchas, blocked access to services like YouTube unless logged in, and the usual extra latency if the nearest tunnel endpoint is far away. That undercuts the old answer of 'just tunnel IPv6 until your ISP catches up.'

    If your audience lacks native IPv6, do not assume tunnel brokers are an acceptable substitute. For production use, native support from the ISP or access network is the only answer that avoids reputation and performance penalties.

      Attribution:
    • cge #1
    • toast0 #1
    • sleepydog #1

In plain english

APNIC
Asia Pacific Network Information Centre, a regional internet registry that also publishes internet measurement data.
CDN
Content delivery network, a distributed service that serves web content from locations closer to users.
CGNAT
Carrier-grade network address translation, where an ISP makes many customers share the same public IPv4 address.
CPE
Customer premises equipment, usually the router or modem installed at a home or business.
Dual stack
Running IPv4 and IPv6 at the same time on the same network or device.
IPv4
Internet Protocol version 4, the older addressing system used by most of the internet and limited to about 4.3 billion addresses.
IPv6
Internet Protocol version 6, the newer internet addressing system that uses much larger addresses than IPv4.
ISP
Internet service provider, the company that gives homes, phones, or businesses internet access.
NAT
Network address translation, a method that rewrites network addresses so multiple devices can share one public address.
NAT64
A translation method that lets IPv6-only clients reach IPv4-only services.
WebRTC
Web Real-Time Communication, a browser technology for direct audio, video, and data connections between users.

Reference links

Adoption data and dashboards

ISP rollout examples

Transition and implementation references

  • nat64.xyz
    Listed as a volunteer service making some IPv4-only destinations reachable from IPv6-only networks
  • Tailscale on NAT traversal
    Referenced to explain why CGNAT is harder for peer-to-peer traffic than ordinary NAT or firewalls
  • LocalSend
    Offered as a local-network file sharing option that does not depend on public IPv6 reachability
  • Ubiquiti UniFi IPv6 configuration guide
    Shared to rebut claims that Ubiquiti gear lacks IPv6 support

Case studies and technical reading

Background articles and standards discussion