Chapter 11: IPng--The Next Generation

Chapter Snapshot

IP version 6 currently is being defined and developed. This chapter presents IP version 6 as it is currently defined by discussing the following areas of interest: You can find documentation of a more technical nature in several Internet Request for Comment documents (RFCs) and documents of Internet drafts. Look to the end of this chapter for a listing of these documents and sources.

IPng--The Next Generation

"The difference between reality and fiction? Fiction has to make sense." --TOM CLANCY

The IP layer is the foundation of the TCP/IP protocol suite. Perhaps the IP layer's most critical function is addressing. The IP address structure was developed with the expectation that it should meet current and future requirements. The current implementation of IP, also known as version 4, which utilizes a 32-bit addressing space, does provide for a large addressing space.

This is illustrated in the following table:

Table 11.1

IP Version 4 Addressing Capabilities

Address 	First Octet 	Number of	Number of Nodes Per
Class		Range		Networks	per Network

A		1-127		127 		16,277,214
B		128-191		16,383		65,534
C		192-223		2,097,151	254
IP version 4's addressing capacity met the internetwork community's requirements when first implemented but has rapidly been exhausted, owing principally to the enormous growth of devices that utilize IP addresses.

The computer environment currently is the largest group of devices that utilize IP addresses and one of the fastest growing areas of technology. Now being purchased in the thousands are personal computers, many of which utilize TCP/IP as a communications protocol and therefore have an IP address. More and more platforms, such as mainframes, utilize TCP/IP and have IP addresses.

The Internet has experienced phenomenal growth over the past several years, and that rate of growth is likely only to increase. As of October 1994, estimations suggested that the Internet consisted of approximately 40,000 networks. Since then, the number of networks in the Internet is rapidly increasing each year. At the same time, the number of users within these networks also is increasing owing to the rapid growth in use of the Internet in both the business and home communities. Another example of the growth in the Internet is quantified by the number of World Wide Web servers. Matthew Gray provides statistics on the number of WWW servers on the Internet, shown in table 11.2.

Table 11.2

WWW Servers in the Internet

June 1993	130 sites
December 1993	623 sites
June 1994	1265 sites
December 1994	11576 sites

Current	More than 15000 sites
*Source: Matthew Gray "Growth of the World Wide Web" http://www.netgen.com/info/growth.html Systems and network management also has contributed to exhausting IP addresses. Network and device management is critical for organizations that implement local and wide area networks and for client-server environments that require monitoring, control, and fault detection. Using technologies based on Simple Network Management Protocol (SNMP), an IP-based protocol, requires that each device--a network hub, a network interface card in a personal computer, a file server, a router, a LAN switch or other communications equipment--have an IP address.

Although the computer and network market's growth has been explosive, it might not experience the amount of growth now only priming to erupt in the consumer entertainment market. By providing services such as cable television, video on demand, home shopping, and information access, every television could become an Internet device with an IP address. The growth that this market alone can be expected to drive will demand an architecture that provides efficient, easy-to-implement, and easy-to-monitor large scale addressing and routing.

History of IP Next Generation

IP Next Generation, or version 6, actually is the evolution and compilation of a number of proposals and efforts over the last three years within the standards communities. Numerous proposals have addressed some but not all of the IP version 4 issues.

By the end of 1992, the Internet community had developed three primary proposals for consideration: TCP and UDP with Bigger Addresses (TUBA), Common Architecture for the Internet (CATNIP), and the Simple Internet Protocol Plus (SIPP).

TUBA--TCP and UDP with Bigger Addresses

By design, TUBA's primary objective is to address the IP address exhaustion issue; specifically, to provide a significantly larger address space by replacing the current IP layer with CLNP. CLNP uses an address format known as Network Service Access Point (NSAP) addresses, which are significantly larger than the IP version 4 32-bit addresses. Furthermore, the hierarchy that can be structured into these address structures would enhance the scalability of the Internet environment and increase the levels of efficiency of routing data through the Internet.

One of TUBA's strongest points is that it doesn't require completely replacing the current transport (TCP and UDP) protocols or application protocols (FTP, TELNET, SMTP, SNMP, HTTP, and so on). TUBA doesn't imply a complete transition to the OSI protocol suite--rather it just replaces the current network layer with CLNP.

