Monday, April 21, 2008

What is the Difference Between IPv4 and IPv6? continue...

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.

Internet 2010

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:

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.

No comments:

Internet Blogosphere