Extension Headers

Comparing the IPv6 header in Figure 2-5 with the IPv4 header in Figure 1.2, you can see that although the Source and Destination Address fields are each four times as long in the IPv6 header, the IPv6 header itself is not that much larger than an IPv4 header: 40 bytes for IPv6 versus a minimum of 20 bytes for IPv4. If extensive use is made of the IPv4 Options field, although unusual, the IPv4 header can actually be larger than the IPv6 header.

Also notice that in addition to the Options field, other fields that are not always used, such as those associated with fragmentation, are eliminated from the IPv6 header. So given its fixed length and exclusion of all fields that do not carry information necessary for the forwarding of every packet, the IPv6 header is both compact and efficient.

But what if you do want to use one of those optional IP features, such as fragmentation or source routing or authentication? When an optional function is used in IPv6, an extension header appropriate for the function is added after the packet header. If, for example, source routing, fragmentation, and authentication options are to be used, three extension headers formatted to carry the information needed for each of those functions are added as shown in Figure 2-6. Because of these headers, efficiency is added to IPv6 packets in two ways:

• The packet carries only the information required by that individual packet. No unused fields are carried.

• New optional functions can be added to the IPv6 packet by defining new extension headers.

Figure 2-6. Extension headers allow IPv6 packets to carry all the information required for that packet, but only the information required for that packet.

Each extension header, like the IPv6 header, has a Next Header field. So each header tells which header follows it. Table 2-4 shows the currently defined extension headers and their next header values. So, for example, in Figure 2-7, the Next Header value in the IPv6 header indicates that the next header is a Routing extension header (43), that header's Next Header field indicates that the next header is a Fragmentation extension header (44), and so on. The last extension header, AH, indicates that the next header is a TCP header (Protocol Number 6).

Table 2-4. Next Header values.

Header	Next Header Value
Hop-By-Hop Options	0
Routing	43
Fragment	44
Encapsulating Security Payload (ESP)	50
Authentication Header (AH)	51
Destination Options	60
TCP/IP Protocols	Protocol number value defined for that protocol (such as TCP = 6, UDP = 17, OSPF = 89, and so on)
No Next Header	59

Figure 2-7. The Next Header field in the IPv6 header and each extension header specifies which header follows it.

The format of each of the extension headers is described in RFC 1883. But briefly, the function of each extension header is as follows:

• Hop-By-Hop Optionscarries information that must be examined by every node along the forwarding path, such as Router Alert and Jumbo Payload options.

• Routingprovides source routing functionality by listing nodes that the packet must pass through on the way to its destination.

• Fragmentis used when a packet is fragmented, to provide the information necessary for the receiving node to reassemble the packet. A significant difference between IPv4 and IPv6 is that only originating nodes can fragment packets; IPv6 routers do not fragment the packets. So originating nodes must either use Path MTU Discovery (PMD) to find the lowest MTU along a path to the destination, or never produce packets larger than 1280 bytes. PMD is described in the next section. IPv6 specifies that all links on which it runs must be able to support packet sizes of at least 1280 bytes so that originators can use the minimum-size option rather than PMD if they so choose.

• Encapsulating Security Payload (ESP) is used when the payload is encrypted.

• Authentication Header (AH) is used when the packet must be authenticated between the source and destination.

• Destination Options carries information to be examined only by the destination node or possibly by nodes listed in the Routing header.

RFC 1883 also specifies the order in which extension headers, if they are used, should appear. The only hard-and-fast rule here is that if the Hop-By-Hop Options header is used, it must directly follow the IPv6 header so that it can be easily found by the transit nodes that must examine it. The recommended extension header order is as follows:

1. IPv6 Header

2. Hop-By-Hop Options

3. Destination Options (only if intermediate routers specified in the Routing header must examine this header)

4. Routing

5. Fragment

6. Authentication

7. Encapsulating Security Payload

8. Destination Options (if only the final destination must examine this header)

9. Upper-Layer Header