rfc1519.txt

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

Fuller, Li, Yu & Varadhan                                       [Page 6]

RFC 1519                 CIDR Address Strategy            September 1993


   of this expected drop and the permanent reduction in rate of growth
   is given in the next section.

   In should also be noted that the present method of flat address
   allocations imposes a large bureaucratic cost on the central address
   allocation authority. For scaling reasons unrelated to address space
   exhaustion or routing table overflow, this should be changed. Using
   the mechanism proposed in this paper will have the fortunate side
   effect of distributing the address allocation procedure, greatly
   reducing the load on the central authority.

   3.1  Present Allocation Figures

   An informal analysis of "network-contacts.txt" (available from the
   DDN NIC) indicates that as of 2/25/92, 46 of 126 class A network
   numbers have been allocated (leaving 81) and 5467 of 16382 class B
   numbers have been allocated, leaving 10915. Assuming that recent
   trends continue, the number of allocated class B's will continue to
   double approximately once a year.  At this rate of growth, all class
   B's will be exhausted within about 15 months.  As of 1/13/93, 52
   class A network numbers have been allocated and 7133 class B's have
   been allocated.  We suggest that the change in the class B allocation
   rate is due to the initial deployment of this address allocation
   plan.



























Fuller, Li, Yu & Varadhan                                       [Page 7]

RFC 1519                 CIDR Address Strategy            September 1993


   3.2  Historic growth rates

      MM/YY     ROUTES                        MM/YY     ROUTES
                ADVERTISED                              ADVERTISED
      ------------------------                -----------------------
      Dec-92    8561                          Sep-90    1988
      Nov-92    7854                          Aug-90    1894
      Oct-92    7354                          Jul-90    1727
      Sep-92    6640                          Jun-90    1639
      Aug-92    6385                          May-90    1580
      Jul-92    6031                          Apr-90    1525
      Jun-92    5739                          Mar-90    1038
      May-92    5515                          Feb-90    997
      Apr-92    5291                          Jan-90    927
      Mar-92    4976                          Dec-89    897
      Feb-92    4740                          Nov-89    837
      Jan-92    4526                          Oct-89    809
      Dec-91    4305                          Sep-89    745
      Nov-91    3751                          Aug-89    650
      Oct-91    3556                          Jul-89    603
      Sep-91    3389                          Jun-89    564
      Aug-91    3258                          May-89    516
      Jul-91    3086                          Apr-89    467
      Jun-91    2982                          Mar-89    410
      May-91    2763                          Feb-89    384
      Apr-91    2622                          Jan-89    346
      Mar-91    2501                          Dec-88    334
      Feb-91    2417                          Nov-88    313
      Jan-91    2338                          Oct-88    291
      Dec-90    2190                          Sep-88    244
      Nov-90    2125                          Aug-88    217
      Oct-90    2063                          Jul-88    173

            Table I : Growth in routing table size, total numbers
                      Source for the routing table size data is MERIT

   3.3   Detailed Analysis

   There is a small technical cost and minimal administrative cost
   associated with deployment of the new address assignment plan. The
   administrative cost is basically that of convincing the NIC, the
   IANA, and the network service providers to agree to this plan, which
   is not expected to be too difficult.  In addition, administrative
   cost for the central numbering authorities (the NIC and the IANA)
   will be greatly decreased by the deployment of this plan.  To take
   advantage of aggregation of routing information, however, it is
   necessary that the capability to represent routes as arbitrary
   network and mask fields (as opposed to the current class A/B/C



Fuller, Li, Yu & Varadhan                                       [Page 8]

RFC 1519                 CIDR Address Strategy            September 1993


   distinction) be added to the common Internet inter-domain routing
   protocol(s).  Thus, the technical cost is in the implementation of
   classless interdomain routing protocols.

   3.3.1 Benefits of the new addressing plan

   There are two benefits to be had by deploying this plan:

      o    The current problem with depletion of the available class B
           address space can be ameliorated by assigning more-
           appropriately sized blocks of class C's to mid-sized
           organizations (in the 200-4000 host range).

      o    When the improved inter-domain routing protocol is deployed,
           an immediate decrease in the number routing table entries
           should occur, followed by a significant reduction in the rate
           growth of routing table size (for default-free routers).

   3.3.2 Growth rate projections

   As of Jan '92, a default-free routing table (for example, the routing
   tables maintained by the routers in the NSFNET backbone) contained
   approximately 4700 entries. This number reflects the current size of
   the NSFNET routing database. Historic data shows that this number, on
   average, has doubled every 10 months between 1988 and 1991. Assuming
   that this growth rate is going to persist in the foreseeable future
   (and there is no reason to assume otherwise), we expect the number of
   entries in a default-free routing table to grow to approximately
   30000 in two years time.  In the following analysis, we assume that
   the growth of the Internet has been, and will continue to be,
   exponential.

   It should be stressed that these projections do not consider that the
   current shortage of class B network numbers may increase the number
   of instances where many class C's are used rather than a class B.
   Using an assumption that new organizations which formerly obtained
   class B's will now obtain somewhere between 4 and 16 class C's, the
   rate of routing table growth can conservatively be expected to at
   least double and probably quadruple. This means the number of entries
   in a default-free routing table may well exceed 10,000 entries within
   six months and 20,000 entries in less than a year.

   As of Dec '92, the routing table contains 8500 routes.  The original
   growth curves would predict over 9400 routes.  At this time, it is
   not clear if this would indicate a significant change in the rate of
   growth.

   Under the proposed plan, growth of the routing table in a default-



