Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1752

The Recommendation for the IP Next Generation Protocol

Pages: 52
Proposed Standard
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   RFC1752 - Page 1
Network Working Group                                         S. Bradner
Request for Comments: 1752                            Harvard University
Category: Standards Track                                      A. Mankin
                                                            January 1995

         The Recommendation for the IP Next Generation Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This document presents the recommendation of the IPng Area Directors
   on what should be used to replace the current version of the Internet
   Protocol.  This recommendation was accepted by the Internet
   Engineering Steering Group (IESG).

Table of Contents

   1.        Summary. . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.        Background . . . . . . . . . . . . . . . . . . . . . . .  4
   3.        A Direction for IPng . . . . . . . . . . . . . . . . . .  5
   4.        IPng Area. . . . . . . . . . . . . . . . . . . . . . . .  6
   5.        ALE Working Group. . . . . . . . . . . . . . . . . . . .  6
     5.1     ALE Projections. . . . . . . . . . . . . . . . . . . . .  7
     5.2     Routing Table Size . . . . . . . . . . . . . . . . . . .  7
     5.3     Address Assignment Policy Recommendations. . . . . . . .  8
   6.        IPng Technical Requirements. . . . . . . . . . . . . . .  8
     6.1     The IPng Technical Criteria document . . . . . . . . . .  9
   7.        IPng Proposals . . . . . . . . . . . . . . . . . . . . . 11
     7.1     CATNIP. . .  . . . . . . . . . . . . . . . . . . . . . . 11
     7.2     SIPP. . . .  . . . . . . . . . . . . . . . . . . . . . . 12
     7.3     TUBA. . . .  . . . . . . . . . . . . . . . . . . . . . . 13
   8.        IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 13
     8.1     CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 14
     8.2     SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 15
     8.3     TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 16
     8.4     Summary of Proposal Reviews. . . . . . . . . . . . . . . 17
   9.        A Revised Proposal . . . . . . . . . . . . . . . . . . . 17
   10        Assumptions .  . . . . . . . . . . . . . . . . . . . . . 18
     10.1    Criteria Document and Timing of Recommendation . . . . . 18
Top   ToC   RFC1752 - Page 2
     10.2    Address Length . . . . . . . . . . . . . . . . . . . . . 19
   11.       IPng Recommendation. . . . . . . . . . . . . . . . . . . 19
     11.1    IPng Criteria Document and IPng. . . . . . . . . . . . . 20
     11.2    IPv6. . . . .  . . . . . . . . . . . . . . . . . . . . . 21
   12.       IPv6 Overview  . . . . . . . . . . . . . . . . . . . . . 21
     12.1    IPv6 Header Format . . . . . . . . . . . . . . . . . . . 24
     12.2    Extension Headers. . . . . . . . . . . . . . . . . . . . 25
     12.2.1  Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 25
     12.2.2  IPv6 Header Options. . . . . . . . . . . . . . . . . . . 26
     12.2.3  Routing Header . . . . . . . . . . . . . . . . . . . . . 27
     12.2.4  Fragment Header. . . . . . . . . . . . . . . . . . . . . 28
     12.2.5  Authentication Header. . . . . . . . . . . . . . . . . . 29
     12.2.6  Privacy Header . . . . . . . . . . . . . . . . . . . . . 30
     12.2.7  End-to-End Option Header . . . . . . . . . . . . . . . . 32
   13.       IPng Working Group . . . . . . . . . . . . . . . . . . . 32
   14.       IPng Reviewer  . . . . . . . . . . . . . . . . . . . . . 33
   15.       Address Autoconfiguration. . . . . . . . . . . . . . . . 33
   16.       Transition . . . . . . . . . . . . . . . . . . . . . . . 34
     16.1    Transition - Short Term. . . . . . . . . . . . . . . . . 35
     16.2    Transition - Long Term . . . . . . . . . . . . . . . . . 36
   17.       Other Address Families . . . . . . . . . . . . . . . . . 37
   18.       Impact on Other IETF Standards . . . . . . . . . . . . . 38
   19.       Impact on non-IETF standards and on products . . . . . . 39
   20.       APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   21.       Future of the IPng Area and Working Groups . . . . . . . 40
   22.       Security Considerations. . . . . . . . . . . . . . . . . 40
   23.       Authors' Addresses . . . . . . . . . . . . . . . . . . . 43

   Appendix A    Summary of Recommendations . . . . . . . . . . . . . 44
   Appendix B    IPng Area Directorate. . . . . . . . . . . . . . . . 45
   Appendix C    Documents Referred to the IPng Working Groups. . . . 46
   Appendix D    IPng Proposal Overviews. . . . . . . . . . . . . . . 46
   Appendix E    RFC 1550 White Papers. . . . . . . . . . . . . . . . 47
   Appendix F    Additional References. . . . . . . . . . . . . . . . 48
   Appendix G    Acknowledgments. . . . . . . . . . . . . . . . . . . 52

