Support for IPv6

Adoption, incentives, and “is IPv6 worth it?”

• Some say IPv6 is clearly “here” (near half of Google traffic, strong mobile support) and launching IPv4-only projects in 2024 is a mistake.
• Others argue IPv6 is optional: nothing is dropping IPv4 soon, dual‑stack adds complexity, and running IPv4‑only is “radically simpler” with few downsides.
• Several note cloud and ISP economics pushing IPv6 (IPv4 address charges, scarcity, CGNAT costs), but also that big providers don’t heavily incentivize it beyond basic support.
• There is disagreement whether IPv6 is a success (steady adoption after IPv4 exhaustion) or a “failed project” due to slow, long‑tail migration.

IPv4–IPv6 interoperability and NAT64

• A recurring confusion: IPv4 is not inherently “accessible over IPv6”; an IPv6‑only host cannot talk to IPv4 without translation.
• NAT64/DNS64 are repeatedly cited as the practical bridge: most real‑world IPv6 deployments use them to reach IPv4‑only sites, at the cost of extra infrastructure and some latency/complexity.
• Some see this as an acceptable design (similar to NAT on IPv4); others call it a “missed opportunity” but struggle to propose a realistic native‑compatibility alternative.

Complexity, usability, and design trade‑offs

• Pro‑IPv6 comments emphasize: simpler header, no fragmentation by routers, unified ICMPv6 control, stateless autoconfiguration, huge address space eliminating NAT and RFC1918 conflicts.
• Critics highlight: multiple address assignment mechanisms (SLAAC, RA, stateful/stateless DHCPv6), privacy addresses, and non‑obvious DNS precedence, making it harder to reason about than small IPv4 networks.
• Some see dual‑stack as almost free (OSes and libraries already support both); others focus on human and operational overhead: staff must understand two stacks, tools, and failure modes.

NAT, performance, and operational pain

• Strong sentiment that NAT is an ugly but necessary IPv4 band‑aid, causing protocol contortions (STUN/TURN/ICE), complicated VPN/VoIP/security, and severe issues at CGNAT scale (overload, port exhaustion, extra latency).
• Others counter that per‑packet NAT overhead is microseconds and not a material latency/bandwidth bottleneck for typical home use; problems stem from under‑provisioned ISPs, not NAT itself.
• Several note IPv6 simplifies VPNs and internal addressing (no overlapping RFC1918, easy /48–/64 allocation), and can avoid deep NAT chains that become unmaintainable.

Address space, “IPv5” ideas, and backwards‑compatibility debates

• Some wish for “IPv4 but bigger” (incremental extension preserving all existing /32 blocks), claiming IPv6 overreached and forced a hard migration.
• Others explain why that’s infeasible: routers and hosts can’t handle larger addresses without upgrades anyway; extended headers break legacy return‑path routing; DNS and APIs would still need new types.
• Consensus among defenders: any non‑trivial alternative would require essentially the same global upgrade effort and coexistence story as IPv6.

Obtaining and routing IPv6 blocks

• For independent space, commenters mention: getting provider‑independent IPv6 (e.g., /48), an ASN, and peering via BGP; or having ISPs announce your prefix with an LOA.
• Tunnel brokers (e.g., HE) can give free /64 or /48 over IPv4, but add latency, CDN path issues, and abuse‑related blocking.
• Business‑grade ISPs commonly support BGP for customer prefixes; residential ISPs usually do not.

Real‑world IPv6‑only and dual‑stack experiences

• Some operators run IPv6‑only management or internal networks with NAT64 at the edge, reporting simpler routing, firewalls, VPNs, clustering, and fewer address‑management headaches.
• Others tried IPv6‑only and reverted due to cloud provider gaps and software that assumes IPv4 presence even for local services.
• There is frustration that many modern tools and devices (e.g., some streaming boxes, telemetry servers) still lack proper IPv6 support, forcing continued IPv4 or expensive translation layers.