Reclaiming IPv4 Class E's 240.0.0.0/4

Original Article ↗ Hacker News Discussion ↗

Pressure on scarce IPv4 address space has revived proposals to reclaim the long-reserved 240.0.0.0/4 “Class E” range, but many engineers argue this would be a fragile stopgap that breaks devices and delays an inevitable move to IPv6. Commenters contrast the theoretical gains from unlocking more IPv4 with the practical realities of dual‑stack complexity, legacy hardware, cloud and ISP inertia, and error‑prone IPv6 deployments that lead some operators to disable it entirely. The prevailing view is that while reclaiming exotic IPv4 blocks may help at the margins, only broad, well-supported IPv6 adoption — potentially nudged by regulation and pricing — can sustainably address address exhaustion and restore end‑to‑end connectivity.

Thread focus

  • Debate centers on whether reclaiming IPv4 Class E (240.0.0.0/4) is worthwhile versus pushing harder on IPv6.
  • Many see 240/4 as a distraction that prolongs IPv4 dependence without solving structural problems.

IPv6 vs reclaiming 240/4

  • Pro-IPv6 view: reclaiming 240/4 breaks devices, firewalls, and software, buys only a few years, and weakens incentives to deploy IPv6.
  • Critics of 240/4 note that to use it on the public Internet you effectively need near‑100% support across OSes, routers, and middleboxes; anything less creates opaque reachability bugs.
  • Some argue 240/4 might be useful as extra private space (e.g., behind NAT, containers) but not as globally routable space.

IPv6 design, complexity, and backward‑compatibility debates

  • Several commenters argue IPv6 could have been a “bigger IPv4” with minimal changes (longer addresses, same model), citing historical proposals (TP/IX, TUBA, Extended IP).
  • Counter-argument: any expanded-address protocol would still break APIs, hardware, and assumptions; you’d still need new structs, DNS record types, and transition mechanisms.
  • IPv6-specific complaints: SLAAC and privacy addresses, multiple addresses per interface, dependence on ICMP, dynamic prefixes from ISPs, DHCPv6 vs SLAAC tensions, Android not supporting stateful DHCPv6.

Operational experiences and deployment barriers

  • Some report IPv6 has “just worked” for a decade (home ISPs, HE tunnels, mobile networks).
  • Others see IPv6 as flaky or absent (certain ISPs, cloud services, major sites like Github), making IPv6-only setups impractical.
  • Admins dislike dual-stack: two firewall configs, two address plans, more debugging surface, while IPv4 must remain anyway.
  • Usability gripe: IPv6 text form is hard to type, recognize, and select; tools and conventions (ifconfig, 8.8.8.8) are IPv4-centric.

NAT, CGNAT, and address scarcity

  • Some want IPv6 to eliminate NAT; others note NAT and CGNAT remain due to legacy IPv4-only services and dynamic prefixes.
  • Mobile carriers often run IPv6-only plus NAT64/DNS64 for IPv4 sites; suggested as a model for ISPs.
  • Address scarcity is now monetized (e.g., cloud IPv4 charges); this may slowly push services toward IPv6, but big holders feel little pressure.

Other reserved ranges (0/8, 127/8)

  • Reusing 127/8 or 0/8 is seen as far riskier than 240/4 due to ubiquitous hardcoded loopback and “this host” assumptions and potential security issues.
  • Some niche use of expanded 127/8 for local aliases exists; shrinking it (e.g., to /16) would be extremely slow and fragile.

Policy / incentives

  • Some advocate mandates (FCC or governments requiring IPv6, even v6-only government sites) to break the stalemate.
  • Others argue against misusing CVEs or hard mandates; emphasize that economics and inertia, not protocol design quality alone, explain slow adoption.