IPv6 Extension Headers

The IPv4 header includes all options. Therefore, each intermediate router must check for their existence and process them when present. This can cause performance degradation in the forwarding of IPv4 packets. With IPv6, delivery and forwarding options are moved to extension headers. The only extension header that must be processed at each intermediate router is the Hop-by-Hop Options extension header. This increases IPv6 header processing speed and improves the performance of forwarding IPv6 packets.

RFC 2460 specifies that the following IPv6 extension headers must be supported by all IPv6 nodes:

• Hop-by-Hop Options header
• Destination Options header
• Routing header
• Fragment header
• Authentication header
• Encapsulating Security Payload header

With the exception of the Authentication header and Encapsulating Security Payload header, all the above IPv6 extension headers are defined in RFC 2460.

In a typical IPv6 packet, no extension headers are present. If special handling is required by either intermediate routers or the destination, the sending host adds one or more extension headers.

Each extension header must fall on a 64-bit (8-byte) boundary. Extension headers of a fixed size must be an integral multiple of 8 bytes. Extension headers of variable size contain a Header Extension Length field and must use padding as needed to ensure that their size is an integral multiple of 8 bytes.

The Next Header field in the IPv6 header and zero or more extension headers form a chain of pointers. Each pointer indicates the type of header that comes after the immediate header until the upper-layer protocol is ultimately identified. Figure 4-4 shows the chain of pointers formed by the Next Header field for various IPv6 packets.

Figure 4-4. The chain of pointers formed by the Next Header field

Extension Headers Order

Extension headers are processed in the order in which they are present. Because the only extension header that is processed by every node on the path is the Hop-by-Hop Options header, it must be first. There are similar rules for other extension headers. In RFC 2460, it is recommended that extension headers be placed after the IPv6 header in the following order:

1. Hop-by-Hop Options header
2. Destination Options header (for intermediate destinations when the Routing header is present)
3. Routing header
4. Fragment header
5. Authentication header
6. Encapsulating Security Payload header
7. Destination Options header (for the final destination)

Hop-by-Hop Options Header

The Hop-by-Hop Options header is used to specify delivery parameters at each hop on the path to the destination. It is identified by the value of 0 in the IPv6 header's Next Header field. Figure 4-5 shows the structure of the Hop-by-Hop Options header.

Figure 4-5. The structure of the Hop-by-Hop Options header

The Hop-by-Hop Options header consists of a Next Header field, a Header Extension Length field, and an Options field that contains one or more options. The value of the Header Extension Length field is the number of 8-byte blocks in the Hop-by-Hop Options extension header, not including the first 8 bytes. Therefore, for an 8-byte Hop-by-Hop Options header, the value of the Header Extension Length field is 0. Padding options are used to ensure 8-byte boundaries.

An IPv6 Router Optimization

The interpretation of the Header Extension Length field in the Hop-by-Hop Options header is another example of how the designers of IPv6 wanted to optimize processing of IPv6 packets at intermediate routers. For those packets with a Hop-by-Hop Options header, one of the first operations is to determine the size of the header. If the Header Extension Length field were defined to be the number of 8-byte blocks in the header, its minimum value would be 1 (the minimum-sized Hop-by-Hop Options header is 8 bytes long). To ensure robustness in an IPv6 forwarding implementation, a field whose valid values begin at 1 would have to be checked for the invalid value of 0 before additional processing could be done.

With the current definition of the Header Extension Length field, 0 is a valid value and no testing of invalid values needs to be done. The number of bytes in the Hop-by-Hop Options header is calculated from the following formula: (header extension length + 1) x 8.

An option is a set of fields that either describes a specific characteristic of the packet delivery or provides padding. Options are sent in the Hop-by-Hop Options header and Destination Options header (described later in this chapter). Each option is encoded in the type-length-value (TLV) format that is commonly used in TCP/IP protocols. Figure 4-6 shows the structure of an option.

Figure 4-6. The structure of an option

The Option Type field both identifies the option and determines the way it is handled by the processing node. The Option Length field indicates the number of bytes in the option, not including the Option Type and Option Length fields. The option data is the specific data associated with the option.

