RFC 8475

Using Conditional Router Advertisements for Enterprise Multihoming

📅 published October 2018, from ietf

RFC 8475 ✨ Using Conditional Router Advertisements for Enterprise Multihoming 🎀

okay bestie, this is part 1 of 4!! 💖 The title block says this one is an Informational doc (so not a Standards Track spec 🦋), by J. Linkova (Google) and M. Stucchi (RIPE NCC), dated October 2018. It's an ISSN 2070-1721 RFC, and it doesn't obsolete or update anything. 🌸 It's all about how an enterprise can hook up to multiple ISPs using address space those ISPs handed out.

Abstract

so the big picture 🧚 This doc looks at the most common ways an enterprise network connects to several ISPs using address space assigned by an ISP, and how the approach from "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be used in those setups. 💅 Here's the tea: enterprise multihoming without any kind of address translation is still unsolved, because two things have to happen. The network has to pick the right egress ISP based on the packet's source address, and hosts have to pick the right source address for the egress ISP they want. 😭

The other doc fixes the uplink problem by adding a new routing feature called Source Address Dependent Routing, and it uses Router Advertisements to nudge hosts toward the right source address. 🔥 This one doesn't try to solve everything. It takes that approach and applies it to a limited set of common use cases, mainly an enterprise with two Internet uplinks running either primary/backup or both at once, where the hosts might not fully support multihoming yet (see RFC 8028). 🫶

Status of This Memo

boring but important ✨ This is not an Internet Standards Track spec. It's published for information only. 🦋

It's a product of the Internet Engineering Task Force (IETF) and reflects the consensus of the IETF community. It went through public review and got approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for that. 💜

For the current status, errata, and feedback, go to https://www.rfc-editor.org/info/rfc8475. 🌈

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read them closely, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes. 📜

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  Common Enterprise Multihoming Scenarios . . . . . . . . . . .   4
  2.1.  Two ISP Uplinks, Primary and Backup . . . . . . . . . . .   4
  2.2.  Two ISP Uplinks, Used for Load-Balancing  . . . . . . . .   5
3.  Conditional Router Advertisements . . . . . . . . . . . . . .   5
  3.1.  Solution Overview . . . . . . . . . . . . . . . . . . . .   5
    3.1.1.  Uplink Selection  . . . . . . . . . . . . . . . . . .   5
    3.1.2.  Source Address Selection and Conditional RAs  . . . .   5
  3.2.  Example Scenarios . . . . . . . . . . . . . . . . . . . .   8
    3.2.1.  Single Router, Primary/Backup Uplinks . . . . . . . .   8
    3.2.2.  Two Routers, Primary/Backup Uplinks . . . . . . . . .   9
    3.2.3.  Single Router, Load-Balancing between Uplinks . . . .  12
    3.2.4.  Two Routers, Load-Balancing between Uplinks . . . . .  12
    3.2.5.  Topologies with Dedicated Border Routers  . . . . . .  13
    3.2.6.  Intrasite Communication during Simultaneous Uplinks
            Outage  . . . . . . . . . . . . . . . . . . . . . . .  15
    3.2.7.  Uplink Damping  . . . . . . . . . . . . . . . . . . .  15
    3.2.8.  Routing Packets When the Corresponding Uplink Is
            Unavailable . . . . . . . . . . . . . . . . . . . . .  16
  3.3.  Solution Limitations  . . . . . . . . . . . . . . . . . .  16
    3.3.1.  Connections Preservation  . . . . . . . . . . . . . .  17
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
  5.1.  Privacy Considerations  . . . . . . . . . . . . . . . . .  18
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  20
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1. Introduction 🌸

this is the setup bestie 😭 Multihoming is basically a must-have for lots of enterprise networks if they want solid reliability. 💅 But once you're using more than one ISP (and the address space those ISPs gave you), you run into the problem of how to assign IP addresses to hosts. In IPv4 you don't really have a choice: you use private address space [RFC1918] and NAT [RFC3022] at the network edge [RFC4116]. 🦋

Provider Independent (PI) address space isn't always an option either, because it means running BGP between the enterprise and the ISPs. Getting and managing PI space can also be a lot of admin work. 🙈

