It’s 2018. IPv6 has been around for 20+ years and global adoption is above 20%. Among those who have not yet deployed the modern version of the IP protocol, one particular category stands out: enterprise networks.
And you know what? I can’t blame them; because if you are going to deploy IPv6 in an enterprise network, especially a small one, you almost inevitably face one problem, which was mostly ignored until recently — multihoming.
One might ask: what’s so special about enabling IPv6 multihoming for an enterprise/small to medium business network? Isn’t BGP supposed to solve all multihoming problems? Well, yes and no.
Enterprise multihoming problems
First of all, enterprise networks quite often do not have their own address space but use provider-aggregatable (PA) addresses, allocated by their ISPs.
Secondly, sometimes running BGP between an enterprise network and its ISP might not be desirable or even possible. Besides, does having every small network (ten people, two printers and a kitten) advertising their own /48 globally sound like a good idea to you? I suspect it doesn’t unless you are in a business of selling memory and CPU for backbone routers.
So, it would be quite reasonable to expect that a multihomed network receives IPv6 address assignments from each ISP and its hosts have addresses in all assigned prefixes.
An IPv6 host, by design, can have multiple addresses. To select a specific address to be used as a source for new traffic flow, the source address selection algorithm defined in RFC 6724 is used.
Now two very interesting issues arise and need to be solved before the network in question can benefit from IPv6 multihoming.
Routing
The first problem is routing. If a host has addresses in multiple prefixes and can select any of them as its source address, the source address of the packet needs to be taken into account while the routing decision is being made.
A packet has to be sent to an ISP uplink if, and only if, its source address belongs to that ISP address space. If the next-hop is chosen by traditional routing mechanisms (by looking at the destination only), packets with source addresses from one ISP address space could be sent to another ISP. If that second ISP does the right thing and has BCP38 implemented, those packets will be dropped, causing connectivity issues and user unhappiness. Even if the ISP does not have BCP38 implemented, the anti-spoofing filtering could happen further upstream.
There are many ways to solve this problem. The easiest way is well-known as policy-based routing: it works very well for simple topologies but quickly becomes an operational nightmare as the network complexity increases.
Some recently developed advanced technologies could be potentially suitable for selecting a network path based on a packet source address, for example, IPv6 Segment Routing or Source Address Dependent Routing (SADR), especially for large complex networks.
For simplicity, all examples below are using policy-based routing.
Source address selection and prefix availability
The second problem is more tricky. When both uplinks are operational, hosts may use addresses on both prefixes and those packets will be sent to corresponding uplinks, as described above. However, if one uplink goes down, that ISP’s addresses should not be used anymore as there is no uplink the traffic can be sent to and there is no way the return traffic would reach the hosts.
So, it looks like the network needs to signal the prefix’s availability to hosts so that hosts don’t use source addresses that can’t be routed outside the network. It might sound crazy but what if I tell you that there is a mechanism for this already and it’s a part of the StateLess Address AutoConfiguration (SLAAC) (RFC 4862).
SLAAC allows hosts to configure their interfaces based on information from Router Advertisement (RA) messages sent by a router. An RA message might contain one or more Prefix Information Options (PIOs, [RFC 4861]) which include a /64 network prefix and, among other information, the preferred lifetime for that prefix. The preferred lifetime defines for how long the particular address is in a ‘preferred’ state, which means its use in arbitrary communication is unrestricted.
When the preferred lifetime is expired, the address becomes deprecated (its use is discouraged, but not strictly forbidden). Receiving an RA with preferred lifetime for the prefix set to 0 leads to immediate deprecation of all addresses in the affected prefix. This functionality is widely used in renumbering IPv6 networks.
How can SLAAC be used in a multihoming scenario? Well, the same way as it’s used in renumbering. Modifying the preferred lifetime in a PIO allows:
- Deprecating addresses by sending an RA with the preferred lifetime set to 0 in the corresponding PIO to indicate to hosts that addresses from that prefix should not be used.
- Making previously unused (deprecated) prefixes usable again (by sending an RA containing a POI with a non-zero preferred lifetime) to indicate to hosts that addresses from that prefix can be used again (for example, when the failed uplink comes back up).
The next question is: how to bind the network topology and its changes with PIO parameters? It looks like we need a new functionality on routers, so they can:
- Send RAs triggered by configurable event policies in response to uplink status change events.
- While sending periodic or solicited RAs, set the value in the given RA field (for example, PIO preferred lifetime) based on the uplink status.
To some degree, the desired behaviour is similar to widely implemented Virtual Router Redundancy Protocol (VRRP) interface tracking, when a router changes its VRRP priority based on the status of the interface.
The exact definition of the ‘uplink status change’ event may vary for each network. For example, the following can be considered as an indication of uplink availability:
- Physical interface status
- BGP session status
- Results of connectivity checks originated from the router itself
- Presence of a particular route
It should be noted that the idea of deprecating a prefix when the corresponding uplink becomes unavailable is not new — it’s been here for a while as a requirement of L-13 for IPv6 CPE routers ([RFC 7084]) and as documented behaviour of homenet devices. The only problem is that it’s never made its way to enterprise-grade routers.
Example scenarios
Let’s now look at some typical scenarios to see how the proposed solution would work for them.
Note: This article is not trying to describe all possible topologies and use cases for using conditional RAs in enterprise multihoming. Readers who would like to know more about the proposed solutions are advised to consult the original IETF document: draft-ietf-v6ops-conditional-ras, which discusses the solution in more detail.
Let’s consider an enterprise network connected to two ISPs: the Red ISP and the Blue ISP. Each ISP assigns one /56 prefix from its address space: 2001:db8:1::/56 (the red prefix) and 2001:db8:2::/56 (the blue prefix). For simplicity, we’ll call addresses in those prefixes ‘red addresses’ / ’blue addresses’ and the corresponding uplinks ‘red uplink’ and ‘blue uplink’ respectively.
Scenario 1: Single router with two ISP uplinks
The example topology is shown in Figure 1.
Figure 1 — While the border/first-hop router R1 might look like a SPOF, in reality, it might be two physical devices acting as a single logical router.
To ensure packets are always sent to the right ISP, the router needs to have the following policy configured:
=== if (source address is red) then (default next-hop is red uplink). if (source address blue) then (default next-hop is blue uplink). ===
If an uplink goes down, the router needs to explicitly deprecate addresses from the corresponding prefix on the LAN. The uplink recovery needs to make the prefix operational again. To achieve this, the following policy would be needed:
prefix 2001:db8:1::/64 { IF (red uplink is up) THEN preferred lifeme 604800 ### 7 days, default value ELSE preferred_lifeme 0 } prefix 2001:db8:2::/64 { IF (blue uplink is up) THEN preferred lifeme 604800 ### 7 days, default value ELSE preferred_lifeme 0 }
Such policy allows both uplinks to be used simultaneously, in load-sharing mode.
If it’s desirable to use the uplinks in primary/backup mode (for example, the red uplink is a primary one while the blue one should be used only when the red one is unavailable), the RA policy would be slightly different: blue addresses should be used if and only if the red uplink is down:
prefix 2001:db8:1::/64 { IF (red uplink is up) THEN preferred lifeme 604800 ### 7 days, default value ELSE preferred_lifeme 0 } prefix 2001:db8:2::/64 { IF (red uplink is up) THEN preferred_lifeme 0 ELSE preferred lifeme 604800 ### 7 days, default value }
Scenario 2: Two routers, each ISP uplink is terminated on a dedicated router
The example topology for this scenario is shown in Figure 2.
Figure 2 — The routing policy, in this case, is similar to the one described in the previous section but both routers need to have a route to the neighbour’s uplink.
The RA policy depends on how the uplinks are supposed to be used: in load sharing (both uplinks simultaneously) or in primary/backup mode. For the latter, the easiest way would be to bind the VRRP mastership and the uplink usage together, so the router with the active uplink is the VRRP master and advertises a non-zero preferred lifetime for the corresponding prefix. For example, if the red and the blue uplinks are primary and backup respectively, then R1 should be the VRRP master by default but lose its mastership if the red uplink becomes unreachable (the standard VRRP interface tracking feature could be used for that).
Router R1:
prefix 2001:db8:1::/64 { IF (vrrp master) THEN preferred lifeme 604800 ### 7 days, default value ELSE preferred_lifeme 0 } prefix 2001:db8:2::/64 { IF (vrrp master) THEN preferred_lifeme 0 ELSE preferred lifeme 604800 ### 7 days, default value }
Router R2:
prefix 2001:db8:1::/64 { IF (vrrp master) THEN preferred_lifeme 0 ELSE preferred lifeme 604800 ### 7 days, default value } prefix 2001:db8:2::/64 { IF (vrrp master) THEN preferred lifeme 604800 ### 7 days, default value preferred_lifeme 0 ELSE preferred_lifeme 0 }
You can multihome (and deploy IPv6) today!
Those who are still reading this might wonder: what enterprise routers support the conditional RA feature? And what software release is needed?
Well, good news: you don’t have to wait until router vendors add those configuration knobs to modify the RA setting. It can be done (and IPv6 multihoming deployed) right now by using automation available on most popular routing platforms. For example, JunOS automation (event scripts and even policies) provide all the tools needed to enable conditional RAs today as described in this article.
So, there is no reason not to deploy IPv6!
The above is a summary of a presentation Jen gave at RIPE 76.
Jen Linkova is a Network Engineer at Google and Co-Chair of the RIPE IPv6 Working Group.
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.
It seems to me to be quite high risk to be deploying behaviour in a distributed computing environment (the routers). Essentially, if I understand this piece correctly, each enterprise will be building its own coordination protocol and will not have the expertise to validate or test it.
An open question: wouldn’t it be more straightforward to rely on the homenet model/protocols? If not does there need to be work to build a comparable protocol for the enterprise space?