rfc1752.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   * 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.