An edited version of an early draft this paper appeared in the Handbook on Local Area Networks, published by Auerbach in August 1997. © Auerbach, 1997. Various additions have been made over time...
The Internet is historically linked to the ARPANET, the pioneering packet switched network built for the U.S. Department of Defense in 1969. Starting with four nodes that year, the ARPANET slowly grew to encompass many systems across the U.S., and connecting to hosts in Europe and Asia by the end of the 1970s. By the early 1980s, there were many regional and national networks across the globe that started to become interconnected, and their common communications protocols were based on the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. But even by the later-1980s, the number of host systems on these primarily academic and R&D networks could be counted in the hundreds or thousands. In addition, most of the traffic was supporting simple text-based applications, such as electronic-mail, file transfers, and remote login.
By the 1990s, however, commercial users discovered the Internet and commercial use, previously prohibited or constrained on the Internet, was actively encouraged. Since the beginning of this decade, new host systems are being added to the Internet at rates of up to 10% per month, and the Internet has been doubling in size every 10-12 months for several years; by January 1997, the number of hosts on the Internet was over 16 million, ranging from PC-class systems to supercomputers, on more than 100,000 networks worldwide.
The number of connected hosts is but one measure of the Internet's growth. Another way to quantify the change, however, is in the changing applications. On today's Internet, it is common to see hypermedia, audio, video, animation, and other types of traffic that were once thought to be anathema to a packet switching environment. As the Internet provides better type-of-service support, new applications will spark even more growth and changing demographics. In addition, nomadic access has become a major issue with the increased use of laptop computers, and security concerns have growth with the increased amount of sensitive information accessible via the Internet and the number of attacks launched from the Net.
The Internet Protocol was introduced in the ARPANET in the mid-1970s. The version of IP in common use today is IP version 4 (IPv4), described in Request for Comments (RFC) 791 (September 1981). Although several protocol suites (including Open System Interconnection) have been proposed over the years to replace IPv4, none have succeeded because of IPv4's large, and continually growing, installed base. Nevertheless, IPv4 was never intended for the Internet that we have today, either in terms of the number of hosts, types of applications, or security concerns.
In the early 1990s, the Internet Engineering Task Force (IETF) recognized that the only way to cope with these changes was to design a new version of IP to become the successor to IPv4. The IETF formed the IP next generation (IPng) Working Group to define this transitional protocol to ensure long-term compatibility between the current and new IP versions, and support for current and emerging IP-based applications.
Work started on IPng in 1991 and several IPng proposeals were subsequently drafted. The result of this effort was IP version 6 (IPv6), described in RFCs 1883-1886; these four RFCs were officially entered into the Internet Standards Track in December 1995.1
IPv6 is designed as an evolution from IPv4 rather than as a radical change. Useful features of IPv4 were carried over in IPv6 and less useful features were dropped. According to the IPv6 specification, the changes from IPv4 to IPv6 fall primarily into the following categories:
IPv6 also introduces and formalizes terminology that, in the IPv4 environment, are loosely defined, ill-defined, or undefined. The new and improved terminology includes:
The format of an IPv6 header is shown in Figure 1. Note that although IPv6 addresses are four times the size of IPv4 addresses, the basic IPv6 header is only twice the size of an IPv4 header, thus decreasing the impact of the larger address fields. The fields of the IPv6 header are:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+FIGURE 1. IPv6 Header Format (from RFC 1883). |
| Value | Contents of the next header |
|---|---|
| 1 | Internet Control Message Protocol (ICMP) |
| 6 | Transmission Control Protocol (TCP) |
| 17 | User Datagram Protocol (UDP) |
| 43 | Routing header |
| 44 | Fragment header |
| 58 | Internet Control Message Protocol version 6 (ICMPv6) |
| 59 | nothing; this is the final header |
| 60 | Destination Options header |
| 89 | Open Shortest Path First (OSPF) |
To accommodate almost unlimited growth, and a variety of addressing formats, IPv6 addresses are 128 bits in length. This address space is probably sufficient to uniquely address every molecule in the solar system!
IPv6 defines three types of addresses. A unicast address specifies a single host. An anycast address is one that is assigned to more than a single interface, usually belonging to different IPv6 nodes, such as a set of routers belonging to an ISP. A packet sent to an anycast address is delivered to one of the routers identified by that address, usually the "closest" one as defined by the routing protocol. A multicast address also identifies a set of hosts; a packet sent to a multicast address is delivered to all of the hosts in the group. Note that there is no broadcast address in IPv6 as in IPv4, since that function is provided by multicast addresses.
IPv4 addresses are written in dotted decimal notation, where the decimal value of each of the four address bytes is separated by dots. The preferred, or regular, form of an IPv6 address is to write the hexadecimal value of the eight 16-bit blocks of the address, separated by colons (:), such as FF04:19:5:ABD4:187:2C:754:2B1. Note that leading zeros do not have to be written and that each field must have some value.
IPv6 addresses will often contain long strings of zeros because of the way in which addresses are allocated. A shorthand, or compressed, address form uses a double colon (::) to indicate multiple 16-bit blocks of zeros; for example, the address FF01:0:0:0:0:0:0:5A could be written as FF01::5A. To avoid ambiguity, the "::" can only appear once in an address.
Finally, an alternative, hybrid address format has been defined to make it more convenient to represent an IPv4 address in an IPv6 environment. In this scheme, the first 96 address bits (six groups of 16) are represented in the regular IPv6 format and the remaining 32 address bits are represented in common IPv4 dotted decimal; for example, 0:0:0:0:0:0:199.182.20.17 (or ::199.182.20.17).
| ALLOCATION | Prefix (binary) |
Fraction of Address Space |
|---|---|---|
| Reserved | 0000 0000 | 1/256 |
| Unassigned | 0000 0001 | 1/256 |
| Reserved for NSAP Allocation | 0000 001 | 1/128 |
| Reserved for IPX Allocation | 0000 010 | 1/128 |
| Unassigned | 0000 011 | 1/128 |
| Unassigned | 0000 1 | 1/32 |
| Unassigned | 0001 | 1/16 |
| Unassigned | 001 | 1/8 |
| Provider-Based Unicast Address | 010 | 1/8 |
| Unassigned | 011 | 1/8 |
| Reserved for Geographic-Based Unicast Addresses |
100 | 1/8 |
| Unassigned | 101 | 1/8 |
| Unassigned | 110 | 1/8 |
| Unassigned | 1110 | 1/16 |
| Unassigned | 1111 0 | 1/32 |
| Unassigned | 1111 10 | 1/64 |
| Unassigned | 1111 110 | 1/128 |
| Unassigned | 1111 1110 0 | 1/512 |
| Link Local Use Addresses | 1111 1110 10 | 1/1024 |
| Site Local Use Addresses | 1111 1110 11 | 1/1024 |
| Multicast Addresses | 1111 1111 | 1/256 |
One of the goals of the IPv6 address format is to accommodate many different types of addresses. The beginning of an address contains a three- to ten-bit Format Prefix defining the general address type (Table 2); the remaining bits contain the actual host address, in a format specific to the indicated address type.
| 3 | 5 bits | n bits | 56-n bits | 64 bits | +---+------------+------------+--------------+------------------+ |010| RegistryID | ProviderID | SubscriberID | Intra-Subscriber | +---+------------+------------+--------------+------------------+FIGURE 2. Provider-Based Unicast Address Format (from RFC 1884). |
For example, the Provider-Based Unicast Address is an IPv6 address that might be assigned by an Internet service provider (ISP) to a customer. This type of address contains a number of subfields, including (Figure 2):
Another particularly important address type is the one that indicates an IPv4 address. With over sixteen million hosts using 32-bit addresses, the public Internet must continue to accommodate IPv4 addresses even as it slowly migrates to IPv6 and IPv6 addressing,
IPv4 addresses are carried in a 128-bit IPv6 address that begins with 80 zeros (0:0:0:0:0). The next 16-bit block contains the compatibility bits, which indicate the way in which the host/router handles IPv4 and IPv6 addresses. If the device can handle either IPv4 or IPv6 addresses, the compatibility bits are all set to zero (0) and this is termed an IPv4-compatible IPv6 address; if the address represents an IPv4-only node, the compatibility bits are all set to one (0xFFFF) and the address is termed an IPv4-mapped IPv6 address. The final 32 bits contain a 32-bit IPv4 address in dotted decimal form.
Finally, IPv6 multicast addresses provide an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses may not be used as a source address in IPv6 packets or appear in any routing header.
| 8 | 4 | 4 | 112 bits | +--------+----+----+--------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+--------------------------------------------+FIGURE 3. Multicast Address Format (from RFC 1884). |
All multicast addresses, as shown in Figure 3, begin with eight ones (0xFF). The next four bits are a set of flag bits (flgs); the three high-order bits are set to zero and the fourth bit (T-bit) indicates a permanently assigned ("well-known") multicast address (T=0) or a nonpermanently assigned ("transient") multicast address (T=1). The next four bits indicate the scope of the address (scop), or the part of the network for which this multicast address is relevant; options include node-local (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), or global (0xE). The remaining 112 bits are the Group Identifier, which identifies the multicast group, either permanent or transient, within the given scope. The interpretation of a permanently assigned multicast address is independent of the scope value; for example, if the "Internet video servers group" is assigned a permanent multicast address with a group identifier of 0x77, then:
Finally, a number of well-known multicast addresses are predefined, including:
In IPv6, optional IP Layer information is encoded in separate extension headers that are placed between the IPv6 basic header and the higher layer protocol header. An IPv6 packet may carry zero, one, or more such extension headers, each identified by the Next Header field of the preceding header and each containing an even multiple of 64 bits (Figure 4). A fully compliant implementation of IPv6 includes support for the following extension headers and corresponding options:
<--- 32 bits ---> <--- 32 bits ---> <--- 32 bits --->
+---------------+ +---------------+ +---------------+
| IPv6 header | | IPv6 header | | IPv6 header |
| | | | | |
| Next Header = | | Next Header = | | Next Header = |
| TCP | | Routing | | Routing |
+---------------+ +---------------+ +---------------+
| TCP header | |Routing header | |Routing header |
| + | | | | |
| data | | Next Header = | | Next Header = |
| | | TCP | | Fragment |
+---------------+ +---------------+ +---------------+
| TCP header | |Fragment header|
| + | | |
| data | | Next Header = |
| | | TCP |
+---------------+ +---------------+
| TCP header |
| + |
| data |
| |
+---------------+
FIGURE 4. IPv6 Extension Header examples. TCP segment
encapsulatedin IP without additional options (left); TCP segment following a Routing header (middle); and TCP segment fragment following a Fragment header following a Routing header (right) (inspired from RFC 1883). |
With the exception of the Hop-by-Hop Option, extension headers are only examined or processed by the intended destination node(s). The contents of each extension header determine whether or not to proceed to the next header and, therefore, extension headers must be processed in the order they appear in the packet.
The Priority and Flow Label fields in the IPv6 header are used by a source to identify packets needing special handling by network routers. The concept of a flow in IP is a major departure from IPv4 and most other connectionless protocols; some have called flows a form of connectionless virtual circuits since all packets with the same flow label are treated similarly and the network views them as associated entities.
Special handling for non-default quality-of-service is an important capability in order to support applications that require guaranteed throughput, end-to-end delay, and/or jitter, such as multimedia or real-time communication. These QOS parameters are an extension of IPv4's Type of Service (TOS) capability.
The Priority field allows the source to identify the desired priority of a packet. Values 0-7 are used for congestion-controlled traffic, or traffic that backs off in response to network congestion, such as TCP segments. For this type of traffic, the following priority values are recommended:
Values 8-15 are defined for noncongestion-controlled traffic, or traffic that does not back off in response to network congestion, such as real-time packets being sent at a constant rate. For this type of traffic, the lowest priority value (8) should be used for packets that the sender is most willing to have discarded under congestion conditions (e.g., high-fidelity video traffic) and the highest value (15) should be used for those packets that the sender is least willing to have discarded (e.g., low-fidelity audio traffic).2
The Flow Label is used by a source to identify packets needing nondefault QOS. The nature of the special handling might be conveyed to the network routers by a control protocol, such as the Resource Reservation Protocol (RSVP), or by information within the flow packets themselves, such as a hop-by-hop option. There may be multiple active flows from a source to a destination, as well as traffic that is not associated with any flow (i.e., Flow Label = 0). A flow is uniquely identified by the combination of a source address and a nonzero flow label. This aspect of IPv6 is still in the experimental stage and future definition is expected.
In the early days of TCP/IP, the ARPANET user community was small and close, and security mechanisms were not of primary concern. As the number of TCP/IP hosts grew, and the user community became one of strangers (some nefarious) rather than friends, security became more important. As critical and sensitive data travels on today's Internet, security is of paramount concern.
Although many of today's TCP/IP applications have their own security mechanisms, many would argue that security should be implemented at the lowest possible protocol layer. IPv4 had few, if any, security mechanisms, and authentication and privacy mechanisms at lower protocol layers is largely absent. IPv6 builds two security schemes into the basic protocol.
The first mechanism is the IP Authentication Header (RFC 1826), an extension header that can provide integrity3 and authentication4 for IP packets. Although many different authentication techniques will be supported, use of the keyed Message Digest 5 (MD5, described in RFC 1321) algorithm is required to ensure interoperability. Use of this option can eliminate a large number of network attacks, such as IP address spoofing; this will also be an important addition to overcoming some of the security weaknesses of IP source routing. IPv4 provides no host authentication; all IPv4 can do is to supply the sending host's address as advertised by the sending host in the IP datagram. Placing host authentication information at the Internet Layer in IPv6 provides significant protection to higher layer protocols and services that currently lack meaningful authentication processes.
The second mechanism is the IP Encapsulating Security Payload (ESP, described in RFC 1827), an extension header that can provide integrity and confidentiality5 for IP packets. Although the ESP definition is algorithm-independent, the Data Encryption Standard using cipher block chaining mode (DES-CBC) is specified as the standard encryption scheme to ensure interoperability. The ESP mechanism can be used to encrypt an entire IP packet (tunnel-mode ESP) or just the higher layer portion of the payload (transport-mode ESP).
These features will add to the secure nature of IP traffic while actually reducing the security effort; authentication performed on an end-to-end basis during session establishment will provide more secure communications even in the absence of firewall routers. Some have suggested that the need for firewalls will be obviated by widespread use of IPv6, although there is no evidence to that effect yet.
The Internet Control Message Protocol (ICMP) provides error and information messages that are beyond the scope of IP. ICMP for IPv6 (ICMPv6) is functionally similar to ICMP for IPv4 and uses a similar message format, and forms an integral part of IPv6. ICMPv6 messages are carried in an IPv6 datagram with a Next Header field value of 58.
ICMPv6 error messages are:
ICMPv6 informational messages are Echo Request and Echo Reply (used by IPv6 nodes for diagnostic purposes), as well as Group Membership Query, Group Membership Report, and Group Membership Reduction (all used to convey information about multicast group membership from nodes to their neighboring routers).
The transition to IPv6 has already started even though most Internet and TCP/IP users have not yet seen new software on their local systems nor local networks. Before IPv6 can be widely deployed, the network infrastructure must be upgraded to employ software that accommodates the new protocol.
In addition, the new address format must be accommodated by every TCP/IP protocol that uses addresses. The Domain Name System (DNS), for example, has defined an AAAA resource record for IPv6 128-bit addresses (IPv4's 32-bit addresses use an A record) and the IP6.INT address domain (IPv4 uses the ARPA address domain). Other protocols that must be modified for IPv6 include DHCP, the Address Resolution Protocol (ARP) family, and IP routing protocols such as the Routing Information Protocol (RIP), Open Shortest Path First (OSPF) protocol, and the Border Gateway Protocol (BGP). Only after the routers and the backbones are upgraded will hosts start to transition to the new protocol and applications be modified to take advantage of IPv6's capabilities.
When IPv4 became the official ARPANET standard in 1983, use of previous protocols ceased and there was no planned interoperability between the old and the new. This will not — can not — be the case with the introduction of IPv6. Although IPv6 trials started in 1996 and initial rollout of IPv6 in the Internet backbone is expected in 1997, there is no scheduled — or desired — date of a flash cut from one to the other; coexistence of IPv4 and IPv6 is anticipated for many years to come. The simple fact of the sheer number of hosts using IPv4 today suggests that no other policy even begins to make sense. While IPv6 will appear in the large ISP backbones sooner rather than later, some smaller service providers and local network administrators will not make the conversion quickly unless they perceive some benefit from IPv6.
(-----) ------------- (-----) ------------- (-----) ( IPv6 ) | IPv4/IPv6 | ( IPv4 ) | IPv4/IPv6 | ( IPv6 ) ( network )---| router |---( network )---| router |---( network ) ( ) ------------- ( ) ------------- ( ) (-----) (-----) (-----)FIGURE 5. Common short-term scenario where an IPv4 network interconnects IPv6 networks. |
The coexistence of IPv4 and IPv6 in the network means that different protocols and procedures will need to be accommodated. In one common short-term scenario, IPv6 networks will be interconnected via an IPv4 backbone (Figure 5). The boundary routers will be IPv4-compatible IPv6 nodes and the routers' interfaces will be given IPv4-compatible IPv6 addresses. The IPv6 packet is transported over the IPv4 network by encapsulating the packet in an IPv4 header; this process is called tunneling. Tunneling can also be performed when an organization has converted a part of its subnet to IPv6. This process can be used on host-host, router-router, or host-router links.
Although the introduction of IPv6 is inevitable, many of the market pressures for its development have been somewhat obviated because of parallel developments that enhance the capabilities of IPv4. The address limitations of IPv4, for example, are minimized by use of Classless Interdomain Routing (CIDR). Nomadic user address allocation can be managed by the Dynamic Host Configuration Protocol (DHCP). Quality of service management can be handled by the Resource Reservation Protocol (RSVP). And the IP Authentication Header and Encapsulating Security Payload procedures can be applied to IPv4 as well as IPv6.
This is not meant to suggest that IP vendors are waiting. IPv6 has already started to appear in real products and production networks. Support for IPv6 on several versions of UNIX have been announced by such organizations as Digital Equipment Corporation, IBM, INRIA (Institut National De Recherche En Informatique Et En Automatique, or The French National Institute for Research in Computer Science and Control), Japan's WIDE Project, Sun Microsystems, the Swedish Institute of Computer Science (SICS), and the U.S. Naval Research Laboratory. Other companies have announced support for IPv6 in other operating environments, including Apple Computer (MacOS), FTP Software (DOS/Windows), Mentat (STREAMS), Novell (NetWare), Pacific Softworks, and Siemens Nixdorf (BS2000). Major router vendors that have announced support for IPv6 include Bay Networks, Cisco Systems, Digital Equipment Corporation, Ipsilon Networks, Penril Datability Networks, and Telebit Communications.
One of the important proving grounds of IPv6 is the 6bone, a testbed network spanning North America, Europe, and Japan that began operation in 1996. The 6bone is a virtual network built on top of portions of today's IPv4-based Internet, designed specifically to route IPv6 packets. The goal of this collaborative trial is to test IPv6 implementations and to define early policies and procedures that will be necessary to support IPv6 in the future. In addition, it will demonstrate IPv6's new capabilities and will provide a basis for user confidence in the new protocol.
For most users, the transition from IPv4 to IPv6 will occur when the version of their host's operating system software is updated; in some cases, it will mean running dual-stacked systems with both versions of IP. For larger user networks, it may make sense to follow the model of the larger global Internet; in particular, pre-design the IPv6 network topology and addressing scheme, build a testbed IPv6 network with routers and a DNS, and then slowly migrate applications, users, and subnetworks to the new backbone. The lessons learned from the 6bone activity will be useful for individual networks as well as the Internet backbone.
Bradner, S. and A. Mankin. IPng: Internet Protocol Next Generation. Reading (MA): Addison-Wesley, 1996.
Deering, S. "SIP: Simple Internet Protocol." IEEE Network, May 1993.
Feit, S. TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security, 2nd ed. New York: McGraw-Hill, 1997.
Francis, P. "A Near-Term Architecture for Deploying Pip." IEEE Network, May 1993.
Hinden, R.M. "IP Next Generation Overview." Communications of the ACM, June 1996.
Huitema, C. IPv6: The New Internet Protocol. Upper Saddle River (NJ): Prentice-Hall, 1996.
IETF IPng Working Group Home Page. URL: http://www.ietf.org/html.charters/ipngwg-charter.html. Last accessed: 29 January 1997.
IP Next Generation Web Page. URL: http://playground.sun.com/pub/ipng/html. Last accessed: 29 January 1997.
Katz, D. and P.S. Ford. "TUBA: Replacing IP with CLNP." IEEE Network, May 1993.
Kessler, G.C. An Overview of TCP/IP Protocols and the Internet. URL: http://www.sover.net/library/tcpip.html. Last accessed: 1 February 1997.
Miller, M. "Making the Move: The path for an orderly transition from IPv4 to IPv6." Network World, January 20, 1997.
Schneier, B. Applied Cryptography, 2/e. New York: John Wiley & Sons, 1996.
6bone Web Page. URL: http://www-6bone.lbl.gov/6bone. Last accessed: 29 January 1997.
Stallings, W. "IPv6: The New Internet Protocol." IEEE Communications Magazine, July 1996. (Also: URL: http://www.ieee.org/comsoc/stallings.html. Last accessed: December 10, 1996.)
Thomas, S. IPng and the TCP/IP Protocols. New York: John Wiley & Sons, 1996.
ABOUT THE AUTHOR: At the time of this paper's publication, Gary C. Kessler was Director of Information Technology at Hill Associates, a telecommunications training and education firm located in Colchester, Vermont. He is the co-author of ISDN, 4/e (McGraw-Hill), author of more than 50 articles, and frequent speaker at industry conferences. He can be reached via e-mail at kumquat@sover.net.
IPv6 is specified in a number of RFCs. The core description of IPv6 and related protocols can be found in:
Other related RFCs include:
RFCs may be obtained over the Internet via anonymous FTP from ftp://ds.internic.net/rfc. For additions sites and mechanisms to obtain RFCs, send e-mail to rfc-info@isi.edu and put help: ways_to_get_rfcs in the message body.