draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt   draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.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 18, 2012 Alcatel-Lucent Expires: August 24, 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
November 15, 2011 February 21, 2012
IPv6 Multihoming without Network Address Translation IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04
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, which solutions are suitable to solve the multihoming issues, described in
described in this document. Nevertheless, we mention that the this document, while NPTv6 may be required as an intermediate
possible needs for NPTv6 in the transition phase to the fully solution.
deployment of the proposed solutions.
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 May 18, 2012. This Internet-Draft will expire on August 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
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. Policy distribution . . . . . . . . . . . . . . . . . . . 12 4.2. 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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . 14
6. Implementation approach . . . . . . . . . . . . . . . . . . . 15 6. Implementation approach . . . . . . . . . . . . . . . . . . . 14
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 6.4. Other algorithms available in RFCs . . . . . . . . . . . . 16
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 considerations . . . . . . . . . . . . . . . 17
7.3. Policy collision consideration . . . . . . . . . . . . . . 19 7.3. Policy collision consideration . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
In this document, we analyze the use cases of multihoming, describe
functional requirements and the problems with IPv6 multihoming.
There are two ways to avoid the problems of IPv6 multihoming:
1. IPv6 network prefix translation (NPTv6, [RFC6296]), or;
2. refining IPv6 specifications to resolve the problems with IPv6
multihoming.
This document concerns itself with the latter, and explores the
solution space. We hope this will encourage the development of
solutions to the problem so that, in the long run, NPTv6 can be
avoided.
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.
Though there are some mechanisms to implement multihoming, such as Though there are mechanisms to implement multihoming, such as BGP
BGP multihoming [RFC4116] in network level, and SCTP based multihoming [RFC4116] at the network level, and SCTP based
multihoming [RFC4960] in transport layer for application level, there multihoming [RFC4960] in the transport layer, there is no mechanism
is no mechanism in IPv6 that serves as a replacement for NAT based in IPv6 that serves as a replacement for NAT based multihoming in
multihoming in IPv4. In IPv4, for a host or a small network, NAT IPv4. In IPv4, for a host or a small network, NAT based multihoming
based multihoming is easily deployable and an already deployed is easily deployable and an already deployed technique.
technique. Some of the same reasons for IPv4 NATs may be applicable
to IPv6.
Whenever a host or small network (which does not meet minimum IPv6 Whenever a host or small network (that does not meet minimum IPv6
allocation criteria) is connected to multiple upstream networks, an allocation criteria) is connected to multiple upstream networks, an
IPv6 address is assigned by each respective service provider IPv6 address is assigned by each respective service provider
resulting in hosts with multiple global scope IPv6 addresses with resulting in hosts with multiple global scope IPv6 addresses with
different prefixes. As each service provider is allocated a different prefixes. As each service provider is allocated a
different address space from its Internet Registry, it in-turn different address space from its Internet Registry, it, in turn
assigns a different address space to the end-user network or host. assigns a different address space to the end-user network or host.
For example, a remote access user's host or router may use a VPN to For example, a remote access user's host or router may use a VPN to
simultaneously connect to a remote network and retain a default route simultaneously connect to a remote network and retain a default route
to the Internet for other purposes. to the Internet for other purposes.
In IPv4 a common solution to the multihoming problem is to employ In IPv4 a common solution to the multihoming problem is to employ
NAPT on a border router and use private address space for individual NAPT on a border router and use private address space for individual
host addressing. The use of NAPT allows hosts to have exactly one IP host addressing. The use of NAPT allows hosts to have exactly one IP
address visible on the public network and the combination of NAPT address visible on the public network and the combination of NAPT
with provider-specific outside addresses (one for each uplink) and with provider-specific outside addresses (one for each uplink) and
destination-based routing insulates a host from the impacts of destination-based routing insulates a host from the impacts of
multiple upstream networks. The border router may also implement a multiple upstream networks. The border router may also implement a
DNS cache or DNS policy to resolve address queries from hosts. DNS cache or DNS policy to resolve address queries from hosts.
It is our goal to avoid the IPv6 equivalent of NAT. So, the goals It is our goal to avoid the IPv6 equivalent of NAT. So, the goals
for IPv6 multihoming defined in [RFC3582] do not match the goals of for IPv6 multihoming defined in [RFC3582] do not match the goals of
this document. Also regardless of what the NPTv6 specification is, this document. Also regardless of what the NPTv6 specification is,
we are trying to avoid any form of network address translation we are trying to avoid any form of network address translation
technique that may not be visible for either of the end hosts. To technique that may not be visible to either of the end hosts. To
reach this goal, mechanisms are needed for end-user hosts to have reach this goal, several mechanisms are needed for end-user hosts to
multiple address assignments and resolve issues such as which address have multiple address assignments and resolve issues such as which
to use for sourcing traffic to which destination: address to use for sourcing traffic to which destination:
o If multiple routers exist on a single link the host must select o If multiple routers exist on a single link the host must select
the appropriate next-hop for each connected network. Each router the appropriate next-hop for each connected network. Each router
is in turn connected to a different service provider network, is in turn connected to a different service provider network,
which provides independent address assignment. Routing protocols which provides independent address assignment. Routing protocols
that would normally be employed for router-to-router network that would normally be employed for router-to-router network
advertisement seem inappropriate for use by individual hosts. advertisement seem inappropriate for use by individual hosts.
o Source address selection also becomes difficult whenever a host o Source address selection becomes difficult whenever a host has
has more than one address within the same address scope. Current more than one address of the same address scope. Current address
address selection criteria may result in hosts using an arbitrary selection criteria, may result in hosts using an arbitrary or
or random address when sourcing upstream traffic. Unfortunately, random address when sourcing upstream traffic. Unfortunately, for
for the host, the appropriate source address is a function of the the host, the appropriate source address is a function of the
upstream network for which the packet is bound for. If an upstream network for which the packet is bound for. If an
upstream service provider uses IP anti-spoofing or ingress upstream service provider uses IP anti-spoofing or ingress
filtering, it is conceivable that the packets that have an filtering, it is conceivable that the packets that have an
inappropriate source address for the upstream network would never inappropriate source address for the upstream network would never
reach their destination. reach their destination.
o In a multihomed environment, different DNS scopes or partitions o In a multihomed environment, different DNS scopes or partitions
may exist in each independent upstream network. A DNS query sent may exist in each independent upstream network. A DNS query sent
to an arbitrary upstream DNS recursive name servier may result in to an arbitrary upstream DNS recursive name server may result in
incorrect or poisoned responses. incorrect or poisoned responses.
In short, while IPv6 facilitates hosts having more than one address In short, while IPv6 facilitates hosts having more than one address
in the same address scope, the application of this causes significant in the same address scope, the application of this causes significant
issues for a host from routing, source address selection and DNS issues for a host; from routing, source address selection and DNS
resolution perspectives. A possible consequence of assigning a host resolution perspectives. A possible consequence of assigning a host
multiple identically-scoped addresses is severely impaired IP multiple identically-scoped addresses is severely impaired IP
connectivity. connectivity.
If a host connects to a network behind an IPv4 NAPT, the host has one If a host connects to a network behind an IPv4 NAPT, the host has one
private address in the local network. There is no confusion. The private address in the local network. There is no confusion. The
NAT becomes the gateway of the host and forwards the packet to an NAT becomes the gateway of the host and forwards the packet to an
appropriate network when it is multihomed. It also operates a DNS appropriate network when it is multihomed. It also operates a DNS
cache server, which receives all DNS inquires, and gives a correct cache server or DNS proxy, which receives all DNS inquires, and gives
answer to the host. a correct answer to the host.
In this document, we analyze the use cases of multihoming. We also
describe functional requirements and possible solutions for
multihoming without the use of prefix translation in IPv6 for hosts
and small IPv6 networks that would otherwise be unable to meet
minimum IPv6 allocation criteria. We conclude that DHCPv6 based
solutions are suitable to solve the multihoming issues, which
described in this document. Nevertheless, we mention that the
possible needs for NPTv6 in the transition phase to the fully
deployment of the proposed solutions.
2. Terminology 2. Terminology
NPTv6 IPv6-to-IPv6 Network Prefix Translation in NPTv6 IPv6-to-IPv6 Network Prefix Translation in
NPTv6 [RFC6296]. NPTv6 [RFC6296].
NAPT Network Address Port Translation as described NAPT Network Address Port Translation as described
in [RFC3022]. In other contexts, NAPT is often in [RFC3022]. In other contexts, NAPT is often
pronounced "NAT" or written as "NAT". pronounced "NAT" or written as "NAT".
skipping to change at page 6, line 31 skipping to change at page 6, line 31
In this section, we classify three scenarios of the multihoming In this section, we classify three scenarios of the multihoming
environment. environment.
3.1. Classification of network scenarios for multihomed host 3.1. Classification of network scenarios for multihomed host
Scenario 1: Scenario 1:
In this scenario, two or more routers are present on a single link In this scenario, two or more routers are present on a single link
shared with the host(s). Each router is in turn connected to a shared with the host(s). Each router is in turn connected to a
different service provider network, which provides independent different service provider network, that provides independent address
address assignment and DNS recursive name servers. A host in this assignment and DNS recursive name servers. A host in this
environment would be offered multiple prefixes and DNS recursive name environment would be offered multiple prefixes and DNS recursive name
servers advertised from the two different routers. servers advertised from the two different routers.
+------+ ___________ +------+ ___________
| | / \ | | / \
+---| rtr1 |=====/ network \ +---| rtr1 |=====/ network \
| | | \ 1 / | | | \ 1 /
+------+ | +------+ \___________/ +------+ | +------+ \___________/
| | | | | |
| hosts|-----+ | hosts|-----+
skipping to change at page 11, line 49 skipping to change at page 11, line 49
to serve a local namespace. to serve a local namespace.
4. Requirements 4. Requirements
This section describes requirements that any solution multi-address This section describes requirements that any solution multi-address
and multi-uplink architectures need to meet. and multi-uplink architectures need to meet.
4.1. End-to-End transparency 4.1. End-to-End transparency
One of the major design goals for IPv6 is to restore the end-to-end One of the major design goals for IPv6 is to restore the end-to-end
transparency of the Internet. If NAT mechanism is applied to IP transparency of the Internet. If NAT is applied to IP communication
communication between hosts, it is required to apply complex NAT between hosts, NAT traversal mechanism are required, to establish bi-
traversal mechanism to establish bi-directional IP communication. directional IP communication. A NAT traversal mechanism does not
need to be implemented in an application, in an environment with end-
Essentially, extra NAT traversal meachanism does not need to be to-end transparency. Therefore, the IPv6 multihoming solution should
implemented on application, on an environment with end-to-end strive to avoid NPTv6 to achieve end-to-end transparency.
transparency. Therefore, The IPv6 multihoming solution should
guarantee end-to-end transparency by avoiding NPTv6.
4.2. Policy distribution
The solution SHOULD have a function to provide a policy on sites/
nodes. In particular, a network service provider has to control his
or her user nodes such as CPE devices. All nodes are not necessarily
controlled evenly with policy providing. It is required to identify
a nodes and provide indepenent policy by each node.
The providing mechanisms should have:
o a function to distribute policies to nodes dynamically to update
their behavior. When the network environment changes and the
nodes' behavior has to be changed, a network administrator can
modify the behavior of the nodes.
o a function to control every node centrally. A site administrator
or a service provider could determine or could have an effect on
the behavior at their users' hosts.
o a function to control node-specific behavior. Even when multiple
nodes are on the same subnet, the mechanism should be able to
provide a method for the network administrator to make nodes
behave differently. For example, each node may have a different
set of assigned prefixes. In such a case, the appropriate
behavior may be different.
4.3. Scalability 4.2. Scalability
The solution will have to be able to manage a large number of sites/ The solution will have to be able to manage a large number of sites/
nodes. In services for residential users, provider edge devices have nodes. In services for residential users, provider edge devices have
to manage thousands of sites. In such environments, sending packets to manage thousands of sites. In such environments, sending packets
periodically to each site may affect edge system performance. periodically to each site may affect edge system performance.
5. Problem statement and analysis 5. Problem statement and analysis
The problems described in Section 3 can be classified into these The problems described in Section 3 can be classified into these
three types: three types:
skipping to change at page 13, line 15 skipping to change at page 12, line 35
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 resolve address selection rules [RFC3484] may not deterministically select
the correct source address when the host addressing was via Router the correct source address.
Advertisement (RA) or DHCPv6.
[I-D.ietf-6man-addr-select-considerations] describes the use of the [I-D.ietf-6man-addr-select-considerations] describes the use of the
policy table [RFC3484] to resolve this problem, but there is no policy table [RFC3484] to resolve this problem, but there is no
mechanism defined to disseminate the policy table information to a 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 host. A proposal is in [I-D.ietf-6man-addr-select-opt] to provide a
DHCPv6 mechanism for host policy table management. 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.
skipping to change at page 14, line 41 skipping to change at page 14, line 13
must also support [I-D.ietf-mif-dhcpv6-route-option]. 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]
required 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
specific destination-based policy for both routing and source address specific destination-based policy for both routing and source address
selection, it is desirable to extend a policy-based concept to DNS selection, it is desirable to extend a policy-based concept to DNS
recursive name server selection. Doing so can minimize DNS recursive recursive name server selection. Doing so can minimize DNS recursive
name server load and avoid issues where DNS recursive name servers in name server load and avoid issues where DNS recursive name servers in
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 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. [I-D.ietf-mif-dns-server-selection]
proposes a solution for distributing DNS server selection policy proposes a solution for 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 [I-D.ietf-mif-dns-server-selection].
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 in source address selection, next-hop selection, and three problems; source address selection, next-hop selection, and DNS
DNS recursive name server selection. In this section, possible recursive name server selection. In this section, possible solutions
solution mechanisms for each problem are introduced and evaluated for each problem are introduced and evaluated against the
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 Possible solutions and their evaluation are summarized in
[I-D.ietf-6man-addr-select-considerations]. When those solutions are [I-D.ietf-6man-addr-select-considerations]. When those solutions are
examined against the requirements in Section 4, the proactive examined against the requirements in Section 4, the proactive
approaches, such as the policy table distribution mechanism and the approaches, such as the policy table distribution mechanism and the
routing hints mechanism, are more appropriate in that they can routing hints mechanism, are more appropriate in that they can
propagate the network administrator's policy directly. The policy propagate the network administrator's policy directly. The policy
distribution mechanism has an advantage with regard to the host's distribution mechanism has an advantage with regard to the host's
skipping to change at page 16, line 4 skipping to change at page 15, line 27
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-
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, the pairs of source prefixes and next-hops can intermediate routers, pairs of source prefixes and next-hops can be
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], the DHCPv6
route information option proposed in route information option proposed in
[I-D.ietf-mif-dhcpv6-route-option], and the [TR069] standardized at [I-D.ietf-mif-dhcpv6-route-option], and the [TR069] standardized at
BBF. BBF.
The RA-based mechanism has difficulty in per-host routing information The RA-based mechanism doesn't handle distribution of per-host
distribution. The dynamic routing protocols such as RIPng are not routing information easily. Dynamic routing protocols are not
usually used between the residential users and ISP networks because typically used between residential users and ISPs, because of their
of their scalability implications. The DHCPv6 mechanism does not scalability and security implications. The DHCPv6 mechanism does not
have these difficulties 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
(CPE). It assumes, however, IP reachability to the Auto (CPE). It assumes, however, IP reachability to the Auto
Configuration Server (ACS) is established. Therefore, if the CPE Configuration Server (ACS) is established. Therefore, if the CPE
requires routing information to reach the ACS, [TR069] cannot be used requires routing information to reach the ACS, [TR069] cannot be used
to distribute this information. to distribute this information.
6.3. DNS recursive name server selection 6.3. DNS recursive name server selection
As in the above two problems, a policy-based approach and non policy- Note: Split-horizon DNS is discussed in this section. Split-
based approach are possible. In a non policy-based approach, a host horizon DNS is known to cause problems with applications to allow
or a home gateway router is assumed to send DNS queries to several information leakage. The discussion of split-horizon DNS is not
DNS recursive name servers at once or to select one of the available condoning its use, but rather acknowledging that split-horizon DNS
servers. is used and that its use is another justification for network
address translation. The goal of this document is to encourage
building solutions which do not need network address translation.
Two solutions appear possible: make split-horizon DNS work better
(which is discussed below) or meet network administrator's
requirements without split-horizon DNS (which is out of scope of
this document).
As in the above two problems, a policy-based approach and a non
policy-based approach are possible. In a non policy-based approach,
a host or a home gateway router is assumed to send DNS queries to
several DNS recursive name servers at once or to select one of the
available servers.
In the non policy-based approach, by making a query to a DNS In the non policy-based approach, by making a query to a DNS
recursive name server in a different service provider to that which recursive name server in a different service provider to that which
hosts the service, a user could be directed to unexpected IP address hosts the service, a user could be directed to unexpected IP address
or receive an invalid response, and thus cannot connect to the or receive an invalid response, and thus cannot connect to the
service provider's private and legitimate service. For example, some service provider's private and legitimate service. For example, some
DNS recursive name servers reply with different answers depending on DNS recursive name servers reply with different answers depending on
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
skipping to change at page 18, line 28 skipping to change at page 17, line 47
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].
7.2. Co-existence consideration 7.2. Co-existence considerations
To allow the co-existence of non-MHMP hosts and MHMP hosts (i.e. To allow the co-existence of non-MHMP hosts and MHMP hosts (i.e.
hosts supporting multi-prefix with the enhancements for the source hosts supporting multi-prefix with the enhancements for the source
address selection), GW-rtr may need to treat those hosts separately. address selection), GW-rtr may need to treat those hosts separately.
An idea to achieve this is that GW-rtr identifies the hosts, and then An idea for how to achieve this, is that GW-rtr identifies the hosts,
assigns a single prefix to non-MHMP hosts and assigns multiple and then assigns a single prefix to non-MHMP hosts and assigns
prefixes to MHMP hosts. In this case, GW-rtr can perform IPv6 NAT multiple prefixes to MHMP hosts. In this case, GW-rtr can perform
only for the traffic from non-MHMP hosts if its source address is not IPv6 NAT only for the traffic from non-MHMP hosts if its source
appropriate. address is not appropriate.
Another idea is that GW-rtr assigns multiple prefixes to the both Another idea is that GW-rtr assigns multiple prefixes to both hosts,
hosts, and it performs IPv6 NAT for the traffic from non-MHMP hosts and performs IPv6 NAT for traffic from non-MHMP hosts if its source
if its source address is not appropriate. address is not appropriate.
In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT
box. In this case, the non-MHMP host can access the service through box. In this case, the non-MHMP host can access the service through
the NAT box. the NAT box.
The implementation of identifying non-MHMP hosts and NAT policy is The implementation of identifying non-MHMP hosts and NAT policy is
outside the scope of this document. outside the scope of this document.
7.3. Policy collision consideration 7.3. Policy collision consideration
skipping to change at page 19, line 28 skipping to change at page 18, line 46
This document does not presume specific recommendations for resolving This document does not presume specific recommendations for resolving
policy collision. It is expected to the implementation to decide how policy collision. It is expected to the implementation to decide how
to resolve the conflicts. If they are not resolved consistently by to resolve the conflicts. If they are not resolved consistently by
different implementations, that could affect interoperability and different implementations, that could affect interoperability and
security trust boundaries. Future work will be expected to address security trust boundaries. Future work will be expected to address
the need for consistent policy resolution to avoid interoperability the need for consistent policy resolution to avoid interoperability
and security trust boundary issues. and security trust boundary issues.
8. Security Considerations 8. Security Considerations
In today's multi-homed IPv4 networks, it is difficult to resolve or
coordinate conflicts between the two upstream networks. This problem
persists with IPv6, no matter if the hosts use IPv6 provider-
dependent or provider-independent addresses.
This document requires that the solutions for MHMP should have policy This document requires that the solutions for MHMP should have policy
providing functions. New security threats can be introduced providing functions. New security threats can be introduced
depending on what kind and what form of the policy. The threats can depending on what kind and what form of the policy. The threats can
be categorized in two parts: the policy receiver side and the policy be categorized in two parts: the policy receiver side and the policy
distributor side. distributor side.
A policy receiver may receive an evil policy from a policy A policy receiver may receive an evil policy from a policy
distributor. A policy distributor should expect some hosts in its distributor. A policy distributor should expect some hosts in its
network do not follow the distributed policy. The security threats network do not follow the distributed policy. At the time of
related to IPv6 multihoming are described in [RFC4218]. Those writing, there are no known methods to resolve conflicts between the
threats that are specific to MHMP solutions are enumerated below. host's own policy (policy receiver) and the policies of upstream
providers (policy provider). As this document is analyzing the
problem space, rather than proposing a solution, we note the
following problems:
Threats related to the policy distributor side: Threats related to the policy distributor side:
Service provider should expect the existence of hosts that will Service provider should expect the existence of hosts that will
not obey the received policy. A possible solutions is to not obey the received policy. A possible solutions is to
ingress-filter those packets that do not match the distributed ingress-filter those packets that do not match the distributed
policy and drop them. About the route selection, packet policy and drop them. About the route selection, packet
forwarding or redirection can be another possible solution. forwarding or redirection can be another possible solution.
About the source address selection, IPv6 NAT can be another About the source address selection, IPv6 NAT can be another
possible solution. possible solution.
skipping to change at page 21, line 13 skipping to change at page 20, line 37
at the network service provider router can be a solution. at the network service provider router can be a 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
[RFC4218].
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Contributors 10. Contributors
The following people contributed to this document: Akiko Hattori, The following people contributed to this document: Akiko Hattori,
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
skipping to change at page 21, line 39 skipping to change at page 21, line 19
[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., 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-02 (work in progress),
June 2011. February 2012.
[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
(work in progress), September 2011. (work in progress), September 2011.
[I-D.ietf-mif-dns-server-selection] [I-D.ietf-mif-dns-server-selection]
Savolainen, T., Kato, J., and T. Lemon, "Improved DNS Savolainen, T., Kato, J., and T. Lemon, "Improved DNS
Server Selection for Multi-Interfaced Nodes", Server Selection for Multi-Interfaced Nodes",
draft-ietf-mif-dns-server-selection-07 (work in progress), draft-ietf-mif-dns-server-selection-07 (work in progress),
skipping to change at page 23, line 21 skipping to change at page 23, line 9
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.
Authors' Addresses Authors' Addresses
Ole Troan (editor) Ole Troan (editor)
Cisco Cisco
Bergen Oslo
Norway Norway
Email: ot@cisco.com Email: ot@cisco.com
David Miles David Miles
Alcatel-Lucent Alcatel-Lucent
Melbourne Melbourne
Australia Australia
Email: david.miles@alcatel-lucent.com Email: david.miles@alcatel-lucent.com
 End of changes. 39 change blocks. 
127 lines changed or deleted 121 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/