The current version of the Internet Protocol, known as IPv4 or simply as IP, has served the Internet and corporate Intranets in good stead for over twenty years. Now, however, it is beginning to show its age as it struggles to cope with the Internet's daunting growth rate and the demand for new services. With IP, configuring networks and terminals is no easy task, the available address space is running out, and there are no simple solutions to the problem of renumbering a network when Internet Service Provider (ISP) is changed. Though a number of mechanisms for overcoming these limitations have been developed over the years - including DHCP (Dynamic Host Configuration Protocol) for automatic terminal configuration and NATs (Network Address Translators) to make it possible to reuse addresses - all have major drawbacks.

The IETF (Internet Engineering Task Force) tackled this problem in the early '90s, embarking on a research project designed to specify a new-generation IP protocol capable of overcoming the limitations of today's versions. After a series of proposals which contributed to establishing the requirements for the new protocol, the candidate replacement for the current IP, designated IPv6, was selected in 1994 . Since then, an enormous amount of work has been done: specifications have reached a high level of maturity, and more than fifty implementations of the protocol have been completed or are nearing completion, including some by the major router manufacturers. From 1996 onwards, a worldwide IPv6 protocol testbed, the 6Bone network, has grown continuously and now encompasses around four hundred nodes operated by manufacturers, ISPs, universities and research centers in 41 countries, using some 25 different implementations of the protocol.

Growth of Internet hosts

