rfc1380.txt

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

Network Working Group                                           P. Gross
Request for Comments: 1380                                    IESG Chair
                                                             P. Almquist
                                                        IESG Internet AD
                                                           November 1992


              IESG Deliberations on Routing and Addressing

Status Of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo summarizes issues surrounding the routing and addressing
   scaling problems in the IP architecture, and it provides a brief
   background of the ROAD group and related activities in the Internet
   Engineering Task Force (IETF).

   It also provides a preliminary report of the Internet Engineering
   Steering Group (IESG) deliberations on how these routing and
   addressing issues should be pursued in the Internet Architecture
   Board (IAB)/IETF.

Acknowledgements

   This note draws principally from two sources: the output from the
   ROAD group, as reported at the San Diego IETF meeting, and on
   numerous detailed discussions in the IESG following the San Diego
   IETF meeting.  Zheng Wang, Bob Hinden, Kent England, and Bob Smart
   provided input for the "Criteria For Bigger Internet Addresses"
   section below.  Greg Vaudreuil prepared the final version of the
   bibliography, based on previous bibliographies by Lyman Chapin and
   bibliographies distributed on the Big-Internet mailing list.

Table of Contents

   1. INTRODUCTION..................................................  2
   2.  ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET...............  3
   2.1  The Problems................................................  3
   2.2  Possible Solutions..........................................  5
   3. PREPARING FOR ACTION..........................................  7
   3.1 The IAB Architecture Retreats................................  7
   3.2 The Santa Fe IETF............................................  7
   3.3 The ROAD Group and beyond....................................  8



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


   4. SETTING DIRECTIONS FOR THE IETF............................... 10
   4.1 The Need For Interim Solutions............................... 10
   4.2 The Proposed Phases.......................................... 10
   4.3 A Solution For Routing Table Explosion -- CIDR............... 12
   4.4 Regarding "IP Address Exhaustion"............................ 13
   4.5 Milestones And Timetable For Making a Recommendation for
       "Bigger Internet Addresses".................................. 14
   5. SUMMARY....................................................... 15
   Appendix A. FOR MORE INFORMATION................................. 16
   Appendix B. INFORMATION AND SELECTION CRITERIA FOR "BIGGER
               INTERNET ADDRESSES".................................. 16
   Appendix C. BIBLIOGRAPHY......................................... 20
   Security Considerations.......................................... 21
   Authors' Addresses............................................... 22

1. INTRODUCTION

   It seems unlikely that the designers of IP ever imagined at the time
   what phenomenal success the Internet would achieve.  Internet
   connections were initially intended primarily for mainframe computers
   at sites performing DARPA-sponsored research.  Now, of course, the
   Internet has extended its reach to the desktop and is beginning to
   extend into the home.  No longer the exclusive purview of pure R&D
   establishments, the Internet has become well entrenched in parts of
   the corporate world and is beginning to make inroads into secondary
   and even primary schools.  While once it was an almost exclusively
   U.S. phenomenon, the Internet now extends to every continent and
   within a few years may well include network connections in every
   country.

   Over the past couple of years, we have seen increasingly strong
   indications that all of this success will stress the limits of IP
   unless appropriate corrective actions are taken.  The supply of
   unallocated Class B network numbers is rapidly dwindling, and the
   amount of routing information now carried in the Internet is
   increasingly taxing the abilities of both the routers and the people
   who have to manage them.  Somewhat longer-term, it is possible that
   we will run out of host addresses or network numbers altogether.

   While these problems could be avoided by attempting to restrict the
   growth of the Internet, most people would prefer solutions that allow
   growth to continue.  Fortunately, it appears that such solutions are
   possible, and that, in fact, our biggest problem is having too many
   possible solutions rather than too few.

   This memo provides a preliminary report of IESG deliberations on how
   routing and addressing issues can be pursued in the IAB/IETF.




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


   In following sections, we will discuss in more detail the problems
   confronting us and possible approaches.  We will give a brief
   overview of the ROAD group and related activities in the IETF.  We
   will then discuss possible courses of action in the IETF.
   Ultimately, the IESG will issue a recommendation from the IESG/IETF
   to the IAB.

2.  ISSUES OF GROWTH AND EVOLUTION IN THE INTERNET

2.1  The Problems

   The Internet now faces three growth-related problems:

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

2.1.1  Class B Network Number Exhaustion

   Over the last several years, the number of network numbers assigned
   and the number of network numbers configured into the Merit NSFnet
   routing database have roughly doubled every 12 months.  This has led
   to estimates that, at the current allocation rate, and in the absence
   of corrective measures, it will take less than 2 years to allocate
   all of the currently unassigned Class B network numbers.

   After that, new sites which wished to connect more than the number of
   hosts possible in a single Class C (253 hosts) would need to be
   assigned multiple Class C networks.  This will exacerbate the routing
   table explosion problems described next.