An option might have an alignment requirement to ensure that specific fields within the option fall on desired boundaries. For example, it is easier to process an IPv6 address if it falls on an 8-byte boundary. Alignment requirements are expressed by using the notation xn + y, indicating that the option must begin at a byte boundary equal to an integral multiple of x bytes plus y bytes from the start of the header. For example, the alignment requirement 4n + 2 indicates that the option must begin at a byte boundary of (an integral multiple of 4 bytes) + 2 bytes. In other words, the option must begin at the byte boundary of 6, 10, 14, and so on, relative to the start of the Hop-by-Hop Options or Destination Options headers. To accommodate alignment requirements, padding typically appears before an option and appears between each option when multiple options are present.

Option Type Field

Within the Option Type field, the two high-order bits indicate how the option is handled when the node processing the option does not recognize the option type. Table 4-3 lists the defined values of these two bits and their purpose.

Table 4-3. Values of the Two High-Order Bitsin the Option Type Field

Value (Binary)	Action Taken
00	Skip the option
01	Silently discard the packet
10	Discard the packet and send an ICMPv6 ParameterProblem message to the sender if the Destination Address field in the IPv6 header is a unicast or multicast address
11	Discard the packet and send an ICMPv6 ParameterProblem message to the sender if the Destination Address field in the IPv6 header is not a multicast address

The third-highest-order bit of the Option Type indicates whether the option data can change (= 1) or not change (= 0) in the path to the destination.

Pad1 Option

The Pad1 option is defined in RFC 2460 and is used to insert a single byte of padding so that the Hop-by-Hop Options or Destination Options headers fall on 8-byte boundaries and to accommodate the alignment requirements of options. The Pad1 option has no alignment requirements. Figure 4-7 shows the Pad1 option.

Figure 4-7. The structure of the Pad1 option

The Pad1 option consists of a single byte; Option Type is set to 0, and it has no length or value fields. With Option Type set to 0, the option is skipped if not recognized and it is not allowed to change in transit.

PadN Option

The PadN option is defined in RFC 2460 and is used to insert two or more bytes of padding so that the Hop-by-Hop Options or Destination Options headers fall on 8-byte boundaries and to accommodate the alignment requirements of options. The PadN option has no alignment requirements. Figure 4-8 shows the PadN option.

Figure 4-8. The structure of the PadN option

The PadN option consists of the Option Type field (set to 1), the Length field (set to the number of padding bytes present), and 0 or more bytes of padding. With the Option Type field set to 1, the option is skipped if not recognized and it is not allowed to change in transit.

Jumbo Payload Option

The Jumbo Payload option is defined in RFC 2675 and is used to indicate a payload size that is greater than 65,535 bytes. The Jumbo Payload option has the alignment requirement of 4n + 2. Figure 4-9 shows the Jumbo Payload option.

Figure 4-9. The structure of the Jumbo Payload option

With the Jumbo Payload option, the Payload Length field in the IPv6 header no longer indicates the size of the IPv6 packet payload. Instead, the Jumbo Payload Length field in the Jumbo Payload option indicates the size, in bytes, of the IPv6 packet payload. With a 32-bit Jumbo Payload Length field, payload sizes of up to 4,294,967,295 bytes can be indicated. An IPv6 packet with a payload size greater than 65,535 bytes is known as a jumbogram. With the Option Type field set to 194 (0xC2 hexadecimal, binary 11000010), the packet is discarded and an ICMPv6 Parameter Problem message is sent if the option is not recognized and the destination address is not a multicast address, and the option is not allowed to change in transit. Microsoft implementations of IPv6 do not support the use of jumbograms.

Router Alert Option

The Router Alert option (Option Type 5) is defined in RFC 2711 and is used to indicate to a router that the contents of the packet require additional processing. The Router Alert option has the alignment requirement of 2n + 0. Figure 4-10 shows the structure of the Router Alert option.

Figure 4-10. The structure of the Router Alert option

The Router Alert option is used for Multicast Listener Discovery (MLD) and the Resource ReSerVation Protocol (RSVP). With the Option Type field set to 5, the option is skipped if not recognized and it is not allowed to change in transit.

Network Monitor Capture

