<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
                                 string such as <29> printed in the blank line at the
                                 beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC
         if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
         Some like symbolic tags in the references (and citations) and others prefer
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. --> version='1.0' encoding='utf-8'?>
<!-- These two save paper: Just setting compact converted to "yes" makes savings by not starting each
         main section on a new page but does not omit the blank lines between list items.
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions v3:  xml2rfc v2v3 conversion 2.32.0 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc category="info"
xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-rtgwg-enterprise-pa-multihoming-12"
     ipr="trust200902">
number="8678"
updates=""
obsoletes=""
category="info"
submissionType="IETF"
consensus="true"
ipr="trust200902"
sortRefs="true"
symRefs="true"
xml:lang="en"
tocInclude="true"
version="3">
  <front>
    <title abbrev="Enterprise PA Multihoming">Enterprise Multihoming using Using
    Provider-Assigned IPv6 Addresses without Network Prefix Translation:
    Requirements and Solutions</title>
    <seriesInfo name="RFC" value="8678"/>
    <author fullname="Fred Baker" initials="F.J." initials="F" surname="Baker">
      <address>
        <postal>
          <street/>
          <city>Santa Barbara</city>
          <code>93117</code>
          <region>California</region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>FredBaker.IETF@gmail.com</email>
      </address>
    </author>
    <author fullname="Chris Bowers" initials="C." initials="C" surname="Bowers">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <city>Sunnyvale</city>
          <code>94089</code>
          <region>California</region>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>cbowers@juniper.net</email>
      </address>
    </author>
    <author fullname="Jen Linkova" initials="J." initials="J" surname="Linkova">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1 Darling Island Rd</street>
          <city>Pyrmont</city>
          <region>NSW</region>
          <code>2009</code>
          <country>AU</country>
          <country>Australia</country>
        </postal>

        <phone></phone>
        <phone/>
        <email>furry@google.com</email>
      </address>
    </author>

    <date/>
    <date year="2019" month="December"></date>
    <area>Routing Area</area>
    <workgroup>Routing Working Group</workgroup>

    <abstract>
      <t>Connecting an enterprise site to multiple ISPs over IPv6 using
      provider-assigned addresses is difficult without the use of some form of
      Network Address Translation (NAT). Much has been written on this topic
      over the last 10 to 15 years, but it still remains a problem without a
      clearly defined or widely implemented solution. Any multihoming solution
      without NAT requires hosts at the site to have addresses from each ISP
      and to select the egress ISP by selecting a source address for outgoing
      packets. It also requires routers at the site to take into account those
      source addresses when forwarding packets out towards the ISPs.</t>
      <t>This document examines currently available mechanisms for providing a solution
to this problem for a broad range of enterprise topologies.
      It covers the behavior of routers to forward traffic by taking into account
      source address, and it covers the behavior of hosts to select appropriate
      default source addresses. It also covers any possible role that routers might
      play in providing information to hosts to help them select appropriate
      source addresses. In the process of exploring potential solutions, this
      document also makes explicit requirements for how the solution would be
      expected to behave from the perspective of an enterprise site network
      administrator.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Site multihoming, the connection of a subscriber network to multiple
      upstream networks using redundant uplinks, is a common enterprise
      architecture for improving the reliability of its Internet connectivity.
      If the site uses provider-independent (PI) addresses, all traffic
      originating from the enterprise can use source addresses from the PI
      address space. Site multihoming with PI addresses is commonly used with
      both IPv4 and IPv6, and does not present any new technical
      challenges.</t>
      <t>It may be desirable for an enterprise site to connect to multiple
      ISPs using provider-assigned (PA) addresses, addresses instead of PI addresses.
      Multihoming with provider-assigned addresses is typically less expensive
      for the enterprise relative to using provider-independent addresses as it does not
      require obtaining and maintaining PI address space as well as nor does it require
      running BGP between the enterprise and the ISPs (for small/meduim networks small/medium networks,
      running BGP might be not just only  undesirable but also impossible, especially if
      residential-type ISP connections are used).
      PA multihoming is also a practice that should be facilitated and encouraged
      because it does not add to the size of the Internet routing table,
      whereas PI multihoming does. Note that PA is also used to mean
      "provider-aggregatable". In this document document, we assume that
      provider-assigned addresses are always provider-aggregatable.</t>
      <t>With PA multihoming, for each ISP connection, the site is assigned a
      prefix from within an address block allocated to that ISP by its
      National or Regional Internet Registry. In the simple case of two ISPs
      (ISP-A and ISP-B), the site will have two different prefixes assigned to
      it (prefix-A and prefix-B). This arrangement is problematic. First,
      packets with the "wrong" source address may be dropped by one of the
      ISPs. In order to limit denial of service denial-of-service attacks using spoofed source
      addresses, <xref target="RFC2827">BCP38</xref> target="RFC2827" format="default"/> recommends that ISPs
      filter traffic from customer sites to only allow only traffic with a source
      address that has been assigned by that ISP. So a packet sent from a
      multihomed site on the uplink to ISP-B with a source address in prefix-A
      may be dropped by ISP-B.</t>
      <t>However, even if ISP-B does not implement BCP38 BCP 38, or ISP-B adds
      prefix-A to its list of allowed source addresses on the uplink from the
      multihomed site, two-way communication may still fail. If the packet
      with a source address in prefix-A was sent to ISP-B because the uplink to
      ISP-A failed, then if ISP-B does not drop the packet packet, and the packet
      reaches its destination somewhere on the Internet, the return packet
      will be sent back with a destination address in prefix-A. The return
      packet will be routed over the Internet to ISP-A, but it will not be
      delivered to the multihomed site because the site uplink with ISP-A has failed.
      Two-way communication would require some arrangement for ISP-B to
      advertise prefix-A when the uplink to ISP-A fails.</t>
      <t>Note that the same may be true with of a provider that does not
      implement BCP 38, even if his upstream provider does, or of a provider
      that has no corresponding route to deliver the ingress traffic
      to the multihomed site. The issue is not that the immediate provider implements ingress
      filtering; it is that someone upstream does (so egress traffic is blocked), blocked) or lacks a route (causing blackholing of the ingress traffic).</t>
      <t>
      Another issue with asymmetric traffic flow (when the egress traffic
      leaves the site via one ISP ISP, but the return traffic enters the site
      via another uplink) is related to stateful firewalls/middleboxes.
      Keeping state in that case might be problematic, even impossible.
</t>

      <t>With IPv4, this problem is commonly solved by using <xref
      target="RFC1918"/> private address
      space described in <xref target="RFC1918" format="default"/> within the multi-homed multihomed site and
      Network Address Translation (NAT) or Network Address/Port Translation
      (NAPT) <xref target="RFC2663"/> on the uplinks to the ISPs. However, one of the goals of IPv6 is
      to eliminate the need for and the use of NAT or NAPT. Therefore,
      requiring the use of NAT or NAPT for an enterprise site to multihome
      with provider-assigned addresses is not an attractive solution.</t>
      <t><xref target="RFC6296"/> target="RFC6296" format="default"/> describes a translation solution
      specifically tailored to meet the requirements of multi-homing multihoming with
      provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix
      Translation (NPTv6) solution, within the site an enterprise can use either
      Unique Local Addresses <xref target="RFC4193"/> target="RFC4193" format="default"/> or the prefix assigned
      by one of the ISPs. ISPs within its site. As traffic leaves the site on an uplink to an ISP,
      the source address gets is translated in a predictable and reversible manner
      to an address within the prefix assigned by the ISP on that uplink in a predictable and reversible
      manner. uplink.
      <xref target="RFC6296"/> target="RFC6296" format="default"/> is currently classified as
      Experimental, and it has been implemented by several vendors.
      See <xref
      target="sec_nptv6"/>, target="sec_nptv6" format="default"/> for more discussion of NPTv6.</t>
      <t>This document defines routing requirements for enterprise multihoming multihoming.
      This document focuses on the following general class of
      solutions.</t>
      <t>Each host at the enterprise has multiple addresses, at least one from
      each ISP-assigned prefix. Each host, as As discussed in <xref
      target="sec_host_address_selection_algo"/> target="sec_host_address_selection_algo" format="default"/>
      and in <xref target="RFC6724"/>, target="RFC6724" format="default"/>, each host
      is responsible for choosing the source address that is applied to each packet it
      sends. A host is expected to be able to respond dynamically to the failure of an
      uplink to a given ISP by no longer sending packets with the source
      address corresponding to that ISP. Potential mechanisms for the
      communication of changes in the
      communicating network changes to the host are Neighbor
      Discovery Router Advertisements (<xref target="RFC4861"/>), <xref target="RFC4861" format="default"/>, DHCPv6 (<xref target="RFC8415"/>), <xref target="RFC8415" format="default"/>, and ICMPv6 (<xref target="RFC4443"/>).</t> <xref target="RFC4443" format="default"/>.</t>

      <t>The routers in the enterprise network are responsible for ensuring
      that packets are delivered to the "correct" ISP uplink based on source
      address. This requires that at least some routers in the site network
      are able to take into account the source address of a packet when
      deciding how to route it. That is, some routers must be capable of some
      form of Source Address Dependent Routing (SADR), if only as described in
      the section 4.3 of
      <xref target="RFC3704"/>. target="RFC3704" sectionFormat="of" section="4.3" format="default"/>. At a minimum, the routers connected to the ISP
      uplinks (the site exit routers or SERs) must be capable of Source
      Address Dependent Routing. Expanding the connected domain of routers
      capable of SADR from the site exit routers deeper into the site network
      will generally result in more efficient routing of traffic with external
      destinations.</t>
      <t>This document is organized as follows. <xref target="sec_enterprise_req"/> target="sec_enterprise_req" format="default"/> looks in more detail at the
		enterprise networking environments in which this solution is expected to
		operate. The discussion of <xref target="sec_enterprise_req"/> target="sec_enterprise_req" format="default"/> uses the concepts of
		source-prefix-scoped routing
		Source-Prefix-Scoped Routing advertisements and forwarding tables
		and provides a description of describes how
		source-prefix-scoped routing
		Source-Prefix-Scoped Routing advertisements are used to generate
		source-prefix-scoped forwarding tables. Instead, this A detailed
		description of generating source-prefix-scoped forwarding tables is provided in
                <xref target="sec_method"/>. target="sec_method" format="default"/>. <xref target="sec_host_mechanisms"/> target="sec_host_mechanisms" format="default"/>
		discusses existing and proposed mechanisms for hosts to
		select the default source address to be used by applications.
		It also discusses the requirements for routing that are needed to
		support these enterprise network scenarios and the mechanisms by
		which hosts are expected to update default source addresses based
		on network state.
		<xref target="sec_deployment"/> target="sec_deployment" format="default"/> discusses deployment considerations, while <xref target="sec_other_solutions"/> target="sec_other_solutions" format="default"/> discusses other solutions.</t>
    </section>
    <section title="Requirements Language">
	    <t>The numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section title="Terminology">
	    <t>
		    PA numbered="true" toc="default">
      <name>Terminology</name>
        <dl>
          <dt>PA (provider-assigned or provider-aggregatable) address space: a space:</dt>
          <dd>a block of IP addresses assigned by an a Regional Internet Registry (RIR)
              to a Local Internet Registry (LIR), used to create allocations to end sites.
              Can be aggregated and present in the routing table as one route.
	    </t>
	    <t>
		    PI route.</dd>
          <dt>PI (provider-independent) address space: a space:</dt>
          <dd>a block of IP addresses assigned by an a Regional Internet Registry
	  (RIR) directly to end site/end customer.
	    </t>
	    <t>
		    ISP: Internet site / end customer.</dd>
          <dt>ISP:</dt>
          <dd>Internet Service Provider.
	    </t>
	    <t>
		    LIR Provider</dd>
          <dt>LIR (Local Internet Registry): an organisation Registry):</dt>
          <dd>an organization (usually an ISP or an enterprise/academic) which that receives
              its allocation of IP addresses allocation from its Regional Internet Regsitry, Registry, then assign assigns parts of that allocation to its customers.
	    </t>
	    <t>
		    RIR customers.</dd>
          <dt>RIR (Regional Internet Registry): an Registry):</dt>
          <dd>an organization which that manages the Internet number resources (such
	  as IP addresses and AS autonomous system (AS) numbers)
              within a geographical region of the world.
	    </t>
	    <t>
		    SADR world.</dd>
          <dt>SADR (Source Address Dependent Routing): Routing which Routing):</dt>
          <dd>routing that takes into account the source address of a packet in addition to the packet destination address.
	    </t>
	    <t>
		    SADR domain: a address.</dd>
          <dt>SADR domain:</dt>
          <dd>a routing domain where in which some (or all) routers exchange source-dependent routing information.
	    </t>
	    <t>
		    Source-Prefix-Scoped information.</dd>
          <dt>Source-Prefix-Scoped Routing/Forwarding Table: a Table:</dt>
          <dd>a routing (or forwarding) table which that contains routing (or forwarding) information which is only
              applicable to packets with source addresses from the specific prefix only.
	    </t>
	    <t>
		    Unscoped prefix.</dd>
          <dt>Unscoped Routing/Forwarding Table:  a Table:</dt>
          <dd>a routing (or forwarding) table which that can be used to route/forward packets with any source addresses.
	    </t>
	    <t>
		    SER address.</dd>
          <dt>SER (Site Edge Router): a Router):</dt>
          <dd>a router which that connects the site to an ISP (terminates an ISP uplink)..
	    </t>
	    <t>
		    LLA uplink).</dd>
          <dt>LLA (Link-Local Address): Address):</dt>
          <dd>an IPv6 Unicast Address unicast address from the fe80::/10 prefix (<xref target="RFC4291"/>).
	    </t>
	    <t>
		    ULA <xref target="RFC4291" format="default"/>.</dd>
          <dt>ULA (Unique Local IPv6 Unicast Address): Address):</dt>
          <dd>an IPv6 unicast addresses address from the FC00::/7 prefix. They are globally unique and intended for
              local communications (<xref target="RFC4193"/>).
	    </t>
	    <t>
		    GUA <xref target="RFC4193" format="default"/>.</dd>
          <dt>GUA (Global Unicast Address): Address):</dt>
          <dd>a globally routable IPv6 addresses address of the global scope (<xref target="RFC4291"/>).
	    </t>
	    <t>
		    SLAAC <xref target="RFC4291" format="default"/>.</dd>
          <dt>SLAAC (IPv6 Stateless Address Autoconfiguration): a Autoconfiguration):</dt>
          <dd>a stateless process of configuring the network stack on IPv6 hosts (<xref target="RFC4862"/>).
	    </t>
	    <t>
		    RA <xref target="RFC4862" format="default"/>.</dd>
          <dt>RA (Router Advertisement): a Advertisement):</dt>
          <dd>a message sent by an IPv6 router to advertise its presence to hosts together with various
              network-related parameters required for hosts to perform SLAAC (<xref target="RFC4861"/>).
	    </t>
	    <t>
		    PIO <xref target="RFC4861" format="default"/>.</dd>
          <dt>PIO (Prefix Information Option): a Option):</dt>
          <dd>a part of an RA message containing information about IPv6 prefixes which that could be used by hosts
              to generate global IPv6 addresses (<xref target="RFC4862"/>).
	    </t>
	    <t>
		    RIO <xref target="RFC4862" format="default"/>.</dd>
          <dt>RIO (Route Information Option): a Option):</dt>
          <dd>a part of an RA message containing information about more specific IPv6 prefixes reachable
              via the advertising router (<xref target="RFC4191"/>).
	    </t> <xref target="RFC4191" format="default"/>.</dd>
