IPv6 Extension Headers are really cool! (at least on paper). The idea is that we can add protocol headers in packets after the core IPv6 header to carry supplemental network layer information to be consumed or set by nodes in the communications path. Extension Headers are the mechanism, and really the only sanctioned mechanism, that makes the IP protocol extensible at the network layer. For instance, last week we talked about Firewall And Service Tickets, aka FAST, and the need for host-to-network signaling-- Extension Headers are the only non-hacky solution for that.
For all their promise, Extension Headers have been a notorious underachiever. We just haven't seen much deployment in the past twenty-five years. There's a real question of whether they can be saved from bit bucket oblivion. Personally, I think it would be a shame if Extension Headers went the way of the dinosaurs, they could be a key to a continually extensible and evolving Internet. So what's their deal and what can we do to save these puppies? Let's discuss...
Ancient history: IPv4 Options
First, a bit of a history lesson. We'll journey way back in time, to the early eighties, when IPv4 was being defined. There was an idea to attach ancillary information to network packets in the form of IP Options. The IPv4 header consists of a fixed length common header followed by a variable length list of IP Options. The options are encoded as Type Length Value tuples, or TLVs, that can be consumed and acted upon by any router in the communication path. Only a handful of IP options were ever defined, including Record Route, Source Route, IP security, padding, and End-of-List options.
IP Options were never widely deployed, and nowadays are considered a hopelessly failed protocol. There were several factors that led to their demise:
IP options are hard to process efficiently in hardware
Variable length headers are unpleasant for hardware
TLVs are difficult to process in hardware
No mandatory or even useful options emerged (unlike TCP options for instance)
Result is that routers either don't support IP Options or defer them to slow software path
IPv4 Options. Note that IP Options are part of the IPv4 header where the presence of options is indicated if the header length field is greater than 5 (that field is multiplied by four to compute the header length). The IP options are a list of TLVs with a header format shown at the bottom.
IPv6 Extension Headers: Chance for a do over
As luck would have it, IPv4 was a huge success even without IP Options. In fact, it was so successful that we needed to create a new version of the protocol to address some of the shortcomings in the first try for an Internet protocol. In particular, IPv4 addresses were defined as thirty-two bits values and it became clear that that's too small a space to scale the Internet. To fix this, IPv6 was defined with 128 bit addresses around the early nineties. Changing the address size meant that IPv6 header header format wouldn't be compatible with IPv4, so that provided an opportunity to reconsider how to represent supplemental network layer information in packets. Thus, IPv6 Extension Headers was born!
In formal terms: Extension Headers, placed between the IPv6 header and the upper-layer protocol header, such as a TCP-header, are used to carry optional Internet-layer information in a packet (RFC8200). An IPv6 packet may carry zero, one, or more extension headers. The Next Header field in the IPv6 header and extension headers is used to indicate which extension header or upper-layer protocol header follows the current header. There are a handful of defined Extension Headers: Hop-by-Hop Options contain a list of TLVs that are processed by routers in the path; Destination Options contain a list of TLVs that are processed by the destination host; Fragmentation allows a big packet to be split into small fragments for sending (in IPv4, fragmentation is part of the base header); Routing allows for source routing through a list of intermediate nodes; Authentication is used to authenticate a packet; and Encapsulating Security Payload is used to encrypt packets.
IPv6 Extension Headers. Multiple extension headers can follow the IPv6 header and precede the upper layer protocol (like TCP or UDP). The IPv6 header and Extension Headers form the so-called IPv6 header chain.
Hop-by-Hop and Destination Options. These two Extension Headers contain a list of options as TLVs. This picture illustrates an example Hop-by-Hop Options header. The fields marked in green show the common Extension Header fields, the red fields show a padding option for alignment, and the blue fields show an example option that carries Interface Identifier
So how'd Extension Headers do?
To be honest, deployment of extension headers is disappointing :-(. Granted, they're in a better state than IPv4, but they have a far way to go to achieve ubiquity. The major issue is reachability-- often packets with Extension Headers are arbitrarily dropped by routers especially on the public Internet. Extension headers revisited blog gives some nice data on Extension Header viability in the Internet (the maps below are from that).
Worldwide drop rates of Hop-by-Hop and Destination Options. The top map shows the drop rate of packets with Destination Options, and the bottom map shows the drop rate of packets with Hop-by-Hop Options. The drop rate of Hop-by-Hop Options is much worse likely due to the fact that Hop-by-Hop Options have more visibility to routers and are subject to more scrutiny and restrictions.
The data and analysis of Extension Headers on the Internet reveals some interesting things:
The “Chicken and the egg” problem!
Operators drop EH because there’s no "useful" options defined
Developers don’t develop new options because they’ll just be dropped
Size matters!
Long extension headers exhibit higher drop rates than short ones
Likely due to parsing buffer being exceeded in routers that want to filter L4 ports
Type matters!
Some Extension Header types are more susceptible to packet drops
E.g., Hop-by-Hop Options fairs worse than Destination Options (maps above)
Open-endedness can be a bad thing
There are few inherent limits on Extension Headers
For instance, some could stuff a packet with over 700 hundred Hop-by-Hop options
The lack of limits opens the door to Denial of Service attack
Implementation issues
Easy to find bugs with EH especially with protocol specific hardware offloads
Kernel API is difficult to use, must have root privileges
Obvious DoS attack vector with current model (HW and SW implementations)
Getting Extension Headers to fly
There is ongoing work in IETF to address protocol problems of Extension Headers. Recently, RFC9673 was published that updates procedures and greatly simplifies the processing of Ho-by-Hop Options. Another Internet Draft, Limits on Sending and Processing IPv6 Extension Headers is in final stages of review in IETF and defines a number of optional limits that may be applied to Extension Headers with the goal of eliciting practical implementations (this is also essential in mitigating Denial of Service attacks).
As for useful Extension Headers, there is a growing list of Extension Headers in deployment: SRv6, IOAM, IPsec, and fragmentation are deployed. Additionally, there are several active proposals for QoS signaling, telemetry, and congestion reporting by routers. A workaround to the "chicken and the egg problem" is that most Extension Header deployment is currently in Limited Domains, that is networks under one administrative authority where all the infrastructure can be fixed to properly support Extension Headers. With Limited Domains we can take a much more incremental approach to Extension Header deployment instead of requiring that all the nodes on the Internet have full support from the get go,
As for bugs, we just need to fix them! In the Linux kernel we've identified a few problematic areas like some Checksum offload implementations that are buggy with EH, patches are in the works to start fixing those. Similarly, we're finding that some Service providers are dropping packets with Extension Headers either unknowingly or based on an overly restrictive policy-- several have been open to fixing the issues.
Conclusion: Saving Extension Headers!
As you probably guessed, personally I fall in the second camp of people who would like to see Extension Headers succeed. Nonetheless, I do sympathize with the naysayers and don't have any delusion that we'll be able to fix the whole Internet overnight. But that's okay. If there's one thing I've learned about the Internet, it's that change and evolution is more a marathon than a sprint. But if we succeed with Extension Headers, then everyone can enjoy the benefits of a truly flexible and extensible Internet for probably the next one hundred years! :-)
Comments