Here is an example of a Hop-by-Hop Options header as displayed by Network Monitor (capture 04_02 in the \NetworkMonitorCaptures folder on the companion CD-ROM):

 + Frame: Base frame properties + ETHERNET:  EType = IPv6    IP6: Hop Opts; Proto = ICMP6; Len = 24       IP6: Version = 6 (0x6)       IP6: Traffic Class = 0 (0x0)       IP6: Flow Label = 0 (0x0)       IP6: Payload Length = 32 (0x20)       IP6: Next Header = 0 (Hop-by-Hop Options Header)       IP6: Hop Limit = 1 (0x1)       IP6: Source Address = fe80::2b0:d0ff:fee9:4143       IP6: Destination Address = ff02::1:ffe9:4143       IP6: Hop-by-Hop Options Header           IP6: Next Header = 58 (ICMP6)           IP6: Length = 0 (0x0)           IP6: Router Alert Option               IP6: Type = 5                   IP6: 00...... = Skip option if not recognized                   IP6: ..0..... = Option data does not change enroute               IP6: Length = 2 (0x2)               IP6: Router Alert Value = 0 (0x0)           IP6: Padding (2 bytes)               IP6: Type = 1 (PadN)                   IP6: 00...... = Skip option if not recognized                   IP6: ..0..... = Option data does not change enroute               IP6: Length = 0 (0x0)       IP6: Payload: Number of data bytes remaining = 24 (0x0018) + ICMP6: Multicast Listener Report 

Notice the use of the Router Alert option (option type 5) and the PadN option (option type 1) to pad the entire Hop-by-Hop Options header to 8 bytes (1-byte Next Header field + 1-byte Option Length field + 4-byte Router Alert option + 2-byte PadN option).

Destination Options Header

The Destination Options header is used to specify packet delivery parameters for either intermediate destinations or the final destination. This header is identified by the value of 60 in the previous header's Next Header field. The Destination Options header has the same structure as the Hop-by-Hop Options header, as shown in Figure 4-11.

Figure 4-11. The structure of the Destination Options header

The Destination Options header is used in two ways:

1. If a Routing header is present, it specifies delivery or processing options at each intermediate destination. In this case, the Destination Options header occurs before the Routing header.
2. If no Routing header is present, or if this header occurs after the Routing header, this header specifies delivery or processing options at the final destination.

Binding Update Option

The Binding Update destination option (Option Type 198) is defined in the Internet draft titled "Mobility Support in IPv6" and is used by a mobile IPv6 node to update another node with its new care-of address. The Binding Update option in the Destination Options header (for the final destination) can be included in an existing packet sent to the destination or in a packet that contains just the Destination Options header. In the latter case, the Next Header field in the Destination Options header is set to 59, indicating no next header. The Binding Update option has the alignment requirement of 4n + 2. Figure 4-12 shows the structure of the Binding Update option.

Figure 4-12. The structure of the Binding Update option

The fields in the Binding Update option are:

• Option Type

  With the Option Type field set to 198 (0xC6 hexadecimal, 11000110 binary), the packet is discarded and an ICMPv6 Parameter Problem message is sent if the option is not recognized and the destination address is not a multicast address, and the option is not allowed to change in transit.

• Option Length

  The Option Length field indicates the length of the option in bytes, not including the Option Type and Option Length fields. The Option Length field includes the sub-options, if present.

• Flags

  As defined in version 13 of the Internet draft "Mobility Support in IPv6," there are four 1-bit flags as follows (starting from the high-order bit):

  • Acknowledge (A): Set to indicate that the sender is requesting a binding acknowledgement.
  • Home Registration (H): Set to indicate that the sender is requesting the receiver to be the mobile node's home agent.
  • Router (R): Set to indicate that the mobile node is a router. This flag can be set only if the Home Registration (H) flag is also set.
  • Duplicate Address Detection (D): Set to indicate that the sender is requesting the receiver to perform duplicate address detection for the mobile node's home address. This flag can be set only if the Acknowledge (A) and Home Registration (H) flags are also set.
• Reserved

  The Reserved field contains reserved bits that are set to 0. The size of this field is 4 bits.

• Prefix Length

  The Prefix Length field indicates the length of the subnet prefix in the Home Address field in the Home Address destination option (described later in this chapter). A binding update includes both the Binding Update and Home Address options. The remaining low-order bits in the Home Address option's Home Address field are the interface identifier of the mobile node's home address. The home agent uses this interface identifier to determine all the types of addresses used on the home link (such as link-local, site-local, and global), and performs duplicate address detection if indicated. The Prefix Length field is set only when the Home Registration (H) flag is also set. The size of this field is 8 bits.

