The network layer uses the Internet Protocol (IP) to provide packet delivery service to the layers above it . Last month, in part one of this feature, I reviewed the Internet Protocol, its addressing scheme, and its packet header. This article discusses the problems plaguing the current protocol and outlines the proposed remedy: IP version 6.
The process of moving a datagram from a source to a destination is known as routing. TCP/IP-enabled hosts hand off packets addressed outside the local network to routers. A router is a high performance, dedicated computer system, with multiple points of access to the Internet. Each access point to the internet is known as an interface. Routers receive IP packets from the physical layer, decide the output interface on which to deliver the packet, and dispatch the packet on that interface.
Containing only the address of the destination, a packet has no innate information about the optimal path to its destination [18]. Once the host delivers a packet to the closest router, the new router must determine how to proceed. Each router maintains routing tables containing the IP addresses of the networks it is connected to. Routing tables also contain addresses of local hosts on each network. A trivial example of a routing table is shown in Figure 1.
In the above figure, the Destination field specifies the IP address of the packet's final destination. The Gateway entry indicates the first router or computer along the route. Refcnt is the number of active uses of the route. The Use field gives the total number of packets sent on that route. The Interface entry specifies the local interface which sends packets for a particular route. Finally, the Flags field provides status and destination information about a route. For example Flags might tell if the route is working (U for up) and if it leads to a host (H) or gateway(G). Routing tables also contain many other fields beyond the scope of this article.
Upon receiving an IP packet, a router checks the destination address in the routing table. If the destination belongs to a distant network, the datagram is forwarded on the interface given in the table (network card, optic fiber, or satellite link). Datagrams to local hosts are delivered directly. When the destination network is unknown (not in the routing table), the packet is forwared to a default router containing a more extensive (note the default entry in figure 1) routing table. By only keeping track of other networks (wild-cards for host address e.g. 202.54.0.0) and local hosts (these are fully specified, e.g. 202.54.15.2) the size of routing tables can be minimized. However, the backbone routers [4] of the Internet must have routing tables that cover every network in the world. Maintenance and lookup times for such large tables are tremendous and diminish the 'high-speed, low resource' performance expected of an ideal backbone router.
IP routing is a vast topic that I will devote next month's column to. This column's discussion is heavily incomplete. However, it gives us a context to understand some of the challenges inhibiting the progress of the Internet and its network layer.
After performing extremely well for over a decade, IP has reached the limit of its capabilities. Ironically, the main cause of IPv4's imminent failure is its own popularity and the resulting exponential growth of the Internet [13]. The Internet Protocol performed beyond its designers' expectations. Consequently, the number of IP addresses has grown to the point of exhaustion. After all, there are only 232 theoretically possible IP addresses, of which a large number are wasted due to a non-optimized class scheme (as I discussed in the previous column). In addition, the growth has resulted in routing tables of unmanageable proportions: backbone routers today contain 40,000 or more entries, each!
In addition, the present scheme does not distinguish between types of traffic. For example, packets carrying voice and other time critical data are treated identically to packets carrying file transfers. The new generation of multimedia-rich applications experience trouble because of this. As before, the Internet protocol must support large-scale, low latency routing with controllable Quality of Service parameters. Let us explore this a little more: Today we have a voice network for phone and fax, a global data network for files and images, a television network for moving pictures and local networks for local data. Why?
The only probable reason for this enormous duplication of effort can be that voice, video, and binary data differ in their transmission requirements. One transmission scheme cannot do justice for all types of data. As shown in Table 1, voice requires low bandwidth whereas video frames require high bandwidth. Data file transfers sacrifice speed to achieve accurate delivery. On the other hand, voice cannot tolerate delays but accuracy is not as important.
| Attribute | VOICE | DATA | VIDEO |
|---|---|---|---|
| Bandwidth | LOW | VARIES | HIGH |
| Delay Tolerance | LOW | VARIES | MEDIUM |
| Error Tolerance | HIGH | LOW | MEDIUM to LOW (if compressed) |
| Bursts | NONE | MANY | NONE or MANY (if compressed) |
Will the present system be able to handle and provide for the varying requirements of multi-modal traffic? No, probably not. Some form of differentiating between types of data (i.e., the content of a packet) must be implemented to provide preferential routing of realtime packets. Voice data can then be guaranteed to not suffer delay variances greater than a pre-calculated value, and video can be given more effective bandwidth than binary data, etc. The ability to specify these parameters is denoted Quality of Service. Present packet-switched networks either lack this ability completely, or fail to implement it well.
The present Internet Protocol also lacks authentication and confidentiality provisions. Although many end-to-end provisions have been suggested (like SSL and HTTPS), none of them deal with the problem at the network level. As e-commerce transactions increase, they are bound to force revisions in the Internet Protocol to support authentication and confidentiality.
CIDR (classless inter-domain routing) is being implemented as a partial solution to the address space exhaustion problem. This procedure aims at giving the Internet a bit of extra breathing space by eliminating the concepts of Class A, B, and C networks. CIDR is documented in RFCs 1517 [19], 1518 [20], 1519 [21], and 1520 [22]. However, CIDR only provided a temporary solution for the addressing problem. Moreover, it was not consistently implemented across the Internet and enterprise networks. The change in the overall scenario meant that development of a new version of the IP was imminent.
Apart from the technical problems mentioned above, there are other issues looming in the background. For one, millions of people with wireless portables may want to be connected to the Net and keep in touch with their home bases. Second, with the emerging market for networked entertainment there is an extreme possibility that every television set may someday become an Internet host! Third, the emergence of a new front in the form of device control might use the IP (at the network layer) to control gadgets such as lighting equipment, motors, ovens, and garage doors. Finally, as peer-to-peer computing comes of age, applications such as desktop-to-desktop audio and video, network white boards, and remote teaching will force users to demand permanent IP addresses for round the clock Internet connectivity. This would invalidate the present system in which many dial-in users must use an address allocated from a pool on a temporary basis (the principle behind the Dynamic Host Configuration Protocol: DHCP).
The challenge facing the Internet Engineering Task Force [7] engineers was to create a protocol that met all the above requirements and also provided easy immigration from present networks to new technology. Hence the next generation Internet Protocol, IP version 6 (IPv6) was created. Version number 5 had already been allocated as an experimental implementation. Information about IP version numbers is shown in Table 2.
|
IP version |
Present allocation |
|
0 1-3 4 5 6 7 8 9 10-14 15 |
Reserved Unassigned The present standard Stream IP datagram mode (experimental) IPng (IPv6) TP/IX (The next Internet) The "P" Internet protocol TUBA (TCP UDP with Bigger Addresses) Unassigned Reserved |
IPv6 maintains the good features of the IP (e.g. the hop-by-hop routing model), modifies or discards the bad ones (variable header length, fragmentation fields), and adds new ones where needed (mobility support, optional headers, and QoS). Though IPv6 is not directly compatible with IPv4, is compatible with other Internet protocols such as TCP, UDP, ICMP, IGMP, OSPF, BGP, and DNS.
In order to meet the desired specifications of IPv6, a number of changes were incorporated into the header.
The following explains the modifications made to the IPv4 header, which resulted in the IPv6 header shown in Figure 2.
The IPv6 packet header has several interesting and new features. First of all, it solves the limited number of IP addresses problem by quadrupling the address field from 32-bits to 128-bit. An equally important addition to the IP address scheme is the advanced hierarchical address space design. This allows Internet addresses to function similar to the way country codes or area codes function for telephone networks. More details can be found in RFC 2373 [6].
The simpler IPv6 header can be processed by a router more quickly, allowing for higher throughput. The classic IPv4 header contains fourteen fields, whereas IPv6 requires only eight. The options field in a IPv4 header, designed to carry optional information relevant to the routing process or host applications, has been replaced in IPv6 by the flexible extension headers that travel after the primary IPv6 header and before the transport header and payload. These optional headers provide a powerful means to support security, fragmentation, source routing, and network management. Each extension header typically occurs only once in a given packet and a packet can carry any number of such optional headers. Since the intermediate routers normally do not have to look beyond the first 40 bytes of primary header, they can move packets much more quickly.
Authentication and privacy are key features of the new IP. An optional authentication header guarantees that the packet did indeed come from the claimed source (RFC 2402 [9] provides the details). The absence of such an option in IPv4 allowed hackers to configure one IP host to impersonate another. This IP spoofing will now be extremely difficult. In addition, an encryption header has also been proposed to eliminate the possibility of anyone sniffing or snooping the contents of a packet. Two types of encryption services are offered. In the first type, only the transport header and data are encrypted. This is called "transport-mode" encryption. If higher security is desired, the entire datagram is encrypted and a new IPv6 header is wrapped around the encrypted datagram. This is called "tunnel-mode" encryption because the contents of the datagram are available only at the endpoints of the security 'tunnel'. There is, of course, a considerable overhead involved with this type of encryption. RFC 2406 [10] describes the encryption headers. Mobility issues have also been addressed in IPv6. [3], [11]. These will be addressed by a separate column on mobile issues.
As mentioned above, all fields related to fragmentation have been discarded. IPv4 had the ability to fragment packets into smaller chunks at any point in the path. In IPv6, it is planned that probe packets sent before the data would determine the smallest packet size for any link along the path and packets no larger than that would be generated. This would save the routers from fragmenting packets along the way, thereby creating a speed gain. In case fragmentation cannot be avoided, IPv6 provides an optional extension header that can be used by source nodes. Note that only end-to-end fragmentation is allowed, intermediate routers cannot fragment packets.
Another innovative new feature called anycasting allows a packet addressed to a group's (common) anycast address to be delivered only to one of the interfaces in the group -- typically the 'nearest' interface, according to a protocol metric such as number of hops. A few applications have been envisioned for this technology. For example, traffic from an enterprise will have several redundant access points to the Internet. In case one goes down, traffic is automatically routed to the next nearest device. Similarly DNS servers could be given identical anycast addresses. Essentially this is a highly flexible and cost effective method of traffic load balancing.
Finally, more attention has been paid to Quality of Service (QoS) than in the past. A 24-bit flow identification field and a priority field can be combined to give traffic flows a specific level of security, propagation delay, or cost, accommodating the rapidly increasing multi-media traffic. Experimental work on non-standard IPv4 QoS has already proved that it is quite feasible to convey video and audio streams across meshed internetwork topologies. Research is presently focusing on how these fields can be optimally utilized.
Confusion is to be expected considering the mammoth implications of transferring our global inter-network infrastructure to a new generation protocol [2]. The Internet Engineering Task Force (IETF) has attempted to ensure that the transition would be as painless as possible. In initial implementations, IP drivers conforming to IPv6 will be backward compatible with IPv4. Each computer running the new protocol will have two IP addresses: A 32-bit address for IPv4 and a 128-bit address for IPv6. Almost all hosts and routers today are of the multi-protocol variety running combinations of IP, IPX, AppleTalk and NetBIOS. The addition of IPv6 in the stack is a fairly trivial job. Engineers are working on IPv6 versions of popular routing protocols like OSPF and RIP. The IPv6 DNS, RFC 1886 [23], has already been defined.
If IPv6 routing is not available, the IPv6 packets will be delivered using IPv4 routing under a technique called tunneling (see figure 2). In this technique, IPv6 packets are encapsulated inside IPv4 packets, which take advantage of existing IPv4 infrastructure. All this at the price of increased overhead.
IPv6 is first expected to appear in operating system software and client software packages from Microsoft, Novell, and Sun. Most of us will not need the benefits of IPv6 immediately. However, if your organization plans to use real-time audio or video, perhaps for desktop video-conferencing or for voice-over IP telephone connections, the new standard will provide immediate and significant benefits. For the rest of us, the World Wide Wait might finally be over.
The deficiencies in version 4 of the Internet Protocol have been remedied in IP version 6. The deployment of this new protocol is expected to occur in a gradual and distributed manner. In next month's column, we will explore IP routing in detail and have a look at the protocols (such as OSPF, RIP, and BGP) that make IP routing work.
The interested reader can read information on the IPv6 from RFCs 1752 [24], 1883 [25], 1886 [23], 1971 [26], 1993 [27], 2553 [28], 2292 [29], and 2460 [30].
Last Modified:
Location: www.acm.org/crossroads/columns/connector/august2000.html