rfc1338.txt

RFC 的详细文档！

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: [e-mail]


      Tony Li
      cisco Systems, Inc.
      1525 O'Brien Drive
      Menlo Park, CA 94025
      email: [e-mail]

      Jessica (Jie Yun) Yu
      Merit Network, Inc.
      1071 Beal Ave.
      Ann Arbor, MI 48109
      email: [e-mail]





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


      Kannan Varadhan
      Internet Engineer, OARnet
      1224, Kinnear Road,
      Columbus, OH 43212
      email: [e-mail]














































Fuller, Li, Yu, & Varadhan                                     [Page 20]