draft-ietf-v6ops-conditional-ras-00.txt   draft-ietf-v6ops-conditional-ras-01.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: April 11, 2018 October 8, 2017 Expires: August 31, 2018 February 27, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-00 draft-ietf-v6ops-conditional-ras-01
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 48
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 April 11, 2018. This Internet-Draft will expire on August 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . 4 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 . . . . . . . . 6
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 Uplinks Outage . . . 13 3.2.6. Intra-Site Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 13 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 or PI address space is not network edge. Using Provider Independent (PI) address space is not
always an option as it requires running BGP between the enterprise always an option as it requires running BGP between the enterprise
network and the ISPs). As IPv6 host can, by design, have multiple network and the ISPs, not mentioning administrative overhead of
addresses of the global scope, multihoming using provider address obtaining and managing PI address space. As IPv6 host can, by
looks even easier for IPv6: each ISP assigns an IPv6 block (usually design, have multiple addresses of the global scope, multihoming
/48) and hosts in the enterprise network have addresses assigned from using provider address looks even easier for IPv6: each ISP assigns
each ISP block. However using IPv6 PA blocks in multihoming scenario an IPv6 block (usually /48) and hosts in the enterprise network have
introduces some challenges, including but not limited to: addresses assigned from each ISP block. However using IPv6 PA blocks
in multihoming scenario introduces some challenges, including but not
limited to:
o Selecting the correct uplink based on the packet source address; o Selecting the correct uplink based on the packet source address;
o Signaling to hosts that some source addresses should or should not o Signaling to hosts that some source addresses should or should not
be used (e.g. an uplink to the ISP went down or became available be used (e.g. an uplink to the ISP went down or became available
again). again).
The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses
these and other related challenges in details in relation to the these and other related challenges in details in relation to the
general multihoming scenario for enterprise networks. Unfortunately general multihoming scenario for enterprise networks. Unfortunately
skipping to change at page 7, line 50 skipping to change at page 7, line 50
} }
then { then {
next-hop is ISP_B_uplink 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 the desired until the ISP_A uplink comes back up. To achieve this the router
behavior the router advertisement configuration on the R1 device for advertisement configuration on the R1 device for the interface facing
the interface facing H1 needs to have the following policy: H1 needs to have the following policy:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
if ISP_A_uplink is up if ISP_A_uplink is up
then preferred_lifetime = 604800 then 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_A_Uplink is up if ISP_A_Uplink is up
then preferred_lifetime = 0 then preferred_lifetime = 0
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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 = 0
else preferred_lifetime = 604800 else preferred_lifetime = 604800
} }
3.2.6. Intra-Site Communication during 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. communication. In the scenario when intra-site connectivity is vital
even in multiple failure scenario, administrators might consider
using ULAs or provisioning additional backup uplinks to protect the
network from double-failure cases.
3.2.7. Uplink Damping
If an actively used uplink (primary one or one used in load balaning
scenario) starts flapping, it might lead to undesirable situation of
flapping addresses on hosts (every time the uplink goes up hosts
receive an RA with non-zerop preferred PIO lifetime, and every time
the uplink goes down all address in the affected prefix become
deprecated). Undoubtedly it would negatively impact user experience,
not mentioning spikes of DAD traffic every time an uplink comes back
up. Therefore it's recommended that router vendors implement some
form of damping policy for conditional RAs and either postpone
sending an RA with non-zero lifetime for a POI when the uplink comes
up for a number of seconds or even introduce accumulated penalties/
exponential backoff algorithm for such delays. (In the case of
multiple simultaneous uplink failure scenario, when all but one
uplinks are down and the last remaining is flapping it might result
in all addresses being 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. The main goal is to solve for all possible multihoming scenarios. The main goal is to solve
some common use cases so it would suit very well relatively simple some common use cases so it would suit very well relatively simple
topologies with straightforward policies. The more complex the topologies with straightforward policies. The more complex the
network topology and the corresponding routing policies more network topology and the corresponding routing policies more
configuration would be required to implement the solution. Another configuration would be required to implement the solution. Another
limitation is related to the load balancing between the uplinks. In limitation is related to the load balancing between the uplinks. In
skipping to change at page 14, line 13 skipping to change at page 14, line 33
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, Dave Thaler. Keane, Erik Kline, David Lamparter, 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 15, line 31 skipping to change at page 16, line 5
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>. <https://www.rfc-editor.org/info/rfc6296>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<https://www.rfc-editor.org/info/rfc7157>. <https://www.rfc-editor.org/info/rfc7157>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<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>.
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-05 (work in Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in
progress), July 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-01 (work in draft-ietf-rtgwg-enterprise-pa-multihoming-02 (work in
progress), July 2017. progress), October 2017.
[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 16, line 38 skipping to change at page 17, line 19
[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>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>.
Appendix A. Change Log Appendix A. Change Log
Initial Version: July 2017 Initial Version: July 2017
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
Email: max@stucchi.ch Email: max@stucchi.ch
 End of changes. 20 change blocks. 
34 lines changed or deleted 61 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/