• Sequence Number

  The Sequence Number field indicates the sequence of the binding update and is used by the mobile node to match a binding update with a corresponding binding acknowledgement. The size of this field is 16 bits.

• Lifetime

  The Lifetime field indicates the number of seconds that the binding is valid. A value of 0xFFFFFFFF indicates infinity. A value of 0 indicates that the binding is invalid and must be deleted. The size of this field is 32 bits.

• Sub-Options

  Sub-options can include additional optional information and allow the binding update to be extended in the future. Sub-options use the TLV format, in the same way that options do. The current sub-options defined for the Binding Update option are:

  • The Unique Identifier sub-option consists of an 8-bit Type field (set to 2), an 8-bit Length field (set to 2), and a 16-bit Unique Identifier field. The Unique Identifier sub-option is used to match a binding update with a binding request.
  • The Alternate Care-of Address sub-option consists of an 8-bit Type field (set to 4), an 8-bit Length field (set to 16), and a 128-bit Alternate Care-of Address field. The Alternate Care-of Address sub-option is included when the mobile node wants to indicate a care-of address that is different from the source address of the packet containing the binding update.

Binding Acknowledgement Option

The Binding Acknowledgement destination option (Option Type 7) is defined in the Internet draft titled "Mobility Support in IPv6" and is used to acknowledge the receipt of a binding update (a packet that contains the Binding Update option) when the Acknowledge (A) flag is set. Like the Binding Update option, the Binding Acknowledgement option can be included in an existing packet being sent to the mobile node or in a packet that contains just the Destination Options header. The Binding Acknowledgement option has the alignment requirement of 4n + 3. Figure 4-13 shows the structure of the Binding Acknowledgement option.

Figure 4-13. The structure of the BindingAcknowledgement option

The fields in the Binding Acknowledgement option are:

• Option Type

  With the Option Type field set to 7 (binary 00000111), the option is skipped if not recognized and is not allowed to change in transit.

• Option Length

  The Option Length field indicates the length of the option in bytes, not including the Option Type and Option Length fields. The Option Length field includes the sub-options, if present.

• Status

  The Status field indicates the status of the binding update. Status field values less than 128 indicate successful acceptance of the binding update by the receiving node. Status field values greater than 127 indicate failure of the binding update. The size of this field is 8 bits. Table 4-4 lists the values of the Status field defined in version 13 of the Internet draft titled "Mobility Support in IPv6."

Table 4-4. Values of the Status Field

Status Field Value (Decimal)	Description
0	Binding update accepted
128	Reason unspecified
130	Administratively prohibited
131	Insufficient resources
132	Home registration not supported
133	Not home subnet
136	Incorrect interface identifier length
137	Not home agent for this mobile node
138	Duplicate address detection failed

• Sequence Number

  The Sequence Number field indicates the binding update forthis binding acknowledgement and is set to the Sequence Number field in the received Binding Update option. The size of this field is 16 bits.

• Lifetime

  The Lifetime field indicates the number of seconds that the sending node will maintain the binding for the mobile node. If the sending node is the mobile node's home agent, the Lifetime field also indicates the number of seconds the sending node is the home agent. This field is relevant only if the binding update was received successfully. The size of this field is 32 bits.

• Refresh

  The Refresh field indicates an interval, in seconds, at which the mobile node should update its binding with the sending node. This field is relevant only if the binding update was successfully received. The size of this field is 32 bits.

• Sub-Options

  Sub-options can include additional optional information and allow the binding acknowledgement to be extended in the future. There are currently no sub-options defined for the Binding Acknowledgement option.

Binding Request Option

The Binding Request destination option (Option Type 8) is defined in the Internet draft titled "Mobility Support in IPv6" and is used to request the binding from a mobile node. Like the Binding Update option, the Binding Request option can be included in an existing packet being sent to the mobile node or in a packet that contains just the Destination Options header. The Binding Request option has no alignment requirements. Figure 4-14 shows the structure of the Binding Request option.

