One document matched: draft-baker-6man-multi-homed-host-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-6man-multi-homed-host-02"
ipr="trust200902">
<front>
<title abbrev="Host routing in a multi-prefix network">Host routing in a
multi-prefix network</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
<organization abbrev="Univ. of Auckland"/>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region/>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>IPv6 Maintenance</workgroup>
<abstract>
<t>This note describes expected host behavior in a network that has more
than one prefix, each allocated by an upstream network that implements
BCP 38 filtering, when the host has multiple routers to choose from.</t>
<t>This may interact with source address selection in a given
implementation, but logically follows it - given that the network or
host is or appears to be multihomed with PA addresses, the host has
elected to use source address in a given prefix, and some but not all
neighboring routers are advertising that prefix in their RA PIOs, to
which router should a host present its transmission?</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>This note describes the expected behavior of an <xref
target="RFC2460">IPv6</xref> host in a network that has more than one
prefix, each allocated by an upstream network that implements <xref
target="RFC2827">BCP 38</xref> filtering, and in which the host is
presented with a choice of routers. It expects that the network will
implement some form of egress routing, so that packets sent to a host
outside the local network from a given ISP's prefix will go to that ISP.
If the packet is sent to the wrong egress, it is liable to be discarded
by the BCP 38 filter. However, the mechanics of egress routing once the
packet leaves the host are out of scope. The question here is how the
host interacts with that network.</t>
<t>Note that, apart from ensuring that a message with a given source
address is given to a first-hop router that appears to know about the
prefix in question, this specification provides no new guidance over
that in <xref target="RFC4861"/>.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
</section>
<section title="Sending context expected by the host">
<section anchor="host_expects"
title="Expectations the host has of the network">
<t>A host receives prefixes in a <xref target="RFC4861">Router
Advertisement</xref>, which goes on to identify whether they are
usable by <xref target="RFC4862">SLAAC</xref> <xref target="RFC4941"/>
<xref target="RFC7217"/>. When no prefixes are usable for SLAAC, the
Router Advertisement would normally signal the availability of <xref
target="RFC3315">DHCPv6</xref> and the host would use it to configure
its addresses. In the latter case (or if both SLAAC and DHCPv6 are
used on the same link for some reason) it will be generally the case
that the configured addresses match one of the prefixes advertised in
a Router Advertisement that are supposed to be in that link.</t>
<t>The simplest multihomed network implementation in which a host
makes choices among routers might be a LAN with one or more hosts on
it and two or more routers, one for each upstream network, or a host
that is served by disjoint networks on separate interfaces. In such a
network, especially the latter, there is not necessarily a routing
protocol, and the two routers may not even know that the other is a
router as opposed to a host, or may be configured to ignore its
presence. One might expect that the routers may or may not receive
each other's RAs and form an address in the other router's prefix
(which is not per <xref target="RFC4862"/>, but is implemented by some
stub router implementations). However, all hosts in such a network
might be expected to create an address in each prefix so
advertised.</t>
<figure anchor="simple" title="Two simple networks">
<artwork align="center"><![CDATA[+---------+ +---------+ +---------+ +---------+
| ISP | | ISP | | ISP | | ISP |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| Router | | Router | | Router | | Router |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
+------+------+ | +--------+ |
| +--+ Host +--+
+----+----+ +--------+
| Host |
+---------+
Common LAN Case Disjoint LAN Case
(Multihomed Network) (Multihomed Host)
]]></artwork>
</figure>
<t>If there is no routing protocol among those routers, there is no
mechanism by which packets can be deterministically forwarded between
the routers (as described in <xref target="RFC3704">BCP 84</xref>) in
order to avoid BCP 38 filters. Even if there was routing, it would
result in an indirect route, rather than a direct route originating
with the host; this is not "wrong", but can be inefficient. Therefore
the host would do well to select the appropriate router itself.</t>
<t>Since the host derives fundamental default routing information from
the Router Advertisement, this implies that, in any network with hosts
using multiple prefixes, each prefix SHOULD be advertised via a Prefix
Information Option (PIO) <xref target="RFC4861"/> by one of the
attached routers, even if addresses are being assigned using DHCPv6. A
router that advertises a prefix indicates that it is able to
appropriately route packets with source addresses within that prefix,
regardless of the setting of the L and A flags in the PIO. In some
circumstances both L and A might be zero.</t>
</section>
<section title="Expectations of multihomed networks">
<t>The direct implication of <xref target="host_expects"/> is that
routing protocols used in multihomed networks SHOULD be capable of
source-prefix based egress routing, and that multihomed networks
SHOULD deploy them.</t>
</section>
</section>
<section anchor="network_expects"
title="Reasonable expectations of the host">
<t>Modern hosts maintain a fair bit of history, in terms of what has
historically worked or not worked for a given address or prefix and in
some cases the effective window and MSS values for TCP or other
protocols. This includes a next hop address for use when a packet is
sent to the indicated address.</t>
<t>When a host makes a successful exchange with a remote destination
using a particular source address, and the host has received a PIO that
matches that source address in an RA, then the host SHOULD include the
prefix in such history, whatever the setting of the L and A flags in the
PIO. On subsequent attempts to communicate with that destination, if it
has an address in that prefix at that time, a host MAY use an address in
the remembered prefix for the session.</t>
<t>Default Router Selection is modified as follows: A host SHOULD select
default routers for each prefix it is assigned an address in. Routers
that have advertised the prefix in its Router Advertisement message
SHOULD be preferred over routers that do not advertise the prefix.</t>
<t>As a result of doing so, when a host sends a packet using a source
address in one of those prefixes and has no history directing it
otherwise, it SHOULD send it to the indicated default router. In the
"simplest" network described in <xref target="host_expects"/>, that
would get it to the only router that is directly capable of getting it
to the right ISP. This will also apply in more complex networks, even
when more than one physical or virtual interface is involved.</t>
<t>In more complex cases, wherein routers advertise RAs for multiple
prefixes whether or not they have direct or isolated upstream
connectivity, the host is dependent on the routing system already. If
the host gives the packet to a router advertising its source prefix, it
should be able to depend on the router to do the right thing.</t>
<t>There is an interaction with <xref target="RFC6724">Default Address
Selection</xref>. Rule 5.5 of that specification states that the source
address used to send to a given destination address should if possible
be chosen from a prefix known to be advertised by the first-hop router
for that destination. This selection rule would be applicable in a host
following the recommendation in the previous paragraph.</t>
<t>There is potential for adverse interaction with any off-link Redirect
(Redirect for a GUA destination that is not on-link) message sent by a
router in accordance with Section 8 of <xref target="RFC4861"/>. Hosts
SHOULD apply off-link redirects only for the specific pair of source and
destination addresses concerned, so the host's Destination Cache may
need to contain appropriate source-specific entries.</t>
</section>
<section title="Residual issues">
<t>In a network where routers on a link run a routing protocol and are
configured with the same information. That is on each link all routers
advertise all prefixes on the link, the assumption that packets will be
forwarded to the appropriate egress by the local routing system might
cause at least one extra hop in the local network (from the host to the
wrong router, and from there to another router on the same link).</t>
<t>In a slightly more complex situation such as the disjoint LAN case of
<xref target="simple"/>, which happens to be one of the authors' home
plus corporate home-office configuration, the two upstream routers might
be on different LANs and therefore different subnets (e.g., the host is
itself multi-homed). In that case, there is no way for the "wrong"
router to detect the existence of the "right" router, or to route to
it.</t>
<t>In such a case it is particularly important that hosts take the
responsibility to memorize and select the best first-hop as described in
<xref target="network_expects"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not create any new security or privacy
exposures.</t>
<t>There might be a small privacy improvement, however: with the current
practice, a multihomed host that sends packets with the wrong address to
an upstream router or network discloses the prefix of one upstream to
the other upstream network. This practice reduces the probability of
that occurrence.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Comments were received from Jinmei Tatuya and Ole Troan, who have
suggested important text, plus Mikael Abrahamsson, Steven Barth, Juliusz
Chroboczek, Toerless Eckert, Pierre Pfister, Mark Smith, and Dusan
Mudric.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.6724" ?>
<?rfc include="reference.RFC.7217" ?>
</references>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">2015-08-05</t>
<t hangText="Version 01:">Update text on PIOs, added text on
Redirects, and clarified the concept of a "simple" network,
2015-08-13.</t>
<t hangText="Version 02:">Clarifications after WG discussions,
2015-08-19.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:43 |