Several folks have written to comment on the 250% increase in overhead I attributed to IPv6 in my previous column on the topic. They’re right. The number is overstated, for a rather embarrassing reason (got my bits and bytes confused – spent too long away from a protocol analyzer).
But while my initial figure was clearly incorrect, determining the actual figure was more challenging than either my readers or I had anticipated. More than half who sent in the “right” figure subsequently revised their calculations (including reader Mel Beckman’s letter to the editor.
With the gracious help of David Newman, a Network World Test Alliance partner, here are the corrected figures and how we arrived at them:
First, Newman advocates using as a baseline a 40-byte TCP/IP acknowledgment (ACK) packet, rather than a 64-byte packet, given that TCP ACKs are among the most common packets on the ‘Net. ACKs have a TCP header but no payload, so the breakdown is as follows:
l Under IPv4, the total IP header without options runs to 20 bytes. The TCP header takes up an additional 20 bytes, for a total packet length of 40 bytes.
l Under IPv6, the total IP header without options is 40 bytes. The TCP header takes another 20 bytes (same as for v4), for a total packet length of 60 bytes.
The upshot? A 100% increase in IP header overhead (from 20 to 40 bytes), and a 50% increase in total packet length. As noted, that’s not the 250% increase for a 64-byte packet I initially cited, but it’s still plenty.
It’s also reasonable to ask how many packets on the Internet are small enough for the overhead to matter. The answer, as indicated by the data, is “most of them.” Various analyses demonstrate that between 20% and 25% of packets are 40 bytes, with roughly 50% of all packets at 220 bytes or less. (See this Sprint document and check out data obtained by the Cooperative Association for Internet Data Analysis). Therefore, the overhead increase generated by IPv6 on small packets is neither negligible nor a red herring.
In addition, the exact timing of IP address exhaustion has proven fluid. The best current projections range between 2013 and 2030 (for a good baseline analysis, check out IPv4 Address Space Report). But the projected exhaustion point tends to keep receding into the future (early projections were that addresses would run out in the late 1990s), largely because of the widespread deployment of network address translation (NAT).
And NAT’s not going anywhere. While packet purists despise NAT, because it breaks the end-to-end-ness of the Internet, most companies deploy NAT by choice – preferring not to provide internal addressing information to the public Internet. That’s not likely to change with the deployment of IPv6 – Cisco has implemented IPv6 NAT functionality in its routers. Don’t look for NAT to die any time soon.
The bottom line stays the same: Companies shouldn’t race to embrace IPv6.