Figure 4-14. The structure of the Binding Request option

The fields in the Binding Request option are:

• Option Type

  With the Option Type field set to 8 (binary 00001000), the option is skipped if not recognized and is not allowed to change in transit.

• Option Length

  Indicates the length of the option in bytes, not including the Option Type and Option Length fields. The Option Length field includes the sub-options, if present. The presence of sub-options is detected through the value of the Option Length field. If the Option Length field is greater than 0, sub-options are present.

• Sub-Options

  Sub-options can include additional optional information and allow the binding request to be extended in the future. The only sub-option defined for the binding request is the Unique Identifier sub-option, which is used to match a binding request to a binding update.

Home Address Option

The Home Address destination option (Option Type 201) is defined in the Internet draft titled "Mobility Support in IPv6" and is used to indicate the home address of the mobile node. The Home Address option is included in the binding update. The Home Address option has the alignment requirement of 8n + 6. Figure 4-15 shows the structure of the Home Address option.

Figure 4-15. The structure of the Home Address option

The fields in the Home Address option are:

• Option Type

  With the Option Type field set to 201 (0xC9 hexadecimal, 11001001 binary), the packet is discarded and an ICMPv6 Parameter Problem message is sent if the option is not recognized and the destination address is not a multicast address, and the option is not allowed to change in transit.

• Option Length

  The Option Length field indicates the length of the option in bytes, not including the Option Type and Option Length fields. The Option Length field includes the sub-options, if present. The presence of sub-options is detected through the value of the Option Length field. If the Option Length field is greater than 16, sub-options are present.

• Home Address

  The Home Address field indicates the home address of the mobile node. The size of this field is 128 bits.

• Sub-Options

  Sub-options can include additional optional information and allow the Home Address option to be extended in the future. There are currently no sub-options defined for the Home Address option.

Network Monitor Capture

Here is an example of the Home Address option in the DestinationOptions header as displayed by Network Monitor (capture 04_03 in the \NetworkMonitorCaptures folder on the companion CD-ROM):

 + Frame: Base frame properties + ETHERNET:  EType = IPv6    IP6: Dest Opts; Len = 0       IP6: Version = 6 (0x6)       IP6: Traffic Class = 0 (0x0)       IP6: Flow Label = 0 (0x0)       IP6: Payload Length = 40 (0x28)       IP6: Next Header = 60 (Destination Options Header)       IP6: Hop Limit = 255 (0xFF)       IP6: Source Address = 3ffe:2900:d005:4f:2c0:4fff:fe68:38c5       IP6: Destination Address = 3ffe:2900:d005:1d4a:2c0:4fff:fe09:2f31       IP6: Destination Options Header           IP6: Next Header = 59 (None)           IP6: Length = 4 (0x4)         + IP6: Padding (4 bytes)         + IP6: Binding Update Option         + IP6: Padding (6 bytes)           IP6: Home Address Option               IP6: Type = 201                   IP6: 11...... = Discard packet if not recognized, and
                                  send ICMP if not multicast                   IP6: ..0..... = Option data does not change enroute               IP6: Length = 16 (0x10)               IP6: Home Address = 3ffe:2900:d005:6:2c0:4fff:fe68:38c5 

Notice how the value of the Next Header field in the Destination Options header is set to 59, indicating no next header. Also notice the use of two PadN options to pad the entire Destination Options header to a multiple of 8 bytes (1-byte Next Header field + 1-byte Length field + 4-byte PadN option + 10-byte Binding Update option + 6-byte PadN option + 18-byte Home Address option = 40 bytes). Also notice how the PadN options are used to enforce the Binding Update option's alignment requirement of 4n + 2 (the Binding Update option begins at the byte offset of 6 [= (4 x 1) + 2]) and the Home Address option alignment requirement of 8n + 6 (the Home Address option begins at the byte offset of 22 [= (8 x 2) + 6]).

Summary of Option Types

Table 4-5 lists the different option types for options in Hop-by-Hop Options and Destination Options headers.

Table 4-5. Option Types

