The Babel routing protocol [RFC 8966
] is a distance vector routing protocol for next-hop routing. In next-hop routing, each node maintains a forwarding table that maps destination prefixes to next hops. The forwarding decision is a per-packet operation that depends on the destination address of the packets and on the entries of the forwarding table. When a packet is about to be routed, its destination address is compared to the prefixes of the routing table: the entry with the most specific prefix containing the destination address of the packet is chosen, and the packet is forwarded to the associated next hop. Next-hop routing is a simple, well-understood paradigm that works satisfactorily in a large number of cases.
The use of next-hop routing limits the flexibility of the routing system in two ways. First, since the routing decision is local to each router, a router A can only select a route ABC...Z if its neighbouring router B has selected the route BC...Z. Second, the only criterion used by a router to choose a route is the destination address: two packets with the same destination follow the same route. Yet, there are other data in the IP header that could conceivably be used to guide the routing decision -- the Type of Service (ToS) octet and, of course, the source address.
Source-specific routing [SS-ROUTING
], or Source Address Dependent Routing (SADR), is a modest extension to next-hop routing where the forwarding decision depends not only on the destination address but also on the source address of the packet being routed, which makes it possible for two packets with the same destination but different source addresses to be routed following different paths.
This document describes a source-specific routing extension for the Babel routing protocol [RFC 8966
]. This involves minor changes to the data structures, which must include a source prefix in addition to the destination prefix already present, and some changes to the Update, Route Request, and Seqno Request TLVs, which are extended with a source prefix. The source prefix is encoded using a mandatory sub-TLV (RFC 8966
, Section 4.4
Multihoming is the practice of connecting a single network to two or more transit networks. The main application of source-specific routing is a form of multihoming known as "multihoming with multiple addresses".
Classical multihoming consists of assigning a provider-independent range of addresses to the multihomed network and announcing it to all transit providers. While classical multihoming works well for large networks, the cost of obtaining a provider-independent address range and announcing it globally in the Internet is prohibitive for small networks. Unfortunately, it is not possible to implement classical multihoming with ordinary provider-dependent addresses: in a network connected to two providers A and B, a packet with a source address allocated by A needs to be routed through the edge router connected to A. If it is routed through the edge router connected to B, it will most likely be filtered (dropped), in accordance with [BCP84
In multihoming with multiple addresses, every host in the multihomed network is assigned multiple addresses, one for each transit provider. Additional mechanisms are needed in order (i) to choose, for each packet, a source address that is associated with a provider that is currently up, and (ii) to route each packet towards the router connected to the provider associated with its source address. One might argue that multihoming with multiple addresses splits the difficult problem of multihoming into two simpler sub-problems.
The issue of choosing a suitable source address is a decision local to the sending host and is an area of active research. The simplest solution is to use a traditional transport-layer protocol, such as TCP, and to probe all available source addresses at connection time, analogously to what is already done with destination addresses, either sequentially [RFC 6724
] or in parallel [RFC 8305
]. Since the transport-layer protocol is not aware of the multiple available addresses, flows are interrupted when the selected provider goes down (from the point of view of the user, all TCP connections are dropped when the network environment changes). A better user experience can be provided by making all of the potential source and destination addresses available to higher-layer protocols, either at the transport layer [RFC 8684
] [RFC 4960
] or at the application layer [RFC 8445
Source-specific routing solves the problem of routing a packet to the edge router indicated by its source address. Every edge router announces into the routing domain a default route specific to the prefix associated with the provider it is connected to. This route is propagated all the way to the routers on the access link, which are therefore able to route every packet to the correct router. Hosts simply send packets to their default router -- no host changes are necessary at the network layer.
In addition to multihoming with multiple addresses, we are aware of two applications of source-specific routing. Tunnels and VPNs are packet encapsulation techniques that are commonly used in the Internet to establish a network-layer topology that is different from the physical topology. In some deployments, the default route points at the tunnel; this causes the network stack to attempt to send encapsulated packets through the tunnel, which causes it to break. Various solutions to this problem are possible, the most common of which is to point a host route at the tunnel endpoint.
When source-specific routing is available, it becomes possible to announce through the tunnel a default route that is specific to the prefix served by the tunnel. Since the encapsulated packets have a source address that is not within that prefix, they are not routed through the tunnel.
The third application of source-specific routing is controlled anycast. Anycast is a technique in which a single destination address is used to represent multiple network endpoints, collectively called an "anycast group". A packet destined to the anycast group is routed to an arbitrary member of the group, typically the one that is nearest according to the routing protocol.
In many applications of anycast, such as DNS root servers, the nondeterminism of anycast is acceptable; some applications, however, require finer control. For example, in some Content Distribution Networks (CDNs), every endpoint is expected to handle a well-defined subset of the client population. With source-specific routing, it is possible for each member of the anycast group to announce a route specific to its client population, a technique that is both simpler and more robust than manually tweaking the routing protocol's metric ("prepending" in BGP).
In ordinary next-hop routing, when multiple routing table entries match the destination of a packet, the "longest prefix rule" mandates that the most specific entry applies. The reason why this rule makes sense is that the set of prefixes has the following "tree property":
For any prefixes P and P', either P and P' are disjoint, or one is morespecific than the other.
It would be a natural proposition to order pairs of prefixes pointwise: to define that (D,S) is more specific than (D',S') when D is more specific than D and S is more specific than S'. Unfortunately, the set of pairs of prefixes with the pointwise ordering doesn't satisfy the tree property. Indeed, consider the following two pairs:
(2001:db8:0:1::/64, ::/0) and (::/0, 2001:db8:0:2::/64)
These two pairs are not disjoint (a packet with destination 2001:db8:0:1::1 and source 2001:db8:0:2::1 is matched by both), but neither is more specific than the other. The effect is that there is no natural, unambiguous way to interpret a routing table such as the following:
destination source next-hop
2001:db8:0:1::/64 ::/0 A
::/0 2001:db8:0:2::/64 B
A finer ordering of pairs of prefixes is required in order to avoid all ambiguities. There are two natural choices: destination-first ordering, where (D,S) is more specific than (D',S') when
D is strictly more specific than D', or
D = D', and S is more specific than S'
and, symmetrically, source-first ordering, in which sources are compared first and destinations second.
Expedient as it would be to leave the choice to the implementation, this is not possible: all routers in a routing domain must use the same ordering lest persistent routing loops occur. Indeed, consider the following topology:
Suppose that A announces a route for (::/0, 2001:db8:0:2::/64), while D announces a route for (2001:db8:0:1::/64, ::/0). Suppose further that B uses destination-first ordering while C uses source-first ordering. Then a packet that matches both routes, say, with destination 2001:db8:0:1::1 and source 2001:db8:0:2::1, would be sent by B towards D and by C towards A and would therefore loop indefinitely between B and C.
This document mandates (Section 4
) that all routers use destination-first ordering, which is generally believed to be more useful than source-first ordering. Consider the following topology, where A is an edge router connected to the Internet and B is an internal router connected to an access network N:
(::/0, S) (D, ::/0)
Internet --- A --- B --- N
A announces a source-specific default route with source S (::/0, S), while B announces a nonspecific route to prefix D. Consider what happens to a packet with a destination in D and a source in S. With destination-first ordering, the packet is routed towards the network N, which is the only way it can possibly reach its destination. With source-first ordering, on the other hand, the packet is sent towards the Internet, with no hope of ever reaching its destination in N.