Tell HN: Hacker News now supports IPv6

Hacker News Discussion ↗

Hacker News has enabled direct IPv6 access, prompting technical commentary on how it’s deployed (including prior use of Cloudflare, lack of TLS 1.3, and DNS/TTL choices) and how to verify connectivity with tools and browser extensions. Participants debate the real-world benefits of IPv6—larger address space, simpler end-to-end networking, and often lower latency—against its perceived complexity, dual‑stack operational burdens, and uneven ISP support. The exchange also surfaces broader concerns about address allocation policy, long-term IPv4 coexistence, and whether IPv6 has truly solved the address exhaustion problem it was designed for.

HN enabling IPv6 & infrastructure

  • HN now serves traffic over IPv6; some users confirmed via browser tools and direct IPv6 access.
  • Site was briefly behind Cloudflare (e.g., during a DDoS) which could also have provided IPv6; now appears to serve traffic directly again.
  • DNS A/AAAA TTL is set to 1s; some speculate this is for load balancing, but there’s no clear evidence of multiple IPs.
  • A few users report connectivity issues after the switch, often tied to misconfigured home routers or legacy 6to4 setups.

TLS and protocol support

  • HN does not support TLS 1.3 yet; past attempts were reportedly rolled back due to breakage behind corporate TLS-intercept proxies.
  • Some argue TLS 1.3 should be re-enabled alongside 1.2, as most MITM boxes now support it.

Browser tools & extension security

  • IPvFoo extension is widely cited for quickly showing IPv4 vs IPv6 usage.
  • Discussion around its “read and change data on all sites” permission leads to worries about extension takeovers, auto-updates, and malicious buyers.
  • Mitigations suggested: code review, sideloading, disabling auto-updates.

IPv6 address space, allocations, and subnetting

  • Debate over whether “undecillions” of addresses can ever be exhausted.
  • Concern about very large allocations (e.g., IPv6 /16 to a single company) and long-term waste; questions about RIR policy and transparency.
  • Strong disagreement over mandatory /64 subnets: some see waste and want smaller subnets; others stress technical reasons (SLAAC, routing hardware, security properties) for /64.

Operational behavior: SLAAC, DHCPv6, home networking

  • Many home ISPs give only a /64, which complicates multi-LAN setups; guidance says /56 or /48 is preferable.
  • Tension between SLAAC (requires /64) and DHCPv6; Android’s lack of DHCPv6 support is a sore point.
  • People struggle with integrating auto-configured IPv6 addresses into local DNS; some use ULAs, mDNS, or static addresses.

Performance and latency

  • Consensus: extra header bytes have negligible latency impact; differences are dominated by routing, NAT, and hardware.
  • Multiple references (Google, Facebook) suggest average IPv6 latency is often lower than IPv4 due to better paths and less CGNAT.
  • Some report provider-specific IPv6 issues (e.g., buggy firmware, undersized IPv6 infrastructure).

Security, NAT, and privacy

  • Debate over whether IPv4 NAT meaningfully increases security; several note NAT without a firewall is weak or bypassable.
  • IPv6 home setups generally use stateful firewalls instead of NAT; some fear exposing IoT devices, others highlight massive subnet size and default-blocking firewalls.
  • IPv6 privacy extensions (rotating addresses) partially offset loss of NAT “obscurity,” but tracking via other means remains.

Adoption, UX, and critiques of IPv6 design

  • Enthusiasts praise end-to-end addressing, simpler homelab DNS (same address LAN/WAN), easier subnet math with hex, and elimination of hairpin NAT.
  • Skeptics say IPv6 complicates firewalls, DNS, and multi-LAN home networks, and provides no obvious benefit while IPv4 still works.
  • Many dislike the address notation and find typing/remembering IPv6 painful; others counter that DNS and mDNS should be used instead.
  • Recurring “IPv4 with more octets” proposals are criticized as technically unsound and essentially recreating current dual-stack complexity.

Transition strategy and IPv4’s future

  • Some argue IPv6 “failed” because it hasn’t eliminated IPv4 or fully solved address depletion; others say dual-stack was necessary and IPv6 already reduces IPv4 demand (e.g., IPv6-only servers, mobile networks).
  • Expectation that IPv4 will slowly become legacy: more IPv6-only services, IPv4 behind NAT64/4-in-6, and eventually poor quality for IPv4-only users.
  • A few long-time operators note how slowly core Internet protocols evolve and see business and operational inertia, not just technology, as the main drag on IPv6 adoption.