draft-ietf-v6ops-conditional-ras-08.txt   rfc8475.txt 
IPv6 Operations J. Linkova Internet Engineering Task Force (IETF) J. Linkova
Internet-Draft Google Request for Comments: 8475 Google
Intended status: Informational M. Stucchi Category: Informational M. Stucchi
Expires: February 22, 2019 RIPE NCC ISSN: 2070-1721 RIPE NCC
August 21, 2018 October 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-08
Abstract Abstract
This document discusses the most common scenarios of connecting an This document discusses the most common scenarios of connecting an
enterprise network to multiple ISPs using an address space assigned enterprise network to multiple ISPs using an address space assigned
by an ISP and how the approach proposed in the "ietf-rtgwg- by an ISP and how the approach proposed in "Enterprise Multihoming
enterprise-pa-multihoming" draft could be applied in those scenarios. using Provider-Assigned Addresses without Network Prefix Translation:
The problem of enterprise multihoming without address translation of Requirements and Solution" could be applied in those scenarios. The
any form has not been solved yet as it requires both the network to 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 select the correct egress ISP based on the packet source address and
hosts to select the correct source address based on the desired hosts to select the correct source address based on the desired
egress ISP for that traffic. The "ietf-rtgwg-enterprise-pa- egress ISP for that traffic. The aforementioned document proposes a
multihoming" document proposes a solution to this problem by solution to this problem by introducing a new routing functionality
introducing a new routing functionality (Source Address Dependent (Source Address Dependent Routing) to solve the uplink selection
Routing) to solve the uplink selection issue and using Router issue. It also proposes using Router Advertisements to influence the
Advertisements to influence the host source address selection. While host source address selection. It focuses on solving the general
the above-mentioned document focuses on solving the general problem problem and covering various complex use cases, and this document
and on covering various complex use cases, this document adopts the adopts its proposed approach to provide a solution for a limited
approach proposed in the "ietf-rtgwg-enterprise-pa-multihoming" draft number of common use cases. In particular, the focus of this
to provide a solution for a limited number of common use cases. In document is on scenarios in which an enterprise network has two
particular, the focus is on scenarios where an enterprise network has Internet uplinks used either in primary/backup mode or simultaneously
two Internet uplinks used either in primary/backup mode or and hosts in that network might not yet properly support multihoming
simultaneously and hosts in that network might not yet properly as described in RFC 8028.
support multihoming as described in RFC8028.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. 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.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc8475.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4 2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4
2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4
2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 5 2.2. Two ISP Uplinks, Used for Load-Balancing . . . . . . . . 5
3. Conditional Router Advertisements . . . . . . . . . . . . . . 5 3. Conditional Router Advertisements . . . . . . . . . . . . . . 5
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5
3.1.2. Source Address Selection and Conditional RAs . . . . 5 3.1.2. Source Address Selection and Conditional RAs . . . . 5
3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8
3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9
3.2.3. Single Router, Load Balancing Between Uplinks . . . . 12 3.2.3. Single Router, Load-Balancing between Uplinks . . . . 12
3.2.4. Two 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.5. Topologies with Dedicated Border Routers . . . . . . 13
3.2.6. Intra-Site Communication during Simultaneous Uplinks 3.2.6. Intrasite Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 15 Outage . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Routing Packets when the Corresponding Uplink is 3.2.8. Routing Packets When the Corresponding Uplink Is
Unavailable . . . . . . . . . . . . . . . . . . . . . 16 Unavailable . . . . . . . . . . . . . . . . . . . . . 16
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16
3.3.1. Connections Preservation . . . . . . . . . . . . . . 17 3.3.1. Connections Preservation . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Multihoming is an obvious requirement for many enterprise networks to Multihoming is an obvious requirement for many enterprise networks to
ensure the desired level of network reliability. However, using more ensure the desired level of network reliability. However, using more
than one ISP (and address space assigned by those ISPs) introduces than one ISP (and address space assigned by those ISPs) introduces
the problem of assigning IP addresses to hosts. In IPv4 there is no the problem of assigning IP addresses to hosts. In IPv4, there is no
choice but using [RFC1918] address space and NAT ([RFC3022]) at the choice but using address space [RFC1918] and NAT [RFC3022] at the
network edge ([RFC4116]). Using Provider Independent (PI) address network edge [RFC4116]. Using Provider Independent (PI) address
space is not always an option, since it requires running BGP between space is not always an option, since it requires running BGP between
the enterprise network and the ISPs. Administrative overhead of the enterprise network and the ISPs. The administrative overhead of
obtaining and managing PI address space can also be a concern. As obtaining and managing PI address space can also be a concern. As
IPv6 hosts can, by design, have multiple addresses of the global IPv6 hosts can, by design, have multiple addresses of the global
scope ([RFC4291]), multihoming using provider address looks even scope [RFC4291], multihoming using provider addresses looks even
easier for IPv6: each ISP assigns an IPv6 block (usually /48) and easier for IPv6: each ISP assigns an IPv6 block (usually /48), and
hosts in the enterprise network have addresses assigned from each ISP hosts in the enterprise network have addresses assigned from each ISP
block. However using IPv6 PA blocks in multihoming scenario block. However, using IPv6 provider-assigned (PA) blocks in a
introduces some challenges, including but not limited to: multihoming scenario introduces some challenges, including, but not
limited to:
o Selecting the correct uplink based on the packet source address; o Selecting the correct uplink based on the packet source address;
o Signaling to hosts that some source addresses should or should not 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 be used (e.g., an uplink to the ISP went down or became available
again). again).
The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses [PROVIDER-ASSIGNED] discusses these and other related challenges in
these and other related challenges in detail in relation to the detail in relation to the general multihoming scenario for enterprise
general multihoming scenario for enterprise networks and proposes a networks. It proposes a solution that relies heavily on Rule 5.5 of
solution which relies heavily on the rule 5.5 of the default address the default address selection algorithm [RFC6724]. Rule 5.5 makes
selection algorithm ([RFC6724]). The rule 5.5 makes hosts prefer hosts prefer source addresses in a prefix advertised by the next hop
source addresses in a prefix advertised by the next-hop and therefore and, therefore, is very useful in multihomed scenarios when different
is very useful in multihomed scenarios when different routers may routers may advertise different prefixes. While [RFC6724] defines
advertise different prefixes. While [RFC6724] defines the Rule 5.5 Rule 5.5 as optional, the recent [RFC8028] recommends that multihomed
as optional, the recent [RFC8028] recommends that multihomed hosts hosts SHOULD support it. Unfortunately, that rule has not been
SHOULD support it. Unfortunately that rule has not been widely widely implemented at the time of writing. Therefore, network
implemented when this document was written. Therefore network
administrators in enterprise networks can't yet assume that all administrators in enterprise networks can't yet assume that all
devices in their network support the rule 5.5, especially in the devices in their network support Rule 5.5, especially in the quite
quite common BYOD ("Bring Your Own Device") scenario. However, while common BYOD ("Bring Your Own Device") scenario. However, while it
it does not seem feasible to solve all the possible multihoming does not seem feasible to solve all the possible multihoming
scenarios without relying on rule 5.5, it is possible to provide IPv6 scenarios without relying on Rule 5.5, it is possible to provide IPv6
multihoming using provider-assigned (PA) address space for the most multihoming using PA address space for the most common use cases.
common use cases. This document discusses how the general approach This document discusses how the general approach described in
described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be [PROVIDER-ASSIGNED] can be applied to solve multihoming scenarios
applied to solve multihoming scenarios when: when:
o An enterprise network has two or more ISP uplinks; o An enterprise network has two or more ISP uplinks;
o Those uplinks are used for Internet access in active/backup or o Those uplinks are used for Internet access in active/backup or
load sharing mode w/o any sophisticated traffic engineering load-sharing mode without any sophisticated traffic engineering
requirements; requirements;
o Each ISP assigns the network a subnet from its own PA address o Each ISP assigns the network a subnet from its own PA address
space space; and
o Hosts in the enterprise network are not expected to support the o Hosts in the enterprise network are not expected to support Rule
Rule 5.5 of the default address selection algorithm ([RFC6724]). 5.5 of the default address selection algorithm [RFC6724].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14 [RFC2119] "OPTIONAL" in this document are to be interpreted as described in
[RFC8174] when, and only when, they appear in all capitals, as shown BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
here. capitals, as shown here.
2. Common Enterprise Multihoming Scenarios 2. Common Enterprise Multihoming Scenarios
2.1. Two ISP Uplinks, Primary and Backup 2.1. Two ISP Uplinks, Primary and Backup
This scenario has the following key characteristics: This scenario has the following key characteristics:
o The enterprise network is using uplinks to two (or more) ISPs for o The enterprise network uses uplinks to two (or more) ISPs for
Internet access; Internet access;
o Each ISP assigns IPv6 PA address space for the network; o Each ISP assigns IPv6 PA address space for the network;
o Uplink(s) to one ISP is a primary (preferred) one. All other 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 uplinks are backup and are not expected to be used while the
primary one is operational; primary one is operational;
o If the primary uplink is operational, all Internet traffic should o If the primary uplink is operational, all Internet traffic should
flow via that uplink; flow via that uplink;
o When the primary uplink fails the Internet traffic needs to flow o When the primary uplink fails, the Internet traffic needs to flow
via the backup uplinks; via the backup uplinks;
o Recovery of the primary uplink needs to trigger the traffic o Recovery of the primary uplink needs to trigger the traffic
switchover from the backup uplinks back to primary one; switchover from the backup uplinks back to the primary one;
o Hosts in the enterprise network are not expected to support the o Hosts in the enterprise network are not expected to support Rule
Rule 5.5 of the default address selection algorithm ([RFC6724]). 5.5 of the default address selection algorithm [RFC6724].
2.2. Two ISP Uplinks, Used for Load Balancing 2.2. Two ISP Uplinks, Used for Load-Balancing
This scenario has the following key characteristics: This scenario has the following key characteristics:
o The enterprise network is using uplinks to two (or more) ISPs for o The enterprise network is using uplinks to two (or more) ISPs for
Internet access; Internet access;
o Each ISP assigns an IPv6 PA address space; o Each ISP assigns an IPv6 PA address space;
o All the uplinks may be used simultaneously, with the traffic flows o All the uplinks may be used simultaneously, with the traffic flows
being randomly (not necessarily equally) distributed between them; being randomly (not necessarily equally) distributed between them;
o Hosts in the enterprise network are not expected to support the o Hosts in the enterprise network are not expected to support Rule
Rule 5.5 of the default address selection algorithm ([RFC6724]). 5.5 of the default address selection algorithm [RFC6724].
3. Conditional Router Advertisements 3. Conditional Router Advertisements
3.1. Solution Overview 3.1. Solution Overview
3.1.1. Uplink Selection 3.1.1. Uplink Selection
As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of As discussed in [PROVIDER-ASSIGNED], one of the two main problems to
the two main problems to be solved in the enterprise multihoming be solved in the enterprise multihoming scenario is the problem of
scenario is the problem of the next-hop (uplink) selection based on the next-hop (uplink) selection based on the packet source address.
the packet source address. For example, if the enterprise network For example, if the enterprise network has two uplinks, to ISP_A and
has two uplinks, to ISP_A and ISP_B, and hosts have addresses from ISP_B, and hosts have addresses from subnet_A and subnet_B (belonging
subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) to ISP_A and ISP_B, respectively), then packets sourced from subnet_A
then packets sourced from subnet_A must be sent to ISP_A uplink while must be sent to the ISP_A uplink while packets sourced from subnet_B
packets sourced from subnet_B must be sent to ISP_B uplink. Sending must be sent to the ISP_B uplink. Sending packets with source
packets with source addresses belonging to one ISP address space to addresses belonging to one ISP address space to another ISP might
another ISP might cause those packets to be filtered out if those cause those packets to be filtered out if those ISPs or their uplinks
ISPs or their uplinks implement anti-spoofing ingress filtering implement antispoofing ingress filtering [RFC2827][RFC3704].
([RFC2827], [RFC3704]).
While some work is being done in the Source Address Dependent Routing While some work is being done in the Source Address Dependent Routing
(SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest way (SADR) (such as [DESTINATION]), the simplest way to implement the
to implement the desired functionality currently is to apply a policy desired functionality currently is to apply a policy that selects a
which selects a next-hop or an egress interface based on the packet next hop or an egress interface based on the packet source address.
source address. Most SMB/Enterprise grade routers have such Currently, most SMB/Enterprise-grade routers have such functionality
functionality available currently. available.
3.1.2. Source Address Selection and Conditional RAs 3.1.2. Source Address Selection and Conditional RAs
Another problem to be solved in the multihoming scenario is the Another problem to be solved in the multihoming scenario is the
source address selection on hosts. In the normal situation (all source address selection on hosts. In the normal situation (all
uplinks are up/operational) hosts have multiple global unique uplinks are up/operational), hosts have multiple global unique
addresses and can rely on the default address selection algorithm addresses and can rely on the default address selection algorithm
([RFC6724]) to pick up a source address, while the network is [RFC6724] to pick up a source address, while the network is
responsible for choosing the correct uplink based on the source responsible for choosing the correct uplink based on the source
address selected by a host as described in Section 3.1.1. However, address selected by a host, as described in Section 3.1.1. However,
some network topology changes (i.e. changing uplink status) might some network topology changes (i.e., changing uplink status) might
affect the global reachability for packets sourced from the affect the global reachability for packets sourced from particular
particular prefixes and therefore such changes have to be signaled prefixes; therefore, such changes have to be signaled back to the
back to the hosts. For example: hosts. For example:
o An uplink to an ISP_A went down. Hosts should not use addresses o An uplink to ISP_A went down. Hosts should not use addresses from
from ISP_A prefix; an ISP_A prefix;
o A primary uplink to ISP_A which was not operational has come back o A primary uplink to ISP_A that was not operational has come back
up. Hosts should start using the source addresses from ISP_A up. Hosts should start using the source addresses from an ISP_A
prefix. prefix.
[I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed [PROVIDER-ASSIGNED] provides a detailed explanation of why Stateless
explanation on why SLAAC (Stateless Address Autoconfiguration, Address Autoconfiguration (SLAAC) [RFC4862] and Router Advertisements
[RFC4862]) and RAs (Router Advertisements, [RFC4861]) are the most (RAs) [RFC4861] are the most suitable mechanisms for signaling
suitable mechanism for signaling network topology changes to hosts network topology changes to hosts, thereby influencing the source
and thereby influencing the source address selection. Sending a address selection. Sending an RA to change the preferred lifetime
router advertisement to change the preferred lifetime for a given for a given prefix provides the following functionality:
prefix provides the following functionality:
o deprecating addresses (by sending an RA with the o Deprecating addresses by sending an RA with preferred_lifetime set
preferred_lifetime set to 0 in the corresponding PIO (Prefix to 0 in the corresponding Prefix Information option (PIO)
Information option, [RFC4861])) to indicate to hosts that that [RFC4861]. This indicates to hosts that addresses from that
addresses from that prefix should not be used; prefix should not be used;
o making a previously unused (deprecated) prefix usable again (by o Making a previously unused (deprecated) prefix usable again by
sending an RA containing a PIO with non-zero preferred lifetime) sending an RA containing a PIO with nonzero preferred lifetime.
to indicate to hosts that addresses from that prefix can be used This indicates to hosts that addresses from that prefix can be
again. used again.
It should be notes that only preferred lifetime for the affected 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 prefix needs to be changed. As the goal is to influence the source
address selection algoorithm on hosts, not preventing them from address selection algorithm on hosts rather than prevent them from
forming addresses from a specific prefix, the valid lifetime should forming addresses from a specific prefix, the valid lifetime should
not be changed. Actually it would not even be possible for not be changed. Actually, changing the valid lifetime would not even
unauthenticated RAs (which is the most common deployment scenario) as be possible for unauthenticated RAs (which is the most common
Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime deployment scenario), because Section 5.5.3 of [RFC4862] prevents
for addresses to zero unless RAs are authenticated. 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 provide the desired functionality, first-hop routers are required
to to:
o send RA triggered by defined event policies in response to uplink o Send RAs triggered by defined event policies in response to an
status change event; and uplink status change event; and
o while sending periodic or solicted RAs, set the value in the given o While sending periodic or solicited RAs, set the value in the
RA field (e.g. PIO preferred lifetime) based on the uplink given RA field (e.g., PIO preferred lifetime) based on the uplink
status. status.
The exact definition of the 'uplink status' depends on the network The exact definition of the "uplink status" depends on the network
topology and may include conditions like: topology and may include conditions like:
o uplink interface status change; 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- o Presence of a particular route in the routing table;
hop, tag etc) in the routing table;
o protocol adjacency change. o Presence of a particular route with a particular attribute (next
hop, tag, etc.) in the routing table;
etc. o Protocol adjacency change.
In some scenarios, when two routers are providing first-hop In some scenarios, when two routers are providing first-hop
redundancy via VRRP (Virtual Router Redundancy Protocol, [RFC5798]), redundancy via Virtual Router Redundancy Protocol (VRRP) [RFC5798],
the master-backup status can be considered as a condition for sending the master-backup status can be considered to be a condition for
RAs and changing the preferred lifetime value. See Section 3.2.2 for sending RAs and changing the preferred lifetime value. See
more details. Section 3.2.2 for more details.
If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS If hosts are provided with the IPv6 addresses of ISP DNS servers via
(Router Advertisement Options for DNS Configuration, [RFC8106]) it a Recursive DNS Server (RDNSS) (see "IPv6 Router Advertisement
might be desirable for the conditional RAs to update the Lifetime Options for DNS Configuration" [RFC8106]), it might be desirable for
field of the RDNSS option as well. 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 The trigger is not only forcing the router to send an unsolicited RA
to propagate the topology changes to all hosts. Obviously the RA to propagate the topology changes to all hosts. Obviously, the
fields values (like PIO Preferred Lifetime or DNS Server Lifetime) values of the RA fields (like PIO Preferred Lifetime or DNS Server
changed by the particular trigger need to stay the same until another Lifetime) changed by the particular trigger need to stay the same
event happens causing the value to be updated. E.g. if the ISP_A until another event causes the value to be updated. For example, if
uplink failure causes the prefix to be deprecated, all solicited and an ISP_A uplink failure causes the prefix to be deprecated, all
unsolicited RAs sent by the router need to have the Preferred solicited and unsolicited RAs sent by the router need to have the
Lifetime for that PIO set to 0 until the uplink comes back up. 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 It should be noted that the proposed solution is quite similar to the
existing requirement L-13 for IPv6 Customer Edge Routers ([RFC7084]) existing requirement L-13 for IPv6 Customer Edge Routers [RFC7084]
and the documented behavior of homenet devices ([RFC7788]). It is and the documented behavior of homenet devices [RFC7788]. It is
using the same mechanism of deprecating a prefix when the using the same mechanism of deprecating a prefix when the
corresponding uplink is not operational, applying it to enterprise corresponding uplink is not operational, applying it to an
network scenario. enterprise-network scenario.
3.2. Example Scenarios 3.2. Example Scenarios
This section illustrates how the conditional RAs solution can be This section illustrates how the conditional RAs solution can be
applied to most common enterprise multihoming scenarios, described in applied to the most common enterprise multihoming scenarios,
Section 2. described in Section 2.
3.2.1. Single Router, Primary/Backup Uplinks 3.2.1. Single Router, Primary/Backup Uplinks
-------- --------
,-------, ,' ', ,-------, / \
+----+ 2001:db8:1::/48 ,' ', : : +----+ 2001:db8:1::/48 ,' ', : :
| |------------------+ ISP_A +--+: : | |-----------------+ ISP_A +--+: :
2001:db8:1:1::/64 | | ', ,' : : 2001:db8:1:1::/64 | | ', ,' : :
| | '-------' : : | | '-------' : :
H1------------------| R1 | : INTERNET : H1-----------------| R1 | : INTERNET :
| | ,-------, : : | | ,-------, : :
2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : :
| |------------------+ ISP_B +--+: : | |-----------------+ ISP_B +--+: :
+----+ ', ,' : : +----+ ', ,' : :
'-------' ', ,' '-------' \ /
-------- --------
Figure 1: Single Router, Primary/Backup Uplinks Figure 1: Single Router, Primary/Backup Uplinks
Let's look at a simple network topology where a single router acts as 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 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 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, 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 while the ISP_B uplink is a backup, to be used only when the primary
uplink is not operational. uplink is not operational.
To ensure that packets with source addresses from ISP_A and ISP_B are 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 only routed to ISP_A and ISP_B uplinks, respectively, the network
administrator needs to configure a policy on R1: administrator needs to configure a policy on R1:
IF (packet_source_address is in 2001:db8:1::/48) IF (packet_source_address is in 2001:db8:1::/48)
and and
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) (packet_destination_address is not in
THEN (2001:db8:1::/48 or 2001:db8:2::/48))
default next-hop is ISP_A_uplink THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48) IF (packet_source_address is in 2001:db8:2::/48)
and and
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) (packet_destination_address is not in
THEN (2001:db8:1::/48 or 2001:db8:2::/48))
default next-hop is ISP_B_uplink THEN
default next hop is ISP_B_uplink
Under normal circumstances it is desirable that all traffic be sent Under normal circumstances, it is desirable that all traffic be sent
via the ISP_A uplink, therefore hosts (the host H1 in the example via the ISP_A uplink; therefore, hosts (the host H1 in the example
topology figure) should be using source addresses from topology figure) should be using source addresses from
2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 2001:db8:1:1::/64. When or if the ISP_A uplink fails, hosts should
using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 stop using the 2001:db8:1:1::/64 prefix and start using
until the ISP_A uplink comes back up. To achieve this the router 2001:db8:2:1::/64 until the ISP_A uplink comes back up. To achieve
advertisement configuration on the R1 device for the interface facing this, the RA configuration on the R1 device for the interface facing
H1 needs to have the following policy: H1 needs to have the following policy:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up) IF (ISP_A_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_A_Uplink is up) IF (ISP_A_Uplink is up)
THEN THEN
preferred_lifetime = 0 preferred_lifetime = 0
ELSE ELSE
preferred_lifetime = 604800 preferred_lifetime = 604800
} }
A similar policy needs to be applied to the RDNSS Lifetime if ISP_A A similar policy needs to be applied to the RDNSS lifetime if ISP_A
and ISP_B DNS servers are used. and ISP_B DNS servers are used.
3.2.2. Two Routers, Primary/Backup Uplinks 3.2.2. Two Routers, Primary/Backup Uplinks
Let's look at a more complex scenario where two border routers are Let's look at a more complex scenario where two border routers are
terminating two ISP uplinks (one each), acting as redundant first-hop terminating two ISP uplinks (one each), acting as redundant first-hop
routers for hosts. The topology is shown on Fig.2 routers for hosts. The topology is shown in Figure 2.
--------
,-------, ,' ', --------
+----+ 2001:db8:1::/48 ,' ', : : ,-------, / \
2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 2001:db8:1:1::/64 +----+ 2001:db8:1::/48 ,' ', : :
| | R1 | ', ,' : : _| |----------------+ ISP_A +--+: :
| +----+ '-------' : : | | R1 | ', ,' : :
H1------------------| : INTERNET : | +----+ '-------' : :
| +----+ ,-------, : : H1----------------| : INTERNET :
|_| | 2001:db8:2::/48 ,' ', : : | +----+ ,-------, : :
2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : |_| | 2001:db8:2::/48 ,' ', : :
+----+ ', ,' : : | R2 |----------------+ ISP_B +--+: :
'-------' ', ,' 2001:db8:2:1::/64 +----+ ', ,' : :
-------- '-------' \ /
--------
Figure 2: Two Routers, Primary/Backup Uplinks Figure 2: Two Routers, Primary/Backup Uplinks
In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 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), and R2 sends RAs with PIO for 2001:db8:2:1::/64
address space). Each router needs to have a forwarding policy (ISP_B address space). Each router needs to have a forwarding policy
configured for packets received on its hosts-facing interface: configured for packets received on its hosts-facing interface:
IF (packet_source_address is in 2001:db8:1::/48) IF (packet_source_address is in 2001:db8:1::/48)
and and
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) (packet_destination_address is not in
THEN (2001:db8:1::/48 or 2001:db8:2::/48))
default next-hop is ISP_A_uplink THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48) IF (packet_source_address is in 2001:db8:2::/48)
i and and
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) (packet_destination_address is not in
THEN (2001:db8:1::/48 or 2001:db8:2::/48))
default next-hop is ISP_B_uplink THEN
default next hop is ISP_B_uplink
In this case there is more than one way to ensure that hosts are 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 selecting the correct source address based on the uplink status. If
VRRP is used to provide first-hop redundancy and the master router is VRRP is used to provide first-hop redundancy, and the master router
the one with the active uplink, then the simplest way is to use the is the one with the active uplink, then the simplest way is to use
VRRP mastership as a condition for router advertisement. So, if the VRRP mastership as a condition for RA. So, if ISP_A is the
ISP_A is the primary uplink, the routers R1 and R2 need to be primary uplink, the routers R1 and R2 need to be configured in the
configured in the following way: following way:
R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A R1 is the VRRP master by default (when the ISP_A uplink is up). If
uplink is down, then R1 becomes a backup (the VRRP interface status the ISP_A uplink is down, then R1 becomes a backup (the VRRP
tracking is expected to be used to automatically modify the VRRP interface-status tracking is expected to be used to automatically
priorities and trigger the mastership switchover). Router modify the VRRP priorities and trigger the mastership switchover).
advertisements on R1's interface facing H1 needs to have the RAs on R1's interface facing H1 needs to have the following policy
following policy applied: applied:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (vrrp_master) IF (vrrp_master)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
R2 is VRRP backup by default. Router advertsement on R2 interface R2 is VRRP backup by default. RA on R2's interface facing H1 needs
facing H1 needs to have the following policy applied: to have the following policy applied:
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF(vrrp_master) IF(vrrp_master)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
If VRRP is not used or interface status tracking is not used for If VRRP is not used or interface status tracking is not used for
mastership switchover, then each router needs to be able to detect mastership switchover, then each router needs to be able to detect
the uplink failure/recovery on the neighboring router, so that RAs the uplink failure/recovery on the neighboring router, so that RAs
with updated preferred lifetime values are triggered. Depending on with updated preferred lifetime values are triggered. Depending on
the network setup various triggers like a route to the uplink the network setup, various triggers can be used, such as a route to
interface subnet or a default route received from the uplink can be the uplink interface subnet or a default route received from the
used. The obvious drawback of using the routing table to trigger the uplink. The obvious drawback of using the routing table to trigger
conditional RAs is that some additional configuration is required. the conditional RAs is that some additional configuration is
For example, if a route to the prefix assigned to the ISP uplink is required. For example, if a route to the prefix assigned to the ISP
used as a trigger, then the conditional RA policy would have the uplink is used as a trigger, then the conditional RA policy would
following logic: have the following logic:
R1: R1:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up) IF (ISP_A_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
R2: R2:
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present) IF (ISP_A_uplink_route is present)
THEN THEN
preferred_lifetime = 0 preferred_lifetime = 0
ELSE ELSE
preferred_lifetime = 604800 preferred_lifetime = 604800
} }
3.2.3. Single Router, Load Balancing Between Uplinks 3.2.3. Single Router, Load-Balancing between Uplinks
Let's look at the example topology shown in Figure 1, but with both Let's look at the example topology shown in Figure 1, but with both
uplinks used simultaneously. In this case R1 would send RAs uplinks used simultaneously. In this case, R1 would send RAs
containing PIOs for both prefixes, 2001:db8:1:1::/64 and containing PIOs for both prefixes, 2001:db8:1:1::/64 and
2001:db8:2:1::/64, changing the preferred lifetime based on 2001:db8:2:1::/64, changing the preferred lifetime based on
particular uplink availability. If the interface status is used as particular uplink availability. If the interface status is used as
uplink availability indicator, then the policy logic would look like an uplink availability indicator, then the policy logic would look
the following: like the following:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up) IF (ISP_A_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up) IF (ISP_B_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
R1 needs a forwarding policy to be applied to forward packets to the R1 needs a forwarding policy to be applied to forward packets to the
correct uplink based on the source address similar to one described correct uplink based on the source address, similar to the policy
in Section 3.2.1. described in Section 3.2.1.
3.2.4. Two Router, Load Balancing Between Uplinks 3.2.4. Two Routers, Load-Balancing between Uplinks
In this scenario the example topology is similar to the one shown in 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. It means 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 that both R1 and R2 need to have the corresponding forwarding policy
to forward packets based on their source addresses. to forward packets based on their source addresses.
Each router would send RAs with PIO for the corresponding prefix. Each router would send RAs with PIO for the corresponding prefix,
setting preferred_lifetime to a non-zero value when the ISP uplink is setting preferred_lifetime to a nonzero value when the ISP uplink is
up, and deprecating the prefix by setting the preferred lifetime to 0 up and deprecating the prefix by setting preferred_lifetime to 0 in
in case of uplink failure. The uplink recovery would trigger another the case of uplink failure. The uplink recovery would trigger
RA with non-zero preferred lifetime to make the addresses from the another RA with a nonzero preferred lifetime to make the addresses
prefix preferred again. The example RA policy on R1 and R2 would from the prefix preferred again. The example RA policy on R1 and R2
look like: would look like:
R1: R1:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up) IF (ISP_A_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
R2: R2:
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up) IF (ISP_B_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
3.2.5. Topologies with Dedicated Border Routers 3.2.5. Topologies with Dedicated Border Routers
For simplicity, all topologies above show the ISP uplinks terminated For simplicity, all topologies above show the ISP uplinks terminated
on the first-hop routers. Obviously, the proposed approach can be on the first-hop routers. Obviously, the proposed approach can be
used in more complex topologies when dedicated devices are used for used in more complex topologies when dedicated devices are used for
terminating ISP uplinks. In that case VRRP mastership or interface terminating ISP uplinks. In that case, VRRP mastership or interface
status can not be used as a trigger for conditional RAs and route status cannot be used as a trigger for conditional RAs. Route
presence as described above (Section 3.2.2) should be used instead. presence as described in Section 3.2.2 should be used instead.
Let's look at the example topology shown on the Figure 3: Let's look at the example topology shown in Figure 3:
2001:db8:1::/48 -------- 2001:db8:1::/48 --------
2001:db8:1:1::/64 ,-------, ,' ', 2001:db8:1:1::/64 ,-------, ,' ',
+----+ +---+ +----+ ,' ', : : +----+ +---+ +----+ ,' ', : :
_| |--| |--| R3 |----+ ISP_A +---+: : _| |--| |--| R3 |----+ ISP_A +---+: :
| | R1 | | | +----+ ', ,' : : | | R1 | | | +----+ ', ,' : :
| +----+ | | '-------' : : | +----+ | | '-------' : :
H1--------| |LAN| : INTERNET : H1--------| |LAN| : INTERNET :
| +----+ | | ,-------, : : | +----+ | | ,-------, : :
|_| | | | +----+ ,' ', : : |_| | | | +----+ ,' ', : :
| R2 |--| |--| R4 |----+ ISP_B +---+: : | R2 |--| |--| R4 |----+ ISP_B +---+: :
+----+ +---+ +----+ ', ,' : : +----+ +---+ +----+ ', ,' : :
2001:db8:2:1::/64 '-------' ', ,' 2001:db8:2:1::/64 '-------' ', ,'
2001:db8:2::/48 -------- 2001:db8:2::/48 --------
Figure 3: Dedicated Border Routers Figure 3: Dedicated Border Routers
For example, if ISP_A is a primary uplink and ISP_B is a backup one For example, if ISP_A is a primary uplink and ISP_B is a backup, then
then the following policy might be used to achieve the desired the following policy might be used to achieve the desired behavior
behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while (H1 is using ISP_A address space, 2001:db8:1:1::/64, while the ISP_A
ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if uplink is up and only using the ISP_B 2001:db8:2:1::/64 prefix if the
the uplink is non-operational): uplink is non-operational):
R1 and R2 policy: R1 and R2 policy:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present) IF (ISP_A_uplink_route is present)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present) IF (ISP_A_uplink_route is present)
THEN THEN
preferred_lifetime = 0 preferred_lifetime = 0
ELSE ELSE
preferred_lifetime = 604800 preferred_lifetime = 604800
} }
For the load-balancing case, the policy would look slightly
For the load-balancing case the policy would look slightly different: different: each prefix has a nonzero preferred_lifetime only if the
each prefix has non-zero preferred_lifetime only if the correspoding corresponding ISP uplink route is present:
ISP uplink route is present:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present) IF (ISP_A_uplink_route is present)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink_route is present) IF (ISP_B_uplink_route is present)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 3.2.6. Intrasite Communication during Simultaneous Uplinks Outage
Prefix deprecation as a result of an uplink status change might lead Prefix deprecation as a result of an uplink status change might lead
to a situation when all global prefixes are deprecated (all ISP to a situation in which all global prefixes are deprecated (all ISP
uplinks are not operational for some reason). Even when there is no uplinks are not operational for some reason). Even when there is no
Internet connectivity it might be still desirable to have intra-site Internet connectivity, it might be still desirable to have intrasite
IPv6 connectivity (especially when the network in question is an IPv6 connectivity (especially when the network in question is an
IPv6-only one). However while an address is in a deprecated state, IPv6-only one). However, while an address is in a deprecated state,
its use is discouraged, but not strictly forbidden ([RFC4862]). In its use is discouraged, but not strictly forbidden [RFC4862]. In
such a scenario all IPv6 source addresses in the candidate set such a scenario, all IPv6 source addresses in the candidate set
([RFC6724]) are deprecated, which means that they still can be used [RFC6724] are deprecated, which means that they still can be used (as
(as there are no preferred addresses available) and the source there are no preferred addresses available), and the source address
address selection algorithm can pick up one of them, allowing the selection algorithm can pick up one of them, allowing intrasite
intra-site communication. However some OSes might just fall back to communication. However, some operating systems might just fall back
IPv4 if the network interface has no preferred IPv6 global addresses. to IPv4 if the network interface has no preferred IPv6 global
Therefore if intra-site connectivity is vital during simultanious addresses. Therefore, if intrasite connectivity is vital during
outages of multiple uplinks, administrators might consider using ULAs simultaneous outages of multiple uplinks, administrators might
(Unique Local Addresses, [RFC4193]) or provisioning additional backup consider using Unique Local Addresses (ULAs) [RFC4193] or
uplinks to protect the network from double-failure cases. provisioning additional backup uplinks to protect the network from
double-failure cases.
3.2.7. Uplink Damping 3.2.7. Uplink Damping
If an actively used uplink (primary one or one used in load balaning If an actively used uplink (a primary one or one used in a load-
scenario) starts flapping, it might lead to the undesirable situation balancing scenario) starts flapping, it might lead to the undesirable
of flapping addresses on hosts (every time the uplink goes up hosts situation of flapping addresses on hosts: every time the uplink goes
receive an RA with non-zero preferred PIO lifetime, and every time up, hosts receive an RA with a nonzero preferred PIO lifetime, and
the uplink goes down all addresses in the affected prefix become every time the uplink goes down, all addresses in the affected prefix
deprecated). This would, undoubtedly, negatively impact the user become deprecated. This would, undoubtedly, negatively impact the
experience, not to mention the impact of spikes of duplicate address user experience, not to mention the impact of spikes of duplicate
detection traffic every time an uplink comes back up. Therefore it's address detection traffic every time an uplink comes back up.
recommended that router vendors implement some form of damping policy Therefore, it's recommended that router vendors implement some form
for conditional RAs and either postpone sending an RA with non-zero of damping policy for conditional RAs and either postpone sending an
lifetime for a PIO when the uplink comes up for a number of seconds RA with a nonzero lifetime for a PIO when the uplink comes up for a
or even introduce accumulated penalties/exponential backoff algorithm number of seconds or (even) introduce accumulated penalties/
for such delays. (In the case of a multiple simultaneous uplink exponential backoff algorithm for such delays. (In the case of
failure scenario, when all but one uplinks are down and the last multiple simultaneous uplink failure, when all but one of the uplinks
remaining is flapping it might result in all addresses being are down and the last remaining one is flapping, it might result in
deprecated for a while after the flapping uplink recovers.) all addresses being deprecated for a while after the flapping uplink
recovers.)
3.2.8. Routing Packets when the Corresponding Uplink is Unavailable 3.2.8. Routing Packets When the Corresponding Uplink Is Unavailable
Deprecating IPv6 addresses by setting the preferred lifetime to 0 Deprecating IPv6 addresses by setting the preferred lifetime to 0
discourage but not strictly forbid its usage in new communications. discourages but does not strictly forbid its usage in new
A deprecated address may still be used for existing connections communications. A deprecated address may still be used for existing
([RFC4862]). Therefore when an ISP uplink goes down the connections [RFC4862]. Therefore, when an ISP uplink goes down, the
corresponding border router might still receive packets with source corresponding border router might still receive packets with source
addresses belonging to that ISP address space while there is no addresses belonging to that ISP address space while there is no
available uplink to send those packets to. available uplink to send those packets to.
The expected router behaviour would depend on the uplink selection The expected router behavior would depend on the uplink selection
mechanism. For example if some form of SADR is used then such 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 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 behaviour policy-based routing is used to set a next hop, then the behavior
would be implementation-dependend and may vary from dropping the would be implementation dependent and may vary from dropping the
packets to forwarding them based on the routing table entries. It 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 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 the ISP uplink is not operational). Therefore, even if the outgoing
packets are sent to another ISP the return traffic might not be packets are sent to another ISP, the return traffic might not be
delivered. delivered.
3.3. Solution Limitations 3.3. Solution Limitations
It should be noted that the proposed approach is not a "silver It should be noted that the proposed approach is not a "silver
bullet" for all possible multihoming scenarios. It would work very bullet" for all possible multihoming scenarios. It would work very
well for networks with relatively simple topologies and well for networks with relatively simple topologies and
straightforward routing policies. The more complex the network straightforward routing policies. The more complex the network
topology and the corresponding routing policies, the more topology and the corresponding routing policies, the more
configuration would be required to implement the solution. configuration would be required to implement the solution.
Another limitation is related to the load balancing between the Another limitation is related to the load-balancing between the
uplinks. In the scenario in which both uplinks are active, hosts uplinks. In the scenario in which both uplinks are active, hosts
would select the source prefix using the Default Address Selection would select the source prefix using the Default Address Selection
algorithm ([RFC6724]), and therefore the load between two uplinks algorithm [RFC6724]; therefore, the load between two uplinks most
most likely would not be evenly distributed. (However, the proposed likely would not be evenly distributed. (However, the proposed
mechanism does allow a creative way of controlling uplinks load in mechanism does allow a creative way of controlling uplinks load in
software defined networks where controllers might selectively software-defined networks where controllers might selectively
deprecate prefixes on some hosts but not others to move egress deprecate prefixes on some hosts but not others to move egress
traffic between uplinks). Also the prefix selection does not take traffic between uplinks). Also, the prefix selection does not take
into account any other uplinks properties (such as latency etc), so into account any other properties of uplinks (such as latency), so
egress traffic might not be sent to the nearest uplink if the egress traffic might not be sent to the nearest uplink if the
corresponding prefix is selected as a source. In general, if not all corresponding prefix is selected as a source. In general, if not all
uplinks are equal and some uplinks are expected to be preferred over uplinks are equal, and some uplinks are expected to be preferred over
others, then the network administrator should ensure that prefixes others, then the network administrator should ensure that prefixes
from non-preferred ISP(s) are kept deprecated (so primary/backup from non-preferred ISP(s) are kept deprecated (so primary/backup
setup is used). setup is used).
3.3.1. Connections Preservation 3.3.1. Connections Preservation
The proposed solution is not designed to preserve connection state The proposed solution is not designed to preserve connection state
after an uplink failure. If all uplinks to an ISP go down, all after an uplink failure. If all uplinks to an ISP go down, all
sessions to/from addresses from that ISP address space are sessions to/from addresses from that ISP address space are
interrupted as there is no egress path for those packets and there is interrupted as there is no egress path for those packets and there is
no return path from the Internet to the corresponding prefix. In no return path from the Internet to the corresponding prefix. In
this regard it is similar to IPv4 multihoming using NAT, where an this regard, it is similar to IPv4 multihoming using NAT, where an
uplink failure and failover to another uplink means that a public uplink failure and failover to another uplink means that a public
IPv4 address changes and all existing connections are interrupted. IPv4 address changes and all existing connections are interrupted.
An uplink recovery, however, does not necessarily lead to connections However, an uplink recovery does not necessarily lead to connections
interruption. In the load sharing/balancing scenario an uplink interruption. In the load-sharing/balancing scenario, an uplink
recovery does not affect any existing connections at all. In the recovery does not affect any existing connections at all. In the
active/backup topology when the primary uplink recovers from the active/backup topology, when the primary uplink recovers from the
failure and the backup prefix is deprecated, the existing sessions failure and the backup prefix is deprecated, the existing sessions
(established to/from the backup ISP addresses) can be preserved if (established to/from the backup ISP addresses) can be preserved if
the routers are configured as described in Section 3.2.1 and send the routers are configured as described in Section 3.2.1 and send
packets with the backup ISP source addresses to the backup uplink packets with the backup ISP source addresses to the backup uplink,
even when the primary one is operational. As a result, the primary even when the primary one is operational. As a result, the primary
uplink recovery makes the usage of the backup ISP addresses uplink recovery makes the usage of the backup ISP addresses
discouraged but still possible. discouraged but still possible.
It should be noted that in IPv4 multihoming with NAT, when the egress It should be noted that in IPv4 multihoming with NAT, when the egress
interface is chosen without taking packet source address into account interface is chosen without taking packet source address into account
(as internal hosts usually have addresses from [RFC1918] space), (as internal hosts usually have addresses from [RFC1918] space),
sessions might not be preserved after an uplink recovery unless sessions might not be preserved after an uplink recovery unless
packet forwarding is integrated with existing NAT sessions tracking. packet forwarding is integrated with existing NAT sessions tracking.
4. IANA Considerations 4. IANA Considerations
This memo asks the IANA for no new parameters. This document has no IANA actions.
5. Security Considerations 5. Security Considerations
This memo introduces no new security considerations. It relies on This memo introduces no new security considerations. It relies on
Router Advertisements ([RFC4861]) and SLAAC ([RFC4862] mechanism and RAs [RFC4861] and the SLAAC [RFC4862] mechanism and inherits their
inherits their security properties. If an attacker is able to send a security properties. If an attacker is able to send a rogue RA, they
rogue RA they could deprecate IPv6 addresses on hosts or infuence could deprecate IPv6 addresses on hosts or influence source-address-
source address selection processes on hosts. selection processes on hosts.
The potential attack vectors are including but not limited to: 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 deprecating IPv6 addresses on hosts;
o An attacker sends a rogue RA making addresses preferred while the o An attacker sends a rogue RA making addresses preferred while the
corresponding ISP uplink is not operational; corresponding ISP uplink is not operational;
o An attacker sends a rogue RA making addresses preferred for a o An attacker sends a rogue RA making addresses preferred for a
backup ISP, steering traffic to undesirable (e.g. more expensive) backup ISP, steering traffic to an undesirable (e.g., more
uplink. expensive) uplink.
Therefore the network administrators SHOULD secure Router Therefore, the network administrators SHOULD secure RAs, e.g., by
Advertisements, e.g., by deploying RA guard [RFC6105]. deploying an RA guard [RFC6105].
5.1. Privacy Considerations 5.1. Privacy Considerations
This memo introduces no new privacy considerations. This memo introduces no new privacy considerations.
6. Acknowledgements 6. References
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, Dave
Thaler.
7. References
7.1. Normative References 6.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 5 skipping to change at page 20, line 9
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 6.2. Informative References
[I-D.ietf-rtgwg-dst-src-routing] [DESTINATION]
Lamparter, D. and A. Smirnov, "Destination/Source Lamparter, D. and A. Smirnov, "Destination/Source
Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in Routing", Work in Progress,
progress), October 2017. draft-ietf-rtgwg-dst-src-routing-06, October 2017.
[I-D.ietf-rtgwg-enterprise-pa-multihoming] [PROVIDER-ASSIGNED]
Baker, F., Bowers, C., and J. Linkova, "Enterprise Baker, F., Bowers, C., and J. Linkova, "Enterprise
Multihoming using Provider-Assigned Addresses without Multihoming using Provider-Assigned Addresses without
Network Prefix Translation: Requirements and Solution", Network Prefix Translation: Requirements and Solution",
draft-ietf-rtgwg-enterprise-pa-multihoming-07 (work in Work in Progress,
progress), June 2018. draft-ietf-rtgwg-enterprise-pa-multihoming-07, June 2018.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010, DOI 10.17487/RFC5798, March 2010,
<https://www.rfc-editor.org/info/rfc5798>. <https://www.rfc-editor.org/info/rfc5798>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>. <https://www.rfc-editor.org/info/rfc7084>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>. 2016, <https://www.rfc-editor.org/info/rfc7788>.
Appendix A. Change Log Acknowledgements
Initial Version: July 2017 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 Authors' Addresses
Jen Linkova Jen Linkova
Google Google
Mountain View, California 94043 Mountain View, California 94043
USA United States of America
Email: furry@google.com Email: furry@google.com
Massimiliano Stucchi Massimiliano Stucchi
RIPE NCC RIPE NCC
Stationsplein, 11 Stationsplein, 11
Amsterdam 1012 AB Amsterdam 1012 AB
The Netherlands The Netherlands
Email: mstucchi@ripe.net Email: mstucchi@ripe.net
 End of changes. 138 change blocks. 
432 lines changed or deleted 428 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/