draft-ietf-rtgwg-enterprise-pa-multihoming-03.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-04.txt 
Routing Working Group F. Baker Routing Working Group F. Baker
Internet-Draft Internet-Draft
Intended status: Informational C. Bowers Intended status: Informational C. Bowers
Expires: August 31, 2018 Juniper Networks Expires: October 15, 2018 Juniper Networks
J. Linkova J. Linkova
Google Google
February 27, 2018 April 13, 2018
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-03 draft-ietf-rtgwg-enterprise-pa-multihoming-04
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 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 October 15, 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 3, line 24 skipping to change at page 3, line 24
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 . . . . . . . . . . . . . 40 4.7. Other Configuration Parameters . . . . . . . . . . . . . 40
4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40 4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40
5. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 41 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 41
5.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 42
5.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42 6.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
[RFC6296] describes a translation solution specifically tailored to [RFC6296] describes a translation solution specifically tailored to
meet the requirements of multi-homing with provider-assigned IPv6 meet the requirements of multi-homing with provider-assigned IPv6
addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6)
solution, within the site an enterprise can use Unique Local solution, within the site an enterprise can use Unique Local
Addresses [RFC4193] or the prefix assigned by one of the ISPs. As Addresses [RFC4193] or the prefix assigned by one of the ISPs. As
traffic leaves the site on an uplink to an ISP, the source address traffic leaves the site on an uplink to an ISP, the source address
gets translated to an address within the prefix assigned by the ISP gets translated to an address within the prefix assigned by the ISP
on that uplink in a predictable and reversible manner. [RFC6296] is on that uplink in a predictable and reversible manner. [RFC6296] is
currently classified as Experimental, and it has been implemented by currently classified as Experimental, and it has been implemented by
several vendors. See Section 5.2, for more discussion of NPTv6. several vendors. See Section 6.2, for more discussion of NPTv6.
This document defines routing requirements for enterprise multihoming This document defines routing requirements for enterprise multihoming
using provider-assigned IPv6 addresses. We have made no attempt to using provider-assigned IPv6 addresses. We have made no attempt to
write these requirements in a manner that is agnostic to potential write these requirements in a manner that is agnostic to potential
solutions. Instead, this document focuses on the following general solutions. Instead, this document focuses on the following general
class of solutions. class of solutions.
Each host at the enterprise has multiple addresses, at least one from Each host at the enterprise has multiple addresses, at least one from
each ISP-assigned prefix. Each host, as discussed in Section 4.1 and each ISP-assigned prefix. Each host, as discussed in Section 4.1 and
[RFC6724], is responsible for choosing the source address applied to [RFC6724], is responsible for choosing the source address applied to
skipping to change at page 40, line 13 skipping to change at page 40, line 13
Redirects as discussed in [RFC8028]. Redirects as discussed in [RFC8028].
4.7. Other Configuration Parameters 4.7. Other Configuration Parameters
4.7.1. DNS Configuration 4.7.1. DNS Configuration
In mutihomed envinronment each ISP might provide their own list of In mutihomed envinronment each ISP might provide their own list of
DNS servers. E.g. in the topology show on Figure 3, ISP-A might DNS servers. E.g. in the topology show on Figure 3, ISP-A might
provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B
might provide H61 2001:db8:0:6666::61 as a recursive DNS server. might provide H61 2001:db8:0:6666::61 as a recursive DNS server.
[RFC6106] defines IPv6 Router Advertisement options to allow IPv6 [RFC8106] defines IPv6 Router Advertisement options to allow IPv6
routers to advertise a list of DNS recursive server addresses and a routers to advertise a list of DNS recursive server addresses and a
DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped' DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped'
RAs as described above would allow a first-hop router (R3 in the RAs as described above would allow a first-hop router (R3 in the
Figure 3) to send DNS server addresses and search lists provided by Figure 3) to send DNS server addresses and search lists provided by
each ISP (or the corporate DNS servers addresses if the enterprise is each ISP (or the corporate DNS servers addresses if the enterprise is
running its own DNS servers). running its own DNS servers).
As discussed in Section 4.5.2, failure of all ISP uplinks would cause As discussed in Section 4.5.2, failure of all ISP uplinks would cause
deprecaction of all addresses assigned to a host from the address deprecaction of all addresses assigned to a host from the address
space if all ISPs. If any intra-site IPv6 connectivity is still space if all ISPs. If any intra-site IPv6 connectivity is still
skipping to change at page 41, line 22 skipping to change at page 41, line 22
hop and then chose 2001:db8:0:a010::31 as the source address for hop and then chose 2001:db8:0:a010::31 as the source address for
packets to the DNS server. packets to the DNS server.
It should be noted that [RFC6106] explicitly prohibits using DNS It should be noted that [RFC6106] explicitly prohibits using DNS
information if the RA router Lifetime expired: "An RDNSS address or a information if the RA router Lifetime expired: "An RDNSS address or a
DNSSL domain name MUST be used only as long as both the RA router DNSSL domain name MUST be used only as long as both the RA router
Lifetime (advertised by a Router Advertisement message) and the Lifetime (advertised by a Router Advertisement message) and the
corresponding option Lifetime have not expired.". Therefore hosts corresponding option Lifetime have not expired.". Therefore hosts
might ignore RDNSS information provided in ULA-scoped RAs as those might ignore RDNSS information provided in ULA-scoped RAs as those
RAs would have router lifetime set to 0. However the updated version RAs would have router lifetime set to 0. However the updated version
of RFC6106 ([I-D.ietf-6man-rdnss-rfc6106bis]) has that requirement of RFC6106 ([RFC8106]) has that requirement removed.
removed.
5. Other Solutions 5. Deployment Considerations
5.1. Shim6 The solution described in this document requires certain mechanisms
to be supported by the network infrastructure and hosts. It requires
some routers in the enterprise site to support some form of Source
Address Dependent Routing (SADR). It also requires hosts to be able
to learn when the uplink to an ISP chages its state so the
corresponding source addresses should (or should not) be used.
Ongoing work to create mechanisms to accomplish this are discussed in
this document, but they are still a work in progress.
The solution discussed in this document relies on the default address
selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] consideres
this rule as optional, the recent [RFC8028] recommends that a host
SHOULD select default routers for each prefix in which it is assigned
an address. It also recommends that hosts SHOULD implement Rule 5.5.
of [RFC6724]. Therefore while RFC8028-compliant hosts already have
mechanism to learn about ISP uplinks state changes and selecting the
source addresses accordingly, many hosts do not have such mechanism
supported yet.
It should be noted that multihomed enterprise network utilizing
multipe ISP prefixes can be considered as a typical mutiple
provisioning domain (mPVD) scenario, as desribed in [RFC7556]. This
document defines a way for network to provide the PVD information to
hosts indirectly, using the existing mechanisms. At the same time
[I-D.ietf-intarea-provisioning-domains]takes one step further and
describes a comprehensive mechanism for hosts to discover the whole
set of configuration information associated with different PVD/ISPs.
[I-D.ietf-intarea-provisioning-domains] complements this document in
terms of making hosts being able to learn about ISP uplink states and
selecting the corresponding source addresses.
6. Other Solutions
6.1. Shim6
The Shim6 working group specified the Shim6 protocol [RFC5533] which The Shim6 working group specified the Shim6 protocol [RFC5533] which
allows a host at a multihomed site to communicate with an external allows a host at a multihomed site to communicate with an external
host and exchange information about possible source and destination host and exchange information about possible source and destination
address pairs that they can use to communicate. It also specified address pairs that they can use to communicate. It also specified
the REAP protocol [RFC5534] to detect failures in the path between the REAP protocol [RFC5534] to detect failures in the path between
working address pairs and find new working address pairs. A working address pairs and find new working address pairs. A
fundamental requirement for Shim6 is that both internal and external fundamental requirement for Shim6 is that both internal and external
hosts need to support Shim6. That is, both the host internal to the hosts need to support Shim6. That is, both the host internal to the
multihomed site and the host external to the multihomed site need to multihomed site and the host external to the multihomed site need to
support Shim6 in order for there to be any benefit for the internal support Shim6 in order for there to be any benefit for the internal
host to run Shim6. The Shim6 protocol specification was published in host to run Shim6. The Shim6 protocol specification was published in
2009, but it has not been implemented on widely used operating 2009, but it has not been widely implemented. Therefore Shim6 is not
systems. considered as a viable solution for enterprise multihoming.
We do not consider Shim6 to be a viable solution. It suffers from
the fact that it requires widespread deployment of Shim6 on hosts all
over the Internet before the host at a PA multihomed site sees
significant benefit. However, there appears to be no motivation for
the vast majority of hosts on the Internet (which are not at PA
multihomed sites) to deploy Shim6. This may help explain why Shim6
has not been widely implemented.
5.2. IPv6-to-IPv6 Network Prefix Translation 6.2. IPv6-to-IPv6 Network Prefix Translation
IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the
focus of this document. This document describes a solution where a focus of this document. NPTv6 suffers from the same fundamental
host in a multihomed site determines which ISP a packet will be sent issue as any other address translation approaches: it breaks end-to-
to based on the source address it applies to the packet. This end connectivity. Therefore NPTv6 is not considered as desirable
solution has many moving parts. It requires some routers in the solution and this document intentionally focuses on solving
enterprise site to support some form of Source Address Dependent enterprise multihoming problem without any form of address
Routing (SADR). It requires a host to be able to learn when the translations.
uplink to an ISP fails so that it can stop using the source address
corresponding to that ISP. Ongoing work to create mechanisms to
accomplish this are discussed in this document, but they are still a
work in progress.
This document attempts to create a PA multihoming solution that is as With increasing interest and ongoing work in bringing path awareness
easy as possible for an enterprise to deploy. However, the success to transport and application layer protocols hosts migth be able to
of this solution will depend greatly on whether or not the mechanisms determine the properties of the various network paths and choose
for hosts to select source addresses based on the state of ISP among paths available to them. As selecting the correct source
uplinks gets implemented across a wide range of operating systems as address is one of the possible mechanisms path-aware hosts may
the default mode of operation. Until that occurs, NPTv6 should still utilize, address translation negatively affects hosts path-awareness
be considered a viable option to enable PA multihoming for which makes NTPv6 even more undesirable solution.
enterprises.
6. IANA Considerations 7. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
7. Security Considerations 8. Security Considerations
7.1. Privacy Considerations 8.1. Privacy Considerations
8. Acknowledgements 9. Acknowledgements
The original outline was suggested by Ole Troan. The original outline was suggested by Ole Troan.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
skipping to change at page 44, line 28 skipping to change at page 44, line 50
[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>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>.
[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>.
9.2. Informative References [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<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>.
10.2. Informative References
[I-D.baker-ipv6-isis-dst-src-routing] [I-D.baker-ipv6-isis-dst-src-routing]
Baker, F. and D. Lamparter, "IPv6 Source/Destination Baker, F. and D. Lamparter, "IPv6 Source/Destination
Routing using IS-IS", draft-baker-ipv6-isis-dst-src- Routing using IS-IS", draft-baker-ipv6-isis-dst-src-
routing-07 (work in progress), July 2017. routing-07 (work in progress), July 2017.
[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),
skipping to change at page 45, line 10 skipping to change at page 45, line 43
[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-03 (work in Babel", draft-boutier-babel-source-specific-03 (work in
progress), July 2017. progress), July 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-intarea-provisioning-domains]
Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, Pfister, P., Vyncke, E., Pauly, T., and D. Schinazi,
"IPv6 Router Advertisement Options for DNS Configuration", "Discovering Provisioning Domain Names and Data", draft-
draft-ietf-6man-rdnss-rfc6106bis-16 (work in progress), ietf-intarea-provisioning-domains-01 (work in progress),
February 2017. February 2018.
[I-D.ietf-mif-mpvd-arch] [I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
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.
 End of changes. 23 change blocks. 
61 lines changed or deleted 96 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/