Byline: Mark A. Miller, P.E  President, DigiNet Corporation

In the third installment in this series http://www.telecomreseller.com/2011/04/15/the-rise-of-ipv6-part-3-what%E2%80%99s-behind-the-curtain/ , we took a peek behind the curtain, exploring some of the IPv6 architectural enhancements that the designers from the Internet Engineering Task Force (IETF) included in the new protocol. The list was fairly extensive, including: expanded addressing and routing capabilities, a simplified header format, support for header extensions and options, beefed up security with authentication and encryption, auto configuration (“plug and play” capabilities), support for source routes, defined transition plans for moving from IPv4 to IPv6, and quality of service (QoS) capabilities. In this article, we’ll dig into the new header format in greater detail.

If we look at a simplified model of data communications, we could categorize the information conveyed between sender and receiver in two broad categories: control information, and user information. The control information (sometimes called protocol control information) provides the background details that are required to get the data from point A to point B. This might include the source and destination addresses, the packet length, error control, like a checksum, plus security information such as encryption. The user information is what the end user (human or machine) wants to convey, such as the contents of an email, a database record request, or the transfer of a spreadsheet file. Thus, the control information operates quietly in the background, making sure that everything works for the transmission and reception of the user information.

With most protocols, the control information is contained in a packet header, which is examined at every stop between sender and receiver. Some of that control information (such as the source/destination addresses) is untouched between the origin and the destination, while other elements (such as a checksum) may be recalculated at every handoff.

For IPv6, the packet header underwent a major facelift, as described in Section 3 of RFC 2460 (see ftp://ftp.rfc-editor.org/in-notes/rfc2460.txt). Many of the fields within the IPv4 header were designated in the 1970s when the original Internet Protocol was under development, and a time when the protocol was being designed for military and government communications, not business and electronic commerce. Thus, many of the IPv4 fields were currently obsolete, and only adding to the packet overhead. As a result, the IPv4 header with 12 fields and 20 octets in length (an octet is an 8-bit byte), was simplified to an IPv6 header containing eight fields and 40 octets in length (recall from our last installment that the IPv6 addresses are 16 octets (128 bits) each, which accounts for the vast majority of the increase in IPv6 header length over its IPv4 predecessor)

The IPv6 header fields are:

  • Version (4 bits): carries the version number (6) of the Internet protocol. This is the only field between the IPv4 and IPv6 headers that remains completely unchanged.
  • Traffic Class (8 bits): designed for use by originating stations, and/or forwarding routers to identify and distinguish between different categories or priorities of IPv6 packets. Two of these 8 bits are defined in RFC 3169 (see ftp://ftp.rfc-editor.org/in-notes/rfc3168.txt), as explicit congestion notification (ECN) bits.
  • Flow Label (16 bits): is used by an originating host station to request that certain packets be given special handling, such as a higher quality of service. RFC 1809 (see http://www.rfc-editor.org/rfc/rfc1809.txt), was published to specifically address ideas for the use of this flow label field, which would likely operate in concert with the Traffic Class field noted above. Implementation of these two fields is challenging, however, as they must operate on an end-to-end basis (i.e. all devices, both hosts and routers) for the system to be most effective.
  • Payload Length (16 bits): identifies the length of the packet that follows the IPv6 header, given in octets.
  • Next Header (8 bits): identifies the header that immediately follows the IPv6 header, and is consistent with the values from the IPv4 Protocol field. Assignments of these headers can be found in the Internet Assigned Numbers Authority (IANA) registry (see http://www.iana.org/assignments/ipv6-parameters).
  • Hop Limit (8 bits): designed to keep mis-addressed packets from circulating around the Internet forever. This number is initialized by the originating station (which should have some knowledge of the network that it is attached to), and then decremented by one at every hop along the way. When the Hop Limit field reaches zero (meaning that the actual number of hops has exceeded the expected number of hops), the packet is discarded (then requiring upper layer protocols, such as TCP, to request a retransmission).
  • Source Address (128 bits): identifies the initial sending station.
  • Destination Address (128 bits): identifies the intended recipient station (which may or may not be the ultimate destination, depending on the routing infrastructure).
  • Extension Headers (optional): provide a built-in mechanism for IPv6 to add functionality in the future, as new technological needs arise.

The extension headers, of which several have been defined, are one of the most interesting aspects of the IPv6 design, and will be the subject of our next discussion.

Author’s Biography

Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including the Internet Technologies Handbook, published by John Wiley & Sons.

 

245 queries. 0.626 seconds.