</dl>
    </section>
    <section anchor="sec_enterprise_req"
             title="Enterprise numbered="true" toc="default">
      <name>Enterprise Multihoming Use Cases"> Cases</name>
      <section anchor="sec_simple_scenario"
               title="Simple numbered="true" toc="default">
        <name>Simple ISP Connectivity with Connected SERs"> SERs</name>
        <t>We start by looking at a scenario in which a site has connections
        to two ISPs, as shown in <xref target="fig_simple_scenario"/>. target="fig_simple_scenario" format="default"/>. The
        site is assigned the prefix 2001:db8:0:a000::/52 by ISP-A and prefix
        2001:db8:0:b000::/52 by ISP-B. We consider three hosts in the site.
        H31 and H32 are on a LAN that has been assigned subnets
        2001:db8:0:a010::/64 and 2001:db8:0:b010::/64. H31 has been assigned
        the addresses 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has
        been assigned 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a
        different subnet that has been assigned 2001:db8:0:a020::/64 and
        2001:db8:0:b020::/64.</t>
        <figure align="center" anchor="fig_simple_scenario"
                title="Simple anchor="fig_simple_scenario">
          <name>Simple ISP Connectivity With with Connected SERs"> SERs</name>

        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                                      2001:db8:0:1234::101   H101
                                                               |
                                                               |
2001:db8:0:a010::31                                        --------
2001:db8:0:b010::31                          ,-----.      /        \
                 +--+   +--+       +----+  ,'       `.   :          :
             +---|R1|---|R4|---+---|SERa|-+   ISP-A   +--+--        :
        H31--+   +--+   +--+   |   +----+  `.       ,'   :          :
             |                 |             `-----'     : Internet :
             |                 |                         :          :
             |                 |                         :          :
             |                 |                         :          :
             |                 |             ,-----.     :          :
        H32--+   +--+          |   +----+  ,'       `.   :          :
             +---|R2|----------+---|SERb|-+   ISP-B   +--+--        :
                 +--+          |   +----+  `.       ,'   :          :
                               |             `-----'     :          :
                               |                         :          :
                 +--+  +--+  +--+                         \        /
        H41------|R3|--|R5|--|R6|                          --------
                 +--+  +--+  +--+

2001:db8:0:a020::41
2001:db8:0:b020::41
]]></artwork>
        </figure>
        <t>We refer to a router that connects the site to an ISP as a site
        edge router (SER). Several other routers provide connectivity among the
        internal hosts (H31, H32, and H41), as well as connecting connect the internal
        hosts to the Internet through SERa and SERb. In this example example, SERa and
        SERb share a direct connection to each other.
        In <xref
        target="sec_simple_not_dir_conn"/>, target="sec_simple_not_dir_conn" format="default"/>, we consider a scenario where in which this
        is not the case.</t>
        <t>For the moment, we assume that the hosts are able to make good
        choices about which select
        suitable source addresses through some mechanism that
        doesn't involve the routers in the site network. Here, we focus on
        the primary task of the routed site network, which is to get packets
        efficiently to their destinations, while sending a packet to the ISP
        that assigned the prefix that matches the source address of the
        packet. In <xref target="sec_host_mechanisms"/>, target="sec_host_mechanisms" format="default"/>, we examine what role
        the routed network may play in helping hosts make good choices about select suitable
        source addresses for packets.</t>
        <t>With this solution, routers will need some form of Source Address
        Dependent Routing, which will be new functionality. It would be useful
        if an enterprise site does not need to upgrade all routers to support
        the new SADR functionality in order to support PA multi-homing. multihoming. We
        consider if whether this is possible and what are examine the tradeoffs trade-offs of not having
        all routers in the site support SADR functionality.</t>
        <t>In the topology in <xref target="fig_simple_scenario"/>, target="fig_simple_scenario" format="default"/>, it is
        possible to support PA multihoming with only SERa and SERb being
        capable of SADR. The other routers can continue to forward based only
        on destination address, and exchange routes that only consider
        destination address. In this scenario, SERa and SERb communicate
        source-scoped routing information across their shared connection. When
        SERa receives a packet with a source address matching prefix
        2001:db8:0:b000::/52 ,
        2001:db8:0:b000::/52, it forwards the packet to SERb, which forwards
        it on the uplink to ISP-B. The analogous behaviour behavior holds for traffic
        that SERb receives with a source address matching prefix
        2001:db8:0:a000::/52.</t>

        <t>In <xref target="fig_simple_scenario"/>, target="fig_simple_scenario" format="default"/>, when only SERa and SERb
        are capable of source address dependent routing, PA multi-homing multihoming will
        work. However, the paths over which the packets are sent will
        generally not be the shortest paths. The forwarding paths will
        generally be more efficient as when more routers are capable of SADR. For
        example, if R4, R2, and R6 are upgraded to support SADR, then they can
        exchange source-scoped routes with SERa and SERb. They will then know
        to send traffic with a source address matching prefix
        2001:db8:0:b000::/52 directly to SERb, without sending it to SERa
        first.</t>
      </section>
      <section anchor="sec_simple_not_dir_conn"
               title="Simple numbered="true" toc="default">
        <name>Simple ISP Connectivity Where SERs Are Not Directly Connected"> Connected</name>
        <t>In <xref target="fig_simple_not_dir_conn"/>, target="fig_simple_not_dir_conn" format="default"/>, we modify the topology
        slightly by inserting R7, so that SERa and SERb are no longer directly
        connected. With this topology, it is not enough to just enable SADR
        routing on SERa and SERb to support PA multi-homing. multihoming. There are two
        solutions to enable PA multihoming in this topology.</t>
        <figure align="center" anchor="fig_simple_not_dir_conn"
                title="Simple anchor="fig_simple_not_dir_conn">
          <name>Simple ISP Connectivity Where SERs Are Not Directly Connected"> Connected</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                                      2001:db8:0:1234::101    H101
                                                               |
                                                               |
2001:db8:0:a010::31                                        --------
2001:db8:0:b010::31                          ,-----.      /        \
                 +--+   +--+       +----+  ,'       `.   :          :
             +---|R1|---|R4|---+---|SERa|-+   ISP-A   +--+--        :
        H31--+   +--+   +--+   |   +----+  `.       ,'   :          :
             |                 |             `-----'     : Internet :
             |               +--+                        :          :
             |               |R7|                        :          :
             |               +--+                        :          :
             |                 |             ,-----.     :          :
        H32--+   +--+          |   +----+  ,'       `.   :          :
             +---|R2|----------+---|SERb|-+   ISP-B   +--+--        :
                 +--+          |   +----+  `.       ,'   :          :
                               |             `-----'     :          :
                               |                         :          :
                 +--+  +--+  +--+                         \        /
        H41------|R3|--|R5|--|R6|                          --------
                 +--+  +--+  +--+                              |
                                                               |
2001:db8:0:a020::41                   2001:db8:0:5678::501    H501
2001:db8:0:b020::41
]]></artwork>
        </figure>
        <t>One option is to effectively modify the topology by creating a
		logical tunnel between SERa and SERb, SERb by using GRE (<xref target="RFC7676"/>) Generic Routing
        Encapsulation (GRE) <xref target="RFC7676" format="default"/>, for example. Although
        SERa and SERb are not directly connected physically in this topology,
        they can be directly connected logically by a tunnel.</t>
        <t>The other option is to enable SADR functionality on R7. In this
        way, R7 will exchange source-scoped routes with SERa and SERb, making
        the three routers act as a single SADR domain. This illustrates the
        basic principle that the minimum requirement for the routed site
        network to support PA multi-homing multihoming is having all of the site exit
        routers be part of a connected SADR domain. Extending the connected
        SADR domain beyond that point can produce more efficient forwarding
        paths.</t>
      </section>
      <section anchor="sec_network_operator_expectations"
               title="Enterprise numbered="true" toc="default">
        <name>Enterprise Network Operator Expectations"> Expectations</name>
        <t>Before considering a more complex scenario, let's look in more
        detail at the reasonably simple multihoming scenario in <xref
        target="fig_simple_not_dir_conn"/> target="fig_simple_not_dir_conn" format="default"/> to understand what can reasonably
        be expected from this solution. As a general guiding principle, we
        assume an enterprise network operator will expect a multihomed network
        to behave as close as to a single-homed network as possible. So a
        solution that meets those expectations where possible is a good
        thing.</t>
        <t>For traffic between internal hosts and for traffic from outside the
        site to internal hosts, an enterprise network operator would expect
        there to be no visible change in the path taken by this traffic, since
        this traffic does not need to be routed in a way that depends on
        source address. It is also reasonable to expect that internal hosts
        should be able to communicate with each other using either of their
        source addresses without restriction. For example, H31 should be able
        to communicate with H41 using a packet with S=2001:db8:0:a010::31,
        D=2001:db8:0:b020::41, regardless of the state of uplink to ISP-B.</t>

        <t>These goals can be accomplished by having all of the routers in the
        network continue to originate normal unscoped destination routes for
        their connected networks. If we can arrange it so that these unscoped
	destination routes get are used for forwarding this traffic, then we will
	have accomplished the multihoming's goal of keeping not affecting the forwarding
	of traffic destined for internal hosts, unaffected by the multihoming solution.</t> hosts.</t>
        <t>For traffic destined for external hosts, it is reasonable to expect
        that traffic with a source address from the prefix assigned by ISP-A
        to follow the path to that the traffic would follow if there is were no
        connection to ISP-B. This can be accomplished by having SERa originate
        a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0) . D=::/0).
        If all of the routers in the site support SADR, then the path of
        traffic exiting via ISP-A can match that expectation. If some routers
        don't support SADR, then it is reasonable to expect that the path for
        traffic exiting via ISP-A may be different within the site. This is a
        tradeoff
        trade-off that the enterprise network operator may decide to make.</t>
        <t>It is important to understand how the behavior of this multihoming solution behaves
        when an uplink to one of the ISPs fails. To simplify this discussion,
        we assume that all routers in the site support SADR. We first start by
        looking at how the operation of the network operates when the uplinks to both ISP-A and
        ISP-B are functioning properly. SERa originates a source-scoped route
        of the form (S=2001:db8:0:a000::/52, D=::/0), and SERb is originates a
        source-scoped route of the form (S=2001:db8:0:b000::/52, D=::/0).
        These routes are distributed through the routers in the site, and they
        establish within the routers two set sets of forwarding paths for traffic
        leaving the site. One set of forwarding paths is for packets with
        source address addresses in 2001:db8:0:a000::/52. The other set of forwarding
        paths is for packets with source address addresses in 2001:db8:0:b000::/52. The
        normal destination routes routes, which are not scoped to these two source
        prefixes
        prefixes, play no role in the forwarding. Whether a packet exits the
        site via SERa or via SERb is completely determined by the source
        address applied to the packet by the host. So for example, when host
        H31 sends a packet to host H101 with (S=2001:db8:0:a010::31,
        D=2001:db8:0:1234::101), the packet will only be sent out the link
        from SERa to ISP-A.</t>
        <t>Now consider what happens when the uplink from SERa to ISP-A fails.
        The only way for the packets from H31 to reach H101 is for H31 to
        start using the source address for ISP-B. H31 needs to send the
        following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101).</t>
        <t>This behavior is very different from the behavior that occurs with
        site multihoming using PI addresses or with PA addresses using NAT. In
        these other multi-homing multihoming solutions, hosts do not need to react to
        network failures several hops away in order to regain Internet access.
        Instead, a host can be largely unaware of the failure of an uplink to
        an ISP. When multihoming with PA addresses and NAT, existing sessions
        generally need to be re-established reestablished after a failure since the external
        host will receive packets from the internal host with a new source
        address. However, new sessions can be established without any action
        on the part of the hosts.  Multihoming with PA addresses and NAT has created
		the expectation of a fairly quick and simple recovery from network failures.
		Alternatives should to be evaluated in terms of the speed and complexity
		of the recovery mechanism.</t>
        <t>Another example where the behavior of significant difference between this multihoming solution
        differs significantly from that of
        and multihoming with either PI address addresses or with
        PA addresses using NAT is in the ability of the enterprise network
        operator to route traffic over different ISPs based on destination
        address. We still consider the fairly simple network of
        <xref
        target="fig_simple_not_dir_conn"/> target="fig_simple_not_dir_conn" format="default"/> and assume that uplinks to both
        ISPs are functioning. Assume that the site is multihomed using PA
        addresses and NAT, and that SERa and SERb each originate a normal
        destination route for D=::/0, with the route origination dependent on
        the state of the uplink to the respective ISP.</t>
        <t>Now suppose it is observed that an important application running
        between internal hosts and external host H101 experience experiences much better
        performance when the traffic passes through ISP-A (perhaps because
        ISP-A provides lower latency to H101.) H101). When multihoming this site with
        PI addresses or with PA addresses and NAT, the enterprise network
        operator can configure SERa to originate into the site network a
        normal destination route for D=2001:db8:0:1234::/64 (the destination
        prefix to reach H101) that depends on the state of the uplink to
        ISP-A. When the link to ISP-A is functioning, the destination route
        D=2001:db8:0:1234::/64 will be originated by SERa, so traffic from all
        hosts will use ISP-A to reach H101 based on the longest destination
        prefix match in the route lookup.</t>

        <t>Implementing the same routing policy is more difficult with the PA
        multihoming solution described in this document since it doesn't use
        NAT. By design, the only way to control where a packet exits this
        network is by setting the source address of the packet. Since the
        network cannot modify the source address without NAT, the host must
        set it. To implement this routing policy, each host needs to use the
        source address from the prefix assigned by ISP-A to send traffic
        destined for H101. Mechanisms have been proposed to allow hosts to
        choose the source address for packets in a fine grained fine-grained manner. We
        will discuss these proposals in <xref target="sec_host_mechanisms"/>. target="sec_host_mechanisms" format="default"/>.
        However, interacting an enterprise network administrator would not expect to
        interact with host operating systems in some manner to ensure that a particular
        source address is chosen for a particular
        destination prefix is not what an enterprise network administrator
        would expect to have to do in order to implement this routing policy.</t>
      </section>
      <section anchor="sec_more_complex_isp_connectivity"
               title="More complex numbered="true" toc="default">
        <name>More Complex ISP connectivity"> Connectivity</name>
        <t>The previous sections considered two variations of a simple
        multihoming scenario where in which the site is connected to two ISPs offering
        only Internet connectivity. It is likely that many actual enterprise
        multihoming scenarios will be similar to this simple example. However,
        there are more complex multihoming scenarios that we would like this
        solution to address as well.</t>
        <t>It is fairly common for an ISP to offer a service in addition to
        Internet access over the same uplink. Two variations of this are
        reflected in <xref target="fig_isp_service"/>. target="fig_isp_service" format="default"/>. In addition to Internet
        access, ISP-A offers a service which that requires the site to access host
        H51 at 2001:db8:0:5555::51. The site has a single physical and logical
        connection with ISP-A, and ISP-A only allows access to H51 over that
        connection. So when H32 needs to access the service at H51 H51, it needs to
        send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) D=2001:db8:0:5555::51), and
        those packets need to be forward forwarded out the link from SERa to ISP-A.</t>
        <figure align="center" anchor="fig_isp_service"
                title="Internet access anchor="fig_isp_service">
          <name>Internet Access and services offered Services Offered by ISP-A and ISP-B "> ISP-B</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
                                      2001:db8:0:1234::101    H101
                                                               |
                                                               |
2001:db8:0:a010::31                                        --------
2001:db8:0:b010::31                          ,-----.      /        \
                 +--+   +--+       +----+  ,'       `.   :          :
             +---|R1|---|R4|---+---|SERa|-+   ISP-A   +--+--        :
        H31--+   +--+   +--+   |   +----+  `.       ,'   :          :
             |                 |             `-----'     : Internet :
             |                 |                |        :          :
             |                 |               H51       :          :
             |                 |     2001:db8:0:5555::51 :          :
             |               +--+                        :          :
             |               |R7|                        :          :
             |               +--+                        :          :
             |                 |                         :          :
             |                 |             ,-----.     :          :
        H32--+   +--+          |  +-----+  ,'       `.   :          :
             +---|R2|-----+----+--|SERb1|-+   ISP-B   +--+--        :
                 +--+     |       +-----+  `.       ,'   :          :
                        +--+                 `--|--'     :          :
