5. Routing Implementation Considerations

5. Routing Implementation Considerations

With the change from classful network numbers to classless prefixes,

it is not possible to infer the network mask from the initial bit

pattern of an IPv4 address. This has implications for how routing

information is stored and propagated. Network masks or prefix

lengths must be explicitly carried in routing protocols. Interior

routing protocols, such as OSPF [RFC2328], Intermediate System to

Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453], and Cisco

Enhanced Interior Gateway Routing Protocol (EIGRP), and the BGP4

exterior routing protocol [RFC4271], all support this functionality,

having been developed or modified as part of the deployment of

classless inter-domain routing during the 1990s.

Older interior routing protocols, such as RIP [RFC1058], HELLO, and

Cisco Interior Gateway Routing Protocol (IGRP), and older exterior

routing protocols, such as Exterior Gateway Protocol (EGP) [RFC904],

do not support explicit carriage of prefix length/mask and thus

cannot be effectively used on the Internet other than in very limited

stub configurations. Although their use may be appropriate in simple

legacy end-site configurations, they are considered obsolete and

should NOT be used in transit networks connected to the global

Internet.

Similarly, routing and forwarding tables in layer-3 network equipment

must be organized to store both prefix and prefix length or mask.

Equipment that organizes its routing/forwarding information according

to legacy Class A/B/C network/subnet conventions cannot be expected

to work correctly on networks connected to the global Internet; use

of such equipment is not recommended. Fortunately, very little such

equipment is in use today.

5.1. Rules for Route Advertisement

1. Forwarding in the Internet is done on a longest-match basis.

   This implies that destinations that are multi-homed relative to a

   routing domain must always be explicitly announced into that

   routing domain (i.e., they cannot be summarized). If a network

   is multi-homed, all of its paths into a routing domain that is

   "higher" in the hierarchy of networks must be known to the

   "higher" network).

2. A router that generates an aggregate route for multiple, more-

   specific routes must discard packets that match the aggregate

   route, but not any of the more-specific routes. In other words,

   the "next hop" for the aggregate route should be the null

   destination. This is necessary to prevent forwarding loops when

   some addresses covered by the aggregate are not reachable.



Note that during failures, partial routing of traffic to a site that

takes its address space from one service provider but that is

actually reachable only through another (i.e., the case of a site

that has changed service providers) may occur because such traffic

will be forwarded along the path advertised by the aggregated route.

Rule #2 will prevent packet misdelivery by causing 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 that network rather than in the network that is no

longer advertising the more-specific prefix. This may be confusing

to those trying to diagnose connectivity problems; see the example in

Section 6.2 for details. A solution to this perceived "problem" is

beyond the scope of this document; it lies with better education of

the user/operator community, not in routing technology.

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 to

prefix 0.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 only be advertised to another routing domain when a

router is explicitly configured to do so, never as a non-configured,

"default" option.

5.2. How the Rules Work

Rule #1 guarantees that the forwarding algorithm used is consistent

across routing protocols and implementations. 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 longest-match forwarding causes this not to work.

More details are provided in [RFC4116].

Rule #2 guarantees that no routing loops form due to aggregation.

Consider a site that has been assigned 192.168.64/19 by its "parent"

provider, which has 192.168.0.0/16. The "parent" network will

advertise 192.168.0.0/16 to the "child" network. If the "child"

network were to lose internal connectivity to 192.168.65.0/24 (which

is part of its aggregate), traffic from the "parent" to the to the

"child" destined for 192.168.65.1 will follow the "child's"

advertised route. When that traffic gets to the "child", however,

the child must not follow the route 192.168.0.0/16 back up to the

"parent", since that would result in a forwarding loop. Rule #2 says



that the "child" may not follow a less-specific route for a

destination that matches one of its own aggregated routes (typically,

this is implemented by installing a "discard" or "null" route for all

aggregated prefixes that one network advertises to another). Note

that handling of the "default" route (0.0.0.0/0) is a special case of

this rule; a network must not follow the default to destinations that

are part of one of its aggregated advertisements.

5.3. A Note on Prefix Filter Formats

Systems that process route announcements must be able to verify that

information that they receive is acceptable according to policy

rules. Implementations that filter route advertisements must allow

