doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc1338.txt b/doc/rfc/rfc1338.txt
new file mode 100644
index 0000000..386decb
--- /dev/null
+++ b/doc/rfc/rfc1338.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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).
+
+
+
+Fuller, Li, Yu, & Varadhan                                      [Page 5]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+     Hierarchical sub-allocation of addresses in this manner implies
+     that clients with addresses allocated out of a given service
+     provider are, for routing purposes, part of that service provider
+     and will be routed via its infrastructure. This implies that
+     routing information about multi-homed organizations, i.e.,
+     organizations connected to more than one network service provider,
+     will still need to be known by higher levels in the hierarchy.
+
+     The advantages of hierarchical assignment in this fashion are
+
+     a)   It is expected to be easier for a relatively small number of
+          service providers to obtain addresses from the central
+          authority, rather than a much larger, and monotonically
+          increasing, number of individual clients.  This is not to be
+          considered as a loss of part of the service providers' address
+          space.
+
+     b)   Given the current growth of the Internet, a scalable and
+          delegatable method of future allocation of network numbers has
+          to be achieved.
+
+   For these reasons, and in the interest of providing a consistent
+   procedure for obtaining Internet addresses, it is recommended that
+   most, if not all, network numbers be distributed through service
+   providers.
+
+3.  Cost-benefit analysis
+
+   This new method of assigning address through service providers can be
+   put into effect immediately and will, from the start, have the
+   benefit of distributing the currently centralized process of
+   assigning new addresses. Unfortunately, before the benefit of
+   reducing the size of globally-known routing destinations can be
+   achieved, it will be necessary to deploy an Inter-Domain routing
+   protocol capable of handling arbitrary network+mask pairs. Only then
+   will it be possible to aggregate individual class-C networks into
+   larger blocks represented by single routing table entries.
+
+   This means that upon introduction, the new addressing plan will not
+   in and of itself help solve the routing table size problem. Once the
+   new Inter-Domain routing protocol is deployed, however, an immediate
+   drop in the number of destinations which clients of the new protocol
+   must carry will occur.  A detailed analysis of the magnitude 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
+
+
+
+Fuller, Li, Yu, & Varadhan                                      [Page 6]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   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 happy side effect
+   of distributing the address allocation procedure, greatly reducing
+   the load on the central authority.
+
+   3.1.  Present Allocation Figures
+
+      A back-of-the-envelope 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 16256 class-B numbers have been allocated, leaving 10789.
+      Assuming that recent trends continue, the number of allocated
+      class-B's will continue to double approximately once a year. At
+      this rate of grown, all class-B's will be exhausted within about
+      15 months.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                      [Page 7]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   3.2.  Historic growth rates
+
+      MM/YY     ROUTES                        MM/YY     ROUTES
+                ADVERTISED                              ADVERTISED
+      ------------------------                -----------------------
+      Feb-92    4775                          Apr-90    1525
+      Jan-92    4526                          Mar-90    1038
+      Dec-91    4305                          Feb-90    997
+      Nov-91    3751                          Jan-90    927
+      Oct-91    3556                          Dec-89    897
+      Sep-91    3389                          Nov-89    837
+      Aug-91    3258                          Oct-89    809
+      Jul-91    3086                          Sep-89    745
+      Jun-91    2982                          Aug-89    650
+      May-91    2763                          Jul-89    603
+      Apr-91    2622                          Jun-89    564
+      Mar-91    2501                          May-89    516
+      Feb-91    2417                          Apr-89    467
+      Jan-91    2338                          Mar-89    410
+      Dec-90    2190                          Feb-89    384
+      Nov-90    2125                          Jan-89    346
+      Oct-90    2063                          Dec-88    334
+      Sep-90    1988                          Nov-88    313
+      Aug-90    1894                          Oct-88    291
+      Jul-90    1727                          Sep-88    244
+      Jun-90    1639                          Aug-88    217
+      May-90    1580                          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 no 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+mask fields (as opposed to the current
+      class-A/B/C distinction) be added to the common Internet inter-
+      domain routing protocol(s).
+
+
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                      [Page 8]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   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
+           followed by a significant reduction in the rate growth of
+           routing table size should occur (for default-free routers).
+
+   3.3.2. Growth rate projections
+
+      Currently, a default-free routing table (for example, the routing
+      tables maintained by the routers in the NSFNET backbone) contains
+      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(2) 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.
+
+      Under the proposed plan, growth of the routing table in a
+      default-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.
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                      [Page 9]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+      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 grown rate of
+      approximately 6%.  This is in clear contrast to the current annual
+      growth of 150%.  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 1338                      Supernetting                     June 1992
+
+
+4.    Changes to Inter-Domain routing protocols
+
+   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[RFC1267]) 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+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 mechanisms that routers use to
+   interpret routing information returned by the 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
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 11]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+          (this makes intuitive sense - if a network is multi-homed, all
+          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 make the
+   implementation be generalized, so that 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.
+
+
+
+
+
+
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 12]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   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:
+
+        accept 128.32.0.0
+        accept 128.120.0.0
+        accept 134.139.0.0
+        accept 36.0.0.0
+
+   would look something like:
+
+        accept 128.32.0.0 255.255.0.0
+        accept 128.120.0.0 255.255.0.0
+        accept 134.139.0.0 255.255.0.0
+        deny 36.2.0.0 255.255.0.0
+        accept 36.0.0.0 255.0.0.0
+
+   This is merely making explicit the network mask which was implied by
+   the class-A/B/C classification of network numbers.
+
+   4.3.  How the rules work
+
+   Rule #1 guarantees that the routing algorithm used is consistent
+   across implementations and consistent with other routing protocols,
+   such as OSPF. Multi-homed networks are always explicitly advertised
+   by every service provider through which they are routed even if they
+   are a specific subset of one service provider's aggregate (if they
+   are not, they clearly must be explicitly advertised). It may seem as
+   if the "primary" service provider could advertise the multi-homed
+   site implicitly as part of its aggregate, but the assumption that
+   longest-match routing is always done causes this not to work.
+
+   Rule #2 guarantees that no routing loops form due to aggregation.
+   Consider a mid-level network which has been allocated the 2048
+   class-C networks starting with 192.24.0.0 (see the example in section
+   5 for more on this).  The mid-level advertises to a "backbone"
+   192.24.0.0/255.248.0.0. Assume that the "backbone", in turn, has been
+   allocated the block of networks 192.0.0.0/255.0.0.0. The backbone
+   will then advertise this aggregate route to the mid-level. Now, if
+   the mid-level loses internal connectivity to the network
+   192.24.1.0/255.255.255.0 (which is part of its aggregate), traffic
+   from the "backbone" to the mid-level to destination 192.24.1.1 will
+   follow the mid-level's advertised route. When that traffic gets to
+   the mid-level, however, the mid-level *must not* follow the route
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 13]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   192.0.0.0/255.0.0.0 it learned from the backbone, since that would
+   result in a routing loop. Rule #2 says that the mid-level may not
+   follow a less-specific route for a destination which matches one of
+   its own aggregated routes. Note that handling of the "default" route
+   (0.0.0.0/0.0.0.0) is a special case of this rule - a network must not
+   follow the default to destinations which are part of one of it's
+   aggregated advertisements.
+
+   4.4.  Responsibility for and configuration of aggregation
+
+   The AS which owns a range of addresses has the sole authority for
+   aggregation of its address space.  In the usual case, the AS will
+   install manual configuration commands in its border routers to
+   aggregate some portion of its address space.  As AS can also delegate
+   aggregation authority to another AS.  In this case, aggregation is
+   done in the other AS by one of its border routers.
+
+   When an inter-domain border router performs route aggregation, it
+   needs to know the range of the block of IP addresses to be
+   aggregated.  The basic principle is that it should aggregate as much
+   as possible but not to aggregate those routes which cannot be treated
+   as part of a single unit due to multi-homing, policy, or other
+   constraints.
+
+   One mechanism is to do aggregation solely based on dynamically
+   learned routing information. This has the danger of not specifying a
+   precise enough range since when a route is not present, it is not
+   always possible to distinguish whether it is temporarily unreachable
+   or that it does not belong in the aggregate. Purely dynamic routing
+   also does not allow the flexibility of defining what to aggregate
+   within a range. The other mechanism is to do all aggregation based on
+   ranges of blocks of IP addresses preconfigured in the router.  It is
+   recommended that preconfiguration be used, since it more flexible and
+   allows precise specification of the range of destinations to
+   aggregate.
+
+   Preconfiguration does require some manually-maintained configuration
+   information, but not excessively more so than what router
+   administrators already maintain today. As an addition to the amount
+   of information that must be typed in and maintained by a human,
+   preconfiguration is just a line or two defining the range of the
+   block of IP addresses to aggregate. In terms of gathering the
+   information, if the advertising router is doing the aggregation, its
+   administrator knows the information because the aggregation ranges
+   are assigned to its domain.  If the receiving domain has been granted
+   the authority to and task of performing aggregation, the information
+   would be known as part of the agreement to delegate aggregation.
+   Given that it is common practice that a network administrator learns
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 14]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   from its neighbor which routes it should be willing to accept,
+   preconfiguration of aggregation information does not introduce
+   additional administrative overhead.
+
+5.    Example of new allocation and routing
+
+   5.1.  Address allocation
+
+   Consider the block of 2048 class-C network numbers beginning with
+   192.24.0.0 (0xC0180000 and ending with 192.31.255.0 (0xC01FFF00)
+   allocated to a single network provider, "RA". A "supernetted" route
+   to this block of network numbers would be described as 192.24.0.0
+   with mask of 255.248.0.0 (0xFFF80000).
+
+   Assume this service provider connects six clients in the following
+   order (significant because it demonstrates how temporary "holes" may
+   form in the service provider's address space):
+
+       "C1" requiring fewer than 2048 addresses (8 class-C networks)
+
+       "C2" requiring fewer than 4096 addresses (16 class-C networks)
+
+       "C3" requiring fewer than 1024 addresses (4 class-C networks)
+
+       "C4" requiring fewer than 1024 addresses (4 class-C networks)
+
+       "C5" requiring fewer than 512 addresses (2 class-C networks)
+
+       "C6" requiring fewer than 512 addresses (2 class-C networks)
+
+   In all cases, the number of IP addresses "required" by each client is
+   assumed to allow for significant growth. The service provider
+   allocates its address space as follows:
+
+       C1: allocate 192.24.0 through 192.24.7. This block of networks is
+           described by the "supernet" route 192.24.0.0 and mask
+           255.255.248.0
+
+       C2: allocate 192.24.16 through 192.24.31. This block is described
+           by the route 192.24.16.0, mask 255.255.240.0
+
+       C3: allocate 192.24.8 through 192.24.11. This block is described
+           by the route 192.24.8.0, mask 255.255.252.0
+
+       C4: allocate 192.24.12 through 192.24.15. This block is described
+           by the route 192.24.12.0, mask 255.255.252.0
+
+       C5: allocate 192.24.32 and 192.24.33. This block is described by
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 15]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+           the route 192.24.32.0, mask 255.255.254.0
+
+       C6: allocate 192.24.34 and 192.24.35. This block is described by
+           the route 192.24.34.0, mask 255.255.254.0
+
+   Note that if the network provider uses an IGP which can support
+   classless networks, he can (but doesn't have to) perform
+   "supernetting" at the point where he connects to his clients and
+   therefore only maintain six distinct routes for the 36 class-C
+   network numbers. If not, explicit routes to all 36 class-C networks
+   will have to be carried by the IGP.
+
+   To make this example more realistic, assume that C4 and C5 are multi-
+   homed through some other service provider, "RB". Further assume the
+   existence of a client "C7" which was originally connected to "RB" but
+   has moved to "RA". For this reason, it has a block of network numbers
+   which are allocated out "RB"'s block of (the next) 2048 class-C
+   network numbers:
+
+       C7: allocate 192.32.0 through 192.32.15. This block is described
+           by the route 192.32.0, mask 255.255.240.0
+
+   For the multi-homed clients, we will assume that C4 is advertised as
+   primary via "RA" and secondary via "RB"; C5 is primary via "RB" and
+   secondary via "RA". To connect this mess together, we will assume
+   that "RA" and "RB" are connected via some common "backbone" provider
+   "BB".
+
+   Graphically, this simple topology looks something like this:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 16]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+
+                       C1
+192.24.0.0 -- 192.24.7.0 \         _ 192.32.0.0 - 192.32.15.0
+192.24.0.0/255.255.248.0  \       /  192.32.0.0/255.255.240.0
+                           \     /             C7
+                       C2  +----+                                 +----+
+192.24.16.0 - 192.24.31.0 \|    |                                 |    |
+192.24.16.0/255.255.240.0  |    |  _ 192.24.12.0 - 192.24.15.0 _  |    |
+                           |    | /  192.24.12.0/255.255.252.0  \ |    |
+                       C3 -|    |/              C4               \|    |
+192.24.8.0 - 192.24.11.0   | RA |                                 | RB |
+192.24.8.0/255.255.252.0   |    |___ 192.24.32.0 - 192.24.33.0 ___|    |
+                          /|    |    192.24.32.0/255.255.254.0    |    |
+                       C6  |    |               C5                |    |
+192.24.34.0 - 192.24.35.0  |    |                                 |    |
+192.24.34.0/255.255.254.0  |    |                                 |    |
+                           +----+                                 +----+
+                              \\                                     \\
+192.24.12.0/255.255.252.0 (C4) ||      192.32.12.0/255.255.252.0 (C4) ||
+192.24.32.0/255.255.254.0 (C5) ||      192.32.32.0/255.255.192.0 (C5) ||
+192.32.0.0/255.255.240.0  (C7) ||      192.32.0.0/255.248.0.0 (RB)    ||
+192.24.0.0/255.248.0.0 (RA)    ||                                     ||
+                               VV                                     VV
+                     +--------------- BACKBONE PEER  BB ---------------+
+
+
+   5.2.  Routing advertisements
+
+   To follow rule #1, RA will need to advertise the block of addresses
+   that it was given and C7.  Since C4 and C5 are multi-homed, they must
+   also be advertised.
+
+   Advertisements from "RA" to "BB" will be:
+
+       192.24.12.0/255.255.252.0 primary    (advertises C4)
+       192.24.32.0/255.255.254.0 secondary  (advertises C5)
+       192.32.0.0/255.255.240.0 primary     (advertises C7)
+       192.24.0.0/255.248.0.0 primary       (advertises remainder of RA)
+
+   For RB, the advertisements must also include C4 and C5 as well as
+   it's block of addresses.  Further, RB may advertise that C7 is
+   unreachable.
+
+   Advertisements from "RB" to "BB" will be:
+
+       192.24.12.0/255.255.252.0 secondary  (advertises C4)
+       192.24.32.0/255.255.254.0 primary    (advertises C5)
+       192.32.0.0/255.248.0.0 primary       (advertises remainder of RB)
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 17]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   To illustrate the problem alluded to by the "note" in section 4.2,
+   consider what happens if RA loses connectivity to C7 (the client
+   which is allocated out of RB's space). In a stateful protocol, RA
+   will announce to BB that 192.32.0.0/255.255.240.0 has become
+   unreachable. Now, when BB flushes this information out of its routing
+   table, any future traffic sent through it for this destination will
+   be forwarded to RB (where it will be dropped according to Rule #2) by
+   virtue of RB's less specific match 192.32.0.0/255.248.0.0.  While
+   this does not cause an operational problem (C7 is unreachable in any
+   case), it does create some extra traffic across "BB" (and may also
+   prove confusing to a network manager debugging the outage with
+   "traceroute"). A mechanism to cache such unreachability information
+   would help here, but is beyond the scope of this document (such a
+   mechanism is also not implementable in the near-term).
+
+6.  Transitioning to a long term solution
+
+   This solution does not change the Internet routing and addressing
+   architectures.  Hence, transitioning to a more long term solution is
+   not affected by the deployment of this plan.
+
+7.  Conclusions
+
+   We are all aware of the growth in routing complexity, and the rapid
+   increase in allocation of network numbers.  Given the rate at which
+   this growth is being observed, we expect to run out in a few short
+   years.
+
+   If the inter-domain routing protocol supports carrying network routes
+   with associated masks, all of the major concerns demonstrated in this
+   paper would be eliminated.
+
+   One of the influential factors which permits maximal exploitation of
+   the advantages of this plan is the number of people who agree to use
+   it.  It is hoped that having the IAB and the Internet society bless
+   this plan would go a long way in the wide deployment, and hence
+   benefit of this plan.
+
+   If service providers start charging networks for advertising network
+   numbers, this would be a very great incentive to share the address
+   space, and hence the associated costs of advertising routes to
+   service providers.
+
+8.  Recommendations
+
+   The NIC should begin to hand out large blocks of class-C addresses to
+   network service providers.  Each block must fall on bit boundaries
+   and should be large enough to serve the provider for two years.
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 18]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+   Further, the NIC should distribute very large blocks to continental
+   and national network service organizations to allow additional levels
+   of aggregation to take place at the major backbone networks.
+
+   Service providers will further allocate power-of-two blocks of
+   class-C addresses from their address space to their subscribers.
+
+   All organizations, including those which are multi-homed, should
+   obtain address space from their provider (or one of their providers,
+   in the case of the multi-homed).  These blocks should also fall on
+   bit boundaries to permit easy route aggregation.
+
+   To allow effective use of this new addressing plan to reduce
+   propagated routing information, appropriate IETF WGs will specify the
+   modifications needed to Inter-Domain routing protocols.
+   Implementation and deployment of these modifications should occur as
+   quickly as possible.
+
+9.  Bibliography
+
+   [RFC1247]  Moy, J, "The OSPF Specification  Version 2", January 1991.
+
+10.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+11.  Authors' Addresses
+
+      Vince Fuller
+      BARRNet
+      Pine Hall 115
+      Stanford, CA, 94305-4122
+      email: vaf@Stanford.EDU
+
+
+      Tony Li
+      cisco Systems, Inc.
+      1525 O'Brien Drive
+      Menlo Park, CA 94025
+      email: tli@cisco.com
+
+      Jessica (Jie Yun) Yu
+      Merit Network, Inc.
+      1071 Beal Ave.
+      Ann Arbor, MI 48109
+      email: jyy@merit.edu
+
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 19]
+
+RFC 1338                      Supernetting                     June 1992
+
+
+      Kannan Varadhan
+      Internet Engineer, OARnet
+      1224, Kinnear Road,
+      Columbus, OH 43212
+      email: kannan@oar.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fuller, Li, Yu, & Varadhan                                     [Page 20]
+
\ No newline at end of file