Integral to the TUBA proposal is a migration strategy that would allow a gradual transition of Internet devices. The primary devices affected during this migration phase would be host systems that serve as platforms for Internet applications and Domain Name Server (DNS) platforms that provide host name to address translation functions. This migration strategy would allow both traditional IP version 4 addresses and NSAP addresses to coexist in the Internet, and this would allow for a smooth transition rather than a large scale conversion effort all at once.

CATNIP--Common Architecture for the Internet

The concept driving CATNIP is to establish a commonality between several of the most prominent protocol environments you see in today's networks: namely, in the Internet, which is predominately TCP/IP based, OSI, and Novell IPX. The objective is to eliminate the architectural and protocol barriers between these environments and to facilitate growth of the Internet. The goal is to extend the life of the Internet and to increase the performance of it.

The CATNIP concept specifies that any of the current transport layer protocols (TCP, UDP, IPX, SPX, TP4 and CLTP) be able to function on any of the prominent layer three protocols (CLNP, IP version 4, IPX, and CATNIP). It also would permit one device that might use IP as a network layer protocol to interoperate with a device that uses IPX as a network layer protocol.

Like TUBA, CATNIP implements OSI Network Service Access Point (NSAP) format addresses.

SIPP--Simple Internet Protocol Plus

Perhaps the primary consideration behind the design of the Simple Internet Protocol is to develop a protocol that would provide an easy transition from IP version 4. It is expected that SIPP would function well in high performance network environments, such as FDDI and ATM, as well as in lower performance networks, such as low bandwidth wide area networks (WANs) or wireless networks. The two primary areas addressed are addressing and structure of the IP packet.

The Simple Internet Protocol increases the size of the IP address from 32 to 64 bits, and this larger address space allows for a significantly larger number of addressable devices as well as for a higher degree of hierarchical structure in a network. This would dramatically increase the efficiency of routing data in large networks such as the Internet. Furthermore, the architecture allows the 64-bit address space to be expanded even further in 64-bit increments. Given this, it is projected that SIPP could have a longer viable lifespan than earlier versions of IP.

The structure of the IP packet also has been revised. Functions and fields not functional or deemed unnecessary have been eliminated. Enhancements required have been added to the specifications. A certain capability was added, for example, to enable identifying packets as being part of a "conversation" between two devices that might need special handling as they are transported through an internetwork.

IP Next Generation Overview

Each of the preceding proposals resolved some of the existing issues with IP version 4 and also introduced new functionality necessary for the future requirements of the IP protocol. None of them, however, addressed all of the relevant issues. IP Next Generation, as it is currently defined, is in fact the result of adopting the salient features of these three prominent proposals.

One of the primary objectives of IP version 6 design is to maintain compatibility with higher level protocols that rely on it, such as SMTP, SNMP, FTP, and HTTP. By design, it is meant to be evolutionary, so that it doesn't require completely redesigning the applications that thousands of users currently utilize.

The evolution of IP version 6 can be categorized into several areas:

The following sections discuss how IP version 6 seeks to address the issues and limitations of the current implementation of IP in each of these areas.

IP Next Generation Addressing

One of the most noticeable differences between IP versions 4 and 6 comes in the area of addressing. IP version 4 utilizes a 32-bit address space, whereas IP version 6 increases this address space from 32 bits to 128 bits, which allows a much greater number of addressable devices--a total of 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. This is 4 billion times 4 billion the number of addresses that are possible with IP version 4.

IP version 6 has three types of addresses, as follow:

The type of IPng address is determined by the leading bits in the address. This variable length field is called the Format Prefix (FP).

IP version 4 addresses are distinguished by class, but this is not so with IPng addresses. The IPng concept resembles Classless Inter Domain Routing (CIDR), which is discussed in detail in RFC 1338.


This RFC does not explain IPng addressing. It is a source for a similar mechanism, and the reference is provided for someone who might want more technical information.
The leading bits in the address indicate the specific type of IPng address. The variable-length field that comprises these leading bits is called the Format Prefix (FP). The initial allocation of these prefixes is as follows:
Table 11.3

Address Distribution for IP Version 6

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 Neutral-Interconnect-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
*Source: R. Hinden, http://www.playground.sun.com/pub/ipng/html/pingmain.html Based on this scheme, approximately 15% of the address space has been reserved and 85% is available for future use.

Routing

One of the objectives with IPng was to minimize the effect on other protocols and technologies that rely on the IP protocol. One such example is routing.

Routing in IPng is very similar to routing in IP version 4 environments using CIDR, except for the actual addresses used for routing; that is, IPng addresses being 128 bits long rather than 32 bits.

