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 254IP 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.
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).
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.
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.
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.
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:
IP version 6 has three types of addresses, as follow:
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.
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 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.
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:
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.
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.
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.
The section "Security" discusses authentication in detail later in this chapter.
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.
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.
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:
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.
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)
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.
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.
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.
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.
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.