No NAT November: My month without IPv4

Original Article ↗ Hacker News Discussion ↗

IPv6’s promise of abundant addresses, simpler routing, and end‑to‑end connectivity is running up against weak business incentives, uneven ISP support, and entrenched IPv4 practices. Commenters weigh real-world benefits like escaping carrier-grade NAT, lower latency on some networks, and easier internal addressing against obstacles such as legacy hardware, major services that remain IPv4-only (e.g. Steam, GitHub/Discord backends), and awkward transition tools like tunnels and NAT64/CLAT. Much of the debate centers on misconceptions about NAT as a security feature, how stateful firewalls fit into IPv6-only setups, and whether dual stack or IPv6-only cores are the most realistic migration path in the near term.

Deployment incentives and business case

  • Many see little immediate business pressure to adopt IPv6; IPv4 scarcity is handled via markets and CGNAT.
  • Counterpoint: NAT hardware and carrier-grade NAT don’t scale well; large ISPs and mobile operators already see cost and complexity advantages from IPv6-only cores with limited IPv4 at the edges (e.g., NAT64/464XLAT, DS-Lite, MAP, lw4o6).
  • Some argue IPv6 is already “ready” (large corporate and mobile deployments, significant user share), others liken its pace to nuclear fusion and self‑driving cars.

Practical benefits and drawbacks of IPv6

  • Benefits cited: huge address space, easier prefix delegation, end-to-end connectivity, avoidance of CGNAT issues, simpler large networks, fewer DHCP hassles, and sometimes lower latency.
  • IPv4 scarcity is a major problem for smaller/new networks; one example describes spending large sums to support IPv4-only consumer devices (Roku, satellite tuners, cameras, POS).
  • Home users in wealthy markets with dedicated IPv4 addresses often don’t feel pain yet, so the benefit is less visible.

NAT, firewalls, and security misconceptions

  • Strong theme: NAT is not security; stateful firewalls provide the actual protection. NAT’s main role is address translation.
  • Several posts detail NAT behaviors (endpoint-independent mapping/filtering, cone styles) and how hole punching and protocols like STUN/TURN/ICE work around NAT.
  • Others argue that, regardless of theory, NAT’s default “no unsolicited inbound” behavior dramatically reduced successful attacks on home networks in practice.
  • With IPv6, equivalent protection comes from stateful firewalls plus optional PCP; NAT-related complexity can be avoided.

Transition mechanisms and tooling

  • Discussion of NAT64/DNS64, 464XLAT, DS-Lite, MAP-T/E, lw4o6, and whether to rely on CLAT vs DNS64.
  • Linux NAT64 options (tayga, jool, eBPF implementations) exist but are seen as rough: user-space overhead, DKMS kernels, and nontrivial configuration.
  • OpenBSD/pf is praised for first-class NAT64 support.

Operational hurdles: ISPs, hardware, VPNs

  • Many ISPs still lack IPv6 or have broken/unstable implementations; some even crash when IPv6 is enabled.
  • Consumer and “prosumer” routers (Ubiquiti, MikroTik, UniFi) often have poor or partial IPv6 support; sometimes only in slow software-forwarding.
  • VPN providers and configs frequently leak IPv6 unless explicitly handled; some users disable IPv6 entirely as a workaround.

Service and ecosystem gaps

  • Major services (Steam, GitHub, parts of Reddit, Discord) are still IPv4-only or partially v6, often due to legacy assumptions, reputation systems, and hardcoded IPv4 logic.
  • IoT, consoles, and “cheap” devices often omit IPv6 to save cost, pushing users toward dual-stack or IPv4-only despite IPv6’s advantages.