2001:db8:0:a010::32     |R8|                    |         \        /
                        +--+                 ,--|--.       --------
                          |       +-----+  ,'       `.         |
                          +-------|SERb2|-+   ISP-B   |        |
                          |       +-----+  `.       ,'       H501
                          |                  `-----'  2001:db8:0:5678
                          |                     |               ::501
                  +--+  +--+                   H61
         H41------|R3|--|R5|           2001:db8:0:6666::61
                  +--+  +--+

2001:db8:0:a020::41
2001:db8:0:b020::41
]]></artwork>
        </figure>
        <t>ISP-B illustrates a variation on this scenario. In addition to
        Internet access, ISP-B also offers a service which that requires the site
        to access host H61. The site has two connections to two different
        parts of ISP-B (shown as SERb1 and SERb2 in
        <xref
        target="fig_isp_service"/>). target="fig_isp_service" format="default"/>). ISP-B expects Internet traffic to use the
        uplink from SERb1, while it expects traffic destined for
        the service at H61 to use the uplink from SERb2. For either uplink,
        ISP-B expects the ingress traffic to have a source address matching
        the prefix that it assigned to the site, 2001:db8:0:b000::/52.</t>
        <t>As discussed before, we rely completely on the internal host to set
        the source address of the packet properly. In the case of a packet
        sent by H31 to access the service in ISP-B at H61, we expect the
        packet to have the following addresses: (S=2001:db8:0:b010::31,
        D=2001:db8:0:6666::61). The routed network has two potential ways of
        distributing routes so that this packet exits the site on the uplink
        at SERb2.</t>
        <t>We could just rely on normal destination routes, without using
        source-prefix scoped
        source-prefix-scoped routes. If we have SERb2 originate a normal
        unscoped destination route for D=2001:db8:0:6666::/64, the packets
        from H31 to H61 will exit the site at SERb2 as desired. We should not
        have to worry about SERa needing to originate the same route, because
        ISP-B should choose a globally unique prefix for the service at
        H61.</t>
        <t>The alternative is to have SERb2 originate a source-prefix-scoped
        destination route of the form (S=2001:db8:0:b000::/52,
        D=2001:db8:0:6666::/64). From a forwarding point of view, the use of
        the source-prefix-scoped destination route would result in traffic
        with source addresses corresponding only to ISP-B being sent to SERb2.
        Instead, the use of the unscoped destination route would result in
        traffic with source addresses corresponding to ISP-A and ISP-B being
        sent to SERb2, as long as the destination address matches the
        destination prefix. It seems like either forwarding behavior would be
        acceptable.</t>
        <t>However, from the point of view of the enterprise network
        administrator trying to configure, maintain, and trouble-shoot troubleshoot this
        multihoming solution, it seems much clearer to have SERb2 originate
        the source-prefix-scoped destination route correspond corresponding to the service
        offered by ISP-B. In this way, all of the traffic leaving the site is
        determined by the source-prefix-scoped routes, and all of the traffic
        within the site or arriving from external hosts is determined by the
        unscoped destination routes. Therefore, for this multihoming solution
        we choose to originate source-prefix-scoped routes for all traffic
        leaving the site.</t>
      </section>
      <section anchor="sec_isps_and_pa_prefixes"
               title="ISPs numbered="true" toc="default">
        <name>ISPs and Provider-Assigned Prefixes"> Prefixes</name>
        <t>While we expect that most site multihoming involves connecting to
        only two ISPs, this solution allows for connections to an arbitrary
        number of ISPs to be supported. ISPs. However, when evaluating scalable
        implementations of the solution, it would be reasonable to assume that
	the maximum number of ISPs that a site would connect to is five (topologies with two redundant routers routers,
	each having two uplinks to different ISPs ISPs, plus a tunnel to a headoffice head office acting as fifth one are not unheard of).</t>
        <t>It is also useful to note that the prefixes assigned to the site by
        different ISPs will not overlap. This must be the case, since the
        provider-assigned addresses have to be globally unique.</t>
      </section>
      <section anchor="sec_simpler_topologies" title="Simplified Topologies"> numbered="true" toc="default">
        <name>Simplified Topologies</name>
        <t>The topologies of many enterprise sites using this multihoming
        solution may in practice be simpler than the examples that we have
        used. The topology in <xref target="fig_simple_scenario"/> target="fig_simple_scenario" format="default"/> could be
        further simplified by having directly connecting all hosts directly connected to the LAN
        connecting
        that connects the two site exit routers, SERa and SERb. The topology
        could also be simplified by having the connecting both uplinks to ISP-A and ISP-B both
        connected
        to the same site exit router. However, it is the aim of this
        document to provide a solution that applies to a broad a range of
        enterprise site network topologies, so this document focuses on providing
        a solution to the more general case. The simplified cases will also be
        supported by this solution, and there may even be optimizations that
        can be made for simplified cases. This solution however solution, however, needs to
        support more complex topologies.</t>
        <t>We are starting with the basic assumption that enterprise site
        networks can be quite complex from a routing perspective. However,
        even a complex site network can be multihomed to different ISPs with
        PA addresses using IPv4 and NAT. It is not reasonable to expect an
        enterprise network operator to change the routing topology of the site
        in order to deploy IPv6.</t>
      </section>
    </section>
    <section anchor="sec_method"
             title="Generating numbered="true" toc="default">
      <name>Generating Source-Prefix-Scoped Forwarding Tables"> Tables</name>
      <t>So far far, we have described in general terms how the SADR-capable routers in this
      solution that are capable of Source Address Dependent Routing will forward traffic by using both normal unscoped destination routes and
      source-prefix-scoped destination routes. Here we give a precise method
      for generating a source-prefix-scoped forwarding table on a router that
      supports SADR.</t>

      <t><list style="numbers">
          <t>Compute
      <ol spacing="normal" type="1">
        <li>Compute the next-hops for the source-prefix-scoped destination
          prefixes using only routers in the connected SADR domain. These are
          the initial source-prefix-scoped forwarding table entries.</t>

          <t>Compute entries.</li>
        <li>Compute the next-hops for the unscoped destination prefixes using
          all routers in the IGP. This is the unscoped forwarding table.</t>

  <t>
For table.</li>
        <li>For a given source-prefix-scoped forwarding table T (scoped to
       source prefix P), consider a source-prefix-scoped forwarding
       table T', whose source prefix P' contains P.  We call T the more
       specific source-prefix-scoped forwarding table, and T' the less
       specific source-prefix-scoped forwarding table.  We select
       entries in the less specific
source-prefix-scoped forwarding table T' to augment the more specific source-prefix-scoped forwarding table T
       based on the following rules.  If a destination prefix of an
       entry in the less specific
source-prefix-scoped forwarding table T' exactly matches the destination
       prefix of an existing entry in the more
specific source-prefix-scoped forwarding table T (including
       destination prefix length), then do not add the entry to the more specific
source-prefix-scoped
       forwarding table. table T.  If the destination prefix does NOT match an
       existing entry, then add the entry to the more
specific source-prefix-scoped forwarding table. table T.
       As the unscoped forwarding table is considered to be scoped
       to ::/0, this process will propagate routes from the unscoped
       forwarding table to the more specific source-prefix-scoped forwarding table. table T.  If there exist multiple
       source-prefix-scoped forwarding tables whose source prefixes
       contain P, these source-prefix-scoped forwarding tables should be
       processed in order from most specific to least specific.

  </t>
        </list></t> specific.</li>

      </ol>
      <t>The forwarding tables produced by this process are used in the following
	      way to forward packets. <list style="numbers">
		      <t>Select </t>
      <ol spacing="normal" type="1">
        <li>Select the most specific (longest prefix match) source-prefix-scoped forwarding table
			      that matches the source address of the packet (again, the unscoped
			      forwarding table is considered to be scoped to ::/0). </t>
		      <t>Look </li>
        <li>Look up the destination address of the packet in
			             the selected forwarding table to
				     determine the next-hop for the packet.
			     </t>
        </list></t> </li>
      </ol>
      <t>The following example illustrates how this process is used to create
      a forwarding table for each provider-assigned source prefix. We consider
      the multihomed site network in <xref target="fig_isp_service"/>. target="fig_isp_service" format="default"/>.
      Initially we assume that all of the routers in the site network support
      SADR. <xref target="fig_routes_originated"/> target="fig_routes_originated" format="default"/> shows the routes that are
      originated by the routers in the site network.</t>
      <figure align="center" anchor="fig_routes_originated"
              title="Routes anchor="fig_routes_originated">
        <name>Routes Originated by Routers in the Site Network"> Network</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
Routes originated by SERa:
(S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64)
(S=2001:db8:0:a000::/52, D=::/0)
(D=2001:db8:0:5555::/64)
(D=::/0)

Routes originated by SERb1:
(S=2001:db8:0:b000::/52, D=::/0)
(D=::/0)

Routes originated by SERb2:
(S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64)
(D=2001:db8:0:6666::/64)

Routes originated by R1:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)

Routes originated by R2:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)

Routes originated by R3:
(D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64)
]]></artwork>
      </figure>
      <t>Each SER originates destination routes which that are scoped to the source
      prefix assigned by the ISP that to which the SER connects to. connects. Note that the SERs
      also originate the corresponding unscoped destination route. This is not
      needed when all of the routers in the site support SADR. However, it is
      required when some routers do not support SADR. This will be discussed
      in more detail later.</t>
      <t>We focus on how R8 constructs its source-prefix-scoped forwarding
      tables from these route advertisements. R8 computes the next hops for
      destination routes which that are scoped to the source prefix
      2001:db8:0:a000::/52. The results are shown in the first table in
      <xref
      target="fig_forwarding_entries"/>. target="fig_forwarding_entries" format="default"/>. (In this example, the next hops are
      computed assuming that all links have the same metric.) Then, R8
      computes the next hops for destination routes which that are scoped to the
      source prefix 2001:db8:0:b000::/52. The results are shown in the second
      table in <xref target="fig_forwarding_entries"/> . target="fig_forwarding_entries" format="default"/>. Finally, R8 computes
      the next hops for the unscoped destination prefixes. The results are
      shown in the third table in <xref target="fig_forwarding_entries"/>.</t> target="fig_forwarding_entries" format="default"/>.</t>
      <figure align="center" anchor="fig_forwarding_entries"
              title="Forwarding anchor="fig_forwarding_entries">
        <name>Forwarding Entries Computed at R8"> R8</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
forwarding entries scoped to
source prefix = 2001:db8:0:a000::/52
============================================
D=2001:db8:0:5555/64      NH=R7
D=::/0                    NH=R7

forwarding entries scoped to
source prefix = 2001:db8:0:b000::/52
============================================
D=2001:db8:0:6666/64      NH=SERb2
D=::/0                    NH=SERb1

unscoped forwarding entries
============================================
D=2001:db8:0:a010::/64    NH=R2
D=2001:db8:0:b010::/64    NH=R2
D=2001:db8:0:a020::/64    NH=R5
D=2001:db8:0:b020::/64    NH=R5
D=2001:db8:0:5555::/64    NH=R7
D=2001:db8:0:6666::/64    NH=SERb2
D=::/0                    NH=SERb1
]]></artwork>
      </figure>
      <t>
	      The final step is for R8 to augment the more specific source-prefix-
scoped source-prefix-scoped
forwarding tables with entries from less specific source-prefix-scoped
forwarding tables.  The unscoped forwarding table is considered as being
scoped to ::/0, so both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52
are more specific prefixes of ::/0.  Therefore, entries in the unscoped
forwarding table will be evaluated to be added to these two
more specific source-prefix-scoped forwarding tables.   If a forwarding
entry from the less specific source-prefix-scoped forwarding table
has the exact same destination prefix (including destination prefix length)
as the forwarding entry from the more specific source-prefix-scoped forwarding table,
then the existing forwarding entry in the more specific source-prefix-scoped forwarding table wins.
</t>
      <t>As an example of how the source scoped source-prefix-scoped forwarding entries are
      augmented, we consider how the two
      entries in the first table in <xref target="fig_forwarding_entries"/> target="fig_forwarding_entries" format="default"/>
      (the table for source prefix = 2001:db8:0:a000::/52) are augmented with
      entries from the third table in <xref target="fig_forwarding_entries"/> target="fig_forwarding_entries" format="default"/>
      (the table of unscoped or scoped to ::/0 forwarding entries). The first four unscoped
      forwarding entries (D=2001:db8:0:a010::/64, D=2001:db8:0:b010::/64,
      D=2001:db8:0:a020::/64, and D=2001:db8:0:b020::/64) are not an exact
      match for any of the existing entries in the forwarding table for source
      prefix 2001:db8:0:a000::/52. Therefore, these four entries are added to
      the final forwarding table for source prefix 2001:db8:0:a000::/52. The
      result of adding these entries is reflected in the first four entries the
      first table in <xref target="fig_forwarding_tables"/>.</t> target="fig_forwarding_tables" format="default"/>.</t>

      <t>The next less specific scoped source-prefix-scoped (scope is ::/0) forwarding table entry is for
      D=2001:db8:0:5555::/64. This entry is an exact match for the existing
      entry in the forwarding table for the more specific source prefix 2001:db8:0:a000::/52.
      Therefore, we do not replace the existing entry with the entry from the
      unscoped forwarding table. This is reflected in the fifth entry in the
      first table in <xref target="fig_forwarding_tables"/>. target="fig_forwarding_tables" format="default"/>. (Note that since
      both scoped and unscoped entries have R7 as the next hop, the result of
      applying this rule is not visible.)</t>

      <t>The next less specific prefix scoped source-prefix-scoped (scope is ::/0) forwarding table entry is for
      D=2001:db8:0:6666::/64. This entry is not an exact match for any
      existing entries in the forwarding table for source prefix
      2001:db8:0:a000::/52. Therefore, we add this entry. This is reflected in
      the sixth entry in the first table in <xref
      target="fig_forwarding_tables"/>.</t> target="fig_forwarding_tables" format="default"/>.</t>
      <t>The next less specific prefix scoped source-prefix-scoped (scope is ::/0) forwarding table entry
      is for D=::/0. This entry is
      an exact match for the existing entry in the forwarding table for the more specific source
      prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing
      source-prefix-scoped entry, as can be seen in the last entry in the
      first table in <xref target="fig_forwarding_tables"/>.</t> target="fig_forwarding_tables" format="default"/>.</t>
      <figure align="center" anchor="fig_forwarding_tables"
              title="Complete anchor="fig_forwarding_tables">
        <name>Complete Forwarding Tables Computed at R8"> R8</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
if source address matches 2001:db8:0:a000::/52
then use this forwarding table
============================================
D=2001:db8:0:a010::/64    NH=R2
D=2001:db8:0:b010::/64    NH=R2
D=2001:db8:0:a020::/64    NH=R5
D=2001:db8:0:b020::/64    NH=R5
D=2001:db8:0:5555::/64    NH=R7
D=2001:db8:0:6666::/64    NH=SERb2
D=::/0                    NH=R7

else if source address matches 2001:db8:0:b000::/52
then use this forwarding table
============================================
D=2001:db8:0:a010::/64    NH=R2
D=2001:db8:0:b010::/64    NH=R2
D=2001:db8:0:a020::/64    NH=R5
D=2001:db8:0:b020::/64    NH=R5
D=2001:db8:0:5555::/64    NH=R7
D=2001:db8:0:6666::/64    NH=SERb2
D=::/0                    NH=SERb1