1. Summary

   The IETF started its effort to select a successor to IPv4 in late
   1990 when projections indicated that the Internet address space would
   become an increasingly limiting resource.  Several parallel efforts
   then started exploring ways to resolve these address limitations
   while at the same time providing additional functionality.  The IETF
   formed the IPng Area in late 1993 to investigate the various
   proposals and recommend how to proceed.  We developed an IPng
   technical criteria document and evaluated the various proposals
   against it.  All were found wanting to some degree.  After this
   evaluation, a revised proposal was offered by one of the working
Top   ToC   RFC1752 - Page 3
   groups that resolved many of the problems in the previous proposals.
   The IPng Area Directors recommend that the IETF designate this
   revised proposal as the IPng and focus its energy on bringing a set
   of documents defining the IPng to Proposed Standard status with all
   deliberate speed.

   This protocol recommendation includes a simplified header with a
   hierarchical address structure that permits rigorous route
   aggregation and is also large enough to meet the needs of the
   Internet for the foreseeable future. The protocol also includes
   packet-level authentication and encryption along with plug and play
   autoconfiguration.  The design changes the way IP header options are
   encoded to increase the flexibility of introducing new options in the
   future while improving performance. It also includes the ability to
   label traffic flows.

   Specific recommendations include:

   * current address assignment policies are adequate
   * there is no current need to reclaim underutilized assigned network
   * there is no current need to renumber major portions of the Internet
   * CIDR-style assignments of parts of unassigned Class A address space
     should be considered
   * "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)"
     [Deering94b] be adopted as the basis for IPng
   * the documents listed in Appendix C be the foundation of the IPng
   * an IPng Working Group be formed, chaired by Steve Deering and Ross
   * Robert Hinden be the document editor for the IPng effort
   * an IPng Reviewer be appointed and that Dave Clark be the reviewer
   * an Address Autoconfiguration Working Group be formed, chaired by
     Dave Katz and Sue Thomson
   * an IPng Transition Working Group be formed, chaired by Bob Gilligan
     and TBA
   * the Transition and Coexistence Including Testing Working Group be
   * recommendations about the use of non-IPv6 addresses in IPv6
     environments and IPv6 addresses in non-IPv6 environments be
   * the IESG commission a review of all IETF standards documents for
     IPng implications
   * the IESG task current IETF working groups to take IPng into account
   * the IESG charter new working groups where needed to revise old
     standards documents
   * Informational RFCs be solicited or developed describing a few
     specific IPng APIs
Top   ToC   RFC1752 - Page 4
   * the IPng Area and Area Directorate continue until main documents
     are offered as Proposed Standards in late 1994
   * support for the Authentication Header be required
   * support for a specific authentication algorithm be required
   * support for the Privacy Header be required
   * support for a specific privacy algorithm be required
   * an "IPng framework for firewalls" be developed

2. Background

   Even the most farseeing of the developers of TCP/IP in the early
   1980s did not imagine the dilemma of scale that the Internet faces
   today.  1987 estimates projected a need to address as many as 100,000
   networks at some vague point in the future. [Callon87]  We will reach
   that mark by 1996.  There are many realistic projections of many
   millions of interconnected networks in the not too distant future.
   [Vecchi94, Taylor94]

   Further, even though the current 32 bit IPv4 address structure can
   enumerate over 4 billion hosts on as many as 16.7 million networks,
   the actual address assignment efficiency is far less than that, even
   on a theoretical basis. [Huitema94]  This inefficiency is exacerbated
   by the granularity of assignments using Class A, B and C addresses.

   In August 1990 during the Vancouver IETF meeting, Frank Solensky,
   Phill Gross and Sue Hares projected that the current rate of
   assignment would exhaust the Class B space by March of 1994.

   The then obvious remedy of assigning multiple Class C addresses in
   place of Class B addresses introduced its own problem by further
   expanding the size of the routing tables in the backbone routers
   already growing at an alarming rate.

   We faced the dilemma of choosing between accepting either limiting
   the rate of growth and ultimate size of the Internet, or disrupting
   the network by changing to new techniques or technologies.

   The IETF formed the Routing and Addressing (ROAD) group in November
   1991 at the Santa Fe IETF meeting to explore this dilemma and guide
   the IETF on the issues.  The ROAD group reported their work in March
   1992 at the San Diego IETF meeting.  [Gross92]  The impact of the
   recommendations ranged from "immediate" to "long term" and included
   adopting the CIDR route aggregation proposal [Fuller93] for reducing
   the rate of routing table growth and recommending a call for
   proposals "to form working groups to explore separate approaches for
   bigger Internet addresses."
