IPB199: Developing IPv6-Friendly Code
Network engineer and security developer Chris Cummings joins IPv6 Buzz to discuss the practical benefits of IPv6 for software developers, focusing on how eliminating NAT reduces complexity, improves logging, and lowers costs. The conversation also covers common pitfalls developers encounter when writing IPv6-compatible code and best practices for building address-family-agnostic applications.
Summary
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.
Key Insights
- Chris Cummings argues that NAT traversal forces developers to build complex workarounds into protocols, and that this complexity multiplies in containerized environments like Docker and Kubernetes where multiple NAT layers stack on top of each other.
- Nick Baraglio notes that service providers maintaining CGN NAT translation logs face approximately a 10x increase in storage requirements, and that law enforcement inquiries about subscriber identity almost always involve IPv4 addresses — making IPv6 a practical solution to both cost and accountability problems.
- Chris contends that one of the most common IPv6 developer errors is a naive regex that only accepts dotted-decimal IPv4 addresses, causing software to silently reject valid IPv6 inputs rather than being address-family agnostic.
- Chris warns that attempting to enumerate a /64 subnet in a script — as one might enumerate a /24 in IPv4 — will cause the script to run indefinitely at 100% CPU, illustrating how IPv4-centric assumptions break down at IPv6 scale.
- Chris argues that developers should almost never make raw socket calls specifying a specific address family, and that changing a bind address from '0.0.0.0' to '::' is often sufficient to enable full dual-stack support — a change she demonstrated with a single-line pull request accepted by an open-source project.
Topics
Full transcript available for MurmurCast members
Sign Up to Access