Fuller, Li, Yu & Varadhan                                       [Page 9]

RFC 1519                 CIDR Address Strategy            September 1993


   free router is greatly reduced since most new address assignment will
   come from one of the large blocks allocated to the service providers.
   For the sake of this analysis, we assume prompt implementation of
   this proposal and deployment of the revised routing protocols. We
   make the initial assumption that any initial block given to a
   provider is sufficient to satisfy its needs for two years.

   Since under this plan, multi-homed networks must continue to be
   explicitly advertised throughout the system (according to Rule #1
   described in section 4.2), the number multi-homed routes is expected
   to be the dominant factor in future growth of routing table size,
   once the supernetting plan is applied.

   Presently, it is estimated that there are fewer than 100 multi-homed
   organizations connected to the Internet. Each such organization's
   network is comprised of one or more network numbers.  In many cases
   (and in all future cases under this plan), the network numbers used
   by an organization are consecutive, meaning that aggregation of those
   networks during route advertisement may be possible. This means that
   the number of routes advertised within the Internet for multi-homed
   networks may be approximated as the total number of multi-homed
   organizations.  Assuming that the number of multi-homed organization
   will double every year (which may be a over-estimation, given that
   every connection costs money), the number of routes for multi-homed
   networks would be expected to grow to approximately 800 in three
   years.

   If we further assume that there are approximately 100 service
   providers, then each service provider will also need to advertise its
   block of addresses.  However, due to aggregation, these
   advertisements will be reduced to only 100 additional routes.  We
   assume that after the initial two years, new service providers
   combined with additional requests from existing providers will
   require an additional 50 routes per year.  Thus, the total is 4700 +
   800 + 150 = 5650.  This represents an annual growth rate of
   approximately 6%.  This is in clear contrast to the current annual
   growth of 130%.  This analysis also assumes an immediate deployment
   of this plan with full compliance. Note that this analysis assumes
   only a single level of route aggregation in the current Internet -
   intelligent address allocation should significantly improve this.

   Clearly, this is not a very conservative assumption in the Internet
   environment nor can 100% adoption of this proposal be expected.
   Still, with only a 90% participation in this proposal by service
   providers, at the end of the target three years, global routing table
   size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes -- without
   any action, the routing table will grow to approximately 75000 routes
   during that time period.



Fuller, Li, Yu & Varadhan                                      [Page 10]

RFC 1519                 CIDR Address Strategy            September 1993


