IPB202: How to Get Hands-On IPv6 Deployment Experience
Ed Horley interviews John, an experienced network engineer, about practical ways to gain hands-on IPv6 experience at home. They discuss consumer-grade IPv6 setups, multi-homing challenges, ULA addressing, NAT/masquerading trade-offs, and how working with multiple historical protocols informs modern IPv6 design thinking.
Summary
The episode focuses on practical, consumer-level IPv6 deployment experience as a way for network engineers and enthusiasts to build foundational knowledge. Guest John describes setting up an Xfinity Now connection ($25/month) as a secondary internet link specifically to explore IPv6 from a pure consumer standpoint. He configured a dual-stack WAN with an IPv6-only LAN using VyOS (an open-source routing platform), finding the setup surprisingly straightforward once he understood the nomenclature and syntax.
John describes his multi-homing challenge at home, where he has both a WISP connection (with his own ASN and routed IP space) and Comcast/Xfinity as a backup. He explored NPTv6 (Network Prefix Translation) for failover but found it limiting because the WISP and Comcast assign different prefix sizes, making one-for-one prefix translation impractical. He ultimately fell back to IPv6 masquerading (similar to IPv4 NAT overload), which works reliably but sacrifices true end-to-end IPv6 connectivity. He uses ULA (Unique Local Addresses) internally for consistent addressing regardless of upstream provider.
The conversation addresses the broader philosophical debate around NAT in IPv6. Ed and John agree that NAT, while historically criticized by IPv6 purists, represents a practical toolset that operators need available to them, and that trying to enforce a no-NAT framework on everyone is overly narrow. They also discuss the 'DHCP wars' in IPv6 (SLAAC vs. DHCPv6), noting that the lack of standardization has caused some open-source projects to simply implement their own solutions, creating inconsistency across platforms.
John draws heavily on his experience with legacy protocols (IPX, AppleTalk, SNA) to argue that IPv6 isn't fundamentally different from other networking protocols — it's just a larger integer with a fixed 64-bit network/host boundary. He suggests that engineers who only know IPv4 struggle more because they've internalized IPv4-specific assumptions, whereas those who worked with multiple protocols find the transition more natural. He recommends that beginners simply start with consumer hardware (Ubiquiti, OpenWRT, MikroTik, VyOS) and a mainstream ISP like Comcast, let it work, then use tools like Wireshark to observe what's actually happening on the wire.
The discussion also touches on the broader distinction between 'real' internet connectivity (where every device has a publicly routable address) versus 'proxy' internet access (where only the router/gateway has a true internet presence). John argues that most consumers and applications have adapted to the proxy model, and that IPv6's true value — giving every device a real address — is underappreciated. He notes that application developers have built workarounds (persistent outbound connections, cloud proxies) specifically because of IPv4 NAT constraints, and that IPv6 could eliminate the need for such workarounds.
Key Insights
- John argues that engineers who grew up with multiple protocols (IPX, AppleTalk, SNA) find IPv6 adoption easier because they never internalized the assumption that IP is the only protocol, making the 'just another protocol' mindset natural for them.
- John found that NPTv6 (Network Prefix Translation) is impractical for residential multi-homing because different ISPs assign different prefix sizes, preventing the one-for-one prefix mapping NPTv6 requires, leading him to fall back to IPv6 masquerading instead.
- John argues that the lack of a NAT overload equivalent standard in IPv6 has caused open-source projects like VyOS to implement their own non-standard solutions, creating cross-platform inconsistency that harms application developers who need predictable network behavior.
- Ed and John contend that most consumers and enterprises have lived with 'proxy internet access' (NAT) for 25+ years and that only the gateway router technically has true internet connectivity — a distinction they argue is widely misunderstood and shapes unrealistic expectations about IPv6.
- John observed that consumer router UIs, including VyOS, provide insufficient visibility into what PD (Prefix Delegation) information has been received from the ISP, making troubleshooting unnecessarily difficult for users who need to debug IPv6 prefix assignment.
- John claims that Comcast/Xfinity's IPv6 implementation is mature enough that a basic dual-stack home setup 'just works' with minimal configuration on prosumer hardware, with the complexity only emerging when attempting multi-homing or advanced features like masquerading.
- Ed argues that Cisco IOS displaying IPv6 addresses in uppercase is a legacy artifact from before the RFC standardizing lowercase display was finalized, and that such platform inconsistencies create unnecessary cognitive overhead for engineers learning IPv6.
- John contends that application developers have engineered persistent outbound connections and cloud proxy architectures specifically to work around IPv4 NAT constraints, and that IPv6's end-to-end addressing model could eliminate the architectural need for these workarounds.
Topics
Full transcript available for MurmurCast members
Sign Up to Access