An Introduction to IPv6 Extension Headers

This is the first of a series of blog posts aiming at describing how to use Chiron to abuse IPv6, and especially IPv6 Extension Headers. However, in order to understand the possibilities that exist with regard to the abuse of IPv6 Extension Headers, we first need to understand the related standardisation foundation.

My objective is that when this series of the blog posts come to an end, the reader shall be able not only to reproduce all the known related attacks, but also to compile and implement his own attack methods. And this is exactly the power of Chiron: it does not just implement known attacks (there are other tools that do it really well), but it provides you the ability and flexibility  to implement any kind of related attack, new or not, without having to write a single line of code. 

IPv6, initially introduced with [RFC 1883] and [RFC 2460], and lately updated with [RFC 8200], brings several important changes to the IP protocol. Among them, as stated in these RFCs, is the “Improved Support for Extensions and Options”. Specifically, it is described that “changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future”.

Whilst “greater flexibility” and “less stringent forwarding” are usually welcome from operational and interoperability perspective, typically they also introduce security implications. As several publications at security conferences or even RFCs has shown (see for example [RFC 7112]), IPv6 Extension Headers unfortunately is not an exception. These security implications become even more important when combined with fragmentation (but I will talk about them in another article).

In this article I will first refresh our memory by summarising the IPv6 Extension Headers concept. Despite my objective is not to discuss extensively and analyse the security implications themselves that arise from the support of IPv6 Extension Headers, I will summarise them briefly and I will point to the right publications.

In IPv6, the IPv6 header (from now on called IPv6 main header) has been simplified in comparison with IPv4 header, whilst its size is constant to 40 bytes (and cannot not vary, is it is the case of IPv4). However, IPv6 Extension headers have been introduced to allow the incorporation and usage of several options, only if and when needed. These IPv6 Extension headers, which can be none, one, or more, follow the IPv6 main header and come before the layer 4 header (e.g. TCP, or UDP) and its payload.

The IPv6 Extension headers are identified by their protocol number, which is used by the preceding header in the so called “Next header” (Nh) field to “point” to (i.e. to indicate) the next header. The protocol numbers of the IPv6 Extension headers are included in the IANA “Assigned Internet Protocol Numbers” list.

A few examples of how IPv6 header chains are constructed are given in the figure of Chapter 4 of [RFC 8200] and depicted below:

The case where IPv6 fragmentation is involved will be examined in a next article.

Each extension header is an integer multiple of 8 octets long, to retain 8-octet alignment for subsequent headers. A uniform format for IPv6 Extension Headers is defined in [RFC 6564]. Currently, all but the Fragment Extension header (which was defined earlier than [RFC 6564]) follow this uniform format, which is depicted below:

The “Next Header” filed identifies the type of header immediately following this extension header, while “Hdr Ext Len” filed provides the length of the extension header in 8-octet units, not including the first 8 octets.

A list of the currently defined IPv6 Extension headers, as summarised in [RFC 7045], along with the corresponding protocol numbers, is given below:

• IPv6 Hop-by-Hop Option, protocol number 0, currently defined in [RFC 8200].

• Routing Header for IPv6, protocol number 43, currently defined in [RFC 8200] (the currently defined types of routing headers can be found at “Internet Protocol Version 6 (IPv6) Parameters – Routing Types”).

• Fragment Header for IPv6, protocol number 44, currently defined in [RFC 8200].

• Encapsulating Security Payload, protocol number 50, currently defined in [RFC 4303].

• Authentication Header, protocol number 51, currently defined in [RFC 4302].

• Destination Options for IPv6, protocol number 60, [RFC 8200].

• Mobility Header, protocol number 135, currently defined in [RFC 6275].

• Host Identity Protocol Version 2, protocol number 139, currently defined in [RFC 7401].

• Shim6 Protocol, protocol number 140, defined in [RFC 5533].

• Use for experimentation and testing, protocol number 253, defined in [RFC 3692] and [RFC 4727].

• Use for experimentation and testing, protocol number 254, defined in [RFC 3692] and [RFC 4727].

This list excludes the next header type 59, called “No Next Header”, defined in [RFC 8200], which is not an extension header as such.

It should be noted that if the upper-layer header is another IPv6 header (in the case of IPv6 being tunnelled over or encapsulated in IPv6), it may be followed by its own extension headers (which are separately subject to the same ordering recommendations – see below).

The recommended IPv6 Extension header order is defined in [RFC 8200]. In a nutshell, “each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header)”. However, as it is also clearly stated in [RFC 8200], “IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only”.

It should also be noted that, as described in [RFC 8200], “Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches” its final destination (whilst “the Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path”, if a node is “explicitly configured to do so”).

At the destination node, extension headers must be processed strictly in the order they appear in the packet; the contents and semantics of each extension header determine whether or not to proceed to the next header.

If the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet (more details can be found in [RFC 8200]). The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header.

Further information regarding the transmission and processing of IPv6 Extension Headers can be found in [RFC 7045]...

As explained above, the introduction of Extension Headers into IPv6 introduces enormous flexibility in terms of the options that are or can be supported in the future. In a nutshell, their types, the formats of some of them and the rules of construction of the IPv6 header chain render the potential possibilities and combinations almost infinite.

The situation from a security perspective becomes even more complicated when considering that the rules governing the processing of the Extension Headers at recipient’s side follow closely the robustness principle (i.e. "be conservative in what you send, be liberal in what you accept from others").

Whilst it is not in the scope of this article to discuss and analyse the various security implications related with the abuse of IPv6 Extension Headers, these can mainly be summarised to the break of any type of signatures (e.g. Access Control Lists, IDS signatures) or similar control mechanisms in several security mechanisms (e.g. routers, IDS, or even firewalls).

For more, detailed information, the reader can refer to the following:

• A. Atlasis, “Security Impacts of Abusing IPv6 Extension Headers”, Abu Dhabi, Black Hat Asia, 2012.

• A. Atlasis, E. Rey, R. Schaefer, “Evasion of High-End IDPS Devices at the IPv6 Era”, Amsterdam, Black Hat Europe, 2014.

• F. Gont, V. Manral, R. Bonica, “Implications of Oversized IPv6 Header Chains”, IETF RFC 7112, 2004.