IPB199: Developing IPv6-Friendly Code

In this episode of IPv6 Buzz, host Tom Coffeen and Nick Baraglio are joined by guest Chris Cummings, a network engineer turned security developer who works in an IPv6-first environment. The discussion centers on the often-overlooked perspective of software developers when it comes to IPv6 adoption.

Chris argues that IPv6 is not merely a compliance burden but offers genuine practical benefits to developers. The core argument is that IPv4 with NAT breaks end-to-end connectivity, forcing developers to implement complex workarounds — particularly in environments like Docker and Kubernetes where multiple layers of NAT compound the problem. Chris references a Tailscale article that catalogued six or seven distinct NAT traversal types as evidence of how deeply this complexity has penetrated networking software.

The conversation pivots to security and logging benefits. Chris explains that from a security standpoint, IPv6 simplifies log analysis by exposing actual host addresses rather than shared NAT addresses. Nick extends this point to highlight the massive storage overhead that CGN NAT translation logging imposes on service providers — potentially a 10x increase in storage requirements compared to native IPv6 logging — and notes that law enforcement inquiries almost always involve IPv4 addresses, creating accountability gaps.

The group also discusses the financial case for IPv6 adoption in enterprise environments: reduced log storage costs, elimination of IPv4 surcharges from cloud providers, and reduced engineering time spent troubleshooting NAT-related failures.

The NAT-equals-security debate is addressed at length. Chris acknowledges that some enterprises still conflate NAT with firewall protection, citing a research article demonstrating NAT bypass via state table entry reuse as a turning point in public awareness. The group also discusses the nuanced tension around NPTv6 as a workaround for multi-homing without provider-independent address space, with the general consensus that while PI space is preferable, dogmatic positions are counterproductive.

Chris then outlines specific 'rakes to step on' for developers new to IPv6: containerization tools may not work out of the box in IPv6-only environments, GitHub tooling still has gaps, source address selection in dual-stack environments can create unpredictable routing, and the concept of multiple addresses per interface is counterintuitive for developers accustomed to using IP as an identity layer. She also warns against naively enumerating a /64 subnet in scripts — a mistake that would result in CPU exhaustion and near-infinite runtime.

Finally, Chris advises developers to avoid hardcoding address family assumptions into their software. She recommends using DNS names and higher-level abstractions rather than raw socket calls, ensuring input validation supports both address families, and replacing hardcoded '0.0.0.0' bind addresses with '::' to enable dual-stack listening. She recounts submitting a one-line pull request that changed '0.0.0.0' to '::' in an open-source project, immediately adding IPv6 support.