draft-ietf-rtgwg-enterprise-pa-multihoming-00.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-01.txt 
Routing Working Group F. Baker Routing Working Group F. Baker
Internet-Draft Cisco Systems Internet-Draft
Intended status: Informational C. Bowers Intended status: Informational C. Bowers
Expires: September 14, 2017 Juniper Networks Expires: January 3, 2018 Juniper Networks
J. Linkova J. Linkova
Google Google
March 13, 2017 July 2, 2017
Enterprise Multihoming using Provider-Assigned Addresses without Network Enterprise Multihoming using Provider-Assigned Addresses without Network
Prefix Translation: Requirements and Solution Prefix Translation: Requirements and Solution
draft-ietf-rtgwg-enterprise-pa-multihoming-00 draft-ietf-rtgwg-enterprise-pa-multihoming-01
Abstract Abstract
Connecting an enterprise site to multiple ISPs using provider- Connecting an enterprise site to multiple ISPs using provider-
assigned addresses is difficult without the use of some form of assigned addresses is difficult without the use of some form of
Network Address Translation (NAT). Much has been written on this Network Address Translation (NAT). Much has been written on this
topic over the last 10 to 15 years, but it still remains a problem topic over the last 10 to 15 years, but it still remains a problem
without a clearly defined or widely implemented solution. Any without a clearly defined or widely implemented solution. Any
multihoming solution without NAT requires hosts at the site to have multihoming solution without NAT requires hosts at the site to have
addresses from each ISP and to select the egress ISP by selecting a addresses from each ISP and to select the egress ISP by selecting a
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 14, 2017. This Internet-Draft will expire on January 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 48 skipping to change at page 2, line 48
4.1. Source Address Selection Algorithm on Hosts . . . . . . . 23 4.1. Source Address Selection Algorithm on Hosts . . . . . . . 23
4.2. Selecting Source Address When Both Uplinks Are Working . 26 4.2. Selecting Source Address When Both Uplinks Are Working . 26
4.2.1. Distributing Address Selection Policy Table with 4.2.1. Distributing Address Selection Policy Table with
DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 26 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.2. Controlling Source Address Selection With Router 4.2.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 26 Advertisements . . . . . . . . . . . . . . . . . . . 26
4.2.3. Controlling Source Address Selection With ICMPv6 . . 28 4.2.3. Controlling Source Address Selection With ICMPv6 . . 28
4.2.4. Summary of Methods For Controlling Source Address 4.2.4. Summary of Methods For Controlling Source Address
Selection To Implement Routing Policy . . . . . . . . 30 Selection To Implement Routing Policy . . . . . . . . 30
4.3. Selecting Source Address When One Uplink Has Failed . . . 31 4.3. Selecting Source Address When One Uplink Has Failed . . . 31
4.3.1. Controlling Source Address Selection With DHCPv6 . . 31 4.3.1. Controlling Source Address Selection With DHCPv6 . . 32
4.3.2. Controlling Source Address Selection With Router 4.3.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 33 Advertisements . . . . . . . . . . . . . . . . . . . 33
4.3.3. Controlling Source Address Selection With ICMPv6 . . 34 4.3.3. Controlling Source Address Selection With ICMPv6 . . 34
4.3.4. Summary Of Methods For Controlling Source Address 4.3.4. Summary Of Methods For Controlling Source Address
Selection On The Failure Of An Uplink . . . . . . . . 34 Selection On The Failure Of An Uplink . . . . . . . . 34
4.4. Selecting Source Address Upon Failed Uplink Recovery . . 35 4.4. Selecting Source Address Upon Failed Uplink Recovery . . 35
4.4.1. Controlling Source Address Selection With DHCPv6 . . 35 4.4.1. Controlling Source Address Selection With DHCPv6 . . 35
4.4.2. Controlling Source Address Selection With Router 4.4.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 35 Advertisements . . . . . . . . . . . . . . . . . . . 35
4.4.3. Controlling Source Address Selection With ICMP . . . 36 4.4.3. Controlling Source Address Selection With ICMP . . . 36
4.4.4. Summary Of Methods For Controlling Source Address 4.4.4. Summary Of Methods For Controlling Source Address
Selection Upon Failed Uplink Recovery . . . . . . . . 36 Selection Upon Failed Uplink Recovery . . . . . . . . 36
4.5. Selecting Source Address When All Uplinks Failed . . . . 36 4.5. Selecting Source Address When All Uplinks Failed . . . . 37
4.5.1. Controlling Source Address Selection With DHCPv6 . . 37 4.5.1. Controlling Source Address Selection With DHCPv6 . . 37
4.5.2. Controlling Source Address Selection With Router 4.5.2. Controlling Source Address Selection With Router
Advertisements . . . . . . . . . . . . . . . . . . . 37 Advertisements . . . . . . . . . . . . . . . . . . . 37
4.5.3. Controlling Source Address Selection With ICMPv6 . . 38 4.5.3. Controlling Source Address Selection With ICMPv6 . . 38
4.5.4. Summary Of Methods For Controlling Source Address 4.5.4. Summary Of Methods For Controlling Source Address
Selection When All Uplinks Failed . . . . . . . . . . 38 Selection When All Uplinks Failed . . . . . . . . . . 38
4.6. Summary Of Methods For Controlling Source Address 4.6. Summary Of Methods For Controlling Source Address
Selection . . . . . . . . . . . . . . . . . . . . . . . . 38 Selection . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7. Other Configuration Parameters . . . . . . . . . . . . . 39 4.7. Other Configuration Parameters . . . . . . . . . . . . . 40
4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 39 4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40
5. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 41 5. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 41
5.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 41 5.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Normative References . . . . . . . . . . . . . . . . . . 42 9.1. Normative References . . . . . . . . . . . . . . . . . . 42
9.2. Informative References . . . . . . . . . . . . . . . . . 44 9.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 46 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
Site multihoming, the connection of a subscriber network to multiple Site multihoming, the connection of a subscriber network to multiple
upstream networks using redundant uplinks, is a common enterprise upstream networks using redundant uplinks, is a common enterprise
architecture for improving the reliability of its Internet architecture for improving the reliability of its Internet
connectivity. If the site uses provider-independent (PI) addresses, connectivity. If the site uses provider-independent (PI) addresses,
all traffic originating from the enterprise can use source addresses all traffic originating from the enterprise can use source addresses
from the PI address space. Site multihoming with PI addresses is from the PI address space. Site multihoming with PI addresses is
commonly used with both IPv4 and IPv6, and does not present any new commonly used with both IPv4 and IPv6, and does not present any new
skipping to change at page 22, line 13 skipping to change at page 22, line 13
hosts to choose the correct source address. We also look at what hosts to choose the correct source address. We also look at what
role, if any, the routers may play in providing information that role, if any, the routers may play in providing information that
helps hosts to choose source addresses. helps hosts to choose source addresses.
Any host that needs to be able to send traffic using the uplinks to a Any host that needs to be able to send traffic using the uplinks to a
given ISP is expected to be configured with an address from the given ISP is expected to be configured with an address from the
prefix assigned by that ISP. The host will control which ISP is used prefix assigned by that ISP. The host will control which ISP is used
for its traffic by selecting one of the addresses configured on the for its traffic by selecting one of the addresses configured on the
host as the source address for outgoing traffic. It is the host as the source address for outgoing traffic. It is the
responsibility of the site network to ensure that a packet with the responsibility of the site network to ensure that a packet with the
source address from an ISP is not sent on an uplink to that ISP. source address from an ISP is now sent on an uplink to that ISP.
If all of the ISP uplinks are working, the choice of source address If all of the ISP uplinks are working, the choice of source address
by the host may be driven by the desire to load share across ISP by the host may be driven by the desire to load share across ISP
uplinks, or it may be driven by the desire to take advantage of uplinks, or it may be driven by the desire to take advantage of
certain properties of a particular uplink or ISP. If any of the ISP certain properties of a particular uplink or ISP. If any of the ISP
uplinks is not working, then the choice of source address by the host uplinks is not working, then the choice of source address by the host
can determine if packets get dropped. can determine if packets get dropped.
How a host should make good decisions about source address selection How a host should make good decisions about source address selection
in a multihomed site is not a solved problem. We do not attempt to in a multihomed site is not a solved problem. We do not attempt to
skipping to change at page 26, line 41 skipping to change at page 26, line 41
does NOT require that the hosts use DHCPv6 for address assignment. does NOT require that the hosts use DHCPv6 for address assignment.
The hosts could still use stateless address autoconfiguration for The hosts could still use stateless address autoconfiguration for
address configuration, while using DHCPv6 only for policy table address configuration, while using DHCPv6 only for policy table
distribution (see [RFC3736]). However this method has a number of distribution (see [RFC3736]). However this method has a number of
disadvantages: disadvantages:
o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so
this method might not work for all devices. this method might not work for all devices.
o Network administrators are required to explicitly configure the o Network administrators are required to explicitly configure the
desired network access policies on DHCPv6 servers. desired network access policies on DHCPv6 servers. While it might
be feasible in the scenarion of a single multihomed network, such
approach might have some scalability issues, especially if the
centralized DHCPv6 solution is deployed to serve a large number of
multiomed sites.
4.2.2. Controlling Source Address Selection With Router Advertisements 4.2.2. Controlling Source Address Selection With Router Advertisements
Neighbor Discovery currently has two mechanisms to communicate prefix Neighbor Discovery currently has two mechanisms to communicate prefix
information to hosts. The base specification for Neighbor Discovery information to hosts. The base specification for Neighbor Discovery
(see [RFC4861]) defines the Prefix Information Option (PIO) in the (see [RFC4861]) defines the Prefix Information Option (PIO) in the
Router Advertisement (RA) message. When a host receives a PIO with Router Advertisement (RA) message. When a host receives a PIO with
the A-flag set, it can use the prefix in the PIO as source prefix the A-flag set, it can use the prefix in the PIO as source prefix
from which it assigns itself an IP address using stateless address from which it assigns itself an IP address using stateless address
autoconfiguration (SLAAC) procedures described in [RFC4862]. In the autoconfiguration (SLAAC) procedures described in [RFC4862]. In the
skipping to change at page 38, line 5 skipping to change at page 38, line 5
when SERb1 lost the uplink to ISP-B (so there is no Internet when SERb1 lost the uplink to ISP-B (so there is no Internet
connectivity from 2001:db8:0:b000::/52 sources) but those sources can connectivity from 2001:db8:0:b000::/52 sources) but those sources can
be used to reach some specific destinations. In the case of ULA be used to reach some specific destinations. In the case of ULA
there is no Internet connectivity from ULA sources but they can be there is no Internet connectivity from ULA sources but they can be
used to reach another ULA destinations. Note that ULA usage could be used to reach another ULA destinations. Note that ULA usage could be
particularly useful if all ISPs assign prefixes via DHCP-PD. In the particularly useful if all ISPs assign prefixes via DHCP-PD. In the
absence of ULAs uplinks failure hosts would lost all their GUAs upon absence of ULAs uplinks failure hosts would lost all their GUAs upon
prefix lifetime expiration which again makes intra-site communication prefix lifetime expiration which again makes intra-site communication
impossible. impossible.
It should be noted that the Rule 5.5 (prefer a prefix advertised by
the selected next-hop) takes precedence over the Rule 6 (prefer
matching label, which ensures that GUA source addresses are preferred
over ULAs for GUA destinations). Therefore if ULAs are used, the
network adminstrator needs to ensure that while the site has an
Internet connectivity, hosts do not select a roter which advertises
ULA prefixes as their default router.
4.5.3. Controlling Source Address Selection With ICMPv6 4.5.3. Controlling Source Address Selection With ICMPv6
In case of all uplinks failure all SERs will drop outgoing IPv6 In case of all uplinks failure all SERs will drop outgoing IPv6
traffic and respond with ICMPv6 error message. In the large network traffic and respond with ICMPv6 error message. In the large network
when many hosts are trying to reach Internet destinations it means when many hosts are trying to reach Internet destinations it means
that SERs need to generate an ICMPv6 error to every packet they that SERs need to generate an ICMPv6 error to every packet they
receive from hosts which presents the same scalability issues receive from hosts which presents the same scalability issues
discussed in Section 4.3.3 discussed in Section 4.3.3
4.5.4. Summary Of Methods For Controlling Source Address Selection When 4.5.4. Summary Of Methods For Controlling Source Address Selection When
skipping to change at page 44, line 29 skipping to change at page 44, line 43
routing-06 (work in progress), October 2016. routing-06 (work in progress), October 2016.
[I-D.baker-rtgwg-src-dst-routing-use-cases] [I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and
Use Cases for Source/Destination Routing", draft-baker- Use Cases for Source/Destination Routing", draft-baker-
rtgwg-src-dst-routing-use-cases-02 (work in progress), rtgwg-src-dst-routing-use-cases-02 (work in progress),
April 2016. April 2016.
[I-D.boutier-babel-source-specific] [I-D.boutier-babel-source-specific]
Boutier, M. and J. Chroboczek, "Source-Specific Routing in Boutier, M. and J. Chroboczek, "Source-Specific Routing in
Babel", draft-boutier-babel-source-specific-01 (work in Babel", draft-boutier-babel-source-specific-02 (work in
progress), May 2015. progress), June 2017.
[I-D.huitema-shim6-ingress-filtering] [I-D.huitema-shim6-ingress-filtering]
Huitema, C., "Ingress filtering compatibility for IPv6 Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites", draft-huitema-shim6-ingress- multihomed sites", draft-huitema-shim6-ingress-
filtering-00 (work in progress), September 2005. filtering-00 (work in progress), September 2005.
[I-D.ietf-6man-rdnss-rfc6106bis] [I-D.ietf-6man-rdnss-rfc6106bis]
Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
draft-ietf-6man-rdnss-rfc6106bis-16 (work in progress), draft-ietf-6man-rdnss-rfc6106bis-16 (work in progress),
skipping to change at page 45, line 7 skipping to change at page 45, line 23
draft-ietf-mif-mpvd-arch-11 (work in progress), March draft-ietf-mif-mpvd-arch-11 (work in progress), March
2015. 2015.
[I-D.ietf-mptcp-experience] [I-D.ietf-mptcp-experience]
Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
Operational Experience with Multipath TCP", draft-ietf- Operational Experience with Multipath TCP", draft-ietf-
mptcp-experience-07 (work in progress), October 2016. mptcp-experience-07 (work in progress), October 2016.
[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-03 (work in Routing", draft-ietf-rtgwg-dst-src-routing-04 (work in
progress), November 2016. progress), May 2017.
[I-D.pfister-6man-sadr-ra] [I-D.pfister-6man-sadr-ra]
Pfister, P., "Source Address Dependent Route Information Pfister, P., "Source Address Dependent Route Information
Option for Router Advertisements", draft-pfister-6man- Option for Router Advertisements", draft-pfister-6man-
sadr-ra-01 (work in progress), June 2015. sadr-ra-01 (work in progress), June 2015.
[I-D.xu-src-dst-bgp] [I-D.xu-src-dst-bgp]
Xu, M., Yang, S., and J. Wu, "Source/Destination Routing Xu, M., Yang, S., and J. Wu, "Source/Destination Routing
Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress), Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress),
March 2016. March 2016.
skipping to change at page 46, line 44 skipping to change at page 47, line 17
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<http://www.rfc-editor.org/info/rfc8028>. <http://www.rfc-editor.org/info/rfc8028>.
Appendix A. Change Log Appendix A. Change Log
Initial Version: July 2016 Initial Version: July 2016
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: fred@cisco.com Email: FredBaker.IETF@gmail.com
Chris Bowers Chris Bowers
Juniper Networks Juniper Networks
Sunnyvale, California 94089 Sunnyvale, California 94089
USA USA
Email: cbowers@juniper.net Email: cbowers@juniper.net
Jen Linkova Jen Linkova
Google Google
Mountain View, California 94043 Mountain View, California 94043
 End of changes. 17 change blocks. 
20 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/