else if source address matches ::/0 use this forwarding table
============================================
D=2001:db8:0:a010::/64    NH=R2
D=2001:db8:0:b010::/64    NH=R2
D=2001:db8:0:a020::/64    NH=R5
D=2001:db8:0:b020::/64    NH=R5
D=2001:db8:0:5555::/64    NH=R7
D=2001:db8:0:6666::/64    NH=SERb2
D=::/0                    NH=SERb1
]]></artwork>
      </figure>
      <t>The forwarding tables produced by this process at R8 have the desired
      properties. A packet with a source address in 2001:db8:0:a000::/52 will
      be forwarded based on the first table in <xref
      target="fig_forwarding_tables"/>. target="fig_forwarding_tables" format="default"/>. If the packet is destined for the
      Internet at large or the service at D=2001:db8:0:5555/64, it will be
      sent to R7 in the direction of SERa. If the packet is destined for an
      internal host, then the first four entries will send it to R2 or R5 as
      expected. Note that if this packet has a destination address
      corresponding to the service offered by ISP-B (D=2001:db8:0:5555::/64),
      then it will get forwarded to SERb2. It will be dropped by SERb2 or by
      ISP-B, since the packet has a source address that was not assigned by
      ISP-B. However, this is expected behavior. In order to use the service
      offered by ISP-B, the host needs to originate the packet with a source
      address assigned by ISP-B.</t>
      <t>In this example, a packet with a source address that doesn't match
      2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated from
      an external host. Such a packet will use the unscoped forwarding table
      (the last table in <xref target="fig_forwarding_tables"/>). target="fig_forwarding_tables" format="default"/>). These
      packets will flow exactly as they would in absence of multihoming.</t>
      <t>We can also modify this example to illustrate how it supports
      deployments where in which not all routers in the site support SADR. Continuing
      with the topology shown in <xref target="fig_isp_service"/>, target="fig_isp_service" format="default"/>, suppose
      that R3 and R5 do not support SADR. Instead they are only capable of
      understanding unscoped route advertisements. The SADR routers in the
      network will still originate the routes shown in <xref
      target="fig_routes_originated"/>. target="fig_routes_originated" format="default"/>. However, R3 and R5 will only
      understand the unscoped routes as shown in <xref
      target="fig_routes_understood_by_non_SADR"/>.</t> target="fig_routes_understood_by_non_SADR" format="default"/>.</t>
      <figure align="center" anchor="fig_routes_understood_by_non_SADR"
              title="Routes anchor="fig_routes_understood_by_non_SADR">
        <name>Route Advertisements Understood by Routers that do no That Do Not Support SADR"> SADR</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
Routes originated by SERa:
(D=2001:db8:0:5555::/64)
(D=::/0)

Routes originated by SERb1:
(D=::/0)

Routes originated by SERb2:
(D=2001:db8:0:6666::/64)

Routes originated by R1:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)

Routes originated by R2:
(D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64)

Routes originated by R3:
(D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64)
]]></artwork>
      </figure>
      <t>With these unscoped route advertisements, R5 will produce the
      forwarding table shown in <xref target="fig_R5_forwarding_table"/>.</t> target="fig_R5_forwarding_table" format="default"/>.</t>
      <figure align="center" anchor="fig_R5_forwarding_table"
              title="Forwarding anchor="fig_R5_forwarding_table">
        <name>Forwarding Table For for R5, Which Doesn't Understand Source-Prefix-Scoped Routes"> Routes</name>
        <artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
forwarding table
============================================
D=2001:db8:0:a010::/64    NH=R8
D=2001:db8:0:b010::/64    NH=R8
D=2001:db8:0:a020::/64    NH=R3
D=2001:db8:0:b020::/64    NH=R3
D=2001:db8:0:5555::/64    NH=R8
D=2001:db8:0:6666::/64    NH=SERb2
D=::/0                    NH=R8
]]></artwork>
      </figure>
      <t>As all SERs belong to the SADR domain domain, any traffic that needs to exit the site will eventually hit a SADR-capable router.  To prevent routing loops involving SADR-capable and non-SADR-capable routers, traffic that enters the SADR-capable domain does not leave the domain until it exits the site. Therefore all SADR-capable routers within the domain MUST <bcp14>MUST</bcp14> be logically connected.</t>

      <t>Note that the mechanism described here for converting
      source-prefix-scoped destination prefix routing advertisements into
      forwarding state is somewhat different from that proposed in <xref target="I-D.ietf-rtgwg-dst-src-routing"/>.
      target="I-D.ietf-rtgwg-dst-src-routing" format="default"/>. The method
      described in the current this document is functionally equivalent, but it is based on application of existing mechanisms for the described scenarios.</t>
    </section>
    <section anchor="sec_host_mechanisms"
             title="Mechanisms For numbered="true" toc="default">
      <name>Mechanisms for Hosts To Choose Good Default Source Addresses In A in a Multihomed Site"> Site</name>
      <t>Until this point, we have made the assumption that hosts are able to
      choose the correct source address using some unspecified mechanism. This
      has allowed us to just focus on what the routers in a multihomed site
      network need to do in order to forward packets to the correct ISP based
      on source address. Now we look at possible mechanisms for hosts to
      choose the correct source address. We also look at what role, if any,
      the routers may play in providing information that helps hosts to choose
      source addresses.</t>
      <t>
       It should be noted that this section discussed discusses how hosts could select
       the default source address for new connections. Any connection which that
       already exists on a host is bound to the a specific source address which can not that
       cannot be changed. <xref target="sec_conn_pre"/> target="sec_conn_pre" format="default"/>
       discusses the connections preservation issue in more details. detail.
</t>
      <t>Any host that needs to be able to send traffic using the uplinks to a given ISP
      is expected to be configured with an address from the prefix
      assigned by that ISP. The host will control which ISP is used for its
      traffic by selecting one of the addresses configured on the host as the
      source address for outgoing traffic. It is the responsibility of the
      site network to ensure that a packet with the source address from an ISP
      is now sent on an uplink to that ISP.</t>
      <t>If all of the ISP uplinks are working, then the host's choice of source address
      by the host
      may be driven by the desire to load share across ISP
      uplinks, or it may be driven by the desire to take advantage of certain
      properties of a particular uplink or ISP (if some information about various
      path properties has been made availabe available to the host somehow - see somehow. See
      <xref target="I-D.ietf-intarea-provisioning-domains"/> target="I-D.ietf-intarea-provisioning-domains" format="default"/>
      as an example). If any of the ISP uplinks is
      not working, then the choice of source address by the host can cause
      packets to get dropped.</t>
      <t>How a host should make good decisions about selects a suitable source address selection
      in a multihomed site is not a solved problem. We do not attempt to solve
      this problem in this document. Instead we discuss the current state of
      affairs with respect to standardized solutions and the implementation of
      those solutions. We also look at proposed solutions for this
      problem.</t>
      <t>An external host initiating communication with a host internal to a
      PA multihomed
      PA-multihomed site will need to know multiple addresses for that host in
      order to communicate with it using different ISPs to the multihomed
      site (knowing just one address would undermine all benefits of redundant connectivity provided by multihoming). These addresses are typically learned through DNS. (For
      simplicity, we assume that the external host is single-homed.) The
      external host chooses the ISP that will be used at the remote multihomed
      site by setting the destination address on the packets it transmits. For
      a session originated from an external host to an internal host, the
      choice of source address used by the internal host is simple. The
      internal host has no choice but to use the destination address in the
      received packet as the source address of the transmitted packet.</t>
      <t>For a session originated by a host inside the multi-homed multihomed site,
      the decision of what which source address to select is more complicated. We
      consider three main methods for hosts to get information about the
      network. The two proactive methods are Neighbor Discovery Router
      Advertisements and DHCPv6. The one reactive method we consider is
      ICMPv6. Note that we are explicitly excluding the possibility of having
      hosts participate in in, or even listen directly to to, routing protocol
      advertisements.</t>
      <t>First we look at how a host is currently expected to select the
	      default source and destination addresses to be used for a new connection.</t>
      <section anchor="sec_host_address_selection_algo"
               title="Default numbered="true" toc="default">
        <name>Default Source Address Selection Algorithm on Hosts"> Hosts</name>
        <t><xref target="RFC6724"/> target="RFC6724" format="default"/> defines the algorithms that hosts are
        expected to use to select source and destination addresses for
        packets. It defines an algorithm for selecting a source address and a
        separate algorithm for selecting a destination address. Both of these
        algorithms depend on a policy table. <xref target="RFC6724"/> target="RFC6724" format="default"/> defines
        a default policy which that produces certain behavior.</t>
        <t>The rules in the two algorithms in <xref target="RFC6724"/> target="RFC6724" format="default"/> depend
        on many different properties of addresses. While these are needed for
        understanding how a host should choose addresses in an arbitrary
        environment, most of the rules are not relevant for understanding how
        a host should choose among multiple source addresses in a multihomed
        environment when sending a
        packet to a remote host. Returning to the example in <xref
        target="fig_isp_service"/>, target="fig_isp_service" format="default"/>, we look at what the default algorithms in
        <xref target="RFC6724"/> target="RFC6724" format="default"/> say about the source address that internal
        host H31 should use to send traffic to external host H101, somewhere
        on the Internet.</t>
        <t>There is no choice to be made with respect to destination address.
        H31 needs to send a packet with D=2001:db8:0:1234::101 in order to
        reach H101. So H31 have has to choose between using S=2001:db8:0:a010::31
        or S=2001:db8:0:b010::31 as the source address for this packet. We go
	through the rules for source address selection in Section 5 of <xref target="RFC6724"/>. target="RFC6724" sectionFormat="of" section="5" format="default"/>. </t>
        <t> Rule 1 (Prefer same address) is not useful to
        break the tie between source addresses, addresses because neither one of the candidate
	source addresses equals the destination address.  </t>
        <t> Rule 2 (Prefer appropriate scope) is also not used useful in this scenario, scenario because both
        source addresses and the destination address have global scope.</t>

        <t>Rule 3 (Avoid deprecated addresses) applies to an address that has
        been autoconfigured by a host using stateless address
        autoconfiguration as defined in <xref target="RFC4862"/>. target="RFC4862" format="default"/>. An address
        autoconfigured by a host has a preferred lifetime and a valid
        lifetime. The address is preferred until the preferred lifetime
        expires, after which it becomes deprecated. A deprecated address is not
        used if there is a preferred address of the appropriate scope available.
        When the valid lifetime expires, the address cannot be used at all. The
        preferred and valid lifetimes for an autoconfigured address are set
        based on the corresponding lifetimes in the Prefix Information Option
        in Neighbor Discovery Router Advertisements. So In this scenario, a
	possible tool to control source address selection in this scenario
	would be for a host to make deprecate an address deprecated by having routers on that
	link, R1 and R2 in <xref target="fig_isp_service"/>, target="fig_isp_service" format="default"/>, send a Router Advertisement message messages
	containing a Prefix Information Option PIOs with the Preferred Lifetime value for the deprecated
	source prefix to be
        discouraged (or prohibited) with the preferred lifetime set to zero. This is a rather blunt tool, because it discourages or prohibits the use
        of that source prefix for all destinations. However, it may be useful in some scenarios.
        For example, if all uplinks to a particular ISP fail, it is desirable to prevent hosts from
        using source addresses from that ISP address space.
        </t>
        <t>Rule 4 (Avoid home addresses) does not apply here because we are
        not considering Mobile IP.</t>
        <t>Rule 5 (Prefer outgoing interface) is not useful in this scenario, scenario
        because both source addresses are assigned to the same interface.</t>
        <t>Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is not
        useful in the scenario when both R1 and R2 will advertise both source
        prefixes. However potentially However, this rule may potentially allow a host to select the
        correct source prefix by selecting a next-hop. The most obvious way
        would be to make R1 to advertise itself as a default router and send
        PIO for 2001:db8:0:a010::/64, while R2 is advertising advertises itself as a
        default router and sending sends PIO for 2001:db8:0:b010::/64. We'll discuss
        later how Rule 5.5 can be used to influence a source address selection
        in single-router topologies (e.g. (e.g., when H41 is sending traffic using R3
        as a default gateway).</t>
        <t>Rule 6 (Prefer matching label) refers to the Label label value determined
        for each source and destination prefix as a result of applying the
        policy table to the prefix. With the default policy table defined in
        Section 2.1 of
        <xref target="RFC6724"/>, target="RFC6724" sectionFormat="of" section="2.1" format="default"/>, Label(2001:db8:0:a010::31) =
        5, Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) =
        5. So with the default policy, Rule 6 does not break the tie. However,
        the algorithms in <xref target="RFC6724"/> target="RFC6724" format="default"/> are defined in such a way
        that non-default address selection policy tables can be used.
        <xref
        target="RFC7078"/> target="RFC7078" format="default"/> defines a way to distribute a non-default address
        selection policy table to hosts using DHCPv6. So even though the
        application of rule Rule 6 to this scenario using the default policy table
        is not useful, rule Rule 6 may still be a useful tool.</t>
        <t>Rule 7 (Prefer temporary addresses) has to do with the technique
        described in <xref target="RFC4941"/> target="RFC4941" format="default"/> to periodically randomize the
        interface portion of an IPv6 address that has been generated using
        stateless address autoconfiguration. In general, if H31 were using
        this technique, it would use it for both source addresses, for example example,
        creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and
        2001:db8:0:b010:4838:f483:8384:3208, in addition to
        2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would prefer
        the two temporary addresses, but it would not break the tie between
        the two source prefixes from ISP-A and ISP-B.</t>

        <t>Rule 8 (Use longest matching prefix) dictates that that, between two
candidate source addresses addresses, the host selects the one which that has
longest common prefix length with the destination address. For example, if H31 were
        selecting the source address for sending packets to H101, this rule
        would not be a break the tie breaker as for both between candidate source addresses
        2001:db8:0:a101::31 and 2001:db8:0:b101::31 since the common prefix length
        with the destination is 48. However However, if H31 were selecting the source
        address for sending packets to H41 address 2001:db8:0:a020::41, then this
        rule would result in using 2001:db8:0:a101::31 as a source
        (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix
        2001:db8:0:a000::/58, while for 2001:db8:0:b101::31 and
        2001:db8:0:a020::41
        2001:db8:0:a020::41, the common prefix is 2001:db8:0:a000::/51).
        Therefore rule Rule 8 might be useful for selecting the correct source
        address in some some, but not all all, scenarios (for example if ISP-B services
        belong to 2001:db8:0:b000::/59 2001:db8:0:b000::/59, then H31 would always use
        2001:db8:0:b010::31 to access those destinations).</t>
        <t>So we can see that of the 8 eight source selection address selection rules from
        <xref target="RFC6724"/>, target="RFC6724" format="default"/>, four actually apply to our basic site
        multihoming scenario. The rules that are relevant to this scenario are
        summarized below.</t>

        <t><list style="symbols">
            <t>Rule
        <ul spacing="normal">
          <li>Rule 3: Avoid deprecated addresses.</t>

            <t>Rule addresses.</li>
          <li>Rule 5.5: Prefer addresses in a prefix advertised by the
            next-hop.</t>

            <t>Rule
            next-hop.</li>
          <li>Rule 6: Prefer matching label.</t>

            <t>Rule label.</li>
          <li>Rule 8: Prefer longest matching prefix.</t>
          </list></t> prefix.</li>
        </ul>
        <t>The two methods that we discuss for controlling the source address
        selection through the four relevant rules above are SLAAC Router
        Advertisement messages and DHCPv6.</t>
        <t>We also consider a possible role for ICMPv6 for getting
        traffic-driven feedback from the network. With the source address
        selection algorithm discussed above, the goal is to choose the correct
        source address on the first try, before any traffic is sent. However,
        another strategy is to choose a source address, send the packet, get
        feedback from the network about whether or not the source address is
        correct, and try another source address if it is not.</t>
        <t>We consider four scenarios where in which a host needs to select the correct
        source address. The In the first is when scenario, both uplinks are working. The In
        the second
        is when scenario, one uplink has failed. The third one scenario is a
        situation when in which one failed uplink has recovered. The last one scenario is failure of both (all)
	uplinks.</t>
        <t>
	It should be noted that <xref target="RFC6724"/> target="RFC6724" format="default"/>
	only defines the behavior of IPv6
