IPv6 Header
The IPv6 header is a streamlined version of the IPv4 header. It eliminates fields that are either unneeded or rarely used, and adds a field that provides better support for real-time traffic. Figure 4-3 shows the structure of the IPv6 header as described in RFC 2460.
Figure 4-3. The structure of the IPv6 header
The fields in the IPv6 header are:
- Version
The Version field indicates the version of IP and is set to 6. The size of this field is 4 bits. While the purpose of the Version field is defined in the same way for both IPv4 and IPv6, its value is not used to pass the packet to an IPv4 or IPv6 protocol layer. This identification is done through a protocol identification field in the link-layer header. For example, a common link-layer encapsulation for Ethernet called Ethernet II uses a 16-bit EtherType field to identify the Ethernet frame payload. For IPv4 packets, the EtherType field is set to 0x800. For IPv6 packets, the EtherType field is set to 0x86DD. Thus, the determination of the protocol of the Ethernet payload occurs before the packet is passed to the appropriate protocol layer.
- Traffic Class
The Traffic Class field indicates the IPv6 packet's class or priority. The size of this field is 8 bits. This field provides functionality similar 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. Like the Type of Service field in the IPv4 header, RFC 2474 provides an alternate definition of the Traffic Class field in the form of the Differentiated Services (DS) field.
- Flow Label
The Flow Label field 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 (QoS) connections, such as those needed by real-time data (voice and video). For default router handling, the Flow Label field is set to 0. There can be multiple flows between a source and destination, as distinguished by separate non-zero flow labels. Like the Traffic Class field, exact details of the Flow Label field's use are not yet defined.
- Payload Length
The Payload Length field 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, which is covered later in this chapter.
- Next Header
The Next Header field indicates either the type of 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, the Next Header field uses the same values that are used in the IPv4 Protocol field.
- Hop Limit
The Hop Limit field 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 field 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 Hop Limit equals 0 at a router, the router sends an ICMPv6 Time Exceeded-Hop Limit Exceeded in Transit message to the source and discards the packet.
- Source Address
The Source Address field indicates the IPv6 address of the originating host. The size of this field is 128 bits.
- Destination Address
The Destination Address field indicates the IPv6 address of the current destination node. The size of this field is 128 bits. In most cases the Destination Address field is set to the final destination address. However, if a Routing extension header is present, the Destination Address field might be set to the address of the next intermediate destination.
Network Monitor Capture
Here is an example of an IPv6 header, as displayed by Network Monitor (capture 04_01 in the \NetworkMonitorCaptures folder on the companion CD-ROM):
+ Frame: Base frame properties + ETHERNET: EType = IPv6 IP6: Proto = ICMP6; Len = 40 IP6: Version = 6 (0x6) IP6: Traffic Class = 0 (0x0) IP6: Flow Label = 0 (0x0) IP6: Payload Length = 40 (0x28) IP6: Next Header = 58 (ICMP6) IP6: Hop Limit = 128 (0x80) IP6: Source Address = fe80::260:97ff:fe02:6e8f IP6: Destination Address = fe80::260:97ff:fe02:6d3d IP6: Payload: Number of data bytes remaining = 40 (0x0028) + ICMP6: Echo Request; ID = 0, Seq = 24
This ICMPv6 Echo Request packet uses the default Traffic Class and Flow Label, a Hop Limit of 128, and is sent between two hosts using link-local addresses.
Values of the Next Header Field
Table 4-1 lists typical values of the Next Header field for an IPv6 header or an IPv6 extension header. Each of the IPv6 extension headers is covered later in the chapter.
Table 4-1. Typical Values of the Next Header Field
| Value (Decimal) | Header |
|---|---|
0 | Hop-by-Hop Options header |
6 | TCP |
17 | UDP |
41 | Encapsulated IPv6 header |
43 | Routing header |
44 | Fragment header |
50 | Encapsulating Security Payload header |
51 | Authentication header |
58 | ICMPv6 |
59 | No next header |
60 | Destination Options header |
For the most current list of the reserved values for the IPv4 Protocol and IPv6 Next Header fields, see http://www.iana.org/numbers.html.
In looking at the value of the Next Header field to indicate no next header, it would seem to make more sense to set its value to 0, rather than 59. However, the designers of IPv6 wanted to optimize the processing of IPv6 packets at intermediate routers. The only extension header that must be processed at every intermediate router is the Hop-by-Hop Options header. To optimize the test of whether the Hop-by-Hop Options header is present, its Next Header value is set to 0. In router hardware, it is easier to test for a value of 0 than to test for a value of 59.
Comparing the IPv4 and IPv6 Headers
In comparing the IPv4 and IPv6 headers, you can see the following:
- The number of fields has dropped from 12 (including options) in the IPv4 header to 8 in the IPv6 header.
- The number of fields that must be processed by an intermediate router has dropped from 6 to 4, making the forwarding of normal IPv6 packets more efficient.
- Seldom-used fields such as fields supporting fragmentation and options in the IPv4 header have been moved to extension headers in the IPv6 header.
- The size of the IPv6 header has doubled from 20 bytes for a minimum-sized IPv4 header to 40 bytes. However, the new IPv6 header contains source and destination addresses that are four times longer than IPv4 source and destination addresses.
Table 4-2 lists the individual differences between the IPv4 and IPv6 header fields.
Table 4-2. IPv4 Header Fields and CorrespondingIPv6 Equivalents
| IPv4 Header Field | IPv6 Header Field |
|---|---|
Version | Same field but with a different version number. |
Internet Header Length | Removed in IPv6. IPv6 does not include a Header Length field because the IPv6 header is always a fixed length of 40 bytes. Each extension header is either a fixed length or indicates its own length. |
Type of Service | Replaced by the IPv6 Traffic Class field. |
Total Length | Replaced by the IPv6 Payload Length field, which indicates only the size of the payload. |
Identification | Removed in IPv6. Fragmentation information is not included in the IPv6 header. It is contained in a Fragmentextension header. |
Flags | |
Fragment Offset | |
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, the link layer performs bit-level error detection for the entire IPv6 packet. |
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. IPv6 extension headers replace IPv4 options. |
The one new field in the IPv6 header that is not included in the IPv4 header is the Flow Label field.
The result of the new IPv6 header is a reduction in the critical router loop, the set of instructions that must be executed to determine how to forward a packet. To forward a normal IPv4 packet, a router typically performs the following in its critical router loop:
- Verify the Header Checksum field by performing its own checksum calculation and comparing its result with the result stored in the IPv4 header. While this step is required by RFC 1812, modern high-speed routers commonly skip it.
- Verify the value of the Version field. While this step is not required by RFC 791 or 1812, doing so saves network bandwidth, as a packet containing an invalid version number is not propagated across the IPv4 internetwork only to be discarded by the destination node.
- Decrement the value of the TTL field. If its new value is less than 1, send an ICMPv4 Time Exceeded-Time to Live Exceeded in Transit message to the source of the packet and then discard the packet. If not, place the new value in the TTL field.
- Check for the presence of IPv4 header options. If present, process them.
- Use the value of the Destination Address field and the contents of the local routing table to determine a forwarding interface and a next-hop IPv4 address. If a route is not found, send an ICMPv4 Destination Unreachable-Host Unreachable message to the source of the packet and discard the packet.
- If the IPv4 maximum transmission unit (MTU) of the forwarding interface is less than the value of the Total Length field and the Don't Fragment (DF) flag is set to 0, perform IPv4 fragmentation. If the MTU of the forwarding interface is less than the value of the Total Length field and the DF flag is set to 1, send an ICMPv4 Destination Unreachable-Fragmentation Needed And DF Set message to the source of the packet and discard the packet.
- Recalculate the new header checksum and place its new value in the Header Checksum field.
- Forward the packet by using the appropriate forwarding interface.
This critical router loop for IPv4 routers is a simplified list of items that an IPv4 router typically performs when forwarding. This list is not meant to imply any specific implementation nor an optimized order in which to process IPv4 packets for forwarding.
To forward a normal IPv6 packet, a router typically performs the following in its critical router loop:
- Verify the value of the Version field. Although this step is not required by RFC 2460, doing so saves network bandwidth, because a packet containing an invalid version number is not propagated across the IPv6 internetwork only to be discarded by the destination node.
- Decrement the value of the Hop Limit field. If its new value is less than 1, send an ICMPv6 Time Exceeded-Hop Limit Exceeded in Transit message to the source of the packet and discard the packet. If not, place the new value in the Hop Limit field.
- Check the Next Header field for a value of 0. If 0, process the Hop-by-Hop Options header.
- Use the value of the Destination Address field and the contents of the local routing table to determine a forwarding interface and a next-hop IPv6 address. If a route is not found, send an ICMPv6 Destination Unreachable-No Route To Destination message to the source of the packet and then discard the packet.
- If the link MTU of the forwarding interface is less than (40 + the value of the Payload Length field), send an ICMPv6 Packet Too Big message to the source of the packet and discard the packet.
- Forward the packet by using the appropriate forwarding interface.
This critical router loop for IPv6 routers is a simplified list of items that an IPv6 router typically performs when forwarding. This list is not meant to imply any specific implementation nor an optimized order in which to process packets for forwarding.
As you can see, the process to forward an IPv6 packet is much simpler than for an IPv4 packet, as it does not have to verify and recalculate a header checksum, perform fragmentation, or process options not intended for the router.
