IPv6 Extension Headers Review
IPv6 is different from IPv4 in many ways. Of course, IPv4 and IPv6 addresses are obviously different (32 versus 128 bits, decimal versus hexadecimal are examples), but these protocols also have different protocol header formats. Similar to the IPv4 option fields, IPv6 packets can utilize “Extension Headers” to extend the functionality of the protocol, without having to completely change the IPv6 protocol header every time we want to add new functionality. These extension headers can be used “optionally” and are placed between the IPv6 header and the upper-layer protocol headers (e.g., TCP or UDP).
Extension headers are defined in the IPv6 full standard protocol specification, IETF RFC 8200, Internet Protocol, Version 6 (IPv6) Specification. In Section 4 of RFC 8200, there are details on how extension headers work and the format of the more common headers that all IPv6 nodes must support. The IPv6 header has a Next Header field that contains the type number of the extension header that follows. In turn, each subsequent extension header also has its own Next Header field to indicate the following header type. The following illustration from IETF RFC 8200 shows the use of the Next Header values.
In this way, IPv6 packets can have multiple extension headers between the outer IPv6 header and the upper-layer protocol header. The Internet Assigned Numbers Authority (IANA) maintains the list of the Next Header type numbers used in the IPv6 header and within the subsequent extension header’s Next Header fields.
A good document on how IPv6 extension headers function can be found at this Cisco document from 2006 titled “IPv6 Extension Headers Review and Considerations” (PDF). Tom Coffeen has also written a three-part blog series on what he terms “IPv6’s Prosthetic Head(ers)” (part 1, part 2, part 3).
Making a New Extension Header
One of the design characteristics of IPv6 extension headers is that new ones can be added to extend the functionality of the protocol without having to completely overhaul the main IPv6 header itself. In the future, new header types can be added as new requirements of networking and applications evolve.
Let’s say that we have come up with an amazing new idea for handling IPv6 packets and we want to create a new extension header. We may have come up with a great idea for how to forward and process IPv6 packets traversing networks. Or maybe we want to “make money fast (MMF)” and create a new header that integrates with some blockchain or cryptocurrency. Let’s consider what it would take to add a new extension header to IPv6 and address all the issues with “inventing” a new header and getting it used/permitted worldwide.
The first step is to engage with the IETF and write a draft proposal and submit it for peer review. The ipv6 IETF working group has concluded now that the protocol is a full Internet standard. Therefore, the 6man IETF working group and/or the v6ops IETF working group are probably where we would need to make our case and submit our proposed draft. However, some in the IETF may point to Section 4.8 in IETF RFC 8200, which discourages creating new extension headers. If the new EH were approved, this would become a new IETF RFC for the extension header, but we may also need to revise RFC 8200 to include the new header. Depending on the support for our idea and the lengthy standards process, this could take a year or even longer to move through the IETF.
Once approved, we would need to get a Next Header number added to the IANA list of extension headers. This might not take as long as the IETF standards process, but the new extension header number would need to be mentioned in the IETF RFC that describes our extension header (or RFC 8200).
Now comes the hard part: getting our newly approved extension header implemented across the whole of the Internet. This would involve getting all the world’s network equipment to be able to pass our packets, and possibly observe these headers and process them in some way. The new extension header would need to be implemented in core Internet routers, service provider networks, subscriber CPE, enterprise networks, and cloud infrastructure. We would also need to get our extension header permitted to be forwarded across all the firewalls, deep packet inspection (DPI) systems, load balancers, and other middleboxes all over the world. We would also need to make sure that other security functions like Intrusion Prevention Systems (IPSs), packet brokers, web proxy services, malware prevention systems, and other filters don’t accidentally (or intentionally) block IPv6 packets with our new extension header.
The next step is to have every end-node host operating system implement the new extension header into their IPv6 protocol stack. This means that Apple macOS, iOS, iPadOS, Microsoft Windows, Google (for Android and ChromeOS), Linux, and many other OSs would need to be modified and patches would need to be pushed out to all devices. This process could take years because there are many old hosts out there. I’ve witnessed enterprise networks that still use Red Hat Enterprise Linux (RHEL) 6 and CentOS 4/5/6 and Linux 2.6 kernel systems as evidence of the OS “long tail”.
We shouldn’t be in a hurry to get through this OS and network upgrade and adoption process. From start to finish, this whole process could take as little as three years but could take up to a decade depending on old equipment and software.
Dropping IPv6 Packets with Extension Headers
Even after all that, there could still be networks around the globe that drop the newly minted extension header. For example, even today, there are many networks around the globe that drop IPv6 packets with well-known extension headers. Studies were conducted almost a decade ago on this topic, which resulted in the publishing of IETF RFC 7872, “Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World”.
Additional research was performed by many groups to further analyze why certain extension headers are dropped and to determine causality and trends. Much was written about the issues related to IPv6 packets containing Fragmentation headers and IETF RFC 8900 concluded that “IP Fragmentation Considered Fragile”. In 2021, IETF RFC 9098, “Operational Implications of IPv6 Packets with Extension Headers,” thoroughly covered this topic again.
Geoff Huston, Chief Scientist at APNIC, has written and presented numerous times on his observations of IPv6 extension headers and the challenges therein. Back in 2020, Geoff wrote about his “Measurement of IPv6 Extension Header Support” and in 2023 he wrote an update titled “A further update on IPv6 extension headers”. Geoff’s research shows that there are different drop rates of different extension header types in different geographic regions. His measurements show that Hop-by-Hop extension headers are almost always dropped and Destination Option headers are frequently dropped. His research also showed a trend of fewer Fragmentation and Destination Option header drops in recent years.
There are also rules for proper IPv6 extension header usage along with documented security implications if these rules are broken when attackers create crafted packets (RFC 7112). And now, there is new guidance on how filtering of IPv6 packets with extension headers should be performed. This is documented in IETF RFC 9288, “Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers”. The commonly accepted advice is to drop or ignore IPv6 packets with Hop-by-Hop (HbH) Options headers and drop select Routing Headers (type 0, 1, and 3), drop experimental and testing header types, while permitting others to be forwarded. After we create our new extension header, this RFC would need to be updated to tell everyone to permit our header.
Summary
Worldwide IPv6 deployment is well underway. IPv6 has now been fairly ubiquitously deployed within the Internet “backbone” and in service provider networks and mobile carriers. A high percentage of broadband and mobile subscribers now unknowingly use IPv6. However, many enterprises have yet to deploy IPv6 within their private network environments.
It is a daunting task to create a new extension header and get it adopted by all network products and host operating systems. This fact leads to the question of whether or not IPv6 deployment is too far along and whether or not it is too difficult to change the protocol at this point in its evolution.
Even if we had a fantastic and compelling idea for a new extension header, we would need to get it approved by the IETF and assigned a Next Header number by IANA. There may even be other auxiliary RFCs that would need to be updated. Then the process of getting it permitted by all the firewalls and middleboxes may not be feasible.
The whole process of getting our new extension header designed and then fully deployed globally across the Internet could conservatively take five to 10 years. This is not to say that it is impossible to create a new IPv6 extension header at this point, but realistically it would take a lot of work and take a lot of time so the new functionality must be very compelling to make it worthwhile.
