ipv6.doc

IP V6 Header

The IPv6 header is a streamlined version of the IPv4 header. It eliminates fields that are unneeded or rarely used and adds fields that provide better support for real-time traffic.

Structure of an IPv6 Packet

Figure 17 shows the structure of an IPv6 packet.

Figure 17 The structure of an IPv6 packet

IPv6 Header

The IPv6 header is always present and is a fixed size of 40 bytes. The fields in the IPv6 header are described in detail later in this paper.

Zero or more extension headers can be present and are of varying lengths. A Next Header field in the IPv6 header indicates the next extension header. Within each extension header is a Next Header field that indicates the next extension header. The last extension header indicates the upper layer protocol (such as TCP, UDP, or ICMPv6) contained within the upper layer protocol data unit.

The IPv6 header and extension headers replace the existing IPv4 IP header with options. The new extension header format allows IPv6 to be augmented to support future needs and capabilities. Unlike options in the IPv4 header, IPv6 extension headers have no maximum size and can expand to accommodate all the extension data needed for IPv6 communication.

Upper Layer Protocol Data Unit

The upper layer protocol data unit (PDU) usually consists of an upper layer protocol header and its payload (for example, an ICMPv6 message, a UDP message, or a TCP segment).

The IPv6 packet payload is the combination of the IPv6 extension headers and the upper layer PDU. Normally, it can be up to 65,535 bytes long. Payloads greater than 65,535 bytes in length can be sent using the Jumbo Payload option in the Hop-by-Hop Options extension header.

IPv6 Header

Figure 19 shows the IPv6 header as defined in RFC 2460.

Figure 19 The IPv6 header

The fields in the IPv6 header are:

Version – 4 bits are used to indicate the version of IP and is set to 6.

Traffic Class – Indicates the class or priority of the IPv6 packet. The size of this field is 8 bits. The Traffic Class field provides similar functionality to the IPv4 Type of Service field. In RFC 2460, the values of the Traffic Class field are not defined. However, an IPv6 implementation is required to provide a means for an application layer protocol to specify the value of the Traffic Class field for experimentation.

Flow Label – Indicates that this packet belongs to a specific sequence of packets between a source and destination, requiring special handling by intermediate IPv6 routers. The size of this field is 20 bits. The Flow Label is used for non-default quality of service connections, such as those needed by real-time data (voice and video). For default router handling, the Flow Label is set to 0. There can be multiple flows between a source and destination, as distinguished by separate non-zero Flow Labels.

Payload Length – Indicates the length of the IPv6 payload. The size of this field is 16 bits. The Payload Length field includes the extension headers and the upper layer PDU. With 16 bits, an IPv6 payload of up to 65,535 bytes can be indicated. For payload lengths greater than 65,535 bytes, the Payload Length field is set to 0 and the Jumbo Payload option is used in the Hop-by-Hop Options extension header.

Next Header – Indicates either the first extension header (if present) or the protocol in the upper layer PDU (such as TCP, UDP, or ICMPv6). The size of this field is 8 bits. When indicating an upper layer protocol above the Internet layer, the same values used in the IPv4 Protocol field are used here.

Hop Limit – Indicates the maximum number of links over which the IPv6 packet can travel before being discarded. The size of this field is 8 bits. The Hop Limit is similar to the IPv4 TTL field except that there is no historical relation to the amount of time (in seconds) that the packet is queued at the router. When the Hop Limit equals 0, an ICMPv6 Time Exceeded message is sent to the source address and the packet is discarded.

Source Address –Stores the IPv6 address of the originating host. The size of this field is 128 bits.

Destination Address – Stores the IPv6 address of the current destination host. The size of this field is 128 bits. In most cases the Destination Address is set to the final destination address. However, if a Routing extension header is present, the Destination Address might be set to the next router interface in the source route list.

Values of the Next Header Field

Table 5 shows the typical values of the Next Header field for an IPv6 header or an IPv6 extension header.

Table 5 Values of the Next Header Field

Value (in decimal)	Header
0	Hop-by-Hop Options Header
6	TCP
17	UDP
41	Encapsulated IPv6 Header
43	Routing Header
44	Fragment Header
46	Resource ReSerVation Protocol
50	Encapsulating Security Payload
51	Authentication Header
58	ICMPv6
59	No next header
60	Destination Options Header

Comparing the IPv4 and IPv6 Headers

Table 6 shows the differences between the IPv4 and IPv6 header fields.

Table 6 IPv4 Header Fields and Corresponding IPv6 Equivalents

IPv4 Header Field	IPv6 Header Field
Version	Same field but with different version numbers.
Internet Header Length	Removed in IPv6. IPv6 does not include a Header Length field because the IPv6 header is always a fixed size of 40 bytes. Each extension header is either a fixed size or indicates its own size.
Type of Service	Replaced by the IPv6 Traffic Class field.
Total Length	Replaced by the IPv6 Payload Length field, which only indicates the size of the payload.
Identification Fragmentation Flags Fragment Offset	Removed in IPv6. Fragmentation information is not included in the IPv6 header. It is contained in a Fragment extension header.


