rfc1380.txt

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

      5) Aggregation of routing information.  It is fairly clear that in
      the long-term it will be necessary for addresses to be more
      hierarchical.  This will allow routes to many networks to be
      collapsed into a single summary route.  Therefore, an important
      question is whether aggregation can also be part of the short-term
      solution.  Of the proposals to date, only CIDR could provide
      aggregation in the short-term.  All longer-term proposals should
      aggregation.

Human Limits

      1) Additional human resources.  Network providers could devote
      additional manpower to routing management, or accept the
      consequences of a reduced level of routing management.  This is
      obviously unattractive as anything other than a very short-term
      solution.

      2) Better tools.  Network operators and router vendors could work
      to develop more powerful paradigms and mechanisms for routing
      management.

      The IETF has already undertaken some work in the areas of route
      filtering and route leaking.




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


2.2.3.  IP Address Exhaustion

   The following general approaches have been suggested for dealing with
   the possible exhaustion of the IP address space:

      1) Protocol modifications to provide a larger address space.  By
      enhancing IP or by transitioning to another protocol with a larger
      address space, we could substantially increase the number of
      available network numbers and addresses.

      2) Addresses which are not globally unique.  Several proposed
      schemes have emerged whereby a host's domain name is globally
      unique, but its IP address would be unique only within it's local
      routing domain.  These schemes usually involve address translating

      3) Partitioned Internet.  The Internet could be partitioned into
      areas, such that a host's IP address would be unique only within
      its own area.  Such schemes generally postulate application
      gateways to interconnect the areas.  This is not unlike the
      approach often used to connect differing protocol families.

      4) Reclaiming network numbers.  Network numbers which are not
      used, or are used by networks which are not connected to the
      Internet, could conceivably be reclaimed for general Internet use.
      This isn't a long-term solution, but could possibly help in the
      interim if for some reason address exhaustion starts to occur
      unexpectedly soon.

3. PREPARING FOR ACTION

3.1 The IAB Architecture Retreats

   In July 1991, the IAB held a special workshop to consider critical
   issues in the IP architecture (Clark91).  Of particular concern were
   the problems related to Internet growth and scaling.  The IAB felt
   the issues were of sufficient concern to begin organizing a special
   group to explore the issues and to explore possible solutions.  Peter
   Ford (LANL) was asked to organize this effort.  The IAB reconvened
   the architecture workshop in January 1992 to further examine these
   critical issues, and to meet jointly with the then-formed ROAD group
   (see below).

3.2 The Santa Fe IETF

   At the November 1991 Santa Fe IETF meeting, the BGP Working Groups
   independently began a concerted exploration of the issues of routing
   table scaling.  The principal approach was to perform route
   aggregation by using address masks in BGP to do "supernetting"



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


   (rather than "subnetting").  This approach would eventually evolve
   into CIDR.  The BGP WG decided to form a separate subgroup, to be led
   by Phill Gross (ANS) to pursue this solution.

