The IPv6 Headers

In Chapter 24 you learned about the simple IPv4 header format. Headers are used by protocols to provide information about source and destination addresses, protocols, or the payload encapsulated by the datagram. It is typical that one protocol's packet is sent as the payload of another protocol. For example, the IP datagram is usually sent across most LANs encapsulated in an Ethernet frame. At the destination, the Ethernet portion of the frame is stripped off and the IP packet information is revealed. The IP information is then removed by the protocol stack, and the TCP (or other protocol) information is then removed before the actual data is reassembled and sent to an application.

A few of the IPv4 fields were never put to any practical use. And some of those fields no longer exist in the IPv6 header. In Figure 35.1 you can see the fields that make up the IPv6 header.

The fields for IPv6, as shown in Figure 35.1, are as listed here:

• Version This 4-bit field is the version of the Internet Protocol. The value for IPv4 was 4. The version for IPv6 in this field is 6. Routers and other devices use this value to determine what type of datagram is being processed.

• Traffic Class Similar to the Flow Label field, this field enables nodes to specify a particular "traffic class," the definition of which is still being defined by many RFC documents. This field should be supported by any intervening device (such as a router) that understands this field (as it exists today), and ignored by those that do not.

• Flow Label This 20-bit field is used to request that devices that stand between the source and the destination give special preference to this datagram. This can be compared to the Quality of Service field of IPv4 headers.

• Payload Length This 16-bit field is used to indicate the length of the payload section of the datagram. This does not include the original header of the IP datagram, but it does include any additional headers, as well as the actual payload of the datagram.

• Next Header One of the most useful features that IPv6 provides is that additional headers can be included in a datagram, in addition to the main IPv6 header itself. There are many types of headers (discussed later in this chapter), and they can be useful depending on the type of payload, or the treatment of the current datagram (such as routing techniques).

• Hop Limit This 8-bit field is similar to a Time to Live (TTL) field used by many other protocols. It is decremented by 1 at each router the datagram passes through. When the value reaches 0, the datagram can be discarded.

• Source Address A 128-bit address used to describe the IP source of the datagram.

• Destination Address A 128-bit address used to describe the IP destination address of the datagram.

Figure 35.1. The IPv6 header is vastly different from the IPv4 header.

This section describes just the initial IPv6 header format. In the next section you will learn about how IPv6 can include additional headers that extend the traditional header to provide information about additional services for the IP protocol.

IPv6 Extension Headers

In general, most protocols have header information followed by a payload that contains the actual data to be transmitted from one point to another. Some protocols include a trailer that usually is used to provide some type of integrity check, such as CRC, to ensure that the frame or datagram has arrived at the destination without corruption.

Still other protocols, and we're talking about IPv6 here, allow for additional headers to follow the initial IPv6 header, to describe certain aspects of the datagram. These headers are not required, but one or more can be placed into the datagram. These additional extension headers are placed directly after the IPv6 header, where the payload section is usually located. The payload that follows the IPv6 header, or the extension headers, will be a header for the encapsulated upper-layer protocol being transported by the IPv6 datagram. It is interesting to note that among the following headers, if the hop-by-hop header is used, it must follow the IPv6 header as the first additional header. Other extension headers don't have to be in any particular order, but the RFCs do suggest that certain headers be placed in a certain order.

Note

Although the extension headers don't necessarily have to be placed in any particular order (except for the hop-by-hop header, described in the following text), any node that needs to look at the extension headers is required to do so in the order in which they appear in the datagram. A node cannot simply look through the headers trying to find a specific header.

The field Next Header is used to indicate whether another header follows the current header, after the initial IPv6 header. Yet if the next header is not one that the receiving node recognizes, the node should discard the datagram and send an ICMP message to the source indicating that there was a problem with the packet. In IPv6, the ICMP code for this is 1, which in text format means "unrecognized Next Header Field Header type encountered." This ICMP message is used in many of the IPv6 procedures.