Time to Live	Replaced by the IPv6 Hop Limit field.
Protocol	Replaced by the IPv6 Next Header field.
Header Checksum	Removed in IPv6. In IPv6, bit-level error detection for the entire IPv6 packet is performed by the link layer.
Source Address	The field is the same except that IPv6 addresses are 128 bits in length.
Destination Address	The field is the same except that IPv6 addresses are 128 bits in length.
Options	Removed in IPv6. IPv4 options are replaced by IPv6 extension headers.

The one new field in the IPv6 header that is not included in the IPv4 header is the Flow Label field.

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 forwarding process performance.

RFC 2460 defines the following IPv6 extension headers that 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

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

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

Figure 20 shows the Next Header field in the IPv6 header and zero or more extension headers that 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 20 IPv6 extension headers

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 in 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 21 shows the Hop-by-Hop Options header.

Figure 21 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 option is a header within the Hop-by-Hop Options header that either describes a specific characteristic of the packet delivery or provides padding. Each option is encoded in the type-length-value (TLV) format that is commonly used in TCP/IP protocols. The option type both identifies the option and determines the way it is handled by the processing node. The option length identifies its length. The option value is the data associated with the option.

RFCs 2460, 2675, and 2711 define the following options:

· The Pad1 option (Option Type 0) is used to insert a single byte of padding.

· The PadN option (Option Type 1) is used to insert 2 or more bytes of padding.

· The Jumbo Payload option (Option Type 194) is used to indicate a payload size that is greater than 65,535 bytes. With the Jumbo Payload option, payload sizes of up to 4,294,967,295 bytes can be indicated using a 32-bit Jumbo Payload Length field. An IPv6 packet with a payload size greater than 65,535 bytes is named a jumbogram.

· The Router Alert option (Option Type 5) is used to indicate to the router that the contents of the packet require additional processing. The Router Alert option is used for Multicast Listener Discovery and the Resource ReSerVation Protocol (RSVP).

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. Figure 22 shows the Destination Options header.

Figure 22 The Destination Options header

The fields within the Destination Options header are defined the same as the Hop-by-Hop 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.

2. It specifies delivery or processing options at the final destination.

Routing Header

Similar to the loose source routing supported by IPv4, IPv6 source nodes can use the Routing extension header to specify a loose source route, 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.

The Routing header consists of a Next Header field, a Header Extension Length field (defined the same way as the Hop-by-Hop Options extension header), a Routing Type field, a Segments Left field, and routing type-specific data.

For Routing Type 0, which is defined in RFC 2460, the routing type-specific data is a list of intermediate destination addresses. When the IPv6 packet reaches an intermediate destination, the Routing header is processed and the address of the next intermediate destination (based on the value of the Segments Left field) becomes the Destination Address in the IPv6 header.

Figure 23 shows the Routing header for Routing Type 0.

Figure 23 The Routing header for Routing Type 0

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 24 shows the Fragment header.

Figure 24 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 IPv6 jumbograms.

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 extension header to provide reassembly information.

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 each intermediate node 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 only be processed 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 25 shows the fragmentation process for an IPv6 packet.

Figure 25 The IPv6 fragmentation process

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. The Authentication header, described in RFC 2402, is part of the Security Architecture for the Internet Protocol defined in RFC 2401.

The Authentication header is identified by the value of 51 in the previous header’s Next Header field. Figure 26 shows the Authentication header.

Figure 26 The Authentication header

The Authentication header contains a Next Header field, a Payload Length field, a Security Parameters Index (SPI) field that identifies 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 check value (ICV). The ICV provides data authentication and integrity.

The Authentication extension header does not provide data confidentiality services by encrypting the data. To provide this, the Authentication header can be used in conjunction with the Encapsulating Security Payload (ESP) header.

Details about how the Authentication header provides data authentication and integrity through cryptographic techniques are beyond the scope of this paper. For more information, see RFC 2402.

Encapsulating Security Payload Header and Trailer

The Encapsulating Security Payload (ESP) header and trailer provide data confidentiality, data authentication, and data integrity services to the encapsulated payload. In contrast, the Authentication header provides data authentication and integrity services for the entire IPv6 packet. The ESP header and trailer are identified by the value of 50 in the previous header’s Next Header field. Figure 27 shows the ESP header and trailer.

Figure 27 The ESP header and trailer

The ESP header contains a Security Parameters Index (SPI) field that identifies 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 Authentication Data field contains the integrity check value (ICV).

Details about how the ESP extension header and trailer provide data confidentiality, authentication, and integrity through cryptographic techniques are beyond the scope of this paper. For more information, see RFC 2406.