draft-ietf-v6ops-conditional-ras-03.txt   draft-ietf-v6ops-conditional-ras-04.txt 
IPv6 Operations J. Linkova IPv6 Operations J. Linkova
Internet-Draft Google Internet-Draft Google
Intended status: Informational M. Stucchi Intended status: Informational M. Stucchi
Expires: October 1, 2018 RIPE NCC Expires: November 5, 2018 RIPE NCC
March 30, 2018 May 4, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-03 draft-ietf-v6ops-conditional-ras-04
Abstract Abstract
This document discusses 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. The problem of enterprise multihoming without address by an ISP. The problem of enterprise multihoming without address
translation of any form has not been solved yet as it requires both 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 the network to select the correct egress ISP based on the packet
source address and hosts to select the correct source address based source address and hosts to select the correct source address based
on the desired egress ISP for that traffic. on the desired egress ISP for that traffic. The "ietf-rtgwg-
[I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to enterprise-pa-multihoming" document proposes a solution to this
this problem by introducing a new routing functionality (Source problem by introducing a new routing functionality (Source Address
Address Dependent Routing) to solve the uplink selection issue and Dependent Routing) to solve the uplink selection issue and using
using Router Advertisements to influence the host source address Router Advertisements to influence the host source address selection.
selection. While the above-mentioned document focuses on solving the While the above-mentioned document focuses on solving the general
general problem and on covering various complex use cases, this problem and on covering various complex use cases, this document
document describes how the solution proposed in describes how the solution proposed in the "ietf-rtgwg-enterprise-pa-
[I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited multihoming" draft can be adopted for a limited number of common use
number of common use cases. In particular, the focus is on scenarios cases. In particular, the focus is on scenarios where an enterprise
where an enterprise network has two Internet uplinks used either in network has two Internet uplinks used either in primary/backup mode
primary/backup mode or simultaneously and hosts in that network might or simultaneously and hosts in that network might not yet properly
not yet properly support multihoming as described in [RFC8028]. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 1, 2018. This Internet-Draft will expire on November 5, 2018.
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 33 skipping to change at page 2, line 33
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 . . . . . . . . 4 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . 7 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 7 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 7
3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 8 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 8
3.2.3. Single Router, Load Balancing Between Uplinks . . . . 10 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 11
3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 11 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 11
3.2.5. Topologies with Dedicated Border Routers . . . . . . 11 3.2.5. Topologies with Dedicated Border Routers . . . . . . 12
3.2.6. Intra-Site Communication during Simultaneous Uplinks 3.2.6. Intra-Site Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 13 Outage . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 14
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 14 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 15
3.3.1. Connections Preservation . . . . . . . . . . . . . . 14 3.3.1. Connections Preservation . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 15 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 [RFC1918] address space and NAT ([RFC3022]) at the
network edge. Using Provider Independent (PI) address space is not network edge. Using Provider Independent (PI) address space is not
always an option as it requires running BGP between the enterprise always an option, since it requires running BGP between the
network and the ISPs, not mentioning administrative overhead of enterprise network and the ISPs. Administrative overhead of
obtaining and managing PI address space. As IPv6 host can, by obtaining and managing PI address space can also be a concern. As
design, have multiple addresses of the global scope, multihoming IPv6 hosts can, by design, have multiple addresses of the global
using provider address looks even easier for IPv6: each ISP assigns scope, multihoming using provider address looks even easier for IPv6:
an IPv6 block (usually /48) and hosts in the enterprise network have each ISP assigns an IPv6 block (usually /48) and hosts in the
addresses assigned from each ISP block. However using IPv6 PA blocks enterprise network have addresses assigned from each ISP block.
in multihoming scenario introduces some challenges, including but not However using IPv6 PA blocks in multihoming scenario introduces some
limited to: 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 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses
these and other related challenges in details in relation to the these and other related challenges in detail in relation to the
general multihoming scenario for enterprise networks. Unfortunately general multihoming scenario for enterprise networks and proposes
the proposed solution heavily relies on the rule 5.5 of the default solution which relies heavily on the rule 5.5 of the default address
address selection algorithm ([RFC6724]) which has not been widely selection algorithm ([RFC6724]). The rule 5.5 makes hosts prefer
implemented at the moment this document was written. Therefore source addresses in a prefix advertised by the next-hop and therefore
network administrators in enterprise networks can't yet assume that is very useful in multihomed scenarios when different routers may
all devices in their network support the rule 5.5, especially in the advertise different prefixes. Unfortunately that rule has not been
widely implemented when this document was written. Therefore network
administrators in enterprise networks can't yet assume that all
devices in their network support the rule 5.5, especially in the
quite common BYOD ("Bring Your Own Device") scenario. However, while quite common BYOD ("Bring Your Own Device") scenario. However, while
it does not seem feasible to solve all the possible multihoming it does not seem feasible to solve all the possible multihoming
scenarios without reliying on rule 5.5, it is possible to provide scenarios without relying on rule 5.5, it is possible to provide IPv6
IPv6 multihoming using provider-assigned (PA) address space for the multihoming using provider-assigned (PA) address space for the most
most common use cases. This document discusses how the general common use cases. This document discusses how the general solution
solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be
be applied to scenarios when: applied to scenarios 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 soficticated traffic engineering load sharing mode w/o 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
o Hosts in the enterprise network are not expected to support the o Hosts in the enterprise network are not expected to support the
Rule 5.5 of the default address selection algorithm ([RFC6724]). Rule 5.5 of the default address selection algorithm ([RFC6724]).
2. Common Enterprise Multihoming Scenarios 2. Common Enterprise Multihoming Scenarios
skipping to change at page 4, line 45 skipping to change at page 4, line 48
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 nessesary 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 the
Rule 5.5 of the default address selection algorithm ([RFC6724]). Rule 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
skipping to change at page 5, line 23 skipping to change at page 5, line 23
scenario is the problem of the next-hop (uplink) selection based on scenario is the problem of the next-hop (uplink) selection based on
the packet source address. For example, if the enterprise network the packet source address. For example, if the enterprise network
has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 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) subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively)
then packets sourced from subnet_A must be sent to ISP_A uplink while then packets sourced from subnet_A must be sent to ISP_A uplink while
packets sourced from subnet_B must be sent to ISP_B uplink. packets sourced from subnet_B must be sent to ISP_B uplink.
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) area, the simplest way to implement the desired functionality (SADR) area, the simplest way to implement the desired functionality
currently is to apply a policy which selects a next-hop or an egress currently is to apply a policy which selects a next-hop or an egress
interface based on the packet source address. Most of the SMB/ interface based on the packet source address. Most SMB/Enterprise
Enterprise grade routers have such functionality available currently. grade routers have such functionality available currently.
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.2. However, address selected by a host as described in Section 3.1.2. However,
skipping to change at page 6, line 6 skipping to change at page 6, line 6
prefix. prefix.
[I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed
explanation on why SLAAC and router advertisements are the most explanation on why SLAAC and router advertisements are the most
suitable mechanism for signaling network topology changes to hosts suitable mechanism for signaling network topology changes to hosts
and thereby influencing the source address selection. Sending a and thereby influencing the source address selection. Sending a
router advertisement to change the preferred lifetime for a given router advertisement to change the preferred lifetime 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 the
preferred_lifetime set to 0 in the corresponding POI) to indicate preferred_lifetime set to 0 in the corresponding PIO (Prefix
to hosts that that addresses from that prefix should not be used; Information option, [RFC4861]) to indicate to hosts that that
addresses from that 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 POI with non-zero preferred lifetime) sending an RA containing a POI with non-zero preferred lifetime)
to indicate to hosts that addresses from that prefix can be used to indicate to hosts that addresses from that prefix can be used
again. again.
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 RA triggered by defined event policies in response to uplink
skipping to change at page 6, line 50 skipping to change at page 6, line 51
condition for sending RAs and changing the preferred lifetime value. condition for sending RAs and changing the preferred lifetime value.
See Section 3.2.2 for more details. See Section 3.2.2 for more details.
If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS
[RFC8106] it might be desirable for the conditional RAs to update the [RFC8106] it might be desirable for the conditional RAs to update the
Lifetime field of the RDNSS option as well. 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 RA
fields values (like PIO Preferred Lifetime or DNS Server Lifetime) fields values (like PIO Preferred Lifetime or DNS Server Lifetime)
changed by the particular trigger MUST stay the same until another changed by the particular trigger need to stay the same until another
event happens causing the value to be updated. E.g. if the ISP_A event happens causing the value to be updated. E.g. if the ISP_A
uplink failure causes the prefix to be deprecated all solicited and uplink failure causes the prefix to be deprecated, all solicited and
unsolicited RAs sent by the router MUST have the Preferred Lifetime unsolicited RAs sent by the router need to have the Preferred
for that POI set to 0 until the uplink comes back up. Lifetime for that POI 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 CPE routers ([RFC7084]) and the existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the
documented behaviour of homenet devices. It is using the same documented behavior of homenet devices. It is using the same
mechanism of deprecating a prefix when the corresponding uplink is mechanism of deprecating a prefix when the corresponding uplink is
not operational, applying it to enterprise network scenario. not operational, applying it to 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 most common enterprise multihoming scenarios, described in
Section 2. Section 2.
3.2.1. Single Router, Primary/Backup Uplinks 3.2.1. Single Router, Primary/Backup Uplinks
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 { 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))
packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 THEN
packet_source_address is in 2001:db8:1::/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) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))
} THEN
if { default next-hop is ISP_B_uplink
packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48
packet_source_address is in 2001:db8:2::/48
}
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/if ISP_A uplink fails, hosts should stop
using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 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 router until the ISP_A uplink comes back up. To achieve this the router
advertisement configuration on the R1 device for the interface facing advertisement 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 preferred_lifetime = 604800 THEN
else preferred_lifetime = 0 preferred_lifetime = 604800
} ELSE
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 preferred_lifetime = 0 THEN
else preferred_lifetime = 604800 preferred_lifetime = 0
ELSE
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 on Fig.2
skipping to change at page 9, line 25 skipping to change at page 9, line 25
'-------' ', ,' '-------' ', ,'
-------- --------
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 (ISP_B
address space). Each router needs to have a forwarding policy 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 { 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))
packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 THEN
packet_source_address is in 2001:db8:1::/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) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))
} THEN
if { default next-hop is ISP_B_uplink
packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48
packet_source_address is in 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 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 is
the one with the active uplink, then the simplest way is to use the the one with the active uplink, then the simplest way is to use the
VRRP mastership as a condition for router advertisement. So, if VRRP mastership as a condition for router advertisement. So, if
ISP_A is the primary uplink, the routers R1 and R2 need to be ISP_A is the primary uplink, the routers R1 and R2 need to be
configured in the following way: configured in the 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 ISP_A uplink is up). If ISP_A
uplink is down, then R1 becomes a backup. Router advertisements on uplink is down, then R1 becomes a backup. Router advertisements on
R1's interface facing H1 needs to have the following policy applied: R1's interface facing H1 needs to have the following policy applied:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
if vrrp_master then preferred_lifetime = 604800 IF (vrrp_master)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
} }
R2 is VRRP backup by default. Router advertsement on R2 interface R2 is VRRP backup by default. Router advertsement on R2 interface
facing H1 needs to have the following policy applied: facing H1 needs to have the following policy applied:
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
if vrrp_master then preferred_lifetime = 604800 IF(vrrp_master)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
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 like a route to the uplink
interface subnet or a default route received from the uplink can be interface subnet or a default route received from the uplink can be
used. The obvious drawback of using the routing table to trigger the used. The obvious drawback of using the routing table to trigger the
conditional RAs is that some additional configuration is required. conditional RAs is that some additional configuration is required.
For example, if a route to the prefix assigned to the ISP uplink is 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 used as a trigger, then the conditional RA policy would have the
following logic: following logic:
R1: R1:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
if ISP_A_uplink is up then preferred_lifetime = 604800 IF (ISP_A_uplink is up)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
} }
R2: R2:
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
if ISP_A_uplink_route is present then preferred_lifetime = 0 IF (ISP_A_uplink_route is present)
else preferred_lifetime = 604800 THEN
preferred_lifetime = 0
ELSE
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 uplink availability indicator, then the policy logic would look like
the following: the following:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
if ISP_A_uplink is up then preferred_lifetime = 604800 IF (ISP_A_uplink is up)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
} }
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
if ISP_B_uplink is up then preferred_lifetime = 604800 IF (ISP_B_uplink is up)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
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 as described in correct uplink based on the source address as described in
Section 3.2.1. Section 3.2.1.
3.2.4. Two Router, Load Balancing Between Uplinks 3.2.4. Two Router, 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. It means
skipping to change at page 11, line 36 skipping to change at page 12, line 11
setting preferred_lifetime to a non-zero value when the ISP uplink is setting preferred_lifetime to a non-zero 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 the preferred lifetime to 0
in case of uplink failure. The uplink recovery would trigger another in case of uplink failure. The uplink recovery would trigger another
RA with non-zero preferred lifetime to make the addresses from the RA with non-zero preferred lifetime to make the addresses from the
prefix preferred again. The example RA policy on R1 and R2 would prefix preferred again. The example RA policy on R1 and R2 would
look like: look like:
R1: R1:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
if ISP_A_uplink is up then preferred_lifetime = 604800 IF (ISP_A_uplink is up)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
} }
R2: R2:
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
if ISP_B_uplink is up then preferred_lifetime = 604800 IF (ISP_B_uplink is up)
else preferred_lifetime = 0 THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
} }
3.2.5. Topologies with Dedicated Border Routers 3.2.5. Topologies with Dedicated Border Routers
For simplicity reasons all topologies below show the ISP uplinks For simplicity, all topologies below show the ISP uplinks terminated
terminated on the first-hop routers. Obviously, the proposed on the first-hop routers. Obviously, the proposed approach can be
approach can be used in more complex topologies when dedicated used in more complex topologies when dedicated devices are used for
devices are used for terminating ISP uplinks. In that case VRRP terminating ISP uplinks. In that case VRRP mastership or interface
mastership or inteface status can not be used as a trigger for status can not be used as a trigger for conditional RAs and route
conditional RAs and route presence as described above should be used presence as described above should be used instead.
instead.
Let's look at the example topology shown on the Figure 3: Let's look at the example topology shown on the 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 :
skipping to change at page 12, line 35 skipping to change at page 13, line 30
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 one
then the following policy might be used to achieve the desired then the following policy might be used to achieve the desired
behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while
ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if
the uplink is non-operational): the 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 then preferred_lifetime = 604800 IF (ISP_A_uplink_route is present)
else preferred_lifetime = 0 THEN
} preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
if ISP_A_uplink_route is present then preferred_lifetime = 0 IF (ISP_A_uplink_route is present)
else preferred_lifetime = 604800 THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
} }
For load-balancing case the policy would look slightly different: For the load-balancing case the policy would look slightly different:
each prefix has non-zero preferred_lifetime only if the correspoding each prefix has non-zero preferred_lifetime only if the correspoding
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 then preferred_lifetime = 604800 IF (ISP_A_uplink_route is present)
else preferred_lifetime = 0 THEN
} preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
if ISP_B_uplink_route is present then preferred_lifetime = 604800 IF (ISP_B_uplink_route is present)
else preferred_lifetime = 0 THEN
} preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 3.2.6. Intra-Site 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 when 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 intra-site
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 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 there is no preferred addresses available) and the source address (as there is no preferred addresses available) and the source address
selection algorith can pick up one of them, allowing the intra-site selection algorith can pick up one of them, allowing the intra-site
communication. However some OSes might just fall back to IPv4 if the communication. However some OSes might just fall back to IPv4 if the
network interface has no preferred IPv6 global addresses. Therefore network interface has no preferred IPv6 global addresses. Therefore
if intra-site connectivity is vital during simultanious outages of if intra-site connectivity is vital during simultanious outages of
multiple uplinks, administrators might consider using ULAs or multiple uplinks, administrators might consider using ULAs or
provisioning additional backup uplinks to protect the network from provisioning additional backup uplinks to protect the network from
double-failure cases. 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 (primary one or one used in load balaning
scenario) starts flapping, it might lead to undesirable situation of scenario) starts flapping, it might lead to the undesirable situation
flapping addresses on hosts (every time the uplink goes up hosts of flapping addresses on hosts (every time the uplink goes up hosts
receive an RA with non-zerop preferred PIO lifetime, and every time receive an RA with non-zero preferred PIO lifetime, and every time
the uplink goes down all address in the affected prefix become the uplink goes down all addresses in the affected prefix become
deprecated). Undoubtedly it would negatively impact user experience, deprecated). This would, undoubtedly, negatively impact the user
not mentioning spikes of DAD traffic every time an uplink comes back experience, not to mention the impact of spikes of DAD traffic every
up. Therefore it's recommended that router vendors implement some time an uplink comes back up. Therefore it's recommended that router
form of damping policy for conditional RAs and either postpone vendors implement some form of damping policy for conditional RAs and
sending an RA with non-zero lifetime for a POI when the uplink comes either postpone sending an RA with non-zero lifetime for a POI when
up for a number of seconds or even introduce accumulated penalties/ the uplink comes up for a number of seconds or even introduce
exponential backoff algorithm for such delays. (In the case of accumulated penalties/exponential backoff algorithm for such delays.
multiple simultaneous uplink failure scenario, when all but one (In the case of a multiple simultaneous uplink failure scenario, when
uplinks are down and the last remaining is flapping it might result all but one uplinks are down and the last remaining is flapping it
in all addresses being deprecated for a while after the flapping might result in all addresses being deprecated for a while after the
uplink recovers.) flapping uplink recovers.)
3.3. Solution Limitations 3.3. Solution Limitations
It should be noted that the proposed approach is not a silver bullet It should be noted that the proposed approach is not a silver bullet
for all possible multihoming scenarios. The main goal is to solve for all possible multihoming scenarios. It would work very well for
some common use cases so it would suit very well relatively simple networks with relatively simple topologies and straightforward
topologies with straightforward policies. The more complex the routing policies. The more complex the network topology and the
network topology and the corresponding routing policies more corresponding routing policies, the more configuration would be
configuration would be required to implement the solution. 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 that scenario when both uplinks are active hosts would uplinks. In the scenario in which both uplinks are active, hosts
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 most algorithm ([RFC6724]), and therefore the load between two uplinks
likely would not be evenly distributed. (However the proposed most 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
SDN networks where controllers might selectively deprecate prefixes SDN networks where controllers might selectively deprecate prefixes
on some hosts but not others to move egress traffic between uplinks). on some hosts but not others to move egress traffic between uplinks).
Also the prefix selection does not take into account any other Also the prefix selection does not take into account any other
uplinks properties (such as RTT etc) so egress traffic might not be uplinks properties (such as RTT etc), so egress traffic might not be
sent to the nearest uplink if the corresponding prefix is selected as 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 a source. In general, if not all uplinks are equal and some uplinks
are expected to be preferred over others then the network are expected to be preferred over others, then the network
adminitrator should ensure that prefixes from non-preferred ISP(s) administrator should ensure that prefixes from non-preferred ISP(s)
are kept deprecated (so primary/backup setup is used). are kept deprecated (so primary/backup setup is used).
3.3.1. Connections Preservation 3.3.1. Connections Preservation
The proposed solution is not designed to preserve connections 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
not return path from Internet to the correspodning prefix. In this not return path from the Internet to the correspodning prefix. In
regard it is similar to IPv4 multihoming using NAT, where an uplink this regard it is similar to IPv4 multihoming using NAT, where an
failure and failover to another uplink means that a public IPv4 uplink failure and failover to another uplink means that a public
address changes and all existing connections are interrupted. IPv4 address changes and all existing connections are interrupted.
An uplink recovery, however, does not nessesary leads to connections An uplink recovery, however, 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 deprectaed, 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),
skipping to change at page 17, line 26 skipping to change at page 18, line 36
[I-D.ietf-rtgwg-dst-src-routing] [I-D.ietf-rtgwg-dst-src-routing]
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", draft-ietf-rtgwg-dst-src-routing-06 (work in
progress), October 2017. progress), October 2017.
[I-D.ietf-rtgwg-enterprise-pa-multihoming] [I-D.ietf-rtgwg-enterprise-pa-multihoming]
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-03 (work in draft-ietf-rtgwg-enterprise-pa-multihoming-05 (work in
progress), February 2018. progress), April 2018.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>. 2004, <https://www.rfc-editor.org/info/rfc3704>.
[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>.
 End of changes. 47 change blocks. 
172 lines changed or deleted 206 lines changed or added

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