8.6: IPv6 Extension Headers

Last updated
Save as PDF

Page ID: 11175

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

In IPv4, the IP header contained a Protocol field to identify the next header; usually UDP or TCP. All IPv4 options were contained in the IP header itself. IPv6 has replaced this with a scheme for allowing an arbitrary chain of supplemental IPv6 headers. The IPv6 Next Header field can indicate that the following header is UDP or TCP, but can also indicate one of several IPv6 options. These optional, or extension, headers include:

Hop-by-Hop options header
Destination options header
Routing header
Fragment header
Authentication header
Mobility header
Encapsulated Security Payload header

These extension headers must be processed in order; the recommended order for inclusion is as above. Most of them are intended for processing only at the destination host; the hop-by-hop and routing headers are exceptions.

8.5.1 Hop-by-Hop Options Header

This consists of a set of ⟨type,value⟩ pairs which are intended to be processed by each router on the path. A tag in the type field indicates what a router should do if it does not understand the option: drop the packet, or continue processing the rest of the options. The only Hop-by-Hop options provided by RFC 2460 [https://tools.ietf.org/html/rfc2460.html] were for padding, so as to set the alignment of later headers.

RFC 2675 [https://tools.ietf.org/html/rfc2675.html] later defined a Hop-by-Hop option to support IPv6 jumbograms: datagrams larger than 65,535 bytes. The need for such large packets remains unclear, in light of 5.3 Packet Size. IPv6 jumbograms are not meant to be used if the underlying LAN does not have an MTU larger than 65,535 bytes; the LAN world is not currently moving in this direction.

Because Hop-by-Hop Options headers must be processed by each router encountered, they have the potential to overburden the Internet routing system. As a result, RFC 6564 [https://tools.ietf.org/html/rfc6564.html] strongly discourages new Hop-by-Hop Option headers, unless examination at every hop is essential.

8.5.2 Destination Options Header

This is very similar to the Hop-by-Hop Options header. It again consists of a set of ⟨type,value⟩ pairs, and the original RFC 2460 [https://tools.ietf.org/html/rfc2460.html] specification only defined options for padding. The Destination header is intended to be processed at the destination, before turning over the packet to the transport layer.

Since RFC 2460 [https://tools.ietf.org/html/rfc2460.html], a few more Destination Options header types have been defined, though none is in common use. RFC 2473 [https://tools.ietf.org/html/rfc2473.html] defined a Destination Options header to limit the nesting of tunnels, called the Tunnel Encapsulation Limit. RFC 6275 [https://tools.ietf.org/html/rfc6275.html] defines a Destination Options header for use in Mobile IPv6. RFC 6553 [https://tools.ietf.org/html/rfc6553.html], on the Routing Protocol for Low-Power and Lossy Networks, or RPL, has defined a Destination (and Hop-by-Hop) Options type for carrying RPL data.

A complete list of Option Types for Hop-by-Hop Option and Destination Option headers can be found at www.iana.org/assignments/ipv6-parameters [http://www.iana.org/assignments/ipv6...-parameters-2]; in accordance with RFC 2780 [https://tools.ietf.org/html/rfc2780.html].

8.5.3 Routing Header

The original, or Type 0, Routing header contained a list of IPv6 addresses through which the packet should be routed. These did not have to be contiguous. If the list to be visited en route to destination D was ⟨R1,R2,…,Rn⟩, then this option header contained ⟨R2,R3,…,Rn,D⟩ with R1 as the initial destination address; R1 then would update this header to ⟨R1,R3,…,Rn,D⟩ (that is, the old destination R1 and the current next-router R2 were swapped), and would send the packet on to R2. This was to continue on until Rn addressed the packet to the final destination D. The header contained a Segments Left pointer indicating the next address to be processed, incremented at each Ri. When the packet arrived at D the Routing Header would contain the routing list ⟨R1,R3,…,Rn⟩. This is, in general principle, very much like IPv4 Loose Source routing. Note, however, that routers between the listed routers R1…Rn did not need to examine this header; they processed the packet based only on its current destination address.

This form of routing header was deprecated by RFC 5095 [https://tools.ietf.org/html/rfc5095.html], due to concerns about a traffic-amplification attack. An attacker could send off a packet with a routing header containing an alternating list of just two routers ⟨R1,R2,R1,R2,…,R1,R2,D⟩; this would generate substantial traffic on the R1–R2 link. RFC 6275 [https://tools.ietf.org/html/rfc6275.html] and RFC 6554 [https://tools.ietf.org/html/rfc6554.html] define more limited routing headers. RFC 6275 [https://tools.ietf.org/html/rfc6275.html] defines a quite limited routing header to be used for IPv6 mobility (and also defines the IPv6 Mobility header). The RFC 6554 [https://tools.ietf.org/html/rfc6554.html] routing header used for RPL, mentioned above, has the same basic form as the Type 0 header described above, but its use is limited to specific low-power routing domains.

8.5.4 IPv6 Fragment Header

IPv6 supports limited IPv4-style fragmentation via the Fragment Header. This header contains a 13-bit Fragment Offset field, which contains – as in IPv4 – the 13 high-order bits of the actual 16-bit offset of the fragment. This header also contains a 32-bit Identification field; all fragments of the same packet must carry the same value in this field.

IPv6 fragmentation is done only by the original sender; routers along the way are not allowed to fragment or re-fragment a packet. Sender fragmentation would occur if, for example, the sender had an 8 kB IPv6 packet to send via UDP, and needed to fragment it to accommodate the 1500-byte Ethernet MTU.

If a packet needs to be fragmented, the sender first identifies the unfragmentable part, consisting of the IPv6 fixed header and any extension headers that must accompany each fragment (these would include Hop-by-Hop and Routing headers). These unfragmentable headers are then attached to each fragment.

IPv6 also requires that every link on the Internet have an MTU of at least 1280 bytes beyond the LAN header; link-layer fragmentation and reassembly can be used to meet this MTU requirement (which is what ATM links (3.5 Asynchronous Transfer Mode: ATM) carrying IP traffic do).

Generally speaking, fragmentation should be avoided at the application layer when possible. UDP-based applications that attempt to transmit filesystem-sized (usually 8 kB) blocks of data remain persistent users of fragmentation.

8.5.5 General Extension-Header Issues

In the IPv4 world, many middleboxes (7.7.2 Middleboxes) examine not just the destination address but also the TCP port numbers; firewalls, for example, do this routinely to block all traffic except to a designated list of ports. In the IPv6 world, a middlebox may have difficulty finding the TCP header, as it must traverse a possibly lengthy list of extension headers. Worse, some of these extension headers may be newer than the middlebox, and thus unrecognized. Some middleboxes would simply drop packets with unrecognized extension headers, making the introduction of new such headers problematic.

RFC 6564 [https://tools.ietf.org/html/rfc6564.html] addresses this by requiring that all future extension headers use a common “type-length-value” format: the first byte indicates the extension-header’s type and the second byte indicates its length. This facilitiates rapid traversal of the extension-header chain. A few older extension headers – for example the Encapsulating Security Payload header of RFC 4303 [https://tools.ietf.org/html/rfc4303.html] – do not follow this rule; middleboxes must treat these as special cases.

RFC 2460 [https://tools.ietf.org/html/rfc2460.html] states

With one exception [that is, Hop-by-Hop headers], extension headers are not examined or processed by any node along a packet’s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.

Nonetheless, sometimes intermediate nodes do attempt to add extension headers. This can break Path MTU Discovery (12.13 Path MTU Discovery), as the sender no longer controls the total packet size.

RFC 7045 [https://tools.ietf.org/html/rfc7045.html] attempts to promulgate some general rules for the real-world handling of extension headers. For example, it states that, while routers are allowed to drop packets with certain extension headers, they may not do this simply because those headers are unrecognized. Also, routers may ignore Hop-by-Hop Option headers, or else process packets with such headers via a slower queue.