The IPv4 address space is nearing exhaustion. The unallocated address pool is currently expected to be depleted at the IANA level in June 2011, and at the Regional Internet Registry (RIR) level in January 2012. Networks will need to transition to IPv6, which allows for an astronomically larger address space (among other nice features). IPv6 has been around in some form since 1995. However, since network operators are human beings, the consensus has not been to methodically migrate to IPv6 over the last 15 years, but rather to procrastinate 15 years and then pull an all-nighter on the eve of exhaustion.

IPv6 is likely to become an important topic in the next few years, and I've become interested in brushing up on the protocol. (I first studied IPv6 in 1996, back when everyone figured adoption would be imminent.) IPv6 is likely to be deployed on a much larger scale in the coming years than in years past, exposing many practical network engineering challenges, and perhaps creating opportunities for a low-level software engineer such as myself to provide value in easing migration and filling in the coverage gaps.

My first experiment was to measure the extra protocol overhead of IPv6 in common network scenarios. An IPv4 header occupies 20 bytes in the common case, and an IPv6 header occupies 40 bytes in the common case. The practical difference in overhead depends on the size of the packets—with large packets, the extra 20 bytes of header doesn't matter too much when measuring the overhead with respect to the total payload being transmitted. IPv6 evangelists occasionally tout the protocols's minimum MTU (1280 bytes) which is larger than in IPv4 (68 bytes, or 576 bytes to avoid fragmentation) when calculating efficiency, and come to the conclusion that IPv6 is even more efficient than IPv4. This doesn't reflect the practical reality of the modern Internet where most routes support a path MTU of 1500 without a problem. IPv6 is a necessary and worthwhile protocol, but we shouldn't be afraid to study the actual, real-world overhead.

To measure IPv6 overhead in a real-world test, I configured two User-Mode Linux instances (similar to virtual machines) with a virtual serial connection between them which can support PPP. I used the nc program to transfer data streams of various sizes over TCP in both IPv4 and IPv6, and recorded the total number of transferred bytes as measured by pppd. Performing real-world measurements was somewhat redundant, since the theoretical overhead can be easily calculated using the size of the packet headers and payload lengths. However, it was interesting to see the protocol in action.

As expected, the additional outbound overhead from our TCP sending node is quite negligible. However, the return traffic—mostly small packets of TCP ACKs with empty payloads—contains a significant amount of additional overhead. I wonder how this will affect users with asymmetric connections with a limited upload capacity. At some point, upload limitations can start bottlenecking the download. (It might be an interesting experiment to see how effective TCP sliding window sizes are at mitigating this effect.)

I performed this experiment again, limiting the outbound TCP segment payloads to 128 bytes, to get an idea of how applications with smaller packet sizes might impact an IPv6 network.

The IPv6 header overhead begins to really add up when using smaller packet sizes. The total bandwidth consumed by applications with small bits of sporadic data or low-latency requirements (i.e. VoIP) might be significantly higher on an IPv6 network.

All in all, I think the additional protocol overhead of IPv6 is quite manageable in most cases, and I hope network operators begin upgrading their IP networks soon.