3.3 The ROAD Group and Beyond

   At the Santa Fe IETF, the initially separate IAB and BGP WG
   activities were combined into a special effort, named the "ROuting
   and ADdressing (ROAD) Group", to be co-chaired by Ford and Gross.

   The group was asked to explore possible near-term approaches for the
   scaling problems described in the last section, namely:

       - Class B address exhaustion
       - Routing table explosion
       - IP address space exhaustion

   The ROAD group was asked to report back to the IETF at the San Diego
   IETF (March 1992).  Suggested guidelines included minimizing changes
   to hosts, must be incrementally deployable, and must provide support
   for a billion networks.

   The ROAD group was not a traditional open IETF working group.  It was
   always presumed that this was a one-time special group that would
   lead to the formation of other IETF WGs after its report in San
   Diego.

   The ROAD group held several face-face meetings between the November
   1991 (Santa Fe) and March 1992 (San Diego) IETF meetings.  This
   included several times at the Santa Fe IETF meeting, December 1991 in
   Reston VA, January 1992 in Boston (in conjunction with the IAB
   architecture workshop), and January 1992 in Arizona).  There was also
   much discussion by electronic mail.

   The group produced numerous documents, which have variously been made
   available as Internet-Drafts or RFCs (see Bibliography in Appendix
   D).

   As follow-up, the ROAD co-chairs reported to the IETF plenary in
   March 1992 in San Diego.  Plus, several specific ROAD-related
   activities took place during the IETF meeting that week.

   The Ford/Gross presentation served as a preliminary report from the
   ROAD group.  The basic thrust was:

      1.  The Internet community needs a better way to deal with current
      addresses (e.g., hierarchical address assignments for routing
      aggregation to help slow Class B exhaustion and routing table



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


      explosion).  Classless Inter-Domain Routing (CIDR; also called
      "supernetting") was recommended.  CIDR calls for:

        - The development of a plan for hierarchical IP address
          assignment for aggregation in routing,

        - Enhanced "classless" Inter-domain protocols (i.e., carry
          address masks along with IP addresses),

        - Inter-Domain routing "Usage documents" for using addressing
          and routing plan with the enhanced inter-domain protocols,
          and for interacting with IGPs.

      2.  The Internet community needs bigger addresses for the Internet
      to stem IP address exhaustion.  The ROAD group explored several
      approaches in some depth.  Some of these approaches were discussed
      at the San Diego IETF.  However, a final recommendation of a
      single approach did not emerge.

      3.  The Internet community needs to focus more effort on future
      directions for Internet routing and advanced Internet layer
      features.

   Other ROAD-related activities at the San Diego IETF meeting included:

      - Monday,  8:00 - 9:00 am,  Report from the ROAD group on
      "Internet Routing and Addressing Considerations",

      - Monday,  9:30-12:00pm,  Geographical Addressing and Routing
      (during NOOP WG session),

      - Monday,  1:30-3:30pm,  Preliminary discussion of a CIDR routing
      and addressing plan  (during ORAD session),

      - Tuesday,  1:30-6:00pm,  Internet Routing and Addressing BOF (to
      discuss ROAD results and to explore approaches for bigger Internet
      address space),

      - Wednesday,  1:30-3:30pm,  CIDR Supernetting BOF (joint with BGP
      WG),

      - Thursday,  4:00-6:00pm,  Summary of ROAD activities in San Diego
      followed by open plenary discussion.

   The slides for the Monday presentation (Ford92), slides for the
   Thursday summary (and notes in the Chair's message) (Gross92), and
   notes for the other sessions are contained in the Proceedings of the
   Twenty-Third IETF (San Diego).



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


4. SETTING DIRECTIONS FOR THE IETF

4.1 The Need For Interim Solutions

   Solutions to the problems of advanced Internet layer functionality
   are far from being well understood.  While we should certainly
   encourage research in these areas, it is premature to start an
   engineering effort for an Internet layer which would solve not only
   the scaling problems but also those other issues.

   Plus, most approaches to the problem of IP address space exhaustion
   involve changes to the Internet layer.  Such approaches mean changes
   changes to host software that will require us to face the very
   difficult transition of a large installed base.

   It is therefore not likely that we can (a) develop a single solution
   for the near-term scaling problems that will (b) also solve the
   longer-term problems of advanced Internet-layer functionality, that
   we can (c) choose, implement and deploy before the nearer-term
   problems of Class B exhaustion or routing table explosion confront
   us.

   This line of reasoning leads to the inevitable conclusion that we
   will need to make major enhancements to IP in (at least) two stages.

   Therefore, we will consider interim measures to deal with Class B
   address exhaustion and routing table explosion (together), and to
   deal with IP address exhaustion (separately).

   We will also suggest that the possible relation between these nearer-
   term measures and work toward advanced Internet layer functionality
   should be made an important consideration.

4.2 The Proposed Phases

   The IESG recommends that we divide the overall course of action into
   several phases.  For lack of a better vocabulary, we will term these
   "immediate", "short-term", mid-term", and "long-term" phases.  But,
   as the ROAD group pointed out, we should start all the phases
   immediately. We cannot afford to act on these phases consecutively!

   In brief, the phases are:

    - "Immediate".  These are configuration and engineering actions that
   can take place immediately without protocol design, development, or
   deployment.  There are a number of actions that can begin
   immediately.  Although none of these will solve any of the problems,
   they can help slow the onset of the problems.



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


   The IESG specifically endorses:

       1) the need for more conservative address assignment
          policies,
       2) alignment of new address assignment policies with any new
          aggregation schemes,
       3) efforts to reclaim unused Class B addresses,
       4) installation of more powerful routers by network operators
          at key points in the Internet, and
       5) careful attention to topology engineering.

    - "Short-term".  Actions in this phase are aimed at dealing with
   Class B exhaustion and routing table explosion.  These problems are
   deemed to be quite pressing and to need solutions well before the IP
   address exhaustion problem needs to be or could be solved.  In this
   timeframe, changes to hosts can *not* be considered.

    - "Mid-term".  In the mid-term, the issue of IP address exhaustion
   must be solved.  This is the most fundamental problem facing the IP
   architecture.  Depending on the expected timeframe, changes to host
   software could be considered.  Note: whatever approach is taken, it
   must also deal with the routing table explosion.  If it does not,
   then we will simply be forced to deal with that problem again, but in
   a larger address space.

    - "Long-term".  Taking a broader view, the IESG feels that advanced
   Internet layer functionality, like QOS support and  resource
   reservation, will be crucial to the long-term success of the Internet
   architecture.

   Therefore, planning for advanced Internet layer functionality should
   play a key role in our choice of mid-term solutions.

   In particular, we need to keep several things in mind:

      1) The long-term solution will require replacement and/or
      extension of the Internet layer.  This will be a significant
      trauma for vendors, operators, and for users.  Therefore, it is
      particularly important that we either minimize the trauma involved
      in deploying the sort-and mid-term solutions, or we need to assure
      that the short- and mid-term solutions will provide a smooth
      transition path for the long-term solutions.

      2) The long-term solution will likely require globally unique
      endpoint identifiers with an hierarchical structure to aid
      routing.  Any effort to define hierarchy and assignment mechanisms
      for short- or mid-term solutions would, if done well, probably
      have long-term usefulness, even if the long-term solution uses



Gross & Almquist                                               [Page 11]