draft-ietf-v6ops-conditional-ras-06.txt   draft-ietf-v6ops-conditional-ras-07.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: February 2, 2019 RIPE NCC Expires: February 11, 2019 RIPE NCC
August 1, 2018 August 10, 2018
Using Conditional Router Advertisements for Enterprise Multihoming Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-06 draft-ietf-v6ops-conditional-ras-07
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 and how the approach proposed in the "ietf-rtgwg- by an ISP and how the approach proposed in the "ietf-rtgwg-
enterprise-pa-multihoming" draft could be applied in those scenarios. enterprise-pa-multihoming" draft could be applied in those scenarios.
The problem of enterprise multihoming without address translation of The problem of enterprise multihoming without address translation of
any form has not been solved yet as it requires both the network to any form has not been solved yet as it requires both the network to
select the correct egress ISP based on the packet source address and select the correct egress ISP based on the packet source address and
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 February 11, 2019.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 7 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8
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 . . . . 12
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 . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Routing Packets when the Corresponding Uplink is 3.2.8. Routing Packets when the Corresponding Uplink is
Unavailable . . . . . . . . . . . . . . . . . . . . . 15 Unavailable . . . . . . . . . . . . . . . . . . . . . 16
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16
3.3.1. Connections Preservation . . . . . . . . . . . . . . 16 3.3.1. Connections Preservation . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 17 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 5, line 37 skipping to change at page 5, line 37
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. 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], [RFC3704]).
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) (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest way (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest way
to implement the desired functionality currently is to apply a policy to implement the desired functionality currently is to apply a policy
which selects a next-hop or an egress interface based on the packet which selects a next-hop or an egress interface based on the 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
skipping to change at page 6, line 36 skipping to change at page 6, line 36
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.
It should be notes that only preferred lifetime for the affected
prefix needs to be changed. As the goal is to influence the source
address selection algoorithm on hosts, not preventing them from
forming addresses from a specific prefix, the valid lifetime should
not be changed. Actually it would not even be possible as
Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime
for addresses to zero.
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
RA field (e.g. PIO preferred lifetime) based on the uplink RA field (e.g. PIO preferred lifetime) based on the uplink
status. status.
skipping to change at page 10, line 26 skipping to change at page 10, line 46
In this case there is more than one way to ensure that hosts are In this case there is more than one way to ensure that hosts are
selecting the correct source address based on the uplink status. If selecting the correct source address based on the uplink status. If
VRRP is used to provide first-hop redundancy and the master router is VRRP is used to provide first-hop redundancy and the master router is
the one with the active uplink, then the simplest way is to use the the one with the active uplink, then the simplest way is to use the
VRRP mastership as a condition for router advertisement. So, if VRRP mastership as a condition for router advertisement. So, if
ISP_A is the primary uplink, the routers R1 and R2 need to be ISP_A is the primary uplink, the routers R1 and R2 need to be
configured in the following way: configured in the following way:
R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A
uplink is down, then R1 becomes a backup. Router advertisements on uplink is down, then R1 becomes a backup (the VRRP interface status
R1's interface facing H1 needs to have the following policy applied: tracking is expected to be used to automatically modify the VRRP
priorities and trigger the mastership switchover). Router
advertisements on R1's interface facing H1 needs to have the
following policy applied:
prefix 2001:db8:1:1::/64 { prefix 2001:db8:1:1::/64 {
IF (vrrp_master) IF (vrrp_master)
THEN THEN
preferred_lifetime = 604800 preferred_lifetime = 604800
ELSE ELSE
preferred_lifetime = 0 preferred_lifetime = 0
} }
R2 is VRRP backup by default. Router advertsement on R2 interface R2 is VRRP backup by default. Router advertsement on R2 interface
skipping to change at page 18, line 26 skipping to change at page 19, line 5
[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>.
[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>.
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
 End of changes. 14 change blocks. 
17 lines changed or deleted 32 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/