Building network automation solutions

9 module online course

Start now!

Cisco PR propagates IPv6 myths

One could understand application programmers falling into the traps of IPv6 myths, but when it happens to Cisco’s Global PR Manager, it’s embarrassing. Marc Musgrove was promoting at least one and a half myths (I’m still not sure about easier mobility with IPv6) in his latest blog post.

Simplified packet header for routing efficiency. This is a new one for me (and I thought I’ve seen them all), but no less bogus than any other. Cisco’s own measurements confirm that IPv6 performs almost equally well (or marginally worse) than IPv4. There’s no improvement and no increased efficiency.

Mandatory IPSec implementation for all IPv6 devices. While this is technically true, it’s at least misleading, as most readers automatically assume it means any host-to-host communication can be easily encrypted. Not necessarily true, you’ve implemented a compliant IPSec implementation even if you just recognize the IPSec header without having any ESP (encryption) or AH (integrity/origin authentication) capabilities.

Maybe it’s time we all grow up and admit the only benefit of IPv6 is its larger address space.


  1. With regards to the "simplified packet header for routing efficiency". There is actually something to this claim. With a fixed header size compared to IPv4's variable length header, the 64 bit alignment and the removal of the checksum. One could certainly make the claim that the header is better optimized for forwarding than the IPv4 one.

    Options in IPv4 aren't used and the checksum isn't that hard to compute. The benefit of 64 bit alignment, especially if the L2 header isn't aligned isn't that great and compared to the lookup of the much longer address I doubt anyone has an implementation with equal hardware forwarding IPv6 faster than IPv4. But sure, the _intention_ of making IPv6 better was there.
  2. You're absolutely correct. However, most of the other IPv6 benefits were true 15 years ago when the standards were ready, including the "reduction in IPv6 routing tables due to hierarchical addressing", "better QoS (due to flow field)", "better mobility" and even "better security" (IPSec on IPv4 was rare in those days). Today they are just myths.

    Going into technical details: it's my understanding that while IPv6 headers might be better aligned than IPv4 headers, they always require extension headers, which could be routing options or upper layer protocols. Forwarding IPv6 packets thus always requires a lookup into the extension headers, whether it's needed or not, while checking the length of IPv4 header (and, in most cases, dropping any packet with options) is a simple comparison.
  3. Forwarding of an IPv6 packet does not require that a router look into the L4 header or extension headers. Features like ACLs might require it, just like for IPv4.

    In fact I have it from a reliable source that IPv6 was specifically designed to make it hard for routers to look any deeper into the packet than the L3 header.

    Too early to say, but I wouldn't be surprised if extension headers will be as rare as IPv4 options are.

    But just to be clear, I fully agree with you. IPv6 is all about the extra address space. Allowing the continuing growth of the Internet. The other changes are insignificant.
  4. Hop-by-hop Extension Header (admittedly deprecated): "is used to carry optional information that must be examined by every node along a packet's delivery path." (

    Routing Header (should be disabled on the routers): equivalent to loose source routing in IPv4

    An intermediate IPv6 router has to examine these two (if they're present). Very similar to IPv4, the datagram with any of these options is probably punted to the CPU (or slow switching, depending on your platform). I can see no real difference with IPv4 options.
  5. There is no in transit fragmentation in IPv6. Moreover the header is fixed-length. The differences observed may come from non optimised asic from vendors, where ipv6 represents less than 1% of the traffic.

    Bigger MTU and shorter routing tables may also help in the future. Time will tell.
  6. There is no in-transit fragmentation in IPv4 ... at least not in the fast path. A while ago fragmentation kicked you down to process switching (exception: GRE packets). Everyone is trying to avoid it anyway. Myth#1 busted.

    IPv4 header is also fixed length (unless you're writing a research paper). Nobody is using IP options and anyone sensible enough has them turned off anyway. BTW, IP options kick you to process switching. Myth #2 busted.

    Shorter routing tables? That's myth#3. Read my other articles about IPv6 myths, they cover this one pretty thoroughly.
Add comment