masks or prefix lengths in filter elements. Thus, filter elements

that formerly were specified as

accept 172.16.0.0

accept 172.25.120.0.0

accept 172.31.0.0

deny 10.2.0.0

accept 10.0.0.0

now look something like this:

accept 172.16.0.0/16

accept 172.25.0.0/16

accept 172.31.0.0/16

deny 10.2.0.0/16

accept 10.0.0.0/8

This is merely making explicit the network mask that was implied by

the Class A/B/C classification of network numbers. It is also useful

to enhance filtering capability to allow the match of a prefix and

all more-specific prefixes with the same bit pattern; fortunately,

this functionality has been implemented by most vendors of equipment

used on the Internet.

5.4. Responsibility for and Configuration of Aggregation

Under normal circumstances, a routing domain (or "Autonomous System")

that has been allocated or assigned a set of prefixes has sole

responsibility for aggregation of those prefixes. In the usual case,

the AS will install configuration in one or more of its routers to

generate aggregate routes based on more-specific routes known to its

internal routing system. These aggregate routes are advertised into

the global routing system by the border routers for the routing

domain. The more-specific internal routes that overlap with the

aggregate routes should not be advertised globally. In some cases,



an AS may wish to delegate aggregation responsibility to another AS

(for example, a customer may wish for its service provider to

generate aggregated routing information on its behalf); in such

cases, aggregation is performed by a router in the second AS

according to the routes that it receives from the first, combined

with configured policy information describing how those routes should

be aggregated.

Note that one provider may choose to perform aggregation on the

routes it receives from another without explicit agreement; this is

termed "proxy aggregation". This can be a useful tool for reducing

the amount of routing state that an AS must carry and propagate to

its customers and neighbors. However, proxy aggregation can also

create unintended consequences in traffic engineering. Consider what

happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs

proxy aggregation while AS 3 does not. Other ASes that receive

transit routing information from both AS 2 and AS 3 will see an

inconsistent view of the routing information originated by AS 1.

This may cause an unexpected shift of traffic toward AS 1 through AS

3 for AS 3's customers and any others receiving transit routes from

AS 3. Because proxy aggregation can cause unanticipated consequences

for parts of the Internet that have no relationship with either the

source of the aggregated routes or the party providing aggregation,

it should be used with extreme caution.

Configuration of the routes to be combined into aggregates is an

implementation of routing policy and requires some manually

maintained information. As an addition to the information that must

be maintained for a set of routeable prefixes, aggregation

configuration is typically just a line or two defining the range of

the block of IPv4 addresses to be aggregated. A site performing its

own aggregation is doing so for address blocks that it has been

assigned; a site performing aggregation on behalf of another knows

this information because of an agreement to delegate aggregation.

Assuming that the best common practice for network administrators is

to exchange lists of prefixes to accept from each other,

configuration of aggregation information does not introduce

significant additional administrative overhead.



The generation of an aggregate route is usually specified either

statically or in response to learning an active dynamic route for a

prefix contained within the aggregate route. If such dynamic

aggregate route advertisement is done, care should be taken that

routes are not excessively added or withdrawn (known as "route

flapping"). In general, a dynamic aggregate route advertisement is

added when at least one component of the aggregate becomes reachable

and it is withdrawn only when all components become unreachable.

Properly configured, aggregated routes are more stable than non-

aggregated routes and thus improve global routing stability.

Implementation note: Aggregation of the "Class D" (multicast) address

space is beyond the scope of this document.

5.5. Route Propagation and Routing Protocol Considerations

Prior to the original deployment of CIDR, common practice was to

propagate routes learned via exterior routing protocols (i.e., EGP or

BGP) through a site's interior routing protocol (typically, OSPF,

IS-IS, or RIP). This was done to ensure that consistent and correct

exit points were chosen for traffic to be sent to a destination

learned through those protocols. Four evolutionary effects -- the

advent of CIDR, explosive growth of global routing state, widespread

adoption of BGP4, and a requirement to propagate full path

information -- have combined to deprecate that practice. To ensure

proper path propagation and prevent inter-AS routing inconsistency

(BGP4's loop detection/prevention mechanism requires full path

propagation), transit networks must use internal BGP (iBGP) for

carrying routes learned from other providers both within and through

their networks.

---