IPv6 is the only way forward
Debate over IPv6’s slow adoption highlights a split between those who see it as essential for overcoming IPv4 address exhaustion and enabling true end-to-end connectivity, and others who view IPv4 plus NAT as “good enough” and IPv6 as overcomplicated or poorly designed. Commenters argue about usability (memorability of addresses, SLAAC vs DHCP), security and privacy implications of globally routable addresses, and the real-world pain of carrier-grade NAT for users in regions with scarce IPv4 space. Many conclude that while IPv6’s technical model is sound and already widely deployed in mobile and some ISP networks, incentives, legacy infrastructure, and operator UX remain the main barriers to broader, practical adoption.
IPv4 vs IPv6: necessity and philosophy
- One camp argues IPv6 is the only realistic path beyond the hard 32‑bit IPv4 limit, especially for late‑arriving regions.
- Others say IPv4 “crisis” has been talked about for decades but NAT and CGNAT keep working; they expect IPv4 to remain dominant.
- Some see IPv6’s “every host has a public address” model as fundamentally flawed and insecure; others note this was also IPv4’s original design and that firewalls, not NAT, should provide protection.
NAT, CGNAT, and P2P connectivity
- Critics of CGNAT highlight: no true port forwarding, unreliable hole punching, degraded gaming and VoIP, mandatory relays, higher latency/cost, and overloaded carrier NAT boxes.
- Skeptics downplay this, claiming most real‑world apps already rely on relays/tunnels and users mainly care about outbound web and streaming.
- Debate centers on lost potential for simple P2P and home hosting versus the acceptability of client–server everything.
Backward compatibility and “IPv4 but bigger”
- Several proposals suggest a hypothetical “IPv4+” or IPv8 with 64‑bit addresses, more compatible with IPv4 or easier to read.
- Network‑savvy participants argue these are effectively new protocols with the same transition costs as IPv6: new packet formats, DNS records, APIs, and upgrades to all routers, OSes, and apps.
- Comparisons to ASCII→UTF‑8 are rejected because IP headers are fixed‑size, not variable‑length like text encodings.
Usability, configuration, and tooling
- Common complaints: long, non‑memorable addresses; SLAAC vs DHCPv6 confusion; dual‑stack doubling troubleshooting; inconsistent OS and router UX.
- Others say v6 complexity is comparable to “IPv4 + ARP + DHCP”; issues are mostly poor CPE/router implementations and legacy scars.
- Many emphasize DNS/mDNS and tools like Tailscale’s “magic DNS” as the real UX layer; memorizing IPs (v4 or v6) is seen as obsolete.
- Some report concrete IPv6 pain: changing ISP prefixes breaking pfSense configs, Android’s SLAAC‑only behavior, and fingerprinting via stable global addresses (partly mitigated by privacy extensions).
Deployment realities and ecosystem gaps
- Mobile networks and some residential ISPs heavily use IPv6 (often with NAT64/464XLAT); for many users “ping6 just works.”
- Major gaps: ISPs that still offer no IPv6, enterprise networks that remain IPv4‑only, and large cloud/SaaS providers (e.g., GitHub, some Azure services) lacking full IPv6 support.
- This fragmented support forces dual‑stack setups and deters operators who don’t see clear short‑term benefits.
Equity and address scarcity
- Several comments frame IPv6 as an equity issue: early US/EU actors hold large IPv4 blocks, while countries like India and China must rely on CGNAT.
- Proposals to “just reclaim” unused or government/enterprise IPv4 are argued to buy at most a short reprieve given growth and fundamental 2³² limits.