4.  Changes to inter-domain routing protocols and practices

   In order to support supernetting efficiently, it is clear that some
   changes will need to be made to both routing protocols themselves and
   to the way in which routing information is interpreted. In the case
   of "new" inter-domain protocols, the actual protocol syntax changes
   should be relatively minor. This mechanism will not work with older
   inter-domain protocols such as EGP2; the only ways to interoperate
   with old systems using such protocols are either to use existing
   mechanisms for providing "default" routes or b) require that new
   routers talking to old routers "explode" supernet information into
   individual network numbers.  Since the first of these is trivial
   while the latter is cumbersome (at best -- consider the memory
   requirements it imposes on the receiver of the exploded information),
   it is recommended that the first approach be used -- that older
   systems to continue to the mechanisms they currently employ for
   default handling.

   Note that a basic assumption of this plan is that those organizations
   which need to import "supernet" information into their routing
   systems must run IGPs (such as OSPF [1]) which support classless
   routes. Systems running older IGPs may still advertise and receive
   "supernet" information, but they will not be able to propagate such
   information through their routing domains.

   4.1  Protocol-independent semantic changes

   There are two fundamental changes which must be applied to Inter-
   Domain routing protocols in order for this plan to work. First, the
   concept of network "class" needs to be deprecated - this plan assumes
   that routing destinations are represented by network and mask pairs
   and that routing is done on a longest-match basis (i.e., for a given
   destination which matches multiple network+mask pairs, the match with
   the longest mask is used).  Second, current inter-domain protocols
   generally do not support the concept of route aggregation, so the new
   semantics need to be implemented in a new set of inter-domain
   protocols. In particular, when doing aggregation, dealing with
   multi-homed sites or destinations which change service providers is
   difficult. Fortunately, it is possible to define several fairly
   simple rules for dealing with such cases.

   4.2.  Rules for route advertisement

      1.   Routing to all destinations must be done on a longest-match
           basis only.  This implies that destinations which are multi-
           homed relative to a routing domain must always be explicitly
           announced into that routing domain - they cannot be summarized
           (this makes intuitive sense - if a network is multi-homed, all



Fuller, Li, Yu & Varadhan                                      [Page 11]

RFC 1519                 CIDR Address Strategy            September 1993


           of its paths into a routing domain which is "higher" in the
           hierarchy of networks must be known to the "higher" network).

      2.   A routing domain which performs summarization of multiple
           routes must discard packets which match the summarization but
           do not match any of the explicit routes which makes up the
           summarization. This is necessary to prevent routing loops in
           the presence of less-specific information (such as a default
           route).  Implementation note - one simple way to implement
           this rule would be for the border router to maintain a "sink"
           route for each of its aggregations. By the rule of longest
           match, this would cause all traffic destined to components of
           the aggregation which are not explicitly known to be
           discarded.

   Note that during failures, partial routing of traffic to a site which
   takes its address space from one service provider but which is
   actually reachable only through another (i.e., the case of a site
   which has change service providers) may occur because such traffic
   will be routed along the path advertised by the aggregated route.
   Rule #2 will prevent any real problem from occurring by forcing such
   traffic to be discarded by the advertiser of the aggregated route,
   but the output of "traceroute" and other similar tools will suggest
   that a problem exists within the service provider advertising the
   aggregate, which may be confusing to network operators (see the
   example in section 5.2 for details). Solutions to this problem appear
   to be challenging and not likely to be implementable by current
   Inter-Domain protocols within the time-frame suggested by this
   document. This decision may need to be revisited as Inter-Domain
   protocols evolve.

   An implementation following these rules should also be generalized,
   so that an arbitrary network number and mask are accepted for all
   routing destinations.  The only outstanding constraint is that the
   mask must be left contiguous.  Note that the degenerate route 0.0.0.0
   mask 0.0.0.0 is used as a default route and MUST be accepted by all
   implementations.  Further, to protect against accidental
   advertisements of this route via the inter-domain protocol, this
   route should never be advertised unless there is specific
   configuration information indicating to do so.

   Systems which process route announcements must also be able to verify
   that information which they receive is correct. Thus, implementations
   of this plan which filter route advertisements must also allow masks
   in the filter elements.  To simplify administration, it would be
   useful if filter elements automatically allowed more specific network
   numbers and masks to pass in filter elements given for a more general
   mask.  Thus, filter elements which looked like:



Fuller, Li, Yu & Varadhan                                      [Page 12]