The figure shows growth in the number of Internet hosts from 1993 to January 1999 (http://www.isc.org/ds/host-count-history.html). As the numbers indicated are based on DNS registration counts (DNS stands for Domain Name Service, the method used to associate addresses with logic names on the Internet), they are lower than the actual number of assigned addresses.

Two projections for future growth in the number of hosts starting from January 1999 are also shown. The higher estimate takes all available data into account, while the lower estimate is based only on host counts from January 1996, the point at which stable exponential growth began.

As can be seen from this data, we can expect to reach the critical threshold for assigned addresses somewhere between 2001 and 2003. From that time on, using IPv4 could become a real problem.

Even now, however, the shortage of addresses is hampering Internet's growth in developing countries, which do not have the buying power needed to absorb the rising costs that obtaining global and unique Internet addresses involves.

The larger address space, in any case, is only one of the distinguishing features of the new IP protocol. Indeed, IPv6 has also provided an ideal opportunity to rationalize the IPv4 protocol by eliminating little-used functions, and to respond to the needs that Internet users have been expressing in the last few years by introducing a set of innovative capabilities not contemplated by the current version of IP.

One of the changes introduced in the move from IPv4 to IPv6 is a significant simplification of header format. Several of the IPv4 header fields have been dropped or made optional in order to reduce the packet processing cost and reduce the header's bandwidth occupation as much as possible, despite the fact that addresses are larger. Thus, even though IPv6 addresses are four times longer than their IPv4 counterparts, the IPv6 header is only twice as large as the IPv4 header.

In addition, substantial changes have been made in how header options are encoded in order to ensure more efficient packet forwarding and provide greater leeway for future protocol extensions. In IPv6, options are no longer an integral part of the IP header, but are each stored in a separate header - called the extension header - placed between the IPv6 header and the header for the overlying transport layer (e.g., TCP or UDP). Furthermore, whereas under IPv4 each router crossed is required to examine all of the options in each packet, most IPv6 extension headers are examined only at the final destination. This, together with the fact that the IPv6 header has a fixed size (which permits a higher degree of optimization for the hardware modules responsible for forwarding), translates into a sizable increase in performance and means that IPv6 options are actually usable in practice.

Over and above all these advantages, the real advances which IPv6 makes over IPv4 are to be found in the capabilities which will be integrated in the protocol in order to facilitate network administration and support for new services and applications. To this end, the final version of the protocol will include native support for:

• Differentiated services (best-effort and guaranteed quality)
• Automatic configuration of terminals, services and network equipment
• Multicast services (i.e., the ability to set up "multipoint-multipoint" communications)
• Terminal mobility
• Secure communication

Support for providing differentiated services is based on the new class and flow label fields in the IPv6 header, which the source can use to mark packets belonging to traffic flows requiring special handling on the part of the network (e.g., guarantees on delay and/or loss en route to the destination).

As regards autoconfiguration mechanisms, on the other hand, IPv6 was designed to be a true "Plug and Play" protocol. This means that each newly installed IPv6 terminal will be able to bring itself to operative status without manual intervention on the part of the network administrator. Powerful host and router autoconfiguration mechanisms have already been defined for this purpose. In particular, these mechanisms include the Neighbor Discovery (ND) protocol, whereby user terminals can independently configure their interfaces' IPv6 addresses starting from information announced by neighboring routers. This mechanism simplifies network administration to a considerable extent because, unlike the autoconfiguration protocols now available for IPv4 (DHCP, Dynamic Host Configuration Protocol), it does not require that a central server be manually configured and maintained.

As mentioned above, the final version of IPv6 will be required to provide integrated support for network services such as multicast transmission, terminal mobility and security. To this end, mechanisms for providing authentication, confidentiality and data integrity services are at an advanced stage of definition, as are the mobility management protocols which enable each IPv6 terminal to seamlessly change its point of access to the Internet without jeopardizing its level of network connectivity.

In addition, we can expect that the transition from IPv4 to IPv6 will be a fairly lengthy one, lasting several years. During this period, the two protocols will coexist, with IPv4 accounting for the lion's share of usage at the beginning. Subsequent evolution will depend to a large extent on how quickly IPv6 is able to gain ground.

For these reasons, work has been going on for some time on transition mechanisms which will permit interoperability between terminals and routers implementing the two protocols. The simplest solution is the dual-stack approach, where both protocols are present on all network nodes (hosts and routers). This solution is extremely advantageous, especially for hosts (system requirements are quite modest by comparison with present-day computing power and memory capacity).

However, a number of different needs may arise, including:

• IPv6 network interconnection via IPv4 backbones
• Interoperability between IPv6-only terminals and IPv4-only terminals
• IPv4 LAN interconnection via IPv6 backbones

Some of the first answers to these needs are to be sought in tunneling mechanisms (e.g., for encapsulating IPv6 packets in IPv4 packets and carrying them across the current Internet). Other solutions consist of placing equipment which performs address and protocol translation at the borders between networks based on different protocols: this is a simple extension of the NAT (Network Address Translator) concept, which thus progresses from being an alternative to IPv6 to being an effective aid to transition. Yet other solutions involve using application gateways or proxies to provide interoperability between applications resident on terminals attached to non-homogeneous networks.

A final class of solutions, such as the Tunnel Broker service proposed by CSELT (https://carmen.cselt.it/ipv6tb) together with IMAG in Grenoble, aims at assisting individual users (including those employing dial-up access) in the procedures involved in connecting to IPv6 networks and services via the current Internet.

The network is organized as a three-layer hierarchical structure. The highest hierarchical level consists of the backbone nodes, and is the portion of the network on which the geographical connectivity enjoyed by all of the other connected nodes is chiefly based. At the next-lower level are the 6Bone transit nodes, i.e., nodes connected to at least one backbone node but which in turn act as points of access to the network for one or more nodes that do not have a direct tunnel to the backbone. The latter nodes are the lowest hierarchical level of the current 6Bone network structure, and are called leaf nodes.

At the moment, the backbone consists of over 60 nodes (including two in Italy: CSELT and INFN-CNAF) and accounts for most of the complexity of 6Bone routing. Connectivity between backbone nodes is guaranteed by a large number of tunnels established through the Internet and forming an arbitrary mesh topology in which IPv6 packet routing is based on the BGP4+ dynamic routing protocol (a version of BGP4 capable of supporting IPv6 as well as IPv6).

CSELT's connections in the 6bone backbone

The figure shows a map of CSELT's connections in the 6Bone backbone (further information about the work now being done at CSELT's IPv6 laboratory is available on the site http://carmen.cselt.it/ipv6).

Together with CSELT, other participants in the initiative include equipment manufacturers (Cisco, Bay Networks, Digital, etc.), TLC operators (MCI, SPRINT, etc.), Internet Service Providers (UUNET, ANSNET, SURFNET, etc.), research centers and universities.

It should be noted that the 6Bone initiative is also giving birth to the first native IPv6 research networks (CAIRN, vBNS/Internet2, WIDE and DARENet). In addition, a number of major ISPs (UUNet, ANSNet) and governmental networks in the U.S. (ESNet) have begun to install IPv6 routers alongside their backbone routers in order to create experimental IPv6 networks. Though largely based on tunnels established on the existing IPv4 infrastructure, these experimental networks make it possible to provide "friendly" users with interconnection service based on the new-generation IP protocol.

Several ISPs are showing signs of wanting to provide IPv6-based service in the fairly near future. Recently, for instance, AT&T, UUNet/Worldcom and other operators asked the Internet Assigned Numbers Authority (IANA) for an official IPv6 address space to be used in their networks. In response to these needs, IANA has already assigned a subset of IPv6 addresses to each of the registries responsible for allocating IP addresses in the United States (ARIN), Europe (RIPE-NCC) and Asia (APNIC), who will manage these addresses in their own areas of jurisdiction. This means that it will shortly be possible for an ISP to request and obtain IPv6 addresses from the registries, and use them to provide commercial services to its customers.

Thus, we can say that the Internet's transition towards the new-generation IP protocol is already under way, and got its start precisely from the experimental activities. There is every sign, moreover, that this transition will proceed "painlessly", and at least at the beginning can be limited to flanking the existing IPv4 infrastructure with IPv6 equipment.