draft-ietf-v6ops-conditional-ras-05.txt   draft-ietf-v6ops-conditional-ras-06.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: December 20, 2018 RIPE NCC Expires: February 2, 2019 RIPE NCC
June 18, 2018 August 1, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-05 draft-ietf-v6ops-conditional-ras-06
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. The problem of enterprise multihoming without address by an ISP and how the approach proposed in the "ietf-rtgwg-
translation of any form has not been solved yet as it requires both enterprise-pa-multihoming" draft could be applied in those scenarios.
the network to select the correct egress ISP based on the packet The problem of enterprise multihoming without address translation of
source address and hosts to select the correct source address based any form has not been solved yet as it requires both the network to
on the desired egress ISP for that traffic. The "ietf-rtgwg- select the correct egress ISP based on the packet source address and
enterprise-pa-multihoming" document proposes a solution to this hosts to select the correct source address based on the desired
problem by introducing a new routing functionality (Source Address egress ISP for that traffic. The "ietf-rtgwg-enterprise-pa-
Dependent Routing) to solve the uplink selection issue and using multihoming" document proposes a solution to this problem by
Router Advertisements to influence the host source address selection. introducing a new routing functionality (Source Address Dependent
While the above-mentioned document focuses on solving the general Routing) to solve the uplink selection issue and using Router
problem and on covering various complex use cases, this document Advertisements to influence the host source address selection. While
adopts the approach proposed in the "ietf-rtgwg-enterprise-pa- the above-mentioned document focuses on solving the general problem
multihoming" draft to provide a solution for a limited number of and on covering various complex use cases, this document adopts the
common use cases. In particular, the focus is on scenarios where an approach proposed in the "ietf-rtgwg-enterprise-pa-multihoming" draft
enterprise network has two Internet uplinks used either in primary/ to provide a solution for a limited number of common use cases. In
backup mode or simultaneously and hosts in that network might not yet particular, the focus is on scenarios where an enterprise network has
properly support multihoming as described in RFC8028. two Internet uplinks used either in primary/backup mode or
simultaneously and hosts in that network might not yet properly
support multihoming as described in 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 February 2, 2019.
This Internet-Draft will expire on December 20, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
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 . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 9 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9
3.2.3. Single Router, Load Balancing Between Uplinks . . . . 11 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 11
3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 12 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 12
3.2.5. Topologies with Dedicated Border Routers . . . . . . 12 3.2.5. Topologies with Dedicated Border Routers . . . . . . 13
3.2.6. Intra-Site Communication during Simultaneous Uplinks 3.2.6. Intra-Site Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 14 Outage . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 14 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 15 3.2.8. Routing Packets when the Corresponding Uplink is
3.3.1. Connections Preservation . . . . . . . . . . . . . . 15 Unavailable . . . . . . . . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 3.3.1. Connections Preservation . . . . . . . . . . . . . . 16
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 19
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 [RFC1918] address space 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
skipping to change at page 3, line 31 skipping to change at page 3, line 34
introduces some challenges, including but not limited to: 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 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses
these and other related challenges in detail in relation to the these and other related challenges in detail in relation to the
general multihoming scenario for enterprise networks and proposes general multihoming scenario for enterprise networks and proposes a
solution which relies heavily on the rule 5.5 of the default address solution which relies heavily on the rule 5.5 of the default address
selection algorithm ([RFC6724]). The rule 5.5 makes hosts prefer selection algorithm ([RFC6724]). The rule 5.5 makes hosts prefer
source addresses in a prefix advertised by the next-hop and therefore source addresses in a prefix advertised by the next-hop and therefore
is very useful in multihomed scenarios when different routers may is very useful in multihomed scenarios when different routers may
advertise different prefixes. While [RFC6724] defines the Rule 5.5 advertise different prefixes. While [RFC6724] defines the Rule 5.5
as optional, the recent [RFC8028] recommends that multihomed hosts as optional, the recent [RFC8028] recommends that multihomed hosts
SHOULD support it. Unfortunately that rule has not been widely SHOULD support it. Unfortunately that rule has not been widely
implemented when this document was written. 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 the rule 5.5, especially in the
skipping to change at page 4, line 14 skipping to change at page 4, line 17
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 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]).
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
2. Common Enterprise Multihoming Scenarios 2. 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 is using 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;
skipping to change at page 5, line 28 skipping to change at page 5, line 40
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. Sending packets sourced from subnet_B must be sent to ISP_B uplink. Sending
packets with source addresses belonging to one ISP address space to packets with source addresses belonging to one ISP address space to
another ISP might cause those packets to be filtered out if those another ISP might cause those packets to be filtered out if those
ISPs or their uplinks implement anti-spoofing ingress filtering ISPs or their uplinks implement anti-spoofing ingress filtering
([RFC2827] ([RFC2827]
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 (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest way
way to implement the desired functionality currently is to apply a to implement the desired functionality currently is to apply a policy
policy which selects a next-hop or an egress interface based on the which selects a next-hop or an egress interface based on the packet
packet source address. Most SMB/Enterprise grade routers have such source address. Most SMB/Enterprise grade routers have such
functionality available currently. 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
skipping to change at page 6, line 11 skipping to change at page 6, line 20
o An uplink to an ISP_A went down. Hosts should not use addresses o An uplink to an ISP_A went down. Hosts should not use addresses
from ISP_A prefix; from ISP_A prefix;
o A primary uplink to ISP_A which was not operational has come back o A primary uplink to ISP_A which 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 ISP_A
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 (Stateless Address Autoconfiguration, explanation on why SLAAC (Stateless Address Autoconfiguration,
[RFC4862] and RAs (Router Advertisements, [RFC4861]) are the most [RFC4862]) and RAs (Router Advertisements, [RFC4861]) 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 PIO (Prefix preferred_lifetime set to 0 in the corresponding PIO (Prefix
Information option, [RFC4861]) to indicate to hosts that that Information option, [RFC4861])) to indicate to hosts that that
addresses from that prefix should not be used; 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 PIO with non-zero preferred lifetime) sending an RA containing a PIO 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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) IF (packet_source_address is in 2001:db8:1::/48)
THEN and
default next-hop is ISP_A_uplink (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next-hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) IF (packet_source_address is in 2001:db8:2::/48)
THEN and
default next-hop is ISP_B_uplink (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next-hop is ISP_B_uplink
Under normal circumstances it is desirable that all traffic be sent 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:
skipping to change at page 10, line 5 skipping to change at page 10, line 5
'-------' ', ,' '-------' ', ,'
-------- --------
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 (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)) IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))
THEN THEN
default next-hop is ISP_A_uplink 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)) IF (packet_source_address is in 2001:db8:2::/48)
i and
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))
THEN THEN
default next-hop is ISP_B_uplink 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:
skipping to change at page 12, line 50 skipping to change at page 13, line 20
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 can not be used as a trigger for conditional RAs and route
presence as described above should be used instead. presence as described above (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 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 14, line 32 skipping to change at page 15, line 4
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 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 there is no preferred addresses available) and the source address (as there are no preferred addresses available) and the source
selection algorithm can pick up one of them, allowing the intra-site address selection algorithm can pick up one of them, allowing the
communication. However some OSes might just fall back to IPv4 if the intra-site communication. However some OSes might just fall back to
network interface has no preferred IPv6 global addresses. Therefore IPv4 if the network interface has no preferred IPv6 global addresses.
if intra-site connectivity is vital during simultanious outages of Therefore if intra-site connectivity is vital during simultanious
multiple uplinks, administrators might consider using ULAs (Unique outages of multiple uplinks, administrators might consider using ULAs
Local Addresses, [RFC4193]) or provisioning additional backup uplinks (Unique Local Addresses, [RFC4193]) or provisioning additional backup
to protect the network from double-failure cases. 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 (primary one or one used in load balaning
scenario) starts flapping, it might lead to the undesirable situation scenario) starts flapping, it might lead to the undesirable situation
of 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-zero preferred PIO lifetime, and every time receive an RA with non-zero preferred PIO lifetime, and every time
the uplink goes down all addresses in the affected prefix become the uplink goes down all addresses in the affected prefix become
deprecated). This would, undoubtedly, negatively impact the user deprecated). This would, undoubtedly, negatively impact the user
experience, not to mention the impact of spikes of duplicate address experience, not to mention the impact of spikes of duplicate address
detection traffic every time an uplink comes back up. Therefore it's detection traffic every time an uplink comes back up. Therefore it's
recommended that router vendors implement some form of damping policy recommended that router vendors implement some form of damping policy
for conditional RAs and either postpone sending an RA with non-zero for conditional RAs and either postpone sending an RA with non-zero
lifetime for a PIO when the uplink comes up for a number of seconds lifetime for a PIO when the uplink comes up for a number of seconds
or even introduce accumulated penalties/exponential backoff algorithm or even introduce accumulated penalties/exponential backoff algorithm
for such delays. (In the case of a multiple simultaneous uplink for such delays. (In the case of a multiple simultaneous uplink
failure scenario, when all but one uplinks are down and the last failure scenario, when all but one uplinks are down and the last
remaining is flapping it might result in all addresses being remaining is flapping it might result in all addresses being
deprecated for a while after the flapping uplink recovers.) deprecated for a while after the flapping uplink recovers.)
3.2.8. Routing Packets when the Corresponding Uplink is Unavailable
Deprecating IPv6 addresses by setting the preferred lifetime to 0
discourage but not strictly forbid its usage in new communications.
A deprecated address may still be used for existing connections
([RFC4862]). Therefore when an ISP uplink goes down the
corresponding border router might still receive packets with source
addresses belonging to that ISP address space while there is no
available uplink to send those packets to.
The expected router behaviour would depend on the uplink selection
mechanism. For example if some form of SADR is used then such
packets will be dropped as there is no route to the destination. If
policy-based routing is used to set a next-hop then the behaviour
would be implementation-dependend and may vary from dropping the
packets to forwarding them based on the routing table entries. It
should be noted that there is no return path to the packet source (as
the ISP uplink is not operational) therefore even if the outgoing
packets are sent to another ISP the return traffic might not be
delivered.
3.3. Solution Limitations 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
for all possible multihoming scenarios. It would work very well for bullet" for all possible multihoming scenarios. It would work very
networks with relatively simple topologies and straightforward well for networks with relatively simple topologies and
routing policies. The more complex the network topology and the straightforward routing policies. The more complex the network
corresponding routing policies, the more configuration would be topology and the corresponding routing policies, the more
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]), and therefore the load between two uplinks
most 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
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 latencyetc), so into account any other uplinks properties (such as latency etc), 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
not return path from the Internet to the correspodning 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 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 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 can not be preserved after an uplink recovery. sessions might not be preserved after an uplink recovery unless
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 memo asks the IANA for no new parameters.
5. Security Considerations 5. Security Considerations
This memo introduces no new security considerations. This memo introduces no new security considerations. It relies on
Router Advertisements ([RFC4861]) and SLAAC ([RFC4862] mechanism and
inherits their security properties. If an attacker is able to send a
rogue RA they could deprecate IPv6 addresses on hosts or infuence
source address selection processes on hosts.
The potential attack vectors are including but not limited to:
o An attacker sends a rogue RA deprecating IPv6 addresses on hosts;
o An attacker sends a rogue RA making addresses preferred while the
corresponding ISP uplink is not operational;
o An attacker sends a rogue RA making addresses preferred for a
backup ISP, steering traffic to undesirable (e.g. more expensive)
uplink.
Therefore the network administrators SHOULD secure Router
Advertisements, e.g., by deploying 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. Acknowledgements
Thanks to the following people (in alphabetical order) for their Thanks to the following people (in alphabetical order) for their
review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus
Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave
skipping to change at page 16, line 37 skipping to change at page 18, line 4
This memo introduces no new privacy considerations. This memo introduces no new privacy considerations.
6. Acknowledgements 6. Acknowledgements
Thanks to the following people (in alphabetical order) for their Thanks to the following people (in alphabetical order) for their
review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus
Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave
Thaler. Thaler.
7. References 7. References
7.1. Normative References 7.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
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001, DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>. <https://www.rfc-editor.org/info/rfc3022>.
skipping to change at page 17, line 28 skipping to change at page 18, line 44
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
DOI 10.17487/RFC6105, February 2011,
<https://www.rfc-editor.org/info/rfc6105>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[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
 End of changes. 29 change blocks. 
71 lines changed or deleted 145 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/