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.