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 use 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 ini tial 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 lPv6 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.
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-byHop 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.
- Authentication
- Encapsulating Security Payloadis
- 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 n just by the node specified by the destination address found in the initial IPv6 header, but also by th other destinations listed in the Routing header, then the Destination Options header should be p1 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.
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. You can use this database to determine what type of protocol or option the Next Header field indicates.
Other IPv6 Considerations
Although IPv6 contains a field that defines the maximum number of hops (the Hop-to-Hop field), it is not required that all nodes support this function, though they can if desired. Instead, upper-layer protocols (such as TCP) are generally delegated this responsibility.
In addition, upper-level protocols should be aware that the maximum payload space has been reduced if IPv6 headers are to be added to the packet. Again, this is a modification that will require that upper-layer protocols be modified, or that the source use fragmentation to deliver packets to their destination.
The Future of IPv6
IPv4 has been in use for more than 10 years now, and although most of the address-space issues have been resolved, there will come a time when the usefulness and flexibility of IPv6 becomes more and more important. There are many enhancements to IPv6 that might warrant its implementation in your network. If your network hasn't yet adopted IPv6, you can bet that eventually it will.