IPv6 hosts can, by design, have multiple global-scope addresses [RFC4291], so multihoming with provider addresses looks even easier for IPv6. ✨ Each ISP hands out an IPv6 block (usually a /48), and hosts in the enterprise get addresses from each ISP's block. 👑 Okay but there's a catch 😭. Using IPv6 provider-assigned (PA) blocks for multihoming brings some challenges, and this isn't the full list:

  • Picking the right uplink based on the packet's source address.
  • Telling hosts that some source addresses should or shouldn't be used (for example, when an uplink to the ISP goes down or comes back). 🔥

[PROVIDER-ASSIGNED] digs into these challenges, and others, in detail for the general enterprise multihoming case. 🧚 It leans hard on Rule 5.5 of the default address selection algorithm [RFC6724]. Rule 5.5 makes hosts prefer source addresses in a prefix advertised by the next hop, which is super useful when different routers advertise different prefixes. 💖

Here's the thing: [RFC6724] calls Rule 5.5 optional, but the more recent [RFC8028] says multihomed hosts SHOULD support it. 😭 Unfortunately, it hasn't been widely implemented yet at the time of writing. So enterprise admins can't assume every device on their network supports Rule 5.5, especially with the very common BYOD ("Bring Your Own Device") situation. 🙈 It doesn't seem feasible to solve every multihoming scenario without Rule 5.5, but it is possible to give IPv6 multihoming with PA space for the most common use cases. 🌈 This doc shows how the general approach in [PROVIDER-ASSIGNED] can handle multihoming when:

  • The enterprise has two or more ISP uplinks.
  • Those uplinks are used for Internet access in active/backup or load-sharing mode, with no fancy traffic engineering needs.
  • Each ISP assigns the network a subnet from its own PA address space.
  • Hosts in the enterprise aren't expected to support Rule 5.5 of the default address selection algorithm [RFC6724].

1.1. Requirements Language 🎀

the rules of the game 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ✨

2. Common Enterprise Multihoming Scenarios 🦋

scenario one: the classic failover 🌸 This scenario has these key characteristics:

  • The enterprise uses uplinks to two (or more) ISPs for Internet access.
  • Each ISP assigns IPv6 PA address space to the network.
  • One ISP's uplink(s) is the primary (preferred) one. All the other uplinks are backup, and they aren't expected to be used while the primary is up. 👑
  • If the primary uplink is operational, all Internet traffic should flow through it. 💖
  • When the primary uplink fails, Internet traffic needs to flow through the backup uplinks. 😭
  • Recovery of the primary uplink needs to trigger a traffic switchover from the backup uplinks back to the primary. 🔥
  • Hosts in the enterprise aren't expected to support Rule 5.5 of the default address selection algorithm [RFC6724].

scenario two: everybody works 💅 This scenario has these key characteristics:

  • The enterprise uses uplinks to two (or more) ISPs for Internet access.
  • Each ISP assigns an IPv6 PA address space.
  • All the uplinks may be used at the same time, with traffic flows randomly (not necessarily equally) spread across them. 🧚
  • Hosts in the enterprise aren't expected to support Rule 5.5 of the default address selection algorithm [RFC6724].

3. Conditional Router Advertisements ✨

3.1. Solution Overview 🎀

the core problem bestie 😭 As [PROVIDER-ASSIGNED] points out, one of the two main problems in enterprise multihoming is picking the next-hop (uplink) based on the packet's source address. 🔥 For example, say the enterprise has two uplinks, to ISP_A and ISP_B, and hosts have addresses from subnet_A and subnet_B (belonging to ISP_A and ISP_B). Then packets sourced from subnet_A must go to the ISP_A uplink, and packets sourced from subnet_B must go to the ISP_B uplink. 💅

Careful here 🙈: sending packets with one ISP's source addresses out through a different ISP can get them dropped, if those ISPs or their uplinks do antispoofing ingress filtering [RFC2827][RFC3704].

Some work is happening in Source Address Dependent Routing (SADR), such as [DESTINATION]. But the simplest way to get this behavior right now is to apply a policy that picks a next hop or egress interface based on the packet's source address. 🌸 Most SMB/Enterprise-grade routers already have that functionality available. 👑