Option Type	Option and Where It Is Used	Alignment Requirement
0	Pad1 option: Hop-by-Hop and Destination Options headers	None
1	PadN option: Hop-by-Hop and Destination Options headers	None
194 (0xC2)	Jumbo Payload option: Hop-by-Hop Options header	4n + 2
5	Router Alert option: Hop-by-Hop Options header	2n + 0
198 (0xC6)	Binding Update option: Destination Options header	4n + 2
7	Binding Acknowledgement option: Destination Options header	4n + 3
8	Binding Request option: Destination Options header	None
201 (0xC9)	Home Address option: Destination Options header	8n + 6

Routing Header

IPv4 defines strict source routing, in which each intermediate destination must be only one hop away, and loose source routing, in which each intermediate destination can be one or more hops away. IPv6 source nodes can use the Routing header to specify a source route, which is a list of intermediate destinations for the packet to travel to on its path to the final destination. The Routing header is identified by the value of 43 in the previous header's Next Header field. Figure 4-16 shows the structure of the Routing header.

Figure 4-16. The structure of the Routing header

The Routing header consists of a Next Header field, a Header Extension Length field (defined in the same way as the Hop-by-Hop Options extension header), a Routing Type field, a Segments Left field that indicates the number of intermediate destinations that are still to be visited, and routing type-specific data.

RFC 2460 also defines Routing Type 0, used for loose source routing. Figure 4-17 shows the structure of the Routing Type 0 header.

Figure 4-17. The structure of the Routing Type 0 header

For Routing Type 0, the routing type-specific data consists of a 32-bit Reserved field and a list of intermediate destination addresses, including the final destination address. When the packet is initially sent, the destination address is set to the first intermediate destination, and the routing type-specific data is the list of additional intermediate destinations and the final destination. The Segments Left field is set to the total number of addresses included in the routing type-specific data.

When the IPv6 packet reaches an intermediate destination, the Routing header is processed and:

1. The current destination address and the address in the (N - Segments Left + 1) position in the list of addresses are swapped, where N is the total number of addresses in the Routing header.
2. The Segments Left field is decremented.
3. The packet is forwarded.

By the time the packet arrives at the final destination, the Segments Left field has been set to 0 and the list of intermediate addresses visited in the path to the destination is recorded in the Routing header.

Network Monitor Capture

Here is an example of the Routing header as displayed by Network Monitor (capture 04_04 in the \NetworkMonitorCaptures folder on the companion CD-ROM):

 + Frame: Base frame properties + ETHERNET:  EType = IPv6    IP6: Routing (1 left of 1); Proto = ICMP6; Len = 40       IP6: Version = 6 (0x6)       IP6: Traffic Class = 0 (0x0)       IP6: Flow Label = 0 (0x0)       IP6: Payload Length = 64 (0x40)       IP6: Next Header = 43 (Routing Header)       IP6: Hop Limit = 127 (0x7F)       IP6: Source Address = fec0::2:2b0:d0ff:fee9:4143       IP6: Destination Address = fec0::2:260:97ff:fe02:6e8f       IP6: Routing Header           IP6: Next Header = 58 (ICMP6)           IP6: Length = 2 (0x2)           IP6: Type = 0 (0x0)           IP6: Segments Left = 1 (0x1)           IP6: Reserved           IP6: Route               IP6: Address = fec0::1:260:8ff:fe52:f9d8       IP6: Payload: Number of data bytes remaining = 40 (0x0028) + ICMP6: Echo Request; ID = 0, Seq = 15642 

In this simple example of the Routing header, an ICMPv6 Echo Request message is sent from the source FEC0::2:2B0:D0FF:FEE9:4143 to the destination FEC0::1:260:8FF:FE52:F9D8 using the intermediate destination of FEC0::2:260:97FF:FE02:6E8F.

Fragment Header

The Fragment header is used for IPv6 fragmentation and reassembly services. This header is identified by the value of 44 in the previous header's Next Header field. Figure 4-18 shows the structure of the Fragment header.

Figure 4-18. The structure of the Fragment header

The Fragment header includes a Next Header field, a 13-bit Fragment Offset field, a More Fragments flag, and a 32-bit Identification field. The Fragment Offset, More Fragments flag, and Identification fields are used in the same way as the corresponding fields in the IPv4 header. Because the use of the Fragment Offset field is defined for 8-byte fragment blocks, the Fragment header cannot be used for jumbograms. The maximum number that can be expressed with the 13-bit Fragment Offset field is 8,191. Therefore, Fragment Offset can be used to indicate only a fragment data starting position of up to 8,191 x 8, or 65,528.

