For reasons that I don’t fully understand, I got very excited when I saw this new IETF draft, IPv6 Extension Headers in the Real World. I guess even in a domain as reputably dry as IETF drafts, I’m not entirely immune to stabs at rhetorical flair.
Having some clarity about the controversial (for admittedly bland applications of the word) topic of IPv6 extension headers would be great all by itself. But then the draft also promises to connect the topic in some way to something called the Real World™ (a domain some wags have suggested the IETF has no business discussing). It’s enough to make me want to break out Ye Olde Blogging Keyboarde.
What IPv6 nerd wouldn’t be excited by a sentence like: “Because there is currently almost no reliance on IPv6 Extension headers, the corresponding code paths are rarely exercised, and there is the potential that bugs still remain to be discovered in some implementations.”
My understanding is that this sentence could be viewed as quite the understatement by those aware of the operational history of IPv6 extension headers, as evidenced by this quote from Arbor Network’s Bill Cerveny:
“In theory, extension headers allow for adding new functionality to IPv6. In reality, it is hard to create and implement new extension headers because of the lead time that network device implementers need to update their hardware and software. Many network devices will drop any packets with extension headers that aren’t recognized by the device. There will be a continual trade-off between the introduction of new extension headers to IPv6 and the cost to network device creators and maintainers of adding support for the new extension header.”
And this only implies the potential security issues, some of the most serious of which are explored in depth here.
In any case, I wanted to dive right into the new draft but realized that readers may not be too familiar with IPv6 extension headers (not to mention my own grasp of them could always use a little brushing up).
So let’s make this a multiple-part blog — i.e., let’s give this blog some extension headers (which would mean the Next Header field of this blog should have any value but ___; feel free to answer in the comments if you like).
In this introduction we’ll cover: What Are IPv6 Extension Headers?
Extension headers in IPv6 (defined in RFC 2460) were a clever design choice to help get rid of the variable length header in IPv4.
Here’s an IPv4 header:
The Internet header length and options field are circled in red. The 4 bit IHL field indicates the number of 32 bit words in the header: a minimum of 5 when no options are present, and a maximum of 15.
Because the length of the IPv4 header might vary depending on the presence of options, a router needs to test a checksum for every packet and determine if the header is actually the right length. Then, it also needs to recalculate the checksum after decrementing the TTL.
The options include things like loose source route, record route, and MTU probe (the full list of options is here).
You may be most familiar with using one or more of these options (at least I was) from doing an extended ping with options on a Cisco router. Here’s a simple GNS3 topology we’ll use to demonstrate extended ping in action:
And here’s the ping, from R1’s loopback to R3’s, and using the record route option:
The first highlighted area shows the selection of the option for extended commands while the next highlighted area shows the “record route” option selected (IP option 7). Last highlighted area shows the ping results with the resulting recorded IP addresses of each router in the ping path.
Neat! But having to potentially check the header length for every packet is, in hindsight, a bit inefficient so in IPv6 the designers decided to make every header the exact same length: 40 bytes.
But because it might continue to be useful to have IP options (as well as any other fields from the IPv4 header that make it longer) a method of appending options and other fields as extension headers was devised; i.e., IPv6 extension headers.
Here’s the IPv6 header:
A lot tidier, right? Fields that were rarely used are gone. And since every header is now 40 bytes, packet processing can be optimized in router hardware.
Meanwhile, the 8 bit Next Header field is how the router is informed of either the upper layer protocol or the presence of header extensions. To improve end-to-end efficiency, the designers of IPv6 made it so that the only extension header that needs to be processed by all routers in the path is the Hop-by-Hop Options header. When the Next Header field is set to 0 this tells the router that a Hop-by-Hop Option extension header is appended. If the field is any value but 0, the intermediate routers can safely ignore any potential extension headers.
Here’s the high-level view of an IPv6 packet and where the extension header(s) go:
Next time: Meet the IPv6 Extension Headers.
Tom