It is important to note that an IPv6 datagram doesn't have to have any extension headers. They are used only when the feature is implemented in the IPv6 hardware (or software) routing mechanism.

The extension headers that can follow the IPv6 header include these:

• Hop-by-Hop If present, this is the only header that must be examined by every node (read that as router, whether an actual router device or a computer acting as a router). This header, as described previously, must be placed directly after the IPv6 header. If you look back at the Next Header field of the IPv6 header shown in Figure 35.1, a value of zero indicates that the Hop-by-Hop header is the next header, and must be examined. The IPv6 header is the only header that can use a value of zero in the Next Header field. If any other extension header contains this value, an ICMP message value of 1 will be sent back to the source. This value indicates "unrecognized Next Header type encountered." This option type can be of variable length.

• Destination Options This header can also be of variable length, and is used only by the destination of the packet. This extension header is used to carry additional information, which is to be defined by other RFCs.

• Routing This field specifies specific network nodes that a packet should be passed through (a route) to reach its destination. Routers usually decide the route a packet will take depending on the routing protocol. Using this option, IPv6 routers can specify a route. The nodes listed in this option are not guaranteed, however, because there is always the possibility that a particular node might not be online. Or the Maximum Transmission Unit (MTU) of a router listed here might not accept the size of the packet, and thus the packet can't be sent through that router.

• Fragment This option enables the source node to fragment a packet so that it will be able to reach its destination based on the MTU of the routers between the source and the destination. However, because this value is set by the source node, and it cannot be certain of the MTU value of intervening nodes, packets can still be dropped. A field called the M flag field can be set to one if more fragments of the original message are to be sent, or zero if the packet contains the last fragment of the original message. An Identification field is used to identify which fragmented packets should be considered as a group to be reassembled at the destination node. At the destination, fragments are identified by the source address + destination address + Identification field.

  Note

  IPv6 assumes a minimum MTU of 1,280 bytes. If the MTU of any link (router) that lies between the source and the destination of the packet uses a smaller MTU, then the packet will be fragmented by the router that lies between the source and the destination, not by IPv6 itself.

  
  

• Authentication This extension header is described in detail in Chapter 46, "Virtual Private Networks (VPNs) and Tunneling."

• Encapsulating Security Payload This extension header is described in detail in Chapter 46.

• Upper-layer header This header follows the other headers, as in an IPv4 packet, and describes the data contained in the remainder of the payload section of the packet.

The preceding list is described in the recommended order suggested by the RFC. This can change depending on a few circumstances. For example, if the Destination Options header should be read not just by the node specified by the destination address found in the initial IPv6 header, but also by the other destinations listed in the Routing header, then the Destination Options header should be placed immediately after the Hop-by-Hop header, followed by the Routing header.

The Options Type Field for Hop-by-Hop and Destination Options

If the Destination Options header should be examined only by the final destination node, it should be placed just before the upper-layer header. The Options Type field for Hop-by-Hop and Destination Options is an 8-bit field. However, it should be interpreted by bit values, not by byte values.

Table 35.1 lists the first two highest-order options type bits. These bits specify what should be done if a node does not understand the option.

Table 35.1. High-Order 2-Bit Option Type Values

Value	Action
00	Ignore this header and continue to process the remaining headers, if any.
01	Drop this packet.
10	Drop this packet and send the source address an ICMP packet indicating that option type was not recognized for this packet, and indicating the header that was not recognized.
11	Similar to 10, but not applicable for multicast packets.

The third-highest-ordered bit used is either zero or one. If the bit has a value of zero, the data contained in the option cannot be changed by a node it passes through on the way to its eventual destination. If the bit has a value of one, a node can change data in the extension header.

The Next Header field is used by all options. It simply specifies what the next option (following the current option) will be. These option type numbers are based on those described for IPv4. These numbers were originally defined in RFC 1700, and later RFCs. However, the RFC process was not sufficient to keep up with newer protocols and services that were being developed, so an online database now exists at the Web site www.iana.org. You can use this database to determine what type of protocol or option the Next Header field indicates.