rfc1338.txt

RFC 的详细文档！

Network Working Group                                         V. Fuller
Request for Comments: 1338                                      BARRNet
                                                                  T. Li
                                                                  cisco
                                                                  J. Yu
                                                                  MERIT
                                                            K. Varadhan
                                                                 OARnet
                                                              June 1992


      Supernetting: an Address Assignment and Aggregation Strategy

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 discusses strategies for address assignment of the existing
   IP address space with a view to conserve the address space and stem
   the explosive growth of routing tables in default-route-free routers
   run by transit routing domain providers.

Table of Contents

   Acknowledgements .................................................  2
   1.  Problem, goal, and motivation ................................  2
   2.  Scheme plan ..................................................  3
   2.1.  Aggregation and its limitations ............................  3
   2.2.  Distributed network number allocation ......................  5
   3.  Cost-benefit analysis ........................................  6
   3.1.  Present allocation figures .................................  7
   3.2.  Historic growth rates ......................................  8
   3.3.  Detailed analysis ..........................................  8
   3.3.1.  Benefits of new addressing plan ..........................  9
   3.3.2.  Growth rate projections ..................................  9
   4.  Changes to Inter-Domain routing protocols .................... 11
   4.1.  General semantic changes ................................... 11
   4.2.  Rules for route advertisement .............................. 11
   4.3.  How the rules work ......................................... 13
   4.4.  Responsibility for and configuration of aggregation ........ 14
   5.  Example of new allocation and routing ........................ 15
   5.1.  Address allocation ......................................... 15
   5.2.  Routing advertisements ..................................... 17
   6.  Transitioning to a long term solution ........................ 18



Fuller, Li, Yu, & Varadhan                                      [Page 1]

RFC 1338                      Supernetting                     June 1992


   7.  Conclusions .................................................. 18
   8.  Recommendations .............................................. 18
   9.  Bibliography ................................................. 19
   10. Security Considerations ...................................... 19
   11. Authors' Addresses ........................................... 19

Acknowledgements

   The authors wish to express their appreciation to the members of the
   ROAD group with whom many of the ideas contained in this document
   were inspired and developed.

1.    Problem, Goal, and Motivation

   As the Internet has evolved and grown over in recent years, it has
   become painfully evident that it is soon to face several serious
   scaling problems. These include:

        1.   Exhaustion of the class-B network address space. One
             fundamental cause of this problem is the lack of a network
             class of a size which is appropriate for mid-sized
             organization; class-C, with a maximum of 254 host
             addresses, is too small while class-B, which allows up to
             65534 addresses, is to large to be widely allocated.

        2.   Growth of routing tables in Internet routers beyond the
             ability of current software (and people) to effectively
             manage.

        3.   Eventual exhaustion of the 32-bit IP address space.

   It has become clear that the first two of these problems are likely
   to become critical within the next one to three years.  This memo
   attempts to deal with these problems by proposing a mechanism to slow
   the growth of the routing table and the need for allocating new IP
   network numbers. It does not attempt to solve the third problem,
   which is of a more long-term nature, but instead endeavors to ease
   enough of the short to mid-term difficulties to allow the Internet to
   continue to function efficiently while progress is made on a longer-
   term solution.

   The proposed solution is to hierarchically allocate future IP address
   assignment, by delegating control of segments of the IP address space
   to the various network service providers.

   It is proposed that this scheme of allocating IP addresses be
   undertaken as soon as possible.  It is also believed that the scheme
   will suffice as a short term strategy, to fill the gap between now



Fuller, Li, Yu, & Varadhan                                      [Page 2]

RFC 1338                      Supernetting                     June 1992


   and the time when a viable long term plan can be put into place and
   deployed effectively.  It is believed that this scheme would be
   viable for at least three (3) years, in which time frame, a suitable
   long term solution would be expected to be deployed.

   Note that this plan neither requires nor assumes that already
   assigned addresses will be reassigned, though if doing so were
   possible, it would further reduce routing table sizes. It is assumed
   that routing technology will be capable of dealing with the current
   routing table size and with some reasonably-small rate of growth.
   The emphasis of this plan is on significantly slowing the rate of
   this growth.

   This scheme will not affect the deployment of any specific long term
   plan, and therefore, this document will not discuss any long term
   plans for routing and address architectures.

