• Hop by hop option header
• Routing header
• Destination option header
• Fragmentation header
• Authentication header and Encrypted Security Payload header

The IPv4 options field was dropped, as it is infrequently used because of the complications it introduces: using the options increases IPv4 packet processing time, since each router crossed must process all of the options before forwarding the packet.
The extension header mechanism was developed to satisfy the need to specify options more efficiently than in the past. For the moment, six extension headers have been specified, though others may be added in the future. Extension headers are placed immediately after the IPv6 header: thus, for the routers that do not have to process them, they are part of the packet payload and are not analyzed. This improves forwarding performance.

Figure 4 - Header chain.
As shown in Figurere 4, each packet can contain more than one header, while each header must specify the type of header which follows it in the next header field, forming what is known as the "header chain". The order indicated below must be respected in forming this chain:

• IPv6 header
  
• hop by hop option header
  
• destination option header
  
• routing header
  
• fragmentation header
  
• authentication header
  
• encrypted security payload header
  
• destination option header
  
• upper layer header (e.g., TCP o UDP).

The destination option header can appear in two distinct positions.

The hop by hop option header must be processed by each node crossed by the packet. Format is shown in Figurere 5, where it will be noted that that the option field can vary in length. Consequently, its length must be specified in hdr ext len. Option format is illustrated in Figurere 6: each option must begin with an 8-bit field which specifies the type, followed by an 8-bit field for length.

The options that can involve all nodes along the path are generally associated with management or debugging functions. The following hop-by-hop options have been specified to date:

• Two padding options used to ensure 64-bit data alignment (type=0)
  
• Payload jumbogram option (type=194)
  
• Router Alert option. This generic option notifies the router that the packet concerned contains specific information that must be carefully examined. An example of a situation where this option can be useful is provided by the RSVP protocol, where the source needs to preempt a path for the packets it generates. The format is shown in Figurere 7.

The routing header is used by a source to list the set of nodes that a packet must cross before reaching its destination. It is identified by a next header value of 43 in the immediately preceding header.
The format of this extension header is shown in Figurere 8. The Routing Type field can be used to specify more than one variant for this header. For each type, different data will be entered in the type-specific data field. The only case which has been specified at the moment is that illustrated in Figurere 9, where the Routing Type is zero. In this case, the segment left field indicates the number of route segments still to be visited before reaching the final destination, the reserved field (32-bit) is not yet used, and Address [1..n] is the list of addresses to be visited along the path.

When this type of routing header is used, the initial IPv6 header contains the first address in the list as its destination address. At each hop, the intermediate node replaces it with that of the next one in the list and decrements segment left.
This type of routing header derives from the IPv4 source routing option, though the latter also makes it possible to specify whether the packet will be sent directly (and only) to the node with that address (strict routing), or can also go through intermediate routers (loose routing). For IPv6, it was decided not to specify this choice between strict and loose, as it is not readily implemented in practice, especially where tunnels are involved. For routing

purposes, in fact, tunnels count as a single hop even if more than one router is crossed. Consequently, whether the end of a tunnel is considered strict or loose is purely subjective.

Format is the same as that of the hop by hop extension header, as options are also specified in this case (see Figurere 5). This is the only extension header that can appear twice in the same packet, though in two different positions.
If it is placed before the routing header, it will be processed by the first node appearing in the IPv6 header's Destination field. In all other cases, it will be visible only at the ends. For the moment, only two padding options have been specified in order to pad out packets to a multiple of 64 bytes in length.

One of the innovations introduced by IPv6 is the elimination of hop by hop packet fragmentation. With the new protocol, fragmentation is managed at the ends by means of a special extension header.
If a packet is too large to fit in the maximum MTU for the link on which this packet must be transmitted, the node discards it and sends an ICMP error message back to the source.
If a datagram must be sent whose payload exceeds the size permitted for the link concerned by the MTU value, IPv6 enables the source station to fragment the packet. Using the fragmentation header permits the destination to reassemble the packet correctly.
The fragmentation header format is illustrated in Figurere 10.

Each packet consists of an unfragmentable part and a fragmentable part, as shown in Figurere 11. The unfragmentable part includes the IPv6 header and the other headers that must be processed by each node, and must be repeated identically for each fragment. There are two exceptions: it is necessary to update the payload length and the last Next Header , which must now indicate that the Fragment Header is present.

IPv6 provides a standard authentication and end-to-end encryption service by means of two extension headers whose format is shown in Figures 13 and 14.
The Authentication Header (AH) is designed to guarantee the authenticity and integrity of the packet in which it is placed, or in other words to check whether this packet was changed en route or was generated by someone who is not authorized to access the resource involved.
By contrast, the Encrypted Security Payload header (ESP) provides a mechanism for handling data in such a way that they can be read only at the end of the route.
In both cases, source and destination must agree on the secret key and algorithm to be used, and on the values to be assigned to the latter's parameters. Together, this information forms a Security Association, or SA, identified by the SPI (security parameter index) field along with the source and destination addresses.
Negotiating a security association is an integral part of the key exchange protocol.
IPv6 implementations must support the MD5 algorithm for authentication and integrity control, and DES_CBC as an encryption algorithm. As the specifications are not dependent on these algorithms, however, other techniques can be used once the security association has been established.

The length of the authentication data field can vary on the basis of the selected authentication algorithm (see Figure 13). This field contains the authentication value generated by the sender, corresponding to the result of a computation using the secret key, the data field and the IP packet header as data. Upon receiving a packet with the AH authentication header, the destination computes the authentication value in the same way it was computed by the source, and compares it with the received value. If the two values are the same, the packet has not been modified or tampered with, and the sender is authentic.
It is important to note that both the source and the destination perform computation on the standardized IP packet, to which the secret key is concatenated. A packet is said to be standardized when the next hop and all of the options that must be changed in transit are set to zero, and the Routing Header (where present) is set to the value it will have at destination.
ESP is the extension header that carries the parameters and keys used for end-to-end encryption.
When used, it must be the last header in the chain, as it completely conceals both the higher-layer data and the headers following it.
There are two possible choices: transport mode and tunnel mode (see Figure 15 ). In the first case, only the IPv6 packet payload is encrypted. If a higher degree of security is required, it is possible to use the tunnel mode, where the entire packet is encrypted and then encapsulated in another packet. In this way, it is visible only at the ends, which makes for higher encryption effectiveness but also increases overhead.