In IPv6, only source nodes can fragment payloads. If the payload submitted by the upper-layer protocol is larger than the link or path MTU, then IPv6 fragments the payload at the source and uses the Fragment header to provide reassembly information. An IPv6 router will never fragment an IPv6 packet being forwarded.

Because the IPv6 internetwork will not transparently fragment payloads, data sent from applications that do not have an awareness of the destination path MTU will not be able to sense when data needing fragmentation by the source is discarded by IPv6 routers. This can be a problem for unicast or multicast traffic sent as a UDP message or other types of message streams that do not use TCP.

Differences in Fragmentation Fields

There are some subtle differences between the fragmentation fields in IPv4 and IPv6. In IPv4, the fragmentation flags are the three high-order bits of the 16-bit quantity composed of the combination of the fragmentation flags and the Fragment Offset field. In IPv6, the bits used for fragmentation flags are the three low-order bits of the 16-bit quantity composed of the combination of the fragmentation flags and the Fragment Offset field. In IPv4, the Identification field is 16 bits rather than 32 bits in IPv6, and in IPv6 there is no Don't Fragment flag. Because IPv6 routers never perform fragmentation, the Don't Fragment flag would always be set to 1 for all IPv6 packets, and therefore does not need to be included.

IPv6 Fragmentation Process

When an IPv6 packet is fragmented, it is initially divided into unfragmentable and fragmentable parts:

• The unfragmentable part of the original IPv6 packet must be processed by intermediate nodes between the fragmenting node and the destination. This part consists of the IPv6 header, the Hop-by-Hop Options header, the Destination Options header for intermediate destinations, and the Routing header.
• The fragmentable part of the original IPv6 packet must be processed only at the final destination node. This part consists of the Authentication header, the Encapsulating Security Payload header, the Destination Options header for the final destination, and the upper-layer PDU.

Next, the IPv6 fragment packets are formed. Each fragment packet consists of the unfragmentable part, a fragment header, and a portion of the fragmentable part. Figure 4-19 shows the IPv6 fragmentation process for a packet fragmented into three fragments.

Figure 4-19. The IPv6 fragmentation process

In each fragment, the Next Header field in the Fragment header indicates the first header or the upper-layer protocol in the original fragmentable part. The Fragment Offset field in the Fragment header indicates the offset, in 8-byte units known as fragment blocks, of this fragment relative to the original payload. The More Fragments flag is set on all fragment packets except the last fragment packet. All fragment packets created from the same IPv6 packet must contain the same Identification field value.

Fragmentation of IPv6 packets can occur when the upper-layer protocol of the sending host submits a packet to IPv6 that is larger than the path MTU to the destination. Examples of IPv6 fragmentation are when a UDP application that is not aware of a path MTU sends large packets to a destination, or when a TCP application sends a packet before it is made aware of a path MTU update that lowers the path MTU. In this latter case, IPv6 is aware of the new path MTU, but TCP is not. TCP submits the TCP segment by using the old, larger value of the path MTU and IPv6 fragments the TCP segment to fit the new, lower path MTU value. Once TCP is made aware of the new path MTU, subsequent TCP segments are not fragmented.

IPv6 packets sent to IPv4 destinations that undergo IPv6-to-IPv4 header translation may receive a path MTU update of less than 1,280. In this case, the sending host sends IPv6 packets with a Fragment header in which the Fragment Offset field is set to 0 and the More Fragments flag is not set, and a smaller payload size of 1,272 bytes. The Fragment header is included so that the IPv6-to-IPv4 translator can use the Identification field in the Fragment header to perform IPv4 fragmentation to reach the IPv4 destination.

Network Monitor Capture