hosts to select default addresses that applications and upper-layer
protocols can use. Applications and upper-layer protocols can make their
own choices on selecting source addresses.
The mechanism proposed in this document attempts to ensure that the subset of source addresses available for applications and upper-layer protocols is selected with the up-to-date network state in mind. The rest of the document discusses various aspects of the default source address selection defined in  <xref target="RFC6724"/>, target="RFC6724" format="default"/>, calling it for the sake of brevity "the source address selection".
</t>
      </section>
      <section anchor="sec_both_uplinks_working"
               title="Selecting numbered="true" toc="default">
        <name>Selecting Default Source Address When Both Uplinks Are Working"> Working</name>
        <t>Again we return to the topology in <xref
        target="fig_isp_service"/>. target="fig_isp_service" format="default"/>. Suppose that the site administrator wants
        to implement a policy by which all hosts need to use ISP-A to reach
        H101 at D=2001:db8:0:1234::101. So for example, H31 needs to select
        S=2001:db8:0:a010::31.</t>
        <section anchor="sec_both_working_dhcpv6"
                 title="Distributing numbered="true" toc="default">
          <name>Distributing Default Address Selection Policy Table with DHCPv6"> DHCPv6</name>
          <t>This policy can be implemented by using DHCPv6 to distribute an
          address selection policy table that assigns the same label to
          destination address addresses that match 2001:db8:0:1234::/64 as it does to
          source addresses that match 2001:db8:0:a000::/52. The following two
          entries accomplish this.</t>

          <figure align="center" anchor="fig_policy_table"
                  title="Policy table entries anchor="fig_policy_table">
            <name>Policy Table Entries to implement Implement a routing policy"> Routing Policy</name>
            <artwork align="center"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
Prefix                 Precedence       Label
2001:db8:0:1234::/64   50               33
2001:db8:0:a000::/52   50               33
]]></artwork>
          </figure>
          <t>This requires that the hosts implement <xref target="RFC6724"/>, target="RFC6724" format="default"/>,
          the basic source and destination address framework, along with <xref
          target="RFC7078"/>, target="RFC7078" format="default"/>, the DHCPv6 extension for distributing a
          non-default policy table. Note that it does NOT require that the
          hosts use DHCPv6 for address assignment. The hosts could still use
          stateless address autoconfiguration for address configuration, while
          using DHCPv6 only for policy table distribution (see <xref
          target="RFC8415"/>). target="RFC8415" format="default"/>). However this method has a number of
          disadvantages: <list style="symbols">
		  <t>DHCPv6 </t>
          <ul spacing="normal">
            <li>DHCPv6 support is not a mandatory requirement for IPv6 hosts (<xref target="RFC6434"/>), <xref target="RFC8504" format="default"/>,
              so this method might not work for all devices.</t>

              <t>Network devices.</li>
            <li>Network administrators are required to explicitly configure
	      the desired network access policies on DHCPv6 servers. While it might be feasible in the scenario
	      of a single multihomed network, such approach might have some scalability issues, especially if the centralized
	      DHCPv6 solution is deployed to serve a large number of multiomed sites.</t>
            </list></t> multihomed sites.</li>
          </ul>
        </section>
        <section anchor="sec_both_working_ra"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With with Router Advertisements"> Advertisements</name>
          <t>Neighbor Discovery currently has two mechanisms to communicate
          prefix information to hosts. The base specification for Neighbor
          Discovery (see <xref target="RFC4861"/>) target="RFC4861" format="default"/>) defines the Prefix
          Information Option (PIO) in the Router Advertisement (RA) message.
          When a host receives a PIO with the A-flag <xref target="RFC8425"
	  format="default"/> set, it can use the
          prefix in the PIO as the source prefix from which it assigns itself an
          IP address using stateless address autoconfiguration (SLAAC)
          procedures described in <xref target="RFC4862"/>. target="RFC4862" format="default"/>. In the example of
          <xref target="fig_isp_service"/>, target="fig_isp_service" format="default"/>, if the site network is using
          SLAAC, we would expect both R1 and R2 to send RA messages with PIOs
          with the A-flag set for both source prefixes 2001:db8:0:a010::/64 and
          2001:db8:0:b010::/64 with the A-flag set.
          2001:db8:0:b010::/64. H31 would then use the
          SLAAC procedure to configure itself with the 2001:db8:0:a010::31 and
          2001:db8:0:b010::31.</t>
          <t>Whereas a host learns about source prefixes from PIO messages,
          hosts can learn about a destination prefix from a Router
          Advertisement containing a Route Information Option (RIO), as
          specified in <xref target="RFC4191"/>. target="RFC4191" format="default"/>. The destination prefixes in
          RIOs are intended to allow a host to choose the router that it uses
          as its first hop to reach a particular destination prefix.</t>
          <t>As currently standardized, neither PIO nor RIO options contained
          in Neighbor Discovery Router Advertisements can communicate the
          information needed to implement the desired routing policy. PIO's PIOs
          communicate source prefixes, and RIO RIOs communicate destination
          prefixes. However, there is currently no standardized way to
          directly associate a particular destination prefix with a particular
          source prefix.</t>
          <t><xref target="I-D.pfister-6man-sadr-ra"/> target="I-D.pfister-6man-sadr-ra" format="default"/> proposes a Source
          Address Dependent Route Information option for Neighbor Discovery
          Router Advertisements which that would associate a source prefix and with
          a destination prefix. The details of <xref
          target="I-D.pfister-6man-sadr-ra"/> target="I-D.pfister-6man-sadr-ra" format="default"/> might need tweaking to address
          this use case. However, in order to be able to use Neighbor
          Discovery Router Advertisements to implement this routing policy, an
          extension is needed that allows would allow R1 and R2 to explicitly communicate to H31
          an association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64
          would be needed.</t> and D=2001:db8:0:1234::/64.</t>
          <t>However, Rule 5.5 of the default source address selection algorithm (discussed
		  in <xref target="sec_host_address_selection_algo"/> above), target="sec_host_address_selection_algo" format="default"/>),
		  together with default router preference
                  (specified in <xref
          target="RFC4191"/>) target="RFC4191" format="default"/>)
          and RIO RIO, can be used to influence a source
          address selection on a host as described below. Let's look at source
          address selection on the host H41. It receives RAs from R3 with PIOs
          for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point point, all
          traffic would use the same next-hop (R3 link-local address) so Rule
          5.5 does not apply. Now let's assume that R3 supports SADR and has
          two scoped forwarding tables, one scoped to S=2001:db8:0:a000::/52
          and another scoped to S=2001:db8:0:b000::/52. If R3 generates two
          different link-local addresses for its interface facing H41 (one for
          each scoped forwarding table, LLA_A and LLA_B) and starts sending LLA_B), R3 will send
          two different RAs: one is sent from LLA_A and that includes a PIO for
          2001:db8:0:a020::/64, and another is sent from LLA_B and that includes a PIO
          for 2001:db8:0:b020::/64. Now it is possible to influence H41 source
          address selection for destinations which that follow the default route by
          setting the default router preference in RAs. If it is desired that H41
          reaches H101 (or any destinations destination in the Internet) via ISP-A, then
          RAs sent from LLA_A should have the default router preference set to 01
          (high priority), while RAs sent from LLA_B should have the preference
          set to 11 (low). Then LLA_A would then be chosen as a next-hop for H101 H101,
          and therefore (as per rule (per Rule 5.5) 2001:db8:0:a020::41 would be
          selected as the source address. If, at the same time, it is desired
          that H61 is accessible via ISP-B ISP-B, then R3 should include a RIO for
          2001:db8:0:6666::/64 to in its RA sent from LLA_B. H41 would chose choose
          LLA_B as a next-hop for all traffic to H61 H61, and then as per Rule 5.5,
          2001:db8:0:b020::41 would be selected as a source address.</t>
          <t>If in the above mentioned above-mentioned scenario it is desirable that all
          Internet traffic leaves the network via ISP-A ISP-A, and the link to ISP-B
          is used for accessing ISP-B services only (not as an ISP-A link
          backup), then RAs sent by R3 from LLA_B should have their Router Lifetime
          values set to 0 zero and should include RIOs for ISP-B address space. It would
          instruct H41 to use LLA_A for all Internet traffic but to use LLA_B as
          a next-hop while sending traffic to ISP-B addresses.</t>
          <t>The description of the mechanism above assumes SADR support by the
		  first-hop routers as well as SERs.  However, a first-hop router can still
		  provide a less flexible version of this mechanism even without
		  implementing SADR.  This could be done by providing configuration knobs on the
		  first-hop router that allow it to generate different link-local addresses
		  and to send individual RAs for each prefix.
          </t>
          <t> The mechanism described above relies on Rule 5.5 of the
		  default source address selection algorithm defined in
                  <xref target="RFC6724"/>. target="RFC6724" format="default"/>.
		  <xref target="RFC8028"/> target="RFC8028" format="default"/>  states that
                  "A host SHOULD <bcp14>SHOULD</bcp14> select default routers for each prefix it is
		  assigned an address in". in." It also recommends that
		  hosts should implement Rule 5.5. of <xref target="RFC6724"/>. target="RFC6724" format="default"/>.
                  Hosts following the recommendations specified in
                  <xref target="RFC8028"/> target="RFC8028" format="default"/>  therefore should be able to benefit from
		  the solution described in this document.  No standards need to be
          updated in regards to host behavior.   </t>
        </section>
        <section anchor="sec_both_working_icmpv6"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With ICMPv6"> with ICMPv6</name>
          <t>We now discuss how one might use ICMPv6 to implement the routing
          policy to send traffic destined for H101 out the uplink to ISP-A,
          even when uplinks to both ISPs are working. If H31 started sending
          traffic to H101 with S=2001:db8:0:b010::31 and
          D=2001:db8:0:1234::101, it would be routed through SER-b1 and out
          the uplink to ISP-B. SERb1 could recognize that this traffic is
          not following the desired routing policy and react by sending an
          ICMPv6 message back to H31.</t>
          <t>In this example, we could arrange things so that SERb1 drops the
          packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and
          then sends to H31 an ICMPv6 Destination Unreachable message with
          Code 5 (Source address failed ingress/egress policy). When H31
          receives this packet, it would then be expected to try another
          source address to reach the destination. In this example, H31 would
          then send a packet with S=2001:db8:0:a010::31 and
          D=2001:db8:0:1234::101, which will reach SERa and be forwarded out
          the uplink to ISP-A.</t>
          <t>However, we would also want it to be the case that SERb1 does not
          enforce this routing policy when the uplink from SERa to ISP-A has
          failed. This could be accomplished by having SERa originate a
          source-prefix-scoped route for (S=2001:db8:0:a000::/52,
          D=2001:db8:0:1234::/64)
          D=2001:db8:0:1234::/64), and have SERb1 monitor the presence of that
          route. If that route is not present (because SERa has stopped
          originating it), then SERb1 will not enforce the routing policy, and
          it will forward packets with S=2001:db8:0:b010::31 and
          D=2001:db8:0:1234::101 out its uplink to ISP-B.</t>
          <t>We can also use this source-prefix-scoped route originated by
          SERa to communicate the desired routing policy to SERb1. We can
          define an EXCLUSIVE flag to be advertised together with the IGP
          route for (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This
          would allow SERa to communicate to SERb that SERb should reject
          traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6
          Destination Unreachable Code 5 message, as long as the route for
	  (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. The definition of an EXCLUSIVE flag for SADR
	  advertisements in IGPs would require future standardization work.

          </t>
          <t>Finally, if we are willing to extend ICMPv6 to support this
          solution, then we could create a mechanism for SERb1 to tell the
          host what which source address it should be using to successfully forward
          packets that meet the policy. In its current form, when SERb1 sends
          an ICMPv6 Destination Unreachable Code 5 message, it is basically
          saying, "This source address is wrong. Try another source address."
          In the absence of a clear indication which address to try next, the host
          will iterate over all addresses assigned to the interface (e.g. (e.g., various
          privacy addresses) addresses), which would lead to significant delays and degraded user experience.
          It would be better is if the ICMPv6 message could say, "This source
          address is wrong. Instead use a source address in
          S=2001:db8:0:a000::/52.".
          S=2001:db8:0:a000::/52". </t>

          <t>However
          <t>However, using ICMPv6 for signaling source address information
          back to hosts introduces new challenges. Most routers currently have
          software or hardware limits on generating ICMP messages. A site
          administrator deploying a solution that relies on the SERs
          generating ICMP messages could try to improve the performance of
          SERs for generating ICMP messages. However, in a large network, it
          is still likely that ICMP message generation limits will be reached.
          As a result result, hosts would not receive ICMPv6 back back, which in turn leads
          to traffic blackholing and poor user experience. To improve the
          scalability of ICMPv6-based signaling signaling, hosts SHOULD <bcp14>SHOULD</bcp14> cache the
          preferred source address (or prefix) for the given destination
          (which in turn might cause issues in the case of the corresponding
          ISP uplinks uplink failure - see <xref target="sec_one_uplink_failed"/>). target="sec_one_uplink_failed" format="default"/>). In
          addition, the same source prefix SHOULD <bcp14>SHOULD</bcp14> be used for other
          destinations in the same /64 as the original destination address.
          The source prefix to the destination mapping SHOULD <bcp14>SHOULD</bcp14> have a specific lifetime. Expiration of the
          lifetime SHOULD <bcp14>SHOULD</bcp14> trigger the source address selection algorithm
	  again.</t>
          <t>
	  Using ICMPv6 Destination Unreachable Messages with Code 5 to influence source address selection
	  introduces some security challenges challenges, which are discussed in <xref target="Security"/>. target="Security" format="default"/>.
          </t>
          <t> As currently standardized in <xref target="RFC4443"/>, target="RFC4443" format="default"/>, the ICMPv6
		  Destination Unreachable Message with Code 5 would allow for the
		  iterative approach to retransmitting packets using different source addresses.
		  As currently defined, the ICMPv6 message does not provide
		  a mechanism to communication communicate information about which source prefix
		  should be used for a retransmitted packet.  The current document does not
		  define such a mechanism mechanism, but it might be a useful extension
		  to define in a different document. However However, this approach has some security implications implications,
                  such as an ability for an attacker to send spoofed ICMPv6 messages
                  to signal an invalid/unreachable source prefix prefix, causing a DoS-type attack.</t>
        </section>
        <section anchor="sec_both_working_summary"
                 title="Summary numbered="true" toc="default">
          <name>Summary of Methods For for Controlling Default Source Address Selection To to Implement Routing Policy"> Policy</name>
          <t>So to summarize this section, we have looked at three methods for
          implementing a simple routing policy where all traffic for a given
          destination on the Internet needs to use a particular ISP, even when
          the uplinks to both ISPs are working.</t>
          <t>The default source address selection policy cannot distinguish
          between the source addresses needed to enforce this policy, so a
          non-default policy table using associating source and destination
          prefixes using Label label values would need to be installed on each host.
          A mechanism exists for DHCPv6 to distribute a non-default policy
          table
          table, but such solution would heavily rely on DHCPv6 support by the host
          operating system. Moreover Moreover, there is no mechanism to translate
          desired routing/traffic engineering policies into policy tables on
          DHCPv6 servers. Therefore using DHCPv6 for controlling the address
          selection policy table is not recommended and SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
          used.</t>
          <t>At the same time time, Router Advertisements provide a reliable
          mechanism to influence the source address selection process via PIO, RIO RIO,
          and default router preferences. As all those options have been
          standardized by the IETF and are supported by various operating systems systems,
          no changes are required on hosts. First-hop routers in the
          enterprise network need to be able capable of sending different RAs for
          different SLAAC prefixes (either based on scoped forwarding tables
          or based on pre-configured preconfigured policies).</t>
          <t>SERs can enforce the routing policy by sending ICMPv6 Destination
          Unreachable messages with Code 5 (Source address failed
          ingress/egress policy) for traffic that is being sent with the wrong
          source address. The policy distribution could be automated by defining
          an EXCLUSIVE flag for the source-prefix-scoped route route, which can could then be
          set on the SER that originates the route. As ICMPv6 message
          generation can be rate-limited rate limited on routers, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used as
          the only mechanism to influence source address selection on hosts.
          While hosts SHOULD <bcp14>SHOULD</bcp14> select the correct source address for a given
          destination
          destination, the network SHOULD <bcp14>SHOULD</bcp14> signal any source address issues back
          to hosts using ICMPv6 error messages.</t>
        </section>
      </section>
      <section anchor="sec_one_uplink_failed"
               title="Selecting numbered="true" toc="default">
        <name>Selecting Default Source Address When One Uplink Has Failed"> Failed</name>
        <t>Now we discuss if whether DHCPv6, Neighbor Discovery Router Advertisements,
        and ICMPv6 can help a host choose the right source address when an
        uplink to one of the ISPs has failed. Again we look at the scenario in
        <xref target="fig_isp_service"/>. target="fig_isp_service" format="default"/>. This time we look at traffic from
        H31 destined for external host H501 at D=2001:db8:0:5678::501. We
        initially assume that the uplink from SERa to ISP-A is working and
        that the uplink from SERb1 to ISP-B is working.</t>
        <t>We assume there is no particular routing policy desired, so H31 is
        free to send packets with S=2001:db8:0:a010::31 or
        S=2001:db8:0:b010::31 and have them delivered to H501. For this
        example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that
        the packets exit via SERb to ISP-B. Now we see what happens when the
        link from SERb1 to ISP-B fails. How should H31 learn that it needs to
        start sending the packet packets to H501 with S=2001:db8:0:a010::31 in order
        to start using the uplink to ISP-A? We need to do this in a way that
        doesn't prevent H31 from still sending packets with
        S=2001:db8:0:b010::31 in order to reach H61 at
        D=2001:db8:0:6666::61.</t>
        <section anchor="sec_one_uplink_failed_dhcpv6"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With DHCPv6"> with DHCPv6</name>
          <t>For this example example, we assume that the site network in
          <xref
          target="fig_isp_service"/> target="fig_isp_service" format="default"/> has a centralized DHCP server and that all
          routers act as DHCP relay agents. We assume that both of the
          addresses assigned to H31 were assigned via DHCP.</t>
          <t>We could try to have the DHCP server monitor the state of the
          uplink from SERb1 to ISP-B in some manner and then tell H31 that it
          can no longer use S=2001:db8:0:b010::31 by settings setting its valid
          lifetime to zero. The DHCP server could initiate this process by
          sending a Reconfigure Message message to H31 as described in Section 18.3 of
          <xref target="RFC8415"/>. target="RFC8415" sectionFormat="of" section="18.3" format="default"/>. Or the DHCP server can assign addresses
          with short lifetimes in order to force clients to renew them
          often.</t>
          <t>This approach would prevent H31 from using S=2001:db8:0:b010::31
          to reach a host on the Internet. However, it would also prevent
          H31 from using S=2001:db8:0:b010::31 to reach H61 at
          D=2001:db8:0:6666::61, which is not desirable.</t>
          <t>Another potential approach is to have the DHCP server monitor the
          uplink from SERb1 to ISP-B and control the choice of source address
          on H31 by updating its address selection policy table via the
          mechanism in <xref target="RFC7078"/>. target="RFC7078" format="default"/>. The DHCP server could
          initiate this process by sending a Reconfigure Message message to H31. Note
          that <xref target="RFC8415"/> target="RFC8415" format="default"/> requires that Reconfigure Message messages use
          DHCP authentication. DHCP authentication could be avoided by using
          short address lifetimes to force clients to send Renew messages to
          the server often. If the host is does not obtaining obtain its IP addresses from
          the DHCP server, then it would need to use the Information Refresh
          Time option defined in <xref target="RFC8415"/>.</t> target="RFC8415" format="default"/>.</t>
          <t>If the following policy table can be installed on H31 after the
          failure of the uplink from SERb1, then the desired routing behavior
          should be achieved based on source and destination prefix being
          matched with label values.</t>

          <t><figure align="center" anchor="fig_policy_table_failed_uplink"
              title="Policy

          <figure anchor="fig_policy_table_failed_uplink">
            <name>Policy Table Needed On on Failure Of of Uplink From SERb1 "> from SERb1</name>
            <artwork align="center"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
Prefix                 Precedence       Label
::/0                   50               44
2001:db8:0:a000::/52   50               44
2001:db8:0:6666::/64   50               55
2001:db8:0:b000::/52   50               55
]]></artwork>
            </figure></t>
          </figure>
          <t>The described solution has a number of significant drawbacks,
          some of them already discussed in <xref
          target="sec_both_working_dhcpv6"/>.</t>

          <t><list style="symbols">
              <t>DHCPv6 target="sec_both_working_dhcpv6" format="default"/>.</t>
          <ul spacing="normal">
            <li>DHCPv6 support is not required for an IPv6 host host, and there are
              operating systems which that do not support DHCPv6. Besides that, it
              does not appear that <xref target="RFC7078"/> target="RFC7078" format="default"/> has been widely
              implemented on host operating systems.</t>

              <t><xref target="RFC7078"/> systems.</li>
            <li>
              <xref target="RFC7078" format="default"/> does not clearly specify this kind
              of a dynamic use case where in which the address selection policy needs to be
              updated quickly in response to the failure of a link. In a large
              network
              network, it would present scalability issues as many hosts need
              to be reconfigured in a very short period of time.</t>

              <t>Updating time.</li>
            <li>Updating DHCPv6 server configuration each time an ISP ISP's
              uplink changes its state introduces some scalability issues, especially
              for mid/large distributed scale distributed-scale enterprise networks. In addition to that,
              the policy table needs to be manually configured by administrators administrators, which makes
              that solution prone to human error.</t>

              <t>No error.</li>
            <li>No mechanism exists for making DHCPv6 servers aware of
              network topology/routing changes in the network. In general general,
              having DHCPv6 servers monitoring monitor network-related events sounds like a
              bad idea as it requires completely new functionality beyond the scope of the
              DHCPv6 role is required.</t>
            </list></t> role.</li>
          </ul>
        </section>
        <section anchor="sec_one_uplink_failed_ra"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With with Router Advertisements"> Advertisements</name>
          <t>The same mechanism as discussed in <xref
          target="sec_both_working_ra"/> target="sec_both_working_ra" format="default"/> can be used to control the source
          address selection in the case of an uplink failure. If a particular
          prefix should not be used as a source for any destinations, destination, then the
          router needs to send an RA with the Preferred Lifetime field for that
          prefix set to 0.</t> zero.</t>
          <t>Let's consider a scenario when in which all uplinks are operational operational, and
          H41 receives two different RAs from R3: one from LLA_A with a PIO for
          2001:db8:0:a020::/64,
          2001:db8:0:a020::/64 and the default router preference set to 11 (low) (low), and
          another one from LLA_B with a PIO for 2001:db8:0:a020::/64, the default
          router preference set to 01 (high) (high), and a RIO for 2001:db8:0:6666::/64.
          As a result result, H41 is using uses 2001:db8:0:b020::41 as a source address for
          all Internet traffic traffic, and those packets are sent by SERs to ISP-B. If
          SERb1
          SERb1's uplink to ISP-B failed, fails, the desired behavior is that H41 stops
          using 2001:db8:0:b020::41 as a source address for all destinations
          but H61. To achieve that that, R3 should react to SERb1 SERb1's uplink failure
          (which could be detected as the disappearance of scoped route
          (S=2001:db8:0:b000::/52, D=::/0) disappearance) D=::/0)) by withdrawing
          itself as a default router. R3 sends a new RA from LLA_B with the Router
          Lifetime value set to 0 zero (which means that it should not be used as
          the default router). That RA still contains a PIO for 2001:db8:0:b020::/64
          (for SLAAC purposes) and a RIO for 2001:db8:0:6666::/64 so that H41 can
          reach H61 using LLA_B as a next-hop and 2001:db8:0:b020::41 as a
          source address. For all traffic following the default route, LLA_A
          will be used as a next-hop and 2001:db8:0:a020::41 as a source
          address.</t>
          <t>If all of the uplinks to ISP-B have failed and therefore failed, source addresses from
