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

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