draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.txt   draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-02.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: March 3, 2012 Alcatel-Lucent Expires: May 3, 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
August 31, 2011 October 31, 2011
IPv6 Multihoming without Network Address Translation IPv6 Multihoming without Network Address Translation
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-02
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 IPv6 NAT. 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. Nevertheless, we mention that the minimum IPv6 allocation criteria. We conclude that DHCPv6 based
possible needs for IPv6 NAT in the transition phase to the fully 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. 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 3, 2012.
This Internet-Draft will expire on March 3, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 5 3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 6
3.1. Classification of network scenarios for multihomed host . 5 3.1. Classification of network scenarios for multihomed host . 6
3.2. Multihomed network environment . . . . . . . . . . . . . . 8 3.2. Multihomed network environment . . . . . . . . . . . . . . 9
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 10
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 10 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 11
4.2. Policy distribution . . . . . . . . . . . . . . . . . . . 11 4.2. Policy distribution . . . . . . . . . . . . . . . . . . . 12
4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12
5. Problem statement and analysis . . . . . . . . . . . . . . . . 11 5. Problem statement and analysis . . . . . . . . . . . . . . . . 12
5.1. Source address selection . . . . . . . . . . . . . . . . . 12 5.1. Source address selection . . . . . . . . . . . . . . . . . 13
5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 12 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 13
5.3. DNS recursive name server selection . . . . . . . . . . . 13 5.3. DNS recursive name server selection . . . . . . . . . . . 14
6. Implementation approach . . . . . . . . . . . . . . . . . . . 14 6. Implementation approach . . . . . . . . . . . . . . . . . . . 15
6.1. Source address selection . . . . . . . . . . . . . . . . . 14 6.1. Source address selection . . . . . . . . . . . . . . . . . 15
6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 14 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 15
6.3. DNS recursive name server selection . . . . . . . . . . . 15 6.3. DNS recursive name server selection . . . . . . . . . . . 16
7. Considerations for host without multi-prefix support . . . . . 16 7. Considerations for MHMP deployment . . . . . . . . . . . . . . 17
7.1. IPv6 NAT . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17
7.2. Co-existence consideration . . . . . . . . . . . . . . . . 17 7.2. Co-existence consideration . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7.3. Policy collision consideration . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 due to the necessity of NAT Unfortunately, this may not be possible in every case, due to the
even in IPv6, because of multihoming. Though there are some possible necessity of NAT even in IPv6, because of multihoming.
mechanisms to implement multihoming, such as BGP multihoming Though there are some mechanisms to implement multihoming, such as
[RFC4116] in network level, and SCTP based multihoming [RFC4960] in BGP multihoming [RFC4116] in network level, and SCTP based
application transport level, there is no mechanism in IPv6 that multihoming [RFC4960] in transport layer for application level, there
serves as a replacement for NAT based multihoming in IPv4. In IPv4, is no mechanism in IPv6 that serves as a replacement for NAT based
for a host or a small network, NAT based multihoming is easily multihoming in IPv4. In IPv4, for a host or a small network, NAT
deployable and an already deployed technique. Some of the same based multihoming is easily deployable and an already deployed
reasons for IPv4 NATs may be applicable to IPv6. 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 (which 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
skipping to change at page 3, line 44 skipping to change at page 4, line 45
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 IPv6 NAT's specification this document. Also regardless of what the NPTv6 specification is,
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 for either of the end hosts. To
reach this goal, mechanisms are needed for end-user hosts to have reach this goal, mechanisms are needed for end-user hosts to have
multiple address assignments and resolve issues such as which address multiple address assignments and resolve issues such as which address
to use for sourcing traffic to which destination: 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
skipping to change at page 4, line 44 skipping to change at page 5, line 44
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, which receives all DNS inquires, and gives a correct
answer to the host. answer to the host.
In this document, we analyze the use cases of multihoming. We also In this document, we analyze the use cases of multihoming. We also
describe functional requirements and possible solutions for describe functional requirements and possible solutions for
multihoming without the use of NAT in IPv6 for hosts and small IPv6 multihoming without the use of prefix translation in IPv6 for hosts
networks that would otherwise be unable to meet minimum IPv6 and small IPv6 networks that would otherwise be unable to meet
allocation criteria. Nevertheless, we mention that the possible minimum IPv6 allocation criteria. We conclude that DHCPv6 based
needs for IPv6 NAT in the transition phase to the fully deployment of solutions are suitable to solve the multihoming issues, which
the proposed solutions. 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", NPTv6 IPv6-to-IPv6 Network Prefix Translation in
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NPTv6 [RFC6296].
document are to be interpreted as described in RFC 2119 [RFC2119].
IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to 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".
Multihomed with multi-prefix (MHMP) A host implementation which Multihomed with multi-prefix (MHMP) A host implementation which
supports the mechanisms described in this supports the mechanisms described in this
document. Namely source address selection document. Namely source address selection
policy, next-hop selection and DNS selection policy, next-hop selection and DNS selection
policy. policy.
skipping to change at page 6, line 27 skipping to change at page 7, line 27
+------+ \___________/ +------+ \___________/
Figure 1: single uplink, multiple next-hop, multiple prefix Figure 1: single uplink, multiple next-hop, multiple prefix
(Scenario 1) (Scenario 1)
Figure 1 illustrates the host connecting to rtr1 and rtr2 via a Figure 1 illustrates the host connecting to rtr1 and rtr2 via a
shared link. Networks 1 and 2 are reachable via rtr1 and rtr2 shared link. Networks 1 and 2 are reachable via rtr1 and rtr2
respectively. When the host sends packets to network 1, the next-hop respectively. When the host sends packets to network 1, the next-hop
to network 1 is rtr1. Similarly, rtr2 is the next-hop to network 2. to network 1 is rtr1. Similarly, rtr2 is the next-hop to network 2.
- e.g., broadband service (Internet, VoIP, IPTV, etc.) - e.g., multiple broadband service providers (Internet, VoIP, IPTV,
etc.)
Scenario 2: Scenario 2:
In this scenario, a single gateway router connects the host to two or In this scenario, a single gateway router connects the host to two or
more upstream service provider networks. This gateway router would more upstream service provider networks. This gateway router would
receive prefix delegations and a different set of DNS recursive name receive prefix delegations and a different set of DNS recursive name
servers from each independent service provider network. The gateway servers from each independent service provider network. The gateway
in turn advertises the provider prefixes to the host, and for DNS, in turn advertises the provider prefixes to the host, and for DNS,
may either act as a lightweight DNS cache server or may advertise the may either act as a lightweight DNS cache server or may advertise the
complete set of service provider DNS recursive name servers to the complete set of service provider DNS recursive name servers to the
skipping to change at page 7, line 15 skipping to change at page 8, line 15
+------+ ___________ +------+ ___________
+-----+ | | / \ +-----+ | | / \
| |=======| rtr1 |=====/ network \ | |=======| rtr1 |=====/ network \
| |port1 | | \ 1 / | |port1 | | \ 1 /
+------+ | | +------+ \___________/ +------+ | | +------+ \___________/
| | | | | | | |
| hosts|-----| GW | | hosts|-----| GW |
| | | rtr | | | | rtr |
+------+ | | +------+ ___________ +------+ | | +------+ ___________
| |port2 | | / \ | |port2 | | / \
| |=======| rtr2 |=====/ network \ | |-------| rtr2 |=====/ network \
+-----+ | | \ 2 / +-----+ | | \ 2 /
+------+ \___________/ +------+ \___________/
Figure 2: single uplink, single next-hop, multiple prefix Figure 2: single uplink, single next-hop, multiple prefix
(Scenario 2) (Scenario 2)
Figure 2 illustrates the host connected to GW rtr. GW rtr connects Figure 2 illustrates the host connected to GW rtr. GW rtr connects
to networks 1 and 2 via port1 and 2 respectively. When the host to networks 1 and 2 via port1 and 2 respectively. As the figure
sends packets to either network 1 or 2, the next-hop is GW rtr. When shows a logical topology of the scenario, the port1 could be a pseudo
the packets are sent to network 1 (network 2), GW rtr forwards the interface for tunneling, which connects to the network 1 through the
packets to port1 (port2). network 2, and vice versa. When the host sends packets to either
network 1 or 2, the next-hop is GW rtr. When the packets are sent to
network 1 (network 2), GW rtr forwards the packets to port1 (port2).
- e.g, Internet + VPN/Application Service Provider (ASP) - e.g, Internet + VPN/Application Service Provider (ASP)
Scenario 3: Scenario 3:
In this scenario, a host has more than one active interface that In this scenario, a host has more than one active interface that
connects to different routers and service provider networks. Each connects to different routers and service provider networks. Each
router provides the host with a different address prefix and set of router provides the host with a different address prefix and set of
DNS recursive name servers, resulting in a host with a unique address DNS recursive name servers, resulting in a host with a unique address
per link/interface. per link/interface.
skipping to change at page 8, line 39 skipping to change at page 9, line 39
3.2. Multihomed network environment 3.2. Multihomed network environment
In an IPv6 multihomed network, a host is assigned two or more IPv6 In an IPv6 multihomed network, a host is assigned two or more IPv6
addresses and DNS recursive name servers from independent service addresses and DNS recursive name servers from independent service
provider networks. When this multihomed host attempts to connect provider networks. When this multihomed host attempts to connect
with other hosts, it may incorrectly resolve the next-hop router, use with other hosts, it may incorrectly resolve the next-hop router, use
an inappropriate source address, or use a DNS response from an an inappropriate source address, or use a DNS response from an
incorrect service provider that may result in impaired IP incorrect service provider that may result in impaired IP
connectivity. connectivity.
Multihomed networks in IPv4 have been commonly implemented through Multihomed networks in IPv4 have been implemented through the use of
the use of a gateway router with NAPT function (scenario 2 with a gateway router with NAPT function (scenario 2 with NAPT) in many
NAPT). An analysis of the current IPv4 NAPT and DNS functions within cases. An analysis of the current IPv4 NAPT and DNS functions within
the gateway router should provide a baseline set of requirements for the gateway router should provide a baseline set of requirements for
IPv6 multihomed environments. A destination prefix/route is often IPv6 multihomed environments. A destination prefix/route is often
used on the gateway router to separate traffic between the networks. used on the gateway router to separate traffic between the networks.
+------+ ___________ +------+ ___________
| | / \ | | / \
+---| rtr1 |=====/ network \ +---| rtr1 |=====/ network \
| | | \ 1 / | | | \ 1 /
+------+ +-----+ | +------+ \___________/ +------+ +-----+ | +------+ \___________/
| IPv4 | | | | | IPv4 | | | |
| host |-----| GW |---+ | hosts|-----| GW |---+
| | | rtr | | | | | rtr | |
+------+ +-----+ | +------+ ___________ +------+ +-----+ | +------+ ___________
(NAPT&DNS) | | | / \ (NAPT&DNS) | | | / \
(private +---| rtr2 |=====/ network \ (private +---| rtr2 |=====/ network \
address | | \ 2 / address | | \ 2 /
space) +------+ \___________/ space) +------+ \___________/
Figure 4: IPv4 Multihomed environment with Gateway Router performing Figure 4: IPv4 Multihomed environment with Gateway Router performing
NAPT NAPT
skipping to change at page 11, line 7 skipping to change at page 12, line 7
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 mechanism is applied to IP
communication between hosts, it is required to apply complex NAT communication between hosts, it is required to apply complex NAT
traversal mechanism to establish bi-directional IP communication. traversal mechanism to establish bi-directional IP communication.
Essentially, extra NAT traversal meachanism does not need to be Essentially, extra NAT traversal meachanism does not need to be
implemented on application, on an environment with end-to-end implemented on application, on an environment with end-to-end
transparency. Therefore, The IPv6 multihoming solution SHOULD transparency. Therefore, The IPv6 multihoming solution should
guarantee end-to-end transparency by avoiding IPv6 NAT. guarantee end-to-end transparency by avoiding NPTv6.
4.2. Policy distribution 4.2. Policy distribution
The solution SHOULD have a function to provide a policy on sites/ The solution SHOULD have a function to provide a policy on sites/
nodes. In particular, a network service provider has to control his nodes. In particular, a network service provider has to control his
or her user nodes such as CPE devices. All nodes are not necessarily or her user nodes such as CPE devices. All nodes are not necessarily
controlled evenly with policy providing. It is required to identify controlled evenly with policy providing. It is required to identify
a nodes and provide indepenent policy by each node. a nodes and provide indepenent policy by each node.
The providing mechanisms should have: The providing mechanisms should have:
skipping to change at page 16, 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.
7. Considerations for host without multi-prefix support 7. Considerations for MHMP deployment
This section presents an alternative approach to mitigate the problem This section describes considerations to mitigate possible problem in
in a multihomed network. This approach will help IPv6 hosts that are a network which implements MHMP described in Section 6.
not capable of the enhancements for the source address selection
policy, next-hop selection policy, and DNS selection policy described
in Section 6.
7.1. IPv6 NAT 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, IPv6 NAT 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 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 IPv6 NAT are out of the scope of The implementation and issues of NPTv6 are out of the scope of this
this document. They may be covered by another document under document. They may be covered by another document under discussion
discussion [RFC6296].
[RFC6296].
7.2. Co-existence consideration 7.2. Co-existence consideration
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 to achieve this is that GW-rtr identifies the hosts, and then
assigns a single prefix to non-MHMP hosts and assigns multiple assigns a single prefix to non-MHMP hosts and assigns multiple
prefixes to MHMP hosts. In this case, GW-rtr can perform IPv6 NAT prefixes to MHMP hosts. In this case, GW-rtr can perform IPv6 NAT
skipping to change at page 17, line 32 skipping to change at page 18, line 30
hosts, and it performs IPv6 NAT for the traffic from non-MHMP hosts hosts, and it performs IPv6 NAT for the traffic from non-MHMP hosts
if its source address is not appropriate. if its source 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
When multiple policy distributors exist, a policy receiver may not
follow one or each of the received policy. In particular, when a
policy conflicts with another policy, a policy receiver cannot
implement each of the policy. To solve or mitigate this issue, it is
required that prioritization rule to align these policies along
preference on a trusted interface. Another solution is to preclude
the functionality of multiple policy acceptance at the receiver side.
In this case, a policy distributor should cooperate with other policy
distributors, and a single representative provider should distribute
a merged policy.
This document does not presume specific recommendations for resolving
policy collision. It is expected to the implementation to decide how
to resolve the conflicts. If they are not resolved consistently by
different implementations, that could affect interoperability and
security trust boundaries. Future work will be expected to address
the need for consistent policy resolution to avoid interoperability
and security trust boundary issues.
8. Security Considerations 8. Security Considerations
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. The security threats
related to IPv6 multihoming are described in [RFC4218]. Those related to IPv6 multihoming are described in [RFC4218]. Those
threats that are specific to MHMP solutions are enumerated below. threats that are specific to MHMP solutions are enumerated below.
Threats related to the policy distributor side: Threats related to the policy distributor side:
Policy collision can happen. When multiple policy distributor Service provider should expect the existence of hosts that will
exists, a policy receiver may not follow one or each of the not obey the received policy. A possible solutions is to
received policy. Especially when a policy conflicts with ingress-filter those packets that do not match the distributed
another policy, a policy receiver cannot implement each of the policy and drop them. About the route selection, packet
policy. To solve or mitigate this issue, policy prioritization forwarding or redirection can be another possible solution.
rule should be defined, such as preference for the policy About the source address selection, IPv6 NAT can be another
received on a trusted interface. Another solution is to possible solution.
preclude the functionality of multiple policy acceptance at the
receiver side. In this case, a policy distributor should
cooperate with other policy distributors, and a single
representative provider should distribute a merged policy.
Apart from the policy collision, a network service provider Administrators of different networks might need to control
should expect the existence of hosts that will not obey the policies (and nodes' behaviors) independently of other
received policy. A possible solutions is to ingress-filter administrators. It means that the need to have access controls
those packets that do not match the distributed policy and drop for such cross-administrative policy access. Administrators
them. About the route selection, packet forwarding or must control only nodes that are part of their own networks, or
redirection can be another possible solution. About the source some administrators must control only nodes that are part of
address selection, IPv6 NAT can be another possible solution. their own networks, while others are authorized to control
nodes across administrative boundaries. To be success to
cross-administrative policy-control, per-user authorization
might be required with existing AAA and network management
standards.
Threats related to the policy receiver side: Threats related to the policy receiver side:
For policy receiver side, who should be trusted to accept
policies is a fundamental issue. How is the trust established,
and how can the network element be assured that it can
established that trust before the network is fully configured.
If a policy receiver trusts untrusted network, it will cause
that distributing unwanted and unauthorized policy that
described below.
A policy receiver are exposed to the threats of unauthorized A policy receiver are exposed to the threats of unauthorized
policy, which can lead to session hijack, DoS, wiretapping and policy, which can lead to session hijack, falsification, DoS,
phishing. Unauthorized policy here means a policy distributed wiretapping and phishing. Unauthorized policy here means a
from an entity that does not have rights to do so. Usually, policy distributed from an entity that does not have rights to
only a site administrator and a network service provider have do so. Usually, only a site administrator and a network
rights to distribute these policies just as well as IP address service provider have rights to distribute these policies just
assignment and DNS server address notification. Regarding as well as IP address assignment and DNS server address
source address selection, unauthorized policy can expose an IP notification. Regarding source address selection, unauthorized
address that will not usually be exposed to an external server, policy can expose an IP address that will not usually be
which can be a privacy problem. To solve or mitigate this exposed to an external server, which can be a privacy problem.
problem of unauthorized policy, one approach is limiting on use To solve or mitigate this problem of unauthorized policy, one
of these policy distribution mechanisms, as described in the approach is limiting on use of these policy distribution
section 4.4 of [I-D.ietf-mif-dns-server-selection]. For mechanisms, as described in the section 4.4 of
example, a policy should be preferred or accepted when the [I-D.ietf-mif-dns-server-selection]. For example, a policy
policy is delivered across a secure, trusted channel such as 3G should be preferred or accepted when the policy is verified its
connection in cellular services. The proposed solutions are integrity and delivered across a secure, trusted channel such
baed on DHCP, so the limitation of local site communication, as 3G connection in cellular services. The proposed solutions
which is often used in WiFi access services, should be another are based on DHCP, so the limitation of local site
solution or mitigation for this problem. About DNS server communication, which is often used in WiFi access services,
selection issue, DNSSEC can be another solution. About source should be another solution or mitigation for this problem.
address selection, the ingress filter at the network service About DNS server selection issue, DNSSEC can be another
provider router can be a solution. solution. About source address selection, the ingress filter
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.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 19, line 36 skipping to change at page 21, line 23
progress), March 2011. progress), March 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-02 Route Options", draft-ietf-mif-dhcpv6-route-option-03
(work in progress), July 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-Homed Nodes", Server Selection for Multi-Interfaced Nodes",
draft-ietf-mif-dns-server-selection-03 (work in progress), draft-ietf-mif-dns-server-selection-07 (work in progress),
June 2011. October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
skipping to change at page 21, line 20 skipping to change at page 23, line 4
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
Satoru Matsushima Satoru Matsushima
Softbank Telecom Softbank Telecom
Tokyo Tokyo
Japan Japan
Email: satoru.matsushima@tm.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Tadahisa Okimoto Tadahisa Okimoto
NTT West NTT West
Osaka Osaka
Japan Japan
Email: t.okimoto@rdc.west.ntt.co.jp Email: t.okimoto@west.ntt.co.jp
Dan Wing Dan Wing
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose San Jose
USA USA
Email: dwing@cisco.com Email: dwing@cisco.com
 End of changes. 33 change blocks. 
132 lines changed or deleted 160 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/