First of all, Happy New Year! Here’s hoping your holidays were relaxing, or at least pleasantly frenetic. Mine managed to be both.
Speaking of New Year’s, one of my resolutions for 2015 is to try to finish my multipart blogs on a tighter schedule.
My last two posts explored the exciting world of IPv6 extension headers. Among other details, we contrasted the variable header length of IPv4 reviewed with the 40 byte fixed header length of IPv6 as — something that makes packet processing much faster for routers and switches. It also provides an efficient model for adding special treatment of, and additional options to, IPv6 packets. These include things like fragmentation, hop-by-hop handling, and authentication and encryption.
Hopefully, I’ve provided enough background to now talk about the inspiration for this series, a new(ish) IETF draft, IPv6 Extension Headers in the Real World. You may recall (and please excuse) a bit of snark on my part regarding the juxtaposition of the abbreviation IETF with the phrase “the Real World.”
And now that you know a little about IPv6 extension headers, here’s that quote from Arbor Network’s Bill Cerveny again:
“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.”
Doesn’t sound very encouraging, does it? Indeed, the opening paragraph of the IETF draft points out:
“IPv6 Extension Headers are deemed to present a challenge to IPv6 implementations and networks, and are known to be intentionally filtered in some existing IPv6 deployments” but promises “real-world data regarding the extent to which packets with IPv6 extension headers are filtered in the public Internet, and where in the network such filtering occurs.”
So what do such data look like?
The authors of the draft ran tests to various types of servers running IPv6. These servers were sourced using the World IPv6 Launch site as well as Alexa.
According to the draft, testing was conducted to web, mail, and DNS servers using the following probes:
• IPv6 packets with a Destination Options header of 8 bytes
• IPv6 packets resulting in two IPv6 fragments of 512 bytes each (approximately)
• IPv6 packets with a Hop-by-Hop Options header of 8 bytes
The authors were primarily concerned where packets including these extension headers might be dropped. If drops occurred in the destination AS network, such results could be attributed to the local security policy — much like, say, the complete filtering of ICMP in IPv4: Limiting for end-to-end troubleshooting, perhaps, but the prerogative of the filtering network.
More troubling to the authors would be drops of packets in transit ASes between the source and destination networks: The viability of any extension header functionality and subsequent deployment and effective use is entirely reliant on whether or not these intermediate networks honor packets with extension headers or merely drop them as a matter of policy.
So here are the data (in the inimitable ASCII formatting that we’ve come to know and love from IETF documents):
A bit of explanation is in order. The first number in each cell (e.g., 11.88%) is the percentage of drops experienced by the extension header type given the target type. The values in parentheses are the “best-case” and “worst-case” percentage “ranges” for where the drop occurred. For example, the best case scenario is the packet drop occurring in the destination network. The worst case scenario happens when the packet is dropped in the transit network. (You may want to refer to the draft for more info about the exact methodology and results.)
At first glance, it doesn’t look too good for the viability of IPv6 extension headers in the “Real World.” Indeed, the authors recommend the following:
“New protocols that are to operate in the public Internet should consider the effect of widespread filtering of IPv6 extension headers in the public Internet. If IPv6 extension headers are at all employed, a fall-back mechanism that does not rely on IPv6 extension headers should be considered.”
This doesn’t mean we can’t take advantage of IPv6 extension headers within an AS (or where traffic paths are deterministic through ASes that are known to support them). But given their limited viability in the “Real World,” we’re likely to see less and less vendor support for existing (and new) IPv6 extension headers over time.