ISP-B address space should not be used at all, used. In such a failure scenario,
the forwarding table scoped S=2001:db8:0:b000::/52 contains no entries.
          Hosts
entries, indicating that R3 can be instructed instruct hosts to stop using source
addresses from that
          block 2001:db8:0:b000::/52 by sending RAs containing PIO PIOs
with Preferred Lifetime values set to
          0.</t> zero.</t>
        </section>
        <section anchor="sec_one_uplink_failed_icmp"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With ICMPv6"> with ICMPv6</name>
          <t>Now we look at how ICMPv6 messages can provide information back
          to H31. We assume again that that, at the time of the failure failure, H31 is
          sending packets to H501 using (S=2001:db8:0:b010::31,
          D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails,
          SERb1 would stop originating its source-prefix-scoped route for the
          default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its
          unscoped default destination route. With these routes no longer in
          the IGP, traffic with (S=2001:db8:0:b010::31,
          D=2001:db8:0:5678::501) would end up at SERa based on the unscoped
          default destination route being originated by SERa. Since that
          traffic has the wrong source address to be forwarded to ISP-A, SERa
          would drop it and send a Destination Unreachable message with Code 5
          (Source address failed ingress/egress policy) back to H31. H31 would
          then know to use another source address for that destination and
          would try with (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This
          would be forwarded to SERa based on the source-prefix-scoped default
          destination route still being originated by SERa, and SERa would
          forward it to ISP-A. As discussed above, if we are willing to extend
          ICMPv6, SERa can even tell H31 what source address it should use to
          reach that destination. The expected host behaviour behavior has been
	  discussed in <xref target="sec_both_working_icmpv6"/>. target="sec_both_working_icmpv6" format="default"/>.
	  Using ICMPv6 would have the same scalability/rate limiting issues
          that are discussed in <xref
		  target="sec_both_working_icmpv6"/>. target="sec_both_working_icmpv6" format="default"/>.
          An ISP-B uplink failure immediately makes source addresses from 2001:db8:0:b000::/52
          unsuitable for external communication and might trigger a large
          number of ICMPv6 packets being sent to hosts in that subnet.
          </t>
        </section>
        <section anchor="sec_uplink_failed_summary"
                 title="Summary Of numbered="true" toc="default">
          <name>Summary of Methods For for Controlling Default Source Address Selection On The on the Failure Of An Uplink"> of an Uplink</name>
          <t>It appears that DHCPv6 is not particularly well suited to quickly
          changing the source address used by a host in the event of the
          failure of when an uplink, uplink
          fails, which eliminates DHCPv6 from the list of
          potential solutions. On the other hand hand, Router Advertisements
          provides
          provide a reliable mechanism to dynamically provide hosts with a
          list of valid prefixes to use as source addresses as well as to prevent
          the use of particular prefixes to be used. prefixes. While no additional new features are
          required to be implemented on hosts, routers need to be able to send
          RAs based on the state of scoped forwarding tables table entries and to
          react to network topology changes by sending RAs with particular
          parameters set.</t>

          <t>The
          <t>It seems that the use of ICMPv6 Destination Unreachable messages generated by
          the SER (or any SADR-capable) routers seem like they have the
          potential to provide a support mechanism routers, together with the use of RAs
          to signal source address selection errors back to hosts, however has the
          potential to provide a support mechanism.  However, scalability issues
          may arise in large networks in case of sudden when topology
          change. Therefore suddenly changes.
          Therefore, it is highly desirable that hosts are able to
          select the correct source address in the case of uplinks failure uplink failure, with
          ICMPv6 being an additional mechanism to signal unexpected failures
          back to hosts.</t>
          <t>The current behavior behaviors of different host operating system when
          receiving systems upon receipt of
          an ICMPv6 Destination Unreachable message with code Code 5 (Source
          address failed ingress/egress policy) is not clear to the authors.
          Information from implementers, users, and testing would be quite
          helpful in evaluating this approach.</t>
        </section>
      </section>
      <section anchor="sec_uplink_recover"
               title="Selecting numbered="true" toc="default">
        <name>Selecting Default Source Address Upon upon Failed Uplink Recovery"> Recovery</name>
        <t>The next logical step is to look at the scenario when a failed
        uplink on SERb1 to ISP-B is coming comes back up, so the hosts can start using
        source addresses belonging to 2001:db8:0:b000::/52 again.</t>
        <section anchor="sec_uplink_recover_dhcpv6"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With DHCPv6"> with DHCPv6</name>
          <t>The mechanism to use DHCPv6 to instruct the hosts (H31 in our
          example) to start using prefixes from ISP-B space (e.g. (e.g.,
          S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is
          quite similar to one discussed in <xref
          target="sec_one_uplink_failed_dhcpv6"/> target="sec_one_uplink_failed_dhcpv6" format="default"/> and shares the same
          drawbacks.</t>
        </section>
        <section anchor="sec_uplink_recover_ra"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With with Router Advertisements"> Advertisements</name>
          <t>Let's look at the scenario discussed in <xref
          target="sec_one_uplink_failed_ra"/>. target="sec_one_uplink_failed_ra" format="default"/>.
          If the uplink(s) failure caused
          the complete withdrawal of prefixes from the 2001:db8:0:b000::/52
          address space by setting the Preferred Lifetime value to 0, zero, then the
          recovery of the link should just trigger the sending of a new RA being sent with a
          non-zero Preferred Lifetime. In another scenario discussed in
          <xref
          target="sec_one_uplink_failed_ra"/>, target="sec_one_uplink_failed_ra" format="default"/>, the failure
          of the SERb1 uplink to ISP-B
          failure
          leads to the disappearance of the (S=2001:db8:0:b000::/52,
          D=::/0) entry from the forwarding table scoped to
          S=2001:db8:0:b000::/52 and, in turn, caused causes R3 to send RAs from
          LLA_B
          with the Router Lifetime set to 0. zero from LLA_B. The recovery of the SERb1 uplink to ISP-B leads to (S=2001:db8:0:b000::/52, D=::/0) the reappearance
of the scoped forwarding entry re-appearance and instructs (S=2001:db8:0:b000::/52, D=::/0).
That reappearance acts as a signal for R3 that it should to advertise itself as
a default router for ISP-B address space domain
          (send (to send RAs from LLA_B
with non-zero Router Lifetime).</t> Lifetime).
</t>
        </section>
        <section anchor="sec_uplink_recover_icmp"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With ICMP"> with ICMP</name>

          <t>It looks like ICMPv6 provides a rather limited functionality to
          signal back to hosts that particular source addresses have become
          valid again. Unless the changes in the uplink state specify a particular
          (S,D) pair, hosts can keep using the same source address even after
          an ISP uplink has come back up. For example, after the uplink from
          SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as
          described in <xref target="sec_one_uplink_failed_icmp"/>) target="sec_one_uplink_failed_icmp" format="default"/>) and
          allegedly started using (S=2001:db8:0:a010::31,
          D=2001:db8:0:5678::501) to reach H501. Now when the SERb1 uplink
          comes back up, the packets with that (S,D) pair are still routed to
          SERa1 and sent to the Internet. Therefore Therefore, H31 is not informed that
          it should stop using 2001:db8:0:a010::31 and start using
          2001:db8:0:b010::31 again. Unless SERa has a policy configured to
          drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and
          send ICMPv6 back if the SERb1 uplink to ISP-B is up, H31 will be unaware
          of the network topology change and keep using S=2001:db8:0:a010::31
          for Internet destinations, including H51.</t>

          <t>One of the possible option options may be using a scoped route with an
          EXCLUSIVE flag as described in <xref
          target="sec_both_working_icmpv6"/>. target="sec_both_working_icmpv6" format="default"/>.
          SERa1 uplink recovery would
          cause the (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to
          reappear in the routing table. In the absence of that that, route packets to H101 which were are sent
          to ISP-B (as ISP-A uplink was down) with source addresses from 2001:db8:0:b000::/52.
          When the route
          re-appears reappears, SERb1 would reject rejects those packets and sends ICMPv6 back as
          discussed in <xref target="sec_both_working_icmpv6"/>. Practically target="sec_both_working_icmpv6" format="default"/>. Practically,
          it might lead to scalability issues issues, which have been already
          discussed in <xref target="sec_both_working_icmpv6"/> target="sec_both_working_icmpv6" format="counter"/>
          and <xref
          target="sec_uplink_recover_icmp"/>.</t> target="sec_uplink_recover_icmp" format="counter"/>.</t>
        </section>
        <section anchor="sec_uplink_recover_summary"
                 title="Summary Of numbered="true" toc="default">
          <name>Summary of Methods For for Controlling Default Source Address Selection Upon upon Failed Uplink Recovery"> Recovery</name>
          <t>Once again again, DHCPv6 does not look like a reasonable choice to
          manipulate the source address selection process on a host in the case of
          network topology changes. Using Router Advertisement provides the
          flexible mechanism to dynamically react to network topology changes
          (if routers are able to use routing changes as a trigger for sending
          out RAs with specific parameters). ICMPv6 could be considered as a
          supporting mechanism to signal incorrect source address back to
          hosts
          hosts, but it should not be considered as the only mechanism to control
          the address selection in multihomed environments.</t>
        </section>
      </section>
      <section anchor="sec_all_uplinks_failed"
               title="Selecting numbered="true" toc="default">
        <name>Selecting Default Source Address When All Uplinks Failed"> Have Failed</name>
        <t>One particular tricky case is a scenario when all uplinks have
        failed. In that case case, there is no valid source address to be used for
        any external destinations while when it might be desirable to have
        intra-site connectivity.</t>
        <section anchor="sec_all_uplinks_failed_dhcpv6"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With DHCPv6"> with DHCPv6</name>
          <t>From the DHCPv6 perspective perspective, uplinks failure should be treated as two
          independent failures and processed as described in
          <xref
          target="sec_one_uplink_failed_dhcpv6"/>. target="sec_one_uplink_failed_dhcpv6" format="default"/>. At this stage stage, it is quite
          obvious that it would result in a quite complicated policy table which
          needs that
          would need to be explicitly configured by administrators and therefore
          seems to be impractical.</t>
        </section>
        <section anchor="sec_all_uplinks_failed_ra"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With with Router Advertisements"> Advertisements</name>
          <t>As discussed in <xref target="sec_one_uplink_failed_ra"/> target="sec_one_uplink_failed_ra" format="default"/>, an
          uplink failure causes the scoped default entry to disappear from the
          scoped forwarding table and triggers RAs with zero Router Lifetime. Lifetimes.
          Complete disappearance of all scoped entries for a given source
          prefix would cause the prefix being to be withdrawn from hosts by setting the
          Preferred Lifetime value to zero in the PIO. If all uplinks (SERa, SERb1
          and SERb2) failed, fail, hosts either lost lose their default routers and/or
          have no global IPv6 addresses to use as a source. (Note that 'uplink
          failure' might mean 'IPv6 connectivity failure with IPv4 still being
          reachable', in which case case, hosts might fall back to IPv4 if there is
          IPv4 connectivity to destinations). As a result, intra-site
          connectivity is broken. One of the possible way ways to solve it is to
          use ULAs.</t>

          <t>All
          <t>In addition to GUAs, all hosts have ULA addresses assigned in addition to GUAs assigned, and these addresses are
          used for intra-site communication even if there is no GUA assigned
          to a host. To avoid accidental leaking of packets with ULA sources sources,
          SADR-capable routers SHOULD <bcp14>SHOULD</bcp14> have a scoped forwarding table for ULA
          source for internal routes but MUST NOT <bcp14>MUST NOT</bcp14> have an entry for D=::/0 in
          that table. In the absence of (S=ULA_Prefix; D=::/0) D=::/0), first-hop
          routers will send dedicated RAs from a unique link-local source
          LLA_ULA with a PIO from ULA address space, a RIO for the ULA prefix prefix, and
          Router Lifetime set to zero. The behaviour behavior is consistent with the
          situation when SERb1 lost the uplink to ISP-B (so there is no
          Internet connectivity from 2001:db8:0:b000::/52 sources) sources), but those
          sources can be used to reach some specific destinations. In the case
          of ULA ULA, there is no Internet connectivity from ULA sources sources, but they
          can be used to reach another other ULA destinations. Note that ULA usage
          could be particularly useful if all ISPs assign prefixes via
          DHCP-PD.
          DHCP prefix delegation. In the absence of ULAs, upon the all uplinks
          failure of all uplinks, hosts would lost lose all
          their GUAs upon prefix lifetime expiration prefix-lifetime expiration, which again makes
	  intra-site communication impossible.</t>
          <t>
	  It should be noted that the Rule 5.5 (prefer a prefix advertised by the selected next-hop)
	  takes precedence over the Rule 6 (prefer matching label, which ensures that GUA source addresses
	  are preferred over ULAs for GUA destinations). Therefore if ULAs are used, the network
	  administrator needs to ensure that that, while the site has an Internet connectivity, hosts do not
	  select a router which that advertises ULA prefixes as their default router.
          </t>
        </section>
        <section anchor="sec_all_uplinks_failed_icmp"
                 title="Controlling numbered="true" toc="default">
          <name>Controlling Default Source Address Selection With ICMPv6"> with ICMPv6</name>
          <t>In the case of all uplinks the failure of all uplinks, all SERs will drop outgoing IPv6
          traffic and respond with ICMPv6 error message. messages. In the a large network
          when
          in which many hosts are trying attempt to reach Internet destinations it means
          that destinations,
          the SERs need to generate an ICMPv6 error to for every packet they
          receive from hosts hosts, which presents the same scalability issues
          discussed in <xref target="sec_one_uplink_failed_icmp"/></t> target="sec_one_uplink_failed_icmp" format="default"/>.</t>
        </section>
        <section anchor="sec_all_uplinks_failed_summary"
                 title="Summary Of numbered="true" toc="default">
          <name>Summary of Methods For for Controlling Default Source Address Selection When All Uplinks Failed"> Failed</name>
          <t>Again, combining SADR with Router Advertisements seems to be the
          most flexible and scalable way to control the source address
          selection on hosts.</t>
        </section>
      </section>
      <section anchor="sec_sas_summary"
               title="Summary Of numbered="true" toc="default">
        <name>Summary of Methods For for Controlling Default Source Address Selection">
        <t>To summarize Selection</name>
        <t>This section summarizes the scenarios and options discussed above:</t> above.</t>
        <t>While DHCPv6 allows administrators to manipulate source address
        selection policy tables, this method has a number of significant
        disadvantages which eliminates that eliminate DHCPv6 from a list of potential
        solutions:</t>

        <t><list style="numbers">
            <t>It required
        <ol spacing="normal" type="1">
          <li>It requires hosts to support DHCPv6 and its extension
            (RFC7078);</t>

            <t>DHCPv6
            <xref target="RFC7078"/>.</li>
          <li>A DHCPv6 server needs to monitor network state and detect routing
            changes.</t>

            <t>The
            changes.</li>
          <li>The use of policy tables requires manual configuration and might be extremely
            complicated, especially in the case of a distributed network when in which a large
            number of remote sites are being served by centralized DHCPv6 servers.</t>

            <t>Network servers.</li>
          <li>Network topology/routing policy changes could trigger
            simultaneous re-configuration reconfiguration of large number of hosts hosts, which
            present
            presents serious scalability issues.</t>
          </list></t> issues.</li>
        </ol>
        <t>The use of Router Advertisements to influence the source address
        selection on hosts seem to be the most reliable, flexible flexible, and scalable
        solution. It has the following benefits:</t>

        <t><list style="numbers">
            <t>no
        <ol spacing="normal" type="1">
          <li>No new (non-standard) functionality needs to be implemented on
            hosts (except for <xref target="RFC4191"/> RIO support, support <xref target="RFC4191" format="default"/>,
            which remains is not widely implemented at the time of this writing not widely implemented);</t>

            <t>no writing).</li>
          <li>No changes in RA format;</t>

            <t>routers format.</li>
          <li>Routers can react to routing table changes by sending RAs RAs, which
            would minimize the failover time in the case of network topology
            changes;</t>

            <t>information
            changes.</li>
          <li>Information required for source address selection is broadcast
            to all affected hosts in the case of a topology change event event, which
            improves the scalability of the solution (comparing (compared to DHCPv6
            reconfiguration or ICMPv6 error messages).</t>
          </list></t> messages).</li>
        </ol>
        <t>To fully benefit from the RA-based solution, first-hop routers need
        to implement SADR, belong to the SADR domain domain, and be able to send dedicated RAs per scoped
        forwarding table as discussed above, reacting to network changes with by
        sending new RAs. It should be noted that the proposed solution would
        work even if first-hop routers are not SADR-capable but still able
        to send individual RAs for each ISP prefix and react to topology changes
        as discussed above (e.g. (e.g., via configuration knobs). </t>
        <t>The RA-based solution relies heavily on hosts correctly implementing
        the default address selection algorithm as defined in <xref target="RFC6724"/>. target="RFC6724" format="default"/>.
        While the basic (and basic, and the most common) common, multihoming scenario (two or more Internet
        uplinks, no 'walled gardens') would work for any host supporting the minimal
        implementation of <xref target="RFC6724"/>, target="RFC6724" format="default"/>, more complex use cases (such as
        "walled garden"
        'walled garden' and other scenarios when some ISP resources can only be reached from
        that ISP address space) require that hosts support Rule 5.5 of the default address
        selection algorithm. There is some evidence that not all host OSes
        have that rule implemented currently.  However  However, it should be noted that
        <xref target="RFC8028"/> target="RFC8028" format="default"/> states that Rule 5.5 should be implemented.
        </t>

        <t>ICMPv6
        <t>The ICMPv6 Code 5 error message SHOULD <bcp14>SHOULD</bcp14> be used to complement an RA-based
        solution to signal incorrect source address selection back to hosts,
        but it SHOULD NOT <bcp14>SHOULD NOT</bcp14> be considered as the stand-alone standalone solution.
        To prevent scenarios when hosts in multihomed envinronments environments incorrectly
        identify onlink/offlink on-link/off-link destinations, hosts SHOULD <bcp14>SHOULD</bcp14> treat ICMPv6 Redirects
        as discussed in <xref target="RFC8028"/>. target="RFC8028" format="default"/>. </t>
      </section>
      <section anchor="sec_conn_pre" title="Solution Limitations"> numbered="true" toc="default">
        <name>Solution Limitations</name>
        <section anchor="sec_conn_pre_1" title="Connections Preservation"> numbered="true" toc="default">
          <name>Connections Preservation</name>
          <t>
                The proposed solution is not designed to preserve connection state in the
case of an uplink failure. When all uplinks to an ISP go down down, all transport connections
established to/from that ISP address space will be interrupted (unless the transport
protocol has specific multihoming support). That behaviour behavior is similar to the scenario
of IPv4 multihoming with NAT when an uplink failure causes all connections to be NATed
to completely different public IPv4 addresses. While it does sound suboptimal, it is
determined by the nature of PA address space: if all uplinks to the particular ISP
have failed, there is no path for the ingress traffic to reach the site site, and the egress
traffic is supposed to be dropped by the <xref target="RFC2827">BCP38</xref> ingress filters. filters <xref target="RFC2827" format="default"/>.
The only potential way to overcome this limitation would be running to run BGP with all ISPs
and to advertise all site prefixes to all uplinks - a solution which that shares all the drawbacks
of using the PI address space without having sharing its benefits. Networks willing and capable
of running BGP and using PI are out of scope of this document.
          </t>
          <t>
                It should be noted that in the case of IPv4 NAT-based multihoming multihoming, uplink
recovery could cause connection interruptions as well (unless packet forwarding is
integrated with the tracking of existing NAT sessions tracking so that the egress interface for the existing
sessions is not changed). However However, the proposed solution has a the benefit of preserving
the existing sessions during/after during and after the restoration of the failed uplink restoration. uplink. Unlike the uplink
failure event event, which causes all addresses from the affected prefix to be deprecated deprecated,
the recovery would just add new new, preferred addresses to a host without making any
addresses unavailable. Therefore Therefore, connections estavlished to/from established to and from those addresses
do not have to be interrupted.
          </t>
          <t>
                While it's desirable for active connections to survive ISP failover events, for sites using PA address space
such events affect the reachability of IP addresses assigned to hosts. hosts in sites using
PA address space. Unless the transport (or even higher level higher-level protocols) are is capable
of suviving surviving the host renumbering, the active connections will be broken. The proposed
solution focuses on minimizing the impact of failover for on new connections and for on
multipath-aware protocols.
          </t>
          <t>
		Another way to preserve connection state would be using is to use multipath
transport as discussed in <xref target="sec_mpath"/>. target="sec_mpath" format="default"/>.
          </t>
        </section>
      </section>
      <section anchor="sec_other_params" title="Other numbered="true" toc="default">
        <name>Other Configuration Parameters"> Parameters</name>
        <section anchor="sec_dns" title="DNS Configuration"> numbered="true" toc="default">
          <name>DNS Configuration</name>
          <t>In mutihomed envinronment a multihomed environment, each ISP might provide their own list of
        DNS servers. For example, in the topology shown in
        <xref target="fig_isp_service"/>, target="fig_isp_service" format="default"/>, ISP-A might provide
        H51 2001:db8:0:5555::51 as a recursive DNS server H51 2001:db8:0:5555::51, server, while ISP-B might provide
        H61 2001:db8:0:6666::61 as a recursive DNS server. server (RDNSS).
        <xref target="RFC8106"/> target="RFC8106" format="default"/> defines IPv6 Router Advertisement options to allow
        IPv6 routers to advertise a list of DNS recursive server RDNSS addresses
        and a DNS Search List (DNSSL) to IPv6 hosts. Using RDNSS together with 'scoped' RAs
        as described above would allow a first-hop router (R3 in the <xref target="fig_isp_service"/>) target="fig_isp_service" format="default"/>) to send
        DNS server addresses and search lists provided by each ISP (or the corporate DNS servers server
        addresses if the enterprise is running its own DNS servers - as servers. As discussed below below, the DNS
        split-horizon problem is to too hard to solve without running a local DNS server).</t>

          <t>As discussed in <xref target="sec_all_uplinks_failed_ra"/>, target="sec_all_uplinks_failed_ra" format="default"/>, failure of all ISP uplinks
        would cause deprecation of all addresses assigned to a host from the address space
		of all ISPs.
        If any intra-site IPv6 connectivity is still desirable (most likely to be the case for
        any mid/large scare mid/large-scale network), then ULAs should be used as discussed in
	<xref target="sec_all_uplinks_failed_ra"/>. target="sec_all_uplinks_failed_ra" format="default"/>.
        In such a scenario, the enterprise network should run its own
	recursive DNS server(s) and provide its ULA addresses to hosts via
	RDNSS in RAs send sent  for ULA-scoped
	forwarding table as described in <xref target="sec_all_uplinks_failed_ra"/>.</t>
	target="sec_all_uplinks_failed_ra" format="default"/>.</t>
          <t>There are some scenarios when in which the final outcome of the name resolution might be different
        depending on:</t>
        <t><list style="symbols">
        <t>which
          <ul spacing="normal">
            <li>which DNS server is used;</t>
        <t>which used;</li>
            <li>which source address the client uses to send a DNS query to the server (DNS split horizon).</t>
        </list></t> horizon).</li>
          </ul>
          <t>There is no way currently to instruct a host to use a particular DNS server out of from the configured servers list
        for resolving a particular name. Therefore Therefore, it does not seem feasible to solve the problem of DNS server selection
        on the host (it should be noted that this particular issue is protocol-agnostic and happens for IPv4 as well). In such
        a scenario scenario, it is recommended that the enterprise runs run its own local recursive DNS server.</t>
          <t>To influence host source address selection for packets sent to a particular DNS server server,
        the following requirements must be met:
        <list  style="symbols">
        <t> the
          </t>
          <ul spacing="normal">
            <li>The host supports RIO as defined in <xref target="RFC4191"/>;</t>
        <t> the target="RFC4191" format="default"/>.</li>
            <li>The routers send RIO RIOs for routes to DNS server addresses.</t>
        </list> addresses.</li>
          </ul>
          <t>
        For example, if it is desirable that host H31 reaches the ISP-A DNS server H51 2001:db8:0:5555::51
        using its source address 2001:db8:0:a010::31, then both R1 and R2 should send the RIO RIOs containing the route to 2001:db8:0:5555::51
		(or covering route) in their 'scoped' RAs, containing LLA_A as the default router address and the PO PIO for SLAAC prefix 2001:db8:0:a010::/64.
		In that case the case, host H31 (if it supports the Rule 5.5) would select LLA_A as a next-hop and then chose choose 2001:db8:0:a010::31 as the source address
		for packets to the DNS server.
          </t>
          <t>It should be noted that <xref target="RFC6106"/> target="RFC6106" format="default"/> explicitly prohibits using DNS information if the RA router Router Lifetime
        expired: "An
        has expired:</t>
