draft-ietf-v6ops-conditional-ras-04.txt   draft-ietf-v6ops-conditional-ras-05.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: November 5, 2018 RIPE NCC Expires: December 20, 2018 RIPE NCC
May 4, 2018 June 18, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-04 draft-ietf-v6ops-conditional-ras-05
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. 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. The "ietf-rtgwg- on the desired egress ISP for that traffic. The "ietf-rtgwg-
enterprise-pa-multihoming" document proposes a solution to this enterprise-pa-multihoming" document proposes a solution to this
problem by introducing a new routing functionality (Source Address problem by introducing a new routing functionality (Source Address
Dependent Routing) to solve the uplink selection issue and using Dependent Routing) to solve the uplink selection issue and using
Router Advertisements to influence the host source address selection. Router Advertisements to influence the host source address selection.
While the above-mentioned document focuses on solving the general While the above-mentioned document focuses on solving the general
problem and on covering various complex use cases, this document problem and on covering various complex use cases, this document
describes how the solution proposed in the "ietf-rtgwg-enterprise-pa- adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-
multihoming" draft can be adopted for a limited number of common use multihoming" draft to provide a solution for a limited number of
cases. In particular, the focus is on scenarios where an enterprise common use cases. In particular, the focus is on scenarios where an
network has two Internet uplinks used either in primary/backup mode enterprise network has two Internet uplinks used either in primary/
or simultaneously and hosts in that network might not yet properly backup mode or simultaneously and hosts in that network might not yet
support multihoming as described in RFC8028. 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 November 5, 2018. 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . 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 . . . . . 11 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 . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 14
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 15 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 15
3.3.1. Connections Preservation . . . . . . . . . . . . . . 15 3.3.1. Connections Preservation . . . . . . . . . . . . . . 15
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 16 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 ([RFC4116]). Using Provider Independent (PI) address
always an option, since it requires running BGP between the space is not always an option, since it requires running BGP between
enterprise network and the ISPs. Administrative overhead of the enterprise network and the ISPs. Administrative overhead of
obtaining and managing PI address space can also be a concern. As obtaining and managing PI address space can also be a concern. As
IPv6 hosts can, by design, have multiple addresses of the global IPv6 hosts can, by design, have multiple addresses of the global
scope, multihoming using provider address looks even easier for IPv6: scope ([RFC4291]), multihoming using provider address looks even
each ISP assigns an IPv6 block (usually /48) and hosts in the easier for IPv6: each ISP assigns an IPv6 block (usually /48) and
enterprise network have addresses assigned from each ISP block. hosts in the enterprise network have addresses assigned from each ISP
However using IPv6 PA blocks in multihoming scenario introduces some block. However using IPv6 PA blocks in multihoming scenario
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
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. Unfortunately that rule has not been advertise different prefixes. While [RFC6724] defines the Rule 5.5
widely implemented when this document was written. Therefore network as optional, the recent [RFC8028] recommends that multihomed hosts
SHOULD support it. 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 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
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 relying on rule 5.5, it is possible to provide IPv6 scenarios without relying on rule 5.5, it is possible to provide IPv6
multihoming using provider-assigned (PA) address space for the most multihoming using provider-assigned (PA) address space for the most
common use cases. This document discusses how the general solution common use cases. This document discusses how the general approach
described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be
applied to scenarios when: applied to solve multihoming 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 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]).
skipping to change at page 5, line 18 skipping to change at page 5, line 21
3.1.1. Uplink Selection 3.1.1. Uplink Selection
As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of
the two main problems to be solved in the enterprise multihoming the two main problems to be solved in the enterprise multihoming
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. Sending
packets with source addresses belonging to one ISP address space to
another ISP might cause those packets to be filtered out if those
ISPs or their uplinks implement anti-spoofing ingress filtering
([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, the simplest way to implement the desired functionality (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest
currently is to apply a policy which selects a next-hop or an egress way to implement the desired functionality currently is to apply a
interface based on the packet source address. Most SMB/Enterprise policy which selects a next-hop or an egress interface based on the
grade routers have such functionality available currently. packet source address. Most SMB/Enterprise 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.1. However,
some network topology changes (i.e. changing uplink status) might some network topology changes (i.e. changing uplink status) might
affect the global reachability for packets sourced from the affect the global reachability for packets sourced from the
particular prefixes and therefore such changes have to be signaled particular prefixes and therefore such changes have to be signaled
back to the hosts. For example: back to the hosts. For example:
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 and router advertisements are the most explanation on why SLAAC (Stateless Address Autoconfiguration,
[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 POI 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
o send RA triggered by defined event policies in response to uplink o send RA triggered by defined event policies in response to uplink
status change event; and status change event; and
o while sending periodic or solicted RAs, set the value in the given o while sending periodic or solicted RAs, set the value in the given
skipping to change at page 6, line 40 skipping to change at page 6, line 52
o presence of a particular route in the routing table; o presence of a particular route in the routing table;
o presence of a particular route with a particular attribute (next- o presence of a particular route with a particular attribute (next-
hop, tag etc) in the routing table; hop, tag etc) in the routing table;
o protocol adjacency change. o protocol adjacency change.
etc. etc.
In some scenarios, when two routers are providing first-hop In some scenarios, when two routers are providing first-hop
redundancy via VRRP, the master-backup status can be considered as a redundancy via VRRP (Virtual Router Redundancy Protocol, [RFC5798]),
condition for sending RAs and changing the preferred lifetime value. the master-backup status can be considered as a condition for sending
See Section 3.2.2 for more details. RAs and changing the preferred lifetime value. 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 (Router Advertisement Options for DNS Configuration, [RFC8106]) it
Lifetime field of the RDNSS option as well. might be desirable for the conditional RAs to update the Lifetime
field of the RDNSS option as well.
The trigger is not only forcing the router to send an unsolicited RA 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 need to 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 need to have the Preferred unsolicited RAs sent by the router need to have the Preferred
Lifetime for that POI set to 0 until the uplink comes back up. Lifetime for that PIO set to 0 until the uplink comes back up.
It should be noted that the proposed solution is quite similar to the It should be noted that the proposed solution is quite similar to the
existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the existing requirement L-13 for IPv6 Customer Edge Routers ([RFC7084])
documented behavior of homenet devices. It is using the same and the documented behavior of homenet devices ([RFC7788]). It is
mechanism of deprecating a prefix when the corresponding uplink is using the same mechanism of deprecating a prefix when the
not operational, applying it to enterprise network scenario. corresponding uplink is 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
-------- --------
,-------, ,' ', ,-------, ,' ',
+----+ 2001:db8:1::/48 ,' ', : : +----+ 2001:db8:1::/48 ,' ', : :
| |------------------+ ISP_A +--+: : | |------------------+ ISP_A +--+: :
2001:db8:1:1::/64 | | ', ,' : : 2001:db8:1:1::/64 | | ', ,' : :
| | '-------' : : | | '-------' : :
H1------------------| R1 | : INTERNET : H1------------------| R1 | : INTERNET :
| | ,-------, : : | | ,-------, : :
2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : :
| |------------------+ ISP_B +--+: : | |------------------+ ISP_B +--+: :
skipping to change at page 11, line 37 skipping to change at page 12, line 4
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up) IF (ISP_B_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
R1 needs a forwarding policy to be applied to forward packets to the R1 needs a forwarding policy to be applied to forward packets to the
correct uplink based on the source address as described in correct uplink based on the source address similar to one described
Section 3.2.1. in 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
that both R1 and R2 need to have the corresponding forwarding policy that both R1 and R2 need to have the corresponding forwarding policy
to forward packets based on their source addresses. to forward packets based on their source addresses.
Each router would send RAs with POI for the corresponding prefix. Each router would send RAs with PIO for the corresponding prefix.
setting preferred_lifetime to a non-zero value when the ISP uplink is setting preferred_lifetime to a 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 {
skipping to change at page 12, line 30 skipping to change at page 12, line 45
prefix 2001:db8:2:1::/64 { prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up) IF (ISP_B_uplink is up)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
3.2.5. Topologies with Dedicated Border Routers 3.2.5. Topologies with Dedicated Border Routers
For simplicity, all topologies below 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 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 ,-------, ,' ',
skipping to change at page 14, line 33 skipping to change at page 14, line 33
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 is no preferred addresses available) and the source address
selection algorith can pick up one of them, allowing the intra-site selection algorithm 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 (Unique
provisioning additional backup uplinks to protect the network from Local Addresses, [RFC4193]) or provisioning additional backup uplinks
double-failure cases. 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 DAD traffic every experience, not to mention the impact of spikes of duplicate address
time an uplink comes back up. Therefore it's recommended that router detection traffic every time an uplink comes back up. Therefore it's
vendors implement some form of damping policy for conditional RAs and recommended that router vendors implement some form of damping policy
either postpone sending an RA with non-zero lifetime for a POI when for conditional RAs and either postpone sending an RA with non-zero
the uplink comes up for a number of seconds or even introduce lifetime for a PIO when the uplink comes up for a number of seconds
accumulated penalties/exponential backoff algorithm for such delays. or even introduce accumulated penalties/exponential backoff algorithm
(In the case of a multiple simultaneous uplink failure scenario, when for such delays. (In the case of a multiple simultaneous uplink
all but one uplinks are down and the last remaining is flapping it failure scenario, when all but one uplinks are down and the last
might result in all addresses being deprecated for a while after the remaining is flapping it might result in all addresses being
flapping uplink recovers.) deprecated for a while after the 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. It would work very well for for all possible multihoming scenarios. It would work very well for
networks with relatively simple topologies and straightforward networks with relatively simple topologies and straightforward
routing policies. The more complex the network topology and the routing policies. The more complex the network topology and the
corresponding routing policies, the more configuration would be corresponding routing policies, the more 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 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
SDN networks where controllers might selectively deprecate prefixes software defined networks where controllers might selectively
on some hosts but not others to move egress traffic between uplinks). deprecate prefixes on some hosts but not others to move egress
Also the prefix selection does not take into account any other traffic between uplinks). Also the prefix selection does not take
uplinks properties (such as RTT etc), so egress traffic might not be into account any other uplinks properties (such as latencyetc), so
sent to the nearest uplink if the corresponding prefix is selected as egress traffic might not be sent to the nearest uplink if the
a source. In general, if not all uplinks are equal and some uplinks corresponding prefix is selected as a source. In general, if not all
are expected to be preferred over others, then the network uplinks are equal and some uplinks are expected to be preferred over
administrator should ensure that prefixes from non-preferred ISP(s) others, then the network administrator should ensure that prefixes
are kept deprecated (so primary/backup setup is used). from non-preferred ISP(s) 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 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 not return path from the Internet to the correspodning 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
skipping to change at page 16, line 44 skipping to change at page 16, line 45
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>.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582,
DOI 10.17487/RFC3582, August 2003,
<https://www.rfc-editor.org/info/rfc3582>.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations", Gill, "IPv4 Multihoming Practices and Limitations",
RFC 4116, DOI 10.17487/RFC4116, July 2005, RFC 4116, DOI 10.17487/RFC4116, July 2005,
<https://www.rfc-editor.org/info/rfc4116>. <https://www.rfc-editor.org/info/rfc4116>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, Architecture", RFC 4291, DOI 10.17487/RFC4291, February
October 2005, <https://www.rfc-editor.org/info/rfc4218>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
Should Think About", RFC 4219, DOI 10.17487/RFC4219,
October 2005, <https://www.rfc-editor.org/info/rfc4219>.
[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>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>.
[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>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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
Network Prefix Translation: Requirements and Solution", Network Prefix Translation: Requirements and Solution",
draft-ietf-rtgwg-enterprise-pa-multihoming-05 (work in draft-ietf-rtgwg-enterprise-pa-multihoming-07 (work in
progress), April 2018. progress), June 2018.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[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>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Extensions for Stateless Address Autoconfiguration in Version 3 for IPv4 and IPv6", RFC 5798,
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, DOI 10.17487/RFC5798, March 2010,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc5798>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, DOI 10.17487/RFC5534, June 2009,
<https://www.rfc-editor.org/info/rfc5534>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>. <https://www.rfc-editor.org/info/rfc7084>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <https://www.rfc-editor.org/info/rfc7788>. 2016, <https://www.rfc-editor.org/info/rfc7788>.
 End of changes. 39 change blocks. 
125 lines changed or deleted 93 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/