Therefore, current routing protocols, such as RIP, OSPF, IS-IS, and IDRP can be used to route IPng with modification rather than force the development of entirely new protocols. This too will facilitate the transition to IP version 6.

One of the new capabilities of routing in IP version 6 environments is facilitated by the IPng routing option. An IPng source device uses the routing option to list one or more intermediate nodes it must pass through on its way to a specified destination. This functionality allows the source device to dictate the path that its data takes, enabling such things as provider selection. To illustrate this concept, examine the network depicted in figure 11.1.

In the network illustrated in figure 11.1, if device SRC (representing a source device) transmits data to device DST (representing a destination device), the routing protocol in use determines its path through the network. A routing protocol may determine the optimal path based on characteristics of the individual connections and devices between the source and destination nodes, such as bandwidth, delay, or hop counts. The path of transmitted data, for example, might be SRC-R1-R2-DST, because the routing metric for this path is the least among the possible paths.

Using the IPng routing option, the device SRC can specify the path of its data through this internetwork. Essentially, this enables the source device, such as a personal computer, to override the router and dictate it's path through the network. If the connection between R1 and R2 is subject to high amounts of delay and the data in question is delay sensitive, for example, SRC might want to specify that the path of its data be SRC-R3-R4-DST.

The IPng routing option also can be used to allow source devices to select which Internet Access Provider (IAP) might handle specific flows of data. If the connection between R1 and R2 is provided by an IAP that might be undesirable for the traffic flow for reasons of cost, bandwidth, delay, or reliability, the source device can direct network traffic onto a favorable path.

IP Next Generation Packet and Header Formats

As mentioned previously, many of the new capabilities of IP version 6 are made possible by a restructuring of the IP header. In this section, you examine the components of the IP version 6 header and explain the capabilities made possible by these components.

The sizes of the fields shown in figure 11.2 are illustrative only. The actual size of each field and its function are explained in the following:

IPng Extensions

In IP version 6, optional IP layer information is placed in separate headers between the IP version 6 header and the transport layer headers of TCP or UDP. A single packet can contain zero, one, or several extension headers. Primarily, only the receiving or destination device uses these headers, and intermediary devices such as routers do not examine them, with the single exception being the Hop-by-Hop Options header (discussed later in this chapter). This serves to improve the performance of routers that process packets that contain IP version 6 options. Unlike IP version 4 headers, IPng extension headers have any length in multiples of 8 octets without IP version 4's 40-byte option limitation.

The header formats shown in figures 11.3 through 11.5 illustrate several possibilities.

At this time, the following IPng headers have been defined: Routing, Fragmentation, Authentication, Encapsulation, Hop-by-Hop Options, Destination, and No Next Header. The following sections discuss each of these headers and the function each provides to the IP version 6 protocol.

Routing
The function of the Routing header is to specify one or more intermediate devices to be visited as a packet is forwarded to its destination (see fig. 11.6). This allows a source to specify the "route" to a destination and essentially override the route that might have ordinarily have been determined by the routing protocol.

The Routing header is identified by a Next Header value of 43 in the header that precedes it. This is illustrated more clearly in figure 11.5, in which the entire IP version 6 is illustrated.

Fragmentation
In an IP version 6 environment, the source node uses the Fragmentation header to send packets that are too large to fit in the maximum packet size or MTU of the destination. By function, the Fragmentation header addresses the possibility that the network to which the receiving station is attached, or any intermediate networks, cannot accommodate packets as large as the sending station. A device connected to an FDDI network, for example, could send packets as large as 4,000 bytes, whereas a receiving device connected to an Ethernet network could only receive a packet of 1,518 bytes.

In this case, the source node divides, or fragments, the larger packet into smaller packets that can fit the receiving device's MTU. Each fragmented packet would have a Fragmentation header that identifies it as a large fragmented packet (see fig. 11.8). When the receiving node receives the fragments, it recombines the fragments into a single packet and processes it accordingly.

IP version 6 fragmentation works much differently than with IP version 4. Whereas with IP version 4, intermediary devices, such as routers, can handle fragmentation, only the source node performs fragmentation with IP version 6. The Fragmentation header is always identified by a Next Header value of 44 in the preceding header.

Authentication
The Authentication header exists specifically to ensure two significant facts: To accomplish this, the sending station calculates a value based on the headers, payload, and user information within the packet. The receiving node then calculates the value based on the same headers, payload, and user information. If these two values match, the receiver considers the packet authentic as defined; if not, it rejects the packet.

