IPv6 Extension Headers

Unlike IPv4, IPv6 has a formal mechanism for adding extension packet headers. This mechanism is specified in RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification", December 1998. RFC 2460 also specifies five extension headers:

  • Hop-by-Hop Options Header (Type 0)
  • Destination Options Header (Type 60)
  •  Routing Header (Type 43)
  • Fragment Header (Type 44)
  • No Next Header

Of these, only the Fragment Header is really useful.

Two additional Extension Headers were specified in RFC xxx, "IPsec":

  • IPsec Authentication Extension Header
  • IPsec Encapsulated Security Payload Extension Header

 

Extension Header Options

The Hop-By-Hop Options Header and Destination Options Header have an options field that can contain one or more TLV (Type-Length-Value) encoded "options". Each option has three fields:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
|  Option Type  |  Opt Data Len |  Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
 
Option Type          8-bit identifier of the type of option.
 
Opt Data Len         8-bit unsigned integer.  Length of the Option
                     Data field of this option, in octets.
 
Option Data          Variable-length field.  Option-Type-specific
                     data.

The Option Type field contains a value encoded such that the two high order bits specify the action that the node must take if that node does not recognize the option type:

00 - skip over this option and continue processing the header.

01 - discard the packet.

10 - discard the packet and, regardless of whether or not the
     packet's Destination Address was a multicast address, send an
     ICMP Parameter Problem, Code 2, message to the packet's
     Source Address, pointing to the unrecognized Option Type.

11 - discard the packet and, only if the packet's Destination
     Address was not a multicast address, send an ICMP Parameter
     Problem, Code 2, message to the packet's Source Address,
     pointing to the unrecognized Option Type.

The third-highest-order bit of the Option Type specifies whether or not the Option Data of that Option can change en-route to the packet's final destination. When an IPsec Authentication Header is present in the packet, for any option whose data may change en-route, its entire Option Data field must be treated as zero-valued bytes when computing of verifying the packet's Authentication value.

0 - Option Data does not change en-route

1 - Option Data may change en-route

The three high-order bits are to be treated as part of the Option Type. This is, a particular option is identified by the full 8-bit value, not just the low-order 5 bits of an option type.

The same Option Type numbering space is used for both the Hop-by-Hop Options Header and the Destination Options Header. However, the specification of a particular option may restrict its use to only one of those two header types.

A given Option may have specific alignment requirements, to ensure that multi-byte values within Option Data fields fall on natural boundaries (e.g. 32-bit boundaries). The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type must appear at an integer multiple of "x" bytes from the start of the header, plus "y" bytes. For example, "2n" means any 2-byte offset from the start of the header. "8n+2" means any 8-byte offset from the start of the header, plus 2 bytes.

The two padding options available are the Pad1 and PadN.

Pad1 (no alignment requirement), is used to insert a single byte with the value 0.

+-+-+-+-+-+-+-+-+
|       0       |
+-+-+-+-+-+-+-+-+

PadN (no alignment requirement), is used to insert two or more bytes of padding into the Options field of an extension header. For N bytes of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 bytes of zero.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
|       1       |  Opt Data Len |  Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

 

Hop-by-Hop Options Header

This extension header allows you to specify things to be done at every hop along the way as the packet is forwarded towards its destination. This extension header is indicated by the Next Header field of the previous header containing the value 0. The syntax is as follows:

hop-by-hop ext header

The Next Header field (8 bits) specifies the type of the following header (another extension header, or ICMPv6/Transport Layer header). The possible values are the same as for the Next Header field of the basic IPv6 Packet Header.

The Hdr Ext Len field (8 bits) contains an unsigned integer. It specifies the length of the Extension Header in units of 8 bytes, not including the first 8 bytes. So a value of 0 means 8 bytes, 1 means 16 bytes, 2 means 24 bytes, etc. Since the options field begins at offset 2, a value of 0 means the options field is 6 bytes long, a value of 1 means the options field is 14 bytes long, etc.

The Options field (variable length) contains one or more TLV (Type-Length-Value) "options" (as defined above). In RFC 2460, the only options defined for this Extension Header are Pad1 and PadN.

 

Destination Options Header

This extension header allows you to specify actions to be performed only at the final destination node (not at any hops along the way). This extension header is indicated by the Next Header field of the previous header containing the value 60. The syntax is as follows:

dest options ext header

The Next Header field (8 bits) specifies the type of the following header (another extension header, or ICMPv6/Transport Layer header). The possible values are the same as for the Next Header field of the basic IPv6 Packet Header.

The Hdr Ext Len field (8 bits) contains an unsigned integer. It specifies the length of the Extension Header in units of 8 bytes, not including the first 8 bytes. So a value of 0 means 8 bytes, 1 means 16 bytes, 2 means 24 bytes, etc. Since the options field begins at offset 2, a value of 0 means the options field is 6 bytes long, a value of 1 means the options field is 14 bytes long, etc.

The Options field (variable length) contains one or more TLV (Type-Length-Value) "options" (as defined above). In RFC 2460, the only options defined for this Extension Header are Pad1 and PadN.

 

Routing Header

This extension header allows you to specify a list of IPv6 addresses that the packet must visit on the way to the final destination. It is similar to IPv4's Loose Source and Record Route option. This extension header is indicated by the Next Header field of the previous header containing the value 43. The syntax is as follows:

routing ext header

The Next Header field (8 bits) specifies the type of the following header (another extension header, or ICMPv6/Transport Layer header). The possible values are the same as for the Next Header field of the basic IPv6 Packet Header.

The Hdr Ext Len field (8 bits) contains an unsigned integer. It specifies the length of the Extension Header in units of 8 bytes, not including the first 8 bytes. So a value of 0 means 8 bytes, 1 means 16 bytes, 2 means 24 bytes, etc. Since the options field begins at offset 2, a value of 0 means the options field is 6 bytes long, a value of 1 means the options field is 14 bytes long, etc.

The Routing Type field (8 bits) specifies a particular Routing Header variant. Only one variant is defined in RFC 2460 (Type 0).

The Segments Left field (8 bits) contains the number of nodes still to be visited before resuming normal routing.

The Type Specific Data field (variable length) contains information specific to the Routing Header Variant.

A Type 0 Routing Header specifies a list of one or more IPv6 addresess to be visited in order, before normal routing resumes. The addresses are listed in order in the Type Specific Data field, starting at offset 8 in the Routing Header. The number of nodes to visit is specified in the Segments Left field. This contents of this field is decremented by one as it visits each node. When this value reaches zero, normal routing takes back over.

As an example of the effects of the above algorithm, consider the case of a source node S sending a packet to destination node D, using a Routing header to cause the packet to be routed via intermediate nodes I1, I2, and I3.  The values of the relevant IPv6 header and Routing header fields on each segment of the delivery path would be
as follows.

You create the packet with the address list in the Type-Specific Data field containing the second hop address (I2), third hop address (I3), and then the final destination address (D). You send the packet to the first hop address (I1).

When node I1 receives the packet, it swaps the first address in the list (I2) with the destination address from the incoming packet (its own address) and sends the packet to the new destination address (I2).

When node I2 receives the packet, it swaps the second address in the list (I3) with the destination address from the incoming packet (its own address) and sends the packet to the new destination address (I3).

When node I3 receives the packet, it swaps the third address in the list (the final destination) with the destination address from the incoming packet (its own address) and sends the packet to the new destination address (the final destination, D).

When the packet arrives at the final destination, the address list contains a history of the nodes that it visited, in the order it visited them. The source address remains that of the original sender through all of this.

   As the packet travels from S to I1:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I1            Segments Left = 3
                                            Address[1] = I2
                                            Address[2] = I3
                                            Address[3] = D

   As the packet travels from I1 to I2:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I2            Segments Left = 2
                                            Address[1] = I1
                                            Address[2] = I3
                                            Address[3] = D

   As the packet travels from I2 to I3:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I3            Segments Left = 1
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = D

   As the packet travels from I3 to D:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = D             Segments Left = 0
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = I3

 

Fragment Header

This extension header is used to fragment packets, in a manner similar to fragmentation in IPv4. Unlike IPv4, only the original sending node is allowed to fragment a packet. This extension header is indicated by the Next Header field of the previous header containing the value 44. The syntax is as follows:

fragment ext header

The Next Header field (8 bits) specifies the type of the following header (another extension header, or ICMPv6/Transport Layer header). The possible values are the same as for the Next Header field of the basic IPv6 Packet Header.

The Reserved field is set to zero on transmit, and ignored on receipt.

The Fragment Offset field (13 bits) contains an unsigned integer. This is the offset, in 8 byte units of where the first byte of this fragment goes in the reassembled packet buffer. This is exactly the same function as the Fragment Offset in the IPv4 Packet Header. The Fragment Offset of the first fragment is zero. It should not result in any overlapping or unspecified regions in the reconstructed fragment (the fragments should be adjacent and non-overlapping).

The Res field (2 bits) is set to zero on transmit, and ignored on receipt.

The M flag is set to 1 if there are more fragments coming, and 0 if this is the last fragment. Since the Fragment header is used only when you have fragmented a packet, it cannot indicate the only fragment of an unfragmented packet (as it does in IPv4). Also, the DF flag from the IPv4 Packet Header is not used here, because in effect it is always set (only the original send can fragment a packet).

The Identification field (32 bits) contains the same value for all fragments of a given original packet, but each original unfragmented packet must use a unique Identification field for all of its packets (or at least a value that has not been used "recently". Typically the Identification field is started at some value and incremented by 1 (modulo 232) for each new original packet. This is the same functionality as the Identification field in the IPv4 Packet Header.

The first part of the original packet (containing at least the basic IPv6 Packet Header, plus all extension headers that must be processed by nodes en-route to the final destination) is called the "unfragmentable" part of the packet. Anything after those fields can be fragmented. Each packet fragment sent contains the unfragmentable part of the orginnal packet, followed by the Fragment Header, followed by the current fragment. The Payload Length field of the basic IPv6 Packet Header (in the unfragmentable part) indicates the length of this fragment packet (minus 40 bytes for the basic IPv6 packet header). The last header of the unfragmentable part is changed to 44. The old Next Header from the final header in the unfragmentable part is copied into the Next Header field of the Fragment Header.

 

No Next Header

If the Next Header field in either the Basic IPv6 Packet Header or any extenion header contains the value 59, then nothing should follow that packet header. If anything is included after that, it should be ignored.