The IPv6 Transition

Original Article ↗ Hacker News Discussion ↗

IPv6 was meant to replace IPv4 and restore a fully addressable, end‑to‑end internet, but commenters describe a stalled, messy transition where workarounds like NAT and carrier‑grade NAT remain cheaper and “good enough” for most users and businesses. They cite technical rough edges (router firmware, DHCPv6, ULA behavior, broken corporate stacks), economic incentives (IPv4 address markets, cloud pricing), and social factors (lack of user demand, operational risk in large enterprises) as key barriers, even as mobile networks and some countries push aggressively toward IPv6‑only. Several argue that only strong pressure from major platforms or governments will complete the shift, while others question whether the modern, heavily centralized, DNS/SNI‑driven internet really needs IPv6 at all beyond niche or large‑scale operator use.

Government, mandates, and big platforms

  • Debate over whether governments should mandate IPv6, incentivize it (grants, tax breaks, gov-only IPv6 requirements), or stay out entirely.
  • Some argue mandates are “authoritarian”; others compare them to safety/environment rules (seatbelts, CFC bans).
  • Several note existing mandates: US federal agencies and DoD, China, India, Vietnam, Department of Commerce policies.
  • Many think the real “switch” will be when Chrome/Android/iOS or major SaaS vendors effectively require IPv6 (similar to HTTPS).

Economics and incentives

  • Common view: IPv4 + NAT/CGNAT is still cheaper than full IPv6 transition for most actors.
  • IPv4 scarcity hurts mainly new/poorer regions and small operators; rich incumbents just pay.
  • Hosting providers increasingly charge for IPv4 and give IPv6 “for free”, but demand for IPv6-only remains weak.
  • Some predict IPv4 will become a paid add‑on or premium service as IPv6 becomes default.

Current deployment picture

  • Many residential ISPs and mobile carriers run dual stack or IPv6-only cores with NAT64; corporate and enterprise networks are seen as major holdouts.
  • Regional variance is large: Germany and parts of the US are quite advanced; UK and Denmark are mixed; some fiber ISPs and hotel/corporate Wi-Fi are IPv4‑only.
  • CGNAT is widespread (Starlink, many mobile/cheap ISPs), causing CAPTCHAs, bans, and broken inbound connectivity.

Technical benefits and limitations

  • Advocates: simpler addressing and subnetting, end-to-end reachability, easier P2P, no address collisions across VPNs, reduced need for NAT trickery.
  • Skeptics: for “just browsing” users, IPv6 adds little; dual stack doubles complexity; many legacy and embedded devices remain IPv4-only.
  • Some see IPv4 exhaustion as effectively “solved” by NAT and cloud centralization; others argue it’s a hidden tax (CGNAT costs, complexity, lock‑in).

Operational pain points

  • Reports of flaky or missing IPv6 in consumer routers, hotels, and enterprise gear; weird MTU issues; router crashes; confusing RA/SLAAC/DHCPv6 behavior.
  • Tooling gaps: inconsistent DHCPv6/hostname handling, weak mDNS/ULA stories, incomplete support in cloud APIs and PaaS firewalls, lack of GitHub/large SaaS IPv6.
  • Dual-stack bugs often lead admins and users to disable IPv6 entirely, perpetuating the chicken‑and‑egg problem.

Security, privacy, and architecture

  • Ongoing confusion about NAT vs firewalls: some treat NAT as security, others stress that proper firewalls work the same with IPv6.
  • IPv6’s global addressing raises privacy concerns; mitigations (temporary addresses, frequent prefix changes) in turn break “stable address” use cases.
  • Several note that the Internet has shifted from peer‑to‑peer ideals to a producer/consumer model mediated by large cloud providers, reducing visible pressure for IPv6.