Having multiple connections to the Internet, or being multihomed, is often a must to avoid a single point of failure. But, it is not as simple as getting two connections to the Internet — most Internet Service Providers (ISP) apply anti-spoofing so all packets sent on one ISP uplink must use a source address from this ISP.
In the legacy IPv4 world, there are basically two ways for a site to be multihomed via two ISPs:
- Get your own IPv4 address space and inject this prefix into the global routing table via BGP. The anti-spoofing mechanism based on routing tables (unicast RPF checks) does not trigger and there won’t be a problem. However, the traffic asymmetry can still be an issue for stateful devices such as firewalls if BGP is not perfectly tuned.
- Use RFC 1918 private addresses and apply Network Address Translation (NAT) to an address of the ISP when using a specific ISP link.
The first approach is often reserved for large sites with talented networking staff. The second approach is more for small and medium businesses without any networking staff.
Moving to IPv6 renders the NAT approach cumbersome and removes most of the benefit of IPv6.
While the BGP approach works perfectly for IPv6, there is a need to have an architecture for small sites. This is possible because, in IPv6, all node interfaces can have multiple addresses from multiple prefixes; so, all site nodes can have one IPv6 address from all ISPs. And if the packet using one specific ISP link uses a source address from this ISP prefix, then the packet won’t be dropped by anti-spoofing and the return traffic will be routed through this ISP (the traffic is symmetrical which is a requirement for any stateful device).
Nodes select their source address based on RFC 6724. In short, this RFC will select the source address having the longest match with the destination address. While this mechanism is perfectly fine for an enterprise network, it does not work correctly for multihoming via different ISPs. Consider, for example, a site with two ISPs (Figure 1).
Figure 1: Example showing ISP A, with a prefix of 2001:babe:a::/48; and ISP B, with a prefix of 2001:bebe:b::/48.
If the node needs to send packets to 2001:bebe:cccc::1, it will select an address from the prefix of ISP B. However, if this packet is routed on the site via ISP A, then this ISP will drop the packet.
In short, we need to be able to route packets with a source address from a prefix of ISP B via the egress router connected to ISP B. This is Source Address Depending Routing (SADR). There is an IETF draft on this topic (draft-ietf-rtgwg-dst-src-routing) and it is already implemented in Linux with experimental images in commercial routers.
In SADR, all Forwarding Information Base (FIB) entries are augmented with a source prefix, in addition to the destination prefix using ::/0, when the entry is not source specific. When forwarding a packet, SADR will select the entry matching both source and destination prefixes while preferring longest destination prefix match and breaking ties with the longest source prefix match. For example, in this very simple FIB:
| Source Prefix | Destination Prefix | Next Hop |
| 2001:babe:a::/48 | ::0 | ISP A |
| 2001:bebe:b::/48 | ::0 | ISP B |
A packet with source 2001:bebe:b::1:2:3:4 and destination 2001:bebe:cccc::1, will be routed via ISP B; avoiding all packets dropped and enforcing symmetric traffic as the return traffic will naturally be routed via ISP B.
Obviously, there will be no load sharing among the ISP uplink, but this is a very simple configuration.
If one ISP uplink fails, then draft-ietf-v6ops-conditional-ras should be configured as it will send a Router Advertisement (RA) with a prefix lifetime of 0 for the prefix of the unreachable ISP, actually removing all addresses from this prefix. So, new connections will never use those addresses and will use addresses from the other ISPs which will be SADR routed to a working ISP.
In my next post, I will present the security issues of SADR (and how to mitigate them), as well as propose a security design leveraging SADR for traffic analysis.
Eric Vyncke is a distinguished engineer working for Cisco, Belgium.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.