2.    Scheme Plan

   There are two basic components of this addressing and routing scheme:
   one, to distribute the allocation of Internet address space and two,
   to provide a mechanism for the aggregation of routing information.

   2.1.  Aggregation and its limitations

   One major goal of this addressing plan is to allocate Internet
   address space in such a manner as to allow aggregation of routing
   information along topological lines. For simple, single-homed
   clients, the allocation of their address space out of a service
   provider's space will accomplish this automatically - rather than
   advertise a separate route for each such client, the service provider
   may advertise a single, aggregate, route which describes all of the
   destinations contained within it. Unfortunately, not all sites are
   singly-connected to the network, so some loss of ability to aggregate
   is realized for the non simple cases.

   There are two situations that cause a loss of aggregation efficiency.

     o    Organizations which are multi-homed. Because multi-homed
          organizations must be advertised into the system by each of
          their service providers, it is often not feasible to aggregate
          their routing information into the address space any one of
          those providers. Note that they still may receive their
          address allocation out of a service provider's address space
          (which has other advantages), but their routing information
          must still be explicitly advertised by most of their service
          providers (the exception being that if the site's allocation
          comes out of its least-preferable service provider, then that



Fuller, Li, Yu, & Varadhan                                      [Page 3]

RFC 1338                      Supernetting                     June 1992


          service provider need not advertise the explicit route -
          longest-match will insure that its aggregated route is used to
          get to the site on a non-primary basis).  For this reason, the
          routing cost for these organizations will typically be about
          the same as it is today.


     o    Organizations which move from one service provider to another.
          This has the effect of "punching a hole" in the aggregation of
          the original service provider's advertisement. This plan will
          handle the situation by requiring the newer service provider
          to advertise a specific advertisement for the new client,
          which is preferred by virtue of being the longest match.  To
          maintain efficiency of aggregation, it is recommended that
          organizations which do change service providers plan to
          eventually migrate their address assignments from the old
          provider's space to that of the new provider. To this end, it
          is recommended that mechanisms to facilitate such migration,
          including improved protocols and procedures for dynamic host
          address assignment, be developed.

     Note that some aggregation efficiency gain can still be had for
     multi-homed sites (and, in general, for any site composed of
     multiple, logical IP network numbers) - by allocating a contiguous
     block of network numbers to the client (as opposed to multiple,
     independently represented network numbers) the client's routing
     information may be aggregated into a single (net, mask) pair. Also,
     since the routing cost associated with assigning a multi-homed site
     out of a service provider's address space is no greater than the
     current method of a random allocation by a central authority, it
     makes sense to allocate all address space out of blocks assigned to
     service providers.

     It is also worthwhile to mention that since aggregation may occur
     at multiple levels in the system, it may still be possible to
     aggregate these anomalous routes at higher levels of whatever
     hierarchy may be present. For example, if a site is multi-homed to
     two NSFNet regional networks both of whom obtain their address
     space from the NSFNet, then aggregation by the NSFNet of routes
     from the regionals will include all routes to the multi-homed site.

     Finally, it should also be noted that deployment of the new
     addressing plan described in this document may (and should) begin
     almost immediately but effective use of the plan to aggregate
     routing information will require changes to some Inter-Domain
     routing protocols. Likewise, deploying the supernet-capable Inter-
     Domain protocols without deployment of the new address plan will
     not allow useful aggregation to occur (in other words, the



Fuller, Li, Yu, & Varadhan                                      [Page 4]

RFC 1338                      Supernetting                     June 1992


     addressing plan and routing protocol changes are both required for
     supernetting, and its resulting reduction in table growth, to be
     effective.) Note, however, that during the period of time between
     deployment of the addressing plan and deployment of the new
     protocols, the size of routing tables may temporarily grow very
     rapidly. This must be considered when planning the deployment of
     the two plans.

     Note: in the discussion and examples which follow, the network+mask
     notation is used to represent routing destinations. This is used
     for illustration only and does not require that routing protocols
     use this representation in their updates.

     2.2.  Distributed allocation of address space

     The basic idea of the plan is to allocate one or more blocks of
     Class-C network numbers to each network service provider.
     Organizations using the network service provider for Internet
     connectivity are allocated bitmask-oriented subsets of the
     provider's address space as required.

     Note that in contrast to a previously described scheme of
     subnetting a class-A network number, this plan should not require
     difficult host changes to work around domain system limitations -
     since each sub-allocated piece of the address space looks like a
     class-C network number, delegation of authority for the IN-
     ADDR.ARPA domain works much the same as it does today - there will
     just be a lot of class-C network numbers whose IN-ADDR.ARPA
     delegations all point to the same servers (the same will be true of
     the root delegating a large block of class-Cs to the network
     provider, unless the delegation just happens to fall on a byte
     boundary). It is also the case that this method of aggregating
     class-C's is somewhat easier to deploy, since it does not require
     the ability to split a class-A across a routing domain boundary
     (i.e., non-contiguous subnets).

     It is also worthy to mention that once Inter-Domain protocols which
     support classless network destinations are widely deployed, the
     rules described by the "supernetting" plan generalize to permit
     arbitrary super/subnetting of the remaining class-A and class-B
     address space (the assumption being that classless Inter-Domain
     protocols will either allow for non-contiguous subnets to exist in
     the system or that all components of a sub-allocated class-A/B will
     be contained within a single routing domain). This will allow this
     plan to continue to be used in the event that the class-C space is
     exhausted before implementation of a long-term solution is deployed
     (there may, however, be further implementation considerations
     before doing this).