RFC 1519 CIDR Address Strategy September 1993
4. Changes to inter-domain routing protocols and practices
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 [1]) 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 and 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 in a new set of 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
(this makes intuitive sense - if a network is multi-homed, all
Fuller, Li, Yu & Varadhan [Page 11]
RFC 1519 CIDR Address Strategy September 1993
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 be generalized,
so that an 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.
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:
Fuller, Li, Yu & Varadhan [Page 12]
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.