rfc1752.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,351 行 · 第 1/5 页

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.