The section "Security" discusses authentication in detail later in this chapter.

Encapsulation
The Encapsulation header seeks to provide the same security functions as authentication but also provides confidentiality between the sender and receiver. It achieves confidentiality by taking the IP version 6 datagram and encrypting the data, which is known as the Encapsulated Security Payload (ESP). Then a new IP version 6 header is attached to the ESP for transmission through the network. The new header is illustrated in figure 11.9.

After the destination device receives the packet, it removes the new header, decrypts the ESP, and then processes the original IP version 6 datagram.

Obviously, coordination of these encryption formats between the source and destination nodes is critical for the receiver to be able to decrypt the packet. Equally critical is the confidentiality of these encryption keys. The section "Security" later in this chapter discusses the principle of encapsulation in IP version 6 in detail.

Hop-by-Hop Options
The Hop-by-Hop Options header (see fig. 11.10) is the one header option that each node or device examines or reviews along the delivery path to the destination. Its function is to identify specific handling that the intermediary nodes between the source and destination nodes require. It is identified by a Next Header value of 0 in the Next Header field of the IP version 6 header.
Destination Options
The Destination Options header (see fig. 11.11) accommodates information that only the destination device for the packet or packets will handle. It is identified by a Next Header value of 60 in the preceding header.
No Next Header Option
The value of 59 in the Next Header value of the IP version 6 header or that of any extension header indicates that no options follow.

As mentioned previously, one of the advantages of IP version 6 is the capability to have larger headers than is possible with IP version 4. This advantage will allow new IP version 6 header options to be defined as new requirements are discovered.

Quality of Service

One of the fastest growing technologies in the internetwork arena is applications that rely on "real-time" data, such as multimedia, multicast, or video applications. These applications have several critical requirements: A host can use the flow label and the priority fields in the IPng header to identify packets that might require special handling by IPng routers to ensure throughput, delay, and jitter to meet application requirements.

Flow Labels

A flow is defined as a series of packets, sent from a specific source device to a specific destination, that requires special handling by any intermediary IPng routers. RFC 1363 defines a flow as "a data structure used by internetwork hosts to request special services of the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic." The destination can be a single device (using unicast addresses as a destination) or multiple devices (using multicast addresses as a destination). One example of a flow would be the transmission of a multimedia presentation from a server to a group of client personal computers.

The flow label field of the IP version 6 header is 24 bits long. A flow is identified by having a value other than zero in the flow label field of the IP version 6 header. A packet that isn't part of a flow would contain a flow label value of 0, which a control protocol, such as Resource Reservation Protocol (RSVP), would then use. RSVP is an example of a protocol designed to reserve a path through an internetwork that meets the application's requirements for bandwidth, delay, and jitter.

A device that doesn't support use of a flow label must do one of the following:

Any packets transmitted as part of a flow must contain the same IP version 6 header information, including the source address, destination address, and flow label value, as well as information in any extension headers, such as Routing headers or the Hop-by-Hop Options header.

Flow labels and the protocols that would utilize them still are being designed and can be expected to change, owing to the requirements that present themselves.

IP Version 6 Priority

Often, to meet application requirements in internetworks, you might need to assign certain data higher priority than other traffic from the source. The priority in the IP version 6 header is a 4-bit field, which offers a value range of 0 to 15. The purpose of this field is to allow a source node to identify the priority level for delivering packets. Data that has a priority level of 12, for example, should be delivered before packets that have a priority level of 3.

The traffic to be transmitted is separated into the two following classes:

	 Priority	 Description

 	0	Uncharacterized traffic 
     	1	"Filler" traffic (e.g., netnews) 
     	2	Unattended data transfer (e.g., email) 
     	3	(Reserved) 
     	4	Attended bulk transfer (e.g., FTP, HTTP, NFS) 
     	5	(Reserved) 
     	6	Interactive traffic (e.g., telnet, X) 
     	7	Internet control traffic (e.g., routing protocols, SNMP) 

Security

IP version 6 contains two mechanisms to address security in networks, both of which are optional extensions to the IP version 6 header. The first is the Authentication header, which guarantees delivery of the packet intact and authenticity of the source address. It does not guarantee confidentiality, however; some other device between the sender and the receiving station could potentially also receive the transmission.

The sending value computes a value based on the headers that don't change during delivery to the destination and the payload of the transmission. When the destination node receives the transmission, it also computes a value based on the headers and payload. If these two values match, then the station addresses and the packet's payload are considered authentic and therefore processed. If these two values do not match, the packet is discarded. The algorithm currently used to compute the value for the authentication header is the MD5 algorithm.

