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

        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.