that's all for part 1, bestie!! 🌈💖 Part 2 is coming next 🦋

3.1.2. Source Address Selection and Conditional RAs 🎀

okay so the next problem in multihoming is picking the source address on hosts 💅. when everything is up and running, hosts have several global unique addresses and can just rely on the default address selection algorithm [RFC6724] to pick one. then the network handles choosing the right uplink based on whichever source address the host picked, as described in Section 3.1.1. 🦋 but when the network topology changes (like an uplink going up or down), the global reachability for packets from certain prefixes can get affected 😭. so those changes have to be signaled back to the hosts. for example:

  • An uplink to ISP_A went down. Hosts should not use addresses from an ISP_A prefix;
  • A primary uplink to ISP_A that was not operational has come back up. Hosts should start using the source addresses from an ISP_A prefix.

[PROVIDER-ASSIGNED] explains in detail why Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Router Advertisements (RAs) [RFC4861] are the most suitable mechanisms for signaling network topology changes to hosts, which is how they end up influencing source address selection ✨. sending an RA to change the preferred lifetime for a given prefix gives you the following functionality:

  • Deprecating addresses by sending an RA with preferred_lifetime set to 0 in the corresponding Prefix Information option (PIO) [RFC4861]. This indicates to hosts that addresses from that prefix should not be used;
  • Making a previously unused (deprecated) prefix usable again by sending an RA containing a PIO with nonzero preferred lifetime. This indicates to hosts that addresses from that prefix can be used again.

it's worth noting that only the preferred lifetime for the affected prefix needs to be changed 🧚. the goal is to influence the source address selection algorithm on hosts, not to stop them from forming addresses from a specific prefix, so the valid lifetime should not be changed. actually, changing the valid lifetime wouldn't even be possible for unauthenticated RAs (which is the most common deployment scenario), because Section 5.5.3 of [RFC4862] stops hosts from setting the valid lifetime for addresses to zero unless RAs are authenticated. the way that rule works is kinda iconic 🙈.

to make this work, first-hop routers are required to:

  • Send RAs triggered by defined event policies in response to an uplink status change event; and
  • While sending periodic or solicited RAs, set the value in the given RA field (e.g., PIO preferred lifetime) based on the uplink status.

the exact definition of "uplink status" depends on the network topology and may include conditions like:

  • Uplink interface status change;
  • Presence of a particular route in the routing table;
  • Presence of a particular route with a particular attribute (next hop, tag, etc.) in the routing table;
  • Protocol adjacency change.

in some scenarios, when two routers provide first-hop redundancy via Virtual Router Redundancy Protocol (VRRP) [RFC5798], the master-backup status can be treated as a condition for sending RAs and changing the preferred lifetime value. see Section 3.2.2 for more details 🌸.

if hosts get the IPv6 addresses of ISP DNS servers via a Recursive DNS Server (RDNSS) (see "IPv6 Router Advertisement Options for DNS Configuration" [RFC8106]), it might be desirable for the conditional RAs to update the Lifetime field of the RDNSS option as well 💜.

the trigger isn't only about forcing the router to send an unsolicited RA to spread the topology changes to all hosts. the values of the RA fields (like PIO Preferred Lifetime or DNS Server Lifetime) that the particular trigger changed need to stay the same until another event causes them to be updated. for example, if an ISP_A uplink failure causes the prefix to be deprecated, all solicited and unsolicited RAs sent by the router need to have the preferred lifetime for that PIO set to 0 until the uplink comes back up. 🚨

the proposed solution is honestly quite similar to the existing requirement L-13 for IPv6 Customer Edge Routers [RFC7084] and the documented behavior of homenet devices [RFC7788] 👑. it uses the same mechanism of deprecating a prefix when the corresponding uplink isn't operational, just applied to an enterprise network scenario. main character energy, fr fr 💅✨

3.2. Example Scenarios 🦋

this section shows how the conditional RAs solution can be applied to the most common enterprise multihoming scenarios, described in Section 2. let's gooo 🌈

                                                          --------
                                         ,-------,       /        \
               +----+ 2001:db8:1::/48  ,'         ',    :          :
               |    |-----------------+    ISP_A    +--+:          :
 2001:db8:1:1::/64 |    |                  ',         ,'    :          :
               |    |                    '-------'      :          :