<blockquote>An RDNSS address or a DNSSL domain name MUST <bcp14>MUST</bcp14> be used only as
        long as both the RA router Lifetime (advertised by a Router
        Advertisement message) and the corresponding option
        Lifetime have not expired.". Therefore expired.
	</blockquote>
<t>Therefore, hosts might ignore RDNSS information provided
        in ULA-scoped RAs RAs, as those RAs would have router lifetime Router Lifetime values set
	to 0. However the updated version of
        RFC6106 (<xref target="RFC8106"/>) zero. However, <xref target="RFC8106" format="default"/>, which
	obsoletes RFC 6106, has removed that requirement removed. requirement.
</t>
          <t>
	As discussed above above, the DNS split-horizon problem and selecting the selection of the correct
DNS server in a multihomed envinroment is environment are not an easy one problems to solve. The proper solution would
require hosts to support the concept of multiple Provisioning
   Domains provisioning domains (PvD, a set of
configuration information associated with a network, <xref target="RFC7556"/>). target="RFC7556" format="default"/>).

</t>
        </section>
      </section>
    </section>
    <section anchor="sec_deployment" title="Deployment Considerations">
	<t>
		The numbered="true" toc="default">
      <name>Deployment Considerations</name>
      <t>The solution described in this document requires certain mechanisms to
	 be supported by the network infrastructure and hosts. It requires some
	 routers in the enterprise site to support some form of Source Address
		Dependent Routing (SADR).
	 SADR. It also requires hosts to be able to learn when the uplink to an ISP changes
         its state so that the corresponding hosts can use appropriate source
		addresses should (or should not) be used. addresses. Ongoing work to create
	 mechanisms to accomplish this are discussed in this document, but they
         are still a work works in progress.
      </t>
      <section anchor="sec_sadr_depl" title="Deploying numbered="true" toc="default">
        <name>Deploying SADR Domain"> Domain</name>

        <t>
	The proposed solution provides does not prescribe particular details regarding deploying an SADR domain within a multihomed enterprise network. However the following guidelines could be applied:
			<list style="symbols">
				<t>The
        </t>
        <ul spacing="normal">
          <li>The SADR domain is usually limited by the multihomed site border.</t>
				<t>The border.</li>
          <li>The minimal deployable scenario requires enabling SADR on all SERs and including them into a single SADR domain.</t>
				<t>As domain.</li>

          <li>As discussed in <xref target="sec_simple_not_dir_conn"/>, target="sec_simple_not_dir_conn" format="default"/>, extending the connected SADR domain beyond that point down the SERs to the first-hop routers can produce more efficient forwarding paths and allow the network to fully benefit from SADR. it It would also simplify the operation of the SADR domain.</t>
				<t>
					During domain.</li>
          <li>During the incremental SADR domain expansion from the SERs down towards first-hop routers routers, it's important to ensure that that, at any moment of time given moment, all SADR-capable routers within the domain are logically connected (see <xref target="sec_method"/>).
				</t>

			</list>
		</t> target="sec_method" format="default"/>).</li>
        </ul>
      </section>
      <section anchor="sec_host" title="Hosts-Related Considerations"> numbered="true" toc="default">
        <name>Hosts-Related Considerations</name>
        <t>
		The solution discussed in this document relies on the default address
		selection algorithm (<xref target="RFC6724"/>) algorithm, Rule 5.5. 5.5 <xref target="RFC6724" format="default"/>.
                While <xref
		target="RFC6724"/> target="RFC6724" format="default"/> considers this rule as optional, the
                more recent <xref
		target="RFC8028"/> target="RFC8028" format="default"/> states that
                "A host SHOULD <bcp14>SHOULD</bcp14> select default routers for each prefix it is
	        assigned an address in". in."  It also recommends
		that hosts should implement Rule 5.5. of <xref target="RFC6724"/>.
		Therefore target="RFC6724" format="default"/>.
		Therefore, while RFC8028-compliant hosts compliant with RFC 8028 already have a mechanism to learn
		about ISP uplinks state changes to ISP uplinks and selecting to select the source addresses
		accordingly, many hosts do not have support such a mechanism supported yet.
        </t>
        <t>
		It should be noted that a multihomed enterprise network utilizing
		multiple ISP prefixes can be considered as a typical multiple
		provisioning domain (mPVD) (mPvD) scenario, as described in <xref
		target="RFC7556"/>. target="RFC7556" format="default"/>.
                This document defines a way for the network to provide
		the PVD PvD information to hosts indirectly, using the existing mechanisms.
		At the same time time, <xref
		target="I-D.ietf-intarea-provisioning-domains"/> target="I-D.ietf-intarea-provisioning-domains" format="default"/> takes one step further
		and describes a comprehensive mechanism for hosts to discover the whole
		set of configuration information associated with different PVD/ISPs. PvDs/ISPs.
		<xref target="I-D.ietf-intarea-provisioning-domains"/> target="I-D.ietf-intarea-provisioning-domains" format="default"/> complements this
		document in terms of making enabling hosts being able to learn about ISP uplink
		states and selecting to select the corresponding source addresses.
        </t>
      </section>
    </section>
    <section anchor="sec_other_solutions" title="Other Solutions"> numbered="true" toc="default">
      <name>Other Solutions</name>
      <section anchor="sec_shim6" title="Shim6"> numbered="true" toc="default">
        <name>Shim6</name>
        <t>The Shim6 working group protocol <xref target="RFC5533" format="default"/>, specified by the Shim6 protocol <xref
        target="RFC5533"/> which
        working group, allows a host at a multihomed site to
        communicate with an external host and to exchange information about
        possible source and destination address pairs that they can use to
        communicate. It The Shim6 working group also specified the REAP protocol REAchability Protocol
        (REAP) <xref
        target="RFC5534"/> target="RFC5534" format="default"/> to detect failures in the path between working
        address pairs and to find new working address pairs. A fundamental
        requirement for Shim6 is that both internal and external hosts need to
        support Shim6. That is, both the host internal to the multihomed site
        and the host external to the multihomed site need to support Shim6 in
        order for there to be any benefit for the internal host to run Shim6.
        The Shim6 protocol specification was published in 2009, but it has not
	been widely implemented. Therefore Shim6 is not considered as a viable solution
        for enterprise multihoming.</t>
      </section>
      <section anchor="sec_nptv6"
               title="IPv6-to-IPv6 numbered="true" toc="default">
        <name>IPv6-to-IPv6 Network Prefix Translation"> Translation</name>
        <t>IPv6-to-IPv6 Network Prefix Translation (NPTv6) <xref
			target="RFC6296"/> target="RFC6296" format="default"/> is not the focus of this document.
		NPTv6 suffers from the same fundamental issue as any other approaches to address
		translation approaches:
		translation: it breaks end-to-end connectivity. Therefore
		NPTv6 is not considered as a desirable solution solution, and this document intentionally
		focuses on solving the enterprise multihoming problem without any form of address translations. translation.
        </t>
        <t>
		 With increasing interest and ongoing work in bringing path awareness to
		transport
		transport- and application layer protocols application-layer protocols, hosts might be able to
		determine the properties of the various network paths and choose among
		the paths that are available to them. As selecting the correct source address is one
		of the possible mechanisms that path-aware hosts may utilize, address
		translation negatively affects hosts path-awareness hosts' path-awareness, which makes NTPv6
		an even more undesirable solution.
        </t>
      </section>
      <section anchor="sec_mpath"
	      title="Multipath Transport"> numbered="true" toc="default">
        <name>Multipath Transport</name>
        <t>
	      Using multipath transport (such as MPTCP, Multipath TCP (MPTCP) <xref target="RFC6824"/> target="RFC6824" format="default"/>
              or multipath capabilities in QUIC) might solve the problems discussed in
              <xref
			target="sec_host_mechanisms"/> target="sec_host_mechanisms" format="default"/> since it a multipath
