rfc1338.txt

RFC 的详细文档！


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]