draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt   draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05.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: August 24, 2012 Alcatel-Lucent Expires: September 19, 2013 Alcatel-Lucent
S. Matsushima S. Matsushima
Softbank Telecom Softbank Telecom
T. Okimoto T. Okimoto
NTT West NTT West
D. Wing D. Wing
Cisco Cisco
February 21, 2012 March 18, 2013
IPv6 Multihoming without Network Address Translation IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05
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 August 24, 2012. This Internet-Draft will expire on September 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 6 3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 6
3.1. Classification of network scenarios for multihomed host . 6 3.1. Classification of network scenarios for multihomed host . 6
3.2. Multihomed network environment . . . . . . . . . . . . . . 9 3.2. Multihomed network environment . . . . . . . . . . . . . . 9
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 10 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 10
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 11 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 11
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
5. Problem statement and analysis . . . . . . . . . . . . . . . . 12 5. Problem statement and analysis . . . . . . . . . . . . . . . . 12
5.1. Source address selection . . . . . . . . . . . . . . . . . 12 5.1. Source address selection . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . 13
6. Implementation approach . . . . . . . . . . . . . . . . . . . 14 6. Implementation approach . . . . . . . . . . . . . . . . . . . 14
6.1. Source address selection . . . . . . . . . . . . . . . . . 15 6.1. Source address selection . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . 15
6.4. Other algorithms available in RFCs . . . . . . . . . . . . 16 6.4. Other algorithms available in RFCs . . . . . . . . . . . . 16
7. Considerations for MHMP deployment . . . . . . . . . . . . . . 17 7. Considerations for MHMP deployment . . . . . . . . . . . . . . 16
7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17 7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17
7.2. Co-existence considerations . . . . . . . . . . . . . . . 17 7.2. Co-existence considerations . . . . . . . . . . . . . . . 17
7.3. Policy collision consideration . . . . . . . . . . . . . . 18 7.3. Policy collision consideration . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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;
skipping to change at page 13, line 38 skipping to change at page 13, line 38
traffic fails to reach the destination server. The host or gateway traffic fails to reach the destination server. The host or gateway
router requires route information for each upstream service provider, router requires route information for each upstream service provider,
but the use of a routing protocol between the gateway and the two but the use of a routing protocol between the gateway and the two
routers causes both configuration and scaling issues. For IPv4 routers causes both configuration and scaling issues. For IPv4
hosts, the gateway router is often pre-configured with static route hosts, the gateway router is often pre-configured with static route
information or uses of Classless Static Route Options [RFC3442] for information or uses of Classless Static Route Options [RFC3442] for
DHCPv4. Extensions to Router Advertisements through Default Router DHCPv4. Extensions to Router Advertisements through Default Router
Preference and More-Specific Routes [RFC4191] provides for link- Preference and More-Specific Routes [RFC4191] provides for link-
specific preferences but does not address per-host configuration in a specific preferences but does not address per-host configuration in a
multi-access topology because of its reliance on Router multi-access topology because of its reliance on Router
Advertisements. A DHCPv6 option, such as that in Advertisements.
[I-D.ietf-mif-dhcpv6-route-option], is preferred for host-specific
configuration. By employing a DHCPv6 solution, a DHCPv6 server could
restrict address assignment (of additional prefixes) only to hosts
that support more advanced next-hop and address selection
requirements.
Scenario 1: "Host" needs to support the solution for this problem. Scenario 1: "Host" needs to support the solution for this problem.
Scenario 2: "GW rtr" needs to support the solution for this problem. Scenario 2: "GW rtr" needs to support the solution for this problem.
Scenario 3: "Host" needs to support the solution for this problem. Scenario 3: "Host" needs to support the solution for this problem.
It is noted that the service providers (i.e., ISP and enterprise/VPN)
must also support [I-D.ietf-mif-dhcpv6-route-option].
5.3. DNS recursive name server selection 5.3. DNS recursive name server selection
A multihomed IPv6 host or gateway router may be provided multiple DNS A multihomed IPv6 host or gateway router may be provided multiple DNS
recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106]. recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106].
When the host or gateway router sends a DNS query, it would normally When the host or gateway router sends a DNS query, it would normally
choose one of the available DNS recursive name servers for the query. choose one of the available DNS recursive name servers for the query.
In the IPv6 gateway router scenario, the Broadband Forum [TR124] In the IPv6 gateway router scenario, the Broadband Forum [TR124]
requires that the query be sent to all DNS recursive name servers, requires that the query be sent to all DNS recursive name servers,
and the gateway waits for the first reply. In IPv6, given our use of and the gateway waits for the first reply. In IPv6, given our use of
skipping to change at page 14, line 29 skipping to change at page 14, line 22
different networks have connectivity issues, or the DNS recursive different networks have connectivity issues, or the DNS recursive
name server are not publicly accessible. In the worst case, a DNS name server are not publicly accessible. In the worst case, a DNS
query for a name from a local namespace may not be resolved correctly query for a name from a local namespace may not be resolved correctly
if sent towards a DNS server not aware of said local namespace, if sent towards a DNS server not aware of said local namespace,
resulting in a lack of connectivity. resulting in a lack of connectivity.
It is not an issue of Domain Name System model itself, but an IPv6 It is not an issue of Domain Name System model itself, but an IPv6
multihomed host or gateway router should have the ability to select multihomed host or gateway router should have the ability to select
appropriate DNS recursive name servers for each service based on the appropriate DNS recursive name servers for each service based on the
domain space for the destination, and each service should provide domain space for the destination, and each service should provide
rules specific to that network. [I-D.ietf-mif-dns-server-selection] rules specific to that network. [RFC6731] proposes a solution for
proposes a solution for distributing DNS server selection policy distributing DNS server selection policy using a DHCPv6 option.
using a DHCPv6 option.
Scenario 1: "Host" needs to support the solution for this problem. Scenario 1: "Host" needs to support the solution for this problem.
Scenario 2: "GW rtr" needs to support the solution for this problem. Scenario 2: "GW rtr" needs to support the solution for this problem.
Scenario 3: "Host" needs to support the solution for this problem. Scenario 3: "Host" needs to support the solution for this problem.
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-mif-dns-server-selection]. must also support [RFC6731].
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
skipping to change at page 15, line 35 skipping to change at page 15, line 24
Routing information is a typical example of policy related to next- Routing information is a typical example of policy related to next-
hop selection. If we assume source address-based routing at hosts or hop selection. If we assume source address-based routing at hosts or
intermediate routers, pairs of source prefixes and next-hops can be intermediate routers, pairs of source prefixes and next-hops can be
another example of next-hop selection policy. another example of next-hop selection policy.
The routing information-based approach has a clear advantage in The routing information-based approach has a clear advantage in
implementation and is already commonly used. implementation and is already commonly used.
The existing proposed or standardized routing information The existing proposed or standardized routing information
distribution mechanisms are routing protocols, such as RIPng and distribution mechanisms are routing protocols, such as RIPng and
OSPFv3, the RA extension option defined in [RFC4191], the DHCPv6 OSPFv3, the RA extension option defined in [RFC4191], and the [TR069]
route information option proposed in standardized at BBF.
[I-D.ietf-mif-dhcpv6-route-option], and the [TR069] standardized at
BBF.
The RA-based mechanism doesn't handle distribution of per-host The RA-based mechanism doesn't handle distribution of per-host
routing information easily. Dynamic routing protocols are not routing information easily. Dynamic routing protocols are not
typically used between residential users and ISPs, because of their typically used between residential users and ISPs, because of their
scalability and security implications. The DHCPv6 mechanism does not scalability and security implications. The DHCPv6 mechanism does not
have these problems and has the advantage of its relaying have these problems and has the advantage of its relaying
functionality. It is commonly used and is thus easy to deploy. functionality. It is commonly used and is thus easy to deploy.
[TR069], mentioned above, is a possible solution mechanism for [TR069], mentioned above, is a possible solution mechanism for
routing information distribution to customer-premises equipment routing information distribution to customer-premises equipment
skipping to change at page 16, line 41 skipping to change at page 16, line 29
the source address of the DNS query, which is sometimes called split- the source address of the DNS query, which is sometimes called split-
horizon. When the host mistakenly makes a query to a different horizon. When the host mistakenly makes a query to a different
provider's DNS recursive name server to resolve a FQDN of another provider's DNS recursive name server to resolve a FQDN of another
provider's private service, and the DNS recursive name server adopts provider's private service, and the DNS recursive name server adopts
the split-horizon configuration, the queried server returns an IP the split-horizon configuration, the queried server returns an IP
address of the non-private side of the service. Another problem with address of the non-private side of the service. Another problem with
this approach is that it causes unnecessary DNS traffic to the DNS this approach is that it causes unnecessary DNS traffic to the DNS
recursive name servers that are visible to the users. recursive name servers that are visible to the users.
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 [RFC6731], where several pairs of DNS recursive name server addresses
recursive name server addresses and DNS domain suffixes are defined and DNS domain suffixes are defined as part of a policy and conveyed
as part of a policy and conveyed to hosts in a new DHCP option. In to hosts in a new DHCP option. In an environment where there is a
an environment where there is a home gateway router, that router can home gateway router, that router can act as a DNS recursive name
act as a DNS recursive name server, interpret this option and server, interpret this option and distribute DNS queries to the
distribute DNS queries to the appropriate DNS servers according to appropriate DNS servers according to the policy.
the policy.
6.4. Other algorithms available in RFCs 6.4. Other algorithms available in RFCs
The authors of this document are aware of a variety of other The authors of this document are aware of a variety of other
algorithms and architectures, such as shim6 [RFC5533] and HIP algorithms and architectures, such as shim6 [RFC5533] and HIP
[RFC5206], that may be useful in this environment. At this writing, [RFC5206], that may be useful in this environment. At this writing,
there is not enough operational experience on which to base a there is not enough operational experience on which to base a
recommendation. Should such operational experience become available, recommendation. Should such operational experience become available,
this document may be updated in the future. 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.
skipping to change at page 20, line 17 skipping to change at page 19, line 51
wiretapping and phishing. Unauthorized policy here means a wiretapping and phishing. Unauthorized policy here means a
policy distributed from an entity that does not have rights to policy distributed from an entity that does not have rights to
do so. Usually, only a site administrator and a network do so. Usually, only a site administrator and a network
service provider have rights to distribute these policies just service provider have rights to distribute these policies just
as well as IP address assignment and DNS server address as well as IP address assignment and DNS server address
notification. Regarding source address selection, unauthorized notification. Regarding source address selection, unauthorized
policy can expose an IP address that will not usually be policy can expose an IP address that will not usually be
exposed to an external server, which can be a privacy problem. exposed to an external server, which can be a privacy problem.
To solve or mitigate this problem of unauthorized policy, one To solve or mitigate this problem of unauthorized policy, one
approach is limiting on use of these policy distribution approach is limiting on use of these policy distribution
mechanisms, as described in the section 4.4 of mechanisms, as described in the section 4.4 of [RFC6731]. For
[I-D.ietf-mif-dns-server-selection]. For example, a policy example, a policy should be preferred or accepted when the
should be preferred or accepted when the policy is verified its policy is verified its integrity and delivered across a secure,
integrity and delivered across a secure, trusted channel such trusted channel such as 3G connection in cellular services.
as 3G connection in cellular services. The proposed solutions The proposed solutions are based on DHCP, so the limitation of
are based on DHCP, so the limitation of local site local site communication, which is often used in WiFi access
communication, which is often used in WiFi access services, services, should be another solution or mitigation for this
should be another solution or mitigation for this problem. problem. About DNS server selection issue, DNSSEC can be
About DNS server selection issue, DNSSEC can be another another solution. About source address selection, the ingress
solution. About source address selection, the ingress filter filter at the network service provider router can be a
at the network service provider router can be a solution. solution.
Another threat is the leakage of the policy and privacy issues Another threat is the leakage of the policy and privacy issues
resulting from that. Especially when each client is resulting from that. Especially when each client is
distributed its own policy from the network service provider, distributed its own policy from the network service provider,
the policy can give a hint of which service the client the policy can give a hint of which service the client
subscribes. Encryption of communication channel, separation of subscribes. Encryption of communication channel, separation of
communication channel per host can be solutions for this communication channel per host can be solutions for this
problem. problem.
The security threats related to IPv6 multihoming are described in The security threats related to IPv6 multihoming are described in
skipping to change at page 21, line 17 skipping to change at page 21, line 6
11.1. Normative References 11.1. Normative References
[I-D.ietf-6man-addr-select-considerations] [I-D.ietf-6man-addr-select-considerations]
Chown, T. and A. Matsumoto, "Considerations for IPv6 Chown, T. and A. Matsumoto, "Considerations for IPv6
Address Selection Policy Changes", Address Selection Policy Changes",
draft-ietf-6man-addr-select-considerations-04 (work in draft-ietf-6man-addr-select-considerations-04 (work in
progress), October 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., and T. Chown, "Distributing
"Distributing Address Selection Policy using DHCPv6", Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-02 (work in progress), draft-ietf-6man-addr-select-opt-08 (work in progress),
February 2012. January 2013.
[I-D.ietf-mif-dhcpv6-route-option]
Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
Route Options", draft-ietf-mif-dhcpv6-route-option-03
(work in progress), September 2011.
[I-D.ietf-mif-dns-server-selection]
Savolainen, T., Kato, J., and T. Lemon, "Improved DNS
Server Selection for Multi-Interfaced Nodes",
draft-ietf-mif-dns-server-selection-07 (work in progress),
October 2011.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. 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.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, December 2012.
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 2001. January 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.
 End of changes. 20 change blocks. 
62 lines changed or deleted 42 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/