Ken Larson - Papers on IT
Designing the Internet Protocol: Next Generation (IPng)
Prepared for IST 656, Telecommunications and Information Network Technology, November 14, 1994
November 1997 note: the new Web address of the IETF site has been added, but the current locations of the documents cited here have not been updated. They may be most easily findable through search tools on the IETF or InterNIC sites.
The address scheme of the current Internet Protocol (IPv4--32 bits divided into four eight-bit parts--would seem to provide for over four billion addresses: one for almost every person on the planet. But for practical reasons, addresses are not assigned one-by-one in a way that would allocate address space most efficiently, but rather are assigned in large blocks to networks. Besides the near impossibility of making one administrative body responsible for assigning and keeping track of an address for every Internet-accessible device (computer, printer, router, etc.) in the world, the assignment of large blocks of addresses to networks makes it possible to reduce the amount of information needed in the routing tables of the Internet's backbone routers. These routers thus merely need to know the location of other networks and how to direct datagrams to them, leaving it up to the networks themselves to direct the datagrams to individual devices. But one consequence of the rapid growth of the Internet has been that even with this scheme, the number of networks joining the Internet each year has caused the amount of information in the routing tables of the backbone routers to increase at a potentially alarming rate--faster, for example, than the rate of improvement in memory technology. The problems of address space depletion and routing table explosion are thus linked, since an attempt to solve the first problem by allocating addresses more "efficiently" (assigning addresses in smaller blocks) merely worsens the second problem, by increasing the number of networks that backbone routers must keep track of in their routing tables. To solve both problems, a new Internet Protocol would not only need to support larger addresses but would need to use an addressing scheme that aggregates networks in hierarchies based on provider, geographic location, or some other principle, so that any given router would need to know only one or two hierarchical levels of information rather than knowing the location of individual networks as in a "flat" addressing scheme.
Even though the immediate motivation for designing a new Internet Protocol was concern about address depletion and the increase of information in routing tables, network engineers were also acutely aware of other deficiencies in today's Internet that could be remedied by a new Internet Protocol. If the Internet Protocol was to be redesigned in any case to support larger addresses and a different addressing structure, it made sense to use this opportunity to make other design changes as well that will give the Internet new functionalities, some of which may be crucial for its uses in the future. Among the most important features considered possible with a new Internet Protocol are security (both authentication and encryption), plug-and-play autoconfiguration of network devices, support for mobility, and the ability to set up traffic "flows" that will make it easier for the Internet to deliver real-time services such as voice and video. Of these, the last feature represents the greatest break with the pure datagram nature of IPv4.
The work of the IETF is divided into approximately ten areas (Routing, Security, Transport, etc.), the chairs of which ("area directors") compose the Internet Engineering Steering Group (IESG). Some degree of hierarchy enters the Internet process in that the IETF submits proposed standards to the IESG for approval. In cases of disagreement, IESG decisions can be appealed still one level higher to the Internet Architecture Board (IAB), whom Ed Krol describes as the Internet's "Council of Elders,"2 but there has not yet been such an appeal. In fact, decisions seem to be made almost entirely on the basis of developing broad consensus throughout the IETF community. Such a process could clearly be put to a severe test by something so fundamental as developing a new Internet Protocol, especially given that various IETF working groups invested a great deal of time and energy in preparing different candidates for IPng, only one of which could be chosen. The IETF's success in developing IPng (at least as it appears in mid-November, 1994) seems to be a sign of the success of the Internet's engineering and decision-making model altogether.
Although the IETF had begun discussion and work on a new IP by late 1991 (four proposals were ready by February 1992, and three more were ready by December, 1992), the most intensive work began in September, 1993, when the chair of the IESG, Phil Gross, issued the memo "A Direction for IPng," based largely on the discussions at the July, 1993 IETF meeting in Amsterdam. Gross created a temporary IPng Area within the IETF, and charged its co-directors to:
The importance of determining the urgency of the problem derived from the need to know whether there was time to incorporate a broad range of desirable new features into IPng, or whether the problem of address space depletion was so urgent that the project needed to be limited to finding an immediate solution for that single issue. To investigate this question, the IPng area directorate formed a working group called ALE (Address Lifetime Expectations). The ALE group eventually came to a conclusion that current IP addresses would probably not be exhausted until sometime between 2005 and 2011--if there was no paradigm shift in the use of the Internet. By "paradigm shift" the ALE group meant the unexpected introduction of a "killer application." The example of such an application that ALE specifically mentioned was the possible incorporation of TCP/IP into set-top cable boxes, permitting tens of millions of televisions to speak IP more or less overnight. The projection of 2005 as a likely date of address exhaustion gave the IPng area directorate confidence that there was probably time to incorporate a range of new features into the new IP; but the impossibility of being sure that there would be no paradigm shift caused the area directorate to move ahead in the design and selection process with all deliberate speed.
To help determine the necessary features of the new IP, the IPng area directorate sent out a solicitation for "white papers" describing what IPng should accomplish. Based on the white papers and discussions within the directorate and the IETF generally (including on various mailing lists), the directorate created a document, "Technical Criteria for Choosing IPng." At a two-day retreat in March, 1994 the area directorate reviewed the candidates for IPng against the requirements, and found all of the proposals lacking. After the retreat one of the working groups revised its proposal to a degree that it was able to meet the directorate's criteria and overcome the objections. Proponents of each of the candidates for IPng were present within the IPng area directorate, but the directorate was nevertheless able to reach consensus on recommending the revised proposal as the next generation Internet Protocol at the July, 1994 IETF in Toronto.
CATNIP (Common Architecture for the Internet) [the letter-by-letter origin of the acronym is unclear] was widely perceived as being one of the most ambitious and innovative proposals. CATNIP was designed as a "convergence protocol," integrating IP, Novell's IPX, and the network layer protocol of the OSI suite, CLNP. The idea was to allow any transport layer in use to run over any of the network layer formats. CATNIP would thus create a "common ground between the Internet, OSI, and Novell protocols."3
SIPP (Simple Internet Protocol Plus) was presented as a more modest effort, an evolutionary step from the current IP (IPv4) and interoperable with IPv4. It would require no "flag day" on which everyone would have to change from IPv4 to IPng. One of SIPP's chief features was its decision to use a fixed-length address, now consisting of 64 bits rather than IPv4's 32 bits. The 64-bit address included the use of hierarchical "cluster" addresses identifying topological regions rather than merely networks, thus resolving the problem of routing table explosion. SIPP's designers detailed how it would provide the full feature set demanded by the "Requirements" document: labeling of packets belonging to particular traffic "flows" for which the sender could request special handling (such as real-time service for audio and video), autoconfiguration, support for mobility, and provision for network-layer authentication and encryption.
TUBA (TCP and UDP with Bigger Addresses) seemed from the "TCP" and "UDP" in its name to be a modest revision of the Internet's TCP/IP suite, but in fact was a proposal to adopt the OSI network layer (CLNP) as the new Internet network layer. CLNP had been created long enough after TCP/IP that it was already clear to its designers that a world-wide network would need to provide for far more addresses than IP did. CLNP could thus be used to solve the address space problem that had launched the IPng effort. But the problem of running TCP or UDP on top of CLNP was not entirely trivial (TCP reaches into the network layer for checksums, for example), so TUBA needed to specify how to adapt the transport layer protocols to work with CLNP. One of the chief features of the TUBA proposal compared with SIPP was that TUBA uses variable-length addresses. TUBA proponents argued that no one would ever be able to predict how large the Internet might become or how it might someday be structured; thus it was essential to build in the possibility to create any length and structure of address by using variable-length addressing.
By contrast, the SIPP proposal, now in a revised form taking into account the original objections, managed to meet all the requirements of IPng. The revised proposal continued to be based on fixed-length addresses, but the address size was increased from 64 bits to 128 bits--four times the size of current IPv4 addresses. While some groups within the area directorate and the IETF as a whole continue to feel uneasy about fixed-length addresses of any size, SIPP was able to convince most examiners that it would be able to support the Internet at least into a fairly distant future, and that it should be the basis for the IPng effort. Nearly all examiners found it "elegant": despite the quadrupling of address size, SIPP ("Simple" IP) is able to keep its header to only twice the size of that of IPv4.
On the basis of consensus within the IPng area directorate, the IESG, and (apparently) the July, 1994 IETF that SIPP should become IPng, the SIPP documents were declared to be the basis for IPng and the SIPP working group disbanded in order to reconstitute itself as the new working group for IPng. IPng was officially renamed IPv6. (The Internet will thus move directly from "version 4" to "version 6" of IP.) The IPv6 documents entered into a Last Call discussion phase, scheduled to end on November 11, 1994, and should be ready for submission as Proposed Standards in December, 1994. According to the time line proposed by the IPng area directorate, the first beta versions of software incorporating IPv6 should be ready by July, 1995, with the first actual production software released by December, 1995. The release of the new software would merely mark the beginning of the Internet's transition from IPv4 to IPv6. Transition planning was an important part of all the IPng proposals, and an essential element of the SIPP plan was the provision for a gradual move to the new version. SIPP proposed that IPv4 and IPv6 would coexist on the Internet for some years, and even assumed that some hosts would never upgrade to IPv6 and yet would continue to interoperate with the rest of the network. At least at the beginning, IPv6 would tunnel between "islands" of IPv6 capability through portions of the Internet capable only of IPv4. In effect, a "virtual" IPv6 Internet would be built upon the physical Internet; as more and more hosts, networks, and backbone routers moved to IPv6, the virtual would begin to become identical with the physical.
If the IETF succeeds in turning its apparent consensus on IPng into a new, vastly more capable Internet Protocol deployed throughout the world it will have demonstrated not only an extraordinary feat of engineering but an equally remarkable decision-making process. Given the importance of the Internet to governments, corporations, and many millions of users, it is close to astonishing that something so fundamental as a new network layer protocol could be created and selected through an entirely open process of building consensus among people interested only in finding the best technical solution to problems. The process is particularly remarkable given that, unlike the early days of the Internet when it was only a research tool, there is clearly money to be made in everything having to do with the media's newly-discovered "Information Superhighway"--a lot of money. The "culture" of nearly all corporations would seem to dictate finding proprietary solutions that they could control. The creation of the new Internet Protocol shows how remarkably open the IETF process is, and demonstrates the vitality of TCP/IP as an open standard. The TCP/IP suite is clearly open not simply because it was invented and given away by the U.S. government long ago, but because it continues to grow and evolve within an open process. Anyone who was convinced that TCP/IP would simply go away in time as a dated suite, to be replaced by more up-to-date OSI protocols, must surely find their assurance challenged by IPv6 and the process that created it.
The make-up of the IPng area directorate, which was chiefly responsible for selecting the new Internet Protocol, gives an interesting insight into the IETF process and underscores the vitality of the TCP/IP open standards. Of the nineteen members of the area directorate (counting the two area co-directors), only three came from educational or non-profit research institutions, one from a non-profit regional network, and one from the government (Naval Research Laboratory). The others had "day jobs" at corporations that are definitely for-profits (and that necessarily had to grant them a considerable amount of release time to pursue their IETF work): Ameritech, AT&T, Boeing, Cisco, Digital, Lotus, Microsoft, Novell, NTT, Wellfleet, and Xerox (x2). At least some of these corporations might be assumed to be interested in pursuing a proprietary version of the "Information Superhighway" that would give them the kind of market dominance that Microsoft has enjoyed in PC operating systems and Novell in LAN operating systems. The fact that engineers from all these companies were able to work together on the IPng process and to come to a consensus that favors no company or industry over another is a sign that the IETF process seems to continue to be viable even when so much money is at stake--money that can potentially be made by all in supporting TCP/IP as a live and evolving open standard.
Bradner, S., Mankin, A, "IP Next Generation (IPng)" [Slides for the IPng Area Directorate's presentation of its decision at the July, 1994 IETF]. July, 1994. <at ietf.cnri.reston.va.us: ietf-online-proceedings/94july/presentations/bradner/pre.bradner.mankin.slides.txt>
Bradner, S., Mankin, A, "IP: Next Generation (IPng) White Paper Solicitation," RFC 1550. December, 1993. <rfc/rfc1550.txt>
Hinden, R., "IP Next Generation Overview," Internet Draft. October, 1994. <internet-drafts/draft-hinden-ipng-overview-00.txt> [Represents a revision of the SIPP White Paper below]
[Anonymous], "IETF Working Group Summary (by Area)." <ietf/1wg-summary.txt>
[Anonymous], "On-Line IETF Information." <ietf/1directories.txt>
Coya, S., "IPNG Directorate Teleconference [Minutes], Nov. 22, Dec. 6, Dec. 20, 1993, Jan. 17, Jan. 25, Valentine's Day [!], March 14, March 21, March 31, April 11, April 25, May 9, July 11, July 18, Aug. 15, Aug. 29, 1994. <iesg/ipng/ipng.93-11-22, 93-12-06, etc.>
Malkin, G., "The Tao of the IETF," RFC 1539 (FYI 17), October, 1993. <ietf/0tao.txt>
Stewart, J., "Internet Engineering Steering Group" [Minutes], 25 August, 8 September, 22 September, 6 October, 1994. <iesg/iesg.94-08-25, 94-09-08, etc.>
Deering, S., "Simple Internet Protocol Plus (SIPP) Specification (128-bit address version)," Internet Draft. July 17, 1994. <internet-drafts/draft-ietf-sipp-spec-01.txt>
Ford, P., Knopper, M., "TUBA as IPng: A White Paper," Draft 0.5, Internet Draft. March 20, 1994. <internet-drafts/draft-ford-ipng-tuba-whitepaper-00.txt>
Hinden, R., "Simple Internet Protocol Plus White Paper," RFC 1710. October, 1994 [Must actually be from before March, 1994]. <rfc/rfc1710.txt>
Besides providing documents such as protocol specifications and minutes from meetings, the Internet serves the day-to-day discussion of issues through mailing lists. At the moment (mid-November, 1994), it seems that the most important discussion of IPng is taking place on the general IETF mailing list (membership requests are sent to: ietf-request@cnri.reston.va.us). It is remarkable to experience the "heroes" of the Internet, the people who created the various IPng candidates, in daily conversation (and argument) about the features of the proposal. In the week leading up to November 11, 1994 (the last day of the IPng Last Call period), the discussants on the list have included some of the most important architects and theorists of the Internet, such as Steve Deering (the chief designer of SIPP), Noel Chiappa, Dave Crocker, Christian Huitema, Stev Knowles, Greg Minshall, and Craig Partridge.
Carl Malamud's interviews with some of the people most deeply involved in today's Internet engineering provide background to the topic of IPng. The interviews were originally multicast over the Internet's multicast backbone (MBONE) on Internet Talk Radio's "Geek of the Week"; selected interviews are also available on cassette tapes from O'Reilly and Associates. One series of eight 30-minute interviews, taped mainly at the July, 1993 Amsterdam IETF and brought together as The Future of the Internet Protocol, is especially relevant. It includes interviews with some of the main designers of SIPP (Steve Deering, Bob Hinden) and TUBA (Peter Ford) as well as with others in the Internet community with insights into the issues behind IPng (Bob Braden [Executive Director of the IAB], Christian Huitema, Craig Partridge, Steve Casner, and Noel Chiappa).
2 Ed Krol, The Whole Internet: User's Guide and Catalog, 2nd ed. (Sabastopol CA: O'Reilly and Associates, 1994) p. 16
3 Bradner and Mankin, "The Recommendation for the IP Next Generation Protocol," Internet Draft, 1994, p. 13 [See "Sources' above.]
Prepared: November 14, 1994
Return to Ken Larson Home Page
This page belongs to Ken Larson, who is solely responsible for its content. Please see our statement of responsibility.