diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1752.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1752.txt')
| -rw-r--r-- | doc/rfc/rfc1752.txt | 2915 |
1 files changed, 2915 insertions, 0 deletions
diff --git a/doc/rfc/rfc1752.txt b/doc/rfc/rfc1752.txt new file mode 100644 index 0000000..c8c0030 --- /dev/null +++ b/doc/rfc/rfc1752.txt @@ -0,0 +1,2915 @@ + + + + + + +Network Working Group S. Bradner +Request for Comments: 1752 Harvard University +Category: Standards Track A. Mankin + ISI + 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. + +Abstract + + 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 + + + +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 + + + After considerable discussion on the sipp and big-internet mailing + lists about these proposed changes, the SIPP working group published + a revised version of SIPP [Deering94b], a new addressing architecture + [Francis94], and a simplified transition mechanism [Gillig94a]. + These were submitted to the IPng Directorate for their consideration. + + This proposal represents a synthesis of multiple IETF efforts with + much of the basic protocol coming from the SIPP effort, the + autoconfiguration and transition portions influenced by TUBA, the + addressing structure is based on the CIDR work and the routing header + evolving out of the SDRP deliberations. + +10. Assumptions + +10.1 Criteria Document and Timing of Recommendation + + In making the following recommendations we are making two assumptions + of community consensus; that the IPng criteria document represents + the reasonable set of requirements for an IPng, and that a specific + recommendation should be made now and that from this point on the + IETF should proceed with a single IPng effort. + + As described above, the IPng Technical Criteria document [Kasten94] + was developed in a open manner and was the topic of extensive + discussions on a number of mailing lists. We believe that there is a + strong consensus that this document accurately reflects the + community's set of technical requirements which an IPng should be + able to meet. + + A prime topic of discussion on the big-internet mailing list this + spring as well as during the open IPng directorate meeting in + Seattle, was the need to make a specific IPng recommendation at this + time. Some people felt that additional research would help resolve + some of the issues that are currently unresolved. While others + argued that selecting a single protocol to work on would clarify the + picture for the community, focus the resources of the IETF on + finalizing its details, and, since the argument that there were open + research items could be made at any point in history, there might + never be a 'right' time. + + Our reading of the community is that there is a consensus that a + specific recommendation should be made now. This is consistent with + the views expressed during the ipdecide BOF in Amsterdam [Gross94] + and in some of the RFC 1550 white papers [Carpen94a]. + + There is no particular reason to think that the basic recommendation + would be significantly different if we waited for another six months + or a year. Clearly some details which are currently unresolved could + + + +Bradner & Mankin [Page 18] + +RFC 1752 Recommendation for IPng January 1995 + + + be filled in if the recommendation were to be delayed, but the + current fragmentation of the IETF's energies limits the efficiency of + this type of detail resolution. Concentrating the resources of the + IETF behind a single effort seems to us to be a more efficient way to + proceed. + +10.2 Address Length + + One of the most hotly discussed aspects of the IPng design + possibilities was address size and format. During the IPng process + four distinct views were expressed about these issues: + + 1. The view that 8 bytes of address are enough to meet the current + and future needs of the Internet (squaring the size of the IP + address space). More would waste bandwidth, promote inefficient + assignment, and cause problems in some networks (such as mobiles + and other low speed links). + + 2. The view that 16 bytes is about right. That length supports easy + auto-configuration as well as organizations with complex internal + routing topologies in conjunction with the global routing topology + now and well into the future. + + 3. The view that 20 byte OSI NSAPs should be used in the interests of + global harmonization. + + 4. The view that variable length addresses which might be smaller or + larger than 16 bytes should be used to embrace all the above + options and more, so that the size of the address could be + adjusted to the demands of the particular environment, and to + ensure the ability to meet any future networking requirements. + + Good technical and engineering arguments were made for and against + all of these views. Unanimity was not achieved, but we feel that a + clear majority view emerged that the use of 16 byte fixed length + addresses was the best compromise between efficiency, functionality, + flexibility, and global applicability. [Mankin94] + +11. IPng Recommendation + + After a great deal of discussion in many forums and with the + consensus of the IPng Directorate, we recommend that the protocol + described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit + ver)" [Deering94b] be adopted as the basis for IPng, the next + generation of the Internet Protocol. We also recommend that the + other documents listed in Appendix C be adopted as the basis of + specific features of this protocol. + + + + +Bradner & Mankin [Page 19] + +RFC 1752 Recommendation for IPng January 1995 + + + This proposal resolves most of the perceived problems, particularly + in the areas of addressing, routing, transition and address + autoconfiguration. It includes the broad base of the SIPP proposal + effort, flexible address autoconfiguration features, and a merged + transition strategy. We believe that it meets the requirements + outlined in the IPng Criteria document and provides the framework to + fully meet the needs of the greater Internet community for the + foreseeable future. + +11.1 IPng Criteria Document and IPng + + A detailed review of how IPng meets the requirements set down in the + IPng Criteria document [Kasten94] will soon be published. Following + is our feelings about the extent to which IPng is responsive to the + criteria. + + * complete specification - the base specifications for IPng are + complete but transition and address autoconfiguration do remain to + be finalized + * architectural simplicity - the protocol is simple, easy to explain + and uses well established paradigms + * scale - an address size of 128 bits easily meets the need to + address 10**9 networks even in the face of the inherent + inefficiency of address allocation for efficient routing + * topological flexibility - the IPng design places no constraints on + network topology except for the limit of 255 hops + * performance - the simplicity of processing, the alignment of the + fields in the headers, and the elimination of the header checksum + will allow for high performance handling of IPng data streams + * robust service - IPng includes no inhibitors to robust service and + the addition of packet-level authentication allows the securing of + control and routing protocols without having to have separate + procedures + * transition - the IPng transition plan is simple and realistically + covers the transition methods that will be present in the + marketplace + * media independence - IPng retains IPv4's media independence, it may + be possible to make use of IPng's Flow Label in some connection- + oriented media such as ATM + * datagram service - IPng preserves datagram service as its basic + operational mode, it is possible that the use of path MTU discovery + will complicate the use of datagrams in some cases + * configuration ease - IPng will have easy and flexible address + autoconfiguration which will support a wide variety of environments + from nodes on an isolated network to nodes deep in a complex + internet + * security - IPng includes specific mechanisms for authentication and + encryption at the internetwork layer; the security features do rely + + + +Bradner & Mankin [Page 20] + +RFC 1752 Recommendation for IPng January 1995 + + + on the presence of a yet to be defined key management system + * unique names - IPng addresses may be used as globally unique names + although they do have topological significance + * access to standards - all of the IPng standards will be published + as RFCs with unlimited distribution + * multicast support - IPng specifically includes multicast support + * extensibility - the use of extension headers and an expandable + header option feature will allow the introduction of new features + into IPng when needed in a way that minimizes the disruption of the + existing network + * service classes - the IPng header includes a Flow Label which may + be used to differentiate requested service classes + * mobility - the proposed IPv4 mobility functions will work with IPng + * control protocol - IPng includes the familiar IPv4 control protocol + features + * tunneling support - encapsulation of IPng or other protocols within + IPng is a basic capability described in the IPng specifications + +11.2 IPv6 + + The IANA has assigned version number 6 to IPng. The protocol itself + will be called IPv6. + + The remainder of this memo is used to describe IPv6 and its features. + This description is an overview snapshot. The standards documents + themselves should be referenced for definitive specifications. We + also make a number of specific recommendations concerning the details + of the proposed protocol, the procedures required to complete the + definition of the protocol, and the IETF working groups we feel are + necessary to accomplish the task. + +12. IPv6 Overview + + IPv6 is a new version of the Internet Protocol, it has been designed + as an evolutionary, rather than revolutionary, step from IPv4. + Functions which are generally seen as working in IPv4 were kept in + IPv6. Functions which don't work or are infrequently used were + removed or made optional. A few new features were added where the + functionality was felt to be necessary. + + The important features of IPv6 include: [Hinden94c] + + * expanded addressing and routing capabilities - The IP address size + is increased from 32 bits to 128 bits providing support for a much + greater number of addressable nodes, more levels of addressing + hierarchy, and simpler auto-configuration of addresses. + + + + + +Bradner & Mankin [Page 21] + +RFC 1752 Recommendation for IPng January 1995 + + + The scaleability of multicast routing is improved by adding a + "scope" field to multicast addresses. + + A new type of address, called a "cluster address" is defined to + identify topological regions rather than individual nodes. The use + of cluster addresses in conjunction with the IPv6 source route + capability allows nodes additional control over the path their + traffic takes. + + * simplified header format - Some IPv4 header fields have been + dropped or made optional to reduce the common-case processing cost + of packet handling and to keep the bandwidth overhead of the IPv6 + header as low as possible in spite of the increased size of the + addresses. Even though the IPv6 addresses are four time longer + than the IPv4 addresses, the IPv6 header is only twice the size of + the IPv4 header. + + * support for extension headers and options - IPv6 options are placed + in separate headers that are located in the packet between the IPv6 + header and the transport-layer header. Since most IPv6 option + headers are not examined or processed by any router along a + packet's delivery path until it arrives at its final destination, + this organization facilitates a major improvement in router + performance for packets containing options. Another improvement is + that unlike IPv4, IPv6 options can be of arbitrary length and not + limited to 40 bytes. This feature plus the manner in which they are + processed, permits IPv6 options to be used for functions which were + not practical in IPv4. + + A key extensibility feature of IPv6 is the ability to encode, + within an option, the action which a router or host should perform + if the option is unknown. This permits the incremental deployment + of additional functionality into an operational network with a + minimal danger of disruption. + + * support for authentication and privacy - IPv6 includes the + definition of an extension which provides support for + authentication and data integrity. This extension is included as a + basic element of IPv6 and support for it will be required in all + implementations. + + IPv6 also includes the definition of an extension to support + confidentiality by means of encryption. Support for this extension + will be strongly encouraged in all implementations. + + + + + + + +Bradner & Mankin [Page 22] + +RFC 1752 Recommendation for IPng January 1995 + + + * support for autoconfiguration - IPv6 supports multiple forms of + autoconfiguration, from "plug and play" configuration of node + addresses on an isolated network to the full-featured facilities + offered by DHCP. + + * support for source routes - IPv6 includes an extended function + source routing header designed to support the Source Demand Routing + Protocol (SDRP). The purpose of SDRP is to support source-initiated + selection of routes to complement the route selection provided by + existing routing protocols for both inter-domain and intra-domain + routes. [Estrin94b] + + * simple and flexible transition from IPv4 - The IPv6 transition plan + is aimed at meeting four basic requirements: [Gillig94a] + + - Incremental upgrade. Existing installed IPv4 hosts and routers + may be upgraded to IPv6 at any time without being dependent on + any other hosts or routers being upgraded. + - Incremental deployment. New IPv6 hosts and routers can be + installed at any time without any prerequisites. + - Easy Addressing. When existing installed IPv4 hosts or routers + are upgraded to IPv6, they may continue to use their existing + address. They do not need to be assigned new addresses. + - Low start-up costs. Little or no preparation work is needed in + order to upgrade existing IPv4 systems to IPv6, or to deploy new + IPv6 systems. + + * quality of service capabilities - A new capability is added to + enable the labeling of packets belonging to particular traffic + "flows" for which the sender has requested special handling, such + as non-default quality of service or "real-time" service. + + + + + + + + + + + + + + + + + + + + +Bradner & Mankin [Page 23] + +RFC 1752 Recommendation for IPng January 1995 + + +12.1 IPv6 Header Format + + The IPv6 header, although longer than the IPv4 header, is + considerably simplified. A number of functions that were in the IPv4 + header have been relocated in extension headers or dropped. + [Deering94b] + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Version| Flow Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Length | Next Header | Hop Limit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Source Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Destination Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + * Version - Internet Protocol version number. IPng has been assigned + version number 6. (4-bit field) + + * Flow Label - This field may be used by a host to label those + packets for which it is requesting special handling by routers + within a network, such as non-default quality of service or "real- + time" service. (28-bit field) + + * Payload Length - Length of the remainder of the packet following + the IPv6 header, in octets. To permit payloads of greater than 64K + bytes, if the value in this field is 0 the actual packet length + will be found in an Hop-by-Hop option. (16-bit unsigned integer) + + * Next Header - Identifies the type of header immediately following + the IPv6 header. The Next Header field uses the same values as the + IPv4 Protocol field (8-bit selector field) + + + + + + +Bradner & Mankin [Page 24] + +RFC 1752 Recommendation for IPng January 1995 + + + * Hop Limit - Used to limit the impact of routing loops. The Hop + Limit field is decremented by 1 by each node that forwards the + packet. The packet is discarded if Hop Limit is decremented to + zero. (8-bit unsigned integer) + + * Source Address - An address of the initial sender of the packet. + (128 bit field) + + * Destination Address - An address of the intended recipient of the + packet (possibly not the ultimate recipient, if an optional Routing + Header is present). (128 bit field) + +12.2 Extension Headers + + In IPv6, optional internet-layer information is encoded in separate + headers that may be placed between the IPv6 header and the + transport-layer header in a packet. There are a small number of such + extension headers, each identified by a distinct Next Header value. + [From a number of the documents listed in Appendix C.] + + 12.2.1 Hop-by-Hop Option Header + + The Hop-by-Hop Options header is used to carry optional + information that must be examined by every node along a packet's + delivery path. The Hop-by-Hop Options header is identified by a + Next Header value of 0 in the IPv6 header, and has the following + format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Hdr Ext Len | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + . . + . Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + * Next Header - Identifies the type of header immediately + following the Hop-by-Hop Options header. Uses the same values + as the IPv4 Protocol field. (8-bit selector) + + * Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet + units, not including the first 8 octets. (8-bit unsigned + integer) + + + + + + +Bradner & Mankin [Page 25] + +RFC 1752 Recommendation for IPng January 1995 + + + * Options - Contains one or more TLV-encoded options. (Variable- + length field, of length such that the complete Hop-by-Hop + Options header is an integer multiple of 8 octets long.) + + 12.2.2 IPv6 Header Options + + Two of the currently-defined extension headers -- the Hop-by-Hop + Options header and the End-to-End Options header -- may carry a + variable number of Type-Length-Value (TLV) encoded "options", of + the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - + | Option Type | Opt Data Len | Option Data + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - + + * Option Type - identifier of the type of option (8-bit field) + + * Opt Data Len - Length of the Option Data field of this option, + in octets. (8-bit unsigned integer) + + * Option Data - Option-Type-specific data. (Variable-length field) + + The Option Type identifiers are internally encoded such that their + highest-order two bits specify the action that must be taken if + the processing IPv6 node does not recognize the Option Type: + + 00 - skip over this option and continue processing the header + 01 - discard the packet + 10 - discard the packet and send an ICMP Unrecognized Type message + to the packet's Source Address, pointing to the unrecognized + Option Type + 11 - undefined. + + In the case of Hop-by-Hop options only, the third-highest-order + bit of the Option Type specifies whether or not the Option Data of + this option shall be included in the integrity assurance + computation performed when an Authentication header is present. + Option data that changes en route must be excluded from that + computation. + + + + + + + + + + + + +Bradner & Mankin [Page 26] + +RFC 1752 Recommendation for IPng January 1995 + + + 12.2.3 Routing Header + + The Routing header is used by an IPv6 source to list one or more + intermediate nodes (or topological clusters) to be "visited" on + the way to a packet's destination. This particular form of the + Routing Header is designed to support SDRP. [Estrin94b] + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header |Routing Type=1 |M|F| Reserved | SrcRouteLen | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NextHopPtr | Strict/Loose Bit Mask | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Source Route . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + * Next Header - Identifies the type of header immediately + following the Routing Header. Uses the same values as the IPv4 + Protocol field. (8-bit selector) + + * Routing Type - Indicates the type of routing supported by this + header. Value must be 1. + + * MRE flag - Must Report Errors. If this bit is set to 1, and a + router can not further forward a packet (with an incompletely + traversed source route), as specified in the Source Route, the + router must generate an ICMP error message. If this bit is set + to 0, and a router can not further forward a packet (with an + incompletely traversed source route), as specified in the Source + Route, the router should not generate an ICMP error message. + + * F flag - Failure of Source Route Behavior. If this bit it set + to 1, it indicates that if a router can not further forward a + packet (with an incompletely traversed source route), as + specified in the Source Route, the router must set the value of + the Next Hop Pointer field to the value of the Source Route + Length field, so that the subsequent forwarding will be based + solely on the destination address. If this bit is set to 0, it + indicates that if a router can not further forward a packet + (with an incompletely traversed source route), as specified in + the Source Route, the router must discard the packet. + + + + + +Bradner & Mankin [Page 27] + +RFC 1752 Recommendation for IPng January 1995 + + + * Reserved - Initialized to zero for transmission; ignored on + reception. + + * SrcRouteLen - Source Route Length - Number of source route + elements/hops in the SDRP Routing header. Length of SDRP + routing header can be calculated from this value (length = + SrcRouteLen * 16 + 8) This field may not exceed a value of 24. + (8 bit unsigned integer) + + * NextHopPtr - Next Hop Pointer- Index of next element/hop to be + processed; initialized to 0 to point to first element/hop in the + source route. When Next Hop Pointer is equal to Source Route + Length then the Source Route is completed. (8 bit unsigned + integer) + + * Strict/Loose Bit Mask - The Strict/Loose Bit Mask is used when + making a forwarding decision. If the value of the Next Hop + Pointer field is N, and the N-th bit in the Strict/Loose Bit + Mask field is set to 1, it indicates that the next hop is a + Strict Source Route Hop. If this bit is set to 0, it indicates + that the next hop is a Loose Source Route Hop. (24 bit + bitpattern) + + * Source Route - A list of IPv6 addresses indicating the path that + this packet should follow. A Source Route can contain an + arbitrary intermix of unicast and cluster addresses. (integral + multiple of 128 bits) + + 12.2.4 Fragment Header + + The Fragment header is used by an IPv6 source to send payloads + larger than would fit in the path MTU to their destinations. + (Note: unlike IPv4, fragmentation in IPv6 is performed only by + source nodes, not by routers along a packet's delivery path) The + Fragment header is identified by a Next Header value of 44 in the + immediately preceding header, and has the following format: + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Reserved | Fragment Offset |Res|M| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + * Next Header - Identifies the type of header immediately + following the Fragment header. Uses the same values as the IPv4 + Protocol field. (8 bit selector) + + + + +Bradner & Mankin [Page 28] + +RFC 1752 Recommendation for IPng January 1995 + + + * Reserved, Res - Initialized to zero for transmission; ignored on + reception. + + * Fragment Offset - The offset, in 8-octet units, of the following + payload, relative to the start of the original, unfragmented + payload. (13-bit unsigned integer) + + * M flag - 1 = more fragments; 0 = last fragment. + + * Identification - A value assigned to the original payload that + is different than that of any other fragmented payload sent + recently with the same IPv6 Source Address, IPv6 Destination + Address, and Fragment Next Header value. (If a Routing header + is present, the IPv6 Destination Address is that of the final + destination.) The Identification value is carried in the + Fragment header of all of the original payload's fragments, and + is used by the destination to identify all fragments belonging + to the same original payload. (32 bit field) + + 12.2.5 Authentication Header + + The Authentication header is used to provide authentication and + integrity assurance for IPv6 packets. Non-repudiation may be + provided by an authentication algorithm used with the + Authentication header, but it is not provided with all + authentication algorithms that might be used with this header. + The Authentication header is identified by a Next Header value of + 51 in the immediately preceding header, and has the following + format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Auth Data Len | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security Association ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Authentication Data . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + * Next Header - Identifies the type of header immediately + following the Authentication header. Uses the same values as + the IPv4 Protocol field. (8-bit selector) + + * Auth Data Len - Length of the Authentication Data field in 8- + octet units. (8-bit unsigned integer) + + + +Bradner & Mankin [Page 29] + +RFC 1752 Recommendation for IPng January 1995 + + + * Reserved - Initialized to zero for transmission; ignored on + reception. + + * Security Assoc. ID - When combined with the IPv6 Source Address, + identifies to the receiver(s) the pre-established security + association to which this packet belongs. (32 bit field) + + * Authentication Data - Algorithm-specific information required + to authenticate the source of the packet and assure its + integrity, as specified for the pre-established security + association. (Variable-length field, an integer multiple of 8 + octets long.) + + 12.2.6 Privacy Header + + The Privacy Header seeks to provide confidentiality and integrity + by encrypting data to be protected and placing the encrypted data + in the data portion of the Privacy Header. Either a transport- + layer (e.g., UDP or TCP) frame may be encrypted or an entire IPv6 + datagram may be encrypted, depending on the user's security + requirements. This encapsulating approach is necessary to provide + confidentiality for the entire original datagram. If present, the + Privacy Header is always the last non-encrypted field in a packet. + + The Privacy Header works between hosts, between a host and a + security gateway, or between security gateways. This support for + security gateways permits trustworthy networks to exist without + the performance and monetary costs of security, while providing + security for traffic transiting untrustworthy network segments. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security Association Identifier (SAID) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Initialization Vector . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header* | Length* | Reserved* | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Protected Data* +-+-+-+-+-+-+-+-+-+-+ + | | trailer* | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + *encrypted + + + + + + +Bradner & Mankin [Page 30] + +RFC 1752 Recommendation for IPng January 1995 + + + * Security Association Identifier (SAID) - Identifies the security + association for this datagram. If no security association has + been established, the value of this field shall be 0x0000. A + security association is normally one-way. An authenticated + communications session between two hosts will normally have two + SAIDs in use (one in each direction). The receiving host uses + the combination of SAID value and originating address to + distinguish the correct association. (32 bit value) + + * Initialization Vector - This field is optional and its value + depends on the SAID in use. For example, the field may contain + cryptographic synchronization data for a block oriented + encryption algorithm. It may also be used to contain a + cryptographic initialization vector. A Privacy Header + implementation will normally use the SAID value to determine + whether this field is present and, if it is, the field's size + and use. (presence and length dependent on SAID) + + * Next Header - encrypted - Identifies the type of header + immediately following the Privacy header. Uses the same values + as the IPv4 Protocol field. (8 bit selector) + + * Reserved - encrypted - Ignored on reception. + + * Length - encrypted - Length of the Privacy Header in 8-octet + units, not including the first 8 octets. (8-bit unsigned + integer) + + * Protected Data - encrypted - This field may contain an entire + encapsulated IPv6 datagram, including the IPv6 header, a + sequence of zero or more IPv6 options, and a transport-layer + payload, or it may just be a sequence of zero or more IPv6 + options followed by a transport-layer payload. (variable + length) + + * trailer (Algorithm-dependent Trailer) - encrypted - A field + present to support some algorithms which need to have padding + (e.g., to a full cryptographic block size for block-oriented + encryption algorithms) or for storage of authentication data for + use with a encryption algorithm that provides confidentiality + without authentication. It is present only when the algorithm + in use requires such a field. (presence and length dependent on + SAID) + + + + + + + + +Bradner & Mankin [Page 31] + +RFC 1752 Recommendation for IPng January 1995 + + + 12.2.7 End-to-End Option Header + + The End-to-End Options header is used to carry optional + information that needs to be examined only by a packet's + destination node(s). The End-to-End Options header is identified + by a Next Header value of TBD in the immediately preceding header, + and has the same format as the Hop-by-Hop Option Header except for + the ability to exclude an option from the authentication integrity + assurance computation. + +13. IPng Working Group + + We recommend that a new IPng Working Group be formed to produce + specifications for the core functionality of the IPv6 protocol suite. + The working group will carry out the recommendations of the IPng Area + Directors as outlined at the July 1994 IETF and in this memo. We + recommend that this working group be chaired by Steve Deering of + Xerox PARC and Ross Callon of Wellfleet. + + The primary task of the working group is to produce a set of + documents that define the basic functions, interactions, assumptions, + and packet formats for IPv6. We recommend that Robert Hinden of Sun + Microsystems be the editor for these documents. The documents listed + in Appendix C will be used by the working group to form the basis of + the final document set. + + The work of the IPng Working Group includes: + + * complete the IPv6 overview document + * complete the IPv6 detailed operational specification + * complete the IPv6 Addressing Architecture specification + * produce specifications for IPv6 encapsulations over various media + * complete specifications for the support of packets larger than 64KB + * complete specifications of the DNS enhancements required to support + IPv6 + * complete specification of ICMP, IGMP and router discovery for + support of IPv6. + * complete specification of path MTU discovery for IPv6 + * complete specifications of IPv6 in IPv6 tunneling + * complete the suggested address format and assignment plan + * coordinate with the Address Autoconfiguration Working Group + * coordinate with the NGTRANS and TACIT Working Groups + * complete specifications of authentication and privacy support + headers + + + + + + + +Bradner & Mankin [Page 32] + +RFC 1752 Recommendation for IPng January 1995 + + + The working group should also consider a few selected enhancements + including: + + * consider ways to compress the IPv6 header in the contexts of native + IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6 + * consider specifying support for a larger minimum MTU + +14. IPng Reviewer + + Currently it is the task of the IPng Area Directors, the IPng + Directorate and the chairs of the proposed ipng working group to + coordinate the activities of the many parallel efforts currently + directed towards different aspects of IPng. While this is possible + and currently seems to be working well it can not be maintained over + the long run because, among other reasons, the IPng Area will be + dissolved eventually and its Directorate disbanded. It will also + become much more difficult as IPng related activities start up in + other IETF areas. + + We recommend that an IPng Reviewer be appointed to be specifically + responsible for ensuring that a consistent view of IPv6 is maintained + across the related working groups. We feel that this function is + required due to the complex nature of the interactions between the + parts of the IPng effort and due to the distribution of the IPng + related work amongst a number of IETF areas. We recommend that Dave + Clark of MIT be offered this appointment. + + This would be a long-term task involving the review of on-going + activities. The aim is not for the IPng Reviewer to make + architectural decisions since that is the work of the various working + groups, the IAB, and the IETF as a whole.. The aim is to spot gaps or + misunderstandings before they reach the point where functionality or + interworkability is threatened. + +15. Address Autoconfiguration + + As data networks become more complex the need to be able to bypass at + least some of the complexity and move towards "plug and play" becomes + ever more acute. The user can not be expected to be able to + understand the details of the network architecture or know how to + configure the network software in their host. In the ideal case, a + user should be able to unpack a new computer, plug it into the local + network and "just" have it work without requiring the entering of any + special information. Security concerns may restrict the ability to + offer this level of transparent address autoconfiguration in some + environments but the mechanisms must be in place to support whatever + level of automation which the local environment feels comfortable + with. + + + +Bradner & Mankin [Page 33] + +RFC 1752 Recommendation for IPng January 1995 + + + The basic requirement of "plug and play" operation is that a host + must be able to acquire an address dynamically, either when attaching + to a network for the first time or when the host needs to be + readdressed because the host moved or because the identity of the + network has changed. There are many other functions required to + support a full "plug and play" environment. [Berk94] Most of these + must be addressed outside of the IPv6 Area but a focused effort to + define a host address autoconfiguration protocol is part of the IPv6 + process. + + We recommend that a new Address Autoconfiguration Working Group + (addrconf) be formed with Dave Katz of Cisco Systems and Sue Thomson + of Bellcore as co-chairs. The purpose of this working group is to + design and specify a protocol for allocating addresses dynamically to + IPv6 hosts. The address configuration protocol must be suitable for + a wide range of network topologies, from a simple isolated network to + a sophisticated globally connected network. It should also allow for + varying levels of administrative control, from completely automated + operation to very tight oversight. + + The scope of this working group is to propose a host address + autoconfiguration protocol which supports the full range of + topological and administrative environments in which IPv6 will be + used. It is the intention that, together with IPv6 system discovery, + the address autoconfiguration protocol will provide the minimal + bootstrapping information necessary to enable hosts to acquire + further configuration information (such as that provided by DHCP in + IPv4). The scope does not include router configuration or any other + host configuration functions. However, it is within the scope of the + working group to investigate and document the interactions between + this work and related functions including system discovery, DNS + autoregistration, service discovery, and broader host configuration + issues, to facilitate the smooth integration of these functions. + [Katz94a] + + The working group is expected to complete its work around the end of + 1994 and disband at that time. The group will use "IPv6 Address + Autoconfiguration Architecture" [Katz94b] draft document as the basis + of their work. + +16. Transition + + The transition of the Internet from IPv4 to IPv6 has to meet two + separate needs. There is a short term need to define specific + technologies and methods to transition IPv4 networks, including the + Internet, into IPv6 networks and an IPv6 Internet. There is also a + long term need to do broad-based operational planning for transition, + including developing methods to allow decentralized migration + + + +Bradner & Mankin [Page 34] + +RFC 1752 Recommendation for IPng January 1995 + + + strategies, understanding the ramifications of a long period of + coexistence when both protocols are part of the basic infrastructure, + developing an understanding of the type and scope of architectural + and interoperability testing that will be required to ensure a + reliable and manageable Internet in the future. + +16.1 Transition - Short Term + + Any IPng transition plan must take into account the realities of what + types of devices vendors will build and network managers will deploy. + The IPng transition plan must define the procedures required to + successfully implement the functions which vendors will be likely to + include in their devices. This is the case even if there are good + arguments to recommend against a particular function, header + translation for example. If products will exist it is better to have + them interoperate than not. + + We recommend that a new IPng Transition (NGTRANS) Working Group be + formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co- + chairs to design the mechanisms and procedures to support the + transition of the Internet from IPv4 to IPv6 and to give advice on + what procedures and techniques are preferred. + + The work of the group will fall into three areas: + + * Define the processes by which the Internet will make the transition + from IPv4 to IPv6. As part of this effort, the group will produce + a document explaining to the general Internet community what + mechanisms will be employed in the transition, how the transition + will work, the assumptions about infrastructure deployment inherent + in the operation of these mechanisms, and the types of + functionality that applications developers will be able to assume + as the protocol mix changes over time. + * Define and specify the mandatory and optional mechanisms that + vendors should implement in hosts, routers, and other components of + the Internet in order for the transition to be carried out. Dual- + stack, encapsulation and header translation mechanisms must all be + defined, as well as the interaction between hosts using different + combinations of these mechanisms. The specifications produced will + be used by people implementing these IPv6 systems. + * Articulate a concrete operational plan for the Internet to make the + transition from IPv4 to IPv6. The result of this work will be a + transition plan for the Internet that network operators and + Internet subscribers can execute. + [Gillig94c] + + + + + + +Bradner & Mankin [Page 35] + +RFC 1752 Recommendation for IPng January 1995 + + + The working group is expected to complete its work around the end of + 1994 and disband at that time. The group will use the "Simple SIPP + Transition (SST)" [Gilig94a] overview document as the starting point + for its work. + +16.2 Transition - Long Term + + There are a number of transition related topics in addition to + defining the specific IPv4 to IPv6 mechanisms and their deployment, + operation and interaction. The ramifications and procedures of + migrating to a new technology or to a new version of an existing + technology must be fully understood. + + We recommend that the Transition and Coexistence Including Testing + (TACIT) Working Group, which was started a few months ago, explore + some of the basic issues associated with the deployment of new + technology into an established Internet. The TACIT Working Group + will focus on the generic issues of transition and will not limit + itself to the upcoming transition to IPv6 because, over time, + enhancements to IPv6 (IPv6ng) will be developed and accepted. At + that point they will need to be deployed into the then existing + Internet. The TACIT Working Group will be more operationally + oriented than the NGTRANS Working Group and will continue well into + the actual IPv6 transition. + + The main areas of exploration are: + + * Make the transition from a currently deployed protocol to a new + protocol while accommodating heterogeneity and decentralized + management. + * Since it is often difficult or impossible to replace all legacy + systems or software, it is important to understand the + characteristics and operation of a long period of coexistence + between a new protocol and the existing protocol. + * The Internet must now be considered a utility. We are far removed + from a time when a new technology could be deployed to see if it + would work in large scale situations. Rigorous architectural and + interoperability testing must be part of the predeployment phase of + any proposed software for the Internet. Testing the scaling up + behaviors and robustness of a new protocol will offer particular + challenges. The WG should determine if there are lessons to be + learned from: OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2 + transition, DECnet Phase 4 to Phase 5 planning and transition, + among others. + + + + + + + +Bradner & Mankin [Page 36] + +RFC 1752 Recommendation for IPng January 1995 + + + The TACIT Working Group will explore each of these facets of the + deployment of new technology and develop a number of documents to + help guide users and managers of affected data networks and provide + to the IETF: + + * Detailed descriptions of problem areas in transition and + coexistence, both predicted, based on lessons learned, and observed + as the IPv6 process progresses. + * Recommendations for specific testing procedures. + * Recommendations for coexistence operations procedures + * Recommendations for the smoothing of decentralized transition + planning. + [Huston94] + +17. Other Address Families + + There are many environments in which there are one or more network + protocols already deployed or where a significant planning effort has + been undertaken to create a comprehensive network addressing plan. In + such cases there may be a temptation to integrate IPv6 into the + environment by making use of an existing addressing plan to define + all or part of the IPv6 addresses. The advantage of doing this is + that it permits unified management of address space among multiple + protocol families. The use of common addresses can help facilitate + transition from other protocols to IPv6. + + If the existing addresses are globally unique and assigned with + regard to network topology this may be a reasonable idea. The IETF + should work with other organizations to develop algorithms that could + be used to map addresses between IPv6 and other environments. The + goal for any such mapping must be to provide an unambiguous 1 to 1 + map between individual addresses. + + Suggestions have been made to develop mapping algorithms for Novell + IPX addresses, some types of OSI NSAPs, E164 addresses and SNA + addresses. Each of these possibilities should be carefully examined + to ensure that use of such an algorithm solves more problems than it + creates. In some cases it may be better to recommend either that a + native IPng addressing plan be developed instead, or that an IPv6 + address be used within the non-IP environment. [Carpen94b] + + We recommend that, in conjunction with other organizations, + recommendations about the use of non-IPv6 addresses in IPv6 + environments and IPv6 addresses in non-IPv6 environments be + developed. + + + + + + +Bradner & Mankin [Page 37] + +RFC 1752 Recommendation for IPng January 1995 + + +18. Impact on Other IETF Standards + + Many current IETF standards are affected by IPv6. At least 27 of the + current 51 full Internet Standards must be revised for IPv6, along + with at least 6 of the 20 Draft Standards and at least 25 of the 130 + Proposed Standards. [Postel94] + + In some cases the revisions consist of simple changes to the text, + for example, in a number of RFCs an IP address is referred to in + passing as a "32 bit IP address" even though IP addresses are not + directly used in the protocol being defined. All of the standards + track documents will have to be checked to see if they contain such + references. + + In most of the rest of the cases revisions to the protocols, + including packet formats, will be required. In many of these cases + the address is just being carried as a data element and a revised + format with a larger field for the address will have no effect on the + functional paradigm. + + In the remaining cases some facet of the operation of the protocol + will be changed as a result of IPv6. For example, the security and + source route mechanisms are fundamentally changed from IPv4 with + IPv6. Protocols and applications that relied on the IPv4 + functionality will have to be redesigned or rethought to use the + equivalent function in IPv6. + + In a few cases this opportunity should be used to determine if some + of the RFCs should be moved to historic, for example EGP [Mills84] + and IP over ARCNET. [Provan91] + + The base IPng Working Group will address some of these, existing IETF + working groups can work on others, while new working groups must be + formed to deal with a few of them. The IPng Working Group will be + responsible for defining new versions of ICMP, ARP/RARP, and UDP. It + will also review RFC 1639, "FTP Operation Over Big Address Records + (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90] + + Existing working groups will examine revisions for some of the + routing protocols: RIPv2, IS-IS, IDRP and SDRP. A new working group + may be required for OSPF. + + The existing DHCP Working Group may be able to revise DHCP and + examine BOOTP. + + + + + + + +Bradner & Mankin [Page 38] + +RFC 1752 Recommendation for IPng January 1995 + + + A TCPng Working Group will be formed soon, and new working groups + will have to be formed to deal with standards such as SNMP, DNS, NTP, + NETbios, OSI over TCP, Host Requirements, and Kerberos as well as + reviewing most of the RFCs that define IP usage over various media. + + In addition to the standards track RFCs mentioned above there are + many Informational and Experimental RFCs which would be affected as + well as numerous Internet Drafts (and those standards track RFCs that + we missed). + + We recommend that the IESG commission a review of all standards track + RFCs to ensure that a full list of affected documents is compiled. We + recommend that the IESG charge current IETF working groups with the + task of understanding the impact of IPv6 on their proposals and, + where appropriate, revise the documents to include support for IPv6. + + We recommend that the IESG charter new working groups where required + to revise other standards RFCs. + +19. Impact on non-IETF standards and on products + + Many products and user applications which rely on the size or + structure of IPv4 addresses will need to be modified to work with + IPv6. While the IETF can facilitate an investigation of the impacts + of IPv6 on non-IETF standards and products, the primary + responsibility for doing so resides in the other standards bodies and + the vendors. + + Examples of non-IETF standards that are effected by IPv6 include the + POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun + ONC, the Andrew File System and MIT's Kerberos. Most products that + provide specialized network security including firewall-type devices + are among those that must be extended to support IPv6. + +20. APIs + + It is traditional to state that the IETF does not "do" APIs. While + there are many reasons for this, the one most commonly referenced is + that there are too many environments where TCP/IP is used, too many + different operating systems, programming languages, and platforms. + The feeling is that the IETF should not get involved in attempting to + define a language and operating system independent interface in the + face of such complexity. + + We feel that this historical tendency for the IETF to avoid dealing + with APIs should be reexamined in the case of IPv6. We feel that in + a few specific cases the prevalence of a particular type of API is + such that a single common solution for the modifications made + + + +Bradner & Mankin [Page 39] + +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. + + + + + + + + + + + + + + + + + + + +Bradner & Mankin [Page 52] + |