H1-----------------| R1 |                                   : INTERNET :
               |    |                    ,-------,      :          :
 2001:db8:2:1::/64 |    | 2001:db8:2::/48  ,'         ',    :          :
               |    |-----------------+    ISP_B    +--+:          :
               +----+                  ',         ,'    :          :
                                         '-------'       \        /
                                                          --------

Figure 1: Single Router, Primary/Backup Uplinks

okay so picture this: a single router acts as a border router terminating two ISP uplinks, and it's also the first-hop router for hosts 🧚. each ISP assigns a /48 to the network. ISP_A is the primary uplink, used for all Internet traffic, while ISP_B is a backup, only used when the primary uplink isn't operational 😭.

to make sure packets with source addresses from ISP_A and ISP_B only get routed to the ISP_A and ISP_B uplinks respectively, the network administrator needs to configure a policy on R1:

IF (packet_source_address is in 2001:db8:1::/48)
    and
    (packet_destination_address is not in
    (2001:db8:1::/48 or 2001:db8:2::/48))
    THEN
        default next hop is ISP_A_uplink

IF (packet_source_address is in 2001:db8:2::/48)
    and
    (packet_destination_address is not in
    (2001:db8:1::/48 or 2001:db8:2::/48))
    THEN
        default next hop is ISP_B_uplink

under normal circumstances, it's desirable that all traffic goes out via the ISP_A uplink, so hosts (the host H1 in the example topology figure) should be using source addresses from 2001:db8:1:1::/64 💖. when or if the ISP_A uplink fails, hosts should stop using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 until the ISP_A uplink comes back up. to achieve this, the RA configuration on the R1 device for the interface facing H1 needs the following policy:

prefix 2001:db8:1:1::/64 {
    IF (ISP_A_uplink is up)
        THEN
            preferred_lifetime = 604800
        ELSE
            preferred_lifetime = 0
}

prefix 2001:db8:2:1::/64 {
    IF (ISP_A_Uplink is up)
        THEN
            preferred_lifetime = 0
        ELSE
            preferred_lifetime = 604800
}

and a similar policy needs to be applied to the RDNSS lifetime if the ISP_A and ISP_B DNS servers are used 🫶💅

okay so bestie, let's level up 🔥. This time we've got two border routers, each terminating one ISP uplink, and they're both acting as redundant first-hop routers for the hosts. Peep Figure 2 👀

                                                              --------
                                             ,-------,       /        \
  2001:db8:1:1::/64 +----+ 2001:db8:1::/48 ,'         ',    :          :
                   _|    |----------------+    ISP_A    +--+:          :
                  | | R1 |                 ',         ,'    :          :
                  | +----+                   '-------'      :          :
H1----------------|                                         : INTERNET :
                  | +----+                   ,-------,      :          :
                  |_|    | 2001:db8:2::/48 ,'         ',    :          :
                    | R2 |----------------+    ISP_B    +--+:          :
 2001:db8:2:1::/64  +----+                 ',         ,'    :          :
                                             '-------'       \        /
                                                              --------

               Figure 2: Two Routers, Primary/Backup Uplinks

In this setup, R1 sends RAs with a PIO for 2001:db8:1:1::/64 (ISP_A address space), and R2 sends RAs with a PIO for 2001:db8:2:1::/64 (ISP_B address space). Each router needs a forwarding policy configured for packets received on its hosts-facing interface ✨

IF (packet_source_address is in 2001:db8:1::/48)
    and
    (packet_destination_address is not in
    (2001:db8:1::/48 or 2001:db8:2::/48))
    THEN
        default next hop is ISP_A_uplink

IF (packet_source_address is in 2001:db8:2::/48)
    and
    (packet_destination_address is not in
    (2001:db8:1::/48 or 2001:db8:2::/48))
    THEN
        default next hop is ISP_B_uplink

So there's more than one way to make sure hosts pick the correct source address based on uplink status 💅. If VRRP is used for first-hop redundancy and the master router is the one with the active uplink, the simplest move is to use the VRRP mastership as the condition for RA. So if ISP_A is the primary uplink, R1 and R2 get set up like this:

R1 is the VRRP master by default (when the ISP_A uplink is up). If the ISP_A uplink goes down, R1 becomes a backup. (VRRP interface-status tracking is expected to be used to automatically modify the VRRP priorities and trigger the mastership switchover.) The RA on R1's interface facing H1 needs this policy applied:

prefix 2001:db8:1:1::/64 {
    IF (vrrp_master)
        THEN
            preferred_lifetime = 604800
        ELSE
            preferred_lifetime = 0
}

R2 is VRRP backup by default. The RA on R2's interface facing H1 needs this policy applied:

prefix 2001:db8:2:1::/64 {
    IF(vrrp_master)
        THEN
            preferred_lifetime = 604800
        ELSE
            preferred_lifetime = 0
}

Now, if VRRP isn't used, or interface status tracking isn't used for mastership switchover, then each router needs to be able to detect the uplink failure/recovery on the neighboring router. That's how RAs with updated preferred lifetime values get triggered 🧚 Depending on the network setup, different triggers can work, like a route to the uplink interface subnet or a default route received from the uplink. The obvious drawback of using the routing table to trigger the conditional RAs is that some extra configuration is required. For example, if a route to the prefix assigned to the ISP uplink is used as the trigger, the conditional RA policy looks like this:

R1:

prefix 2001:db8:1:1::/64 {
    IF (ISP_A_uplink is up)
        THEN
            preferred_lifetime = 604800
        ELSE
           preferred_lifetime = 0
}
R2:

prefix 2001:db8:2:1::/64 {
    IF (ISP_A_uplink_route is present)
        THEN
            preferred_lifetime = 0
        ELSE
            preferred_lifetime = 604800
}

Let's check out the example topology from Figure 1, but this time both uplinks are used at the same time 🙌 In this case, R1 would send RAs containing PIOs for both prefixes, 2001:db8:1:1::/64 and 2001:db8:2:1::/64, and it changes the preferred lifetime based on which uplink is available. If interface status is used as the uplink availability indicator, the policy logic looks like this:

prefix 2001:db8:1:1::/64 {
    IF (ISP_A_uplink is up)
        THEN
            preferred_lifetime  = 604800
        ELSE
            preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
    IF (ISP_B_uplink is up)
        THEN
            preferred_lifetime  = 604800
        ELSE
            preferred_lifetime = 0
}

R1 needs a forwarding policy to send packets out the correct uplink based on the source address, similar to the policy described in Section 3.2.1.

In this scenario, the example topology is similar to the one in Figure 2, but both uplinks can be used at the same time. That means R1 and R2 both need the matching forwarding policy so packets get forwarded based on their source addresses 🫶

Each router sends RAs with a PIO for its corresponding prefix. It sets preferred_lifetime to a nonzero value when its ISP uplink is up, and deprecates the prefix by setting preferred_lifetime to 0 when the uplink fails. Uplink recovery triggers another RA with a nonzero preferred lifetime, which makes the addresses from that prefix preferred again. The example RA policy on R1 and R2 looks like this:

R1:
prefix 2001:db8:1:1::/64 {
    IF (ISP_A_uplink is up)
        THEN
            preferred_lifetime  = 604800
        ELSE
            preferred_lifetime = 0
}

R2:

prefix 2001:db8:2:1::/64 {
    IF (ISP_B_uplink is up)
        THEN
            preferred_lifetime  = 604800
        ELSE
            preferred_lifetime = 0
}

3.2.5. Topologies with Dedicated Border Routers 🍓

For simplicity, every topology above shows the ISP uplinks terminated on the first-hop routers. Obviously the approach can be used in more complex topologies where dedicated devices terminate the ISP uplinks. In that case, VRRP mastership or interface status can't be used as a trigger for conditional RAs. Route presence, as described in Section 3.2.2, should be used instead.

Let's look at the example topology in Figure 3:

                            2001:db8:1::/48              --------
2001:db8:1:1::/64                     ,-------,        ,'        ',
          +----+  +---+  +----+     ,'         ',     :            :
         _|    |--|   |--| R3 |----+    ISP_A    +---+:            :
        | | R1 |  |   |  +----+     ',         ,'     :            :
        | +----+  |   |               '-------'       :            :