Using of the Authentication header impacts the processing performance of IP version 6 devices and the communications latency between them, owing to the need to calculate the authentication value in the source and destination devices and to compare the two computed values in the destination node.

Secondly, IP version 6 provides a feature called Encapsulating Security Payload (ESP). As does using the Authentication header, ESP ensures the integrity of the transmitted data and authenticates the sender and receiver. In addition, ESP ensures the privacy of the transmission. Using an encryption algorithm that only the sender and the receiving device maintain prevents other devices from decrypting and processing the transmission unless they too possess the encryption key.

IP Mobility

Assuming that a network user maintains a single unchanging specific location would frequently lead to error nowadays. Many network users are highly mobile, and many work at home or even in different parts of an organization. IP mobility is in fact not unique to IP version 6 and currently is addressed with IP version 4--and can easily be modified to work with IP version 6. The definition of IP version 6 provides a significant opportunity to implement functionality to meet the unique needs of the mobile network user.

In the Internet draft document from the IP version 6 Working Group titled "Mobility Support in IP version 6," by Charles Perkins and David Johnson, it clearly states the primary issue to be dealt with by IP mobility.

"We believe that the most important function needed to support mobility is the reliable and timely notification of a mobile node's current location to other nodes that need it. The home agent needs this location information in order to forward intercepted packets from the home network to the mobile node, and correspondent nodes need this information in order to send their own packets directly to the mobile node."

IP mobility requires that mobile computers have at least two addresses defined for them--one permanent and any others temporary or care of address. The mobile user would obtain the care of address from a local router or server and then notify the home agent of its temporary location.

You could send information such as e-mail, for example, to a mobile user at the permanent address. If the mobile user is at that location, they receive it. If not, a home agent receives the transmission and redirects the data to the care of the address.

Transitioning to IP Version 6

Clearly, the success of IP Next Generation depends highly on the level of complexity and difficulty in transitioning to this new protocol. A complex, high cost migration plan would dramatically hinder its potential of becoming widely deployed. IPng, however, has number of features that greatly facilitate its implementation.

The most significant feature is the provision for a "phased" implementation. IP version 4 devices, such as client workstations, servers, or routers, can be upgraded gradually with minimal effects on each other. This is due, in part, to the fact that devices upgraded to IP version 6 will essentially run both the IP version 6 and the IP version 4 protocols. This will enable communications with devices that have not yet been upgraded.

The addressing structure of IP version 6 will also ease the burden of transition. Devices that have been upgraded can continue to use their IP version 4 addresses. A server, for example, might be upgraded to support IP version 6 but would still support an IP version 4 address to enable communications to clients that are still using IP version 4. Furthermore, IP version 4 addresses can be "embedded" in the larger address space made possible by IP version 6.

By design, the transition to IP version 6 has been architected to be a smooth, gradual migration. For this reason, it is very likely that the deployment and acceptance of IP version 6 will be swift.

Summary

IP version 6 is designed to be an evolutionary step from IP version 4. It seeks to address known issues with IP version 4 and to introduce functionality to address future requirements of this protocol.

From the start, the issue of migration has been dealt with extensively. As discussed earlier, the addressing techniques designed for IP version 6 allow for the inclusion of IP version 4 addresses to facilitate migration. Hosts that are converted to IP version 6 will be able to maintain their current IP version 4 addresses. By design, IP version 6 hosts will be able to communicate with IP version 4 hosts.

IP version 6 has been designed to work on a variety of networks, ranging from slower technologies such as wireless networks to high speed networks using technologies such as ATM and FDDI.

Perhaps most importantly, IP Next Generation seeks to meet the requirements of the Internet, Next Generation: a large, scaleable, and useable world wide network.

Sources of Information on IP Next Generation

S. Bradner, A. Mankin, RFC 1752, "The Recommendation for the IP Next Generation Protocol," January 1995.

V. Fuller, et al, "Supernetting: an Address Assignment and Aggregation Strategy," RFC 1338, June 1992.

S. Deering, "Simple Internet Protocol Plus (SIPP) Specification (128-bit address version)," Internet Draft, July 1994.

R. Hinden, Editor, "IP Version 6 Addressing Architecture," Internet Draft, April 1995.

R. Gilligan, E. Nordmark, "Transition Mechanisms for IP version 6 Hosts and Routers," Internet Draft, March 1995.