Here is an example of a Fragment header as displayed by Network Monitor (frame 3 of capture 04_05 in the \NetworkMonitorCaptures folder on the companion CD-ROM):

 + Frame: Base frame properties + ETHERNET:  EType = IPv6    IP6: Fragment (id 5 at 0xb50+); Proto = ICMP6; Len = 1448       IP6: Version = 6 (0x6)       IP6: Traffic Class = 0 (0x0)       IP6: Flow Label = 0 (0x0)       IP6: Payload Length = 1456 (0x5B0)       IP6: Next Header = 44 (Fragment Header)       IP6: Hop Limit = 128 (0x80)       IP6: Source Address = fe80::210:5aff:feaa:20a2       IP6: Destination Address = fe80::250:daff:fed8:c153       IP6: Fragment Header           IP6: Next Header = 58 (ICMP6)           IP6: Reserved           IP6: Offset = 2896 (0xB50)           IP6: ...............1 = More fragments           IP6: Identifier = 5 (0x5)       IP6: Payload: Number of data bytes remaining = 1448 (0x05A8) 

This is a fragment of a payload using the identification number of 5 and starts in byte position 2,896 relative to the fragmentable portion of the original IPv6 payload.

IPv6 Reassembly Process

The fragment packets are forwarded by the intermediate IPv6 router(s) to the destination IPv6 address. The fragment packets can take different paths to the destination and arrive in a different order in which they are sent. To reassemble the fragment packets into the original payload, IPv6 uses the Source Address and Destination Address fields in the IPv6 header and the Identification field in the Fragment header to group the fragments. Figure 4-20 shows the IPv6 reassembly process.

Figure 4-20. The IPv6 reassembly process

After all the fragments arrive, the original payload length is calculated and the Payload Length field in the IPv6 header for the reassembled packet is updated. Additionally, the Next Header field of the last header of the unfragmentable part is set to the Next Header field of the Fragment header of the first fragment.

RFC 2460 recommends a reassembly time of 60 seconds before abandoning reassembly and discarding the partially reassembled packet. If the first fragment has arrived and reassembly has not completed, the reassembling host sends an ICMPv6 Time Exceeded-Fragment Reassembly Time Exceeded message to the source of the fragment.

Authentication Header

The Authentication header provides data authentication (verification of the node that sent the packet), data integrity (verification that the data was not modified in transit), and anti-replay protection (assurance that captured packets cannot be retransmitted and accepted as valid data) for the IPv6 packet including the fields in the IPv6 header that do not change in transit across an IPv6 internetwork. The Authentication header, described in RFC 2402, is part of the security architecture for IP, as defined in RFC 2401. The Authentication header is identified by the value of 51 in the previous header's Next Header field. Figure 4-21 shows the structure of the Authentication header.

Figure 4-21. The structure of the Authentication header

The Authentication header contains a Next Header field, a Payload Length field (the number of 4-byte blocks in the Authentication header, not counting the first two), a Reserved field, a Security Parameters Index (SPI) field that helps identify a specific IP Security (IPSec) security association (SA), a Sequence Number field that provides anti-replay protection, and an Authentication Data field that contains an integrity value check (ICV). The ICV provides data authentication and data integrity.

The Authentication header does not provide data confidentiality services for the upper-layer PDU by encrypting the data so that it cannot be viewed without the encryption key. To obtain data authentication and data integrity for the entire IPv6 packet and data confidentiality for the upper-layer PDU, you can use both the Authentication header and the Encapsulating Security Payload header and trailer.

Details about how the Authentication header provides data authentication and integrity through cryptographic techniques are beyond the scope of this book.

Encapsulating Security Payload Header and Trailer

The Encapsulating Security Payload (ESP) header and trailer, described in RFC 2406, provide data confidentiality, data authentication, data integrity, and replay protection services to the encapsulated payload. The ESP header provides no security services for the IPv6 header or extension headers that occur before the ESP header. The ESP header and trailer are identified by the value of 50 in the previous header's Next Header field. Figure 4-22 shows the structure of the ESP header and trailer.

Figure 4-22. The structure of the EncapsulatingSecurity Payload header and trailer

The ESP header contains an SPI field that helps identify the IPSec SA, and a Sequence Number field that provides anti-replay protection. The ESP trailer contains the Padding, Padding Length, Next Header, and Authentication Data fields. The Padding field is used to ensure 4-byte boundaries for the ESP payload and appropriate data block boundaries for encryption algorithms. The Padding Length field indicates the size of the Padding field in bytes. The Authentication Data field contains the ICV.

Details about how the ESP header and trailer provide data confidentiality, authentication, and integrity through cryptographic techniques are beyond the scope of this book.