draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05.txt   draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.txt 
Internet Engineering Task Force O. Troan, Ed. Internet Engineering Task Force O. Troan, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational D. Miles Intended status: Informational D. Miles
Expires: September 19, 2013 Alcatel-Lucent Expires: August 18, 2014 Alcatel-Lucent
S. Matsushima S. Matsushima
Softbank Telecom Softbank Telecom
T. Okimoto T. Okimoto
NTT West NTT West
D. Wing D. Wing
Cisco Cisco
March 18, 2013 February 14, 2014
IPv6 Multihoming without Network Address Translation IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06
Abstract Abstract
Network Address and Port Translation (NAPT) works well for conserving Network Address and Port Translation (NAPT) works well for conserving
global addresses and addressing multihoming requirements, because an global addresses and addressing multihoming requirements, because an
IPv4 NAPT router implements three functions: source address IPv4 NAPT router implements three functions: source address
selection, next-hop resolution and optionally DNS resolution. For selection, next-hop resolution and optionally DNS resolution. For
IPv6 hosts one approach could be the use of NPTv6. However, NAT IPv6 hosts one approach could be the use of NPTv6. However, NAT
should be avoided, if at all possible, to permit transparent end-to- should be avoided, if at all possible, to permit transparent end-to-
end connectivity. In this document, we analyze the use cases of end connectivity. In this document, we analyze the use cases of
multihoming. We also describe functional requirements and possible multihoming. We also describe functional requirements and possible
solutions for multihoming without the use of NAT in IPv6 for hosts solutions for multihoming without the use of NAT in IPv6 for hosts
and small IPv6 networks that would otherwise be unable to meet and small IPv6 networks that would otherwise be unable to meet
minimum IPv6 allocation criteria. We conclude that DHCPv6 based minimum IPv6 allocation criteria. We conclude that DHCPv6 based
solutions are suitable to solve the multihoming issues, described in solutions are suitable to solve the multihoming issues, described in
this document, while NPTv6 may be required as an intermediate this document, while NPTv6 may be required as an intermediate
solution. solution.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 19, 2013. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 6 3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 5
3.1. Classification of network scenarios for multihomed host . 6 3.1. Classification of network scenarios for multihomed host . 5
3.2. Multihomed network environment . . . . . . . . . . . . . . 9 3.2. Multihomed network environment . . . . . . . . . . . . . 7
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 10 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 11 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 10
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10
5. Problem statement and analysis . . . . . . . . . . . . . . . . 12 5. Problem statement and analysis . . . . . . . . . . . . . . . 10
5.1. Source address selection . . . . . . . . . . . . . . . . . 12 5.1. Source address selection . . . . . . . . . . . . . . . . 10
5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 13 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . 11
5.3. DNS recursive name server selection . . . . . . . . . . . 13 5.3. DNS recursive name server selection . . . . . . . . . . . 12
6. Implementation approach . . . . . . . . . . . . . . . . . . . 14 6. Implementation approach . . . . . . . . . . . . . . . . . . . 12
6.1. Source address selection . . . . . . . . . . . . . . . . . 14 6.1. Source address selection . . . . . . . . . . . . . . . . 12
6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 15 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . 13
6.3. DNS recursive name server selection . . . . . . . . . . . 15 6.3. DNS recursive name server selection . . . . . . . . . . . 13
6.4. Other algorithms available in RFCs . . . . . . . . . . . . 16 6.4. Other algorithms available in RFCs . . . . . . . . . . . 14
7. Considerations for MHMP deployment . . . . . . . . . . . . . . 16 7. Considerations for MHMP deployment . . . . . . . . . . . . . 14
7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17 7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 15
7.2. Co-existence considerations . . . . . . . . . . . . . . . 17 7.2. Co-existence considerations . . . . . . . . . . . . . . . 15
7.3. Policy collision consideration . . . . . . . . . . . . . . 18 7.3. Policy collision consideration . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
In this document, we analyze the use cases of multihoming, describe In this document, we analyze the use cases of multihoming, describe
functional requirements and the problems with IPv6 multihoming. functional requirements and the problems with IPv6 multihoming.
There are two ways to avoid the problems of IPv6 multihoming: There are two ways to avoid the problems of IPv6 multihoming:
1. IPv6 network prefix translation (NPTv6, [RFC6296]), or; 1. IPv6 network prefix translation (NPTv6, [RFC6296]), or;
2. refining IPv6 specifications to resolve the problems with IPv6 2. refining IPv6 specifications to resolve the problems with IPv6
skipping to change at page 12, line 35 skipping to change at page 10, line 42
This section reviews the problem statements presented above and the This section reviews the problem statements presented above and the
proposed functional requirements to resolve the issues. proposed functional requirements to resolve the issues.
5.1. Source address selection 5.1. Source address selection
A multihomed IPv6 host will typically have different addresses A multihomed IPv6 host will typically have different addresses
assigned from each service provider either on the same link assigned from each service provider either on the same link
(scenarios 1 & 2) or different links (scenario 3). When the host (scenarios 1 & 2) or different links (scenario 3). When the host
wishes to send a packet to any given destination, the current source wishes to send a packet to any given destination, the current source
address selection rules [RFC3484] may not deterministically select address selection rules [RFC6724] may not deterministically select
the correct source address. the correct source address. [RFC7078] describes the use of the
[I-D.ietf-6man-addr-select-considerations] describes the use of the policy table [RFC6724] to resolve this problem, using a DHCPv6
policy table [RFC3484] to resolve this problem, but there is no mechanism for host policy table management.
mechanism defined to disseminate the policy table information to a
host. A proposal is in [I-D.ietf-6man-addr-select-opt] to provide a
DHCPv6 mechanism for host policy table management.
Again, by employing DHCPv6, the server could restrict address Again, by employing DHCPv6, the server could restrict address
assignment (of additional prefixes) only to hosts that support policy assignment (of additional prefixes) only to hosts that support policy
table management. table management.
Scenario 1: "Host" needs to support the solution for this problem. Scenario 1: "Host" needs to support the solution for this problem.
Scenario 2: "Host" needs to support the solution for this problem. Scenario 2: "Host" needs to support the solution for this problem.
Scenario 3: If "Host" support the next-hop selection solution, there Scenario 3: If "Host" support the next-hop selection solution, there
is no need to support the address selection functionality on the is no need to support the address selection functionality on the
host. host.
It is noted that the service providers (i.e., ISP and enterprise/VPN) It is noted that the service providers (i.e., ISP and enterprise/VPN)
must also support [I-D.ietf-6man-addr-select-opt]. must also support [RFC7078].
5.2. Next-hop selection 5.2. Next-hop selection
A multihomed IPv6 host or gateway may have multiple uplinks to A multihomed IPv6 host or gateway may have multiple uplinks to
different service providers. Here each router would use Router different service providers. Here each router would use Router
Advertisements [RFC4861] for distributing default route/next-hop Advertisements [RFC4861] for distributing default route/next-hop
information to the host or gateway router. information to the host or gateway router.
In this case, the host or gateway router may select any valid default In this case, the host or gateway router may select any valid default
router from the default routers list, resulting in traffic being sent router from the default routers list, resulting in traffic being sent
skipping to change at page 14, line 44 skipping to change at page 12, line 51
6. Implementation approach 6. Implementation approach
As mentioned in Section 5, in the multi-prefix environment, we have As mentioned in Section 5, in the multi-prefix environment, we have
three problems; source address selection, next-hop selection, and DNS three problems; source address selection, next-hop selection, and DNS
recursive name server selection. In this section, possible solutions recursive name server selection. In this section, possible solutions
for each problem are introduced and evaluated against the for each problem are introduced and evaluated against the
requirements in Section 4. requirements in Section 4.
6.1. Source address selection 6.1. Source address selection
Possible solutions and their evaluation are summarized in The problems of address selection in multi-prefix environments are
[I-D.ietf-6man-addr-select-considerations]. When those solutions are summarized in [RFC5220]. When solutions are examined against the
examined against the requirements in Section 4, the proactive requirements in Section 4, the proactive approaches, such as the
approaches, such as the policy table distribution mechanism and the policy table distribution mechanism and the routing hints mechanism,
routing hints mechanism, are more appropriate in that they can are more appropriate in that they can propagate the network
propagate the network administrator's policy directly. The policy administrator's policy directly. The policy distribution mechanism
distribution mechanism has an advantage with regard to the host's has an advantage with regard to the host's protocol stack impact and
protocol stack impact and the static nature of the assumed target the static nature of the assumed target network environment.
network environment.
6.2. Next-hop selection 6.2. Next-hop selection
As for the source address selection problem, both a policy-based As for the source address selection problem, both a policy-based
approach and a non policy-based approach are possible with regard to approach and a non policy-based approach are possible with regard to
the next-hop selection problem. Because of the same requirements, the next-hop selection problem. Because of the same requirements,
the policy propagation-based solution mechanism, whatever the policy, the policy propagation-based solution mechanism, whatever the policy,
should be more appropriate. should be more appropriate.
Routing information is a typical example of policy related to next- Routing information is a typical example of policy related to next-
skipping to change at page 17, line 14 skipping to change at page 15, line 16
7.1. Non-MHMP host consideration 7.1. Non-MHMP host consideration
In a typical IPv4 multihomed network deployment, IPv4 NAPT is In a typical IPv4 multihomed network deployment, IPv4 NAPT is
practically used and it can eventually avoid assigning multiple practically used and it can eventually avoid assigning multiple
addresses to the hosts and solve the next-hop selection problem. In addresses to the hosts and solve the next-hop selection problem. In
a similar fashion, NPTv6 can be used as a last resort for IPv6 a similar fashion, NPTv6 can be used as a last resort for IPv6
multihomed network deployments where one needs to assign a single multihomed network deployments where one needs to assign a single
IPv6 address to a non-MHMP host. IPv6 address to a non-MHMP host.
__________ __________
/ \ / \
+---/ Internet \ +---/ Internet \
gateway router | \ / gateway router | \ /
+------+ +---------------------+ | \__________/ +------+ +---------------------+ | \__________/
| | | | | WAN1 +--+ | | | | | WAN1 +--+
| host |-----|LAN| Router |--------| | host |-----|LAN| Router |--------|
| | | | |NAT|WAN2+--+ | | | | |NAT|WAN2+--+
+------+ +---------------------+ | __________ +------+ +---------------------+ | __________
| / \ | / \
+---/ ASP \ +---/ ASP \
\ / \ /
\__________/ \__________/
Figure 5: Legacy Host Figure 5: Legacy Host
The gateway router also has to support the two features, next-hop The gateway router also has to support the two features, next-hop
selection and DNS server selection, shown in Section 6. selection and DNS server selection, shown in Section 6.
The implementation and issues of NPTv6 are out of the scope of this The implementation and issues of NPTv6 are out of the scope of this
document. They may be covered by another document under discussion document. They may be covered by another document under discussion
[RFC6296]. [RFC6296].
skipping to change at page 20, line 43 skipping to change at page 18, line 47
Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki,
Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley,
Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has
greatly benefited from inputs by Randy Bush, Brian Carpenter, and greatly benefited from inputs by Randy Bush, Brian Carpenter, and
Teemu Savolainen. Teemu Savolainen.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-6man-addr-select-considerations]
Chown, T. and A. Matsumoto, "Considerations for IPv6
Address Selection Policy Changes",
draft-ietf-6man-addr-select-considerations-04 (work in
progress), October 2011.
[I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-08 (work in progress),
January 2013.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[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,
September 2007. September 2007.
[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, June 2011. Translation", RFC 6296, June 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, December 2012. Nodes", RFC 6731, December 2012.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078, January
2014.
11.2. Informative References 11.2. Informative References
[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, January
January 2001. 2001.
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless
Static Route Option for Dynamic Host Configuration Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002. Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003. Multihoming Architectures", RFC 3582, August 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[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
RFC 4116, July 2005. 4116, July 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005. Multihoming Solutions", RFC 4218, October 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
RFC 4960, September 2007. 4960, September 2007.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008. Protocol", RFC 5206, April 2008.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
[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, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010.
[TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol [TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol
v1.1, Version: Issue 1 Amendment 2", December 2007. v1.1, Version: Issue 1 Amendment 2", December 2007.
 End of changes. 18 change blocks. 
86 lines changed or deleted 80 lines changed or added

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