diff options
Diffstat (limited to 'doc/rfc/rfc8475.txt')
| -rw-r--r-- | doc/rfc/rfc8475.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8475.txt b/doc/rfc/rfc8475.txt new file mode 100644 index 0000000..c1707ed --- /dev/null +++ b/doc/rfc/rfc8475.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Linkova +Request for Comments: 8475 Google +Category: Informational M. Stucchi +ISSN: 2070-1721 RIPE NCC + October 2018 + + + Using Conditional Router Advertisements for Enterprise Multihoming + +Abstract + + This document discusses the most common scenarios of connecting an + enterprise network to multiple ISPs using an address space assigned + by an ISP and how the approach proposed in "Enterprise Multihoming + using Provider-Assigned Addresses without Network Prefix Translation: + Requirements and Solution" could be applied in those scenarios. The + problem of enterprise multihoming without address translation of any + form has not been solved yet as it requires both the network to + select the correct egress ISP based on the packet source address and + hosts to select the correct source address based on the desired + egress ISP for that traffic. The aforementioned document proposes a + solution to this problem by introducing a new routing functionality + (Source Address Dependent Routing) to solve the uplink selection + issue. It also proposes using Router Advertisements to influence the + host source address selection. It focuses on solving the general + problem and covering various complex use cases, and this document + adopts its proposed approach to provide a solution for a limited + number of common use cases. In particular, the focus of this + document is on scenarios in which an enterprise network has two + Internet uplinks used either in primary/backup mode or simultaneously + and hosts in that network might not yet properly support multihoming + as described in RFC 8028. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8475. + + + +Linkova & Stucchi Informational [Page 1] + +RFC 8475 Conditional RAs October 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 + + + + +Linkova & Stucchi Informational [Page 2] + +RFC 8475 Conditional RAs October 2018 + + +1. Introduction + + Multihoming is an obvious requirement for many enterprise networks to + ensure the desired level of network reliability. However, using more + than one ISP (and address space assigned by those ISPs) introduces + the problem of assigning IP addresses to hosts. In IPv4, there is no + choice but using address space [RFC1918] and NAT [RFC3022] at the + network edge [RFC4116]. Using Provider Independent (PI) address + space is not always an option, since it requires running BGP between + the enterprise network and the ISPs. The administrative overhead of + obtaining and managing PI address space can also be a concern. As + IPv6 hosts can, by design, have multiple addresses of the global + scope [RFC4291], multihoming using provider addresses looks even + easier for IPv6: each ISP assigns an IPv6 block (usually /48), and + hosts in the enterprise network have addresses assigned from each ISP + block. However, using IPv6 provider-assigned (PA) blocks in a + multihoming scenario introduces some challenges, including, but not + limited to: + + o Selecting the correct uplink based on the packet source address; + + o Signaling to hosts that some source addresses should or should not + be used (e.g., an uplink to the ISP went down or became available + again). + + [PROVIDER-ASSIGNED] discusses these and other related challenges in + detail in relation to the general multihoming scenario for enterprise + networks. It proposes a solution that relies heavily 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 + and, therefore, is very useful in multihomed scenarios when different + routers may advertise different prefixes. While [RFC6724] defines + Rule 5.5 as optional, the recent [RFC8028] recommends that multihomed + hosts SHOULD support it. Unfortunately, that rule has not been + widely implemented at the time of writing. Therefore, network + administrators in enterprise networks can't yet assume that all + devices in their network support Rule 5.5, especially in the quite + common BYOD ("Bring Your Own Device") scenario. However, while it + does not seem feasible to solve all the possible multihoming + scenarios without relying on Rule 5.5, it is possible to provide IPv6 + multihoming using PA address space for the most common use cases. + This document discusses how the general approach described in + [PROVIDER-ASSIGNED] can be applied to solve multihoming scenarios + when: + + o An enterprise network has two or more ISP uplinks; + + + + + +Linkova & Stucchi Informational [Page 3] + +RFC 8475 Conditional RAs October 2018 + + + o Those uplinks are used for Internet access in active/backup or + load-sharing mode without any sophisticated traffic engineering + requirements; + + o Each ISP assigns the network a subnet from its own PA address + space; and + + o Hosts in the enterprise network are not expected to support Rule + 5.5 of the default address selection algorithm [RFC6724]. + +1.1. Requirements Language + + 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 + +2.1. Two ISP Uplinks, Primary and Backup + + This scenario has the following key characteristics: + + o The enterprise network uses uplinks to two (or more) ISPs for + Internet access; + + o Each ISP assigns IPv6 PA address space for the network; + + o Uplink(s) to one ISP is a primary (preferred) one. All other + uplinks are backup and are not expected to be used while the + primary one is operational; + + o If the primary uplink is operational, all Internet traffic should + flow via that uplink; + + o When the primary uplink fails, the Internet traffic needs to flow + via the backup uplinks; + + o Recovery of the primary uplink needs to trigger the traffic + switchover from the backup uplinks back to the primary one; + + o Hosts in the enterprise network are not expected to support Rule + 5.5 of the default address selection algorithm [RFC6724]. + + + + + + + +Linkova & Stucchi Informational [Page 4] + +RFC 8475 Conditional RAs October 2018 + + +2.2. Two ISP Uplinks, Used for Load-Balancing + + This scenario has the following key characteristics: + + o The enterprise network is using uplinks to two (or more) ISPs for + Internet access; + + o Each ISP assigns an IPv6 PA address space; + + o All the uplinks may be used simultaneously, with the traffic flows + being randomly (not necessarily equally) distributed between them; + + o Hosts in the enterprise network are not expected to support Rule + 5.5 of the default address selection algorithm [RFC6724]. + +3. Conditional Router Advertisements + +3.1. Solution Overview + +3.1.1. Uplink Selection + + As discussed in [PROVIDER-ASSIGNED], one of the two main problems to + be solved in the enterprise multihoming scenario is the problem of + the next-hop (uplink) selection based on the packet source address. + For example, if the enterprise network 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, respectively), then packets sourced from subnet_A + must be sent to the ISP_A uplink while packets sourced from subnet_B + must be sent to the ISP_B uplink. Sending packets with source + addresses belonging to one ISP address space to another ISP might + cause those packets to be filtered out if those ISPs or their uplinks + implement antispoofing ingress filtering [RFC2827][RFC3704]. + + While some work is being done in the Source Address Dependent Routing + (SADR) (such as [DESTINATION]), the simplest way to implement the + desired functionality currently is to apply a policy that selects a + next hop or an egress interface based on the packet source address. + Currently, most SMB/Enterprise-grade routers have such functionality + available. + +3.1.2. Source Address Selection and Conditional RAs + + Another problem to be solved in the multihoming scenario is the + source address selection on hosts. In the normal situation (all + uplinks are up/operational), hosts have multiple global unique + addresses and can rely on the default address selection algorithm + [RFC6724] to pick up a source address, while the network is + responsible for choosing the correct uplink based on the source + + + +Linkova & Stucchi Informational [Page 5] + +RFC 8475 Conditional RAs October 2018 + + + address selected by a host, as described in Section 3.1.1. However, + some network topology changes (i.e., changing uplink status) might + affect the global reachability for packets sourced from particular + prefixes; therefore, such changes have to be signaled back to the + hosts. For example: + + o An uplink to ISP_A went down. Hosts should not use addresses from + an ISP_A prefix; + + o 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] provides a detailed explanation of why Stateless + Address Autoconfiguration (SLAAC) [RFC4862] and Router Advertisements + (RAs) [RFC4861] are the most suitable mechanisms for signaling + network topology changes to hosts, thereby influencing the source + address selection. Sending an RA to change the preferred lifetime + for a given prefix provides the following functionality: + + o 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; + + o 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 should be noted that only the preferred lifetime for the affected + prefix needs to be changed. As the goal is to influence the source + address selection algorithm on hosts rather than prevent them from + forming addresses from a specific prefix, the valid lifetime should + not be changed. Actually, changing the valid lifetime would not even + be possible for unauthenticated RAs (which is the most common + deployment scenario), because Section 5.5.3 of [RFC4862] prevents + hosts from setting the valid lifetime for addresses to zero unless + RAs are authenticated. + + To provide the desired functionality, first-hop routers are required + to: + + o Send RAs triggered by defined event policies in response to an + uplink status change event; and + + + + + + +Linkova & Stucchi Informational [Page 6] + +RFC 8475 Conditional RAs October 2018 + + + o 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 the "uplink status" depends on the network + topology and may include conditions like: + + o Uplink interface status change; + + o Presence of a particular route in the routing table; + + o Presence of a particular route with a particular attribute (next + hop, tag, etc.) in the routing table; + + o Protocol adjacency change. + + In some scenarios, when two routers are providing first-hop + redundancy via Virtual Router Redundancy Protocol (VRRP) [RFC5798], + the master-backup status can be considered to be a condition for + sending RAs and changing the preferred lifetime value. See + Section 3.2.2 for more details. + + If hosts are provided with 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 is not only forcing the router to send an unsolicited RA + to propagate the topology changes to all hosts. Obviously, the + values of the RA fields (like PIO Preferred Lifetime or DNS Server + Lifetime) changed by the particular trigger need to stay the same + until another event causes the value 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. + + It should be noted that the proposed solution is quite similar to the + existing requirement L-13 for IPv6 Customer Edge Routers [RFC7084] + and the documented behavior of homenet devices [RFC7788]. It is + using the same mechanism of deprecating a prefix when the + corresponding uplink is not operational, applying it to an + enterprise-network scenario. + + + + + + + +Linkova & Stucchi Informational [Page 7] + +RFC 8475 Conditional RAs October 2018 + + +3.2. Example Scenarios + + This section illustrates how the conditional RAs solution can be + applied to the most common enterprise multihoming scenarios, + described in Section 2. + +3.2.1. Single Router, Primary/Backup Uplinks + + -------- + ,-------, / \ + +----+ 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 + + Let's look at a simple network topology where a single router acts as + a border router to terminate two ISP uplinks and as a first-hop + router for hosts. Each ISP assigns a /48 to the network, and the + ISP_A uplink is a primary one, to be used for all Internet traffic, + while the ISP_B uplink is a backup, to be used only when the primary + uplink is not operational. + + To ensure that packets with source addresses from ISP_A and ISP_B are + only routed to 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 + + + + + + + + + + +Linkova & Stucchi Informational [Page 8] + +RFC 8475 Conditional RAs October 2018 + + + 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 is desirable that all traffic be sent + via the ISP_A uplink; therefore, 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 to have 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 + } + + A similar policy needs to be applied to the RDNSS lifetime if ISP_A + and ISP_B DNS servers are used. + +3.2.2. Two Routers, Primary/Backup Uplinks + + Let's look at a more complex scenario where two border routers are + terminating two ISP uplinks (one each), acting as redundant first-hop + routers for hosts. The topology is shown in Figure 2. + + + + + + + + + + + +Linkova & Stucchi Informational [Page 9] + +RFC 8475 Conditional RAs October 2018 + + + -------- + ,-------, / \ + 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 scenario, R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A + address space), and R2 sends RAs with PIO for 2001:db8:2:1::/64 + (ISP_B address space). Each router needs to have 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 + + In this case, there is more than one way to ensure that hosts are + selecting the correct source address based on the uplink status. If + VRRP is used to provide first-hop redundancy, and the master router + is the one with the active uplink, then the simplest way is to use + the VRRP mastership as a condition for RA. So, if ISP_A is the + primary uplink, the routers R1 and R2 need to be configured in the + following way: + + R1 is the VRRP master by default (when the ISP_A uplink is up). If + the ISP_A uplink is down, then R1 becomes a backup (the VRRP + interface-status tracking is expected to be used to automatically + + + + + +Linkova & Stucchi Informational [Page 10] + +RFC 8475 Conditional RAs October 2018 + + + modify the VRRP priorities and trigger the mastership switchover). + RAs on R1's interface facing H1 needs to have the following 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. RA on R2's interface facing H1 needs + to have the following policy applied: + + prefix 2001:db8:2:1::/64 { + IF(vrrp_master) + THEN + preferred_lifetime = 604800 + ELSE + preferred_lifetime = 0 + } + + If VRRP is not used or interface status tracking is not used for + mastership switchover, then each router needs to be able to detect + the uplink failure/recovery on the neighboring router, so that RAs + with updated preferred lifetime values are triggered. Depending on + the network setup, various triggers can be used, such as 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 additional configuration is + required. For example, if a route to the prefix assigned to the ISP + uplink is used as a trigger, then the conditional RA policy would + have the following logic: + + R1: + + prefix 2001:db8:1:1::/64 { + IF (ISP_A_uplink is up) + THEN + preferred_lifetime = 604800 + ELSE + preferred_lifetime = 0 + } + + + + + + + +Linkova & Stucchi Informational [Page 11] + +RFC 8475 Conditional RAs October 2018 + + + R2: + + prefix 2001:db8:2:1::/64 { + IF (ISP_A_uplink_route is present) + THEN + preferred_lifetime = 0 + ELSE + preferred_lifetime = 604800 + } + +3.2.3. Single Router, Load-Balancing between Uplinks + + Let's look at the example topology shown in Figure 1, but with both + uplinks used simultaneously. In this case, R1 would send RAs + containing PIOs for both prefixes, 2001:db8:1:1::/64 and + 2001:db8:2:1::/64, changing the preferred lifetime based on + particular uplink availability. If the interface status is used as + an uplink availability indicator, then the policy logic would look + like the following: + + 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 be applied to forward packets to the + correct uplink based on the source address, similar to the policy + described in Section 3.2.1. + +3.2.4. Two Routers, Load-Balancing between Uplinks + + In this scenario, the example topology is similar to the one shown in + Figure 2, but both uplinks can be used at the same time. This means + that both R1 and R2 need to have the corresponding forwarding policy + to forward packets based on their source addresses. + + + + + + +Linkova & Stucchi Informational [Page 12] + +RFC 8475 Conditional RAs October 2018 + + + Each router would send RAs with PIO for the corresponding prefix, + setting preferred_lifetime to a nonzero value when the ISP uplink is + up and deprecating the prefix by setting preferred_lifetime to 0 in + the case of uplink failure. The uplink recovery would trigger + another RA with a nonzero preferred lifetime to make the addresses + from the prefix preferred again. The example RA policy on R1 and R2 + would look like: + + 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, all topologies above show the ISP uplinks terminated + on the first-hop routers. Obviously, the proposed approach can be + used in more complex topologies when dedicated devices are used for + terminating ISP uplinks. In that case, VRRP mastership or interface + status cannot be used as a trigger for conditional RAs. Route + presence as described in Section 3.2.2 should be used instead. + + + + + + + + + + + + + + + + +Linkova & Stucchi Informational [Page 13] + +RFC 8475 Conditional RAs October 2018 + + + Let's look at the example topology shown 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 a primary uplink and ISP_B is a backup, then + the following policy might be used to achieve the desired behavior + (H1 is using ISP_A address space, 2001:db8:1:1::/64, while the ISP_A + uplink is up and only using the ISP_B 2001:db8:2:1::/64 prefix if the + 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 + } + + + + + + + + + + +Linkova & Stucchi Informational [Page 14] + +RFC 8475 Conditional RAs October 2018 + + + For the load-balancing case, the policy would look slightly + different: each prefix has a nonzero preferred_lifetime only if the + corresponding 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 + } + +3.2.6. Intrasite Communication during Simultaneous Uplinks Outage + + Prefix deprecation as a result of an uplink status change might lead + to a situation in which all global prefixes are deprecated (all ISP + uplinks are not operational for some reason). Even when there is no + Internet connectivity, it might be still desirable to have intrasite + IPv6 connectivity (especially when the network in question is an + IPv6-only one). However, while an address is in a deprecated state, + its use is discouraged, but not strictly forbidden [RFC4862]. In + such a scenario, all IPv6 source addresses in the candidate set + [RFC6724] are deprecated, which means that they still can be used (as + there are no preferred addresses available), and the source address + selection algorithm can pick up one of them, allowing intrasite + communication. However, some operating systems might just fall back + to IPv4 if the network interface has no preferred IPv6 global + addresses. Therefore, 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. + +3.2.7. Uplink Damping + + If an actively used uplink (a primary one or one used in a load- + balancing scenario) starts flapping, it might lead to 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 the uplink goes down, all addresses in the affected prefix + + + +Linkova & Stucchi Informational [Page 15] + +RFC 8475 Conditional RAs October 2018 + + + become deprecated. This would, undoubtedly, negatively impact the + user experience, not to mention the impact of 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 and 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.) + +3.2.8. Routing Packets When the Corresponding Uplink Is Unavailable + + Deprecating IPv6 addresses by setting the preferred lifetime to 0 + discourages but does not strictly forbid its usage in new + communications. A deprecated address may still be used for existing + connections [RFC4862]. Therefore, when an ISP uplink goes down, the + corresponding border router might still receive packets with source + addresses belonging to that ISP address space while there is no + available uplink to send those packets to. + + The expected router behavior would depend on the uplink selection + mechanism. For example, if some form of SADR is used, then such + packets will be dropped as there is no route to the destination. If + policy-based routing is used to set a next hop, then the behavior + would be implementation dependent and may vary from dropping the + packets to forwarding them based on the routing table entries. It + should be noted that there is no return path to the packet source (as + the ISP uplink is not operational). Therefore, even if the outgoing + packets are sent to another ISP, the return traffic might not be + delivered. + +3.3. Solution Limitations + + It should be noted that the proposed approach is not a "silver + bullet" for all possible multihoming scenarios. It would work very + well for networks with relatively simple topologies and + straightforward routing policies. The more complex the network + topology and the corresponding routing policies, the more + configuration would be required to implement the solution. + + Another limitation is related to the load-balancing between the + uplinks. In the scenario in which both uplinks are active, hosts + would select the source prefix using the Default Address Selection + algorithm [RFC6724]; therefore, the load between two uplinks most + likely would not be evenly distributed. (However, the proposed + + + +Linkova & Stucchi Informational [Page 16] + +RFC 8475 Conditional RAs October 2018 + + + mechanism does allow a creative way of controlling uplinks load in + software-defined networks where controllers might selectively + deprecate prefixes on some hosts but not others to move egress + traffic between uplinks). Also, the prefix selection does not take + into account any other properties of uplinks (such as latency), so + egress traffic might not be sent to the nearest uplink if the + corresponding prefix is selected as a source. In general, if not all + uplinks are equal, and some uplinks are expected to be preferred over + others, then the network administrator should ensure that prefixes + from non-preferred ISP(s) are kept deprecated (so primary/backup + setup is used). + +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, all + sessions to/from addresses from that ISP address space are + interrupted as there is no egress path for those packets and there is + no return path from the Internet to the corresponding prefix. In + this regard, it is similar to IPv4 multihoming using NAT, where an + uplink failure and failover to another uplink means that a public + IPv4 address changes and all existing connections are interrupted. + + However, an uplink recovery does not necessarily lead to connections + interruption. In the load-sharing/balancing scenario, an uplink + recovery does not affect any existing connections at all. In the + active/backup topology, when the primary uplink recovers from the + failure and the backup prefix is deprecated, the existing sessions + (established to/from the backup ISP addresses) can be preserved if + the routers are configured as described in Section 3.2.1 and send + packets with the backup ISP source addresses to the backup uplink, + even when the primary one is operational. As a result, the primary + uplink recovery makes the usage of the backup ISP addresses + discouraged but still possible. + + It should be noted that in IPv4 multihoming with NAT, when the egress + interface is chosen without taking packet source address into account + (as internal hosts usually have addresses from [RFC1918] space), + sessions might not be preserved after an uplink recovery unless + packet forwarding is integrated with existing NAT sessions tracking. + +4. IANA Considerations + + This document has no IANA actions. + + + + + + + +Linkova & Stucchi Informational [Page 17] + +RFC 8475 Conditional RAs October 2018 + + +5. Security Considerations + + This memo introduces no new security considerations. It relies on + RAs [RFC4861] and the SLAAC [RFC4862] mechanism and inherits their + security properties. If an attacker is able to send a rogue RA, they + could deprecate IPv6 addresses on hosts or influence source-address- + selection processes on hosts. + + The potential attack vectors include, but are not limited to: + + o An attacker sends a rogue RA deprecating IPv6 addresses on hosts; + + o An attacker sends a rogue RA making addresses preferred while the + corresponding ISP uplink is not operational; + + o 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 + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + <https://www.rfc-editor.org/info/rfc1918>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, + May 2000, <https://www.rfc-editor.org/info/rfc2827>. + + + + + + + +Linkova & Stucchi Informational [Page 18] + +RFC 8475 Conditional RAs October 2018 + + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + DOI 10.17487/RFC3022, January 2001, + <https://www.rfc-editor.org/info/rfc3022>. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March + 2004, <https://www.rfc-editor.org/info/rfc3704>. + + [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. + Gill, "IPv4 Multihoming Practices and Limitations", + RFC 4116, DOI 10.17487/RFC4116, July 2005, + <https://www.rfc-editor.org/info/rfc4116>. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, + <https://www.rfc-editor.org/info/rfc4193>. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, <https://www.rfc-editor.org/info/rfc4291>. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + <https://www.rfc-editor.org/info/rfc4862>. + + [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. + Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, + DOI 10.17487/RFC6105, February 2011, + <https://www.rfc-editor.org/info/rfc6105>. + + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, + "Default Address Selection for Internet Protocol Version 6 + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + <https://www.rfc-editor.org/info/rfc6724>. + + [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by + Hosts in a Multi-Prefix Network", RFC 8028, + DOI 10.17487/RFC8028, November 2016, + <https://www.rfc-editor.org/info/rfc8028>. + + [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, + "IPv6 Router Advertisement Options for DNS Configuration", + RFC 8106, DOI 10.17487/RFC8106, March 2017, + <https://www.rfc-editor.org/info/rfc8106>. + + + + + +Linkova & Stucchi Informational [Page 19] + +RFC 8475 Conditional RAs October 2018 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +6.2. Informative References + + [DESTINATION] + Lamparter, D. and A. Smirnov, "Destination/Source + Routing", Work in Progress, + draft-ietf-rtgwg-dst-src-routing-06, October 2017. + + [PROVIDER-ASSIGNED] + Baker, F., Bowers, C., and J. Linkova, "Enterprise + Multihoming using Provider-Assigned Addresses without + Network Prefix Translation: Requirements and Solution", + Work in Progress, + draft-ietf-rtgwg-enterprise-pa-multihoming-07, June 2018. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + <https://www.rfc-editor.org/info/rfc4861>. + + [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) + Version 3 for IPv4 and IPv6", RFC 5798, + DOI 10.17487/RFC5798, March 2010, + <https://www.rfc-editor.org/info/rfc5798>. + + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + DOI 10.17487/RFC7084, November 2013, + <https://www.rfc-editor.org/info/rfc7084>. + + [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking + Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April + 2016, <https://www.rfc-editor.org/info/rfc7788>. + +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. + + + + + + + + +Linkova & Stucchi Informational [Page 20] + +RFC 8475 Conditional RAs October 2018 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Linkova & Stucchi Informational [Page 21] + |