draft-troan-ipv6-multihoming-without-ipv6nat.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 RFC3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.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 RFC5006 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5006.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3022.xml">
<!ENTITY I-D.dec-dhcpv6-route-option SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-dec-dhcpv6-route-option-03.xml'>
<!ENTITY I-D.ietf-6man-addr-select-sol SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6man-addr-select-sol-03.xml'>
<!ENTITY I-D.fujisaki-dhc-addr-select-opt SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-fujisaki-dhc-addr-select-opt-09.xml'>
<!ENTITY I-D.savolainen-mif-dns-server-selection SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-savolainen-mif-dns-server-selection-02.xml'>
<!ENTITY I-D.mrw-behave-nat66 SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mrw-behave-nat66-02.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-troan-multihoming-without-nat66-01"
     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>Bergen</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 Corp.</organization>
      <address>
	<postal>
          <street></street>
	  <city>Tokyo</city>
	  <country>Japan</country>
	</postal>
	<email>satoru.matsushima@tm.softbank.co.jp</email>
      </address>
    </author>

    <author fullname="Tadahisa Okimoto" initials="T." surname="Okimoto">
      <organization>NTT</organization>
      <address>
	<postal>
          <street></street>
	  <city>Tokyo</city>
	  <country>Japan</country>
	</postal>
	<email>t.okimoto@hco.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="July" year="2010" />

    <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 IPv6 NAT. However, NAT should be avoided, if
      at all possible, to permit transparent host-to-host
      connectivity. In this document, we analyze the use cases of
      multihoming. We also describe functional requirements 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 .</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <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
      host-to-host transparent connectivity.</t>

      <t>Unfortunately, this may not be possible due to the necessity of NAT
      even in IPv6, because of multihoming.</t>

      <t>Multihoming is a blanket term to describe a host or small network
      that is connected to more than one upstream network. Whenever a host or
      small network (which does not meet minimum IPv6 allocation criteria) is
      connected to multiple upstream networks IPv6 addressing is assigned by
      each respective service provider resulting in hosts with more than one
      active IPv6 address. As each service provided 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 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. To reach
      this goal, 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
      appropriately select next-hop for each connected
      network. 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 also becomes difficult whenever a
      host has more than one address within 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 uRPF, it is conceivable that the packets that
      have 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 resolver 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 identical-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, which
      receives all DNS inquires, and gives a correct answer to the
      host.</t>

      <t>In this document, we identify the functions present in multihomed
      IPv4 NAPT environments and propose requirements that address multihomed
      IPv6 environments without using IPv6 NAT.</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="NAT66 or IPv6 NAT">The terms "NAT66" and "IPv6
	NAT" refer to <xref target="I-D.mrw-behave-nat66"></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, which provides independent address
        assignment and DNS resolvers. A host in this environment would be
        offered multiple prefixes and DNS resolvers advertised from the two
        different routers.</t>

        <figure align="center" anchor="multihome_architecture1"
          title="single uplink, multiple next-hop,
          multiple prefix (Scenario&#160;1)">
          <preamble></preamble>

          <artwork align="center"><![CDATA[
                 +------+       ___________
                 |      |      /           \
             +---| rtr1 |=====/   network   \
             |   |      |     \      1      /
+------+     |   +------+      \___________/
|      |     |
| host |-----+
|      |     |
+------+     |   +------+       ___________
             |   |      |      /           \
             +---| 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., broadband service (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 from each independent service provider
        network and a different set of DNS resolvers. The gateway in turn
        advertises the provider prefixes to the host, and for DNS, may either
        act as a lightweight DNS resolver/cache or may advertise the complete
        set of service provider DNS resolvers to the hosts.</t>

        <figure align="center" anchor="multihome_architecture2"
title="single uplink, single next-hop, multiple prefix (Scenario&#160;2)">
          <preamble></preamble>

          <artwork align="center"><![CDATA[
                           +------+       ___________
                           |      |      /           \
                       +---| rtr1 |=====/   network   \
                       |   |      |     \      1      /
+------+     +-----+   |   +------+      \___________/
|      |     |     |   |
| host |-----| GW  |---+
|      |     | rtr |   |
+------+     +-----+   |   +------+       ___________
                       |   |      |      /           \
                       +---| 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 rtr1 and rtr2, respectively. 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 rtr1 (rtr2).</t>

        <t>- e.g, Internet + VPN/ASP</t>

        <t>Scenario 3:</t>

        <t>In this scenario, a host has more than one active interfaces that
        connects to different routers and service provider networks. Each
        router provides the host with a different address prefix and set of
        DNS resolvers, 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&#160;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 resolvers 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 commonly implemented
        through the use of a gateway router with NAPT function
        (scenario 2 with NAPT). 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 |     |     |   |
| host |-----| GW  |---+
|      |     | rtr |   |
+------+     +-----+   |   +------+       ___________
            (NAPT&DNS) |   |      |      /           \
(private               +---| rtr2 |=====/   network   \
    address                |      |     \      2      /
       space)              +------+      \___________/
            ]]></artwork>
        </figure>
      </section>

      <section title="Multihomed Problem Statement">
        <t>A multihomed IPv6 host has one or more assigned IPv6 addresses and
        DNS resolvers from each upstream service provider, resulting in the
        host having multiple valid IPv6 addresses and DNS resolvers. The host
        must be able to resolve the appropriate next-hop, the correct source
        address and DNS resolver to use based on the destination prefix. To
        prevent IP spoofing, operators will often implement IP filters and uRPF
        to discard traffic with an inappropriate source address, making it
        essential for the host to correctly resolve these three criteria
        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. Upstream uRPF 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. Upstream uRPF or
	  filter policies will discard traffic with source addresses
	  that the operator did not assign.</t>

	  <t>The gateway router does not have a mechanism for
	  determining which traffic should be sent to which
	  network. If the gateway router is implementing host
	  functions (ie, processing RA) 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.</t>

	  <t>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>The host may use an incorrect DNS resolver for DNS
	  queries.</t>
	</list></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
      without employing IPv6 NAT.</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 &amp; 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="RFC3484"></xref> may not deterministically resolve the
        correct source address when the host addressing was via RA or
        DHCPv6. <xref target="I-D.ietf-6man-addr-select-sol"></xref>
        describes the use of the policy table <xref
        target="RFC3484"></xref> to resolve this problem, but
        there is no mechanism defined to disseminate the policy table
        information to a host. A proposal is in <xref
        target="I-D.fujisaki-dhc-addr-select-opt"></xref> to provide 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>
      </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 a host and router 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. A DHCPv6 option, such as 
        that in <xref
        target="I-D.dec-dhcpv6-route-option"></xref>, is preferred for
        host-specific configuration. By employing a DHCPv6 solution, a
        DHCPv6 server could restrict address assignment (of additional
        prefixes) only to hosts that support more advanced next-hop
        and address selection requirements.</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 server selection">
        <t>A multihomed IPv6 host or gateway router may be provided
        multiple DNS resolvers through DHCPv6 or the experimental
        <xref target="RFC5006"></xref>. When the host or gateway
        router sends a DNS query, it would normally choose one of the
        available DNS resolvers for the query.</t>

        <t>In the IPv6 gateway router scenario, the Broadband Forum
        <xref target="TR124"></xref> required that the query be sent
        to all DNS resolvers, 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 resolver selection. Doing so can minimize DNS resolver
        load and avoid issues where DNS resolvers in different
        networks have connectivity issues, or the DNS resolvers are
        not publicly accessible. In the worst case, a DNS query may be
        unanswered if sent towards an incorrect resolver, resulting in
        a lack of connectivity.</t>

        <t>An IPv6 multihomed host or gateway router should have the
        ability to select appropriate DNS resolvers for each service
        based on the domain space for the destination, and each
        service should provide rules specific to that network. <xref
        target="I-D.savolainen-mif-dns-server-selection"></xref>
        proposes a solution for DNS server selection policy
        enforcement solution with 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>
      </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>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 enforcement">
        <t>The solution SHOULD have a function to enforce a policy on
        sites/nodes. In particular, in a managed environment such as enterprise
        networks, an administrator has to control all nodes in his or her
        network.</t>

        <t>The enforcement 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="implementation" title="Implementation approach">
      <t>As mentioned in <xref target="analysis"></xref>,
      in the multi-prefix environment, we have three problems in
      source address selection, next-hop selection, and DNS resolver
      selection. In this section, possible solution mechanisms for
      each problem are introduced and evaluated against the
      requirements in <xref target="requirements"></xref>.</t>

      <section title="Source address selection">

	<t>Possible solutions and their evaluation are summarized in
	<xref target="I-D.ietf-6man-addr-select-sol"></xref>. When
	those solutions are examined against the requirements in <xref
	target="requirements"></xref>, the proactive approaches, such
	as the policy table distribution mechanism and the routing
	system assistance 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
	staticness 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, the 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 router advertisement (RA) extension
	option defined in <xref target="RFC4191"></xref>, the DHCPv6
	route information option proposed in <xref
	target="I-D.dec-dhcpv6-route-option"></xref>, and the <xref
	target="TR069"></xref> standardized at BBF.</t>

	<t>The RA-based mechanism has difficulty in per-host routing
	information distribution. The dynamic routing protocols such as
	RIPng are not usually used between the residential users and
	ISP networks because of their scalability implications. The DHCPv6
	mechanism does not have these difficulties and has the
	advantages 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 resolver selection">

	<t>As in the above two problems, a policy-based approach
	and 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 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
	resolver 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 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 to resolve a FQDN of another
	provider's private service, and the DNS resolver 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 resolvers that are visible to the users.</t>

	<t>The alternative of a policy-based approach is documented in
	<xref
	target="I-D.savolainen-mif-dns-server-selection"></xref>,
	where several pairs of DNS resolver 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 proxy,
	interpret this option and distribute DNS queries to the
	appropriate DNS servers according to the policy.</t>
      </section>
    </section>

    <section anchor="legacy_host" title="Considerations for host without multi-prefix support">
      <t>This section presents an alternative approach to mitigate the
      problem in a multihomed network. This approach will help IPv6
      hosts that are not capable of the enhancements for the source
      address selection policy, next-hop selection policy, and DNS
      selection policy described in <xref
      target="implementation"></xref>.</t>

      <section title="IPv6 NAT">

	<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, IPv6 NAT can be used
	as a last resort for IPv6 multihomed network deployments where
	one needs to assign a single IPv6 address to a 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 IPv6 NAT are out of the
      scope of this document. They may be covered by another document
      under discussion <xref
      target="I-D.mrw-behave-nat66"></xref>.</t>
    </section>

    <section title="Co-exisitence consideration">

      <t>The above scenario relies on the assumption that only hosts
      without multi-prefix support are connected to the GW rtr in
      scenario 2.  To allow the coexistence 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 to achieve this is that GW-rtr identifies the hosts,
      and then assigns single prefix to non-MHMP hosts and assigns
      multiple prefix to MHMP hosts.  In this case, GW-rtr can
      perform IPv6 NAT only for the traffic from MHMP hosts if its
      source address is not appropriate.</t>

      <t>Another idea is that GW-rtr assigns multiple prefix to the
      both hosts, and it performs IPv6 NAT for the 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, 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>

  <section anchor="Security" title="Security Considerations">
      <t>This document does not define any new mechanisms. Each solution
      mechanisms should consider security risks independently. Security risks
      that occur as a result of combining solution mechanisms should be considered
      in another document.</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</t>
    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC3484;
      &RFC4861;
      &RFC4191;
      &I-D.dec-dhcpv6-route-option;
      &I-D.ietf-6man-addr-select-sol;
      &I-D.fujisaki-dhc-addr-select-opt;
      &I-D.savolainen-mif-dns-server-selection;
      &I-D.mrw-behave-nat66;
    </references>

    <references title="Informative References">
      &RFC3022;
      &RFC3442;
      &RFC4966;
      &RFC5006;
      <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>