In my last post, Staring at IPv6’s Prosthetic Head(ers), I introduced the IPv6 extension header. There’s a recent IETF draft that I’d like to explore in a blog entry (IPv6 Extension Headers in the Real World) but I wanted to make sure to first review the IPv6 extension header concept for myself and for readers. We’ll get to that draft next time around in part 3 but for now let’s finish our review of IPv6 extension headers by looking at the specific types that have been defined. (These definitions are summarized on the Internet Assigned Numbers Authority (IANA) site.)
Recall that extension headers in IPv6 were a design choice to help get rid of the variable length header in IPv4. Instead, “optional Internet-layer info is encoded into separate headers that may be placed between the IPv6 header and the upper-layer header in a packet” (RFC 2460). This kind of header chain allows for more than one header to be used to provide special treatment for a packet yet it maintains more optimal packet processing. Figure 1 illustrates an IPv6 packet with a single header followed by an IPv6 packet with a Routing extension header.
Figure 1: IPv6 Header and Extension Header example
While the extension header concept is flexible enough to allow for the definition of new headers for any purpose, there are a relatively small number of extension headers that have been defined (with a smaller subset of these actually in use in production networks).
These are:
- Hop-by-Hop Options header (sometimes shortened to HbH)
- Destination Options header
- Routing header
- Fragment header
- Authentication header
- Encapsulating Security Payload header
RFC 2460 recommends that if more than on extension header is used in the same packet, the particular order in the bullet list above should be preserved. This fixed and predictable order of header extensions enables faster packet processing.
Extension headers always fall on a 64-bit boundary and are always an integer multiple of 8 bits (which can result in padding of the header). This fixed boundary facilitates more optimal processing of the packet in hardware.
Let’s review each of the extension headers in more detail.
Hop-by-Hop Options header
Ever get on an elevator at the ground floor headed for your penthouse suite then had to stop at every floor along the way? Me neither (besides, I’m told, penthouse suites have their own private elevators), but you get the idea. The options in an HbH header (Figure 2) must be examined by every router in the path. Ostensibly, these options are included to indicate to the router what kind of special handling the packet should be receiving. Applications for this option include jumbogram support, MLD support, RSVP for IPv6, and the router alert option.
Figure 2: Hop-by-Hop Options header
The Next Header field is 8 bits. The Header Length field is next and contains 8 bits as well. It specifies the length of the Hop-by-Hop options header (minus the first byte). The Options field that follows contains one or more TLV(Type/Length/Value)-encoded options and is always some multiple of 8 bytes.
A Next Header value of 0 identifies the hop-by-hop options header.
Destination Options header
As the name suggests, this header includes options exclusively for the destination node. An application of destination options includes support for IPv6 mobility.
The Destination Options header looks just like the Hop-by-Hop Options header in Figure 2. It also contains 8-bit Next Header and Header Length fields as well as an mutliple-of-8-octets Options field with one or more TLV(Type/Length/Value)-encoded options.
A Next Header value of 60 identifies the Destination Options header.
Routing header
According to RFC 2460: “The Routing header [Figure 3] is used by an IPv6 source to list one or more intermediate nodes to be ‘visited’ on the way to a packet’s destination. This function is very similar to IPv4’s Loose Source and Record Route option.” (Remember our IPv4 “record route” example from the previous blog?).
Figure 3: Routing Header
You’ll recognize the Next Header and Header length field (identical to the ones above). But we also have two additional fields (Routing Type and Segments Left) as well as a type-specific data field.
The Routing Type field identifies the Routing header variant. The Segments Left field indicates the number of remaining intermediate nodes to visit before reaching the destination. Both fields are also 8 bits in length. The contents of the type specific data are implied by the Routing header variant identified in the Routing Type field.
A Next Header value of 43 identifies the routing header.
Fragment header
The Fragment Header (Figure 4) allows an IPv6 source to send packets bigger than what the path MTU permits.
Figure 4: Fragment header
The 8-bit Next Header field in this case “Identifies the initial header type of the Fragmentable Part of the original packet.” The 8-bit Reserved field is ignored. The Fragment Offset field is 13 bits and indicates the number of octets following the header. The next 2 bits are ignored and the 1-bit M flag indicates whether any more fragments follow.
A Next Header value of 44 identifies the fragment header.
(The fragmentation process is quite involved and takes up several pages of RFC 2460.)
Authentication header
The Authentication header (Figure 5) is used to provide data authentication, integrity, and protection against replays (i.e., retransmission of captured packets) of the IPv6 packet. The standard for it is specified in RFC 4302.
Figure 5: Authentication header
A Next Header value of 51 identifies the fragment header.
Encapsulating Security Payload header
The Encapsulating Security Payload header (Figure 6) is used to provide data confidentiality, authentication, integrity, and protection against replays for the encapsulated payload. The standard for it is specified in RFC 4303.
Figure 6: Encapsulating Security Payload header
A Next Header value of 50 identifies the Encapsulating Security Payload header.
Now that we’ve met the IPv6 extension headers, we can discuss their current status in the Real World™ of IPv6 operations. Stay tuned.
