IPng Candidates

Up to 1994, quite a few different proposals were made for the successor to IPv4. By 1992, the three dominant proposal families that would eventually be considered by the IETF in 1994 had already taken shape. RFC 1347, “TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing,” outlines one. TUBA can be characterized as

simply replacing IP with the OSI internetwork protocol, Connection-Less Network Protocol (CLNP). CLNP usesNetwork Service Access(NSAP) addresses that can be any length but that are often implemented in 20 bytes, providing more than enough address space. Furthermore, using CLNP would help IP and OSI to converge, while at the same time eliminating the need to build an entirely new protocol.

Another proposed IPng candidate was first known as IPv7 in 1992, and in 1993 was described in detail in RFC 1475 under the title “TP/IXTP/IX: The Next Internet.” It is not clear what TP/IX stands for; according to Christian Huitema inIPv6: The New Internet Protocol(Prentice Hall PTR, 1998), the name expresses the desire of its proposer, Robert Ullman, to change not only IP but also TCP with the upgrade. TP/IX uses 64-bit addresses and adds an addressing layer to the hierarchy, above organizations, for administrations.

Under IPv7, eight-byte addresses are used to allocate three bytes to admin-istrative domain, three to the organization’s network, and two bytes for the host identifier. The IPv7 datagram header simplifies the IPv4 header, while adding a forward route identifier to be used by intermediate routers to determine how to handle datagrams. For example, the forward route identifier may be associated with a particular route based on certain val-ues relating to the route itself (throughput or value) or to be associated with a particular datagram stream or even to be associated with data from a mobile host—that is, a host that moves from one network to another while maintaining open TCP connections. TP/IX not only modified TCP and UDP, but it also included a new routing protocol calledRAP.

TP/IX later evolved into another proposal, described in RFC 1707,

“CATNIP: Common Architecture for the Internet.” CATNIP seems to have little in common with TP/IX, however, except that it retains the IPv7 designation. In its goal of providing a common architecture, the CATNIP specification makes allowances for the three most commonly used internetwork architectures: TCP/IP, OSI, and IPX, as well as dis-cussion of how to integrate a competing proposed standard for the next generation of IP. The stated objective is to make it possible for all exist-ing systems to continue to interoperate with **/no/** modifications, no changes in address, and no software upgrades for individual hosts.

By making allowance for different network architectures, the CATNIP proposal meant to minimize impact on the actual infrastructure; how-ever, it meant adding a layer of complexity in order to implement true interoperable internetworking.

The third proposal stream started out as something calledIP in IP, orIP Encaps (for IP encapsulation). Under this proposal, there would be two layers of IP: One would be used for a global backbone, while the other would be used in more limited areas. The IP to be used in limited areas could continue to be IPv4, while the backbone would use a new layer with different addressing. Ultimately, this evolved and merged with other proposals to become theSimple Internet Protocol Plus(SIPP) proposal.

As explained in RFC 1710, “Simple Internet Protocol Plus White Paper,”

the SIPP working group grew from three different IETF working groups focused on developing an IPng. The first group was working on a ver-sion calledIP Address Encapsulation(IPAE); the working group, chaired by Dave Crocker and Robert Hinden, proposed extensions to IPv4 that would carry larger addresses, and the group focused on developing transition mechanisms.

Somewhat later, Steve Deering proposed a new protocol evolved from IPv4 called theSimple Internet Protocol(SIP). A working group was formed to work on this proposal, which was chaired by Steve Deering and Christian Huitema. SIP used 64-bit addresses, a simplified header, and options in separate extension headers. After lengthy interaction between the two working groups and the realization that IPAE and SIP had a number of common elements and the transition mechanisms developed for IPAE would apply to SIP, the groups decided to merge and concentrate their efforts. The chairs of the new SIP working group were Steve Deering and Robert Hinden.

In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded a working group to develop the “P” Internet Protocol (Pip). Pip was a new Internet protocol based on a new architecture. The motivation behind Pip was that the opportunity for introducing a new Internet protocol does not come very often and given that opportunity important new features should be introduced. Pip supported variable-length addressing in 16-bit units, separation of addresses from identifiers, support for provider selection, mobility, and efficient forwarding. It included a transition scheme similar to IPAE.

After considerable discussion among the leaders of the Pip and SIP working groups, they came to realize that the advanced features in Pip could be accomplished in SIP without changing the base SIP protocol as well as keeping the IPAE transition mechanisms. In essence, it was possible to keep the best features of each protocol. Based on this, the groups decided

to merge their efforts. The new protocol was called Simple Internet Protocol Plus (SIPP). The chairs of the merged working group are Steve Deering, Paul Francis, and Robert Hinden.

Briefly, SIPP offers several changes from IPv4, including the following.

Routing and addressing expansion SIPP specifies 64-bit addresses, double the size of IPv4. The intention is to provide greater degrees of hierarchy within which routing can be accomplished. Another feature is the addition ofcluster addresses, which identify regions of the network topology. SIPP address extensions, available in units of 64 bits, work with the cluster addresses to create the possibility of a much larger address space.

IP header simplification SIPP does away with some IPv4 header fields, while streamlining the structure to help improve routing efficiency.

Improvement in option implementation SIPP uses a more flexible approach to encoding and implementing IP options.

Quality of service SIPP makes it possible to label datagrams as belong-ing to specific data flows. Hosts can request special handlbelong-ing for the routing of these flows, especially useful for applications that depend on real-time delivery like that required by video or audio transmission.

Authentication and privacy SIPP adds extensions for authentication, data integrity, and confidentiality.

SIPP was the result of many people from several different groups working together. The finished specification includes many interesting new mech-anisms, while still not straying too far from the goal of being an upgrade to IPv4 rather than an entirely new protocol built from the ground up.

Notable is the use of routing similar to that in IPv4, still using CIDR to add flexibility and improve routing performance. Also important are new routing extensions that allow choice of routes from different providers based on various criteria (including performance, cost, provider policies for traffic, and so on). Other routing extensions include support for mobile hosts as well as automatic readdressing and extended addressing.

One other notable mechanism is the SIPP approach to IP options: Rather than including them as part of the basic IP header, SIPP segregates any

IP options from the main header. The options headers, if any, are simply inserted into the datagram after the header and before the transport layer protocol header. This way, routers can process datagrams without having to process the options headers unless it is necessary—thus improving performance overall for all datagrams.

RFC 1710 provides both a technical overview to the SIPP specification and a readable justification and narrative of the protocol. It is worth a look, if only to see how IPv6 as we know it came to be—because SIPP, with some modifications, was the specification recommended to and accepted by the IESG as the basis for IPng.