IPv6 misinformation (posted 2005-08-30)

From time to time, I like to go to news.google.com and type "ipv6". This way I get to read interesting articles such as Mad as Hell XII: IPv6. However, there are also sometimes stories that get important facts wrong, such as CIO Today's IPv6: Time Is Still Not Right article.

They don't think IPv6 is very useful at this point, they don't take the US government IPv6 position very seriously and they think NAT is actually a good idea because it hides addresses. So far so good: those are all opinions.

I'm not even going to mention the whole "other countries suffer from address scarcity" thing, which is thoroughly debunked elsewhere.

The part that really annoyed me is:

However, this feature isn't exactly free. Quadrupling the address space dramatically increases the bandwidth required to transport each packet. Sending a 64-byte message, for instance, requires 250 percent more bandwidth in IPv6 than in IPv4.

It seems like they're saying a packet with 64 data bytes will be 3.5 times as large in IPv6 as it is in IPv4. But even if we generously assume they meant that the overhead is 2.5 times as large, they're wrong. An IPv6 header is twice as big as an IPv4 header: 40 rather than 20 bytes. But in the real world, there is other overhead as well: TCP (20 bytes) or UDP (8 bytes) as well as ethernet, which has 18 visible and 20 invisible bytes of overhead. So an IPv4 packet with 64 data bytes uses up at least 64 (data) + 20 (IP) + 8 (UDP) + 38 (ethernet) bytes or 130 bytes worth of ethernet bandwidth. (That's 103% overhead.)

The same 64 bytes of data on the same ethernet but now using IPv6 takes up 150 bytes of bandwidth, which is 15.4% more than its IPv4 counterpart. The average size of packet on the internet is around 500 bytes. 20 extra bytes means an additional overhead of 4%. Yes, the extra bandwidth use is annoying, but it's a far cry from "250 percent more bandwidth".

For low-speed links there shouldn't be an issue as the IPv6 header can be compressed, just like the IPv4 header. (However, I'm not sure if this is actually implemented in available products at the moment.)