New patches allow building Linux IPv6-only

Original Article ↗ Hacker News Discussion ↗

Linux kernel patches that would allow building IPv6‑only systems—originally floated partly as an April Fools’ joke—have reignited long‑running arguments over the future of IPv4 versus IPv6. Commenters weigh potential benefits such as simpler end‑to‑end connectivity, relief from carrier‑grade NAT, and cleaner protocol design against concerns about privacy, address stability, legacy hardware, and the large ecosystem of software and services that still assume IPv4. Many see dual‑stack support as necessary for the foreseeable future, with some arguing only government intervention or major cloud players fully backing IPv6 will shift the stalemate in deployment.

Scope of the Patch / April Fools Context

  • Patchset allows Linux to be built IPv6-only, or with either protocol alone; some see this as a useful cleanup of config options.
  • It originated as an April Fools joke, but parts (like cleaner separation of IPv4/IPv6 options) are proposed seriously.
  • Concerns arise that language like “legacy IP” signals hostility to IPv4, though the patch doesn’t remove IPv4 support.

IPv6 Adoption, Policy, and Incentives

  • Some argue IPv6 won’t reach full adoption without government intervention; current global usage appears to be plateauing.
  • Others note big tech and CDNs already benefit from IPv6 (less congestion, redundant paths), while many “eyeball” ISPs lag.
  • ISPs are criticized for dragging their feet despite owning IPv6 space; CGNAT cost and complexity are seen as a driver toward IPv6.

NAT vs Public Addressing, Security, and Privacy

  • Strong disagreement over NAT: some call it a “horrible hack” that breaks end-to-end networking and fuels centralization; others like it as a simple safety net and barrier to per-device billing.
  • Multiple posters stress NAT is not a true security mechanism, though it can reduce exposed surface; real protection should come from firewalls.
  • Privacy debates center on:
    • Fear of ISPs easily counting devices or tracking them via stable IPv6 addresses.
    • Counterpoints that privacy extensions, temporary addresses, and huge address space make device counting unreliable.
    • Acknowledgment of IPv6 “footguns” (e.g., MAC leakage) if privacy features aren’t enabled.

Practical Barriers: Services, Tooling, and IPv6-Only Environments

  • Running IPv6-only systems is described as painful:
    • Many services lack AAAA records or IPv6 origins (e.g., GitHub, some AWS services, certain CDNs and load balancers).
    • Common tooling (Docker, some gateway proxies, subscription tools) often assumes IPv4 and breaks on IPv6-only hosts.
  • Some want true IPv6-only CI environments where IPv4 socket creation fails, to expose and fix such assumptions.

Usability, Home Networking, and DNS

  • Users worry about:
    • Multiple addresses per interface.
    • Publicly addressable IoT/consumer devices if firewalls are misconfigured.
    • Rotating prefixes vs static ones for privacy and home servers.
  • Others argue:
    • Proper default firewalls plus local VLANs/segmentation solve exposure concerns.
    • DNS/mDNS/zeroconf should make addresses rarely typed by hand; resistance to IPv6 literals is seen as a solved problem in principle, though mDNS reliability is disputed.

Philosophy, Freedom, and Backward Compatibility

  • Some see calls to penalize or deprecate IPv4 as coercive, especially for legacy equipment and stable IPv4-based networks.
  • Others explicitly want IPv4 to become painful (“legacy IP”) so that v4-only users experience the same friction as v6-only users, hoping to force progress.
  • There is broad agreement that IPv4 and IPv6 coexist today; disagreement is over whether coexistence should remain indefinite or be intentionally phased out.