Each extension header, like the IPv6 header, has a Subsequent Header field.

Comparing the IPv6 Extension Headers in Figure 2-5 together with the IPv4 header in Figure 1.two, you could see that though the Source and Destination Address fields are each 4 times as long in the IPv6 extension header, the IPv6 header itself is just not that substantially bigger than an IPv4 header: 40 bytes for IPv6 versus a minimum of 20 bytes for IPv4. If substantial use is produced of the IPv4 Possibilities field, though uncommon, the IPv4 header can really be bigger than the IPv6 header.

Also notice that along with the Possibilities field, other fields which can be not generally used, which include 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 important for the forwarding of just about every packet, the IPv6 header is each compact and efficient.

But what should you do wish to use one particular of those optional IP functions, which include fragmentation or source routing or authentication? When an optional function is used in IPv6, an extension header suitable for the function is added after the packet header. If, as an example, source routing, fragmentation, and authentication possibilities are to become used, 3 extension headers formatted to carry the information essential for each of those functions are added as shown in Figure 2-6. As a result of these headers, efficiency is added to IPv6 packets in two methods:

The packet carries only the information expected by that individual packet. No unused fields are carried.
New optional functions is often added for the IPv6 packet by defining new extension headers.

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

image

Every extension header, like the IPv6 header, features a Next Header field. So each header tells which header follows it. Table 2-4 shows the at the moment defined extension headers and their subsequent header values. So, as an example, in Figure 2-7, the following Header value in the IPv6 header indicates that the following header is often a Routing extension header (43), that header's Next Header field indicates that the following header is often a Fragmentation extension header (44), and so on. The last extension header, AH, indicates that the following header is often a TCP header (Protocol Number six).

Table 2-4. Next Header values.

Header

Next Header Worth

Hop-By-Hop Possibilities

0

Routing

43

Fragment

44

Encapsulating Security Payload (ESP)

50

Authentication Header (AH)

51

Destination Possibilities

60

TCP/IP Protocols

Protocol number value defined for that protocol (which include TCP = six, 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.

image

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 just about every node along the forwarding path, which include Router Alert and Jumbo Payload possibilities.
Routingprovides source routing functionality by listing nodes that the packet will need to pass via on the technique to its destination.
Fragmentis used when a packet is fragmented, to offer the information important for the receiving node to reassemble the packet. A substantial distinction among IPv4 and IPv6 is that only originating nodes can fragment packets; IPv6 routers do not fragment the packets. So originating nodes will need to either use Path MTU Discovery (PMD) to locate the lowest MTU along a path for the destination, or in no way produce packets bigger than 1280 bytes. PMD is described in the subsequent section. IPv6 specifies that all links on which it runs must be able to help packet sizes of a minimum of 1280 bytes in order that originators can use the minimum-size choice as opposed to PMD if they so pick out.
Encapsulating Security Payload (ESP) is used when the payload is encrypted.
Authentication Header (AH) is used when the packet must be authenticated among the source and destination.
Destination Possibilities carries information to become 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're used, should really appear. The only hard-and-fast rule here is that if the Hop-By-Hop Possibilities header is used, it will need to directly follow the IPv6 header in order that it can be readily discovered by the transit nodes that will need to examine it. The recommended extension header order is as follows:

IPv6 Header
Hop-By-Hop Possibilities
Destination Possibilities (only if intermediate routers specified in the Routing header will need to examine this header)
Routing
Fragment
Authentication
Encapsulating Security Payload
Destination Possibilities (if only the final destination will need to examine this header)
Upper-Layer Header