One document matched: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> -->
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY RFC6724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml">
<!ENTITY RFC3582 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3582.xml">
<!ENTITY RFC3646 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml">
<!ENTITY RFC4116 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4116.xml">
<!ENTITY RFC4191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml">
<!ENTITY RFC4218 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4218.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!-- <!ENTITY RFC4966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4966.xml"> -->
<!ENTITY RFC3442 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3442.xml">
<!ENTITY RFC5206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5206.xml">
<!ENTITY RFC5533 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml">
<!ENTITY RFC6106 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6106.xml">
<!ENTITY RFC6296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6296.xml">
<!ENTITY RFC7078 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7078.xml'>
<!ENTITY RFC6731 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6731.xml'>
<!ENTITY RFC5220 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5220.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="IPv6 Multihoming without NAT">IPv6 Multihoming without
Network Address Translation</title>
<author fullname="Ole Troan" initials="O." role="editor" surname="Troan">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city>Oslo</city>
<country>Norway</country>
</postal>
<email>ot@cisco.com</email>
</address>
</author>
<author fullname="David Miles" initials="D." surname="Miles">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city>Melbourne</city>
<country>Australia</country>
</postal>
<email>david.miles@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<organization>Softbank Telecom</organization>
<address>
<postal>
<street></street>
<city>Tokyo</city>
<country>Japan</country>
</postal>
<email>satoru.matsushima@g.softbank.co.jp</email>
</address>
</author>
<author fullname="Tadahisa Okimoto" initials="T." surname="Okimoto">
<organization>NTT West</organization>
<address>
<postal>
<street></street>
<city>Osaka</city>
<country>Japan</country>
</postal>
<email>t.okimoto@west.ntt.co.jp</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<!-- -->
<date month="February" year="2014" />
<area>Internet</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword></keyword>
<abstract>
<t>Network Address and Port Translation (NAPT) works well for
conserving global addresses and addressing multihoming
requirements, because an IPv4 NAPT router implements three
functions: source address selection, next-hop resolution and
optionally DNS resolution. For IPv6 hosts one approach could be
the use of NPTv6. However, NAT should be avoided, if at all
possible, to permit transparent end-to-end connectivity. In this
document, we analyze the use cases of multihoming. We also
describe functional requirements and possible solutions for
multihoming without the use of NAT 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,
described in this document, while NPTv6 may be required as an
intermediate solution.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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:
<list style="numbers">
<t>IPv6 network prefix translation
(NPTv6, <xref target="RFC6296"></xref>), or;</t>
<t>refining IPv6 specifications to resolve the problems with IPv6
multihoming.</t>
</list>
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.</t>
<t>IPv6 provides enough globally unique addresses to permit every
conceivable host on the Internet to be uniquely addressed without
the requirement for Network Address Port Translation (<xref
target="RFC3022">NAPT</xref>), offering a renaissance in
end-to-end transparent connectivity.</t>
<t>Unfortunately, this may not be possible in every case, due to
the possible necessity of NAT even in IPv6, because of
multihoming. Though there are mechanisms to implement
multihoming, such as <xref target="RFC4116"> BGP
multihoming</xref> at the network level, and <xref
target="RFC4960">SCTP based multihoming</xref> in the transport
layer, there is no mechanism in IPv6 that serves as a
replacement for NAT based multihoming in IPv4. In IPv4, for a
host or a small network, NAT based multihoming is easily
deployable and an already deployed technique.</t>
<t>Whenever a host or small network (that does not meet minimum
IPv6 allocation criteria) is connected to multiple upstream
networks, an IPv6 address is assigned by each respective service
provider resulting in hosts with multiple global scope IPv6
addresses with different prefixes. As each service provider is
allocated a different address space from its Internet Registry,
it, in turn 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 simultaneously connect to a remote
network and retain a default route to the Internet for other
purposes.</t>
<t>In IPv4 a common solution to the multihoming problem is to
employ 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 address visible on the public network and the
combination of NAPT with provider-specific outside addresses
(one for each uplink) and destination-based routing insulates a
host from the impacts of multiple upstream networks. The border
router may also implement a DNS cache or DNS policy to resolve
address queries from hosts.</t>
<t>It is our goal to avoid the IPv6 equivalent of NAT. So, the
goals for IPv6 multihoming defined in <xref target="RFC3582">
</xref> do not match the goals of this document. Also regardless
of what the NPTv6 specification is, we are trying to avoid any
form of network address translation technique that may not be
visible to either of the end hosts. To reach this goal,
several mechanisms are needed for end-user hosts to have multiple
address assignments and resolve issues such as which address to
use for sourcing traffic to which destination:</t>
<t><list style="symbols"> <t>If multiple routers exist on a single
link the host must select the appropriate next-hop for each
connected network. Each router is in turn connected to a different
service provider network, which provides independent address
assignment. Routing protocols that would normally be employed for
router-to-router network advertisement seem inappropriate for use
by individual hosts.</t>
<t>Source address selection becomes difficult whenever a host
has more than one address of the same address scope.
Current address selection criteria, may result in hosts using an
arbitrary or random address when sourcing upstream traffic.
Unfortunately, for the host, the appropriate source address is a
function of the upstream network for which the packet is bound
for. If an upstream service provider uses IP anti-spoofing or
ingress filtering, it is conceivable that the packets that have
an inappropriate source address for the upstream network would
never reach their destination.</t>
<t>In a multihomed environment, different DNS scopes or partitions
may exist in each independent upstream network. A DNS query sent
to an arbitrary upstream DNS recursive name server may result in
incorrect or poisoned responses.</t>
</list></t>
<t>In short, while IPv6 facilitates hosts having more than one
address in the same address scope, the application of this
causes significant issues for a host; from routing, source
address selection and DNS resolution perspectives. A possible
consequence of assigning a host multiple identically-scoped
addresses is severely impaired IP connectivity.</t>
<t>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 NAT becomes the gateway of the host and forwards
the packet to an appropriate network when it is multihomed. It
also operates a DNS cache server or DNS proxy, which receives
all DNS inquires, and gives a correct answer to the host.</t>
</section>
<section title="Terminology">
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
-->
<t><list hangIndent="22" style="hanging">
<t hangText="NPTv6">IPv6-to-IPv6 Network Prefix Translation in <xref
target="RFC6296">NPTv6</xref>.</t>
<t hangText="NAPT">Network Address Port Translation as
described in <xref target="RFC3022"></xref>. In other
contexts, NAPT is often pronounced "NAT" or written as
"NAT".</t>
<t hangText="Multihomed with multi-prefix (MHMP)">A host
implementation which supports the mechanisms described in this
document. Namely source address selection policy, next-hop
selection and DNS selection policy.</t>
</list></t>
</section>
<section title="IPv6 multihomed network scenarios" anchor="multihomed-scenarios">
<t>In this section, we classify three scenarios of the
multihoming environment.</t>
<section anchor="classification" title="Classification of network scenarios for multihomed host">
<t>Scenario 1:</t>
<t>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 different service provider network, that
provides independent address assignment and DNS recursive name
servers. A host in this environment would be offered multiple
prefixes and DNS recursive name servers advertised from the
two different routers.</t>
<figure align="center" anchor="multihome_architecture1"
title="single uplink, multiple next-hop,
multiple prefix (Scenario 1)">
<preamble></preamble>
<artwork align="center"><![CDATA[
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ | +------+ \___________/
| | |
| hosts|-----+
| | |
+------+ | +------+ ___________
| | | / \
+---| rtr2 |=====/ network \
| | \ 2 /
+------+ \___________/
]]></artwork>
</figure>
<t><xref target="multihome_architecture1"></xref> illustrates
the host connecting to rtr1 and rtr2 via a shared
link. Networks 1 and 2 are reachable via rtr1 and rtr2
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.</t>
<t>- e.g., multiple broadband service providers (Internet, VoIP, IPTV, etc.)</t>
<t>Scenario 2:</t>
<t>In this scenario, a single gateway router connects the host
to two or more upstream service provider networks. This gateway
router would receive prefix delegations and a different set of
DNS recursive name servers from each independent service
provider network. The gateway 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 complete set
of service provider DNS recursive name servers to the hosts.</t>
<figure align="center" anchor="multihome_architecture2"
title="single uplink, single next-hop, multiple prefix (Scenario 2)">
<preamble></preamble>
<artwork align="center"><![CDATA[
+------+ ___________
+-----+ | | / \
| |=======| rtr1 |=====/ network \
| |port1 | | \ 1 /
+------+ | | +------+ \___________/
| | | |
| hosts|-----| GW |
| | | rtr |
+------+ | | +------+ ___________
| |port2 | | / \
| |-------| rtr2 |=====/ network \
+-----+ | | \ 2 /
+------+ \___________/
]]></artwork>
</figure>
<t><xref target="multihome_architecture2"></xref> illustrates
the host connected to GW rtr. GW rtr connects to networks 1 and
2 via port1 and 2 respectively. As the figure shows a logical
topology of the scenario, the port1 could be a pseudo interface
for tunneling, which connects to the network 1 through the
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).</t>
<t>- e.g, Internet + VPN/Application Service Provider (ASP)</t>
<t>Scenario 3:</t>
<t>In this scenario, a host has more than one active interface that
connects to different routers and service provider networks. Each
router provides the host with a different address prefix and set of
DNS recursive name servers, resulting in a host with a unique address per
link/interface.</t>
<figure align="center" anchor="multihome_architecture3"
title="Multiple uplink, multiple next-hop, multiple
prefix (Scenario 3)">
<preamble></preamble>
<artwork><![CDATA[
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
]]></artwork>
</figure>
<t>Figure 3 illustrates the host connecting to rtr1 and rtr2
via a direct connection or a virtual link. When the host sends
packets network 1, the next-hop to network 1 is rtr1. Similarly,
rtr2 is the next-hop to network 2.</t>
<t>- e.g., Mobile Wifi + 3G, ISP A + ISP B</t>
</section>
<section title="Multihomed network environment">
<t>In an IPv6 multihomed network, a host is assigned two or more
IPv6 addresses and DNS recursive name servers from independent
service provider networks. When this multihomed host attempts to
connect with other hosts, it may incorrectly resolve the
next-hop router, use an inappropriate source address, or use a
DNS response from an incorrect service provider that may result
in impaired IP connectivity.</t>
<t>Multihomed networks in IPv4 have been implemented through the
use of a gateway router with NAPT function (scenario 2 with
NAPT) in many cases. An analysis of the current IPv4 NAPT and
DNS functions within the gateway router should provide a
baseline set of requirements for IPv6 multihomed environments. A
destination prefix/route is often used on the gateway router to
separate traffic between the networks.</t>
<figure align="center" anchor="multihome_ipv4_architecture"
title="IPv4 Multihomed environment with Gateway Router
performing NAPT">
<preamble></preamble>
<artwork align="center"><![CDATA[
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ +-----+ | +------+ \___________/
| IPv4 | | | |
| hosts|-----| GW |---+
| | | rtr | |
+------+ +-----+ | +------+ ___________
(NAPT&DNS) | | | / \
(private +---| rtr2 |=====/ network \
address | | \ 2 /
space) +------+ \___________/
]]></artwork>
</figure>
</section>
<section title="Problem Statement">
<t>A multihomed IPv6 host has one or more assigned IPv6
addresses and DNS recursive name servers from each upstream
service provider, resulting in the host having multiple valid
IPv6 addresses and DNS recursive name servers. The host must be
able to resolve the appropriate next-hop, the correct source
address and DNS recursive name server to use based on the
destination prefix. To prevent IP spoofing, operators will often
implement ingress filtering to discard traffic with an
inappropriate source address, making it essential for the host
to correctly resolve these three items before sourcing the
first packet.</t>
<t>IPv6 has mechanisms for the provision of multiple routers
on a single link and multiple address assignments to a single
host. However, when these mechanisms are applied to the three
scenarios in <xref target="classification"></xref> a number of
connectivity issues are identified:</t>
<t>Scenario 1:</t>
<t>The host has been assigned an address from each router and
recognizes both rtr1 and rtr2 as valid default routers (in the
default routers list).</t>
<t><list style="symbols">
<t>The source address selection policy on the host does not
deterministically resolve a source address. Ingress filtering
or filter policies will discard traffic with source addresses
that the operator did not assign.</t>
<t>The host will select one of the two routers as the active
default router. No traffic is sent to the other router.</t>
</list></t>
<t>Scenario 2:</t>
<t>The host has been assigned two different addresses from the single
gateway router. The gateway router is the only default router on the
link.</t>
<t><list style="symbols">
<t>The source address selection policy on the host does not
deterministically resolve a source address. Ingress filtering
or filter policies will discard traffic with source addresses
that the operator did not assign.</t>
<t>The gateway router does not have an autonomous mechanism for
determining which traffic should be sent to which network. If the
gateway router is implementing host functions (i.e., processing
Router Advertisement) then two valid default routers may be
recognized.</t>
</list></t>
<t>Scenario 3:</t>
<t>A host has two separate interfaces and on each interface a
different address is assigned. Each link has its own router.</t>
<t><list style="symbols">
<t>The host does not have enough information for determining
which traffic should be sent to which upstream routers. The host
will select one of the two routers as the active default router,
and no traffic is sent to the other router. The default address
selection rules select the address assigned to the outgoing
interface as the source address. So, if a host has an appropriate
routing table, an appropriate source address will be
selected.</t>
</list></t>
<t>All scenarios:</t>
<t><list style="symbols">
<t>In network deployments utilizing local namespaces, the host may
choose to communicate with a "wrong" DNS recursive server unable
to serve a local namespace.</t>
</list></t>
</section>
</section>
<section anchor="requirements" title="Requirements">
<t>This section describes requirements that any solution multi-address
and multi-uplink architectures need to meet.</t>
<section title="End-to-End transparency">
<t>One of the major design goals for IPv6 is to
restore the end-to-end transparency of the
Internet. If NAT is applied to IP communication
between hosts, NAT traversal mechanism are required,
to establish bi-directional IP communication. A NAT
traversal mechanism does not need to be implemented in
an application, in an environment with end-to-end
transparency. Therefore, the IPv6 multihoming solution
should strive to avoid NPTv6 to achieve end-to-end
transparency.</t>
<!--
<t>End-to-end transparency is a basic concept of the
Internet. <xref target="RFC4966"></xref> states, "One of the
major design goals for IPv6 is to restore the end-to-end
transparency of the Internet. Therefore, because IPv6 is
expected to remove the need for NATs and similar impediments
to transparency, developers creating applications to work
with IPv6 may be tempted to assume that the complex
mechanisms employed by an application to work in a 'NATted'
IPv4 environment are not required." The IPv6 multihoming
solution SHOULD guarantee end-to-end transparency by
avoiding IPv6 NAT.</t>
-->
</section>
<!--
<section title="Policy distribution">
<t>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.</t>
<t>The providing mechanisms should have:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
-->
<section title="Scalability">
<t>The solution will have to be able to manage a large number of
sites/nodes. In services for residential users, provider edge devices
have to manage thousands of sites. In such environments, sending
packets periodically to each site may affect edge system
performance.</t>
</section>
</section>
<section anchor="analysis" title="Problem statement and analysis">
<t>The problems described in <xref
target="multihomed-scenarios"></xref> can be classified into
these three types:
<list style="symbols">
<t>Wrong source address selection</t>
<t>Wrong next-hop selection</t>
<t>Wrong DNS server selection</t>
</list></t>
<t>This section reviews the problem statements presented above
and the proposed functional requirements to resolve the issues.
</t>
<section title="Source address selection"> <t>A multihomed IPv6
host will typically have different addresses assigned from each
service provider either on the same link (scenarios 1 & 2)
or different links (scenario 3). When the host wishes to send a
packet to any given destination, the current source address
selection rules <xref target="RFC6724"></xref> may not
deterministically select the correct source address. <xref
target="RFC7078"></xref> describes the use of the policy table
<xref target="RFC6724"></xref> to resolve this problem, using a
DHCPv6 mechanism for host policy table management.</t>
<t>Again, by employing DHCPv6, the server could restrict address
assignment (of additional prefixes) only to hosts that support
policy table management.</t>
<t>Scenario 1: "Host" needs to support the solution for this
problem.</t>
<t>Scenario 2: "Host" needs to support the solution for this
problem.</t>
<t>Scenario 3: If "Host" support the next-hop selection
solution, there is no need to support the address selection
functionality on the host.</t>
<t>It is noted that the service providers (i.e., ISP and
enterprise/VPN) must also support <xref
target="RFC7078"></xref>.</t>
</section>
<section title="Next-hop selection">
<t>A multihomed IPv6 host or gateway may have multiple uplinks
to different service providers. Here each router would use
Router Advertisements <xref target="RFC4861"></xref> for
distributing default route/next-hop information to the host or
gateway router.</t>
<t>In this case, the host or gateway router may select any
valid default router from the default routers list, resulting
in traffic being sent to the wrong router and discarded by the
upstream service provider. Using the above scenarios as an
example, whenever the host wishes to reach a destination in
network 2 and there is no connectivity between networks 1 and
2 (as is the case for a walled-garden or closed
service), the host or gateway router does not know whether to
forward traffic to rtr1 or rtr2 to reach a destination in
network 2. The host or gateway router may choose rtr1 as the
default router, and traffic fails to reach the destination
server. The host or gateway router requires route information
for each upstream service provider, but the use of a routing
protocol between the gateway and the two routers causes both
configuration and scaling issues. For IPv4 hosts, the gateway
router is often pre-configured with static route information or
uses of Classless Static Route Options <xref
target="RFC3442"></xref> for DHCPv4. Extensions to Router
Advertisements through Default Router Preference and
More-Specific Routes <xref target="RFC4191"></xref> provides for
link-specific preferences but does not address per-host
configuration in a multi-access topology because of its reliance
on Router Advertisements.</t>
<t>Scenario 1: "Host" needs to support the solution for this
problem.</t>
<t>Scenario 2: "GW rtr" needs to support the solution for this
problem.</t>
<t>Scenario 3: "Host" needs to support the solution for this
problem.</t>
</section>
<section title="DNS recursive name server selection">
<t>A multihomed IPv6 host or gateway router may be provided
multiple DNS recursive name servers through <xref
target="RFC3646">DHCPv6</xref> or <xref target="RFC6106">
RA</xref>. 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.</t>
<t>In the IPv6 gateway router scenario, the Broadband Forum
<xref target="TR124"></xref> 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 specific
destination-based policy for both routing and source address
selection, it is desirable to extend a policy-based concept to
DNS recursive name server selection. Doing so can minimize DNS
recursive name server load and avoid issues where DNS recursive
name servers in different networks have connectivity issues, or
the DNS recursive 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 if sent towards a DNS server not
aware of said local namespace, resulting in a lack of
connectivity.</t>
<t>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 appropriate DNS recursive name servers for
each service based on the domain space for the destination,
and each service should provide rules specific to that
network. <xref target="RFC6731"></xref> proposes a solution
for distributing DNS server selection policy using a DHCPv6
option.</t>
<t>Scenario 1: "Host" needs to support the solution for this
problem.</t>
<t>Scenario 2: "GW rtr" needs to support the solution for this
problem.</t>
<t>Scenario 3: "Host" needs to support the solution for this
problem.</t>
<t>It is noted that the service providers (i.e., ISP and
enterprise/VPN) must also support <xref
target="RFC6731"></xref>.</t>
</section>
</section>
<section anchor="implementation" title="Implementation approach">
<t>As mentioned in <xref target="analysis"></xref>, in the
multi-prefix environment, we have three problems; source address
selection, next-hop selection, and DNS recursive name server
selection. In this section, possible solutions for each
problem are introduced and evaluated against the requirements in
<xref target="requirements"></xref>.</t>
<section title="Source address selection">
<t>The problems of address selection in multi-prefix
environments are summarized in <xref
target="RFC5220"></xref>. When solutions are examined against
the requirements in <xref target="requirements"></xref>, the
proactive approaches, such as the policy table distribution
mechanism and the routing hints mechanism, are more
appropriate in that they can propagate the network
administrator's policy directly. The policy distribution
mechanism has an advantage with regard to the host's protocol
stack impact and the static nature of the assumed target
network environment.</t>
</section>
<section title="Next-hop selection">
<t>As for the source address selection problem, both a
policy-based approach and a non policy-based approach are
possible with regard to the next-hop selection problem. Because
of the same requirements, the policy propagation-based solution
mechanism, whatever the policy, should be more
appropriate.</t>
<t>Routing information is a typical example of policy related
to next-hop selection. If we assume source address-based
routing at hosts or intermediate routers, pairs of source
prefixes and next-hops can be another example of next-hop
selection policy.</t>
<t>The routing information-based approach has a clear
advantage in implementation and is already commonly used. </t>
<t>The existing proposed or standardized routing information
distribution mechanisms are routing protocols, such as RIPng
and OSPFv3, the RA extension option defined in <xref
target="RFC4191"></xref>, and the <xref target="TR069"></xref>
standardized at BBF.</t>
<t>The RA-based mechanism doesn't handle distribution of
per-host routing information easily. Dynamic routing protocols
are not typically used between residential users and ISPs,
because of their scalability and security implications. The
DHCPv6 mechanism does not have these problems and has the
advantage of its relaying functionality. It is commonly used
and is thus easy to deploy.</t>
<t><xref target="TR069"></xref>, mentioned above, is a possible
solution mechanism for routing information distribution to
customer-premises equipment (CPE).
It assumes, however, IP reachability to the Auto
Configuration Server (ACS) is established. Therefore, if the CPE
requires routing information to reach the ACS, <xref
target="TR069"></xref> cannot be used to distribute this
information.</t>
</section>
<section title="DNS recursive name server selection">
<t><list style="empty"> <t>Note: Split-horizon DNS is
discussed in this section. Split-horizon DNS is known to
cause problems with applications to allow information leakage.
The discussion of split-horizon DNS is not condoning its use,
but rather acknowledging that split-horizon DNS 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).</t></list></t>
<t>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.</t>
<t>In the non policy-based approach, by making a query to a
DNS recursive name server in a different service provider to
that which hosts the service, a user could be directed to
unexpected IP address or receive an invalid response, and thus
cannot connect to the service provider's private and
legitimate service. For example, some DNS recursive name
servers reply with different answers depending on the source
address of the DNS query, which is sometimes called
split-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 private service, and the DNS
recursive name server adopts the split-horizon configuration,
the queried server returns an IP address of the non-private
side of the service. Another problem with this approach is
that it causes unnecessary DNS traffic to the DNS recursive
name servers that are visible to the users.</t>
<t>The alternative of a policy-based approach is documented in
<xref target="RFC6731"></xref>, where several pairs of DNS
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 an environment where there is a home gateway
router, that router can act as a DNS recursive name server,
interpret this option and distribute DNS queries to the
appropriate DNS servers according to the policy.</t>
</section>
<section anchor="other_algo" title="Other algorithms available in RFCs">
<t>The authors of this document are aware of a variety of other
algorithms and architectures, such as <xref
target="RFC5533">shim6</xref> and <xref target="RFC5206">HIP</xref>,
that may be useful in this environment. At this writing, there is not
enough operational experience on which to base a recommendation.
Should such operational experience become available, this document may
be updated in the future.</t>
</section>
</section>
<section anchor="legacy_host" title="Considerations for MHMP deployment">
<t>This section describes considerations to mitigate possible
problem in a network which implements MHMP described in <xref
target="implementation"></xref>.</t>
<section title="Non-MHMP host consideration">
<t>In a typical IPv4 multihomed network deployment, IPv4 NAPT
is practically used and it can eventually avoid assigning
multiple addresses to the hosts and solve the next-hop
selection problem. In a similar fashion, NPTv6 can be used
as a last resort for IPv6 multihomed network deployments where
one needs to assign a single IPv6 address to a non-MHMP host.</t>
<figure align="center" anchor="fig-legacy_host" title="Legacy Host">
<preamble></preamble>
<artwork align="center"><![CDATA[
__________
/ \
+---/ Internet \
gateway router | \ /
+------+ +---------------------+ | \__________/
| | | | | WAN1 +--+
| host |-----|LAN| Router |--------|
| | | | |NAT|WAN2+--+
+------+ +---------------------+ | __________
| / \
+---/ ASP \
\ /
\__________/
]]></artwork>
<postamble></postamble>
</figure>
<t>The gateway router also has to support the two features,
next-hop selection and DNS server selection, shown in <xref
target="implementation"></xref>.</t>
<t>The implementation and issues of NPTv6 are out of the scope
of this document. They may be covered by another document under
discussion <xref target="RFC6296"></xref>.</t>
</section>
<section title="Co-existence considerations">
<t>To allow the co-existence of non-MHMP hosts and MHMP hosts
(i.e. hosts supporting multi-prefix with the enhancements for
the source address selection), GW-rtr may need to treat those
hosts separately.</t>
<t>An idea for how to achieve this, is that GW-rtr identifies the
hosts, and then assigns a single prefix to non-MHMP hosts and
assigns multiple prefixes to MHMP hosts. In this case, GW-rtr
can perform IPv6 NAT only for the traffic from non-MHMP hosts if
its source address is not appropriate.</t>
<t>Another idea is that GW-rtr assigns multiple prefixes to both
hosts, and performs IPv6 NAT for traffic from non-MHMP
hosts if its source address is not appropriate.</t>
<t>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 the NAT box.</t>
<t>The implementation of identifying non-MHMP hosts and NAT policy
is outside the scope of this document.</t>
</section>
<section title="Policy collision consideration">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>This document requires that the solutions for MHMP should have
policy providing functions. New security threats can be
introduced 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 distributor side.</t>
<t>A policy receiver may receive an evil policy from a policy
distributor. A policy distributor should expect some hosts in its
network do not follow the distributed policy. At the time of
writing, there are no known methods to resolve conflicts between
the 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:</t>
<t><list style="hanging">
<t hangText="Threats related to the policy distributor side:">
<list>
<t>Service provider should expect the existence of hosts
that will not obey the received policy. A possible solutions
is to ingress-filter those packets that do not match the
distributed policy and drop them. About the route selection,
packet forwarding or redirection can be another possible
solution. About the source address selection, IPv6 NAT can
be another possible solution.</t>
<t>Administrators of different networks might need to
control policies (and nodes' behaviors) independently of
other administrators. It means that the need to have access
controls for such cross-administrative policy
access. Administrators must control only nodes that are part
of their own networks, or some administrators must control
only nodes that are part of 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.</t>
</list>
</t>
<t hangText="Threats related to the policy receiver side:">
<list>
<t>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.</t>
<t>A policy receiver are exposed to the threats of
unauthorized policy, which can lead to session hijack,
falsification, DoS, wiretapping and phishing. Unauthorized
policy here means a policy distributed from an entity that
does not have rights to do so. Usually, only a site
administrator and a network service provider have rights to
distribute these policies just as well as IP address
assignment and DNS server address notification. Regarding
source address selection, unauthorized policy can expose an
IP address that will not usually be exposed to an external
server, which can be a privacy problem. To solve or mitigate
this problem of unauthorized policy, one approach is
limiting on use of these policy distribution mechanisms, as
described in the section 4.4 of <xref
target="RFC6731"></xref>. For example, a policy should be
preferred or accepted when the policy is verified its
integrity and delivered across a secure, trusted channel
such as 3G connection in cellular services. The proposed
solutions are based on DHCP, so the limitation of local site
communication, which is often used in WiFi access services,
should be another solution or mitigation for this
problem. About DNS server selection issue, DNSSEC can be
another solution. About source address selection, the
ingress filter at the network service provider router can be
a solution.</t>
<t>Another threat is the leakage of the policy and privacy
issues resulting from that. Especially when each client is
distributed its own policy from the network service
provider, the policy can give a hint of which service the
client subscribes. Encryption of communication channel,
separation of communication channel per host can be
solutions for this problem.
</t>
</list>
</t>
</list>
</t>
<t>The security threats related to IPv6 multihoming are described
in <xref target="RFC4218"></xref>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA actions.</t>
</section>
<section title="Contributors">
<t>The following people contributed to this document: Akiko Hattori,
Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki,
Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley,
Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has
greatly benefited from inputs by Randy Bush, Brian Carpenter, and
Teemu Savolainen.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!-- &RFC2119; -->
&RFC6724;
&RFC4861;
&RFC4191;
&RFC6296;
&RFC7078;
&RFC6731;
</references>
<references title="Informative References">
&RFC3022;
&RFC3442;
&RFC3582;
&RFC3646;
&RFC4116;
&RFC4218;
&RFC4960;
&RFC5206;
&RFC5220;
&RFC5533;
<!-- &RFC4966; -->
&RFC6106;
<reference anchor="TR069">
<front>
<title>TR-069, CPE WAN Management Protocol v1.1, Version: Issue
1 Amendment 2</title>
<author><organization>The BroadBand Forum</organization></author>
<date month="December" year="2007"/>
</front>
<format type='PDF'
target='http://www.broadband-forum.org/technical/download/TR-069_Amendment-2.pdf' />
</reference>
<reference anchor="TR124">
<front>
<title>TR-124i2, Functional Requirements for Broadband
Residential Gateway Devices (work in progress)</title>
<author><organization>The BroadBand Forum</organization></author>
<date month="May" year="2010"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2010-03-23 OT Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:36:30 |