H1--------|         |LAN|                               :  INTERNET  :
        | +----+  |   |               ,-------,       :            :
        |_|    |  |   |  +----+     ,'         ',     :            :
          | R2 |--|   |--| R4 |----+    ISP_B    +---+:            :
          +----+  +---+  +----+     ',         ,'     :            :
2001:db8:2:1::/64                       '-------'        ',        ,'
                            2001:db8:2::/48              --------

                Figure 3: Dedicated Border Routers

For example, if ISP_A is the primary uplink and ISP_B is the backup, the following policy might be used to get the desired behavior. H1 uses ISP_A address space, 2001:db8:1:1::/64, while the ISP_A uplink is up, and only uses the ISP_B 2001:db8:2:1::/64 prefix if that uplink is non-operational:

R1 and R2 policy:

prefix 2001:db8:1:1::/64 {
    IF (ISP_A_uplink_route is present)
        THEN
            preferred_lifetime = 604800
        ELSE
            preferred_lifetime = 0
}

prefix 2001:db8:2:1::/64 {
    IF (ISP_A_uplink_route is present)
        THEN
            preferred_lifetime = 0
        ELSE
            preferred_lifetime = 604800
}

For the load-balancing case, the policy looks a bit different: each prefix only has a nonzero preferred_lifetime if its matching ISP uplink route is present 🎀

prefix 2001:db8:1:1::/64 {
    IF (ISP_A_uplink_route is present)
        THEN
            preferred_lifetime = 604800
        ELSE
            preferred_lifetime = 0
}

prefix 2001:db8:2:1::/64 {
    IF (ISP_B_uplink_route is present)
        THEN
            preferred_lifetime = 604800
        ELSE
            preferred_lifetime = 0
}

Okay, this one's a little scary ngl. Prefix deprecation from an uplink status change can lead to a situation where all global prefixes are deprecated, meaning every ISP uplink is non-operational for some reason 💀 Even when there's no Internet connectivity, it might still be desirable to have intrasite IPv6 connectivity, especially when the network is an IPv6-only one. However, while an address is in a deprecated state, its use is discouraged, but not strictly forbidden [RFC4862]. In that scenario, all IPv6 source addresses in the candidate set [RFC6724] are deprecated. That means they can still be used, since there are no preferred addresses available, and the source address selection algorithm can pick one of them, allowing intrasite communication. Some operating systems might just fall back to IPv4 if the network interface has no preferred IPv6 global addresses, though 🙈 So if intrasite connectivity is vital during simultaneous outages of multiple uplinks, administrators might consider using Unique Local Addresses (ULAs) [RFC4193] or provisioning additional backup uplinks to protect the network from double-failure cases.

If an actively used uplink (a primary one, or one used in a load-balancing scenario) starts flapping, it can cause the undesirable situation of flapping addresses on hosts. Every time the uplink goes up, hosts receive an RA with a nonzero preferred PIO lifetime, and every time it goes down, all addresses in the affected prefix become deprecated. This would, undoubtedly, hurt the user experience 😩, not to mention the spikes of duplicate address detection traffic every time an uplink comes back up. Therefore, it's recommended that router vendors implement some form of damping policy for conditional RAs. They can either postpone sending an RA with a nonzero lifetime for a PIO when the uplink comes up for a number of seconds, or (even) introduce accumulated penalties/exponential backoff algorithm for such delays. (In the case of multiple simultaneous uplink failure, when all but one of the uplinks are down and the last remaining one is flapping, it might result in all addresses being deprecated for a while after the flapping uplink recovers.) 💜

okay so setting a preferred lifetime to 0 to deprecate an IPv6 address is more of a strong suggestion than a hard ban 💅 Deprecated addresses can still be used for existing connections [RFC4862], which means they're not totally banned from new stuff either, just discouraged 🙈 So when an ISP uplink goes down, the border router might still get packets with source addresses from that ISP's space, even though there's no working uplink to send them out on 💀