transport would allow hosts to use multiple
			source addresses for a single connection and to switch between those source
			addresses when a particular address becomes unavailable or a new address
			gets
			is assigned to the host interface. Therefore Therefore, if all hosts in the
			enterprise network are use only using multipath transport for all
			connections, the signaling solution described in
                        <xref
			target="sec_host_mechanisms"/> target="sec_host_mechanisms" format="default"/> might not be needed (it should be noted
			that the Source Address Dependent Routing would still be required to
			deliver packets to the correct uplinks).
			At the time this document was written, multipath transport alone
			could not be considered a solution for the problem of selecting the source
			address in a multihomed environment. There are a significant number of
			hosts which that do not use multipath transport currently currently, and it seems
			unlikely that the situation is going to will change in any the foreseeable
			future (even if new releases of operatin operating systems get multipath protocols support multipath protocols,
                        there will be a long tail of legacy hosts). The solution for enterprise multihoming needs to work for the
			least common denominator: hosts without multipath transport support. In
			addition, not all protocols are using multipath transport. While
			multipath transport would complement the solution described in <xref
			target="sec_host_mechanisms"/>, target="sec_host_mechanisms" format="default"/>, it could not be considered as a sole
			solution to the problem of source address selection in multihomed
			environments.
        </t>
        <t>
			On the other hand hand, PA-based multihoming could provide additional
benefits for to multipath protocol, protocols, should those protocols be deployed in the network. Multipath
protocols could leverage source address selection to achieve maximum path diversity (and potentially improved performance).
        </t>
        <t>
			Therefore deploying
			Therefore, the deployment of multipath protocols could should not be considered
as an alternative to the approach proposed in this document. Instead Instead, both solutions complement
each other other, so deploying multipath protocols in a PA-based multihomed network proves mutually beneficial.
        </t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo asks the IANA for document has no new parameters.</t> IANA actions.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t> <xref target="sec_both_working_icmpv6"/> target="sec_both_working_icmpv6" format="default"/> discusses a mechanism for
			controlling source address selection on hosts using ICMPv6 messages.
Using ICMPv6 to influence source address selection allows an attacker to exhaust the list of candidate source
          addresses on the host by sending spoofed ICMPv6 Code 5 for all
          prefixes known on the network (therefore preventing a victim from
	  establishing a communication with the destination host).
          Another possible attack vector is using ICMPv6 Destination Unreachable
          Messages with Code 5 to steer the egress tra
ffic
          traffic towards the particular ISP (for example if ISP, so the attacker has the can benefit from
          their ability of doing traffic sniffing or man-in-the-middle attack sniffing/interception
          in that ISP network).
  </t> network.</t>
      <t>
	  To prevent those attacks attacks, hosts SHOULD <bcp14>SHOULD</bcp14> verify that the original packet
header included into in the ICMPv6 error message was actually sent by the host (to ensure that the
ICMPv6 message was triggered by a packet sent by the host).
      </t>
      <t>
	  As ICMPv6 Destination Unreachable Messages with Code 5 could be originated by any
SADR-capable router within the domain (or even come from the Internet), GTSM (<xref target="RFC5082"/>) can not the Generalized TTL
Security Mechanism (GTSM) <xref target="RFC5082" format="default"/> cannot be applied.
Filtering such ICMOv6 ICMPv6 messages at the site border can not cannot be recommended as it would break
the legitimate end2end end-to-end error signalling signaling mechanism for which ICMPv6 is designed for. was designed.
      </t>
      <t>
		    The security considerations of using stateless address autoconfiguration are discussed in <xref target="RFC4862"/>. target="RFC4862" format="default"/>.
      </t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.pfister-6man-sadr-ra" to="SADR-RA"/>
    <displayreference target="I-D.ietf-rtgwg-dst-src-routing" to="DST-SRC-RTG"/>
    <displayreference target="I-D.ietf-intarea-provisioning-domains" to="PROV-DOMAINS"/>
    <displayreference target="RFC2827" to="BCP38"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6296.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6106.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8028.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7078.xml"/>
      </references>
      <references>
        <name>Informative References</name>
<!-- draft-pfister-6man-sadr-ra-01 expired Dec 2015 -->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.pfister-6man-sadr-ra.xml"/>
<!-- draft-ietf-rtgwg-dst-src-routing-07 expired Sept 2019 -->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-dst-src-routing.xml"/>
<!-- draft-ietf-intarea-provisioning-domains-08 is an active WG draft -->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-provisioning-domains.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5533.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5534.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8504.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4941.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7676.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6824.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8425.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The original outline was suggested by Ole Troan.</t> <contact fullname="Ole Trøan"/>.</t>
      <t>
    The authors would like to thank the following people (in alphabetical order) for their review and feedback:
		    Olivier Bonaventure, Deborah Brungard, Brian E Carpenter,
		    Lorenzo Colitti, Roman Danyliw, Benjamin Kaduk, Suresh Krishnan, Mirja Kuhlewind,
		    David Lamparter, Nicolai Leymann, Acee Lindem, Philip Matthewsu, Robert Raszuk, Alvaro Retana, Pete Resnick, Dave Thaler, Michael Tuxen, Martin Vigoureux, Eric Vyncke, Magnus Westerlund.
    <contact fullname="Olivier Bonaventure"/>, <contact
    fullname="Deborah Brungard"/>, <contact fullname="Brian E.&nbsp;Carpenter"/>,
    <contact fullname="Lorenzo Colitti"/>, <contact fullname="Roman
      Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact
      fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"/>,
    <contact fullname="David Lamparter"/>, <contact fullname="Nicolai
      Leymann"/>, <contact fullname="Acee Lindem"/>, <contact
      fullname="Philip Matthews"/>, <contact fullname="Robert
      Raszuk"/>, <contact fullname="Alvaro Retana"/>, <contact
      fullname="Pete Resnick"/>, <contact fullname="Dave Thaler"/>,
      <contact fullname="Michael Tüxen"/>, <contact fullname="Martin
	Vigoureux"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Magnus Westerlund"/>.
      </t>
    </section>
  </middle>

  <back>
    <!-- references split to informative and normative -->

    <references title="Normative References">
      <?rfc include="reference.RFC.2827" ?>

      <?rfc include="reference.RFC.4193" ?>

      <?rfc include="reference.RFC.6296" ?>

      <?rfc include="reference.RFC.1918" ?>

      <?rfc include="reference.RFC.2119"?>

	  <?rfc include="reference.RFC.8415" ?>

      <?rfc include="reference.RFC.4191" ?>
      <?rfc include="reference.RFC.4291" ?>

      <?rfc include="reference.RFC.6106" ?>
      <?rfc include="reference.RFC.8106" ?>

      <?rfc include="reference.RFC.7556" ?>

      <?rfc include="reference.RFC.8028" ?>
      <?rfc include="reference.RFC.8174" ?>
      <?rfc include="reference.RFC.4443" ?>
      <?rfc include="reference.RFC.4861" ?>
      <?rfc include="reference.RFC.4862" ?>
      <?rfc include="reference.RFC.6724" ?>
      <?rfc include="reference.RFC.7078" ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.pfister-6man-sadr-ra" ?>

      <?rfc include="reference.I-D.ietf-rtgwg-dst-src-routing" ?>

      <?rfc include="reference.I-D.ietf-intarea-provisioning-domains" ?>

      <?rfc include="reference.RFC.5533" ?>

      <?rfc include="reference.RFC.5534" ?>
      <?rfc include="reference.RFC.5082" ?>
      <?rfc include="reference.RFC.6434" ?>

      <?rfc include="reference.RFC.4941" ?>
      <?rfc include="reference.RFC.7676" ?>

      <?rfc include="reference.RFC.3704" ?>
      <?rfc include="reference.RFC.6824" ?>
	</references>
  </back>
</rfc>