IPv6 Is Hard

Original Article ↗ Hacker News Discussion ↗

What “hard” Means in the Thread

  • Many argue IPv6 isn’t intrinsically hard, just unfamiliar; others say it is harder than it needs to be.
  • Several note that, feature‑for‑feature, IPv4+NAT is conceptually messier, but is “the devil we know.”
  • A recurring theme: dual‑stack operation (v4+v6) is the truly hard part, not IPv6 alone.

Design Complexity: SLAAC, DHCPv6, Prefixes

  • Big friction points: two competing address mechanisms (SLAAC vs DHCPv6), Android’s refusal to use DHCPv6, and fragile interactions with prefix delegation.
  • /64 as the minimum subnet and ISPs that only hand out a single /64 break common needs like VLANs and guest networks.
  • Some say IPv6 “tried to do too much” and should have been “IPv4 with 128‑bit addresses”; others say the extra machinery solves real problems (ND, SEND, mobile IP, etc.).
  • Use of ULAs plus NAT66 or prefix translation is seen by several as the only sane way to get stable internal addressing with dynamic ISP prefixes.

NAT, Firewalls, and End‑to‑End

  • Long subthread debating whether NAT is a firewall. Consensus among networking‑savvy participants: NAT by itself is not a firewall; the accompanying stateful firewall is.
  • However, many defend NAT as de‑facto “security by default” for home users and inherently safer misconfiguration surface than IPv6 without strict firewalls.
  • Others counter that IPv6 can do the same with deny‑by‑default edge firewalls plus PCP/UPnP‑style hole punching, and NAT mainly creates complexity (especially CGNAT).

End‑to‑End Connectivity vs Today’s Threat Model

  • Several argue the original IPv6 dream of every device being directly reachable is incompatible with today’s “dark forest” internet; routers must drop unsolicited inbound traffic.
  • That means most real‑world P2P still needs NAT/firewall traversal tricks, centralized rendezvous, or port‑mapping protocols, even with IPv6.
  • Others reply that IPv6 still simplifies P2P (no port remapping, no double NAT) and eliminates hard CGNAT barriers.

Operational and UX Pain

  • Complaints: hard‑to‑type hex addresses, hard static config on OSes, RA/DHCP interactions, multi‑WAN/multihoming complexity, and flaky behavior when prefixes change.
  • Some report repeatedly fixing odd bugs (slow registries, timeouts) by disabling IPv6.
  • Home/SOHO scenarios with dynamic prefixes, cheap ISP routers, and only a /64 are repeatedly cited as “where IPv6 actually feels hard.”

ISPs, CGNAT, and Incentives

  • Consumer ISPs often delay serious v6 deployment; some only offer v6 on high‑end plans or with poor PD.
  • Cell carriers and some large networks do rely heavily on IPv6 (often IPv6‑only with 464XLAT/NAT64), but this is largely invisible to users.
  • CGNAT is widespread and painful for hosting; IPv6 is viewed both as the escape hatch and as something many ISPs still half‑implement.

Email, Scanning, and Reputation

  • Mixed experiences: some see IPv6 as “invisible” or distrusted by mail filters; others report most legit mail and almost all spam control working fine over IPv6.
  • IPv6 scanning is harder but not impossible; attackers can use subnets, vendor patterns, DNS, and compromised hosts to discover targets.

Adoption Trajectory and Meta‑Views

  • Some claim IPv6 is “second‑system syndrome” that lost the war; others say it’s the only viable successor and starting over would be worse.
  • There’s frustration with “religious” pro‑ and anti‑IPv6 camps; several participants want pragmatic: keep NAT where it helps, push v6 to kill CGNAT, and accept dual‑stack for a long time.