What the router does with those packets depends on how uplink selection works. If some form of SADR is in use, those packets get dropped because there's no route to the destination 🚫 If policy-based routing sets a next hop instead, the behavior is implementation dependent, so it can be anything from dropping the packets to forwarding them based on the routing table entries 🤷‍♀️ Also, there's no return path back to the packet source, since the ISP uplink isn't operational 😭 So even if the outgoing packets get sent out through another ISP, the return traffic might never make it back to you 💔

3.3. Solution Limitations 🧩

not gonna lie, this approach is NOT a "silver bullet" for every multihoming situation ✨ It works really well for networks with relatively simple topologies and straightforward routing policies 💖 The more complicated the topology and routing policies get, the more configuration you'll need to make it work 🍓

Another limitation is load-balancing between uplinks 🙃 When both uplinks are active, hosts pick their source prefix with the Default Address Selection algorithm [RFC6724], so the load between the two uplinks most likely won't be split evenly 📉 (BUT, the mechanism does allow a creative trick for controlling uplink load in software-defined networks 🧚 A controller can selectively deprecate prefixes on some hosts but not others, which moves egress traffic between uplinks 👑) Also, prefix selection doesn't consider any other properties of the uplinks, like latency, so egress traffic might not go out the nearest uplink just because its prefix got picked as the source 🌍 In general, if not all uplinks are equal and some are supposed to be preferred over others, the network administrator should make sure prefixes from the non-preferred ISP(s) stay deprecated, so you end up with a primary/backup setup 🎀

3.3.1. Connections Preservation 🔌

The proposed solution is not designed to preserve connection state after an uplink failure 😭 If all uplinks to an ISP go down, every session to or from addresses in that ISP's space gets interrupted, because there's no egress path for those packets and no return path from the Internet to that prefix 💔 It's kinda like IPv4 multihoming with NAT, where an uplink failure and failover means a public IPv4 address changes and all existing connections get cut 🥲

BUT, an uplink recovery doesn't necessarily interrupt connections 🦋 In the load-sharing/balancing scenario, an uplink recovery doesn't affect any existing connections at all ✨ In the active/backup topology, when the primary uplink recovers and the backup prefix is deprecated, existing sessions (the ones established to or from the backup ISP addresses) can be preserved, as long as the routers are configured as described in Section 3.2.1 and keep sending packets with the backup ISP source addresses out the backup uplink, even while the primary one is up 🫶 So after the primary recovers, the backup ISP addresses are discouraged but still usable, which is iconic behavior 👑

It should be noted that in IPv4 multihoming with NAT, when the egress interface is picked without looking at the packet's source address (since internal hosts usually have addresses from [RFC1918] space), sessions might not survive an uplink recovery unless packet forwarding is integrated with the existing NAT session tracking 🙈

4. IANA Considerations 🌸

This document has no IANA actions. ✨

5. Security Considerations 🔐

This memo introduces no new security considerations, but it does rely on RAs [RFC4861] and the SLAAC [RFC4862] mechanism, so it inherits their security properties 🫣 If an attacker is able to send a rogue RA, they could deprecate IPv6 addresses on hosts or influence the source-address-selection processes on hosts 😱 Yikes!!

The potential attack vectors include, but are not limited to:

  • An attacker sends a rogue RA deprecating IPv6 addresses on hosts; 🚨
  • An attacker sends a rogue RA making addresses preferred while the corresponding ISP uplink is not operational; 🚨
  • An attacker sends a rogue RA making addresses preferred for a backup ISP, steering traffic to an undesirable (e.g., more expensive) uplink. 💸🚨

Therefore, the network administrators SHOULD secure RAs, e.g., by deploying an RA guard [RFC6105]. 🛡️💖

5.1. Privacy Considerations 🫧

This memo introduces no new privacy considerations. 💜

6. References 📚

6.1. Normative References

6.2. Informative References

Acknowledgements 💐

Thanks to the following people (in alphabetical order) for their review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, and Dave Thaler. 🫶🌈

Authors' Addresses 💌

Jen Linkova
Google
Mountain View, California  94043
United States of America

Email: furry@google.com
Massimiliano Stucchi
RIPE NCC
Stationsplein, 11
Amsterdam  1012 AB
The Netherlands

Email: mstucchi@ripe.net
📦 where this page comes from