rfc8678xml2.original.xml   rfc8678.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!-- converted to v3: xml2rfc v2v3 conversion 2.32.0 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- Some of the more generally applicable PIs that most I-Ds might want to use <rfc
--> xmlns:xi="http://www.w3.org/2001/XInclude"
<!-- Try to enforce the ID-nits conventions and DTD validity --> docName="draft-ietf-rtgwg-enterprise-pa-multihoming-12"
<?rfc strict="yes" ?> number="8678"
<!-- Items used when reviewing the document --> updates=""
<?rfc comments="no" ?> obsoletes=""
<!-- Controls display of <cref> elements --> category="info"
<?rfc inline="no" ?> submissionType="IETF"
<!-- When no, put comments at end in comments section, consensus="true"
otherwise, put inline --> ipr="trust200902"
<?rfc editing="no" ?> sortRefs="true"
<!-- When yes, insert editing marks: editing marks consist of a symRefs="true"
string such as <29> printed in the blank line a xml:lang="en"
t the tocInclude="true"
beginning of each paragraph of text. --> version="3">
<!-- 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 pr
efer
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. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not st
arting each
main section on a new page but does not omit the blank lines between li
st 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 -->
<rfc category="info"
docName="draft-ietf-rtgwg-enterprise-pa-multihoming-12"
ipr="trust200902">
<front> <front>
<title abbrev="Enterprise PA Multihoming">Enterprise Multihoming using <title abbrev="Enterprise PA Multihoming">Enterprise Multihoming Using
Provider-Assigned IPv6 Addresses without Network Prefix Translation: Provider-Assigned IPv6 Addresses without Network Prefix Translation:
Requirements and Solutions</title> Requirements and Solutions</title>
<seriesInfo name="RFC" value="8678"/>
<author fullname="Fred Baker" initials="F.J." surname="Baker"> <author fullname="Fred Baker" initials="F" surname="Baker">
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Santa Barbara</city> <city>Santa Barbara</city>
<code>93117</code> <code>93117</code>
<region>California</region> <region>California</region>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>FredBaker.IETF@gmail.com</email> <email>FredBaker.IETF@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Chris Bowers" initials="C" surname="Bowers">
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<code>94089</code> <code>94089</code>
<region>California</region> <region>California</region>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>cbowers@juniper.net</email> <email>cbowers@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Jen Linkova" initials="J" surname="Linkova">
<author fullname="Jen Linkova" initials="J." surname="Linkova"> <organization>Google</organization>
<organization>Google</organization> <address>
<address>
<postal> <postal>
<street>1 Darling Island Rd</street> <street>1 Darling Island Rd</street>
<city>Pyrmont</city> <city>Pyrmont</city>
<region>NSW</region> <region>NSW</region>
<code>2009</code> <code>2009</code>
<country>AU</country> <country>Australia</country>
</postal> </postal>
<phone/>
<phone></phone>
<email>furry@google.com</email> <email>furry@google.com</email>
</address> </address>
</author> </author>
<date year="2019" month="December"></date>
<date/>
<area>Routing Area</area> <area>Routing Area</area>
<workgroup>Routing Working Group</workgroup> <workgroup>Routing Working Group</workgroup>
<abstract> <abstract>
<t>Connecting an enterprise site to multiple ISPs over IPv6 using <t>Connecting an enterprise site to multiple ISPs over IPv6 using
provider-assigned addresses is difficult without the use of some form of provider-assigned addresses is difficult without the use of some form of
Network Address Translation (NAT). Much has been written on this topic 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 over the last 10 to 15 years, but it still remains a problem without a
clearly defined or widely implemented solution. Any multihoming solution clearly defined or widely implemented solution. Any multihoming solution
without NAT requires hosts at the site to have addresses from each ISP 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 and to select the egress ISP by selecting a source address for outgoing
skipping to change at line 118 skipping to change at line 77
<abstract> <abstract>
<t>Connecting an enterprise site to multiple ISPs over IPv6 using <t>Connecting an enterprise site to multiple ISPs over IPv6 using
provider-assigned addresses is difficult without the use of some form of provider-assigned addresses is difficult without the use of some form of
Network Address Translation (NAT). Much has been written on this topic 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 over the last 10 to 15 years, but it still remains a problem without a
clearly defined or widely implemented solution. Any multihoming solution clearly defined or widely implemented solution. Any multihoming solution
without NAT requires hosts at the site to have addresses from each ISP 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 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 packets. It also requires routers at the site to take into account those
source addresses when forwarding packets out towards the ISPs.</t> source addresses when forwarding packets out towards the ISPs.</t>
<t>This document examines currently available mechanisms for providing a s olution <t>This document examines currently available mechanisms for providing a s olution
to this problem for a broad range of enterprise topologies. to this problem for a broad range of enterprise topologies.
It covers the behavior of routers to forward traffic taking into account It covers the behavior of routers to forward traffic by taking into accoun t
source address, and it covers the behavior of hosts to select appropriate source address, and it covers the behavior of hosts to select appropriate
default source addresses. It also covers any possible role that routers mi ght default source addresses. It also covers any possible role that routers mi ght
play in providing information to hosts to help them select appropriate play in providing information to hosts to help them select appropriate
source addresses. In the process of exploring potential solutions, this source addresses. In the process of exploring potential solutions, this
document also makes explicit requirements for how the solution would be document also makes explicit requirements for how the solution would be
expected to behave from the perspective of an enterprise site network expected to behave from the perspective of an enterprise site network
administrator.</t> administrator.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Site multihoming, the connection of a subscriber network to multiple <t>Site multihoming, the connection of a subscriber network to multiple
upstream networks using redundant uplinks, is a common enterprise upstream networks using redundant uplinks, is a common enterprise
architecture for improving the reliability of its Internet connectivity. architecture for improving the reliability of its Internet connectivity.
If the site uses provider-independent (PI) addresses, all traffic If the site uses provider-independent (PI) addresses, all traffic
originating from the enterprise can use source addresses from the PI originating from the enterprise can use source addresses from the PI
address space. Site multihoming with PI addresses is commonly used with address space. Site multihoming with PI addresses is commonly used with
both IPv4 and IPv6, and does not present any new technical both IPv4 and IPv6, and does not present any new technical
challenges.</t> challenges.</t>
<t>It may be desirable for an enterprise site to connect to multiple <t>It may be desirable for an enterprise site to connect to multiple
ISPs using provider-assigned (PA) addresses, instead of PI addresses. ISPs using provider-assigned (PA) addresses instead of PI addresses.
Multihoming with provider-assigned addresses is typically less expensive Multihoming with provider-assigned addresses is typically less expensive
for the enterprise relative to using provider-independent addresses as it does not for the enterprise relative to using provider-independent addresses as it does not
require obtaining and maintaining PI address space as well as running BGP require obtaining and maintaining PI address space nor does it require
between the enterprise and the ISPs (for small/meduim networks running BGP might running BGP between the enterprise and the ISPs (for small/medium networks
be not just undesirable but impossible, especially if residential-type ISP conn ,
ections are used). running BGP might be not only undesirable but also impossible, especially
if
residential-type ISP connections are used).
PA multihoming is also a practice that should be facilitated and encourage d PA multihoming is also a practice that should be facilitated and encourage d
because it does not add to the size of the Internet routing table, 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 whereas PI multihoming does. Note that PA is also used to mean
"provider-aggregatable". In this document we assume that "provider-aggregatable". In this document, we assume that
provider-assigned addresses are always provider-aggregatable.</t> provider-assigned addresses are always provider-aggregatable.</t>
<t>With PA multihoming, for each ISP connection, the site is assigned a <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 prefix from within an address block allocated to that ISP by its
National or Regional Internet Registry. In the simple case of two ISPs 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 (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, it (prefix-A and prefix-B). This arrangement is problematic. First,
packets with the "wrong" source address may be dropped by one of the packets with the "wrong" source address may be dropped by one of the
ISPs. In order to limit denial of service attacks using spoofed source ISPs. In order to limit denial-of-service attacks using spoofed source
addresses, <xref target="RFC2827">BCP38</xref> recommends that ISPs addresses, <xref target="RFC2827" format="default"/> recommends that ISPs
filter traffic from customer sites to only allow traffic with a source filter traffic from customer sites to allow only traffic with a source
address that has been assigned by that ISP. So a packet sent from a 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 multihomed site on the uplink to ISP-B with a source address in prefix-A
may be dropped by ISP-B.</t> may be dropped by ISP-B.</t>
<t>However, even if ISP-B does not implement BCP 38, or ISP-B adds
<t>However, even if ISP-B does not implement BCP38 or ISP-B adds
prefix-A to its list of allowed source addresses on the uplink from the 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 multihomed site, two-way communication may still fail. If the packet
with source address in prefix-A was sent to ISP-B because the uplink to 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 and the packet ISP-A failed, then if ISP-B does not drop the packet, and the packet
reaches its destination somewhere on the Internet, the return packet reaches its destination somewhere on the Internet, the return packet
will be sent back with a destination address in prefix-A. The return 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 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 fa iled. delivered to the multihomed site because the site uplink with ISP-A has fa iled.
Two-way communication would require some arrangement for ISP-B to Two-way communication would require some arrangement for ISP-B to
advertise prefix-A when the uplink to ISP-A fails.</t> advertise prefix-A when the uplink to ISP-A fails.</t>
<t>Note that the same may be true of a provider that does not
<t>Note that the same may be true with a provider that does not implement BCP 38, even if his upstream provider does, or of a provider
implement BCP 38, if his upstream provider does, or has no corresponding that has no corresponding route to deliver the ingress traffic
route to deliver the ingress traffic to the multihomed site. The issue is to the multihomed site. The issue is not that the immediate provider imple
not that the immediate provider implements ingress ments ingress
filtering; it is that someone upstream does (so egress traffic is blocked) filtering; it is that someone upstream does (so egress traffic is blocked)
, or lacks a route (causing blackholing of the ingress traffic).</t> or lacks a route (causing blackholing of the ingress traffic).</t>
<t>
<t> Another issue with asymmetric traffic flow (when the egress traffic
Another issue with asymmetric traffic flow (when the egress traffic leave leaves the site via one ISP, but the return traffic enters the site
s the site via one ISP but the return traffic enters the site via another uplink via another uplink) is related to stateful firewalls/middleboxes.
) is related to stateful firewalls/middleboxes. Keeping state in that case might Keeping state in that case might be problematic, even impossible.
be problematic, even impossible.
</t> </t>
<t>With IPv4, this problem is commonly solved by using <xref <t>With IPv4, this problem is commonly solved by using private address
target="RFC1918"/> private address space within the multi-homed site and space described in <xref target="RFC1918" format="default"/> within the mu
ltihomed site and
Network Address Translation (NAT) or Network Address/Port Translation Network Address Translation (NAT) or Network Address/Port Translation
(NAPT) on the uplinks to the ISPs. However, one of the goals of IPv6 is (NAPT) <xref target="RFC2663"/> on the uplinks to the ISPs. However, one o f the goals of IPv6 is
to eliminate the need for and the use of NAT or NAPT. Therefore, 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 requiring the use of NAT or NAPT for an enterprise site to multihome
with provider-assigned addresses is not an attractive solution.</t> with provider-assigned addresses is not an attractive solution.</t>
<t><xref target="RFC6296" format="default"/> describes a translation solut
<t><xref target="RFC6296"/> describes a translation solution ion
specifically tailored to meet the requirements of multi-homing with specifically tailored to meet the requirements of multihoming with
provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix provider-assigned IPv6 addresses. With the IPv6-to-IPv6 Network Prefix
Translation (NPTv6) solution, within the site an enterprise can use Translation (NPTv6) solution, an enterprise can use either
Unique Local Addresses <xref target="RFC4193"/> or the prefix assigned Unique Local Addresses <xref target="RFC4193" format="default"/> or the pr
by one of the ISPs. As traffic leaves the site on an uplink to an ISP, efix assigned
the source address gets translated to an address within the prefix by one of the ISPs within its site. As traffic leaves the site on an uplin
assigned by the ISP on that uplink in a predictable and reversible k to an ISP,
manner. <xref target="RFC6296"/> is currently classified as the source address is translated in a predictable and reversible manner
Experimental, and it has been implemented by several vendors. See <xref to an address within the prefix assigned by the ISP on that uplink.
target="sec_nptv6"/>, for more discussion of NPTv6.</t> <xref target="RFC6296" format="default"/> is currently classified as
Experimental, and it has been implemented by several vendors.
<t>This document defines routing requirements for enterprise multihoming See <xref target="sec_nptv6" format="default"/> for more discussion of NPT
v6.</t>
<t>This document defines routing requirements for enterprise multihoming.
This document focuses on the following general class of This document focuses on the following general class of
solutions.</t> solutions.</t>
<t>Each host at the enterprise has multiple addresses, at least one from <t>Each host at the enterprise has multiple addresses, at least one from
each ISP-assigned prefix. Each host, as discussed in <xref each ISP-assigned prefix. As discussed in <xref target="sec_host_address_s
target="sec_host_address_selection_algo"/> and <xref target="RFC6724"/>, election_algo" format="default"/>
is responsible for choosing the source address applied to each packet it and in <xref target="RFC6724" format="default"/>, each host
sends. A host is expected to be able respond dynamically to the failure of is responsible for choosing the source address that is applied to each pac
an ket 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 uplink to a given ISP by no longer sending packets with the source
address corresponding to that ISP. Potential mechanisms for the address corresponding to that ISP. Potential mechanisms for
communication of changes in the network to the host are Neighbor communicating network changes to the host are Neighbor
Discovery Router Advertisements (<xref target="RFC4861"/>), DHCPv6 (<xref Discovery Router Advertisements <xref target="RFC4861" format="default"/>,
target="RFC8415"/>), and ICMPv6 (<xref target="RFC4443"/>).</t> DHCPv6 <xref target="RFC8415" format="default"/>, and ICMPv6 <xref target="RFC4
443" format="default"/>.</t>
<t>The routers in the enterprise network are responsible for ensuring <t>The routers in the enterprise network are responsible for ensuring
that packets are delivered to the "correct" ISP uplink based on source that packets are delivered to the "correct" ISP uplink based on source
address. This requires that at least some routers in the site network 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 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 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 form of Source Address Dependent Routing (SADR), if only as described in
the section 4.3 of <xref target="RFC3704"/>. At a minimum, the routers con nected to the ISP <xref 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 uplinks (the site exit routers or SERs) must be capable of Source
Address Dependent Routing. Expanding the connected domain of routers Address Dependent Routing. Expanding the connected domain of routers
capable of SADR from the site exit routers deeper into the site network capable of SADR from the site exit routers deeper into the site network
will generally result in more efficient routing of traffic with external will generally result in more efficient routing of traffic with external
destinations.</t> destinations.</t>
<t>This document is organized as follows. <xref target="sec_enterprise_req
<t>This document is organized as follows. <xref target="sec_enterprise_req " format="default"/> looks in more detail at the
"/> looks in more detail at the
enterprise networking environments in which this solution is expe cted to enterprise networking environments in which this solution is expe cted to
operate. The discussion of <xref target="sec_enterprise_req"/> us operate. The discussion of <xref target="sec_enterprise_req" form
es the concepts of at="default"/> uses the concepts of
source-prefix-scoped routing advertisements and forwarding tables Source-Prefix-Scoped Routing advertisements and forwarding tables
and provides a description of how and describes how
source-prefix-scoped routing advertisements are used to generate Source-Prefix-Scoped Routing advertisements are used to generate
source-prefix-scoped forwarding tables. Instead, this detailed source-prefix-scoped forwarding tables. A detailed
description is provided in <xref target="sec_method"/>. <xref tar description of generating source-prefix-scoped forwarding tables
get="sec_host_mechanisms"/> is provided in
<xref target="sec_method" format="default"/>. <xref target="sec_
host_mechanisms" format="default"/>
discusses existing and proposed mechanisms for hosts to discusses existing and proposed mechanisms for hosts to
select the default source address to be used by applications. select the default source address to be used by applications.
It also discusses the requirements for routing that are needed to It also discusses the requirements for routing that are needed to
support these enterprise network scenarios and the mechanisms by support these enterprise network scenarios and the mechanisms by
which hosts are expected to update default source addresses based which hosts are expected to update default source addresses based
on network state. on network state.
<xref target="sec_deployment"/> discusses deployment consideratio <xref target="sec_deployment" format="default"/> discusses deploy
ns, while <xref target="sec_other_solutions"/> discusses other solutions.</t> ment considerations, while <xref target="sec_other_solutions" format="default"/>
discusses other solutions.</t>
</section> </section>
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT" <name>Requirements Language</name>
, "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL <t>
" in this document are to be interpreted as described in BCP 14 <xref target="RF The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
C2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capita IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ls, as shown here.</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section title="Terminology"> <section numbered="true" toc="default">
<t> <name>Terminology</name>
PA (provider-assigned or provider-aggregatable) address space <dl>
: a block of IP addresses assigned by an Regional Internet Registry (RIR) to a L <dt>PA (provider-assigned or provider-aggregatable) address space:</dt
ocal Internet Registry (LIR), used to create allocations to end sites. Can be ag >
gregated and present in the routing table as one route. <dd>a block of IP addresses assigned by a Regional Internet Registry (
</t> RIR)
<t> to a Local Internet Registry (LIR), used to create allocations to
PI (provider-independent) address space: a block of IP addres end sites.
ses assigned by an Regional Internet Registry (RIR) directly to end site/end cus Can be aggregated and present in the routing table as one route.</
tomer. dd>
</t> <dt>PI (provider-independent) address space:</dt>
<t> <dd>a block of IP addresses assigned by a Regional Internet Registry
ISP: Internet Service Provider. (RIR) directly to end site / end customer.</dd>
</t> <dt>ISP:</dt>
<t> <dd>Internet Service Provider</dd>
LIR (Local Internet Registry): an organisation (usually an IS <dt>LIR (Local Internet Registry):</dt>
P or an enterprise/academic) which receives IP addresses allocation from its Reg <dd>an organization (usually an ISP or an enterprise/academic) that re
ional Internet Regsitry, then assign parts of that allocation to its customers. ceives
</t> its allocation of IP addresses from its Regional Internet Registry
<t> , then assigns parts of that allocation to its customers.</dd>
RIR (Regional Internet Registry): an organization which manag <dt>RIR (Regional Internet Registry):</dt>
es the Internet number resources (such as IP addresses and AS numbers) within a <dd>an organization that manages the Internet number resources (such
geographical region of the world. as IP addresses and autonomous system (AS) numbers)
</t> within a geographical region of the world.</dd>
<t> <dt>SADR (Source Address Dependent Routing):</dt>
SADR (Source Address Dependent Routing): Routing which takes <dd>routing that takes into account the source address of a packet in
into account the source address of a packet in addition to the packet destinatio addition to the packet destination address.</dd>
n address. <dt>SADR domain:</dt>
</t> <dd>a routing domain in which some (or all) routers exchange source-de
<t> pendent routing information.</dd>
SADR domain: a routing domain where some (or all) routers exc <dt>Source-Prefix-Scoped Routing/Forwarding Table:</dt>
hange source-dependent routing information. <dd>a routing (or forwarding) table that contains routing (or forwardi
</t> ng) information only
<t> applicable to packets with source addresses from the specific pref
Source-Prefix-Scoped Routing/Forwarding Table: a routing (or ix.</dd>
forwarding) table which contains routing (or forwarding) information which is ap <dt>Unscoped Routing/Forwarding Table:</dt>
plicable to packets with source addresses from the specific prefix only. <dd>a routing (or forwarding) table that can be used to route/forward
</t> packets with any source address.</dd>
<t> <dt>SER (Site Edge Router):</dt>
Unscoped Routing/Forwarding Table: a routing (or forwarding <dd>a router that connects the site to an ISP (terminates an ISP uplin
) table which can be used to route/forward packets with any source addresses. k).</dd>
</t> <dt>LLA (Link-Local Address):</dt>
<t> <dd>an IPv6 unicast address from the fe80::/10 prefix <xref target="RF
SER (Site Edge Router): a router which connects the site to a C4291" format="default"/>.</dd>
n ISP (terminates an ISP uplink).. <dt>ULA (Unique Local IPv6 Unicast Address):</dt>
</t> <dd>an IPv6 unicast address from the FC00::/7 prefix. They are globall
<t> y unique and intended for
LLA (Link-Local Address): IPv6 Unicast Address from fe80::/10 local communications <xref target="RFC4193" format="default"/>.</d
prefix (<xref target="RFC4291"/>). d>
</t> <dt>GUA (Global Unicast Address):</dt>
<t> <dd>a globally routable IPv6 address of the global scope <xref target=
ULA (Unique Local IPv6 Unicast Address): IPv6 unicast address "RFC4291" format="default"/>.</dd>
es from FC00::/7 prefix. They are globally unique and intended for local communi <dt>SLAAC (IPv6 Stateless Address Autoconfiguration):</dt>
cations (<xref target="RFC4193"/>). <dd>a stateless process of configuring the network stack on IPv6 hosts
</t> <xref target="RFC4862" format="default"/>.</dd>
<t> <dt>RA (Router Advertisement):</dt>
GUA (Global Unicast Address): globally routable IPv6 addresse <dd>a message sent by an IPv6 router to advertise its presence to host
s of the global scope (<xref target="RFC4291"/>). s together with various
</t> network-related parameters required for hosts to perform SLAAC <xr
<t> ef target="RFC4861" format="default"/>.</dd>
SLAAC (IPv6 Stateless Address Autoconfiguration): a stateless <dt>PIO (Prefix Information Option):</dt>
process of configuring network stack on IPv6 hosts (<xref target="RFC4862"/>). <dd>a part of an RA message containing information about IPv6 prefixes
</t> that could be used by hosts
<t> to generate global IPv6 addresses <xref target="RFC4862" format="d
RA (Router Advertisement): a message sent by an IPv6 router t efault"/>.</dd>
o advertise its presence to hosts together with various network-related paramete <dt>RIO (Route Information Option):</dt>
rs required for hosts to perform SLAAC (<xref target="RFC4861"/>). <dd>a part of an RA message containing information about more specific
</t> IPv6 prefixes reachable
<t> via the advertising router <xref target="RFC4191" format="default"
PIO (Prefix Information Option): a part of RA message contain />.</dd>
ing information about IPv6 prefixes which could be used by hosts to generate glo </dl>
bal IPv6 addresses (<xref target="RFC4862"/>).
</t>
<t>
RIO (Route Information Option): a part of RA message containi
ng information about more specific IPv6 prefixes reachable via the advertising r
outer (<xref target="RFC4191"/>).
</t>
</section> </section>
<section anchor="sec_enterprise_req" numbered="true" toc="default">
<section anchor="sec_enterprise_req" <name>Enterprise Multihoming Use Cases</name>
title="Enterprise Multihoming Use Cases"> <section anchor="sec_simple_scenario" numbered="true" toc="default">
<section anchor="sec_simple_scenario" <name>Simple ISP Connectivity with Connected SERs</name>
title="Simple ISP Connectivity with Connected SERs">
<t>We start by looking at a scenario in which a site has connections <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"/>. The to two ISPs, as shown in <xref target="fig_simple_scenario" format="defa ult"/>. The
site is assigned the prefix 2001:db8:0:a000::/52 by ISP-A and prefix 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. 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 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 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 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 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 different subnet that has been assigned 2001:db8:0:a020::/64 and
2001:db8:0:b020::/64.</t> 2001:db8:0:b020::/64.</t>
<figure anchor="fig_simple_scenario">
<name>Simple ISP Connectivity with Connected SERs</name>
<figure align="center" anchor="fig_simple_scenario" <artwork align="center" name="" type="" alt=""><![CDATA[
title="Simple ISP Connectivity With Connected SERs"> 2001:db8:0:1234::101 H101
<artwork align="center"><![CDATA[ |
2001:db8:0:1234::101 H101 |
| 2001:db8:0:a010::31 --------
| 2001:db8:0:b010::31 ,-----. / \
2001:db8:0:a010::31 -------- +--+ +--+ +----+ ,' `. : :
2001:db8:0:b010::31 ,-----. / \ +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
+--+ +--+ +----+ ,' `. : : H31--+ +--+ +--+ | +----+ `. ,' : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : | | `-----' : Internet :
H31--+ +--+ +--+ | +----+ `. ,' : : | | : :
| | `-----' : Internet : | | : :
| | : : | | : :
| | : : | | ,-----. : :
| | : : H32--+ +--+ | +----+ ,' `. : :
| | ,-----. : : +---|R2|----------+---|SERb|-+ ISP-B +--+-- :
H32--+ +--+ | +----+ ,' `. : : +--+ | +----+ `. ,' : :
+---|R2|----------+---|SERb|-+ ISP-B +--+-- : | `-----' : :
+--+ | +----+ `. ,' : : | : :
| `-----' : : +--+ +--+ +--+ \ /
| : : H41------|R3|--|R5|--|R6| --------
+--+ +--+ +--+ \ / +--+ +--+ +--+
H41------|R3|--|R5|--|R6| --------
+--+ +--+ +--+
2001:db8:0:a020::41 2001:db8:0:a020::41
2001:db8:0:b020::41 2001:db8:0:b020::41
]]></artwork> ]]></artwork>
</figure> </figure>
<t>We refer to a router that connects the site to an ISP as a site <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 edge router (SER). Several other routers provide connectivity among the
internal hosts (H31, H32, and H41), as well as connecting the internal internal hosts (H31, H32, and H41), as well as connect the internal
hosts to the Internet through SERa and SERb. In this example SERa and hosts to the Internet through SERa and SERb. In this example, SERa and
SERb share a direct connection to each other. In <xref SERb share a direct connection to each other.
target="sec_simple_not_dir_conn"/>, we consider a scenario where this In <xref target="sec_simple_not_dir_conn" format="default"/>, we conside
r a scenario in which this
is not the case.</t> is not the case.</t>
<t>For the moment, we assume that the hosts are able to select
<t>For the moment, we assume that the hosts are able to make good suitable source addresses through some mechanism that
choices about which source addresses through some mechanism that
doesn't involve the routers in the site network. Here, we focus on doesn't involve the routers in the site network. Here, we focus on
primary task of the routed site network, which is to get packets the primary task of the routed site network, which is to get packets
efficiently to their destinations, while sending a packet to the ISP efficiently to their destinations, while sending a packet to the ISP
that assigned the prefix that matches the source address of the that assigned the prefix that matches the source address of the
packet. In <xref target="sec_host_mechanisms"/>, we examine what role packet. In <xref target="sec_host_mechanisms" format="default"/>, we exa
the routed network may play in helping hosts make good choices about mine what role
the routed network may play in helping hosts select suitable
source addresses for packets.</t> source addresses for packets.</t>
<t>With this solution, routers will need some form of Source Address <t>With this solution, routers will need some form of Source Address
Dependent Routing, which will be new functionality. It would be useful Dependent Routing, which will be new functionality. It would be useful
if an enterprise site does not need to upgrade all routers to support if an enterprise site does not need to upgrade all routers to support
the new SADR functionality in order to support PA multi-homing. We the new SADR functionality in order to support PA multihoming. We
consider if this is possible and what are the tradeoffs of not having consider whether this is possible and examine the trade-offs of not havi
ng
all routers in the site support SADR functionality.</t> all routers in the site support SADR functionality.</t>
<t>In the topology in <xref target="fig_simple_scenario" format="default
<t>In the topology in <xref target="fig_simple_scenario"/>, it is "/>, it is
possible to support PA multihoming with only SERa and SERb being possible to support PA multihoming with only SERa and SERb being
capable of SADR. The other routers can continue to forward based only capable of SADR. The other routers can continue to forward based only
on destination address, and exchange routes that only consider on destination address, and exchange routes that only consider
destination address. In this scenario, SERa and SERb communicate destination address. In this scenario, SERa and SERb communicate
source-scoped routing information across their shared connection. When source-scoped routing information across their shared connection. When
SERa receives a packet with a source address matching prefix SERa receives a packet with a source address matching prefix
2001:db8:0:b000::/52 , it forwards the packet to SERb, which forwards 2001:db8:0:b000::/52, it forwards the packet to SERb, which forwards
it on the uplink to ISP-B. The analogous behaviour holds for traffic it on the uplink to ISP-B. The analogous behavior holds for traffic
that SERb receives with a source address matching prefix that SERb receives with a source address matching prefix
2001:db8:0:a000::/52.</t> 2001:db8:0:a000::/52.</t>
<t>In <xref target="fig_simple_scenario"/>, when only SERa and SERb <t>In <xref target="fig_simple_scenario" format="default"/>, when only S
are capable of source address dependent routing, PA multi-homing will ERa and SERb
are capable of source address dependent routing, PA multihoming will
work. However, the paths over which the packets are sent will work. However, the paths over which the packets are sent will
generally not be the shortest paths. The forwarding paths will generally not be the shortest paths. The forwarding paths will
generally be more efficient as more routers are capable of SADR. For generally be more efficient when more routers are capable of SADR. For
example, if R4, R2, and R6 are upgraded to support SADR, then can 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 exchange source-scoped routes with SERa and SERb. They will then know
to send traffic with a source address matching prefix to send traffic with a source address matching prefix
2001:db8:0:b000::/52 directly to SERb, without sending it to SERa 2001:db8:0:b000::/52 directly to SERb, without sending it to SERa
first.</t> first.</t>
</section> </section>
<section anchor="sec_simple_not_dir_conn" numbered="true" toc="default">
<section anchor="sec_simple_not_dir_conn" <name>Simple ISP Connectivity Where SERs Are Not Directly Connected</nam
title="Simple ISP Connectivity Where SERs Are Not Directly Connec e>
ted"> <t>In <xref target="fig_simple_not_dir_conn" format="default"/>, we modi
<t>In <xref target="fig_simple_not_dir_conn"/>, we modify the topology fy the topology
slightly by inserting R7, so that SERa and SERb are no longer directly 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 connected. With this topology, it is not enough to just enable SADR
routing on SERa and SERb to support PA multi-homing. There are two routing on SERa and SERb to support PA multihoming. There are two
solutions to enable PA multihoming in this topology.</t> solutions to enable PA multihoming in this topology.</t>
<figure anchor="fig_simple_not_dir_conn">
<figure align="center" anchor="fig_simple_not_dir_conn" <name>Simple ISP Connectivity Where SERs Are Not Directly Connected</n
title="Simple ISP Connectivity Where SERs Are Not Directly Conne ame>
cted"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ 2001:db8:0:1234::101 H101
2001:db8:0:1234::101 H101 |
| |
| 2001:db8:0:a010::31 --------
2001:db8:0:a010::31 -------- 2001:db8:0:b010::31 ,-----. / \
2001:db8:0:b010::31 ,-----. / \ +--+ +--+ +----+ ,' `. : :
+--+ +--+ +----+ ,' `. : : +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : H31--+ +--+ +--+ | +----+ `. ,' : :
H31--+ +--+ +--+ | +----+ `. ,' : : | | `-----' : Internet :
| | `-----' : Internet : | +--+ : :
| +--+ : : | |R7| : :
| |R7| : : | +--+ : :
| +--+ : : | | ,-----. : :
| | ,-----. : : H32--+ +--+ | +----+ ,' `. : :
H32--+ +--+ | +----+ ,' `. : : +---|R2|----------+---|SERb|-+ ISP-B +--+-- :
+---|R2|----------+---|SERb|-+ ISP-B +--+-- : +--+ | +----+ `. ,' : :
+--+ | +----+ `. ,' : : | `-----' : :
| `-----' : : | : :
| : : +--+ +--+ +--+ \ /
+--+ +--+ +--+ \ / H41------|R3|--|R5|--|R6| --------
H41------|R3|--|R5|--|R6| -------- +--+ +--+ +--+ |
+--+ +--+ +--+ | |
| 2001:db8:0:a020::41 2001:db8:0:5678::501 H501
2001:db8:0:a020::41 2001:db8:0:5678::501 H501
2001:db8:0:b020::41 2001:db8:0:b020::41
]]></artwork> ]]></artwork>
</figure> </figure>
<t>One option is to effectively modify the topology by creating a <t>One option is to effectively modify the topology by creating a
logical tunnel between SERa and SERb, using GRE (<xref target="RF logical tunnel between SERa and SERb by using Generic Routing
C7676"/>) for example. Although Encapsulation (GRE) <xref target="RFC7676" format="default"/>, for examp
le. Although
SERa and SERb are not directly connected physically in this topology, SERa and SERb are not directly connected physically in this topology,
they can be directly connected logically by a tunnel.</t> they can be directly connected logically by a tunnel.</t>
<t>The other option is to enable SADR functionality on R7. In this <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 way, R7 will exchange source-scoped routes with SERa and SERb, making
the three routers act as a single SADR domain. This illustrates the the three routers act as a single SADR domain. This illustrates the
basic principle that the minimum requirement for the routed site basic principle that the minimum requirement for the routed site
network to support PA multi-homing is having all of the site exit network to support PA multihoming is having all of the site exit
routers be part of a connected SADR domain. Extending the connected routers be part of a connected SADR domain. Extending the connected
SADR domain beyond that point can produce more efficient forwarding SADR domain beyond that point can produce more efficient forwarding
paths.</t> paths.</t>
</section> </section>
<section anchor="sec_network_operator_expectations" numbered="true" toc="d
<section anchor="sec_network_operator_expectations" efault">
title="Enterprise Network Operator Expectations"> <name>Enterprise Network Operator Expectations</name>
<t>Before considering a more complex scenario, let's look in more <t>Before considering a more complex scenario, let's look in more
detail at the reasonably simple multihoming scenario in <xref detail at the reasonably simple multihoming scenario in <xref target="fi
target="fig_simple_not_dir_conn"/> to understand what can reasonably g_simple_not_dir_conn" format="default"/> to understand what can reasonably
be expected from this solution. As a general guiding principle, we be expected from this solution. As a general guiding principle, we
assume an enterprise network operator will expect a multihomed network assume an enterprise network operator will expect a multihomed network
to behave as close as to a single-homed network as possible. So a to behave as close to a single-homed network as possible. So a
solution that meets those expectations where possible is a good solution that meets those expectations where possible is a good
thing.</t> thing.</t>
<t>For traffic between internal hosts and for traffic from outside the
<t>For traffic between internal hosts and traffic from outside the
site to internal hosts, an enterprise network operator would expect site to internal hosts, an enterprise network operator would expect
there be no visible change in the path taken by this traffic, since 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 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 source address. It is also reasonable to expect that internal hosts
should be able to communicate with each other using either of their should be able to communicate with each other using either of their
source addresses without restriction. For example, H31 should be able source addresses without restriction. For example, H31 should be able
to communicate with H41 using a packet with S=2001:db8:0:a010::31, 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> 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 <t>These goals can be accomplished by having all of the routers in the
network continue to originate normal unscoped destination routes for network continue to originate normal unscoped destination routes for
their connected networks. If we can arrange so that these unscoped their connected networks. If we can arrange it so that these unscoped
destination routes get used for forwarding this traffic, then we will destination routes are used for forwarding this traffic, then we will
have accomplished the goal of keeping forwarding of traffic destined have accomplished multihoming's goal of not affecting the forwarding
for internal hosts, unaffected by the multihoming solution.</t> of traffic destined for internal hosts.</t>
<t>For traffic destined for external hosts, it is reasonable to expect <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 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 no to follow the path that the traffic would follow if there were no
connection to ISP-B. This can be accomplished by having SERa originate 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) . a source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0).
If all of the routers in the site support SADR, then the path of 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 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 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 traffic exiting via ISP-A may be different within the site. This is a
tradeoff that the enterprise network operator may decide to make.</t> trade-off that the enterprise network operator may decide to make.</t>
<t>It is important to understand the behavior of this multihoming soluti
<t>It is important to understand how this multihoming solution behaves on
when an uplink to one of the ISPs fails. To simplify this discussion, 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 we assume that all routers in the site support SADR. We start by
looking at how the network operates when the uplinks to both ISP-A and looking at the operation of the network when the uplinks to both ISP-A a
nd
ISP-B are functioning properly. SERa originates a source-scoped route 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 of the form (S=2001:db8:0:a000::/52, D=::/0), and SERb originates a
source-scoped route of the form (S=2001:db8:0:b000::/52, D=::/0). 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 These routes are distributed through the routers in the site, and they
establish within the routers two set of forwarding paths for traffic establish within the routers two sets of forwarding paths for traffic
leaving the site. One set of forwarding paths is for packets with leaving the site. One set of forwarding paths is for packets with
source address in 2001:db8:0:a000::/52. The other set of forwarding source addresses in 2001:db8:0:a000::/52. The other set of forwarding
paths is for packets with source address in 2001:db8:0:b000::/52. The paths is for packets with source addresses in 2001:db8:0:b000::/52. The
normal destination routes which are not scoped to these two source normal destination routes, which are not scoped to these two source
prefixes play no role in the forwarding. Whether a packet exits the prefixes, play no role in the forwarding. Whether a packet exits the
site via SERa or via SERb is completely determined by the source 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 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, 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 D=2001:db8:0:1234::101), the packet will only be sent out the link
from SERa to ISP-A.</t> from SERa to ISP-A.</t>
<t>Now consider what happens when the uplink from SERa to ISP-A fails. <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 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 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> 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 <t>This behavior is very different from the behavior that occurs with
site multihoming using PI addresses or with PA addresses using NAT. In site multihoming using PI addresses or with PA addresses using NAT. In
these other multi-homing solutions, hosts do not need to react to these other multihoming solutions, hosts do not need to react to
network failures several hops away in order to regain Internet access. 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 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 an ISP. When multihoming with PA addresses and NAT, existing sessions
generally need to be re-established after a failure since the external generally need to be reestablished after a failure since the external
host will receive packets from the internal host with a new source host will receive packets from the internal host with a new source
address. However, new sessions can be established without any action address. However, new sessions can be established without any action
on the part of the hosts. Multihoming with PA addresses and NAT has cre ated on the part of the hosts. Multihoming with PA addresses and NAT has cre ated
the expectation of a fairly quick and simple recovery from networ k failures. the expectation of a fairly quick and simple recovery from networ k failures.
Alternatives should to be evaluated in terms of the speed and com plexity Alternatives should to be evaluated in terms of the speed and com plexity
of the recovery mechanism.</t> of the recovery mechanism.</t>
<t>Another significant difference between this multihoming solution
<t>Another example where the behavior of this multihoming solution and multihoming with either PI addresses or with
differs significantly from that of multihoming with PI address or with PA addresses using NAT is the ability of the enterprise network
PA addresses using NAT is in the ability of the enterprise network
operator to route traffic over different ISPs based on destination operator to route traffic over different ISPs based on destination
address. We still consider the fairly simple network of <xref address. We still consider the fairly simple network of
target="fig_simple_not_dir_conn"/> and assume that uplinks to both <xref target="fig_simple_not_dir_conn" format="default"/> and assume tha
t uplinks to both
ISPs are functioning. Assume that the site is multihomed using PA ISPs are functioning. Assume that the site is multihomed using PA
addresses and NAT, and that SERa and SERb each originate a normal addresses and NAT, and that SERa and SERb each originate a normal
destination route for D=::/0, with the route origination dependent on destination route for D=::/0, with the route origination dependent on
the state of the uplink to the respective ISP.</t> the state of the uplink to the respective ISP.</t>
<t>Now suppose it is observed that an important application running <t>Now suppose it is observed that an important application running
between internal hosts and external host H101 experience much better between internal hosts and external host H101 experiences much better
performance when the traffic passes through ISP-A (perhaps because performance when the traffic passes through ISP-A (perhaps because
ISP-A provides lower latency to H101.) When multihoming this site with ISP-A provides lower latency to H101). When multihoming this site with
PI addresses or with PA addresses and NAT, the enterprise network PI addresses or with PA addresses and NAT, the enterprise network
operator can configure SERa to originate into the site network a operator can configure SERa to originate into the site network a
normal destination route for D=2001:db8:0:1234::/64 (the destination 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 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 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 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 hosts will use ISP-A to reach H101 based on the longest destination
prefix match in the route lookup.</t> prefix match in the route lookup.</t>
<t>Implementing the same routing policy is more difficult with the PA <t>Implementing the same routing policy is more difficult with the PA
multihoming solution described in this document since it doesn't use multihoming solution described in this document since it doesn't use
NAT. By design, the only way to control where a packet exits this 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 is by setting the source address of the packet. Since the
network cannot modify the source address without NAT, the host must network cannot modify the source address without NAT, the host must
set it. To implement this routing policy, each host needs to use the 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 source address from the prefix assigned by ISP-A to send traffic
destined for H101. Mechanisms have been proposed to allow hosts to destined for H101. Mechanisms have been proposed to allow hosts to
choose the source address for packets in a fine grained manner. We choose the source address for packets in a fine-grained manner. We
will discuss these proposals in <xref target="sec_host_mechanisms"/>. will discuss these proposals in <xref target="sec_host_mechanisms" forma
However, interacting with host operating systems in some manner to t="default"/>.
ensure a particular source address is chosen for a particular However, an enterprise network administrator would not expect to
destination prefix is not what an enterprise network administrator interact with host operating systems to ensure that a particular
would expect to have to do to implement this routing policy.</t> source address is chosen for a particular
destination prefix in order to implement this routing policy.</t>
</section> </section>
<section anchor="sec_more_complex_isp_connectivity" numbered="true" toc="d
<section anchor="sec_more_complex_isp_connectivity" efault">
title="More complex ISP connectivity"> <name>More Complex ISP Connectivity</name>
<t>The previous sections considered two variations of a simple <t>The previous sections considered two variations of a simple
multihoming scenario where the site is connected to two ISPs offering multihoming scenario in which the site is connected to two ISPs offering
only Internet connectivity. It is likely that many actual enterprise only Internet connectivity. It is likely that many actual enterprise
multihoming scenarios will be similar to this simple example. However, multihoming scenarios will be similar to this simple example. However,
there are more complex multihoming scenarios that we would like this there are more complex multihoming scenarios that we would like this
solution to address as well.</t> solution to address as well.</t>
<t>It is fairly common for an ISP to offer a service in addition to <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 Internet access over the same uplink. Two variations of this are
reflected in <xref target="fig_isp_service"/>. In addition to Internet reflected in <xref target="fig_isp_service" format="default"/>. In addit
access, ISP-A offers a service which requires the site to access host ion to Internet
access, ISP-A offers a service that requires the site to access host
H51 at 2001:db8:0:5555::51. The site has a single physical and logical 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 with ISP-A, and ISP-A only allows access to H51 over that
connection. So when H32 needs to access the service at H51 it needs to connection. So when H32 needs to access the service at H51, it needs to
send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) and send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51), and
those packets need to be forward out the link from SERa to ISP-A.</t> those packets need to be forwarded out the link from SERa to ISP-A.</t>
<figure anchor="fig_isp_service">
<figure align="center" anchor="fig_isp_service" <name>Internet Access and Services Offered by ISP-A and ISP-B</name>
title="Internet access and services offered by ISP-A and ISP-B <artwork align="center" name="" type="" alt=""><![CDATA[
"> 2001:db8:0:1234::101 H101
<artwork align="center"><![CDATA[ |
2001:db8:0:1234::101 H101 |
| 2001:db8:0:a010::31 --------
| 2001:db8:0:b010::31 ,-----. / \
2001:db8:0:a010::31 -------- +--+ +--+ +----+ ,' `. : :
2001:db8:0:b010::31 ,-----. / \ +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- :
+--+ +--+ +----+ ,' `. : : H31--+ +--+ +--+ | +----+ `. ,' : :
+---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : | | `-----' : Internet :
H31--+ +--+ +--+ | +----+ `. ,' : : | | | : :
| | `-----' : Internet : | | H51 : :
| | | : : | | 2001:db8:0:5555::51 : :
| | H51 : : | +--+ : :
| | 2001:db8:0:5555::51 : : | |R7| : :
| +--+ : : | +--+ : :
| |R7| : : | | : :
| +--+ : : | | ,-----. : :
| | : : H32--+ +--+ | +-----+ ,' `. : :
| | ,-----. : : +---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- :
H32--+ +--+ | +-----+ ,' `. : : +--+ | +-----+ `. ,' : :
+---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- : +--+ `--|--' : :
+--+ | +-----+ `. ,' : : 2001:db8:0:a010::32 |R8| | \ /
+--+ `--|--' : : +--+ ,--|--. --------
2001:db8:0:a010::32 |R8| | \ / | +-----+ ,' `. |
+--+ ,--|--. -------- +-------|SERb2|-+ ISP-B | |
| +-----+ ,' `. | | +-----+ `. ,' H501
+-------|SERb2|-+ ISP-B | | | `-----' 2001:db8:0:5678
| +-----+ `. ,' H501 | | ::501
| `-----' 2001:db8:0:5678 +--+ +--+ H61
| | ::501 H41------|R3|--|R5| 2001:db8:0:6666::61
+--+ +--+ H61 +--+ +--+
H41------|R3|--|R5| 2001:db8:0:6666::61
+--+ +--+
2001:db8:0:a020::41 2001:db8:0:a020::41
2001:db8:0:b020::41 2001:db8:0:b020::41
]]></artwork> ]]></artwork>
</figure> </figure>
<t>ISP-B illustrates a variation on this scenario. In addition to <t>ISP-B illustrates a variation on this scenario. In addition to
Internet access, ISP-B also offers a service which requires the site Internet access, ISP-B also offers a service that requires the site
to access host H61. The site has two connections to two different to access host H61. The site has two connections to two different
parts of ISP-B (shown as SERb1 and SERb2 in <xref parts of ISP-B (shown as SERb1 and SERb2 in
target="fig_isp_service"/>). ISP-B expects Internet traffic to use the <xref target="fig_isp_service" format="default"/>). ISP-B expects Intern
et traffic to use the
uplink from SERb1, while it expects traffic destined for uplink from SERb1, while it expects traffic destined for
the service at H61 to use the uplink from SERb2. For either uplink, 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 ISP-B expects the ingress traffic to have a source address matching
the prefix it assigned to the site, 2001:db8:0:b000::/52.</t> 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 <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 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 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, 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 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 distributing routes so that this packet exits the site on the uplink
at SERb2.</t> at SERb2.</t>
<t>We could just rely on normal destination routes, without using <t>We could just rely on normal destination routes, without using
source-prefix scoped routes. If we have SERb2 originate a normal source-prefix-scoped routes. If we have SERb2 originate a normal
unscoped destination route for D=2001:db8:0:6666::/64, the packets 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 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 have to worry about SERa needing to originate the same route, because
ISP-B should choose a globally unique prefix for the service at ISP-B should choose a globally unique prefix for the service at
H61.</t> H61.</t>
<t>The alternative is to have SERb2 originate a source-prefix-scoped <t>The alternative is to have SERb2 originate a source-prefix-scoped
destination route of the form (S=2001:db8:0:b000::/52, 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 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 the source-prefix-scoped destination route would result in traffic
with source addresses corresponding only to ISP-B being sent to SERb2. with source addresses corresponding only to ISP-B being sent to SERb2.
Instead, the use of the unscoped destination route would result in Instead, the use of the unscoped destination route would result in
traffic with source addresses corresponding to ISP-A and ISP-B being traffic with source addresses corresponding to ISP-A and ISP-B being
sent to SERb2, as long as the destination address matches the sent to SERb2, as long as the destination address matches the
destination prefix. It seems like either forwarding behavior would be destination prefix. It seems like either forwarding behavior would be
acceptable.</t> acceptable.</t>
skipping to change at line 672 skipping to change at line 605
<t>The alternative is to have SERb2 originate a source-prefix-scoped <t>The alternative is to have SERb2 originate a source-prefix-scoped
destination route of the form (S=2001:db8:0:b000::/52, 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 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 the source-prefix-scoped destination route would result in traffic
with source addresses corresponding only to ISP-B being sent to SERb2. with source addresses corresponding only to ISP-B being sent to SERb2.
Instead, the use of the unscoped destination route would result in Instead, the use of the unscoped destination route would result in
traffic with source addresses corresponding to ISP-A and ISP-B being traffic with source addresses corresponding to ISP-A and ISP-B being
sent to SERb2, as long as the destination address matches the sent to SERb2, as long as the destination address matches the
destination prefix. It seems like either forwarding behavior would be destination prefix. It seems like either forwarding behavior would be
acceptable.</t> acceptable.</t>
<t>However, from the point of view of the enterprise network <t>However, from the point of view of the enterprise network
administrator trying to configure, maintain, and trouble-shoot this administrator trying to configure, maintain, and troubleshoot this
multihoming solution, it seems much clearer to have SERb2 originate multihoming solution, it seems much clearer to have SERb2 originate
the source-prefix-scoped destination route correspond to the service the source-prefix-scoped destination route corresponding to the service
offered by ISP-B. In this way, all of the traffic leaving the site is 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 determined by the source-prefix-scoped routes, and all of the traffic
within the site or arriving from external hosts is determined by the within the site or arriving from external hosts is determined by the
unscoped destination routes. Therefore, for this multihoming solution unscoped destination routes. Therefore, for this multihoming solution
we choose to originate source-prefix-scoped routes for all traffic we choose to originate source-prefix-scoped routes for all traffic
leaving the site.</t> leaving the site.</t>
</section> </section>
<section anchor="sec_isps_and_pa_prefixes" numbered="true" toc="default">
<section anchor="sec_isps_and_pa_prefixes" <name>ISPs and Provider-Assigned Prefixes</name>
title="ISPs and Provider-Assigned Prefixes">
<t>While we expect that most site multihoming involves connecting to <t>While we expect that most site multihoming involves connecting to
only two ISPs, this solution allows for connections to an arbitrary only two ISPs, this solution allows for connections to an arbitrary
number of ISPs to be supported. However, when evaluating scalable number of ISPs. However, when evaluating scalable
implementations of the solution, it would be reasonable to assume that implementations of the solution, it would be reasonable to assume that
the maximum number of ISPs that a site would connect to is five (topologi the maximum number of ISPs that a site would connect to is five (topologi
es with two redundant routers es with two redundant routers,
each having two uplinks to different ISPs plus a tunnel to a headoffice a each having two uplinks to different ISPs, plus a tunnel to a head office
cting as fifth one are not unheard of).</t> acting as fifth one are not unheard of).</t>
<t>It is also useful to note that the prefixes assigned to the site by <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 different ISPs will not overlap. This must be the case, since the
provider-assigned addresses have to be globally unique.</t> provider-assigned addresses have to be globally unique.</t>
</section> </section>
<section anchor="sec_simpler_topologies" numbered="true" toc="default">
<section anchor="sec_simpler_topologies" title="Simplified Topologies"> <name>Simplified Topologies</name>
<t>The topologies of many enterprise sites using this multihoming <t>The topologies of many enterprise sites using this multihoming
solution may in practice be simpler than the examples that we have solution may in practice be simpler than the examples that we have
used. The topology in <xref target="fig_simple_scenario"/> could be used. The topology in <xref target="fig_simple_scenario" format="default
further simplified by having all hosts directly connected to the LAN "/> could be
connecting the two site exit routers, SERa and SERb. The topology further simplified by directly connecting all hosts to the LAN
could also be simplified by having the uplinks to ISP-A and ISP-B both that connects the two site exit routers, SERa and SERb. The topology
connected to the same site exit router. However, it is the aim of this could also be simplified by connecting both uplinks to ISP-A and ISP-B
document to provide a solution that applies to a broad a range of to the same site exit router. However, it is the aim of this
document to provide a solution that applies to a broad range of
enterprise site network topologies, so this document focuses on providin g enterprise site network topologies, so this document focuses on providin g
a solution to the more general case. The simplified cases will also be a solution to the more general case. The simplified cases will also be
supported by this solution, and there may even be optimizations that supported by this solution, and there may even be optimizations that
can be made for simplified cases. This solution however needs to can be made for simplified cases. This solution, however, needs to
support more complex topologies.</t> support more complex topologies.</t>
<t>We are starting with the basic assumption that enterprise site <t>We are starting with the basic assumption that enterprise site
networks can be quite complex from a routing perspective. However, networks can be quite complex from a routing perspective. However,
even a complex site network can be multihomed to different ISPs with 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 PA addresses using IPv4 and NAT. It is not reasonable to expect an
enterprise network operator to change the routing topology of the site enterprise network operator to change the routing topology of the site
in order to deploy IPv6.</t> in order to deploy IPv6.</t>
</section> </section>
</section> </section>
<section anchor="sec_method" numbered="true" toc="default">
<section anchor="sec_method" <name>Generating Source-Prefix-Scoped Forwarding Tables</name>
title="Generating Source-Prefix-Scoped Forwarding Tables"> <t>So far, we have described in general terms how the SADR-capable routers
<t>So far we have described in general terms how the routers in this in this
solution that are capable of Source Address Dependent Routing will solution forward traffic by using both normal unscoped destination routes
forward traffic using both normal unscoped destination routes and and
source-prefix-scoped destination routes. Here we give a precise method source-prefix-scoped destination routes. Here we give a precise method
for generating a source-prefix-scoped forwarding table on a router that for generating a source-prefix-scoped forwarding table on a router that
supports SADR.</t> supports SADR.</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Compute the next-hops for the source-prefix-scoped destination
<t>Compute the next-hops for the source-prefix-scoped destination
prefixes using only routers in the connected SADR domain. These are prefixes using only routers in the connected SADR domain. These are
the initial source-prefix-scoped forwarding table entries.</t> the initial source-prefix-scoped forwarding table entries.</li>
<li>Compute the next-hops for the unscoped destination prefixes using
<t>Compute the next-hops for the unscoped destination prefixes using all routers in the IGP. This is the unscoped forwarding table.</li>
all routers in the IGP. This is the unscoped forwarding table.</t> <li>For a given source-prefix-scoped forwarding table T (scoped to
source prefix P), consider a source-prefix-scoped forwarding
<t> table T', whose source prefix P' contains P. We call T the more
For a given source-prefix-scoped forwarding table T (scoped to source prefix P), specific source-prefix-scoped forwarding table, and T' the less
consider a source-prefix-scoped forwarding table T', whose source prefix P' cont specific source-prefix-scoped forwarding table. We select
ains P. entries in forwarding table T' to augment forwarding table T
We call T the more specific source-prefix-scoped forwarding table, and T' the le based on the following rules. If a destination prefix of an
ss specific entry in forwarding table T' exactly matches the destination
source-prefix-scoped forwarding table. We select entries in the less specific prefix of an existing entry in forwarding table T (including
source-prefix-scoped forwarding table to augment the more specific source-prefix destination prefix length), then do not add the entry to
-scoped forwarding table T. If the destination prefix does NOT match an
forwarding table based on the following rules. If a destination prefix of an en existing entry, then add the entry to forwarding table T.
try in the less specific As the unscoped forwarding table is considered to be scoped
source-prefix-scoped forwarding table exactly matches the destination prefix of to ::/0, this process will propagate routes from the unscoped
an existing entry in the more forwarding table to forwarding table T. If there exist multiple
specific source-prefix-scoped forwarding table (including source-prefix-scoped forwarding tables whose source prefixes
destination prefix length), then do not add the entry to the more specific contain P, these source-prefix-scoped forwarding tables should be
source-prefix-scoped forwarding table. If the destination prefix processed in order from most specific to least specific.</li>
does NOT match an existing entry, then add the entry to the more
specific source-prefix-scoped forwarding table. 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.
If there exist multiple source-prefix-scoped forwarding tables whose source pref
ixes contain P,
these source-prefix-scoped forwarding tables should be processed in order from
most specific to least specific.
</t>
</list></t>
</ol>
<t>The forwarding tables produced by this process are used in the followin g <t>The forwarding tables produced by this process are used in the followin g
way to forward packets. <list style="numbers"> way to forward packets. </t>
<t>Select the most specific (longest prefix match) source-p <ol spacing="normal" type="1">
refix-scoped forwarding table <li>Select the most specific (longest prefix match) source-prefix-scoped
forwarding table
that matches the source address of the packet (agai n, the unscoped that matches the source address of the packet (agai n, the unscoped
forwarding table is considered to be scoped to ::/0 forwarding table is considered to be scoped to ::/0
). </t> ). </li>
<t>Look up the destination address of the packet in <li>Look up the destination address of the packet in
the selected forwarding table to the selected forwarding table to
determine the next-hop for the packet. determine the next-hop for the packet. </li>
</t> </ol>
</list></t>
<t>The following example illustrates how this process is used to create <t>The following example illustrates how this process is used to create
a forwarding table for each provider-assigned source prefix. We consider a forwarding table for each provider-assigned source prefix. We consider
the multihomed site network in <xref target="fig_isp_service"/>. the multihomed site network in <xref target="fig_isp_service" format="defa ult"/>.
Initially we assume that all of the routers in the site network support Initially we assume that all of the routers in the site network support
SADR. <xref target="fig_routes_originated"/> shows the routes that are SADR. <xref target="fig_routes_originated" format="default"/> shows the ro utes that are
originated by the routers in the site network.</t> originated by the routers in the site network.</t>
<figure anchor="fig_routes_originated">
<figure align="center" anchor="fig_routes_originated" <name>Routes Originated by Routers in the Site Network</name>
title="Routes Originated by Routers in the Site Network"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
Routes originated by SERa: Routes originated by SERa:
(S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64) (S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64)
(S=2001:db8:0:a000::/52, D=::/0) (S=2001:db8:0:a000::/52, D=::/0)
(D=2001:db8:0:5555::/64) (D=2001:db8:0:5555::/64)
(D=::/0) (D=::/0)
Routes originated by SERb1: Routes originated by SERb1:
(S=2001:db8:0:b000::/52, D=::/0) (S=2001:db8:0:b000::/52, D=::/0)
(D=::/0) (D=::/0)
skipping to change at line 811 skipping to change at line 730
Routes originated by R2: Routes originated by R2:
(D=2001:db8:0:a010::/64) (D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64) (D=2001:db8:0:b010::/64)
Routes originated by R3: Routes originated by R3:
(D=2001:db8:0:a020::/64) (D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64) (D=2001:db8:0:b020::/64)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Each SER originates destination routes that are scoped to the source
<t>Each SER originates destination routes which are scoped to the source prefix assigned by the ISP to which the SER connects. Note that the SERs
prefix assigned by the ISP that the SER connects to. Note that the SERs
also originate the corresponding unscoped destination route. This is not also originate the corresponding unscoped destination route. This is not
needed when all of the routers in the site support SADR. However, it is 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 required when some routers do not support SADR. This will be discussed
in more detail later.</t> in more detail later.</t>
<t>We focus on how R8 constructs its source-prefix-scoped forwarding <t>We focus on how R8 constructs its source-prefix-scoped forwarding
tables from these route advertisements. R8 computes the next hops for tables from these route advertisements. R8 computes the next hops for
destination routes which are scoped to the source prefix destination routes that are scoped to the source prefix
2001:db8:0:a000::/52. The results are shown in the first table in <xref 2001:db8:0:a000::/52. The results are shown in the first table in
target="fig_forwarding_entries"/>. (In this example, the next hops are <xref target="fig_forwarding_entries" format="default"/>. (In this example
, the next hops are
computed assuming that all links have the same metric.) Then, R8 computed assuming that all links have the same metric.) Then, R8
computes the next hops for destination routes which are scoped to the computes the next hops for destination routes that are scoped to the
source prefix 2001:db8:0:b000::/52. The results are shown in the second source prefix 2001:db8:0:b000::/52. The results are shown in the second
table in <xref target="fig_forwarding_entries"/> . Finally, R8 computes table in <xref target="fig_forwarding_entries" format="default"/>. Finally , R8 computes
the next hops for the unscoped destination prefixes. The results are the next hops for the unscoped destination prefixes. The results are
shown in the third table in <xref target="fig_forwarding_entries"/>.</t> shown in the third table in <xref target="fig_forwarding_entries" format="
default"/>.</t>
<figure align="center" anchor="fig_forwarding_entries" <figure anchor="fig_forwarding_entries">
title="Forwarding Entries Computed at R8"> <name>Forwarding Entries Computed at R8</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
forwarding entries scoped to forwarding entries scoped to
source prefix = 2001:db8:0:a000::/52 source prefix = 2001:db8:0:a000::/52
============================================ ============================================
D=2001:db8:0:5555/64 NH=R7 D=2001:db8:0:5555/64 NH=R7
D=::/0 NH=R7 D=::/0 NH=R7
forwarding entries scoped to forwarding entries scoped to
source prefix = 2001:db8:0:b000::/52 source prefix = 2001:db8:0:b000::/52
============================================ ============================================
D=2001:db8:0:6666/64 NH=SERb2 D=2001:db8:0:6666/64 NH=SERb2
skipping to change at line 857 skipping to change at line 773
============================================ ============================================
D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2 D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1 D=::/0 NH=SERb1
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The final step is for R8 to augment the more specific source-prefix The final step is for R8 to augment the more specific source-prefix
- -scoped
scoped forwarding tables with entries from less specific source-prefix-scoped forwarding tables with entries from less specific source-prefix-scoped
forwarding tables. The unscoped forwarding table is considered as being 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 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 are more specific prefixes of ::/0. Therefore, entries in the unscoped
forwarding table will be evaluated to be added to these two forwarding table will be evaluated to be added to these two
more specific source-prefix-scoped forwarding tables. If a forwarding more specific source-prefix-scoped forwarding tables. If a forwarding
entry from the less specific source-prefix-scoped forwarding table entry from the less specific source-prefix-scoped forwarding table
has the exact same destination prefix (including destination prefix length) has the exact same destination prefix (including destination prefix length)
as the forwarding entry from the more specific source-prefix-scoped forwarding t able, as the forwarding entry from the more specific source-prefix-scoped forwarding t able,
then the existing forwarding entry in the more specific source-prefix-scoped for warding table wins. then the existing forwarding entry in the more specific source-prefix-scoped for warding table wins.
</t> </t>
<t>As an example of how the source-prefix-scoped forwarding entries are
<t>As an example of how the source scoped forwarding entries are
augmented, we consider how the two augmented, we consider how the two
entries in the first table in <xref target="fig_forwarding_entries"/> entries in the first table in <xref target="fig_forwarding_entries" format ="default"/>
(the table for source prefix = 2001:db8:0:a000::/52) are augmented with (the table for source prefix = 2001:db8:0:a000::/52) are augmented with
entries from the third table in <xref target="fig_forwarding_entries"/> entries from the third table in <xref target="fig_forwarding_entries" form at="default"/>
(the table of unscoped or scoped to ::/0 forwarding entries). The first fo ur unscoped (the table of unscoped or scoped to ::/0 forwarding entries). The first fo ur unscoped
forwarding entries (D=2001:db8:0:a010::/64, D=2001:db8:0:b010::/64, 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 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 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 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 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 result of adding these entries is reflected in the first four entries the
first table in <xref target="fig_forwarding_tables"/>.</t> first table in <xref target="fig_forwarding_tables" format="default"/>.</t >
<t>The next less specific scoped (scope is ::/0) forwarding table entry is for <t>The next less specific 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 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. 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 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 unscoped forwarding table. This is reflected in the fifth entry in the
first table in <xref target="fig_forwarding_tables"/>. (Note that since first table in <xref target="fig_forwarding_tables" format="default"/>. (N ote that since
both scoped and unscoped entries have R7 as the next hop, the result of both scoped and unscoped entries have R7 as the next hop, the result of
applying this rule is not visible.)</t> applying this rule is not visible.)</t>
<t>The next less specific prefix scoped (scope is ::/0) forwarding table e ntry is for <t>The next less specific 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 D=2001:db8:0:6666::/64. This entry is not an exact match for any
existing entries in the forwarding table for source prefix existing entries in the forwarding table for source prefix
2001:db8:0:a000::/52. Therefore, we add this entry. This is reflected in 2001:db8:0:a000::/52. Therefore, we add this entry. This is reflected in
the sixth entry in the first table in <xref the sixth entry in the first table in <xref target="fig_forwarding_tables"
target="fig_forwarding_tables"/>.</t> format="default"/>.</t>
<t>The next less specific source-prefix-scoped (scope is ::/0) forwarding
<t>The next less specific prefix scoped (scope is ::/0) forwarding table e table entry
ntry is for D=::/0. This entry is is for D=::/0. This entry is
an exact match for the existing entry in the forwarding table for more spe an exact match for the existing entry in the forwarding table for the more
cific source specific source
prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing 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 source-prefix-scoped entry, as can be seen in the last entry in the
first table in <xref target="fig_forwarding_tables"/>.</t> first table in <xref target="fig_forwarding_tables" format="default"/>.</t
>
<figure align="center" anchor="fig_forwarding_tables" <figure anchor="fig_forwarding_tables">
title="Complete Forwarding Tables Computed at R8"> <name>Complete Forwarding Tables Computed at R8</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
if source address matches 2001:db8:0:a000::/52 if source address matches 2001:db8:0:a000::/52
then use this forwarding table then use this forwarding table
============================================ ============================================
D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2 D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R7 D=::/0 NH=R7
skipping to change at line 945 skipping to change at line 856
============================================ ============================================
D=2001:db8:0:a010::/64 NH=R2 D=2001:db8:0:a010::/64 NH=R2
D=2001:db8:0:b010::/64 NH=R2 D=2001:db8:0:b010::/64 NH=R2
D=2001:db8:0:a020::/64 NH=R5 D=2001:db8:0:a020::/64 NH=R5
D=2001:db8:0:b020::/64 NH=R5 D=2001:db8:0:b020::/64 NH=R5
D=2001:db8:0:5555::/64 NH=R7 D=2001:db8:0:5555::/64 NH=R7
D=2001:db8:0:6666::/64 NH=SERb2 D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=SERb1 D=::/0 NH=SERb1
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The forwarding tables produced by this process at R8 have the desired <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 properties. A packet with a source address in 2001:db8:0:a000::/52 will
be forwarded based on the first table in <xref be forwarded based on the first table in <xref target="fig_forwarding_tabl
target="fig_forwarding_tables"/>. If the packet is destined for the es" 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 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 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 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 expected. Note that if this packet has a destination address
corresponding to the service offered by ISP-B (D=2001:db8:0:5555::/64), 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 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, 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 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 offered by ISP-B, the host needs to originate the packet with a source
address assigned by ISP-B.</t> address assigned by ISP-B.</t>
skipping to change at line 960 skipping to change at line 869
Internet at large or the service at D=2001:db8:0:5555/64, it will be 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 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 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 expected. Note that if this packet has a destination address
corresponding to the service offered by ISP-B (D=2001:db8:0:5555::/64), 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 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, 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 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 offered by ISP-B, the host needs to originate the packet with a source
address assigned by ISP-B.</t> address assigned by ISP-B.</t>
<t>In this example, a packet with a source address that doesn't match <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 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 an external host. Such a packet will use the unscoped forwarding table
(the last table in <xref target="fig_forwarding_tables"/>). These (the last table in <xref target="fig_forwarding_tables" format="default"/> ). These
packets will flow exactly as they would in absence of multihoming.</t> packets will flow exactly as they would in absence of multihoming.</t>
<t>We can also modify this example to illustrate how it supports <t>We can also modify this example to illustrate how it supports
deployments where not all routers in the site support SADR. Continuing deployments in which not all routers in the site support SADR. Continuing
with the topology shown in <xref target="fig_isp_service"/>, suppose with the topology shown in <xref target="fig_isp_service" format="default"
/>, suppose
that R3 and R5 do not support SADR. Instead they are only capable of that R3 and R5 do not support SADR. Instead they are only capable of
understanding unscoped route advertisements. The SADR routers in the understanding unscoped route advertisements. The SADR routers in the
network will still originate the routes shown in <xref network will still originate the routes shown in <xref target="fig_routes_
target="fig_routes_originated"/>. However, R3 and R5 will only originated" format="default"/>. However, R3 and R5 will only
understand the unscoped routes as shown in <xref understand the unscoped routes as shown in <xref target="fig_routes_unders
target="fig_routes_understood_by_non_SADR"/>.</t> tood_by_non_SADR" format="default"/>.</t>
<figure anchor="fig_routes_understood_by_non_SADR">
<figure align="center" anchor="fig_routes_understood_by_non_SADR" <name>Route Advertisements Understood by Routers That Do Not Support SAD
title="Routes Advertisements Understood by Routers that do no Supp R</name>
ort SADR"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
Routes originated by SERa: Routes originated by SERa:
(D=2001:db8:0:5555::/64) (D=2001:db8:0:5555::/64)
(D=::/0) (D=::/0)
Routes originated by SERb1: Routes originated by SERb1:
(D=::/0) (D=::/0)
Routes originated by SERb2: Routes originated by SERb2:
(D=2001:db8:0:6666::/64) (D=2001:db8:0:6666::/64)
skipping to change at line 1003 skipping to change at line 907
Routes originated by R2: Routes originated by R2:
(D=2001:db8:0:a010::/64) (D=2001:db8:0:a010::/64)
(D=2001:db8:0:b010::/64) (D=2001:db8:0:b010::/64)
Routes originated by R3: Routes originated by R3:
(D=2001:db8:0:a020::/64) (D=2001:db8:0:a020::/64)
(D=2001:db8:0:b020::/64) (D=2001:db8:0:b020::/64)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>With these unscoped route advertisements, R5 will produce the <t>With these unscoped route advertisements, R5 will produce the
forwarding table shown in <xref target="fig_R5_forwarding_table"/>.</t> forwarding table shown in <xref target="fig_R5_forwarding_table" format="d
efault"/>.</t>
<figure align="center" anchor="fig_R5_forwarding_table" <figure anchor="fig_R5_forwarding_table">
title="Forwarding Table For R5, Which Doesn't Understand Source-Pr <name>Forwarding Table for R5, Which Doesn't Understand Source-Prefix-Sc
efix-Scoped Routes"> oped Routes</name>
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
forwarding table forwarding table
============================================ ============================================
D=2001:db8:0:a010::/64 NH=R8 D=2001:db8:0:a010::/64 NH=R8
D=2001:db8:0:b010::/64 NH=R8 D=2001:db8:0:b010::/64 NH=R8
D=2001:db8:0:a020::/64 NH=R3 D=2001:db8:0:a020::/64 NH=R3
D=2001:db8:0:b020::/64 NH=R3 D=2001:db8:0:b020::/64 NH=R3
D=2001:db8:0:5555::/64 NH=R8 D=2001:db8:0:5555::/64 NH=R8
D=2001:db8:0:6666::/64 NH=SERb2 D=2001:db8:0:6666::/64 NH=SERb2
D=::/0 NH=R8 D=::/0 NH=R8
]]></artwork> ]]></artwork>
</figure> </figure>
<t>As all SERs belong to the SADR domain, any traffic that needs to exit t
<t>As all SERs belong to the SADR domain any traffic that needs to exit th he site will eventually hit a SADR-capable router. To prevent routing loops inv
e site will eventually hit a SADR-capable router. To prevent routing loops invo olving SADR-capable and non-SADR-capable routers, traffic that enters the SADR-c
lving SADR-capable and non-SADR-capable routers, traffic that enters the SADR-ca apable domain does not leave the domain until it exits the site. Therefore all S
pable domain does not leave the domain until it exits the site. Therefore all SA ADR-capable routers within the domain <bcp14>MUST</bcp14> be logically connected
DR-capable routers within the domain MUST be logically connected.</t> .</t>
<t>Note that the mechanism described here for converting <t>Note that the mechanism described here for converting
source-prefix-scoped destination prefix routing advertisements into source-prefix-scoped destination prefix routing advertisements into
forwarding state is somewhat different from that proposed in <xref target= forwarding state is somewhat different from that proposed in <xref
"I-D.ietf-rtgwg-dst-src-routing"/>. The method described in the current target="I-D.ietf-rtgwg-dst-src-routing" format="default"/>. The method
document is functionally equivalent, but it is based on application of exi described in this document is functionally equivalent, but it is based on
sting mechanisms for the described scenarios.</t> application of existing mechanisms for the described scenarios.</t>
</section> </section>
<section anchor="sec_host_mechanisms" numbered="true" toc="default">
<section anchor="sec_host_mechanisms" <name>Mechanisms for Hosts To Choose Good Default Source Addresses in a Mu
title="Mechanisms For Hosts To Choose Good Default Source Addresses ltihomed Site</name>
In A Multihomed Site">
<t>Until this point, we have made the assumption that hosts are able to <t>Until this point, we have made the assumption that hosts are able to
choose the correct source address using some unspecified mechanism. This choose the correct source address using some unspecified mechanism. This
has allowed us to just focus on what the routers in a multihomed site has allowed us to focus on what the routers in a multihomed site
network need to do in order to forward packets to the correct ISP based 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 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, 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 the routers may play in providing information that helps hosts to choose
source addresses.</t> source addresses.</t>
<t> <t>
It should be noted that this section discussed how hosts could select the It should be noted that this section discusses how hosts could select
default source address for new connections. Any connection which already exists the default source address for new connections. Any connection that
on a host is bound to the specific source address which can not be changed. <xr already exists on a host is bound to a specific source address that
ef target="sec_conn_pre"/> discusses the connections preservation issue in more cannot be changed. <xref target="sec_conn_pre" format="default"/>
details. discusses the connections preservation issue in more detail.
</t> </t>
<t>Any host that needs to be able to send traffic using the uplinks to a g
<t>Any host that needs to be able to send traffic using the uplinks to a iven ISP
given ISP is expected to be configured with an address from the prefix 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 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 traffic by selecting one of the addresses configured on the host as the
source address for outgoing traffic. It is the responsibility of 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 site network to ensure that a packet with the source address from an ISP
is now sent on an uplink to that ISP.</t> 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
<t>If all of the ISP uplinks are working, the choice of source address address
by the host may be driven by the desire to load share across ISP 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 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 variou properties of a particular uplink or ISP (if some information about variou
s path properties has been made availabe to the host somehow - see <xref target= s
"I-D.ietf-intarea-provisioning-domains"/> as an example). If any of the ISP upli path properties has been made available to the host somehow. See
nks is <xref 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 not working, then the choice of source address by the host can cause
packets to get dropped.</t> packets to get dropped.</t>
<t>How a host selects a suitable source address
<t>How a host should make good decisions about source address selection
in a multihomed site is not a solved problem. We do not attempt to solve 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 this problem in this document. Instead we discuss the current state of
affairs with respect to standardized solutions and implementation of affairs with respect to standardized solutions and the implementation of
those solutions. We also look at proposed solutions for this those solutions. We also look at proposed solutions for this
problem.</t> problem.</t>
<t>An external host initiating communication with a host internal to a <t>An external host initiating communication with a host internal to a
PA multihomed site will need to know multiple addresses for that host in PA-multihomed site will need to know multiple addresses for that host in
order to communicate with it using different ISPs to the multihomed order to communicate with it using different ISPs to the multihomed
site (knowing just one address would undermine all benefits of redundant c onnectivity provided by multihoming). These addresses are typically learned thro ugh DNS. (For site (knowing just one address would undermine all benefits of redundant c onnectivity provided by multihoming). These addresses are typically learned thro ugh DNS. (For
simplicity, we assume that the external host is single-homed.) The simplicity, we assume that the external host is single-homed.) The
external host chooses the ISP that will be used at the remote multihomed 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 site by setting the destination address on the packets it transmits. For
a session originated from an external host to an internal host, the a session originated from an external host to an internal host, the
choice of source address used by the internal host is simple. 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 internal host has no choice but to use the destination address in the
received packet as the source address of the transmitted packet.</t> received packet as the source address of the transmitted packet.</t>
<t>For a session originated by a host inside the multihomed site,
<t>For a session originated by a host inside the multi-homed site, the decision of which source address to select is more complicated. We
the decision of what source address to select is more complicated. We
consider three main methods for hosts to get information about the consider three main methods for hosts to get information about the
network. The two proactive methods are Neighbor Discovery Router network. The two proactive methods are Neighbor Discovery Router
Advertisements and DHCPv6. The one reactive method we consider is Advertisements and DHCPv6. The one reactive method we consider is
ICMPv6. Note that we are explicitly excluding the possibility of having ICMPv6. Note that we are explicitly excluding the possibility of having
hosts participate in or even listen directly to routing protocol hosts participate in, or even listen directly to, routing protocol
advertisements.</t> advertisements.</t>
<t>First we look at how a host is currently expected to select the <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 conne ction.</t> default source and destination addresses to be used for a new conne ction.</t>
<section anchor="sec_host_address_selection_algo" numbered="true" toc="def
<section anchor="sec_host_address_selection_algo" ault">
title="Default Source Address Selection Algorithm on Hosts"> <name>Default Source Address Selection Algorithm on Hosts</name>
<t><xref target="RFC6724"/> defines the algorithms that hosts are <t><xref target="RFC6724" format="default"/> defines the algorithms that
hosts are
expected to use to select source and destination addresses for expected to use to select source and destination addresses for
packets. It defines an algorithm for selecting a source address and a packets. It defines an algorithm for selecting a source address and a
separate algorithm for selecting a destination address. Both of these separate algorithm for selecting a destination address. Both of these
algorithms depend on a policy table. <xref target="RFC6724"/> defines algorithms depend on a policy table. <xref target="RFC6724" format="defa
a default policy which produces certain behavior.</t> ult"/> defines
a default policy that produces certain behavior.</t>
<t>The rules in the two algorithms in <xref target="RFC6724"/> depend <t>The rules in the two algorithms in <xref target="RFC6724" format="def
ault"/> depend
on many different properties of addresses. While these are needed for on many different properties of addresses. While these are needed for
understanding how a host should choose addresses in an arbitrary understanding how a host should choose addresses in an arbitrary
environment, most of the rules are not relevant for understanding how environment, most of the rules are not relevant for understanding how
a host should choose among multiple source addresses in multihomed a host should choose among multiple source addresses in a multihomed
environment when sending a environment when sending a
packet to a remote host. Returning to the example in <xref packet to a remote host. Returning to the example in <xref target="fig_i
target="fig_isp_service"/>, we look at what the default algorithms in sp_service" format="default"/>, we look at what the default algorithms in
<xref target="RFC6724"/> say about the source address that internal <xref target="RFC6724" format="default"/> say about the source address t
hat internal
host H31 should use to send traffic to external host H101, somewhere host H31 should use to send traffic to external host H101, somewhere
on the Internet.</t> on the Internet.</t>
<t>There is no choice to be made with respect to destination address. <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 H31 needs to send a packet with D=2001:db8:0:1234::101 in order to
reach H101. So H31 have to choose between using S=2001:db8:0:a010::31 reach H101. So H31 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 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 targ through the rules for source address selection in <xref target="RFC6724"
et="RFC6724"/>. </t> sectionFormat="of" section="5" format="default"/>. </t>
<t> Rule 1 (Prefer same address) is not useful to
<t> Rule 1 (Prefer same address) is not useful to break the tie between source addresses because neither one of the candid
break the tie between source addresses, because neither the candidate ate
source addresses equals the destination address. </t> source addresses equals the destination address. </t>
<t> Rule 2 (Prefer appropriate scope) is also not useful in this scenari
<t> Rule 2 (Prefer appropriate scope) is also not used in this scenario, because o because both
both
source addresses and the destination address have global scope.</t> source addresses and the destination address have global scope.</t>
<t>Rule 3 (Avoid deprecated addresses) applies to an address that has <t>Rule 3 (Avoid deprecated addresses) applies to an address that has
been autoconfigured by a host using stateless address been autoconfigured by a host using stateless address
autoconfiguration as defined in <xref target="RFC4862"/>. An address autoconfiguration as defined in <xref target="RFC4862" format="default"/ >. An address
autoconfigured by a host has a preferred lifetime and a valid autoconfigured by a host has a preferred lifetime and a valid
lifetime. The address is preferred until the preferred lifetime lifetime. The address is preferred until the preferred lifetime
expires, after which it becomes deprecated. A deprecated address is not expires, after which it becomes deprecated. A deprecated address is not
used if there is a preferred address of the appropriate scope available. 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 When the valid lifetime expires, the address cannot be used at all. The
preferred and valid lifetimes for an autoconfigured address are set preferred and valid lifetimes for an autoconfigured address are set
based on the corresponding lifetimes in the Prefix Information Option based on the corresponding lifetimes in the Prefix Information Option
in Neighbor Discovery Router Advertisements. So a possible tool to in Neighbor Discovery Router Advertisements. In this scenario, a
control source address selection in this scenario would be for a host possible tool to control source address selection in this scenario
to make an address deprecated by having routers on that link, R1 and would be for a host to deprecate an address by having routers on that
R2 in <xref target="fig_isp_service"/>, send a Router Advertisement mess link, R1 and R2 in <xref target="fig_isp_service" format="default"/>, sen
age d Router Advertisement messages
containing a Prefix Information Option for the source prefix to be containing PIOs with the Preferred Lifetime value for the deprecated
discouraged (or prohibited) with the preferred lifetime set to zero. source prefix set to zero. This is a rather blunt tool, because it discou
This is a rather blunt tool, because it discourages or prohibits the use rages or prohibits the use
of that source prefix for all destinations. However, it may be useful in some scenarios. 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 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. using source addresses from that ISP address space.
</t> </t>
<t>Rule 4 (Avoid home addresses) does not apply here because we are <t>Rule 4 (Avoid home addresses) does not apply here because we are
not considering Mobile IP.</t> not considering Mobile IP.</t>
<t>Rule 5 (Prefer outgoing interface) is not useful in this scenario
<t>Rule 5 (Prefer outgoing interface) is not useful in this scenario,
because both source addresses are assigned to the same interface.</t> 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 <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 useful in the scenario when both R1 and R2 will advertise both source
prefixes. However potentially this rule may allow a host to select the prefixes. However, this rule may potentially allow a host to select the
correct source prefix by selecting a next-hop. The most obvious way 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 would be to make R1 advertise itself as a default router and send
PIO for 2001:db8:0:a010::/64, while R2 is advertising itself as a PIO for 2001:db8:0:a010::/64, while R2 advertises itself as a
default router and sending PIO for 2001:db8:0:b010::/64. We'll discuss default router and 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 later how Rule 5.5 can be used to influence a source address selection
in single-router topologies (e.g. when H41 is sending traffic using R3 in single-router topologies (e.g., when H41 is sending traffic using R3
as a default gateway).</t> as a default gateway).</t>
<t>Rule 6 (Prefer matching label) refers to the label value determined
<t>Rule 6 (Prefer matching label) refers to the Label value determined
for each source and destination prefix as a result of applying the for each source and destination prefix as a result of applying the
policy table to the prefix. With the default policy table defined in policy table to the prefix. With the default policy table defined in
Section 2.1 of <xref target="RFC6724"/>, Label(2001:db8:0:a010::31) = <xref 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, 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, 5. So with the default policy, Rule 6 does not break the tie. However,
the algorithms in <xref target="RFC6724"/> are defined in such a way the algorithms in <xref target="RFC6724" format="default"/> are defined
that non-default address selection policy tables can be used. <xref in such a way
target="RFC7078"/> defines a way to distribute a non-default address that non-default address selection policy tables can be used.
<xref target="RFC7078" format="default"/> defines a way to distribute a
non-default address
selection policy table to hosts using DHCPv6. So even though the selection policy table to hosts using DHCPv6. So even though the
application of rule 6 to this scenario using the default policy table application of Rule 6 to this scenario using the default policy table
is not useful, rule 6 may still be a useful tool.</t> is not useful, Rule 6 may still be a useful tool.</t>
<t>Rule 7 (Prefer temporary addresses) has to do with the technique <t>Rule 7 (Prefer temporary addresses) has to do with the technique
described in <xref target="RFC4941"/> to periodically randomize the described in <xref target="RFC4941" format="default"/> to periodically r andomize the
interface portion of an IPv6 address that has been generated using interface portion of an IPv6 address that has been generated using
stateless address autoconfiguration. In general, if H31 were using stateless address autoconfiguration. In general, if H31 were using
this technique, it would use it for both source addresses, for example this technique, it would use it for both source addresses, for example,
creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 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:b010:4838:f483:8384:3208, in addition to
2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would prefer 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 temporary addresses, but it would not break the tie between
the two source prefixes from ISP-A and ISP-B.</t> the two source prefixes from ISP-A and ISP-B.</t>
<t>Rule 8 (Use longest matching prefix) dictates that between two <t>Rule 8 (Use longest matching prefix) dictates that, between two
candidate source addresses the one which has longest common prefix candidate source addresses, the host selects the one that has
length with the destination address. For example, if H31 were longest common prefix length with the destination address. For example, if H31 w
ere
selecting the source address for sending packets to H101, this rule selecting the source address for sending packets to H101, this rule
would not be a tie breaker as for both candidate source addresses would not break the tie between candidate source addresses
2001:db8:0:a101::31 and 2001:db8:0:b101::31 the common prefix length 2001:db8:0:a101::31 and 2001:db8:0:b101::31 since the common prefix leng
with the destination is 48. However if H31 were selecting the source th
address for sending packets H41 address 2001:db8:0:a020::41, then this with the destination is 48. However, if H31 were selecting the source
address for sending packets to H41 address 2001:db8:0:a020::41, then thi
s
rule would result in using 2001:db8:0:a101::31 as a source 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: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:a000::/58, while for 2001:db8:0:b101::31 and
2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51). 2001:db8:0:a020::41, the common prefix is 2001:db8:0:a000::/51).
Therefore rule 8 might be useful for selecting the correct source Therefore Rule 8 might be useful for selecting the correct source
address in some but not all scenarios (for example if ISP-B services address in some, but not all, scenarios (for example if ISP-B services
belong to 2001:db8:0:b000::/59 then H31 would always use belong to 2001:db8:0:b000::/59, then H31 would always use
2001:db8:0:b010::31 to access those destinations).</t> 2001:db8:0:b010::31 to access those destinations).</t>
<t>So we can see that of the eight source address selection rules from
<t>So we can see that of the 8 source selection address rules from <xref target="RFC6724" format="default"/>, four actually apply to our ba
<xref target="RFC6724"/>, four actually apply to our basic site sic site
multihoming scenario. The rules that are relevant to this scenario are multihoming scenario. The rules that are relevant to this scenario are
summarized below.</t> summarized below.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Rule 3: Avoid deprecated addresses.</li>
<t>Rule 3: Avoid deprecated addresses.</t> <li>Rule 5.5: Prefer addresses in a prefix advertised by the
next-hop.</li>
<t>Rule 5.5: Prefer addresses in a prefix advertised by the <li>Rule 6: Prefer matching label.</li>
next-hop.</t> <li>Rule 8: Prefer longest matching prefix.</li>
</ul>
<t>Rule 6: Prefer matching label.</t>
<t>Rule 8: Prefer longest matching prefix.</t>
</list></t>
<t>The two methods that we discuss for controlling the source address <t>The two methods that we discuss for controlling the source address
selection through the four relevant rules above are SLAAC Router selection through the four relevant rules above are SLAAC Router
Advertisement messages and DHCPv6.</t> Advertisement messages and DHCPv6.</t>
<t>We also consider a possible role for ICMPv6 for getting <t>We also consider a possible role for ICMPv6 for getting
traffic-driven feedback from the network. With the source address traffic-driven feedback from the network. With the source address
selection algorithm discussed above, the goal is to choose the correct selection algorithm discussed above, the goal is to choose the correct
source address on the first try, before any traffic is sent. However, source address on the first try, before any traffic is sent. However,
another strategy is to choose a source address, send the packet, get another strategy is to choose a source address, send the packet, get
feedback from the network about whether or not the source address is feedback from the network about whether or not the source address is
correct, and try another source address if it is not.</t> correct, and try another source address if it is not.</t>
<t>We consider four scenarios in which a host needs to select the correc
<t>We consider four scenarios where a host needs to select the correct t
source address. The first is when both uplinks are working. The second source address. In the first scenario, both uplinks are working. In
is when one uplink has failed. The third one is a situation when one the second scenario, one uplink has failed. The third scenario is a
failed uplink has recovered. The last one is failure of both (all) situation in which one failed uplink has recovered. The last scenario is
failure of both (all)
uplinks.</t> uplinks.</t>
<t> <t>
It should be noted that <xref target="RFC6724"/> It should be noted that <xref target="RFC6724" format="default"/>
only defines the behavior of IPv6 only defines the behavior of IPv6
hosts to select default addresses that applications and upper-layer hosts to select default addresses that applications and upper-layer
protocols can use. Applications and upper-layer protocols can make their protocols can use. Applications and upper-layer protocols can make their
own choices on selecting source addresses. own choices on selecting source addresses.
The mechanism proposed in this document attempts to ensure that the subset of so urce 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 va rious aspects of the default source address selection defined in <xref target=" RFC6724"/>, calling it for the sake of brevity "the source address selection". The mechanism proposed in this document attempts to ensure that the subset of so urce 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 va rious aspects of the default source address selection defined in <xref target=" RFC6724" format="default"/>, calling it for the sake of brevity "the source addr ess selection".
</t> </t>
</section> </section>
<section anchor="sec_both_uplinks_working" numbered="true" toc="default">
<section anchor="sec_both_uplinks_working" <name>Selecting Default Source Address When Both Uplinks Are Working</na
title="Selecting Default Source Address When Both Uplinks Are Wor me>
king"> <t>Again we return to the topology in <xref target="fig_isp_service" for
<t>Again we return to the topology in <xref mat="default"/>. Suppose that the site administrator wants
target="fig_isp_service"/>. Suppose that the site administrator wants
to implement a policy by which all hosts need to use ISP-A to reach 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 H101 at D=2001:db8:0:1234::101. So for example, H31 needs to select
S=2001:db8:0:a010::31.</t> S=2001:db8:0:a010::31.</t>
<section anchor="sec_both_working_dhcpv6" numbered="true" toc="default">
<section anchor="sec_both_working_dhcpv6" <name>Distributing Default Address Selection Policy Table with DHCPv6<
title="Distributing Default Address Selection Policy Table with /name>
DHCPv6">
<t>This policy can be implemented by using DHCPv6 to distribute an <t>This policy can be implemented by using DHCPv6 to distribute an
address selection policy table that assigns the same label to address selection policy table that assigns the same label to
destination address that match 2001:db8:0:1234::/64 as it does to destination addresses that match 2001:db8:0:1234::/64 as it does to
source addresses that match 2001:db8:0:a000::/52. The following two source addresses that match 2001:db8:0:a000::/52. The following two
entries accomplish this.</t> entries accomplish this.</t>
<figure align="center" anchor="fig_policy_table" <figure anchor="fig_policy_table">
title="Policy table entries to implement a routing policy"> <name>Policy Table Entries to Implement a Routing Policy</name>
<artwork align="center"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Prefix Precedence Label Prefix Precedence Label
2001:db8:0:1234::/64 50 33 2001:db8:0:1234::/64 50 33
2001:db8:0:a000::/52 50 33 2001:db8:0:a000::/52 50 33
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This requires that the hosts implement <xref target="RFC6724" forma
<t>This requires that the hosts implement <xref target="RFC6724"/>, t="default"/>,
the basic source and destination address framework, along with <xref the basic source and destination address framework, along with <xref t
target="RFC7078"/>, the DHCPv6 extension for distributing a arget="RFC7078" format="default"/>, the DHCPv6 extension for distributing a
non-default policy table. Note that it does NOT require that the non-default policy table. Note that it does NOT require that the
hosts use DHCPv6 for address assignment. The hosts could still use hosts use DHCPv6 for address assignment. The hosts could still use
stateless address autoconfiguration for address configuration, while stateless address autoconfiguration for address configuration, while
using DHCPv6 only for policy table distribution (see <xref using DHCPv6 only for policy table distribution (see <xref target="RFC
target="RFC8415"/>). However this method has a number of 8415" format="default"/>). However this method has a number of
disadvantages: <list style="symbols"> disadvantages: </t>
<t>DHCPv6 support is not a mandatory requirement for IPv6 hosts <ul spacing="normal">
(<xref target="RFC6434"/>), <li>DHCPv6 support is not a mandatory requirement for IPv6 hosts <xr
so this method might not work for all devices.</t> ef target="RFC8504" format="default"/>,
so this method might not work for all devices.</li>
<t>Network administrators are required to explicitly configure <li>Network administrators are required to explicitly configure
the desired network access policies on DHCPv6 servers. Whil the desired network access policies on DHCPv6 servers. While it mig
e it might be feasible in the scenario ht be feasible in the scenario
of a single multihomed network, such approach might have so of a single multihomed network, such approach might have some scala
me scalability issues, especially if the centralized bility issues, especially if the centralized
DHCPv6 solution is deployed to serve a large number of mult DHCPv6 solution is deployed to serve a large number of multihomed s
iomed sites.</t> ites.</li>
</list></t> </ul>
</section> </section>
<section anchor="sec_both_working_ra" numbered="true" toc="default">
<section anchor="sec_both_working_ra" <name>Controlling Default Source Address Selection with Router Adverti
title="Controlling Default Source Address Selection With Router sements</name>
Advertisements">
<t>Neighbor Discovery currently has two mechanisms to communicate <t>Neighbor Discovery currently has two mechanisms to communicate
prefix information to hosts. The base specification for Neighbor prefix information to hosts. The base specification for Neighbor
Discovery (see <xref target="RFC4861"/>) defines the Prefix Discovery (see <xref target="RFC4861" format="default"/>) defines the Prefix
Information Option (PIO) in the Router Advertisement (RA) message. Information Option (PIO) in the Router Advertisement (RA) message.
When a host receives a PIO with the A-flag set, it can use the When a host receives a PIO with the A-flag <xref target="RFC8425"
prefix in the PIO as source prefix from which it assigns itself an 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) IP address using stateless address autoconfiguration (SLAAC)
procedures described in <xref target="RFC4862"/>. In the example of procedures described in <xref target="RFC4862" format="default"/>. In
<xref target="fig_isp_service"/>, if the site network is using the example of
<xref 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 SLAAC, we would expect both R1 and R2 to send RA messages with PIOs
for both source prefixes 2001:db8:0:a010::/64 and 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. H31 would then use the 2001:db8:0:b010::/64. H31 would then use the
SLAAC procedure to configure itself with the 2001:db8:0:a010::31 and SLAAC procedure to configure itself with 2001:db8:0:a010::31 and
2001:db8:0:b010::31.</t> 2001:db8:0:b010::31.</t>
<t>Whereas a host learns about source prefixes from PIO messages, <t>Whereas a host learns about source prefixes from PIO messages,
hosts can learn about a destination prefix from a Router hosts can learn about a destination prefix from a Router
Advertisement containing Route Information Option (RIO), as Advertisement containing a Route Information Option (RIO), as
specified in <xref target="RFC4191"/>. The destination prefixes in specified in <xref target="RFC4191" format="default"/>. The destinatio
n prefixes in
RIOs are intended to allow a host to choose the router that it uses 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> as its first hop to reach a particular destination prefix.</t>
<t>As currently standardized, neither PIO nor RIO options contained <t>As currently standardized, neither PIO nor RIO options contained
in Neighbor Discovery Router Advertisements can communicate the in Neighbor Discovery Router Advertisements can communicate the
information needed to implement the desired routing policy. PIO's information needed to implement the desired routing policy. PIOs
communicate source prefixes, and RIO communicate destination communicate source prefixes, and RIOs communicate destination
prefixes. However, there is currently no standardized way to prefixes. However, there is currently no standardized way to
directly associate a particular destination prefix with a particular directly associate a particular destination prefix with a particular
source prefix.</t> source prefix.</t>
<t><xref target="I-D.pfister-6man-sadr-ra" format="default"/> proposes
<t><xref target="I-D.pfister-6man-sadr-ra"/> proposes a Source a Source
Address Dependent Route Information option for Neighbor Discovery Address Dependent Route Information option for Neighbor Discovery
Router Advertisements which would associate a source prefix and with Router Advertisements that would associate a source prefix with
a destination prefix. The details of <xref a destination prefix. The details of <xref target="I-D.pfister-6man-sa
target="I-D.pfister-6man-sadr-ra"/> might need tweaking to address dr-ra" format="default"/> might need tweaking to address
this use case. However, in order to be able to use Neighbor this use case. However, in order to be able to use Neighbor
Discovery Router Advertisements to implement this routing policy, an Discovery Router Advertisements to implement this routing policy, an
extension that allows R1 and R2 to explicitly communicate to H31 extension is needed that would allow R1 and R2 to explicitly communica
an association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 te to H31
would be needed.</t> an association between S=2001:db8:0:a000::/52 and D=2001:db8:0:1234::/
64.</t>
<t>However, Rule 5.5 of the default source address selection algorithm (discussed <t>However, Rule 5.5 of the default source address selection algorithm (discussed
in <xref target="sec_host_address_selection_algo"/> above), in <xref target="sec_host_address_selection_algo" format="defau
together with default router preference (specified in <xref lt"/>),
target="RFC4191"/>) and RIO can be used to influence a source together with default router preference
(specified in <xref target="RFC4191" format="default"/>)
and RIO, can be used to influence a source
address selection on a host as described below. Let's look at 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 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 all for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point, all
traffic would use the same next-hop (R3 link-local address) so Rule 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 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 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 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 different link-local addresses for its interface facing H41 (one for
each scoped forwarding table, LLA_A and LLA_B) and starts sending each scoped forwarding table, LLA_A and LLA_B), R3 will send
two different RAs: one is sent from LLA_A and includes PIO for two different RAs: one from LLA_A that includes a PIO for
2001:db8:0:a020::/64, another is sent from LLA_B and includes PIO 2001:db8:0:a020::/64, and another from LLA_B that includes a PIO
for 2001:db8:0:b020::/64. Now it is possible to influence H41 source for 2001:db8:0:b020::/64. Now it is possible to influence H41 source
address selection for destinations which follow the default route by address selection for destinations that follow the default route by
setting default router preference in RAs. If it is desired that H41 setting the default router preference in RAs. If it is desired that H4
reaches H101 (or any destinations in the Internet) via ISP-A, then 1
RAs sent from LLA_A should have default router preference set to 01 reaches H101 (or any destination in the Internet) via ISP-A, then
(high priority), while RAs sent from LLA_B should have preference RAs sent from LLA_A should have the default router preference set to 0
set to 11 (low). Then LLA_A would be chosen as a next-hop for H101 1
and therefore (as per rule 5.5) 2001:db8:0:a020::41 would be (high priority), while RAs sent from LLA_B should have the preference
set to 11 (low). LLA_A would then be chosen as a next-hop for H101,
and therefore (per Rule 5.5) 2001:db8:0:a020::41 would be
selected as the source address. If, at the same time, it is desired selected as the source address. If, at the same time, it is desired
that H61 is accessible via ISP-B then R3 should include a RIO for that H61 is accessible via ISP-B, then R3 should include a RIO for
2001:db8:0:6666::/64 to its RA sent from LLA_B. H41 would chose 2001:db8:0:6666::/64 in its RA sent from LLA_B. H41 would choose
LLA_B as a next-hop for all traffic to H61 and then as per Rule 5.5, LLA_B as a next-hop for all traffic to H61, and then per Rule 5.5,
2001:db8:0:b020::41 would be selected as a source address.</t> 2001:db8:0:b020::41 would be selected as a source address.</t>
<t>If in the above-mentioned scenario it is desirable that all
<t>If in the above mentioned scenario it is desirable that all Internet traffic leaves the network via ISP-A, and the link to ISP-B
Internet traffic leaves the network via ISP-A and the link to ISP-B is used for accessing ISP-B services only (not as an ISP-A link
is used for accessing ISP-B services only (not as ISP-A link backup), then RAs sent by R3 from LLA_B should have their Router Lifet
backup), then RAs sent by R3 from LLA_B should have Router Lifetime ime
set to 0 and should include RIOs for ISP-B address space. It would values set to zero and should include RIOs for ISP-B address space. It
instruct H41 to use LLA_A for all Internet traffic but use LLA_B as 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> a next-hop while sending traffic to ISP-B addresses.</t>
<t>The description of the mechanism above assumes SADR support by the <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 first-hop routers as well as SERs. However, a first-hop router can still
provide a less flexible version of this mechanism even without provide a less flexible version of this mechanism even without
implementing SADR. This could be done by providing configurati on knobs on the implementing SADR. This could be done by providing configurati on knobs on the
first-hop router that allow it to generate different link-local addresses first-hop router that allow it to generate different link-local addresses
and to send individual RAs for each prefix. and to send individual RAs for each prefix.
</t> </t>
<t> The mechanism described above relies on Rule 5.5 of the
<t> The mechanism described above relies on Rule 5.5 of the default source address selection algorithm defined in
default source address selection algorithm defined in <xref tar <xref target="RFC6724" format="default"/>.
get="RFC6724"/>. <xref target="RFC8028" format="default"/> states that
<xref target="RFC8028"/> states that "A host SHOULD select def "A host <bcp14>SHOULD</bcp14> select default routers for each
ault routers for each prefix it is prefix it is
assigned an address in". assigned an address in." It also recommends that
It also recommends that hosts should implement Rule 5.5. of <xref target="RFC6724" form
hosts should implement Rule 5.5. of <xref target="RFC6724"/>. H at="default"/>.
osts following the Hosts following the recommendations specified in
recommendations specified in <xref target="RFC8028"/> therefor <xref target="RFC8028" format="default"/> therefore should be
e should be able to benefit from able to benefit from
the solution described in this document. No standards need to be the solution described in this document. No standards need to be
updated in regards to host behavior. </t> updated in regards to host behavior. </t>
</section> </section>
<section anchor="sec_both_working_icmpv6" numbered="true" toc="default">
<section anchor="sec_both_working_icmpv6" <name>Controlling Default Source Address Selection with ICMPv6</name>
title="Controlling Default Source Address Selection With ICMPv6
">
<t>We now discuss how one might use ICMPv6 to implement the routing <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, 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 even when uplinks to both ISPs are working. If H31 started sending
traffic to H101 with S=2001:db8:0:b010::31 and 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 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 the uplink to ISP-B. SERb1 could recognize that this traffic is
not following the desired routing policy and react by sending an not following the desired routing policy and react by sending an
ICMPv6 message back to H31.</t> ICMPv6 message back to H31.</t>
<t>In this example, we could arrange things so that SERb1 drops the <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 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 then sends to H31 an ICMPv6 Destination Unreachable message with
Code 5 (Source address failed ingress/egress policy). When H31 Code 5 (Source address failed ingress/egress policy). When H31
receives this packet, it would then be expected to try another receives this packet, it would then be expected to try another
source address to reach the destination. In this example, H31 would source address to reach the destination. In this example, H31 would
then send a packet with S=2001:db8:0:a010::31 and 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 D=2001:db8:0:1234::101, which will reach SERa and be forwarded out
the uplink to ISP-A.</t> the uplink to ISP-A.</t>
<t>However, we would also want it to be the case that SERb1 does not <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 enforce this routing policy when the uplink from SERa to ISP-A has
failed. This could be accomplished by having SERa originate a failed. This could be accomplished by having SERa originate a
source-prefix-scoped route for (S=2001:db8:0:a000::/52, source-prefix-scoped route for (S=2001:db8:0:a000::/52,
D=2001:db8:0:1234::/64) and have SERb1 monitor the presence of that 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 route. If that route is not present (because SERa has stopped
originating it), then SERb1 will not enforce the routing policy, and originating it), then SERb1 will not enforce the routing policy, and
it will forward packets with S=2001:db8:0:b010::31 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> 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 <t>We can also use this source-prefix-scoped route originated by
SERa to communicate the desired routing policy to SERb1. We can SERa to communicate the desired routing policy to SERb1. We can
define an EXCLUSIVE flag to be advertised together with the IGP 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 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 would allow SERa to communicate to SERb that SERb should reject
traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6 traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6
Destination Unreachable Code 5 message, as long as the route for 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 defini tion of an EXCLUSIVE flag for SADR (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. The defini tion of an EXCLUSIVE flag for SADR
advertisements in IGPs would require future standardization work. advertisements in IGPs would require future standardization work.
skipping to change at line 1431 skipping to change at line 1297
<t>We can also use this source-prefix-scoped route originated by <t>We can also use this source-prefix-scoped route originated by
SERa to communicate the desired routing policy to SERb1. We can SERa to communicate the desired routing policy to SERb1. We can
define an EXCLUSIVE flag to be advertised together with the IGP 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 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 would allow SERa to communicate to SERb that SERb should reject
traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6 traffic for D=2001:db8:0:1234::/64 and respond with an ICMPv6
Destination Unreachable Code 5 message, as long as the route for 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 defini tion of an EXCLUSIVE flag for SADR (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. The defini tion of an EXCLUSIVE flag for SADR
advertisements in IGPs would require future standardization work. advertisements in IGPs would require future standardization work.
</t> </t>
<t>Finally, if we are willing to extend ICMPv6 to support this <t>Finally, if we are willing to extend ICMPv6 to support this
solution, then we could create a mechanism for SERb1 to tell the solution, then we could create a mechanism for SERb1 to tell the
host what source address it should be using to successfully forward host which source address it should be using to successfully forward
packets that meet the policy. In its current form, when SERb1 sends packets that meet the policy. In its current form, when SERb1 sends
an ICMPv6 Destination Unreachable Code 5 message, it is basically an ICMPv6 Destination Unreachable Code 5 message, it is basically
saying, "This source address is wrong. Try another source address." saying, "This source address is wrong. Try another source address."
In the absence of a clear indication which address to try next, the ho st In the absence of a clear indication which address to try next, the ho st
will iterate over all addresses assigned to the interface (e.g. variou will iterate over all addresses assigned to the interface (e.g., vario
s us
privacy addresses) which would lead to significant delays and degraded privacy addresses), which would lead to significant delays and degrade
user experience. d user experience.
It would be better is if the ICMPv6 message could say, "This source It would be better if the ICMPv6 message could say, "This source
address is wrong. Instead use a source address in address is wrong. Instead use a source address in
S=2001:db8:0:a000::/52.". </t> S=2001:db8:0:a000::/52". </t>
<t>However, using ICMPv6 for signaling source address information
<t>However using ICMPv6 for signaling source address information
back to hosts introduces new challenges. Most routers currently have back to hosts introduces new challenges. Most routers currently have
software or hardware limits on generating ICMP messages. A site software or hardware limits on generating ICMP messages. A site
administrator deploying a solution that relies on the SERs administrator deploying a solution that relies on the SERs
generating ICMP messages could try to improve the performance of generating ICMP messages could try to improve the performance of
SERs for generating ICMP messages. However, in a large network, it SERs for generating ICMP messages. However, in a large network, it
is still likely that ICMP message generation limits will be reached. is still likely that ICMP message generation limits will be reached.
As a result hosts would not receive ICMPv6 back which in turn leads As a result, hosts would not receive ICMPv6 back, which in turn leads
to traffic blackholing and poor user experience. To improve the to traffic blackholing and poor user experience. To improve the
scalability of ICMPv6-based signaling hosts SHOULD cache the scalability of ICMPv6-based signaling, hosts <bcp14>SHOULD</bcp14> cac he the
preferred source address (or prefix) for the given destination preferred source address (or prefix) for the given destination
(which in turn might cause issues in case of the corresponding (which in turn might cause issues in the case of the corresponding
ISP uplinks failure - see <xref target="sec_one_uplink_failed"/>). In ISP uplink failure - see <xref target="sec_one_uplink_failed" format="
addition, the same source prefix SHOULD be used for other default"/>). In
addition, the same source prefix <bcp14>SHOULD</bcp14> be used for oth
er
destinations in the same /64 as the original destination address. destinations in the same /64 as the original destination address.
The source prefix to the destination mapping SHOULD have a specific li The source prefix to the destination mapping <bcp14>SHOULD</bcp14> hav
fetime. Expiration of the e a specific lifetime. Expiration of the
lifetime SHOULD trigger the source address selection algorithm lifetime <bcp14>SHOULD</bcp14> trigger the source address selection al
gorithm
again.</t> again.</t>
<t> <t>
Using ICMPv6 Destination Unreachable Messages with Code 5 to influence source address selection Using ICMPv6 Destination Unreachable Messages with Code 5 to influence source address selection
introduces some security challenges which are discussed in <xref target introduces some security challenges, which are discussed in <xref targe
="Security"/>. t="Security" format="default"/>.
</t> </t>
<t> As currently standardized in <xref target="RFC4443" format="defaul
<t> As currently standardized in <xref target="RFC4443"/>, the t"/>, the ICMPv6
ICMPv6
Destination Unreachable Message with Code 5 would allow for the Destination Unreachable Message with Code 5 would allow for the
iterative approach to retransmitting packets using different so urce addresses. iterative approach to retransmitting packets using different so urce addresses.
As currently defined, the ICMPv6 message does not provide As currently defined, the ICMPv6 message does not provide
a mechanism to communication information about which source pre fix a mechanism to communicate information about which source prefi x
should be used for a retransmitted packet. The current documen t does not should be used for a retransmitted packet. The current documen t does not
define such a mechanism but it might be a useful extension define such a mechanism, but it might be a useful extension
to define in a different document. However this approach has so to define in a different document. However, this approach has s
me security implications such as an ability for an attacker to send spoofed ICMP ome security implications,
v6 messages to signal invalid/unreachable source prefix causing DoS-type attack. such as an ability for an attacker to send spoofed ICMPv6 mess
</t> ages
to signal an invalid/unreachable source prefix, causing a DoS-
type attack.</t>
</section> </section>
<section anchor="sec_both_working_summary" numbered="true" toc="default"
<section anchor="sec_both_working_summary" >
title="Summary of Methods For Controlling Default Source Addres <name>Summary of Methods for Controlling Default Source Address Select
s Selection To Implement Routing Policy"> ion to Implement Routing Policy</name>
<t>So to summarize this section, we have looked at three methods for <t>So to summarize this section, we have looked at three methods for
implementing a simple routing policy where all traffic for a given implementing a simple routing policy where all traffic for a given
destination on the Internet needs to use a particular ISP, even when destination on the Internet needs to use a particular ISP, even when
the uplinks to both ISPs are working.</t> the uplinks to both ISPs are working.</t>
<t>The default source address selection policy cannot distinguish <t>The default source address selection policy cannot distinguish
between the source addresses needed to enforce this policy, so a between the source addresses needed to enforce this policy, so a
non-default policy table using associating source and destination non-default policy table using associating source and destination
prefixes using Label values would need to be installed on each host. prefixes using label values would need to be installed on each host.
A mechanism exists for DHCPv6 to distribute a non-default policy A mechanism exists for DHCPv6 to distribute a non-default policy
table but such solution would heavily rely on DHCPv6 support by host table, but such solution would heavily rely on DHCPv6 support by the h
operating system. Moreover there is no mechanism to translate ost
operating system. Moreover, there is no mechanism to translate
desired routing/traffic engineering policies into policy tables on desired routing/traffic engineering policies into policy tables on
DHCPv6 servers. Therefore using DHCPv6 for controlling address DHCPv6 servers. Therefore using DHCPv6 for controlling the address
selection policy table is not recommended and SHOULD NOT be selection policy table is not recommended and <bcp14>SHOULD NOT</bcp14
> be
used.</t> used.</t>
<t>At the same time, Router Advertisements provide a reliable
<t>At the same time Router Advertisements provide a reliable mechanism to influence the source address selection process via PIO, R
mechanism to influence source address selection process via PIO, RIO IO,
and default router preferences. As all those options have been and default router preferences. As all those options have been
standardized by IETF and are supported by various operating systems standardized by the IETF and are supported by various operating system s,
no changes are required on hosts. First-hop routers in the no changes are required on hosts. First-hop routers in the
enterprise network need to be able of sending different RAs for enterprise network need to be capable of sending different RAs for
different SLAAC prefixes (either based on scoped forwarding tables different SLAAC prefixes (either based on scoped forwarding tables
or based on pre-configured policies).</t> or based on preconfigured policies).</t>
<t>SERs can enforce the routing policy by sending ICMPv6 Destination <t>SERs can enforce the routing policy by sending ICMPv6 Destination
Unreachable messages with Code 5 (Source address failed Unreachable messages with Code 5 (Source address failed
ingress/egress policy) for traffic that is being sent with the wrong ingress/egress policy) for traffic sent with the wrong
source address. The policy distribution could be automated by defining source address. The policy distribution could be automated by defining
an EXCLUSIVE flag for the source-prefix-scoped route which can be an EXCLUSIVE flag for the source-prefix-scoped route, which could then be
set on the SER that originates the route. As ICMPv6 message set on the SER that originates the route. As ICMPv6 message
generation can be rate-limited on routers, it SHOULD NOT be used as generation can be rate limited on routers, it <bcp14>SHOULD NOT</bcp14 > be used as
the only mechanism to influence source address selection on hosts. the only mechanism to influence source address selection on hosts.
While hosts SHOULD select the correct source address for a given While hosts <bcp14>SHOULD</bcp14> select the correct source address fo
destination the network SHOULD signal any source address issues back r a given
destination, the network <bcp14>SHOULD</bcp14> signal any source addre
ss issues back
to hosts using ICMPv6 error messages.</t> to hosts using ICMPv6 error messages.</t>
</section> </section>
</section> </section>
<section anchor="sec_one_uplink_failed" numbered="true" toc="default">
<section anchor="sec_one_uplink_failed" <name>Selecting Default Source Address When One Uplink Has Failed</name>
title="Selecting Default Source Address When One Uplink Has Faile <t>Now we discuss whether DHCPv6, Neighbor Discovery Router Advertisemen
d"> ts,
<t>Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements,
and ICMPv6 can help a host choose the right source address when an 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 uplink to one of the ISPs has failed. Again we look at the scenario in
<xref target="fig_isp_service"/>. This time we look at traffic from <xref 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 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 initially assume that the uplink from SERa to ISP-A is working and
that the uplink from SERb1 to ISP-B is working.</t> that the uplink from SERb1 to ISP-B is working.</t>
<t>We assume there is no particular routing policy desired, so H31 is <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 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 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 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 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 link from SERb1 to ISP-B fails. How should H31 learn that it needs to
start sending the packet to H501 with S=2001:db8:0:a010::31 in order start sending 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 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 doesn't prevent H31 from still sending packets with
S=2001:db8:0:b010::31 in order to reach H61 at S=2001:db8:0:b010::31 in order to reach H61 at
D=2001:db8:0:6666::61.</t> D=2001:db8:0:6666::61.</t>
<section anchor="sec_one_uplink_failed_dhcpv6" numbered="true" toc="defa
<section anchor="sec_one_uplink_failed_dhcpv6" ult">
title="Controlling Default Source Address Selection With DHCPv6 <name>Controlling Default Source Address Selection with DHCPv6</name>
"> <t>For this example, we assume that the site network in
<t>For this example we assume that the site network in <xref <xref target="fig_isp_service" format="default"/> has a centralized DH
target="fig_isp_service"/> has a centralized DHCP server and all CP server and that all
routers act as DHCP relay agents. We assume that both of the routers act as DHCP relay agents. We assume that both of the
addresses assigned to H31 were assigned via DHCP.</t> addresses assigned to H31 were assigned via DHCP.</t>
<t>We could try to have the DHCP server monitor the state of the <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 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 its valid can no longer use S=2001:db8:0:b010::31 by setting its valid
lifetime to zero. The DHCP server could initiate this process by lifetime to zero. The DHCP server could initiate this process by
sending a Reconfigure Message to H31 as described in Section 18.3 of sending a Reconfigure message to H31 as described in
<xref target="RFC8415"/>. Or the DHCP server can assign addresses <xref target="RFC8415" sectionFormat="of" section="18.3" format="defau
lt"/>. Or the DHCP server can assign addresses
with short lifetimes in order to force clients to renew them with short lifetimes in order to force clients to renew them
often.</t> often.</t>
<t>This approach would prevent H31 from using S=2001:db8:0:b010::31 <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 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 H31 from using S=2001:db8:0:b010::31 to reach H61 at
D=2001:db8:0:6666::61, which is not desirable.</t> D=2001:db8:0:6666::61, which is not desirable.</t>
<t>Another potential approach is to have the DHCP server monitor the <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 uplink from SERb1 to ISP-B and control the choice of source address
on H31 by updating its address selection policy table via the on H31 by updating its address selection policy table via the
mechanism in <xref target="RFC7078"/>. The DHCP server could mechanism in <xref target="RFC7078" format="default"/>. The DHCP serve
initiate this process by sending a Reconfigure Message to H31. Note r could
that <xref target="RFC8415"/> requires that Reconfigure Message use initiate this process by sending a Reconfigure message to H31. Note
that <xref target="RFC8415" format="default"/> requires that Reconfigu
re messages use
DHCP authentication. DHCP authentication could be avoided by using DHCP authentication. DHCP authentication could be avoided by using
short address lifetimes to force clients to send Renew messages to short address lifetimes to force clients to send Renew messages to
the server often. If the host is not obtaining its IP addresses from the server often. If the host does not obtain its IP addresses from
the DHCP server, then it would need to use the Information Refresh the DHCP server, then it would need to use the Information Refresh
Time option defined in <xref target="RFC8415"/>.</t> Time option defined in <xref target="RFC8415" format="default"/>.</t>
<t>If the following policy table can be installed on H31 after the <t>If the following policy table can be installed on H31 after the
failure of the uplink from SERb1, then the desired routing behavior failure of the uplink from SERb1, then the desired routing behavior
should be achieved based on source and destination prefix being should be achieved based on source and destination prefix being
matched with label values.</t> matched with label values.</t>
<t><figure align="center" anchor="fig_policy_table_failed_uplink" <figure anchor="fig_policy_table_failed_uplink">
title="Policy Table Needed On Failure Of Uplink From SERb1 "> <name>Policy Table Needed on Failure of Uplink from SERb1</name>
<artwork align="center"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Prefix Precedence Label Prefix Precedence Label
::/0 50 44 ::/0 50 44
2001:db8:0:a000::/52 50 44 2001:db8:0:a000::/52 50 44
2001:db8:0:6666::/64 50 55 2001:db8:0:6666::/64 50 55
2001:db8:0:b000::/52 50 55 2001:db8:0:b000::/52 50 55
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The described solution has a number of significant drawbacks, <t>The described solution has a number of significant drawbacks,
some of them already discussed in <xref some of them already discussed in <xref target="sec_both_working_dhcpv
target="sec_both_working_dhcpv6"/>.</t> 6" format="default"/>.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>DHCPv6 support is not required for an IPv6 host, and there are
<t>DHCPv6 support is not required for an IPv6 host and there are operating systems that do not support DHCPv6. Besides that, it
operating systems which do not support DHCPv6. Besides that, it does not appear that <xref target="RFC7078" format="default"/> has
does not appear that <xref target="RFC7078"/> has been widely been widely
implemented on host operating systems.</t> implemented on host operating systems.</li>
<li>
<t><xref target="RFC7078"/> does not clearly specify this kind <xref target="RFC7078" format="default"/> does not clearly specify
of a dynamic use case where address selection policy needs to be this kind
of a dynamic use case in which the address selection policy needs
to be
updated quickly in response to the failure of a link. In a large updated quickly in response to the failure of a link. In a large
network it would present scalability issues as many hosts need network, it would present scalability issues as many hosts need
to be reconfigured in very short period of time.</t> to be reconfigured in a very short period of time.</li>
<li>Updating DHCPv6 server configuration each time an ISP's
<t>Updating DHCPv6 server configuration each time an ISP
uplink changes its state introduces some scalability issues, espec ially uplink changes its state introduces some scalability issues, espec ially
for mid/large distributed scale enterprise networks. In addition t for mid/large distributed-scale enterprise networks. In addition t
o that, o that,
the policy table needs to be manually configured by administrators the policy table needs to be manually configured by administrators
which makes , which makes
that solution prone to human error.</t> that solution prone to human error.</li>
<li>No mechanism exists for making DHCPv6 servers aware of
<t>No mechanism exists for making DHCPv6 servers aware of network topology/routing changes in the network. In general,
network topology/routing changes in the network. In general having DHCPv6 servers monitor network-related events sounds like a
DHCPv6 servers monitoring network-related events sounds like a bad idea as it requires completely new functionality beyond the sc
bad idea as completely new functionality beyond the scope of ope of the
DHCPv6 role is required.</t> DHCPv6 role.</li>
</list></t> </ul>
</section> </section>
<section anchor="sec_one_uplink_failed_ra" numbered="true" toc="default"
<section anchor="sec_one_uplink_failed_ra" >
title="Controlling Default Source Address Selection With Router <name>Controlling Default Source Address Selection with Router Adverti
Advertisements"> sements</name>
<t>The same mechanism as discussed in <xref <t>The same mechanism as discussed in <xref target="sec_both_working_r
target="sec_both_working_ra"/> can be used to control the source a" format="default"/> can be used to control the source
address selection in the case of an uplink failure. If a particular address selection in the case of an uplink failure. If a particular
prefix should not be used as a source for any destinations, then the prefix should not be used as a source for any destination, then the
router needs to send RA with Preferred Lifetime field for that router needs to send an RA with the Preferred Lifetime field for that
prefix set to 0.</t> prefix set to zero.</t>
<t>Let's consider a scenario in which all uplinks are operational, and
<t>Let's consider a scenario when all uplinks are operational and H41 receives two different RAs from R3: one from LLA_A with a PIO for
H41 receives two different RAs from R3: one from LLA_A with PIO for 2001:db8:0:a020::/64 and the default router preference set to 11 (low)
2001:db8:0:a020::/64, default router preference set to 11 (low) and , and
another one from LLA_B with PIO for 2001:db8:0:a020::/64, default another one from LLA_B with a PIO for 2001:db8:0:a020::/64, the defaul
router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. t
As a result H41 is using 2001:db8:0:b020::41 as a source address for router preference set to 01 (high), and a RIO for 2001:db8:0:6666::/64
all Internet traffic and those packets are sent by SERs to ISP-B. If .
SERb1 uplink to ISP-B failed, the desired behavior is that H41 stops As a result, H41 uses 2001:db8:0:b020::41 as a source address for
all Internet traffic, and those packets are sent by SERs to ISP-B. If
SERb1's uplink to ISP-B fails, the desired behavior is that H41 stops
using 2001:db8:0:b020::41 as a source address for all destinations using 2001:db8:0:b020::41 as a source address for all destinations
but H61. To achieve that R3 should react to SERb1 uplink failure but H61. To achieve that, R3 should react to SERb1's uplink failure
(which could be detected as the scoped route (which could be detected as the disappearance of scoped route
(S=2001:db8:0:b000::/52, D=::/0) disappearance) by withdrawing (S=2001:db8:0:b000::/52, D=::/0)) by withdrawing
itself as a default router. R3 sends a new RA from LLA_B with Router itself as a default router. R3 sends a new RA from LLA_B with the Rout
Lifetime value set to 0 (which means that it should not be used as er
default router). That RA still contains PIO for 2001:db8:0:b020::/64 Lifetime value set to zero (which means that it should not be used as
(for SLAAC purposes) and RIO for 2001:db8:0:6666::/64 so H41 can 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 ca
n
reach H61 using LLA_B as a next-hop and 2001:db8:0:b020::41 as a 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 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 will be used as a next-hop and 2001:db8:0:a020::41 as a source
address.</t> address.</t>
<t>If all of the uplinks to ISP-B have failed, source addresses from
<t>If all uplinks to ISP-B have failed and therefore source ISP-B address space should not be used. In such a failure scenario,
addresses from ISP-B address space should not be used at all, the the forwarding table scoped S=2001:db8:0:b000::/52 contains no
forwarding table scoped S=2001:db8:0:b000::/52 contains no entries. entries, indicating that R3 can instruct hosts to stop using source
Hosts can be instructed to stop using source addresses from that addresses from 2001:db8:0:b000::/52 by sending RAs containing PIOs
block by sending RAs containing PIO with Preferred Lifetime set to with Preferred Lifetime values set to zero.</t>
0.</t>
</section> </section>
<section anchor="sec_one_uplink_failed_icmp" numbered="true" toc="defaul
<section anchor="sec_one_uplink_failed_icmp" t">
title="Controlling Default Source Address Selection With ICMPv6 <name>Controlling Default Source Address Selection with ICMPv6</name>
">
<t>Now we look at how ICMPv6 messages can provide information back <t>Now we look at how ICMPv6 messages can provide information back
to H31. We assume again that at the time of the failure H31 is to H31. We assume again that, at the time of the failure, H31 is
sending packets to H501 using (S=2001:db8:0:b010::31, 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, 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 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 default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its
unscoped default destination route. With these routes no longer in unscoped default destination route. With these routes no longer in
the IGP, traffic with (S=2001:db8:0:b010::31, 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 D=2001:db8:0:5678::501) would end up at SERa based on the unscoped
default destination route being originated by SERa. Since that default destination route being originated by SERa. Since that
traffic has the wrong source address to be forwarded to ISP-A, SERa 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 would drop it and send a Destination Unreachable message with Code 5
(Source address failed ingress/egress policy) back to H31. H31 would (Source address failed ingress/egress policy) back to H31. H31 would
then know to use another source address for that destination and 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 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 would be forwarded to SERa based on the source-prefix-scoped default
destination route still being originated by SERa, and SERa would destination route still being originated by SERa, and SERa would
forward it to ISP-A. As discussed above, if we are willing to extend 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 ICMPv6, SERa can even tell H31 what source address it should use to
reach that destination. The expected host behaviour has been reach that destination. The expected host behavior has been
discussed in <xref target="sec_both_working_icmpv6"/>. discussed in <xref target="sec_both_working_icmpv6" format="default"/>.
Using ICMPv6 would have the same scalability/rate limiting issues discu Using ICMPv6 would have the same scalability/rate limiting issues
ssed in <xref that are discussed in <xref target="sec_both_working_icmpv6" format="d
target="sec_both_working_icmpv6"/>. ISP-B uplink failure immedi efault"/>.
ately makes source addresses from 2001:db8:0:b000::/52 unsuitable for external c An ISP-B uplink failure immediately makes source addresses from 2001:d
ommunication and might trigger a large number of ICMPv6 packets being sent to ho b8:0:b000::/52
sts in that subnet. unsuitable for external communication and might trigger a large
</t> number of ICMPv6 packets being sent to hosts in that subnet.
</t>
</section> </section>
<section anchor="sec_uplink_failed_summary" numbered="true" toc="default
<section anchor="sec_uplink_failed_summary" ">
title="Summary Of Methods For Controlling Default Source Addres <name>Summary of Methods for Controlling Default Source Address Select
s Selection On The Failure Of An Uplink"> ion on the Failure of an Uplink</name>
<t>It appears that DHCPv6 is not particularly well suited to quickly <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 changing the source address used by a host when an uplink
failure of an uplink, which eliminates DHCPv6 from the list of fails, which eliminates DHCPv6 from the list of
potential solutions. On the other hand Router Advertisements potential solutions. On the other hand, Router Advertisements
provides a reliable mechanism to dynamically provide hosts with a provide a reliable mechanism to dynamically provide hosts with a
list of valid prefixes to use as source addresses as well as prevent list of valid prefixes to use as source addresses as well as to preven
particular prefixes to be used. While no additional new features are t
the use of particular prefixes. While no additional new features are
required to be implemented on hosts, routers need to be able to send required to be implemented on hosts, routers need to be able to send
RAs based on the state of scoped forwarding tables entries and to RAs based on the state of scoped forwarding table entries and to
react to network topology changes by sending RAs with particular react to network topology changes by sending RAs with particular
parameters set.</t> parameters set.</t>
<t>It seems that the use of ICMPv6 Destination Unreachable messages ge
<t>The use of ICMPv6 Destination Unreachable messages generated by nerated by
the SER (or any SADR-capable) routers seem like they have the the SER (or any SADR-capable) routers, together with the use of RAs
potential to provide a support mechanism together with RAs to signal to signal source address selection errors back to hosts, has the
source address selection errors back to hosts, however scalability potential to provide a support mechanism. However, scalability issues
issues may arise in large networks in case of sudden topology may arise in large networks when topology suddenly changes.
change. Therefore it is highly desirable that hosts are able to Therefore, it is highly desirable that hosts are able to
select the correct source address in case of uplinks failure with select the correct source address in the case of uplink failure, with
ICMPv6 being an additional mechanism to signal unexpected failures ICMPv6 being an additional mechanism to signal unexpected failures
back to hosts.</t> back to hosts.</t>
<t>The current behaviors of different host operating systems upon rece
<t>The current behavior of different host operating system when ipt of
receiving ICMPv6 Destination Unreachable message with code 5 (Source an ICMPv6 Destination Unreachable message with Code 5 (Source
address failed ingress/egress policy) is not clear to the authors. address failed ingress/egress policy) is not clear to the authors.
Information from implementers, users, and testing would be quite Information from implementers, users, and testing would be quite
helpful in evaluating this approach.</t> helpful in evaluating this approach.</t>
</section> </section>
</section> </section>
<section anchor="sec_uplink_recover" numbered="true" toc="default">
<section anchor="sec_uplink_recover" <name>Selecting Default Source Address upon Failed Uplink Recovery</name
title="Selecting Default Source Address Upon Failed Uplink Recove >
ry">
<t>The next logical step is to look at the scenario when a failed <t>The next logical step is to look at the scenario when a failed
uplink on SERb1 to ISP-B is coming back up, so hosts can start using uplink on SERb1 to ISP-B comes back up, so the hosts can start using
source addresses belonging to 2001:db8:0:b000::/52 again.</t> source addresses belonging to 2001:db8:0:b000::/52 again.</t>
<section anchor="sec_uplink_recover_dhcpv6" numbered="true" toc="default
<section anchor="sec_uplink_recover_dhcpv6" ">
title="Controlling Default Source Address Selection With DHCPv6 <name>Controlling Default Source Address Selection with DHCPv6</name>
">
<t>The mechanism to use DHCPv6 to instruct the hosts (H31 in our <t>The mechanism to use DHCPv6 to instruct the hosts (H31 in our
example) to start using prefixes from ISP-B space (e.g. example) to start using prefixes from ISP-B space (e.g.,
S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is
quite similar to one discussed in <xref quite similar to one discussed in <xref target="sec_one_uplink_failed_
target="sec_one_uplink_failed_dhcpv6"/> and shares the same dhcpv6" format="default"/> and shares the same
drawbacks.</t> drawbacks.</t>
</section> </section>
<section anchor="sec_uplink_recover_ra" numbered="true" toc="default">
<section anchor="sec_uplink_recover_ra" <name>Controlling Default Source Address Selection with Router Adverti
title="Controlling Default Source Address Selection With Router sements</name>
Advertisements"> <t>Let's look at the scenario discussed in <xref target="sec_one_uplin
<t>Let's look at the scenario discussed in <xref k_failed_ra" format="default"/>.
target="sec_one_uplink_failed_ra"/>. If the uplink(s) failure caused If the uplink(s) failure caused
the complete withdrawal of prefixes from 2001:db8:0:b000::/52 the complete withdrawal of prefixes from the 2001:db8:0:b000::/52
address space by setting Preferred Lifetime value to 0, then the address space by setting the Preferred Lifetime value to zero, then th
recovery of the link should just trigger new RA being sent with e
non-zero Preferred Lifetime. In another scenario discussed in <xref recovery of the link should just trigger the sending of a new RA with
target="sec_one_uplink_failed_ra"/>, the SERb1 uplink to ISP-B a
failure leads to disappearance of the (S=2001:db8:0:b000::/52, non-zero Preferred Lifetime. In another scenario discussed in
<xref target="sec_one_uplink_failed_ra" format="default"/>, the failur
e
of the SERb1 uplink to ISP-B
leads to the disappearance of the (S=2001:db8:0:b000::/52,
D=::/0) entry from the forwarding table scoped to D=::/0) entry from the forwarding table scoped to
S=2001:db8:0:b000::/52 and, in turn, caused R3 to send RAs from S=2001:db8:0:b000::/52 and, in turn, causes R3 to send RAs
LLA_B with Router Lifetime set to 0. The recovery of the SERb1 with the Router Lifetime set to zero from LLA_B. The recovery of the S
uplink to ISP-B leads to (S=2001:db8:0:b000::/52, D=::/0) scoped ERb1 uplink to ISP-B leads to the reappearance
forwarding entry re-appearance and instructs R3 that it should of the scoped forwarding entry (S=2001:db8:0:b000::/52, D=::/0).
advertise itself as a default router for ISP-B address space domain That reappearance acts as a signal for R3 to advertise itself as
(send RAs from LLA_B with non-zero Router Lifetime).</t> a default router for ISP-B address space domain (to send RAs from LLA_B
with non-zero Router Lifetime).
</t>
</section> </section>
<section anchor="sec_uplink_recover_icmp" numbered="true" toc="default">
<name>Controlling Default Source Address Selection with ICMP</name>
<section anchor="sec_uplink_recover_icmp"
title="Controlling Default Source Address Selection With ICMP">
<t>It looks like ICMPv6 provides a rather limited functionality to <t>It looks like ICMPv6 provides a rather limited functionality to
signal back to hosts that particular source addresses have become signal back to hosts that particular source addresses have become
valid again. Unless the changes in the uplink state a particular valid again. Unless the changes in the uplink specify a particular
(S,D) pair, hosts can keep using the same source address even after (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 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 SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as
described in <xref target="sec_one_uplink_failed_icmp"/>) and described in <xref target="sec_one_uplink_failed_icmp" format="default "/>) and
allegedly started using (S=2001:db8:0:a010::31, allegedly started using (S=2001:db8:0:a010::31,
D=2001:db8:0:5678::501) to reach H501. Now when the SERb1 uplink 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 comes back up, the packets with that (S,D) pair are still routed to
SERa1 and sent to the Internet. Therefore H31 is not informed that SERa1 and sent to the Internet. Therefore, H31 is not informed that
it should stop using 2001:db8:0:a010::31 and start using 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 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 drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and
send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware send ICMPv6 back if the SERb1 uplink to ISP-B is up, H31 will be unawa re
of the network topology change and keep using S=2001:db8:0:a010::31 of the network topology change and keep using S=2001:db8:0:a010::31
for Internet destinations, including H51.</t> for Internet destinations, including H51.</t>
<t>One of the possible option may be using a scoped route with <t>One of the possible options may be using a scoped route with an
EXCLUSIVE flag as described in <xref EXCLUSIVE flag as described in <xref target="sec_both_working_icmpv6"
target="sec_both_working_icmpv6"/>. SERa1 uplink recovery would format="default"/>.
cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to SERa1 uplink recovery would
reappear in the routing table. In the absence of that route packets cause the (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to
to H101 which were sent to ISP-B (as ISP-A uplink was down) with reappear in the routing table. In the absence of that, route packets t
source addresses from 2001:db8:0:b000::/52. When the route o H101 are sent
re-appears SERb1 would reject those packets and sends ICMPv6 back as to ISP-B (as ISP-A uplink was down) with source addresses from 2001:db
discussed in <xref target="sec_both_working_icmpv6"/>. Practically 8:0:b000::/52.
it might lead to scalability issues which have been already When the route reappears, SERb1 rejects those packets and sends ICMPv6
discussed in <xref target="sec_both_working_icmpv6"/> and <xref back as
target="sec_uplink_recover_icmp"/>.</t> discussed in <xref target="sec_both_working_icmpv6" format="default"/>
. Practically,
it might lead to scalability issues, which have been already
discussed in <xref target="sec_both_working_icmpv6" format="counter"/>
and <xref target="sec_uplink_recover_icmp" format="counter"/>.</t>
</section> </section>
<section anchor="sec_uplink_recover_summary" numbered="true" toc="defaul
<section anchor="sec_uplink_recover_summary" t">
title="Summary Of Methods For Controlling Default Source Addres <name>Summary of Methods for Controlling Default Source Address Select
s Selection Upon Failed Uplink Recovery"> ion upon Failed Uplink Recovery</name>
<t>Once again DHCPv6 does not look like reasonable choice to <t>Once again, DHCPv6 does not look like a reasonable choice to
manipulate source address selection process on a host in the case of manipulate the source address selection process on a host in the case
of
network topology changes. Using Router Advertisement provides the network topology changes. Using Router Advertisement provides the
flexible mechanism to dynamically react to network topology changes flexible mechanism to dynamically react to network topology changes
(if routers are able to use routing changes as a trigger for sending (if routers are able to use routing changes as a trigger for sending
out RAs with specific parameters). ICMPv6 could be considered as a out RAs with specific parameters). ICMPv6 could be considered as a
supporting mechanism to signal incorrect source address back to supporting mechanism to signal incorrect source address back to
hosts but should not be considered as the only mechanism to control hosts, but it should not be considered as the only mechanism to contro l
the address selection in multihomed environments.</t> the address selection in multihomed environments.</t>
</section> </section>
</section> </section>
<section anchor="sec_all_uplinks_failed" numbered="true" toc="default">
<section anchor="sec_all_uplinks_failed" <name>Selecting Default Source Address When All Uplinks Have Failed</nam
title="Selecting Default Source Address When All Uplinks Failed"> e>
<t>One particular tricky case is a scenario when all uplinks have <t>One particular tricky case is a scenario when all uplinks have
failed. In that case there is no valid source address to be used for failed. In that case, there is no valid source address to be used for
any external destinations while it might be desirable to have any external destinations when it might be desirable to have
intra-site connectivity.</t> intra-site connectivity.</t>
<section anchor="sec_all_uplinks_failed_dhcpv6" numbered="true" toc="def
<section anchor="sec_all_uplinks_failed_dhcpv6" ault">
title="Controlling Default Source Address Selection With DHCPv6 <name>Controlling Default Source Address Selection with DHCPv6</name>
"> <t>From the DHCPv6 perspective, uplinks failure should be treated as t
<t>From DHCPv6 perspective uplinks failure should be treated as two wo
independent failures and processed as described in <xref independent failures and processed as described in
target="sec_one_uplink_failed_dhcpv6"/>. At this stage it is quite <xref target="sec_one_uplink_failed_dhcpv6" format="default"/>. At thi
obvious that it would result in quite complicated policy table which s stage, it is quite
needs to be explicitly configured by administrators and therefore obvious that it would result in a quite complicated policy table that
would need to be explicitly configured by administrators and therefore
seems to be impractical.</t> seems to be impractical.</t>
</section> </section>
<section anchor="sec_all_uplinks_failed_ra" numbered="true" toc="default
<section anchor="sec_all_uplinks_failed_ra" ">
title="Controlling Default Source Address Selection With Router <name>Controlling Default Source Address Selection with Router Adverti
Advertisements"> sements</name>
<t>As discussed in <xref target="sec_one_uplink_failed_ra"/> an <t>As discussed in <xref target="sec_one_uplink_failed_ra" format="def
ault"/>, an
uplink failure causes the scoped default entry to disappear from the uplink failure causes the scoped default entry to disappear from the
scoped forwarding table and triggers RAs with zero Router Lifetime. scoped forwarding table and triggers RAs with zero Router Lifetimes.
Complete disappearance of all scoped entries for a given source Complete disappearance of all scoped entries for a given source
prefix would cause the prefix being withdrawn from hosts by setting prefix would cause the prefix to be withdrawn from hosts by setting th
Preferred Lifetime value to zero in PIO. If all uplinks (SERa, SERb1 e
and SERb2) failed, hosts either lost their default routers and/or Preferred Lifetime value to zero in the PIO. If all uplinks (SERa, SER
b1
and SERb2) fail, hosts either lose their default routers and/or
have no global IPv6 addresses to use as a source. (Note that 'uplink have no global IPv6 addresses to use as a source. (Note that 'uplink
failure' might mean 'IPv6 connectivity failure with IPv4 still being failure' might mean 'IPv6 connectivity failure with IPv4 still being
reachable', in which case hosts might fall back to IPv4 if there is reachable', in which case, hosts might fall back to IPv4 if there is
IPv4 connectivity to destinations). As a result, intra-site IPv4 connectivity to destinations). As a result, intra-site
connectivity is broken. One of the possible way to solve it is to connectivity is broken. One of the possible ways to solve it is to
use ULAs.</t> use ULAs.</t>
<t>In addition to GUAs, all hosts have ULA addresses assigned, and the
<t>All hosts have ULA addresses assigned in addition to GUAs and se addresses are
used for intra-site communication even if there is no GUA assigned used for intra-site communication even if there is no GUA assigned
to a host. To avoid accidental leaking of packets with ULA sources to a host. To avoid accidental leaking of packets with ULA sources,
SADR-capable routers SHOULD have a scoped forwarding table for ULA SADR-capable routers <bcp14>SHOULD</bcp14> have a scoped forwarding ta
source for internal routes but MUST NOT have an entry for D=::/0 in ble for ULA
that table. In the absence of (S=ULA_Prefix; D=::/0) first-hop source for internal routes but <bcp14>MUST NOT</bcp14> have an entry f
or D=::/0 in
that table. In the absence of (S=ULA_Prefix; D=::/0), first-hop
routers will send dedicated RAs from a unique link-local source routers will send dedicated RAs from a unique link-local source
LLA_ULA with PIO from ULA address space, RIO for the ULA prefix and LLA_ULA with a PIO from ULA address space, a RIO for the ULA prefix, a
Router Lifetime set to zero. The behaviour is consistent with the nd
Router Lifetime set to zero. The behavior is consistent with the
situation when SERb1 lost the uplink to ISP-B (so there is no situation when SERb1 lost the uplink to ISP-B (so there is no
Internet connectivity from 2001:db8:0:b000::/52 sources) but those Internet connectivity from 2001:db8:0:b000::/52 sources), but those
sources can be used to reach some specific destinations. In the case sources can be used to reach some specific destinations. In the case
of ULA there is no Internet connectivity from ULA sources but they of ULA, there is no Internet connectivity from ULA sources, but they
can be used to reach another ULA destinations. Note that ULA usage can be used to reach other ULA destinations. Note that ULA usage
could be particularly useful if all ISPs assign prefixes via could be particularly useful if all ISPs assign prefixes via
DHCP-PD. In the absence of ULAs, upon the all uplinks failure hosts wo DHCP prefix delegation. In the absence of ULAs, upon the
uld lost all failure of all uplinks, hosts would lose all
their GUAs upon prefix lifetime expiration which again makes their GUAs upon prefix-lifetime expiration, which again makes
intra-site communication impossible.</t> intra-site communication impossible.</t>
<t> <t>
It should be noted that the Rule 5.5 (prefer a prefix advertised by the It should be noted that Rule 5.5 (prefer a prefix advertised by the sel
selected next-hop) ected next-hop)
takes precedence over the Rule 6 (prefer matching label, which ensures that GUA source addresses 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 us ed, the network are preferred over ULAs for GUA destinations). Therefore if ULAs are us ed, the network
administrator needs to ensure that while the site has an Internet conne administrator needs to ensure that, while the site has Internet connect
ctivity, hosts do not ivity, hosts do not
select a router which advertises ULA prefixes as their default router. select a router that advertises ULA prefixes as their default router.
</t> </t>
</section> </section>
<section anchor="sec_all_uplinks_failed_icmp" numbered="true" toc="defau
<section anchor="sec_all_uplinks_failed_icmp" lt">
title="Controlling Default Source Address Selection With ICMPv6 <name>Controlling Default Source Address Selection with ICMPv6</name>
"> <t>In the case of the failure of all uplinks, all SERs will drop outgo
<t>In case of all uplinks failure all SERs will drop outgoing IPv6 ing IPv6
traffic and respond with ICMPv6 error message. In the large network traffic and respond with ICMPv6 error messages. In a large network
when many hosts are trying to reach Internet destinations it means in which many hosts attempt to reach Internet destinations,
that SERs need to generate an ICMPv6 error to every packet they the SERs need to generate an ICMPv6 error for every packet they
receive from hosts which presents the same scalability issues receive from hosts, which presents the same scalability issues
discussed in <xref target="sec_one_uplink_failed_icmp"/></t> discussed in <xref target="sec_one_uplink_failed_icmp" format="default
"/>.</t>
</section> </section>
<section anchor="sec_all_uplinks_failed_summary" numbered="true" toc="de
<section anchor="sec_all_uplinks_failed_summary" fault">
title="Summary Of Methods For Controlling Default Source Addres <name>Summary of Methods for Controlling Default Source Address Select
s Selection When All Uplinks Failed"> ion When All Uplinks Failed</name>
<t>Again, combining SADR with Router Advertisements seems to be the <t>Again, combining SADR with Router Advertisements seems to be the
most flexible and scalable way to control the source address most flexible and scalable way to control the source address
selection on hosts.</t> selection on hosts.</t>
</section> </section>
</section> </section>
<section anchor="sec_sas_summary" numbered="true" toc="default">
<section anchor="sec_sas_summary" <name>Summary of Methods for Controlling Default Source Address Selectio
title="Summary Of Methods For Controlling Default Source Address n</name>
Selection"> <t>This section summarizes the scenarios and options discussed above.</t
<t>To summarize the scenarios and options discussed above:</t> >
<t>While DHCPv6 allows administrators to manipulate source address <t>While DHCPv6 allows administrators to manipulate source address
selection policy tables, this method has a number of significant selection policy tables, this method has a number of significant
disadvantages which eliminates DHCPv6 from a list of potential disadvantages that eliminate DHCPv6 from a list of potential
solutions:</t> solutions:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>It requires hosts to support DHCPv6 and its extension
<t>It required hosts to support DHCPv6 and its extension <xref target="RFC7078"/>.</li>
(RFC7078);</t> <li>A DHCPv6 server needs to monitor network state and detect routing
changes.</li>
<t>DHCPv6 server needs to monitor network state and detect routing <li>The use of policy tables requires manual configuration and might b
changes.</t> e extremely
complicated, especially in the case of a distributed network in whic
<t>The use of policy tables requires manual configuration and might h a large
be extremely number of remote sites are being served by centralized DHCPv6 server
complicated, especially in the case of distributed network when larg s.</li>
e <li>Network topology/routing policy changes could trigger
number of remote sites are being served by centralized DHCPv6 server simultaneous reconfiguration of large number of hosts, which
s.</t> presents serious scalability issues.</li>
</ol>
<t>Network topology/routing policy changes could trigger
simultaneous re-configuration of large number of hosts which
present serious scalability issues.</t>
</list></t>
<t>The use of Router Advertisements to influence the source address <t>The use of Router Advertisements to influence the source address
selection on hosts seem to be the most reliable, flexible and scalable selection on hosts seem to be the most reliable, flexible, and scalable
solution. It has the following benefits:</t> solution. It has the following benefits:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>No new (non-standard) functionality needs to be implemented on
<t>no new (non-standard) functionality needs to be implemented on hosts (except for RIO support <xref target="RFC4191" format="default
hosts (except for <xref target="RFC4191"/> RIO support, which remain "/>,
s at the time which is not widely implemented at the time of this writing).</li>
of this writing not widely implemented);</t> <li>No changes in RA format.</li>
<li>Routers can react to routing table changes by sending RAs, which
<t>no changes in RA format;</t>
<t>routers can react to routing table changes by sending RAs which
would minimize the failover time in the case of network topology would minimize the failover time in the case of network topology
changes;</t> changes.</li>
<li>Information required for source address selection is broadcast
<t>information required for source address selection is broadcast to all affected hosts in the case of a topology change event, which
to all affected hosts in case of topology change event which improves the scalability of the solution (compared to DHCPv6
improves the scalability of the solution (comparing to DHCPv6 reconfiguration or ICMPv6 error messages).</li>
reconfiguration or ICMPv6 error messages).</t> </ol>
</list></t>
<t>To fully benefit from the RA-based solution, first-hop routers need <t>To fully benefit from the RA-based solution, first-hop routers need
to implement SADR, belong to the SADR domain and be able to send dedicat to implement SADR, belong to the SADR domain, and be able to send dedica
ed RAs per scoped ted RAs per scoped
forwarding table as discussed above, reacting to network changes with forwarding table as discussed above, reacting to network changes by
sending new RAs. It should be noted that the proposed solution would 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 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 to send individual RAs for each ISP prefix and react to topology changes
as discussed above (e.g. via configuration knobs). </t> as discussed above (e.g., via configuration knobs). </t>
<t>The RA-based solution relies heavily on hosts correctly implementing <t>The RA-based solution relies heavily on hosts correctly implementing
default address selection algorithm as defined in <xref target="RFC6724" the default address selection algorithm as defined in <xref target="RFC6
/>. 724" format="default"/>.
While the basic (and most common) multihoming scenario (two or more Inte While the basic, and the most common, multihoming scenario (two or more
rnet Internet
uplinks, no 'walled gardens') would work for any host supporting the min imal uplinks, no 'walled gardens') would work for any host supporting the min imal
implementation of <xref target="RFC6724"/>, more complex use cases (such implementation of <xref target="RFC6724" format="default"/>, more comple
as x use cases (such as
"walled garden" and other scenarios when some ISP resources can only be 'walled garden' and other scenarios when some ISP resources can only be
reached from reached from
that ISP address space) require that hosts support Rule 5.5 of the defau lt address that ISP address space) require that hosts support Rule 5.5 of the defau lt address
selection algorithm. There is some evidence that not all host OSes selection algorithm. There is some evidence that not all host OSes
have that rule implemented currently. However it should be noted that have that rule implemented currently. However, it should be noted that
<xref target="RFC8028"/> states that Rule 5.5 should be implemented. <xref target="RFC8028" format="default"/> states that Rule 5.5 should be
implemented.
</t> </t>
<t>The ICMPv6 Code 5 error message <bcp14>SHOULD</bcp14> be used to comp
<t>ICMPv6 Code 5 error message SHOULD be used to complement RA-based lement an RA-based
solution to signal incorrect source address selection back to hosts, solution to signal incorrect source address selection back to hosts,
but it SHOULD NOT be considered as the stand-alone solution. but it <bcp14>SHOULD NOT</bcp14> be considered as the standalone solutio
To prevent scenarios when hosts in multihomed envinronments incorrectly n.
identify onlink/offlink destinations, hosts SHOULD treat ICMPv6 Redirect To prevent scenarios when hosts in multihomed environments incorrectly
s identify on-link/off-link destinations, hosts <bcp14>SHOULD</bcp14> trea
as discussed in <xref target="RFC8028"/>. </t> t ICMPv6 Redirects
as discussed in <xref target="RFC8028" format="default"/>. </t>
</section>
<section anchor="sec_conn_pre" title="Solution Limitations">
<section anchor="sec_conn_pre_1" title="Connections Preservation">
<t>
The proposed solution is not designed to preserve connection sta
te in case of an uplink failure. When all uplinks to an ISP go down all transpor
t connections established to/from that ISP address space will be interrupted (un
less the transport protocol has specific multihoming support). That behaviour is
similar to the scenario of IPv4 multihoming with NAT when an uplink failure cau
ses all connections to be NATed to completely different public IPv4 addresses. W
hile it does sound suboptimal, it is determined by the nature of PA address spac
e: if all uplinks to the particular ISP have failed, there is no path for the in
gress traffic to reach the site and the egress traffic is supposed to be dropped
by the <xref target="RFC2827">BCP38</xref> ingress filters. The only potential
way to overcome this limitation would be running BGP with all ISPs and advertise
all site prefixes to all uplinks - a solution which shares all drawbacks of usi
ng PI address space without having 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 case of IPv4 NAT-based multihoming up
link recovery could cause connection interruptions as well (unless packet forwar
ding is integrated with existing NAT sessions tracking so the egress interface f
or the existing sessions is not changed). However the proposed solution has a be
nefit of preserving the existing sessions during/after the failed uplink restora
tion. Unlike the uplink failure event which causes all addresses from the affect
ed prefix to be deprecated the recovery would just add new preferred addresses t
o a host without making any addresses unavailable. Therefore connections estavli
shed to/from those addresses do not have to be interrupted.
</t>
<t>
While it's desirable for active connections to survive ISP failo
ver events, for sites using PA address space such events affect the reachability
of IP addresses assigned to hosts. Unless the transport (or even higher level p
rotocols) are capable of suviving the host renumbering, the active connections w
ill be broken. The proposed solution focuses on minimizing the impact of failove
r for new connections and for multipath-aware protocols.
</t>
<t>
Another way to preserve connection state would be using multipath
transport as discussed in <xref target="sec_mpath"/>.
</t>
</section> </section>
<section anchor="sec_conn_pre" numbered="true" toc="default">
<name>Solution Limitations</name>
<section anchor="sec_conn_pre_1" numbered="true" toc="default">
<name>Connections Preservation</name>
<t>
The proposed solution is not designed to preserve connection sta
te in the
case of an uplink failure. When all uplinks to an ISP go down, all transport con
nections
established to/from that ISP address space will be interrupted (unless the trans
port
protocol has specific multihoming support). That behavior is similar to the scen
ario
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, i
t is
determined by the nature of PA address space: if all uplinks to the particular I
SP
have failed, there is no path for the ingress traffic to reach the site, and the
egress
traffic is supposed to be dropped by the ingress filters <xref target="RFC2827"
format="default"/>.
The only potential way to overcome this limitation would be to run BGP with all
ISPs
and to advertise all site prefixes to all uplinks - a solution that shares all t
he drawbacks
of using the PI address space without 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 multihomin
g, uplink
recovery could cause connection interruptions as well (unless packet forwarding
is
integrated with the tracking of existing NAT sessions so that the egress interfa
ce for the existing
sessions is not changed). However, the proposed solution has the benefit of pres
erving
the existing sessions during and after the restoration of the failed uplink. Unl
ike the uplink
failure event, which causes all addresses from the affected prefix to be depreca
ted,
the recovery would just add new, preferred addresses to a host without making an
y
addresses unavailable. Therefore, connections established to and from those addr
esses
do not have to be interrupted.
</t>
<t>
While it's desirable for active connections to survive ISP failo
ver events,
such events affect the reachability of IP addresses assigned to hosts in sites u
sing
PA address space. Unless the transport (or higher-level protocols) is capable
of surviving the host renumbering, the active connections will be broken. The pr
oposed
solution focuses on minimizing the impact of failover on new connections and on
multipath-aware protocols.
</t>
<t>
Another way to preserve connection state is to use multipath
transport as discussed in <xref target="sec_mpath" format="default"/>.
</t>
</section> </section>
</section>
<section anchor="sec_other_params" numbered="true" toc="default">
<name>Other Configuration Parameters</name>
<section anchor="sec_dns" numbered="true" toc="default">
<name>DNS Configuration</name>
<t>In 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" format="default"/>, ISP-A might provide
H51 2001:db8:0:5555::51 as a recursive DNS server, while ISP-B might pro
vide
H61 2001:db8:0:6666::61 as a recursive DNS server (RDNSS).
<xref target="RFC8106" format="default"/> defines IPv6 Router Advertisem
ent options to allow
IPv6 routers to advertise a list of 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 <xref target="f
ig_isp_service" format="default"/>) to send
DNS server addresses and search lists provided by each ISP (or the corpo
rate DNS server
addresses if the enterprise is running its own DNS servers. As discussed
below, the DNS
split-horizon problem is too hard to solve without running a local DNS s
erver).</t>
<section anchor="sec_other_params" title="Other Configuration Parameters"> <t>As discussed in <xref target="sec_all_uplinks_failed_ra" format="de
<section anchor="sec_dns" title="DNS Configuration"> fault"/>, failure of all ISP uplinks
<t>In mutihomed envinronment each ISP might provide their own list of
DNS servers. For example, in the topology shown in <xref target="fig_isp
_service"/>, ISP-A might provide
recursive DNS server H51 2001:db8:0:5555::51, while ISP-B might provide
H61 2001:db8:0:6666::61 as a recursive DNS server.
<xref target="RFC8106"/> defines IPv6 Router Advertisement options to al
low
IPv6 routers to advertise a list of DNS recursive server addresses
and a DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped'
RAs
as described above would allow a first-hop router (R3 in the <xref targe
t="fig_isp_service"/>) to send
DNS server addresses and search lists provided by each ISP (or the corpo
rate DNS servers
addresses if the enterprise is running its own DNS servers - as discusse
d below DNS split-horizon problem is to hard to solve without running a local DN
S server).</t>
<t>As discussed in <xref target="sec_all_uplinks_failed_ra"/>, failure o
f all ISP uplinks
would cause deprecation of all addresses assigned to a host from the add ress space would cause deprecation of all addresses assigned to a host from the add ress space
of all ISPs. of all ISPs.
If any intra-site IPv6 connectivity is still desirable (most likely to b e the case for If any intra-site IPv6 connectivity is still desirable (most likely to b e the case for
any mid/large scare network), then ULAs should be used as discussed in < any mid/large-scale network), then ULAs should be used as discussed in
xref target="sec_all_uplinks_failed_ra"/>. <xref target="sec_all_uplinks_failed_ra" format="default"/>.
In such a scenario, the enterprise network should run its own recursive In such a scenario, the enterprise network should run its own
DNS server(s) and provide recursive DNS server(s) and provide its ULA addresses to hosts via
its ULA addresses to hosts via RDNSS in RAs send for ULA-scoped forwardi RDNSS in RAs sent for ULA-scoped
ng table as described in <xref target="sec_all_uplinks_failed_ra"/>.</t> forwarding table as described in <xref
target="sec_all_uplinks_failed_ra" format="default"/>.</t>
<t>There are some scenarios when the final outcome of the name resolutio <t>There are some scenarios in which the final outcome of the name res
n might be different olution might be different
depending on:</t> depending on:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>which DNS server is used;</t> <li>which DNS server is used;</li>
<t>which source address the client uses to send a DNS query to the serve <li>which source address the client uses to send a DNS query to the
r (DNS split horizon).</t> server (DNS split horizon).</li>
</list></t> </ul>
<t>There is no way currently to instruct a host to use a particular DN
<t>There is no way currently to instruct a host to use a particular DNS S server from the configured servers list
server out of the configured servers list for resolving a particular name. Therefore, it does not seem feasible to
for resolving a particular name. Therefore it does not seem feasible to solve the problem of DNS server selection
solve the problem of DNS server selection
on the host (it should be noted that this particular issue is protocol-a gnostic and happens for IPv4 as well). In such on the host (it should be noted that this particular issue is protocol-a gnostic and happens for IPv4 as well). In such
a scenario it is recommended that the enterprise runs its own local recu a scenario, it is recommended that the enterprise run its own local recu
rsive DNS server.</t> rsive DNS server.</t>
<t>To influence host source address selection for packets sent to a pa
<t>To influence host source address selection for packets sent to a part rticular DNS server,
icular DNS server
the following requirements must be met: the following requirements must be met:
<list style="symbols"> </t>
<t> the host supports RIO as defined in <xref target="RFC4191"/>;</t> <ul spacing="normal">
<t> the routers send RIO for routes to DNS server addresses.</t> <li>The host supports RIO as defined in <xref target="RFC4191" forma
</list> t="default"/>.</li>
<li>The routers send RIOs for routes to DNS server addresses.</li>
</ul>
<t>
For example, if it is desirable that host H31 reaches the ISP-A DNS serv er H51 2001:db8:0:5555::51 For example, if it is desirable that host H31 reaches the ISP-A DNS serv er H51 2001:db8:0:5555::51
using its source address 2001:db8:0:a010::31, then both R1 and R2 should using its source address 2001:db8:0:a010::31, then both R1 and R2 should
send the RIO containing the route to 2001:db8:0:5555::51 send RIOs containing the route to 2001:db8:0:5555::51
(or covering route) in their 'scoped' RAs, containing LLA_A as th (or covering route) in their 'scoped' RAs, containing LLA_A as th
e default router address and the PO for SLAAC prefix 2001:db8:0:a010::/64. e default router address and the PIO for SLAAC prefix 2001:db8:0:a010::/64.
In that case the host H31 (if it supports the Rule 5.5) would sel In that case, host H31 (if it supports Rule 5.5) would select LLA
ect LLA_A as a next-hop and then chose 2001:db8:0:a010::31 as the source address _A as a next-hop and then choose 2001:db8:0:a010::31 as the source address
for packets to the DNS server. for packets to the DNS server.
</t> </t>
<t>It should be noted that <xref target="RFC6106" format="default"/> e
<t>It should be noted that <xref target="RFC6106"/> explicitly prohibits xplicitly prohibits using DNS information if the RA Router Lifetime
using DNS information if the RA router Lifetime has expired:</t>
expired: "An RDNSS address or a DNSSL domain name MUST be used only as <blockquote>An RDNSS address or a DNSSL domain name <bcp14>MUST</bcp14> be used
only as
long as both the RA router Lifetime (advertised by a Router long as both the RA router Lifetime (advertised by a Router
Advertisement message) and the corresponding option Advertisement message) and the corresponding option
Lifetime have not expired.". Therefore hosts might ignore RDNSS informat Lifetime have not expired.
ion provided </blockquote>
in ULA-scoped RAs as those RAs would have router lifetime set to 0. Howe <t>Therefore, hosts might ignore RDNSS information provided
ver the updated version of in ULA-scoped RAs, as those RAs would have Router Lifetime values set
RFC6106 (<xref target="RFC8106"/>) has that requirement removed. to zero. However, <xref target="RFC8106" format="default"/>, which
obsoletes RFC 6106, has removed that requirement.
</t> </t>
<t> <t>
As discussed above the DNS split-horizon problem and selecting the correc As discussed above, the DNS split-horizon problem and the selection of th
t DNS server in a multihomed envinroment is not an easy one to solve. The proper e correct
solution would require hosts to support the concept of multiple Provisioning DNS server in a multihomed environment are not easy problems to solve. The prope
Domains (PvD, a set of configuration information associated with a r solution would
network, <xref target="RFC7556"/>). require hosts to support the concept of multiple provisioning domains (PvD, a se
t of
configuration information associated with a network, <xref target="RFC7556" form
at="default"/>).
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec_deployment" 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
SADR. It also requires hosts to be able to learn when the uplink to an I
SP changes
its state so that the hosts can use appropriate source addresses. Ongoi
ng work to create
mechanisms to accomplish this are discussed in this document, but they
are still works in progress.
</t>
<section anchor="sec_sadr_depl" numbered="true" toc="default">
<name>Deploying SADR Domain</name>
<section anchor="sec_deployment" title="Deployment Considerations"> <t>
<t> The proposed solution does not prescribe particular details regarding dep
The solution described in this document requires certain mechanis loying an SADR domain within a multihomed enterprise network. However the follow
ms to ing guidelines could be applied:
be supported by the network infrastructure and hosts. It requires </t>
some <ul spacing="normal">
routers in the enterprise site to support some form of Source Add <li>The SADR domain is usually limited by the multihomed site border.<
ress /li>
Dependent Routing (SADR). It also requires hosts to be able to le <li>The minimal deployable scenario requires enabling SADR on all SERs
arn and including them into a single SADR domain.</li>
when the uplink to an ISP changes its state so the corresponding
source
addresses should (or should not) be used. Ongoing work to create
mechanisms to accomplish this are discussed in this document, but
they
are still a work in progress.
</t>
<section anchor="sec_sadr_depl" title="Deploying SADR Domain">
<t>
The proposed solution provides does not prescribe particu
lar details regarding deploying an SADR domain within a multihomed enterprise ne
twork. However the following guidelines could be applied:
<list style="symbols">
<t>The SADR domain is usually limited by the mult
ihomed site border.</t>
<t>The minimal deployable scenario requires enabl
ing SADR on all SERs and including them into a single SADR domain.</t>
<t>As discussed in <xref target="sec_simple_not_d
ir_conn"/>, extending the connected SADR domain beyond that point down to the fi
rst-hop routers can produce more efficient forwarding paths and allow the networ
k to fully benefit from SADR. it would also simplify the operation of the SADR d
omain.</t>
<t>
During the incremental SADR domain expans
ion from the SERs down towards first-hop routers it's important to ensure that a
t any moment of time all SADR-capable routers within the domain are logically co
nnected (see <xref target="sec_method"/>).
</t>
</list> <li>As discussed in <xref target="sec_simple_not_dir_conn" format="def
</t> ault"/>, extending the connected SADR domain beyond the SERs to the first-hop ro
</section> uters can produce more efficient forwarding paths and allow the network to fully
<section anchor="sec_host" title="Hosts-Related Considerations"> benefit from SADR. It would also simplify the operation of the SADR domain.</li
<t> >
<li>During the incremental SADR domain expansion from the SERs down to
wards first-hop routers, it's important to ensure that, at any given moment, all
SADR-capable routers within the domain are logically connected (see <xref targe
t="sec_method" format="default"/>).</li>
</ul>
</section>
<section anchor="sec_host" numbered="true" toc="default">
<name>Hosts-Related Considerations</name>
<t>
The solution discussed in this document relies on the default add ress The solution discussed in this document relies on the default add ress
selection algorithm (<xref target="RFC6724"/>) Rule 5.5. While <x selection algorithm, Rule 5.5 <xref target="RFC6724" format="defa
ref ult"/>.
target="RFC6724"/> considers this rule as optional, the recent <x While <xref target="RFC6724" format="default"/> considers this r
ref ule as optional, the
target="RFC8028"/> states that "A host SHOULD select default rout more recent <xref target="RFC8028" format="default"/> states tha
ers for each prefix it is t
assigned an address in". It also recommends "A host <bcp14>SHOULD</bcp14> select default routers for each pr
that hosts should implement Rule 5.5. of <xref target="RFC6724"/> efix it is
. assigned an address in." It also recommends
Therefore while RFC8028-compliant hosts already have mechanism to that hosts should implement Rule 5.5. of <xref target="RFC6724" f
learn ormat="default"/>.
about ISP uplinks state changes and selecting the source addresse Therefore, while hosts compliant with RFC 8028 already have a mec
s hanism to learn
accordingly, many hosts do not have such mechanism supported yet. about state changes to ISP uplinks and to select the source addre
</t> sses
<t> accordingly, many hosts do not support such a mechanism yet.
It should be noted that multihomed enterprise network utilizing </t>
<t>
It should be noted that a multihomed enterprise network utilizing
multiple ISP prefixes can be considered as a typical multiple multiple ISP prefixes can be considered as a typical multiple
provisioning domain (mPVD) scenario, as described in <xref provisioning domain (mPvD) scenario, as described in <xref target
target="RFC7556"/>. This document defines a way for the network t ="RFC7556" format="default"/>.
o provide This document defines a way for the network to provide
the PVD information to hosts indirectly, using the existing mecha the PvD information to hosts indirectly, using the existing mecha
nisms. nisms.
At the same time <xref At the same time, <xref target="I-D.ietf-intarea-provisioning-dom
target="I-D.ietf-intarea-provisioning-domains"/> takes one step f ains" format="default"/> takes one step further
urther
and describes a comprehensive mechanism for hosts to discover the whole and describes a comprehensive mechanism for hosts to discover the whole
set of configuration information associated with different PVD/IS set of configuration information associated with different PvDs/I
Ps. SPs.
<xref target="I-D.ietf-intarea-provisioning-domains"/> complement <xref target="I-D.ietf-intarea-provisioning-domains" format="defa
s this ult"/> complements this
document in terms of making hosts being able to learn about ISP u document in terms of enabling hosts to learn about ISP uplink
plink states and to select the corresponding source addresses.
states and selecting the corresponding source addresses. </t>
</t> </section>
</section>
</section> </section>
<section anchor="sec_other_solutions" title="Other Solutions"> <section anchor="sec_other_solutions" numbered="true" toc="default">
<section anchor="sec_shim6" title="Shim6"> <name>Other Solutions</name>
<t>The Shim6 working group specified the Shim6 protocol <xref <section anchor="sec_shim6" numbered="true" toc="default">
target="RFC5533"/> which allows a host at a multihomed site to <name>Shim6</name>
communicate with an external host and exchange information about <t>The Shim6 protocol <xref target="RFC5533" format="default"/>, specifi
ed by the Shim6
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 possible source and destination address pairs that they can use to
communicate. It also specified the REAP protocol <xref communicate. The Shim6 working group also specified the REAchability Pro
target="RFC5534"/> to detect failures in the path between working tocol
address pairs and find new working address pairs. A fundamental (REAP) <xref target="RFC5534" format="default"/> to detect failures in t
he 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 requirement for Shim6 is that both internal and external hosts need to
support Shim6. That is, both the host internal to the multihomed site 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 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. 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 The Shim6 protocol specification was published in 2009, but it has not
been widely implemented. Therefore Shim6 is not considered as a viable so lution been widely implemented. Therefore Shim6 is not considered as a viable so lution
for enterprise multihoming.</t> for enterprise multihoming.</t>
</section> </section>
<section anchor="sec_nptv6" numbered="true" toc="default">
<section anchor="sec_nptv6" <name>IPv6-to-IPv6 Network Prefix Translation</name>
title="IPv6-to-IPv6 Network Prefix Translation"> <t>IPv6-to-IPv6 Network Prefix Translation (NPTv6) <xref target="RFC6296
<t>IPv6-to-IPv6 Network Prefix Translation (NPTv6) <xref " format="default"/> is not the focus of this document.
target="RFC6296"/> is not the focus of this document. NPTv6 suffers from the same fundamental issue as any other approa
NPTv6 suffers from the same fundamental issue as any other addres ches to address
s translation: it breaks end-to-end connectivity. Therefore
translation approaches: it breaks end-to-end connectivity. Theref NPTv6 is not considered as a desirable solution, and this documen
ore t intentionally
NPTv6 is not considered as desirable solution and this document i focuses on solving the enterprise multihoming problem without any
ntentionally form of address translation.
focuses on solving enterprise multihoming problem without any for </t>
m of address translations. <t>
</t>
<t>
With increasing interest and ongoing work in bringing path aware ness to With increasing interest and ongoing work in bringing path aware ness to
transport and application layer protocols hosts might be able to transport- and application-layer protocols, hosts might be able t o
determine the properties of the various network paths and choose among determine the properties of the various network paths and choose among
paths available to them. As selecting the correct source address the paths that are available to them. As selecting the correct so
is one urce address is one
of the possible mechanisms path-aware hosts may utilize, address of the possible mechanisms that path-aware hosts may utilize, add
translation negatively affects hosts path-awareness which makes N ress
TPv6 translation negatively affects hosts' path-awareness, which makes
even more undesirable solution. NTPv6
an even more undesirable solution.
</t> </t>
</section> </section>
<section anchor="sec_mpath" <section anchor="sec_mpath" numbered="true" toc="default">
title="Multipath Transport"> <name>Multipath Transport</name>
<t> <t>
Using multipath transport (such as MPTCP, <xref target="RFC Using multipath transport (such as Multipath TCP (MPTCP) <xref targ
6824"/> or multipath capabilities in QUIC) might solve the problems discussed i et="RFC6824" format="default"/>
n <xref or multipath capabilities in QUIC) might solve the problems discus
target="sec_host_mechanisms"/> since it would allow hosts sed in
to use multiple <xref target="sec_host_mechanisms" format="default"/> since a mult
source addresses for a single connection and switch betwe ipath
en source transport would allow hosts to use multiple
source addresses for a single connection and to switch be
tween those source
addresses when a particular address becomes unavailable o r a new address addresses when a particular address becomes unavailable o r a new address
gets assigned to the host interface. Therefore if all hos is assigned to the host interface. Therefore, if all host
ts in the s in the
enterprise network are only using multipath transport for enterprise network use only multipath transport for all
all connections, the signaling solution described in
connections, the signaling solution described in <xref <xref target="sec_host_mechanisms" format="default"/> mi
target="sec_host_mechanisms"/> might not be needed (it sh ght not be needed (it should be noted
ould be noted that Source Address Dependent Routing would still be requ
that the Source Address Dependent Routing would still be ired to
required to
deliver packets to the correct uplinks). deliver packets to the correct uplinks).
At the time this document was written, multipath transpor t alone At the time this document was written, multipath transpor t alone
could not be considered a solution for the problem of sel ecting the source could not be considered a solution for the problem of sel ecting the source
address in a multihomed environment. There are significan address in a multihomed environment. There are a signific
t number of ant number of
hosts which do not use multipath transport currently and hosts that do not use multipath transport currently, and
it seems it seems
unlikely that the situation is going to change in any for unlikely that the situation will change in the foreseeabl
eseeable e
future (even if new releases of operatin systems get mult future (even if new releases of operating systems support
ipath protocols support there will be a long tail of legacy hosts). The solution multipath protocols,
for enterprise multihoming needs to work for the 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 transpo rt support. In least common denominator: hosts without multipath transpo rt support. In
addition, not all protocols are using multipath transport . While addition, not all protocols are using multipath transport . While
multipath transport would complement the solution describ multipath transport would complement the solution describ
ed in <xref ed in <xref target="sec_host_mechanisms" format="default"/>, it could not be con
target="sec_host_mechanisms"/>, it could not be considere sidered as a sole
d as a sole
solution to the problem of source address selection in mu ltihomed solution to the problem of source address selection in mu ltihomed
environments. environments.
</t> </t>
<t> <t>
On the other hand PA-based multihoming could provide addi On the other hand, PA-based multihoming could provide add
tional benefits for multipath protocol, itional
should those protocols be deployed in the network. Multip benefits to multipath protocols, should those protocols be deployed in the netwo
ath protocols could leverage source address selection to achieve maximum path di rk. Multipath
versity (and potentially improved performance). protocols could leverage source address selection to achieve maximum path divers
</t> ity (and potentially improved performance).
<t> </t>
Therefore deploying multipath protocols could not be cons <t>
idered as an alternative to the approach proposed in this document. Instead both Therefore, the deployment of multipath protocols should n
solutions complement each other so deploying multipath protocols in PA-based mu ot be considered
ltihomed network proves mutually beneficial. as an alternative to the approach proposed in this document. Instead, both solut
</t> ions complement
each other, so deploying multipath protocols in a PA-based multihomed network pr
oves mutually beneficial.
</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This memo asks the IANA for no new parameters.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <xref target="sec_both_working_icmpv6" format="default"/> discusses a
<t> <xref target="sec_both_working_icmpv6"/> discusses a mechanis mechanism for
m for
controlling source address selection on hosts using ICMPv 6 messages. controlling source address selection on hosts using ICMPv 6 messages.
Using ICMPv6 to influence source address selection allows an attacker to exhaust the list of candidate source 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 addresses on the host by sending spoofed ICMPv6 Code 5 for all
prefixes known on the network (therefore preventing a victim from prefixes known on the network (therefore preventing a victim from
establishing a communication with the destination host). establishing communication with the destination host).
Another possible attack vector is using ICMPv6 Destination Unreachable Another possible attack vector is using ICMPv6 Destination Unreachable
Messages with Code 5 to steer the egress tra Messages with Code 5 to steer the egress
ffic towards the particular ISP (for example if the attacker has the ability of traffic towards the particular ISP, so the attacker can benefit from
doing traffic sniffing or man-in-the-middle attack in that ISP network). their ability doing traffic sniffing/interception
</t> in that ISP network.</t>
<t> <t>
To prevent those attacks hosts SHOULD verify that the original packet h To prevent those attacks, hosts <bcp14>SHOULD</bcp14> verify that the o
eader included into ICMPv6 error message was actually sent by the host (to ensur riginal packet
e that the ICMPv6 message was triggered by a packet sent by the host). header included in the ICMPv6 error message was actually sent by the host (to en
</t> sure that the
<t> ICMPv6 message was triggered by a packet sent by the host).
As ICMPv6 Destination Unreachable Messages with Code 5 could be origina </t>
ted by any SADR-capable router within the domain (or even come from the Internet <t>
), GTSM (<xref target="RFC5082"/>) can not be applied. Filtering such ICMOv6 mes As ICMPv6 Destination Unreachable Messages with Code 5 could be origina
sages at the site border can not be recommended as it would break the legitimate ted by any
end2end error signalling mechanism ICMPv6 is designed for. SADR-capable router within the domain (or even come from the Internet), the Gene
</t> ralized TTL
<t> Security Mechanism (GTSM) <xref target="RFC5082" format="default"/> cannot be ap
The security considerations of using stateless address autoco plied.
nfiguration are discussed in <xref target="RFC4862"/>. Filtering such ICMPv6 messages at the site border cannot be recommended as it wo
</t> uld break
the legitimate end-to-end error signaling mechanism for which ICMPv6 was designe
</section> d.
</t>
<section anchor="Acknowledgements" title="Acknowledgements"> <t>
<t>The original outline was suggested by Ole Troan.</t> The security considerations of using stateless address autoco
<t> nfiguration are discussed in <xref target="RFC4862" format="default"/>.
The authors would like to thank the following people (in alph </t>
abetical order) for their review and feedback:
Olivier Bonaventure, Deborah Brungard, Brian E Carpenter,
Lorenzo Colitti, Roman Danyliw, Benjamin Kaduk, Suresh Krishn
an, Mirja Kuhlewind,
David Lamparter, Nicolai Leymann, Acee Lindem, Philip Matthew
su, Robert Raszuk, Alvaro Retana, Pete Resnick, Dave Thaler, Michael Tuxen, Mart
in Vigoureux, Eric Vyncke, Magnus Westerlund.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- references split to informative and normative --> <displayreference target="I-D.pfister-6man-sadr-ra" to="SADR-RA"/>
<displayreference target="I-D.ietf-rtgwg-dst-src-routing" to="DST-SRC-RTG"/>
<references title="Normative References"> <displayreference target="I-D.ietf-intarea-provisioning-domains" to="PROV-DO
<?rfc include="reference.RFC.2827" ?> MAINS"/>
<displayreference target="RFC2827" to="BCP38"/>
<?rfc include="reference.RFC.4193" ?> <references>
<name>References</name>
<?rfc include="reference.RFC.6296" ?> <references>
<name>Normative References</name>
<?rfc include="reference.RFC.1918" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2827.xml"/>
<?rfc include="reference.RFC.2119"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4193.xml"/>
<?rfc include="reference.RFC.8415" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6296.xml"/>
<?rfc include="reference.RFC.4191" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4291" ?> ence.RFC.1918.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.6106" ?> ence.RFC.2119.xml"/>
<?rfc include="reference.RFC.8106" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8415.xml"/>
<?rfc include="reference.RFC.7556" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4191.xml"/>
<?rfc include="reference.RFC.8028" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.8174" ?> ence.RFC.4291.xml"/>
<?rfc include="reference.RFC.4443" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4861" ?> ence.RFC.6106.xml"/>
<?rfc include="reference.RFC.4862" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.6724" ?> ence.RFC.8106.xml"/>
<?rfc include="reference.RFC.7078" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7556.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8028.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4443.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4861.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4862.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6724.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.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/refe
rence.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/refe
rence.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/refe
rence.I-D.ietf-intarea-provisioning-domains.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5533.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5534.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5082.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8504.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4941.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7676.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3704.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6824.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2663.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8425.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<references title="Informative References"> <name>Acknowledgements</name>
<?rfc include="reference.I-D.pfister-6man-sadr-ra" ?> <t>The original outline was suggested by <contact fullname="Ole Trøan"/>.<
/t>
<?rfc include="reference.I-D.ietf-rtgwg-dst-src-routing" ?> <t>
The authors would like to thank the following people (in alphabetical order)
<?rfc include="reference.I-D.ietf-intarea-provisioning-domains" ?> for their review and feedback:
<contact fullname="Olivier Bonaventure"/>, <contact
<?rfc include="reference.RFC.5533" ?> fullname="Deborah Brungard"/>, <contact fullname="Brian E.&nbsp;Carpenter"/>
,
<?rfc include="reference.RFC.5534" ?> <contact fullname="Lorenzo Colitti"/>, <contact fullname="Roman
<?rfc include="reference.RFC.5082" ?> Danyliw"/>, <contact fullname="Benjamin Kaduk"/>, <contact
<?rfc include="reference.RFC.6434" ?> fullname="Suresh Krishnan"/>, <contact fullname="Mirja Kühlewind"/>,
<contact fullname="David Lamparter"/>, <contact fullname="Nicolai
<?rfc include="reference.RFC.4941" ?> Leymann"/>, <contact fullname="Acee Lindem"/>, <contact
<?rfc include="reference.RFC.7676" ?> fullname="Philip Matthews"/>, <contact fullname="Robert
Raszuk"/>, <contact fullname="Alvaro Retana"/>, <contact
<?rfc include="reference.RFC.3704" ?> fullname="Pete Resnick"/>, <contact fullname="Dave Thaler"/>,
<?rfc include="reference.RFC.6824" ?> <contact fullname="Michael Tüxen"/>, <contact fullname="Martin
</references> Vigoureux"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Magnu
s Westerlund"/>.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 365 change blocks. 
1541 lines changed or deleted 1531 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/