rfc1380.txt

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


RFC 1380                          ROAD                     November 1992


      radically different message formats.

      3) To some extent, development and deployment of the interim
      measures will divert resources away from other important projects,
      including the development of the long-term solution.  This
      diversion should be carefully considered when choosing which
      interim measures to pursue.

4.3  A Solution For Routing Table Explosion -- CIDR

   The IESG accepted ROAD's endorsement of CIDR [Fuller92].  CIDR solves
   the routing table explosion problem (for the current IP addressing
   scheme), makes the Class B exhaustion problem less important, and
   buys time for the crucial address exhaustion problem.

   The IESG felt that other alternatives (e.g., C#, see Solen92) did not
   provide both routing table aggregation and Class B conservation at
   comparable effort.

   CIDR will require policy changes, protocol specification changes,
   implementation, and deployment of new router software, but it does
   not call for changes to host software.

   The IESG recommends the following course of action to pursue CIDR in
   the IETF:

      a. Adopt the CIDR model described in Fuller92.

      b. Develop a plan for "IP Address Assignment Guidelines".

      The IESG considered the creation of an addressing plan to be an
      operational issue.  Therefore, the IESG asked Bernhard Stockman
      (IESG Operational Requirements Area Co-Director) to lead an effort
      to develop such a plan.  Bernhard Stockman is in a position to
      bring important international input (Stockman92) into this effort
      because he is a key player in RIPE and EBONE and he is a co-chair
      of the Intercontinental Engineering Planning Group (IEPG).

      A specific proposal [Gerich92] has now emerged.  [Gerich92]
      incorporates the views of the IETF, RIPE, IEPG, and the Federal
      Engineering Planning group (FEPG).

      c. Pursue CIDR extensions to BGP in the BGP WG.

      This activity stated at the San Diego IETF meeting.  A new BGP
      specification, BGP4, incorporating the CIDR extensions, is now
      available for public comment [Rekhter92a].




Gross & Almquist                                               [Page 12]

RFC 1380                          ROAD                     November 1992


      d. Form a new WG to consider CIDR-related extensions to IDRP
      (e.g., specify how run IDRP for IP inter-domain routing).

      e. Give careful consideration to how CIDR will be deployed in the
      Internet.

      This includes issues such as how to maintain address aggregation
      across non-CIDR domains and how CIDR and various IGPs will need to
      interact.  Depending on the status of the combined CIDR
      activities, the IESG may recommend forming a "CIDR Deployment WG",
      along the same lines as the current BGP Deployment WG.

4.4 Regarding "Bigger Internet Addresses"

   In April-May 1992, the IESG reviewed the various approaches emerging
   from  the ROAD group activities -- e.g., "Simple CLNP" [Callon92a],
   "IP Encaps"  [Hinden92], "CNAT" [Callon92b], and "Nimrod"
   [Chiappa91].

   (Note: These were the only proposals under serious consideration in
   this time period.  Other proposals, namely "The P Internet Protocol
   (PIP)" [Tsuchiya92b] and "The Simple Internet Protocol (SIP)"
   [Deering92] have since been proposed.  Following the San Diego IETF
   deliberations in March, "Simple CLNP" evolved into "TCP and UDP with
   Bigger Addresses (TUBA)", and "IP Encaps" evolved into "IP Address
   Encapsulation (IPAE)" [Hinden92].)

   The "Simple CLNP" approach perhaps initially enjoyed more support
   than other approaches.

   However, the consensus view in the IESG was that the full impact of
   transition to "Simple CLNP" (or to any of the proposed approaches)
   had not yet been explored in sufficient detail to make a final
   recommendation possible at this time.

   The feeling in the IESG was that such important issues as

      - impact on operational infrastructure,
      - impact on current protocols (e.g., checksum computation
        in TCP and UDP under any new IP-level protocol),
      - deployment of new routing protocols,
      - assignment of new addresses,
      - impact on performance,
      - ownership of change control
      - effect of supporting new protocols, such as for address
        resolution,
      - effect on network management and security, and
      - the costs to network operators and network users who must



Gross & Almquist                                               [Page 13]

RFC 1380                          ROAD                     November 1992


        be trained in the architecture and specifics of any  new
        protocols needed to be explored in more depth before a
        decision of this magnitude should be made.

   At first the question seemed to be one of timing.

   At the risk of oversimplifying some very wide ranging discussions,
   many in the IESG felt that if a decision had to be made
   *immediately*, then "Simple CLNP" might be their choice.  However,
   they would feel much more comfortable if more detailed information
   was part of the decision.

   The IESG felt there needed to be an open and thorough evaluation of
   any proposed new routing and addressing architecture.  The Internet
   community must have a thorough understanding of the impact of
   changing from the current IP architecture to a new one.  The
   community needs to be confident that we all understand which approach
   has the most benefits for long-term internet growth and evolution,
   and the least impact on the current Internet.

   The IESG considered what additional information and criteria were
   needed to choose between alternative approaches.  We also considered
   the time needed for gathering this additional information and the
   amount of time remaining before it was absolutely imperative to make
   this decision (i.e., how much time do we have before we are in danger
   of running out of IP addresses *before* we could deploy a new
   architecture?).

   This led the IESG to propose a specific set of selection criteria and
   information, and specific milestones and timetable for the decision.

   The next section describes the milestones and timetable for choosing
   the approach for bigger Internet addresses.

   The selection criteria referenced in the milestones are contained in
   Appendix B.

4.5 Milestones And Timetable For Making a Recommendation for "Bigger
    Internet Addresses"

   In June, the IESG recommended that a call for proposals be made, with
   initial activities to begin at the July IETF in Boston, and with a
   strict timetable for reaching a recommendation coming out of the
   November IETF meeting [Gross92a].

   Eventually, the call for proposals was made at the July meeting
   itself.




Gross & Almquist                                               [Page 14]

RFC 1380                          ROAD                     November 1992


   A working group will be formed for each proposed approach.  The
   charter of each WG will be to explore the criteria described in
   Appendix B and to develop a detailed plan for IESG consideration.

   The WGs will be asked to submit an Internet-Draft prior to the
   November 1992 IETF, and to make presentations at the November IETF.
   The IESG and the IETF will review all submitted proposals and then
   the IESG will make a recommendation to the IAB following the November
   1992 IETF meeting.

   Therefore, the milestones and timetable for the IESG to reach a
   recommendation on bigger Internet addresses are:

      July 1992 -- Issue a call for proposals at the Boston IETF meeting
      to form working groups to explore separate approaches for bigger
      Internet addresses.

      August-November 1992 -- Proposed WGs submit charters, create
      discussion lists, and begin their deliberations by email and/or
      face- to-face meetings.  Redistribute the IESG recommendation
      (i.e., this memo).  Public review, discussion, and modification as
      appropriate of the "selection criteria" in Appendix B.

      October 1992 -- By the end of October, each WG will be required to
      submit a written description of the approach and how the criteria
      are satisfied.  This is to insure that these documents are
      distributed as Internet-Drafts for public review well before the
      November IETF meeting.

      November 1992 -- Each WG will be given an opportunity to present
      its findings in detail at the November 1992 IETF meeting.  Based
      on the written documents, the presentations, and public
      discussions (by email and at the IETF), the IESG will forward a
      recommendation to the IAB after the November IETF meeting.

5. SUMMARY

   The problems of Internet scaling and address exhaustion are
   fundamentally important to the continued health of the global
   Internet, and to the long-term success of such programs as the U.S.
   NREN and the European EBONE.  Finding and embarking on a course of
   action is critical.  However, the problem is so important that we
   need a deep understanding of the information and criteria described
   in Appendix B before a decision is made.

   With this memo, the IESG re-affirms its earlier recommendation to the
   IAB that (a) we move CIDR forward in the IETF as described in section
   4.3, and (b) that we encourage the exploration of other proposals for



Gross & Almquist                                               [Page 15]

RFC 1380                          ROAD                     November 1992


   a bigger Internet address space according to the timetable in section
   4.5.

Appendix A.  FOR MORE INFORMATION

   To become better acquainted with the issues and/or to follow the
   progress of these activities:

       - Please see the documents in the Bibliography below.

       - Join the Big-Internet mailing list where the general issues
         are discussed ([e-mail]).

       - Any new WG formed will have an open mailing list.  Please feel
         free to join each as they are announced on the IETF mailing
         list.  The current lists are:

          PIP:      [e-mail]
          TUBA:     [e-mail]
          IPAE:     [e-mail]
          SIP:      [e-mail]

       - Attend the November IETF in Washington D.C. (where the WGs
         will report and the IESG recommendation will begin formulating
         its recommendation to the IAB).

   Note: In order to receive announcements of:

       - future IETF meetings and agenda,
       - new IETF working groups, and
       - the posting of Internet-Drafts and RFCs,

   please send a request to join the IETF-Announcement mailing list
   ([e-mail]).

Appendix B.  INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET
             ADDRESSES"

   This section describes the information and criteria which the IESG
   felt that any new routing and addressing proposal should supply.  As
   the community has a chance to comment on these criteria, and as the
   IESG gets a better understanding of the issues relating to selection
   of a new routing and addressing architecture, this section may be
   revised and published in a separate document.

   It is expected that every proposal submitted for consideration should
   address each item below on an point-by-point basis.




Gross & Almquist                                               [Page 16]

RFC 1380                          ROAD                     November 1992


B.1  Description of the Proposed Scheme

   A complete description of the proposed routing and addressing
   architecture should be supplied.  This should be at the level of
   detail where the functionality and complexity of the scheme can be
   clearly understood.  It should describe how the proposal solves the
   basic problems of IP address exhaustion and router resource overload.

B.2  Changes Required

   All changes to existing protocols should be documented and new
   protocols which need to be developed and/or deployed should be
   specified and described.  This should enumerate all protocols which
   are not currently in widespread operational deployment in the
   Internet.

   Changes should also be grouped by the devices and/or functions they
   affect.  This should include at least the following:

         - Protocol changes in hosts
         - Protocol changes in exterior router
         - Protocol changes in interior router
         - Security and Authentication Changes
         - Domain name system changes
         - Network management changes