No NAT November: My month without IPv4

Original Article ↗ Hacker News Discussion ↗

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.