draft-ietf-v6ops-conditional-ras-01.txt   draft-ietf-v6ops-conditional-ras-02.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: August 31, 2018 February 27, 2018 Expires: September 19, 2018 RIPE NCC
March 18, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-01 draft-ietf-v6ops-conditional-ras-02
Abstract Abstract
This document discusses most common scenarios of connecting an This document discusses 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.
skipping to change at page 1, line 48 skipping to change at page 1, line 49
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 August 31, 2018. This Internet-Draft will expire on September 19, 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 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 3 2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 3
2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 3 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 3
2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4
3. Conditional Router Advertisements . . . . . . . . . . . . . . 4 3. Conditional Router Advertisements . . . . . . . . . . . . . . 4
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 4 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 4
3.1.2. Source Address Selection and Conditional RAs . . . . 5 3.1.2. Source Address Selection and Conditional RAs . . . . 5
3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 6 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 6 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 . . . . 10
3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 10 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 10
3.2.5. Topologies with Dedicated Border Routers . . . . . . 11 3.2.5. Topologies with Dedicated Border Routers . . . . . . 11
3.2.6. Intra-Site Communication during Simultaneous Uplinks 3.2.6. Intra-Site Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 13 Outage . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 13 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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 being o All the uplinks may be used simultaneously, with the traffic flows
randomly balanced between them. being randomly (not nessesary equally) distributed between them.
3. Conditional Router Advertisements 3. Conditional Router Advertisements
3.1. Solution Overview 3.1. Solution Overview
3.1.1. Uplink Selection 3.1.1. Uplink Selection
As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of As discussed in [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
skipping to change at page 6, line 46 skipping to change at page 6, line 46
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 behaviour 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. applied to most common enterprise multihoming scenarios, described in
Section 2.
3.2.1. Single Router, Primary/Backup Uplinks 3.2.1. Single Router, Primary/Backup Uplinks
-------- --------
,-------, ,' ', ,-------, ,' ',
+----+ 2001:db8:1::/48 ,' ', : : +----+ 2001:db8:1::/48 ,' ', : :
| |------------------+ ISP_A +--+: : | |------------------+ ISP_A +--+: :
2001:db8:1:1::/64 | | ', ,' : : 2001:db8:1:1::/64 | | ', ,' : :
| | '-------' : : | | '-------' : :
H1------------------| R1 | : INTERNET : H1------------------| R1 | : INTERNET :
| | ,-------, : : | | ,-------, : :
2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : :
| |------------------+ ISP_B +--+: : | |------------------+ ISP_B +--+: :
skipping to change at page 7, line 35 skipping to change at page 7, line 38
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_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
packet_source_address is in 2001:db8:1::/48 packet_source_address is in 2001:db8:1::/48
} then { } then {
next-hop is ISP_A_uplink default next-hop is ISP_A_uplink
} }
if { if {
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
packet_source_address is in 2001:db8:2::/48 packet_source_address is in 2001:db8:2::/48
} }
then { then {
next-hop is ISP_B_uplink 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 9, line 9 skipping to change at page 9, line 11
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_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
packet_source_address is in 2001:db8:1::/48 packet_source_address is in 2001:db8:1::/48
} then { } then {
next-hop is ISP_A_uplink default next-hop is ISP_A_uplink
} }
if { if {
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
packet_source_address is in 2001:db8:2::/48 packet_source_address is in 2001:db8:2::/48
} then { } then {
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 10, line 4 skipping to change at page 10, line 6
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 trgger, 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 then preferred_lifetime = 604800
else preferred_lifetime = 0 else preferred_lifetime = 0
} }
R2: R2:
skipping to change at page 12, line 47 skipping to change at page 12, line 47
For load-balancing case the policy would look slightly different: For 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 then preferred_lifetime = 604800
else preferred_lifetime = 0 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 = 0 if ISP_B_uplink_route is present then preferred_lifetime = 604800
else 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 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. In the scenario when intra-site connectivity is vital communication. However some OSes might just fall back to IPv4 if the
even in multiple failure scenario, administrators might consider network interface has no preferred IPv6 global addresses. Therefore
using ULAs or provisioning additional backup uplinks to protect the if intra-site connectivity is vital during simultanious outages of
network from double-failure cases. multiple uplinks, administrators might consider using ULAs or
provisioning additional backup uplinks to protect the network from
double-failure cases.
3.2.7. Uplink Damping 3.2.7. Uplink Damping
If an actively used uplink (primary one or one used in load balaning If an actively used uplink (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 undesirable situation of
flapping addresses on hosts (every time the uplink goes up hosts 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-zerop preferred PIO lifetime, and every time
the uplink goes down all address in the affected prefix become the uplink goes down all address in the affected prefix become
deprecated). Undoubtedly it would negatively impact user experience, deprecated). Undoubtedly it would negatively impact user experience,
not mentioning spikes of DAD traffic every time an uplink comes back not mentioning spikes of DAD traffic every time an uplink comes back
skipping to change at page 14, line 33 skipping to change at page 14, line 35
This memo introduces no new security considerations. This memo introduces no new security considerations.
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, Erik Nordmark, Dave Thaler. Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave
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>.
skipping to change at page 16, line 26 skipping to change at page 16, line 31
[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-02 (work in draft-ietf-rtgwg-enterprise-pa-multihoming-03 (work in
progress), October 2017. progress), February 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>.
skipping to change at page 17, line 33 skipping to change at page 17, line 38
Authors' Addresses Authors' Addresses
Jen Linkova Jen Linkova
Google Google
Mountain View, California 94043 Mountain View, California 94043
USA USA
Email: furry@google.com Email: furry@google.com
Massimiliano Stucchi Massimiliano Stucchi
RIPE NCC
Stationsplein, 11
Amsterdam 1012 AB
The Netherlands
Email: max@stucchi.ch Email: mstucchi@ripe.net
 End of changes. 18 change blocks. 
21 lines changed or deleted 31 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/