The Road Not Taken: A World Where IPv4 Evolved

Original Article ↗ Hacker News Discussion ↗

Imagining an alternate “IPv4x” that simply extends 32‑bit IPv4 addresses rather than replacing them with IPv6 raises questions about how the Internet could have evolved with better backward compatibility. Commenters weigh whether such an approach would really have eased deployment compared to today’s dual‑stack IPv4/IPv6 world, given the need to upgrade routers, OSes, DNS, and socket APIs in any case, and the entrenched role of NAT. Many ultimately conclude that IPv6’s design trade‑offs and slow, messy rollout are typical of large infrastructure transitions, and that the real bottlenecks are human, economic, and operational rather than purely technical.

IPv4x alternate-history idea

  • IPv4x keeps IPv4 headers and 32‑bit routing, but tucks extra 96 bits of address into the payload, flagged in the header.
  • Legacy routers forward on the 32‑bit part; IPv4x‑aware gear uses the full 128 bits.
  • Proponents in the thread like the idea that:
    • Adoption could be incremental at the edges.
    • There’s only “one network” and one firewall/ACL view, not two parallel stacks.
    • Existing IPv4 space and topology remain first‑class.

Critiques: “Not really better than IPv6”

  • Many argue IPv4x needs the same fundamental changes as IPv6:
    • New code in routers, OS stacks, and middleboxes to understand longer addresses.
    • New DNS record types and updated apps to query and store them.
    • Larger socket address structures and API changes.
  • Once you support both 32‑bit and extended addresses, you are effectively dual‑stack again.
  • Flat 128‑bit space and routing aggregation problems remain; IPv4x doesn’t fix scaling, just shifts it.

NAT, compatibility, and address space

  • Some say the “road actually taken” was NAT: IP+port ≈ 48 bits, multi‑layer NAT ≈ “IPv4x in practice,” requiring no protocol change.
  • Others note NAT is stateful, constrains ports, complicates hole‑punching and non‑TCP/UDP protocols, and doesn’t behave like true routing.
  • IPv4x would still need NAT/translation to reach IPv4‑only endpoints, much like NAT64/CLAT for IPv6.

IPv6 adoption and operational experience

  • Several comments state IPv6 is already significantly deployed: large fractions of major site traffic, v6‑only mobile cores with 464xlat, v6‑only IoT stacks.
  • Others report frequent real‑world breakage (timeouts, bad defaults, VPN or DNS quirks) and prefer disabling IPv6.
  • Debate whether slow uptake is mostly:
    • Human/admin reluctance and lack of perceived payoff, or
    • Genuine complexity and fragile transition tooling.

Fairness and governance

  • A major criticism of IPv4x: all new 96‑bit subspace would attach to existing IPv4 owners, cementing early‑Internet incumbents and disadvantaging latecomers.
  • IPv6 is seen by some as more equitable, because the expanded space was reallocated rather than inherited.

Alternative mechanisms and lessons

  • IPv4x is repeatedly compared to existing IPv6 mechanisms: 6to4, IPv4‑mapped IPv6, NAT64/DNS64, 464xlat, 6rd.
  • Some argue better, standardized “one‑stack with transparent translation” (v6‑only + robust 46/64 translation) in OSes and CPE early on would have accelerated IPv6 far more than an IPv4‑compatible redesign.