In the early 1990s, the Internet Engineering Task Force began an effort to develop a successor to the IPv4 protocol. A prime motivation for this effort was the realization that the 32-bit IP address space was beginning to be used up, with new subnets and IP nodes being attached to the Internet (and being allocated unique IP addresses) at a breathtaking rate. To respond to this need for a large IP address space, a new IP protocol, IPv6, was developed. The designers of IPv6 also took this opportunity to tweak and augment other aspects of IPv4, based on the accumulated operational experience with IPv4.

The point in time when IPv4 addresses would be completely allocated (and hence no new subnets could attach to the Internet) was the subject of considerable debate. The estimates of the two leaders of the IETFs Address Lifetime Expectations working group were that addresses would become exhausted in 2008 and 2018 respectively [Solensky 1996]. A more recent analysis [Huston 2008] puts the exhaustion date around 2010. In 1996, the American Registry for Internet Numbers (ARIN) reported that all of the IPv4 class A addresses had been assigned, 62 percent of the class B addresses had been assigned, and 37 percent of the class C addresses had been assigned [ARIN 1996]. For a recent report on IPv4 address space allocation, see [Hain 2005]. Although these estimates and numbers suggested that a considerable amount of time might be left until the IPv4 address space was exhausted, It was realized that considerable time would be needed to deploy a new technology on such an extensive scale, and so the Next Generation IP (IPng) effort [Bradner 1996] was begun. The result of this effort was the specification of IP version 6 (IPv6). (An often-asked question is what happened to IPv5. It was initially envisioned that the ST-2 protocol would become IPv5, but ST-2 was later dropped in favor of the RSVP protocol, which we'll discuss in "Multimedia Networking"). Excellent sources of information about IPv6 are [Huitema 1998, IPv6 2009].

IPv6 Datagram Format

The format of the IPv6 datagram is shown in Figure 1. The most important changes introduced in IPv6 are evident in the datagram format:

● Expanded addressing capabilities. IPv6 increases the size of the IP address from 32 to 128 bits. This ensures that the world won't run out of IP addresses. Now, every grain of sand on the planet can be IP-addressable. In addition to unicast and multicast addresses, IPv6 has introduced a new type of address, called an anycast address, which allows a datagram to be delivered to any one of a group of hosts. (This feature could be used, for example, to send an HTTP GET to the nearest of a number of mirror sites that contain a given document.)

●  A streamlined 40-byte header. As discussed below, a number of IPv4 fields have been dropped or made optional. The resulting 40-byte fixed-length header allows

IPv6 datagram format

for faster processing of the IP datagram. A new encoding of options allows for more flexible options processing.

●  Flow labeling and priority. IPv6 has an elusive definition of a flow. This allows "labeling of packets belonging to particular flows for which the sender requests special handling, such as a nondefault quality of service or real-time service".  For example, audio and video transmission might likely be treated as a flow. On the other hand, the more traditional applications, such as file transfer and e-mail, might not be treated as flows. It is possible that the traffic carried by a high-priority user (for example, someone paying for better service for their traffic) might also be treated as a flow. What is clear, however, is that the designers of IPv6 foresee the eventual need to be able to differentiate among the flows, even if the exact meaning of a flow has not yet been determined. The IPv6 header also has an 8-bit traffic class field. This field, like the TOS field in IPv4, can be used to give priority to certain datagrams within a flow, or it can be used to give priority to datagrams from certain applications (for example, ICMP) over datagrams from other applications (for example, network news).

As noted above, a comparison of Figure 1 with "The Internet Protocol (IP)" Figure 2 reveals the simpler, more streamlined structure of the IPv6 datagram. The following fields are defined in IPv6:

●  Version. This 4-bit field identifies the IP version number. Not surprisingly, IPv6 carries a value of 6 in this field. Note that putting a 4 in this field does not create a valid IPv4 datagram. (If it did, life would be a lot simpler - see the discussion below regarding the transition from IPv4 to IPv6.)

●  Traffic class. This 8-bit field is similar in spirit to the TOS field we saw in IPv4.

●  Flow label. As discussed above, this 20-bit field is used to identify a flow of datagrams.

●  Payload length. This 16-bit value is treated as an unsigned integer giving the number of bytes in the IPv6 datagram following the fixed-length. 40-byte datagram header.

●  Next header. This field identifies the protocol to which the contents (data field) of this datagram will be delivered (for example, to TCP or UDP). The field uses the same values as the protocol field in the IPv4 header. 

●  Hop limit. The contents of this field are decremented by one by each router that forwards the datagram. If the hop limit count reaches zero, the datagram is discarded.

●  Source and destination addresses. The various formats of the IPv6 128-bit address are described in RFC 4291.

●  Data. This is the payload portion of the IPv6 datagram. When the datagram reaches its destination, the payload will be removed from the IP datagram and passed on to the protocol specified in the next header field.

The discussion above identified the purpose of the fields that are included in the IPv6 datagram. Comparing the IPv6 datagram format in Figure 1 with the IPv4 datagram format that we saw in "The Internet Protocol (IP)" Figure 2, we notice that several fields appearing in the IPv4 datagram are no longer present in the IPv6 datagram.

●  Fragmentation/Reassembly. IPv6 does not allow for fragmentation and reassembly at intermediate routers: these operations can be performed only by the source and destination. If an IPv6 datagram received by a router is too large to be forwarded over the outgoing link, the router simply drops the datagram  and sends a "Packet Too Big" ICMP error message (see below) back to the sender. The sender can then resend the data, using a smaller IP datagram size. Fragmentation and reassembly is a time-consuming operation; removing this functionality from the routers and placing it squarely in the end systems considerably speeds up IP forwarding within the network.

●  Header checksum. Because the transport-layer (for example, TCP and UDP) and data link-layer (for example, Ethernet) protocols in the Internet layers perform checksumming, the designers of IP probably felt that this functionality was sufficiently redundant in the network layer that it could be removed. Once again, fast processing of IP packets was a central concern. Recall from our discussion of IPV4 in "The Internet Protocol (IP)" that since the IPv4 header contains a TTL field (similar to the hop limit field in IPv6), the IPv4 header checksum needed to be recomputed at every router. As with fragmentation and reassembly, this too was a costly operation in IPv4.

●  Options. An options field is no longer a part of the standard IP header. However, it has not gone away. Instead, the options field is one of the possible next headers pointed to from within the IPv6 header. That is, just as TCP or UDP protocol headers can be the next header within an IP packet, so too can an options field. The removal of the options field results in a fixed-length, 40-byte IP header.

Recall from our discussion in "Internet Control Message Protocol (ICMP)" that the ICMP protocol is used by IP nodes to report error conditions and provide limited information (for example, the echo reply to a ping message) to an end system. A new version of ICMP has been defined for IPv6 in RFC 4443. In addition to reorganizing the existing ICMP type and code definitions, ICMPv6 also added new types and codes required by the new IPv6 functionality. These include the "Packet Too Big" type, and an "unrecognized IPv6 options" error code. In addition, ICMPv6 subsumes the functionality of the Internet Group Management Protocol (IGMP) that we'll study in "Broadcast and Multicast Routing". IGMP, which is used to manage a host's joining and leaving of multicast groups, was previously a separate protocol from ICMP in IPv4.


ip address, subnet, anycast address, ip nodes

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.