2.1.2.  Routing Table Explosion

   As the number of networks connected to the Internet has grown, the
   amount of routing information that has to be passed around to keep
   track of them all is likewise growing.  This is leading to two types
   of problems.

Hardware and Protocol Limits

   Routing protocols must pass around this information, and routers must
   store and use it.  This taxes memory limits in the routers, and can
   also consume significant bandwidth when older routing protocols are
   used, (such as EGP and RIP, which were designed for a much smaller
   number of networks).

   The limits on the memory in the routers seem to be the most pressing.
   It is already the case that the routers used in the MILNET are
   incapable of handling all of the current routes, and most other



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


   service providers have found the need to periodically upgrade their
   routers to accommodate ever larger quantities of routing information.
   An informal survey of router vendors by the ROAD group estimated that
   most of the currently deployed generation of high-end routers will
   support O(16000) routes.  This will be probably be adequate for the
   next 12 to 18 months at the current rate of growth.  Most vendors
   have begun, or will soon begin, to ship routers capable of handling
   O(64000) routes, which should be adequate for an additional two years
   if the above Class B Network Number Exhaustion problem is solved.

Human Limits

   The number of routes does not merely tax the network's physical
   plant.  Network operators have found that the inter-domain routing
   protocol mechanisms often need to be augmented by a considerable
   amount of configuration to make the paths followed by packets be
   consistent with the policies and desires of the network operators.
   As the number of networks increases, the configuration (and the
   traffic monitoring to determine whether the configuration has been
   done correctly) becomes increasingly difficult and time-consuming.

   Although it is not possible to determine a number of networks (and
   therefore a time frame) where human limits will be exceeded, network
   operators view this as a significant short-term problem.

2.1.3.  IP Address Exhaustion

   If the current exponential growth rate continues unabated, the number
   of computers connected to the Internet will eventually exceed the
   number of possible IP addresses.  Because IP addresses are divided
   into "network" and "host" portions, we may not ever fully run out of
   IP addresses because we will run out of IP network numbers first.

   There is considerable uncertainty regarding the timeframe when we
   might exceed the limits of the IP address space.  However, the issue
   is serious enough that it deserves our earliest attention.  It is
   very important that we develop solutions to this potential problem
   well before we are in danger of actually running out of addresses.

2.1.4.  Other Internetwork Layer Issues

   Although the catalog of problems above is pretty complete as far as
   the scaling problems of the Internet are concerned, there are other
   Internet layer issues that will need to be addressed over the coming
   years.  These are issues regarding advanced functionality and service
   guarantees in the Internet layer.

   In any attempt to resolve the Internet scaling problems, it is



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


   important to consider how these other issues might affect the future
   evolution of Internet layer protocols.  These issues include:

        1)   Policy-based routing
        2)   Flow control
        3)   Weak Quality-of-Service (QOS)
        4)   Service guarantees (strong QOS)
        5)   Charging

2.2  Possible Solutions

2.2.1.  Class B Network Number Exhaustion

   A number of approaches have been suggested for how we might slow the
   exhaustion of the Class B IP addresses.  These include:

      1)   Reclaiming those Class B network numbers which have been
      assigned but are either unused or used by networks which are not
      connected to the Internet.

      2)   Modifying address assignment policies to slow the assignment
      of Class B network numbers by assigning multiple Class C network
      numbers to organizations which are only a little bit to big to be
      accommodated by a Class C network number.

         Note: It is already the case that a Class B number is assigned
         only if the applicant would need more than "several" Class C
         networks.  The value of "several" has increased over time from
         1 to (currently) 32.

      3)   Use the Class C address space to form aggregations of
      different size than the normal normal Class C addresses.  Such
      schemes include Classless Inter-Domain Routing (CIDR) [Fuller92]
      and the C# scheme [Solen92].

2.2.2.  Routing Table Explosion

   As was described earlier, there are actually two parts to this
   problem.  They each have slightly different possible approaches:

Hardware and Protocol Limits

      1) More thrust.  We could simply recognize the fact that routers
      which need full Internet routing information will require large
      amounts of memory and processing capacity.  This is at best a very
      short-term approach, and we will always need to face this problem
      in the long-term.




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


      2) Route servers (a variant of the "More Thrust" solution).
      Instead of requiring every router to store complete routing
      information, mechanisms could be developed to allow the tasks of
      computing and storing routes to be offloaded to a server.  Routers
      would request routes from the server as needed (presumably caching
      to improve performance).

      3) Topology engineering.  Many network providers already try to
      design their networks in such a way that only a few of the routers
      need complete routing information (the others rely on default
      routes to reach destinations that they don't have explicit routes
      to).  While this is inconvenient for network operators, it is a
      trend which is likely to continue.

      It is also the case that network providers could further reduce
      the number of routers which need full routing information by
      accepting some amount of suboptimal routing or reducing alternate
      paths used for backup.

      4) Charging-based solutions.  By charging for network number
      advertisements, it might be possible to discourage sites from
      connecting more networks to the Internet than they get significant
      value from having connected.