Hello IPv6: a minimal tutorial for IPv4 users
Debate around a tutorial for IPv4 users learning IPv6 quickly pivots to the protocol’s real-world trade-offs: address space abundance, the demise of NAT, and how security is actually provided by firewalls rather than translation. Commenters argue over privacy (SLAAC and temporary addresses vs per-device global IDs), operational pain points like weak DHCPv6 and DNS tooling, and lingering resistance to IPv6 based on usability, router quality, and fear of misconfiguration. Overall, many see IPv6 as technically superior and inevitable, but hampered by uneven client support, poor education, and entrenched habits from the IPv4/NAT era.
IPv6 address privacy & tracking
- Many comments argue IPv6 has no worse privacy than IPv4: IPs are unique in both cases, and tracking usually relies on other techniques.
- Modern OSes typically use SLAAC privacy extensions: hosts get randomized IPv6 interface IDs, often rotated hourly to daily, and can keep multiple active addresses at once.
- This can blur whether two addresses in the same /64 are different devices or one device that rotated.
- Others worry that per‑device global addresses make household users easier to distinguish than behind a single IPv4 NAT; frequency and implementation of rotation are seen as critical.
NAT, firewalls, and security debate
- One camp: NAT is primarily an address-space hack; “security” comes from the firewall’s default‑deny inbound policy, not from NAT itself.
- Counterpoint: For SOHO users, NAT provides practical, robust protection: unsolicited inbound connections “simply don’t work” in typical setups.
- Deep technical back‑and‑forth shows that, if routing allows it, inbound packets to RFC1918 addresses can reach internal hosts; NAT alone is not a hard barrier.
- Consensus from more technical comments: real security is via stateful firewalls; NAT adds complexity and can create a false sense of safety.
Address management: DHCPv6, hostnames, and local vs global
- Complaints that stateful DHCPv6 is poorly supported (notably on Android, with issues on iOS) and lacks some IPv4 DHCP conveniences like easy hostname-based inventory.
- Others propose mDNS for discovery, but critics note it is optional, requires active participation, and misses non‑responding or legacy devices.
- IPv6 allows multiple addresses per interface (global, ULA, link‑local). Source address selection and firewall rules across these are seen as more complex than IPv4+NAT for heterogeneous or IoT-heavy networks.
Operational usability and APIs
- IPv6 is perceived by some as “horrible” or harder to reason about; others prefer hex and note that subnetting in /64, /56, etc. is easier than IPv4 CIDR.
- API friction: need for
sockaddr_storage, bracket syntax for literals, and lack of a 127.0.0.0/8‑style loopback block.
ISP, device counts, and pricing
- With prefix delegation, ISPs assign a prefix (often /48 or /64); internal devices self‑assign, so ISPs cannot reliably count devices, especially with privacy addresses.
- Some fear ISPs could price by device count; others note it’s easier to infer device counts from flows and DNS behavior than from IPv6 addressing itself.
Tutorial quality and IPv6 adoption attitudes
- Some find the linked tutorial too dense, packet‑dump heavy, and poor at explaining basics (address scopes, practical configuration).
- Mixed sentiment on IPv6 overall: enthusiasm for end‑to‑end connectivity and “death of NAT” versus resistance due to perceived complexity, security fears, and satisfaction with IPv4.