Top   ToC   RFC1752 - Page 5
   In the late spring of 1992 the IAB issued "IP version 7" [IAB92],
   concurring in the ROAD group's endorsement of CIDR and also
   recommending "an immediate IETF effort to prepare a detailed and
   organizational plan for using CLNP as the basis for IPv7." After
   spirited discussion, the IETF decided to reject the IAB's
   recommendation and issue the call for  proposals recommended by the
   ROAD group.  This call was issued in July 1992 at the Boston IETF
   meeting and a number of working groups were formed in response

   During the July 1993 Amsterdam IETF meeting an IPng (IP Next
   Generation) Decision Process (ipdecide) BOF was held.  This BOF "was
   intended to help re-focus attention on the very important topic of
   making a decision between the candidates for IPng. The BOF focused on
   the issues of who should take the lead in making the recommendation
   to the community and what criteria should be used to reach the
   recommendation." [Carpen93]

3. A Direction for IPng

   In September 1993 Phill Gross, chair of the IESG issued "A Direction
   for IPng".  [Gross94]  In this memo he summarized the results of the
   ipdecide BOF and open IESG plenary in Amsterdam.

   * The IETF needs to move toward closure on IPng.
   * The IESG has the responsibility for developing an IPng
     recommendation for the Internet community.
   * The procedures of the recommendation-making process should be open
     and published well in advance by the IESG.
   * As part of this process, the IPng WGs may be given new milestones
     and other guidance to aid the IESG.
   * There should be ample opportunity for community comment prior to
     final IESG recommendation.

   The memo also announced "a temporary, ad hoc, 'area' to deal
   specifically with IPng issues."  Phill asked two of the current IESG
   members, Allison Mankin (Transport Services Area) and Scott Bradner
   (Operational Requirements Area), to act as Directors for the new
   area. The Area Directors were given a specific charge on how to
   investigate the various IPng proposals and how to base their
   recommendation to the IETF.  It was also requested that a specific
   recommendation be made.

   * Establish an IPng directorate.
   * Ensure that a completely open process is followed.
   * Develop an understanding of the level of urgency and the time
     constraints imposed by the rate of address assignment and rate of
     growth in the routing tables.
   * Recommend the adoption of assignment policy changes if warranted.
Top   ToC   RFC1752 - Page 6
   * Define the scope of the IPng effort based on the understanding of
     the time constraints.
   * Develop a clear and concise set of technical requirements and
     decision criteria for IPng.
   * Develop a recommendation about which of the current IPng candidates
     to accept, if any.

