RFCs in HTML Format


RFC 1752

         The Recommendation for the IP Next Generation Protocol


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



Bradner & Mankin                                                [Page 1]

RFC 1752 Recommendation for IPng January 1995 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 Bradner & Mankin [Page 2]
RFC 1752 Recommendation for IPng January 1995 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 numbers * 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 effort * an IPng Working Group be formed, chaired by Steve Deering and Ross Callon * 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 chartered * recommendations about the use of non-IPv6 addresses in IPv6 environments and IPv6 addresses in non-IPv6 environments be developed * 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 Bradner & Mankin [Page 3]
RFC 1752 Recommendation for IPng January 1995 * 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." Bradner & Mankin [Page 4]
RFC 1752 Recommendation for IPng January 1995 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. Bradner & Mankin [Page 5]
RFC 1752 Recommendation for IPng January 1995 * 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. (Hsdndev.harvard.edu: pub/ipng.) 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 Bradner & Mankin [Page 6]
RFC 1752 Recommendation for IPng January 1995 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 transition. 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 Bradner & Mankin [Page 7]
RFC 1752 Recommendation for IPng January 1995 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 technology. 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 Bradner & Mankin [Page 8]
RFC 1752 Recommendation for IPng January 1995 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 Bradner & Mankin [Page 9]
RFC 1752 Recommendation for IPng January 1995 utilizing common, commercially available, high-speed media at the time. * 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 internetworks. * 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. Bradner & Mankin [Page 10]
RFC 1752 Recommendation for IPng January 1995 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] 7.1 CATNIP "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 Bradner & Mankin [Page 11]
RFC 1752 Recommendation for IPng January 1995 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- Bradner & Mankin [Page 12]
RFC 1752 Recommendation for IPng January 1995 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 Bradner & Mankin [Page 13]
RFC 1752 Recommendation for IPng January 1995 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. Bradner & Mankin [Page 14]
RFC 1752 Recommendation for IPng January 1995 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 Internet. 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. Bradner & Mankin [Page 15]
RFC 1752 Recommendation for IPng January 1995 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 Bradner & Mankin [Page 16]
RFC 1752 Recommendation for IPng January 1995 achieved. 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 considered. 9. A Revised Proposal As mentioned above, there was considerable discussion of the strengths and weaknesses of the various IPng proposals during the IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b] After this retreat Steve Deering and Paul Francis, two of the co-chairs of the SIPP Working Group, sent a message to the sipp mailing list detailing the discussions at the retreat and proposing some changes in SIPP. [Deering94a] The message noted "The recurring (and unsurprising) concerns about SIPP were: (1) complexity/manageability/feasibility of IPAE, and (2) adequacy/correctness/limitations of SIPP's addressing and routing model, especially the use of loose source routing to accomplish 'extended addressing'". They "proposed to address these concerns by changing SIPP as follows: * Change address size from 8 bytes to 16 bytes (fixed-length). * Specify optional use of serverless autoconfiguration of the 16-byte address by using IEEE 802 address as the low-order ("node ID") part. * For higher-layer protocols that use internet-layer addresses as part of connection identifiers (e.g., TCP), require that they use the entire 16-byte addresses. * Do *not* use Route Header for extended addressing." Bradner & Mankin [Page 17]
RFC 1752 Recommendation for IPng January 1995
RFC 1752 Recommendation for IPng January 1995 necessary by IPv6 should be documented. We recommend that Informational RFCs be solicited or developed for these few cases. In particular, the Berkeley-style sockets interface, the UNIX TLI and XTI interfaces, and the WINSOCK interfaces should be targeted. A draft document exists which could be developed into the sockets API description. [Gillig94b] 21. Future of the IPng Area and Working Groups In our presentation at the Houston IETF meeting we stated that the existing IPng proposal working groups would not be forced to close down after the recommendation was made. Each of them has been working on technologies that may have applications in addition to their IPng proposal and these technologies should not be lost. Since the Toronto IETF meeting the existing IPng working groups have been returned to the Internet Area. The group members may decide to close down the working groups or to continue some of their efforts. The charters of the working groups must be revised if they choose to continue since they would no longer be proposing an IPng candidate. In Toronto the chairs of the SIPP Working Group requested that the SIPP Working Group be concluded. The chairs of the TUBA Working Group requested that the TUBA working group be understood to be in hiatus until a number of the documents in process were completed, at which time they would request that the working group be concluded. We recommend that the IPng Area and its Directorate continue until the basic documents have entered the standards track in late 1994 or early 1995 and that after such time the area be dissolved and those IPng Area working groups still active be moved to their normal IETF areas. 22. Security Considerations The security of the Internet has long been questioned. It has been the topic of much press coverage, many conferences and workshops. Almost all of this attention has been negative, pointing out the many places where the level of possible security is far less than that deemed necessary for the current and future uses of the Internet. A number of the RFC 1550 White Papers specifically pointed out the requirement to improve the level of security available [Adam94, Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the Information Future". [Nat94] Bradner & Mankin [Page 40]
RFC 1752 Recommendation for IPng January 1995 In February of 1994, the IAB convened a workshop on security in the Internet architecture. The report of this workshop [IAB94] includes an exploration of many of the security problem areas and makes a number of recommendations to improve the level of security that the Internet offers its users. We feel that an improvement in the basic level of security in the Internet is vital to its continued success. Users must be able to assume that their exchanges are safe from tampering, diversion and exposure. Organizations that wish to use the Internet to conduct business must be able to have a high level of confidence in the identity of their correspondents and in the security of their communications. The goal is to provide strong protection as a matter of course throughout the Internet. As the IAB report points out, many of the necessary tools are not a function of the internetworking layer of the protocol. These higher level tools could make use of strong security features in the internetworking layer if they were present. While we expect that there will be a number of special high-level security packages available for specific Internet constituencies, support for basic packet-level authentication will provide for the adoption of a much needed, widespread, security infrastructure throughout the Internet. It is best to separate the support for authentication from the support for encryption. One should be able to use the two functions independently. There are some applications in which authentication of a corespondent is sufficient and others where the data exchanged must be kept private. It is our recommendation that IPv6 support packet authentication as a basic and required function. Applications should be able to rely on support for this feature in every IPv6 implementation. Support for a specific authentication algorithm should also be mandated while support for additional algorithms should be optional. Thus we recommend that support for the Authentication Header be required in all compliant IPv6 implementations. We recommend that support for a specific authentication algorithm be required. The specific algorithm should be determined by the time the IPv6 documents are offered as Proposed Standards. We recommend that support for the Privacy Header be required in IPv6 implementations. Bradner & Mankin [Page 41]
RFC 1752 Recommendation for IPng January 1995 We recommend that support for a privacy authentication algorithm be required. The specific algorithm should be determined by the time the IPv6 documents are offered as Proposed Standards. Clearly, a key management infrastructure will be required in order to enable the use of the authentication and encryption headers. However, defining such an infrastructure is outside the scope of the IPv6 effort. We do note that there are on-going IETF activities in this area. The IPv6 transition working groups must coordinate with these activities. Just as clearly, the use of authentication and encryption may add to the cost and impact the performance of systems but the more secure infrastructure is worth the penalty. Whatever penalty there is should also decrease in time with improved software and hardware assistance. The use of firewalls is increasing on the Internet. We hope that the presence of the authentication and privacy features in IPv6 will reduce the need for firewalls, but we do understand that they will continue to be used for the foreseeable future. In this light, we feel that clear guidance should be given to the developers of firewalls on the best ways to design and configure them when working in an IPv6 environment. We recommend that an "IPv6 framework for firewalls" be developed. This framework should explore the ways in which the Authentication Header can be used to strengthen firewall technology and detail how the IPv6 packet should be analyzed by a firewall. Some aspects of security require additional study. For example, it has been pointed out [Vecchi94] that, even in non-military situations, there are places where procedures to thwart traffic analysis will be required. This could be done by the use of encrypted encapsulation, but this and other similar requirements must be addressed on an on-going basis by the Security Area of the IETF. The design of IPv6 must be flexible enough to support the later addition of such security features. We believe that IPv6 with its inherent security features will provide the foundation upon which the Internet can continue to expand its functionality and user base. Bradner & Mankin [Page 42]
RFC 1752 Recommendation for IPng January 1995 23. Authors' Addresses Scott Bradner Harvard University 10 Ware St. Cambridge, MA 02138 Phone: +1 617 495 3864 EMail: sob@harvard.edu Allison Mankin USC/Information Sciences Institute 4350 North Fairfax Drive, Suite 400 Arlington, VA 22303 Phone: +1 703-807-0132 EMail: mankin@isi.edu Bradner & Mankin [Page 43]
RFC 1752 Recommendation for IPng January 1995 Appendix A - Summary of Recommendations 5.3 Address Assignment Policy Recommendations changes in address assignment policies are not recommended reclamation of underutilized assigned addresses is not currently recommended efforts to renumber significant portions of the Internet are not currently recommended recommend consideration of assigning CIDR-type address blocks out of unassigned Class A addressees 11. IPng Recommendation recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)" [Deering94b] be adopted as the basis for IPng recommend that the documents listed in Appendix C be the basis of IPng 13. IPng Working Group recommend that an IPng Working Group be formed, chaired by Steve Deering and Ross Callon recommend that Robert Hinden be the document editor for the IPng effort 14. IPng Reviewer recommend that an IPng Reviewer be appointed and that Dave Clark be that reviewer 15. Address Autoconfiguration recommend that an Address Autoconfiguration Working Group be formed, chaired by Dave Katz and Sue Thomson 16.1 Transition - Short Term recommend that an IPng Transition Working Group be formed, chaired by Bob Gilligan and TBA 16.2 Transition - Long Term recommend that the Transition and Coexistence Including Testing Working Group be chartered 17. Other Address Families recommend that recommendations about the use of non-IPv6 addresses in IPv6 environments and IPv6 addresses in non-IPv6 environments be developed 18. Impact on Other IETF Standards recommend the IESG commission a review of all standards track RFCs recommend the IESG charge current IETF working groups with the task of understanding the impact of IPng on their proposals and, where appropriate, revise the documents to include support for IPng recommend the IESG charter new working groups where required to revise other standards RFCs 20. APIs recommend that Informational RFCs be developed or solicited for a few of the common APIs Bradner & Mankin [Page 44]
RFC 1752 Recommendation for IPng January 1995 21. Future of the IPng Area and Working Groups recommend that the IPng Area and Area Directorate continue until main documents are offered as Proposed Standards in late 1994 22. Security Considerations recommend that support for the Authentication Header be required recommend that support for a specific authentication algorithm be required recommend that support for the Privacy Header be required recommend that support for a specific privacy algorithm be required recommend that an "IPng framework for firewalls" be developed Appendix B - IPng Area Directorate J. Allard - Microsoft <jallard@microsoft.com> Steve Bellovin - AT&T <smb@research.att.com> Jim Bound - Digital <bound@zk3.dec.com> Ross Callon - Wellfleet <rcallon@wellfleet.com> Brian Carpenter - CERN <brian.carpenter@cern.ch> Dave Clark - MIT <ddc@lcs.mit.edu > John Curran - NEARNET <curran@nic.near.net> Steve Deering - Xerox <deering@parc.xerox.com> Dino Farinacci - Cisco <dino@cisco.com> Paul Francis - NTT <francis@slab.ntt.jp> Eric Fleischmann - Boeing <ericf@atc.boeing.com> Mark Knopper - Ameritech <mak@aads.com> Greg Minshall - Novell <minshall@wc.novell.com> Rob Ullmann - Lotus <ariel@world.std.com> Lixia Zhang - Xerox <lixia@parc.xerox.com> Daniel Karrenberg of RIPE joined the Directorate when it was formed but had to withdraw due to the demands of his day job. Since the Toronto IETF meeting Paul Francis has resigned from the Directorate to pursue other interests. Robert Hinden of Sun Microsystems and Yakov Rekhter of IBM joined. Bradner & Mankin [Page 45]
RFC 1752 Recommendation for IPng January 1995 Appendix C - Documents Referred to the IPng Working Groups [Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)", Work in Progress. [Francis94] Francis, P., "SIPP Addressing Architecture", Work in Progress. [Rekhter94] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", Work in Progress. [Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview", Work in Progress. [Gillig94b] Gilligan, R., Govindan, R., Thomson, S., and J. Bound, "SIPP Program Interfaces for BSD Systems", Work in Progress. [Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in Progress. [Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in Progress. [Ford94b] Ford, P., Li, T., and Y. Rekhter, "SDRP Routing Header for SIPP-16", Work in Progress. [Hinden94c] Hinden, R., "IP Next Generation Overview", Work in Progress. Appendix D - IPng Proposal Overviews [Ford94a] Ford, P., and M. Knopper, "TUBA as IPng: A White Paper", Work in Progress. [Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, Sun Microsystems, October 1994. [McGovern94] McGovern, M., and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, Sunspot Graphics, Lotus Development Corp., October 1994. Bradner & Mankin [Page 46]
RFC 1752 Recommendation for IPng January 1995 Appendix E - RFC 1550 White Papers [Adam94] Adamson, B., "Tactical Radio Frequency Communication Requirements for IPng", RFC 1677, NRL, August 1994. [Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T Bell Laboratories, August 1994. [Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T Bell Laboratories, August 1994. [Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC 1682, Digital Equipment Corporation, August 1994. [Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680, Bellcore, August 1994. [Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large Corporate Networks", RFC 1678, IBM, August 1994. [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC 1672, University of Auckland, August 1994. [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other Considerations", RFC 1671, CERN, August 1994. [Chiappa94] Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994. [Clark94] Clark, R., Ammar, M., and K. Calvert, "Multiprotocol Interoperability In IPng", RFC 1683, Georgia Institute of Technology, August 1994. [Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC 1669, BBN, August 1994. [Estrin94a] Estrin, D., Li, T., and Y. Rekhter, "Unified Routing Requirements for IPng", RFC 1668, USC, cisco Systems, IBM, August 1994 [Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng", RFC 1687, Boeing Computer Services, August 1994. [Green94] Green, D., Irey, P., Marlow, D., and K. O'Donoghue, "HPN Working Group Input to the IPng Requirements Solicitation", RFC 1679, NSWC-DD, August 1994. Bradner & Mankin [Page 47]
RFC 1752 Recommendation for IPng January 1995 [Ghisel94] Ghiselli, A., Salomoni, D., and C. Vistoli, "INFN Requirements for an IPng", RFC 1676, INFN/CNAF, August 1994. [Heager94] Heagerty, D., "Input to IPng Engineering Considerations", RFC 1670, CERN, August 1994. [Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688, Daydreamer, August 1994. [Skelton94] Skelton, R., "Electric Power Research Institute Comments on IPng", RFC 1673, EPRI, August 1994. [Syming94] Symington, S., Wood, D., and J. Pullen, "Modeling and Simulation Requirements for IPng", RFC 1667, MITRE, George Mason University, August 1994. [Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674, CDPD Consortium, August 1994. [Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994. Appendix F - Additional References [Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF", Washington DC IETF, November 1992, (ietf/nov92/select-minutes- 92nov.txt). [Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and Requirements", Work in Progress, September 1994. [Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF (ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes- 94mar.txt). [Big] Archives of the big-internet mailing list, on munnari.oz.au in big-internet/list-archives. [Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng) White Paper Solicitation", RFC 1550, Harvard University, NRL, December 1993. [Callon87] Callon, R., "A Proposal for a Next Generation Internet Protocol", Proposal to X3S3, December 1987. [Callon92a] Callon, R., "CNAT", Work in Progress. [Callon92b] Callon, R., "Simple CLNP", Work in Progress. Bradner & Mankin [Page 48]
RFC 1752 Recommendation for IPng January 1995 [Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992. [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt, August 1993. [Carpen94b] Carpenter, B, and J. Bound, "Recommendations for OSI NSAP usage in IPv6", Work in Progress. [Chiappa91] Chiappa, J., "A New IP Routing and Addressing Architecture", Work in Progress. [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991. [Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet mailing list, 22 Sept. 1992. [Deering94a] Deering, S., and P. Francis, Message to sipp mailing list, 31 May 1994. [Estrin94b] Estrin, D., Zappala, D., Li, T., Rekhter, Y., and K. Varadhan, "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)" Work in Progress. [Fuller93] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco Systems, MERIT, OARnet, September 1993. [Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in Progress. [Gross92} Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, ANS, Stanford University, November 1992 [Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December 1994 [Hinden92a] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS)", Work in Progress. [Hinden94b] Hinden, R., Deering, S., and P. Francis, "Simple Internet Protocol Plus", Working Group Charter, April 1994. Bradner & Mankin [Page 49]
RFC 1752 Recommendation for IPng January 1995 [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address Encapsulation (IPAE): A Compatible version of IP with Large Addresses", Work in Progress. [Huston94] Huston, G., and A. Bansal, draft charter for the "Transition and Coexistence Including Testing (TACIT) Working Group, June 1994. [Huitema93] Huitema, C., "IAB Recommendations for an Intermediate Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July 1993 [Huitema94] Huitema, C., "The H ratio for address assignment efficiency", RFC 1715, INRIA, October 1994. [IAB92] Internet Architecture Board, "IP Version 7", Work in Progress. [IAB94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994", RFC 1636, USC/Informaiton Sciences Institute, MIT Laboratory for Computer Science, Trusted Information Systems, Inc., INRIA, IAB Chair, June 1994. [Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical Criteria", Work in Progress. [Kasten94] Partridge, C., and F. Kastenholz, "Technical Criteria for Choosing IP: The Next Generation (IPng)", RFC 1726, BBN Systems and Technologies, FTP Software, December 1994. [Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed Networks (TUBA)", Working Group Charter, January 1994. [Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen IPng Retreat, May 19 & 20 1994". [Leiner93] Leiner, B., and Y. Rekhter, "The MultiProtocol Internet", RFC 1560, USRA, IBM, December 1993. [Mankin94] Mankin, A., and S. Bradner, message to big-internet, tuba, sipp, catnip and ietf mailing lists, 7 July 1994. [Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification", RFC 904, UDEL, April 1984. [Mogul90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990. Bradner & Mankin [Page 50]
RFC 1752 Recommendation for IPng January 1995 [Nat94] National Research Council, "Realizing the Information Future: The Internet and Beyond", National Academy Press, 1994. [Piscit94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, Core Competence, June 1994. [Provan91] Provan, D., "Transmitting IP Traffic over ARCNET Networks", RFC 1051, Novell, February 1991. [Postel94] Postel, J., Editor, "Internet Official Protocol Standards", RFC 1720, USC/Information Sciences Institute, November 1994 [Solens93a] Solensky, F., and T. Li, "Charter for the Address Lifetime Expectations Working Group", FTP Software, Cisco Systems, November 1993. [Solens93b] Solensky, F., "Minutes of the Address Lifetime Expectations BOF (ALE)", Houston IETF, November 1993, (ietf/ale/ale-minutes-93nov.txt). [Solens94] Solensky, F., "Minutes of the Address Lifetime Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale- minutes-94jul.txt). [Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation IP (catnip), Working Group Charter, April 1994. [Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in Progress. [Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993. Bradner & Mankin [Page 51]
RFC 1752 Recommendation for IPng January 1995 Appendix G - Acknowledgments Reaching this stage of the recommendation would not have been even vaguely possible without the efforts of many people. In particular, the work of IPng Directorate (listed in Appendix B), Frank Kastenholz and Craig Partridge (the authors of the Criteria document) along with Jon Crowcroft (who co-chaired the ngreq BOF) was critical. The work and cooperation of the chairs, members and document authors of the three IPng proposal working groups, the ALE working group and the TACIT working group laid the groundwork upon which this recommendation sits. We would also like to thank the many people who took the time to respond to RFC1550 and who provided the broad understanding of the many requirements of data networking that any proposal for an IPng must address. The members of the IESG, the IAB, and the always active participants in the various mailing lists provided us with many insights into the issues we faced. Many other individuals gave us sometimes spirited but always useful counsel during this process. They include (in no particular order) Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave Piscitello, Vint Cerf and Dan Lynch. Thanks to David Williams and Cheryl Chapman who took on the occasionally impossible task of ensuring that what is written here resembles English to some degree. To all of the many people mentioned above and those we have skipped in our forgetfulness, thank you for making this task doable.



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""