draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-02.txt   draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.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: May 3, 2012 Alcatel-Lucent Expires: May 18, 2012 Alcatel-Lucent
S. Matsushima S. Matsushima
Softbank Telecom Softbank Telecom
T. Okimoto T. Okimoto
NTT West NTT West
D. Wing D. Wing
Cisco Cisco
October 31, 2011 November 15, 2011
IPv6 Multihoming without Network Address Translation IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-02 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03
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
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 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 May 3, 2012. This Internet-Draft will expire on May 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 25 skipping to change at page 3, line 25
4.2. Policy distribution . . . . . . . . . . . . . . . . . . . 12 4.2. Policy distribution . . . . . . . . . . . . . . . . . . . 12
4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
5. Problem statement and analysis . . . . . . . . . . . . . . . . 12 5. Problem statement and analysis . . . . . . . . . . . . . . . . 12
5.1. Source address selection . . . . . . . . . . . . . . . . . 13 5.1. Source address selection . . . . . . . . . . . . . . . . . 13
5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 13 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 13
5.3. DNS recursive name server selection . . . . . . . . . . . 14 5.3. DNS recursive name server selection . . . . . . . . . . . 14
6. Implementation approach . . . . . . . . . . . . . . . . . . . 15 6. Implementation approach . . . . . . . . . . . . . . . . . . . 15
6.1. Source address selection . . . . . . . . . . . . . . . . . 15 6.1. Source address selection . . . . . . . . . . . . . . . . . 15
6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 15 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 15
6.3. DNS recursive name server selection . . . . . . . . . . . 16 6.3. DNS recursive name server selection . . . . . . . . . . . 16
6.4. Other algorithms available in RFCs . . . . . . . . . . . . 17
7. Considerations for MHMP deployment . . . . . . . . . . . . . . 17 7. Considerations for MHMP deployment . . . . . . . . . . . . . . 17
7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17 7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17
7.2. Co-existence consideration . . . . . . . . . . . . . . . . 18 7.2. Co-existence consideration . . . . . . . . . . . . . . . . 18
7.3. Policy collision consideration . . . . . . . . . . . . . . 18 7.3. Policy collision consideration . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
IPv6 provides enough globally unique addresses to permit every IPv6 provides enough globally unique addresses to permit every
conceivable host on the Internet to be uniquely addressed without the conceivable host on the Internet to be uniquely addressed without the
requirement for Network Address Port Translation (NAPT [RFC3022]), requirement for Network Address Port Translation (NAPT [RFC3022]),
offering a renaissance in end-to-end transparent connectivity. offering a renaissance in end-to-end transparent connectivity.
Unfortunately, this may not be possible in every case, due to the Unfortunately, this may not be possible in every case, due to the
possible necessity of NAT even in IPv6, because of multihoming. possible necessity of NAT even in IPv6, because of multihoming.
skipping to change at page 17, line 15 skipping to change at page 17, line 15
The alternative of a policy-based approach is documented in The alternative of a policy-based approach is documented in
[I-D.ietf-mif-dns-server-selection], where several pairs of DNS [I-D.ietf-mif-dns-server-selection], where several pairs of DNS
recursive name server addresses and DNS domain suffixes are defined recursive name server addresses and DNS domain suffixes are defined
as part of a policy and conveyed to hosts in a new DHCP option. In as part of a policy and conveyed to hosts in a new DHCP option. In
an environment where there is a home gateway router, that router can an environment where there is a home gateway router, that router can
act as a DNS recursive name server, interpret this option and act as a DNS recursive name server, interpret this option and
distribute DNS queries to the appropriate DNS servers according to distribute DNS queries to the appropriate DNS servers according to
the policy. the policy.
6.4. Other algorithms available in RFCs
The authors of this document are aware of a variety of other
algorithms and architectures, such as shim6 [RFC5533] and HIP
[RFC5206], that may be useful in this environment. At this writing,
there is not enough operational experience on which to base a
recommendation. Should such operational experience become available,
this document may be updated in the future.
7. Considerations for MHMP deployment 7. Considerations for MHMP deployment
This section describes considerations to mitigate possible problem in This section describes considerations to mitigate possible problem in
a network which implements MHMP described in Section 6. a network which implements MHMP described in Section 6.
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
skipping to change at page 21, line 10 skipping to change at page 21, line 31
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] [I-D.ietf-6man-addr-select-considerations]
Chown, T., "Considerations for IPv6 Address Selection Chown, T. and A. Matsumoto, "Considerations for IPv6
Policy Changes", Address Selection Policy Changes",
draft-ietf-6man-addr-select-considerations-03 (work in draft-ietf-6man-addr-select-considerations-04 (work in
progress), March 2011. progress), October 2011.
[I-D.ietf-6man-addr-select-opt] [I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6", "Distributing Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-01 (work in progress), draft-ietf-6man-addr-select-opt-01 (work in progress),
June 2011. June 2011.
[I-D.ietf-mif-dhcpv6-route-option] [I-D.ietf-mif-dhcpv6-route-option]
Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
Route Options", draft-ietf-mif-dhcpv6-route-option-03 Route Options", draft-ietf-mif-dhcpv6-route-option-03
skipping to change at page 22, line 23 skipping to change at page 22, line 47
[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, July 2005. RFC 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 4960, September 2007. RFC 4960, September 2007.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
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.
[TR124] The BroadBand Forum, "TR-124i2, Functional Requirements [TR124] The BroadBand Forum, "TR-124i2, Functional Requirements
for Broadband Residential Gateway Devices (work in for Broadband Residential Gateway Devices (work in
progress)", May 2010. progress)", May 2010.
 End of changes. 11 change blocks. 
13 lines changed or deleted 30 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/