4. IPng Area

   After the IPng Area was formed, we recruited a directorate. (Appendix
   B) The members of the directorate were chosen both for their general
   and specific technical expertise.  The individuals were then asked to
   have their management authorize this participation in the process and
   confirm that they understood the IETF process.

   We took great care to ensure the inclusion of a wide spectrum of
   knowledge. The directors are experts in security, routing, the needs
   of large users, end system manufacturers, Unix and non-Unix
   platforms, router manufacturers, theoretical researchers, protocol
   architecture, and the operating regional, national, and international
   networks.  Additionally, several members of the directorate were
   deeply involved in each of the IPng proposal working groups.

   The directorate functions as a direction-setting and preliminary
   review body as requested by the charge to the area.  The directorate
   engages in biweekly conference calls, participates in an internal
   mailing list and corresponds actively on the Big-Internet mailing
   list. The directorate held open meetings during the March 1994
   Seattle and July 1994 Toronto IETF meetings as well as two additional
   multi-day retreats.  To ensure that the IPng process was as open as
   possible, we took minutes during these meetings and then published
   them. Additionally, we placed the archives of the internal IPng
   mailing list on an anonymous ftp site. (

5. ALE Working Group

   We needed a reasonable estimate of the time remaining before we
   exhausted the IPv4 address space in order to determine the scope of
   the IPng effort.  If the time remaining was about the same needed to
   deploy a replacement, then we would have select the IPng which would
   only fix the address limitations since we would not have enough time
   to develop any other features.  If more time seemed available, we
   could consider additional improvements.

   The IETF formed an Address Lifetime Expectations (ALE) Working Group
   in 1993 "to develop an estimate for the remaining lifetime of the
   IPv4 address space based on currently known and available
Top   ToC   RFC1752 - Page 7
   technologies." [Solens93a]  Tony Li of Cisco Systems and Frank
   Solensky of FTP Software are the co-chairs.  The IETF also charged
   the working group to consider if developing more stringent address
   allocation and utilization policies might provide more time for the

5.1 ALE Projections

   The ALE Working Group met during the November 1993 Houston,
   [Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto
   [Solens94] IETF meetings.  They projected at the Seattle meeting,
   later confirmed at the Toronto meeting that, using the current
   allocation statistics, the Internet would exhaust the IPv4 address
   space between 2005 and 2011.

   Some members of the ipv4-ale and big-internet mailing lists called
   into question the reliability of this projection.  It has been
   criticized as both too optimistic and as too pessimistic.

   Some people pointed out that this type of projection makes an
   assumption of no paradigm shifts in IP usage.  If someone were to
   develop a new 'killer application', (for example cable-TV set top
   boxes.)  The resultant rise in the demand for IP addresses could make
   this an over-estimate of the time available.

   There may also be a problem with the data used to make the
   projection.  The InterNIC allocates IP addresses in large chunks to
   regional Network Information Centers (NICs) and network providers.
   The NICs and the providers then re-allocate addresses to their
   customers.  The ALE projections used the InterNIC assignments without
   regard to the actual rate of assignment of addresses to the end
   users.  They did the projection this way since the accuracy of the
   data seems quite a bit higher.  While using this once-removed data
   may add a level of over-estimation since it assumes the rate of large
   block allocation will continue, this may not be the case.

   These factors reduce the reliability of the ALE estimates but, in
   general, they seem to indicate enough time remaining in the IPv4
   address space to consider adding features in an IPng besides just
   expanding the address size even when considering time required for
   development, testing, and deployment.

5.2 Routing Table Size

   Another issue in Internet scaling is the increasing size of the
   routing tables required in the backbone routers.  Adopting the CIDR
   block address assignment and aggregating routes reduced the size of
   the tables for awhile but they are now expanding again. Providers now
Top   ToC   RFC1752 - Page 8
   need to more aggressively advertise their routes only in aggregates.
   Providers must also advise their new customers to renumber their
   networks in the best interest of the entire Internet community.

   The problem of exhausting the IPv4 address space may be moot if this
   issue is ignored and if routers cannot be found that can keep up with
   the table size growth.  Before implementing CIDR the backbone routing
   table was growing at a rate about 1.5 times as fast as memory

   We should also note that even though IPng addresses are designed with
   aggregation in mind switching to IPng will not solve the routing
   table size problem unless the addresses are assigned rigorously to
   maximize the affect of such aggregation.  This efficient advertising
   of routes can be maintained since IPng includes address
   autoconfiguration mechanisms to allow easy renumbering if a customer
   decides to switch providers.  Customers who receive service from more
   than one provider may limit the ultimate efficiency of any route
   aggregation. [Rekhter94]

5.3 Address Assignment Policy Recommendations

   The IESG Chair charged the IPng Area to consider recommending more
   stringent assignment policies, reclaiming some addresses already
   assigned, or making a serious effort to renumber significant portions
   of the Internet. [Gross94]

   The IPng Area Directors endorse the current address assignment
   policies in view of the ALE projections.  We do not feel that anyone
   should take specific efforts to reclaim underutilized addresses
   already assigned or to renumber forcefully major portions of the
   Internet.  We do however feel that we should all encourage network
   service providers to assist new customers in renumbering their
   networks to conform to the provider's CIDR assignments.

   The ALE Working Group recommends that we consider assigning CIDR-type
   address blocks out of the unassigned Class A address space.  The IPng
   Area Directors concur with this recommendation.

6. IPng Technical Requirements

   The IESG provided an outline in RFC 1380 [Gross92] of the type of
   criteria we should use to determine the suitability of an IPng
   proposal.  The IETF further refined this understanding of the
   appropriate criteria with the recommendations of a Selection Criteria
   BOF held during the November 1992 IETF meeting in Washington D.C.
   [Almqu92]  We felt we needed to get additional input for determining
   the requirements and issued a call for white papers. [Bradner93] This
Top   ToC   RFC1752 - Page 9
   call, issued as RFC 1550, intended to reach both inside and outside
   the traditional IETF constituency to get the broadest possible
   understanding of the requirements for a data networking protocol with
   the broadest possible application.

   We received twenty one white papers in response to the RFC 1550
   solicitation. ( Appendix E)  We received responses from the
   industries that many feel will be the major providers of data
   networking services in the future; the cable TV industry [Vecchi94],
   the cellular industry [Taylor94], and the electric power industry
   [Skelton94].  In addition, we received papers that dealt with
   military applications [Adam94, Syming94, Green94], ATM [Brazd94],
   mobility [Simpson94], accounting [Brown94], routing [Estrin94a,
   Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94,
   Flei94], large corporate networking [Britt94, Fleisch94], transition
   [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host
   implementations [Bound94], as well as a number of other issues.
   [Bello94a, Clark94, Ghisel94]

   These white papers, a Next Generation Requirements (ngreq) BOF
   (chaired by Jon Crowcroft and Frank Kastenholz) held during the March
   1994 Seattle IETF meeting, discussions within the IPng Area
   Directorate and considerable discussion on the big-internet mailing
   list were all used by Frank Kastenholz and Craig Partridge in
   revising their earlier criteria draft [Kasten92] to produce
   "Technical Criteria for Choosing IP The Next Generation (IPng)."
   [Kasten94]  This document is the "clear and concise set of technical
   requirements and decision criteria for IPng" called for in the charge
   from the IESG Chair.  We used this document as the basic guideline
   while evaluating the IPng proposals.

6.1 The IPng Technical Criteria document

   The criteria described in this document include: (from Kasten94)

   * complete specification - The proposal must completely describe the
     proposed protocol.  We must select an IPng by referencing specific
     documents, not to future work.
   * architectural simplicity - The IP-layer protocol should be as
     simple as possible with functions located elsewhere that are more
     appropriately performed at protocol layers other than the IP layer.
   * scale - The IPng Protocol must allow identifying and addressing at
     least 10**9 leaf-networks (and preferably much more)
   * topological flexibility - The routing architecture and protocols
     ofIPng must allow for many different network topologies.  They must
     not assume that the network's physical structure is a tree.
   * performance - A state of the art, commercial grade router must be
     able to process and forward IPng traffic at speeds capable of fully
Top   ToC   RFC1752 - Page 10
     utilizing common, commercially available, high-speed media at the
   * robust service - The network service and its associated routing and
     control protocols must be robust.
   * transition -  The protocol must have a straightforward transition
     plan from IPv4.
   * media independence -  The protocol must work across an internetwork
     of many different LAN, MAN, and WAN media, with individual link
     speeds ranging from a ones-of-bits per second to hundreds of
     gigabits per second.
   * datagram service - The protocol must support an unreliable datagram
     delivery service.
   * configuration ease -  The protocol must permit easy and largely
     distributed configuration and operation. Automatic configuration of
     hosts and routers is required.
   * security - IPng must provide a secure network layer.
   * unique names - IPng must assign unique names to all IP-Layer
     objects in the global, ubiquitous, Internet.  These names may or
     may not have any location, topology, or routing significance.
   * access to standards -  The protocols that define IPng and its
     associated protocols should be as freely available and
     redistributable as the IPv4 and related RFCs.  There must be no
     specification-related licensing fees for implementing or selling
     IPng software.
   * multicast support - The protocol must support both unicast and
     multicast packet transmission.   Dynamic and automatic routing of
     multicasts is also required.
   * extensibility -  The protocol must be extensible; it must be able
     to evolve to meet the future service needs of the Internet. This
     evolution must be achievable without requiring network-wide
     software upgrades.
   * service classes - The protocol must allow network devices to
     associate packets with particular service classes and provide them
     with the  services specified by those classes.
   * mobility - The protocol must support mobile hosts, networks and
   * control protocol - The protocol must include elementary support for
     testing and debugging networks. (e.g., ping and traceroute)
   * tunneling support -  IPng must allow users to build private
     internetworks on top of the basic Internet Infrastructure.  Both
     private IP-based internetworks and private non-IP-based (e.g., CLNP
     or AppleTalk) internetworks must be supported.
Top   ToC   RFC1752 - Page 11
7. IPng Proposals

   By the time that the IPng Area was formed, the IETF had already aimed
   a considerable amount of IETF effort at solving the addressing and
   routing problems of the Internet.  Several proposals had been made
   and some of these reached the level of having a working group
   chartered.  A number of these groups subsequently merged forming
   groups with a larger consensus.  These efforts represented different
   views on the issues which confront us and sought to optimize
   different aspects of the possible solutions.

   By February 1992 the Internet community developed four separate
   proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps"
   [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b].  By
   December 1992 three more proposals followed; "The P Internet
   Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP)
   [Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego
   IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger
   Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP
   Address Encapsulation" (IPAE) [Hinden92b].

   By November 1993, IPAE merged with SIP while still maintaining the
   name SIP. This group then merged with PIP and the resulting working
   group called themselves "Simple Internet Protocol Plus" (SIPP).  At
   the same time the TP/IX Working Group changed its name to "Common
   Architecture for the Internet" (CATNIP).

   None of these proposals were wrong nor were others right.  All of the
   proposals would work in some ways providing a path to overcome the
   obstacles we face as the Internet expands. The task of the IPng Area
   was to ensure that the IETF understand the offered proposals, learn
   from the proposals and provide a recommendation on what path best
   resolves the basic issues while providing the best foundation upon
   which to build for the future.

   The IPng Area evaluated three IPng proposals as they were described
   in their RFC 1550 white papers: CATNIP [McGovern94] , SIPP
   [Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much
   of a research project for consideration as an IPng candidate.  Since
   Nimrod represents one possible future Internet routing strategy we
   solicited a paper describing any requirements Nimrod would put on an
   IPng to add to the requirements process. [Chiappa94]


   "Common Architecture for the Internet (CATNIP) was conceived as a
   convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP
   design provides for any of the transport layer protocols in use, for
Top   ToC   RFC1752 - Page 12
   example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the
   network layer protocol formats: CLNP, IP (version 4), IPX, and
   CATNIP.  With some attention paid to details, it is possible for a
   transport layer protocol (such as TCP) to operate properly with one
   end system using one network layer (e.g., IP version 4) and the other
   using some other network protocol, such as CLNP." [McGovern94]

   "The objective is to provide common ground between the Internet, OSI,
   and the Novell protocols, as well as to advance the Internet
   technology to the scale and performance of the next generation of
   internetwork technology."

   "CATNIP supports OSI Network Service Access Point (NSAP) format
   addresses.  It also uses cache handles to provide both rapid
   identification of the next hop in high performance routing as well as
   abbreviation of the network header by permitting the addresses to be
   omitted when a valid cache handle is available. The fixed part of the
   network layer header carries the cache handles." [Sukonnik94]

7.2 SIPP

   "Simple Internet Protocol Plus (SIPP) is a new version of IP which is
   designed to be an evolutionary step from IPv4.  It is a natural
   increment to IPv4.  It was not a design goal to take a radical step
   away from IPv4.  Functions which work in IPv4 were kept in SIPP.
   Functions which didn't work were removed. It can be installed as a
   normal software upgrade in internet devices and is interoperable with
   the current IPv4.  Its deployment strategy was designed to not have
   any 'flag' days.  SIPP is designed to run well on high performance
   networks (e.g., ATM) and at the same time is still efficient for low
   bandwidth networks (e.g., wireless).  In addition, it provides a
   platform for new internet functionality that will be required in the
   near future." [Hinden94b]

   "SIPP increases the IP address size from 32 bits to 64 bits, to
   support more levels of addressing hierarchy and a much greater number
   of addressable nodes.  SIPP addressing can be further extended, in
   units of 64 bits, by a facility equivalent to IPv4's Loose Source and
   Record Route option, in combination with a new address type called
   'cluster addresses' which identify topological regions rather than
   individual nodes."

   "SIPP changes in the way IP header options are encoded allows for
   more efficient forwarding, less stringent limits on the length of
   options, and greater flexibility for introducing new options in the
   future. A new capability is added to enable the labeling of packets
   belonging to particular traffic 'flows' for which the sender requests
   special handling, such as non-default quality of service or 'real-
Top   ToC   RFC1752 - Page 13
   time' service." [Hinden94a]

7.3 TUBA

   "The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to
   minimize the risk associated with migration to a new IP address
   space. In addition, this proposal is motivated by the requirement to
   allow the Internet to scale, which implies use of Internet
   applications in a very large ubiquitous worldwide Internet. It is
   therefore proposed that existing Internet transport and application
   protocols continue to operate unchanged, except for the replacement
   of 32-bit IP addresses with larger addresses.  TUBA does not mean
   having to move over to OSI completely. It would mean only replacing
   IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would
   run on top of CLNP." [Callon92c]

   "The TUBA effort will expand the ability to route Internet packets by
   using addresses which support more hierarchy than the current
   Internet Protocol (IP) address space. TUBA specifies the continued
   use of Internet transport protocols, in particular TCP and UDP, but
   specifies their encapsulation in ISO 8473 (CLNP) packets.  This will
   allow the continued use of Internet application protocols such as
   FTP, SMTP, TELNET, etc.   TUBA seeks to upgrade the current system by
   a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the
   corresponding large Network Service Access Point (NSAP) address
   space." [Knopper94]

   "The TUBA proposal makes use of a simple long-term migration proposal
   based on a gradual update of Internet Hosts (to run Internet
   applications over CLNP) and DNS servers (to return larger addresses).
   This proposal requires routers to be updated to support forwarding of
   CLNP (in addition to IP). However, this proposal does not require
   encapsulation nor translation of packets nor address mapping. IP
   addresses and NSAP addresses may be assigned and used independently
   during the migration period. Routing and forwarding of IP and CLNP
   packets may be done independently." ([Callon92c]

8. IPng Proposal Reviews

   The IPng Directorate discussed and reviewed the candidate proposals
   during its biweekly teleconferences and through its mailing list.  In
   addition, members of the Big-Internet mailing list discussed many of
   the aspects of the proposals, particularly when the Area Directors
   posted several specific questions to stimulate discussion. [Big]

   The directorate members were requested to each evaluate the proposals
   in preparation for a two day retreat held near Chicago on May 19th
   and 20th 1994.  The retreat opened with a roundtable airing of the
Top   ToC   RFC1752 - Page 14
   views of each of the participants, including the Area Directors, the
   Directorate and a number of guests invited by the working group
   chairs for each for the proposals. [Knopper94b]  We will publish
   these reviews as well as a more detailed compendium review of each of
   the proposals as companion memos.

   The following table summarizes each of the three proposals reviewed
   against the requirements in the IPng Criteria document.  They do not
   necessarily reflect the views of the Area Directors.  "Yes" means the
   reviewers mainly felt the proposal met the specific criterion.  "No"
   means the reviewers mainly felt the proposal did not meet the
   criterion.  "Mixed" means that the reviewers had mixed reviews with
   none dominating. "Unknown" means that the reviewers mainly felt the
   documentation did not address the criterion.

                           CATNIP          SIPP            TUBA
                           ------          ----            ----
   complete spec           no              yes             mostly
   simplicity              no              no              no
   scale                   yes             yes             yes
   topological flex        yes             yes             yes
   performance             mixed           mixed           mixed
   robust service          mixed           mixed           yes
   transition              mixed           no              mixed
   media indepdnt          yes             yes             yes
   datagram                yes             yes             yes
   config. ease            unknown         mixed           mixed
   security                unknown         mixed           mixed
   unique names            mixed           mixed           mixed
   access to stds          yes             yes             mixed
   multicast               unknown         yes             mixed
   extensibility           unknown         mixed           mixed
   service classes         unknown         yes             mixed
   mobility                unknown         mixed           mixed
   control proto           unknown         yes             mixed
   tunneling               unknown         yes             mixed

8.1 CATNIP Reviews

   All the reviewers felt that CATNIP is not completely specified.
   However, many of the ideas in CATNIP are innovative and a number of
   reviewers felt CATNIP shows the best vision of all of the proposals.
   The use of Network Service Attachment Point Addresses (NSAPs) is well
   thought out and the routing handles are innovative.

   While the goal of uniting three major protocol families, IP, ISO-CLNP
   and Novell IPX is laudable our consensus was that the developers had
   not developed detailed enough plans to support realizing that goal.
Top   ToC   RFC1752 - Page 15
   The plans they do describe suffer from the complexity of trying to be
   the union of a number of existing network protocols.  Some reviewers
   felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into
   NSAPs and, as such, does not deal with the routing problems of the
   current and future Internet.

   Additionally the reviewers felt that CATNIP has poor support for
   multicasting and mobility and does not specifically deal with such
   important topics as security and autoconfiguration.

8.2 SIPP Reviews

   Most of the reviewers, including those predisposed to other
   proposals, felt as one reviewer put it, that SIPP is an
   "aesthetically beautiful protocol well tailored to compactly satisfy
   today's known network requirements."  The SIPP Working Group has been
   the most dynamic over the last year, producing a myriad of
   documentation detailing almost all of the aspects necessary to
   produce a complete protocol description.

   The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
   transition plan.  The overwhelming feeling was that IPAE is fatally
   flawed and could not be made to work reliably in an operational

   There was significant disagreement about the adequacy of the SIPP 64
   bit address size.  Although you can enumerate 10**15 end nodes in 64
   bits people have different views about how much inefficiency real-
   world routing plans introduce. [Huitema94]  The majority felt that 64
   bit addresses do not provide adequate space for the hierarchy
   required to meet the needs of the future Internet. In addition since
   no one has any experience with extended addressing and routing
   concepts of the type proposed in SIPP, the reviewers generally felt
   quite uncomfortable with this methodology.  The reviewers also felt
   that the design introduces some significant security issues.

   A number of reviewers felt that SIPP did not address the routing
   issue in any useful way.  In particular, there has been no serious
   attempt made at developing ways to abstract topology information or
   to aggregate information about areas of the network.

   Finally, most of the reviewers questioned the level of complexity in
   the SIPP autoconfiguration plans as well as in SIPP in general, other
   than the header itself.
Top   ToC   RFC1752 - Page 16
8.3 TUBA Reviews

   The reviewers generally felt that the most important thing that TUBA
   has offers is that it is based on CLNP and there is significant
   deployment of CLNP-capable routers throughout the Internet.  There
   was considerably less agreement that there was significant deployment
   of CLNP-capable hosts or actual networks running CLNP.  Another
   strong positive for TUBA is the potential for convergence of ISO and
   IETF networking standards.  A number of reviewers pointed out that,
   if TUBA were to be based on a changed CLNP then the advantage of an
   existing deployed infrastructure would be lost and that the
   convergence potential would be reduced.

   A number of aspects of CLNP were felt to be a problem by the
   reviewers including the inefficiencies introduced by the lack of any
   particular word alignment of the header fields, CLNP source route,
   the lack of a flow ID field, the lack of a protocol ID field, and the
   use of CLNP error messages in TUBA. The CLNP packet format or
   procedures would have to be modified to resolve at least some of
   these issues.

   There seems to be a profound disagreement within the TUBA community
   over the question of the ability of the IETF to modify the CLNP
   standards.  In our presentation in Houston we said that we felt that
   "clone and run" was a legitimate process.  This is also what the IAB
   proposed in "IP version 7". [IAB92]  The TUBA community has not
   reached consensus that this view is reasonable.  While many,
   including a number of the CLNP document authors, are adamant that
   this is not an issue and the IETF can make modifications to the base
   standards, many others are just as adamant that the standards can
   only be changed through the ISO standards process.  Since the
   overwhelming feeling within the IETF is that the IETF must 'own' the
   standards on which it is basing its future, this disagreement within
   the TUBA community was disquieting.

   For a number of reasons, unfortunately including prejudice in a few
   cases, the reviews of the TUBA proposals were much more mixed than
   for SIPP or CATNIP. Clearly TUBA meets the requirements for the
   ability to scale to large numbers of hosts, supports flexible
   topologies, is media independent and is a datagram protocol.  To the
   reviewers, it was less clear that TUBA met the other IPng
   requirements and these views varied widely.

   There was also disagreement over the advisability of using NSAPs for
   routing given the wide variety of NSAP allocation plans.  The
   Internet would have to restrict the use of NSAPs to those which are
   allocated with the actual underlying network topology in mind if the
   required degree of aggregation of routing information is to be
Top   ToC   RFC1752 - Page 17

8.4 Summary of Proposal Reviews

   To summarize, significant problems were seen in all three of the
   proposals. The feeling was that, to one degree or another, both SIPP
   and TUBA would work in the Internet context but each exhibited its
   own problems.  Some of these problems would have to be rectified
   before either one would be ready to replace IPv4, much less be the
   vehicle to carry the Internet into the future.  Other problems could
   be addressed over time.  CATNIP was felt to be too incomplete to be

(page 17 continued on part 2)

Next Section