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]
RFC 1519 CIDR Address Strategy September 1993
the class A address would need to support and use a classless IGP.
Maintenance of DNS with a subnetted class A is somewhat painful. As
part of the mechanism for providing reverse address lookups, DNS
maintains a "IN-ADDR.ARPA" reverse domain. This is configured by
reversing the dotted decimal network number, appending "IN-ADDR.ARPA"
and using this as a type of pseudo-domain. Individual hosts then end
up pointing back to a host name. Thus, for example, 131.108.1.111
has a DNS record "111.1.108.131.IN-ADDR.ARPA." Since the pseudo-
domains can only be delegated on a byte boundary, this becomes
painful if a stub domain receives a block of address space that does
not fall on a byte boundary. The solution in this case is to
enumerate all of the possible byte combinations involved. This is
painful, but workable. This is discussed further below.
Routing within a class A used for CIDR is also an interesting
challenge. The usual case will be that a domain will be assigned a
portion of the class A address space. The domain can either use an
IGP which allows variable length subnets or it can pick a single
subnet mask to be used throughout the domain. In the latter case,
difficulties arise because other domains have been allocated other
parts of the class A address space and may be using a different
subnet mask. If the domain is itself a transit, it may also need to
allocate some portion of its space to a client, which might also use
a different subnet mask. The client would then need routing
information about the remainder of the class A.
If the client's IGP does not support variable length subnet masks,
this could be done by advertising the remainder of the class A's
address space in appropriately sized subnets. However, unless the
client has a very large portion of the class A space, this is likely
to result in a large number of subnets (for example, a mask of
255.255.255.0 would require a total of 65535 subnets, including those
allocated to the client). For this reason, it may be preferable to
simply use an IGP that supports variable length subnet masks within
the client's domain.
Similarly, if a transit has been assigned address space from a class
A network number, it is likely that it was not assigned the entire
class A, and that other transit domains will get address space from
this class A. In this case, the transit would also have to inject
routing information about the remainder of the class A into it's IGP.
This is analogous to the situation above, with the same
complications. For this reason, we recommend that the use of a class
A for CIDR only be attempted if IGP's with variable length subnet
mask support be used throughout the class A. Note that the IGP's
need not support supernetting, as discussed above.
Fuller, Li, Yu & Varadhan [Page 19]
RFC 1519 CIDR Address Strategy September 1993
Note that the technique here could also apply to class B addresses.
However, the limited number of available class B addresses and their
usage for multihomed networks suggests that this address space should
only be reserved for those large single organizations that warrant
this type of address. [2]