draft-ietf-rtgwg-enterprise-pa-multihoming-05.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-06.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: October 15, 2018 Juniper Networks Expires: November 16, 2018 Juniper Networks
J. Linkova J. Linkova
Google Google
April 13, 2018 May 15, 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-05 draft-ietf-rtgwg-enterprise-pa-multihoming-06
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 October 15, 2018. This Internet-Draft will expire on November 16, 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 28 skipping to change at page 3, line 28
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. Deployment Considerations . . . . . . . . . . . . . . . . . . 41 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 41
6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 42 6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 42
6.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42 6.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 43
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43 10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
Site multihoming, the connection of a subscriber network to multiple Site multihoming, the connection of a subscriber network to multiple
skipping to change at page 41, line 15 skipping to change at page 41, line 15
For example, if it is desirable that host H31 reaches the ISP-A DNS For example, if it is desirable that host H31 reaches the ISP-A DNS
server H51 2001:db8:0:5555::51 using its source address server H51 2001:db8:0:5555::51 using its source address
2001:db8:0:a010::31, then both R1 and R2 should send the RIO 2001:db8:0:a010::31, then both R1 and R2 should send the RIO
containing the route to 2001:db8:0:5555::51 (or covering route) in containing the route to 2001:db8:0:5555::51 (or covering route) in
their 'scoped' RAs, containing LLA_A as the default router address their 'scoped' RAs, containing LLA_A as the default router address
and the PO for SLAAC prefix 2001:db8:0:a010::/64. In that case the and the PO for SLAAC prefix 2001:db8:0:a010::/64. In that case the
host H31 (if it supports the Rule 5.5) would select LLA_A as a next- host H31 (if it supports the Rule 5.5) would select LLA_A as a next-
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 [RFC8106] 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 ([RFC8106]) has that requirement removed. of RFC6106 ([RFC8106]) has that requirement removed.
5. Deployment Considerations 5. Deployment Considerations
skipping to change at page 42, line 45 skipping to change at page 42, line 45
translations. translations.
With increasing interest and ongoing work in bringing path awareness With increasing interest and ongoing work in bringing path awareness
to transport and application layer protocols hosts migth be able to to transport and application layer protocols hosts migth be able to
determine the properties of the various network paths and choose determine the properties of the various network paths and choose
among paths available to them. As selecting the correct source among paths available to them. As selecting the correct source
address is one of the possible mechanisms path-aware hosts may address is one of the possible mechanisms path-aware hosts may
utilize, address translation negatively affects hosts path-awareness utilize, address translation negatively affects hosts path-awareness
which makes NTPv6 even more undesirable solution. which makes NTPv6 even more undesirable solution.
6.3. Multipath Transport
Using multipath transport might solve the problems discussed in
Section 4 it would allow hosts to use multiple source addresses for a
single connection and switch between source addresses when a
particular address becomes unavailable or a new address gets assigned
to the host interface. Therefore if all hosts in the enterprise
network are only using multipath transport for all connections, the
signalling solution described in Section 4 migth not be needed (it
should be noted that the Source Address Dependent Routing would still
be required to delver packets to the correct uplinks). Unfortunatelt
when this document was written, mutlipath transport alone can not be
considered a solition for the problem of selecting the source address
in a multihomed envinronments. There are significant number of hosts
which do not use mulipath transport currently and it seems unlikely
that the situation is going to change in any foreseeable future. As
the solution for enterprise multihoming needs to work for the least
common denominator: hosts without multipath transport support. In
addition, not all protocols are using multipath transport. While
multipath transport would complement the solution described in
Section 4, it could not be considered as a sole solution to the
problem of source address selection in multihomed envinronments.
7. IANA Considerations 7. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
8. Security Considerations 8. Security Considerations
8.1. Privacy Considerations This document introduces no new security or privacy considerations.
Security considerations of using stateless address autoconfiguration
is discussed in [RFC4862].
9. Acknowledgements 9. Acknowledgements
The original outline was suggested by Ole Troan. The original outline was suggested by Ole Troan.
The authors would like to thank the following people (in alphabetical The authors would like to thank the following people (in alphabetical
order) for their review and feedback: Brian E Carpenter, Lorenzo order) for their review and feedback: Olivier Bonaventure, Brian E
Colitti, David Lamparter, Acee Lindem, Philip Matthewsu, Dave Thaler. Carpenter, Lorenzo Colitti, David Lamparter, Acee Lindem, Philip
Matthewsu, Robert Raszuk, Dave Thaler.
10. References 10. References
10.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>.
skipping to change at page 43, line 41 skipping to change at page 44, line 15
[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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[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>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
skipping to change at page 44, line 41 skipping to change at page 45, line 10
[RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers
Should Think About", RFC 4219, DOI 10.17487/RFC4219, Should Think About", RFC 4219, DOI 10.17487/RFC4219,
October 2005, <https://www.rfc-editor.org/info/rfc4219>. October 2005, <https://www.rfc-editor.org/info/rfc4219>.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November
2005, <https://www.rfc-editor.org/info/rfc4242>. 2005, <https://www.rfc-editor.org/info/rfc4242>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, DOI 10.17487/RFC6106, November 2010,
<https://www.rfc-editor.org/info/rfc6106>.
[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 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
skipping to change at page 46, line 11 skipping to change at page 46, line 21
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-intarea-provisioning-domains] [I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., and D. Schinazi, Pfister, P., Vyncke, E., Pauly, T., and D. Schinazi,
"Discovering Provisioning Domain Names and Data", draft- "Discovering Provisioning Domain Names and Data", draft-
ietf-intarea-provisioning-domains-01 (work in progress), ietf-intarea-provisioning-domains-01 (work in progress),
February 2018. February 2018.
[I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture",
draft-ietf-mif-mpvd-arch-11 (work in progress), March
2015.
[I-D.ietf-mptcp-experience]
Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
Operational Experience with Multipath TCP", draft-ietf-
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-06 (work in Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in
progress), October 2017. progress), October 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.
skipping to change at page 47, line 35 skipping to change at page 47, line 35
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <https://www.rfc-editor.org/info/rfc5533>. June 2009, <https://www.rfc-editor.org/info/rfc5533>.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming", Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, DOI 10.17487/RFC5534, June 2009, RFC 5534, DOI 10.17487/RFC5534, June 2009,
<https://www.rfc-editor.org/info/rfc5534>. <https://www.rfc-editor.org/info/rfc5534>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078, Address Selection Policy Using DHCPv6", RFC 7078,
DOI 10.17487/RFC7078, January 2014, DOI 10.17487/RFC7078, January 2014,
<https://www.rfc-editor.org/info/rfc7078>. <https://www.rfc-editor.org/info/rfc7078>.
[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>.
[RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
Operational Experience with Multipath TCP", RFC 8041,
DOI 10.17487/RFC8041, January 2017,
<https://www.rfc-editor.org/info/rfc8041>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
Appendix A. Change Log Appendix A. Change Log
Initial Version: July 2016 Initial Version: July 2016
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
 End of changes. 15 change blocks. 
33 lines changed or deleted 46 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/