rfc1519.txt

RFC 的详细文档！


RFC 1519                 CIDR Address Strategy            September 1993


        accept 128.32.0.0
        accept 128.120.0.0
        accept 134.139.0.0
        deny 36.2.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
   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.



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


   4.4.  Responsibility for and configuration of aggregation

   The domain which has been allocated 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.  An domain
   can also delegate aggregation authority to another domain.  In this
   case, aggregation is done in the other domain 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
   from its neighbor which routes it should be willing to accept,
   preconfiguration of aggregation information does not introduce
   additional administrative overhead.

   Implementation note: aggregates which encompass the class D address
   space (multicast addresses) are currently not well understood.  At
   present, it appears that the optimal strategy is to consider



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


   aggregates to never encompass class D space, even if they do so
   numerically.

   4.5  Intra-domain protocol considerations

   While no changes need be made to internal routing protocols to
   support the advertisement of aggregated routing information between
   autonomous systems, it is often the case that external routing
   information is propagated within interior protocols for policy
   reasons or to aid in the propagation of information through a transit
   network. At the point when aggregated routing information starts to
   appear in the new exterior protocols, this practice of importing
   external information will have to be modified.  A transit network
   which imports external information will have to do one of:

      a) use an interior protocol which supports aggregated routing

      b) find some other method of propagating external information
         which does not involve flooding it through the interior
         protocol (i.e., by the use of internal BGP, for example).

      c) stop the importation of external information and flood a
         "default" route through the internal protocol for discovery
         of paths to external destinations.

   For case (a), the modifications necessary to a routing protocol to
   allow it to support aggregated information may not be simple. For
   protocols such as OSPF and IS-IS, which represent routing information
   as either a destination+mask (OSPF) or as a prefix+prefix-length
   (IS-IS) changes to support aggregated information are conceptually
   fairly simple; for protocols which are dependent on the class-A/B/C
   nature of networks or which support only fixed-sized subnets, the
   changes are of a more fundamental nature. Even in the "conceptually
   simple" cases of OSPF and IS-IS, an implementation may need to be
   modified to support supernets in the database or in the forwarding
   table.

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).





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


   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
           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



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


   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:


                       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.24.12.0/255.255.252.0 (C4) ||
192.32.0.0/255.255.240.0  (C7) ||      192.24.32.0/255.255.254.0 (C5) ||
192.24.0.0/255.248.0.0 (RA)    ||      192.32.0.0/255.248.0.0 (RB)    ||
                               ||                                     ||
                               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 is multi-homed and primary
   through RA, it must also be advertised.  C5 is multi-homed and
   primary through RB.  It need not be advertised since longest match by
   BB will automatically select RB as primary and the advertisement of



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


   RA's aggregate will be used as a secondary.

   Advertisements from "RA" to "BB" will be:

       192.24.12.0/255.255.252.0 primary    (advertises C4)
       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)

   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.  Extending CIDR to class A addresses

   At some point, it is expected that this plan will eventually consume
   all of the remaining class C address space.  As of this writing, the
   upper half of the class A address space has already been reserved for
   future expansion.  This section describes how the CIDR plan can be
   used to utilize this portion of the class A space efficiently.  It is
   expected that this contingency would only be used if no long term
   solution has become apparent by the time that the class C address
   space is consumed.

   Fundamentally, there are two differences between using a class A
   address and a block of class C's.  First, the configuration of DNS
   becomes somewhat more complicated than it is without the aggregation
   of class A subnets.  The second difference is that the routers within



Fuller, Li, Yu & Varadhan                                      [Page 18]