One document matched: draft-baker-6man-multi-homed-host-01.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-01"
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>
</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>
<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 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 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 on-link in that subnet.</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. 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
]]></artwork>
</figure>
<t>Because 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, it would be an
indirect route, rather than a direct route originating with the host;
this is not "wrong", but can be inefficient and prone to failure.
Therefore the host would do well to select the appropriate router
itself.</t>
<t>Since the host derives fundamental default routing information from
the Route Advertisement, this implies that, in any network with hosts
using multiple prefixes, each prefix SHOULD be advertised via on-link
Prefix Information Options <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.</t>
</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 address or
prefix using a particular source address, and the host has received a
prefix that matches that source address in an RA, then the host SHOULD
include the prefix in such history. On subsequent attempts to
communicate with that remote address, 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>A host SHOULD select a "default gateway" for each source prefix it
uses to form an address or is assigned an address in. That router SHOULD
be one of the routers advertising the prefix in its RA. As a result of
doing so, when a host emits a datagram using a source address in one of
those prefixes and has no history directing it otherwise, it SHOULD send
it to the indicated "default gateway". 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 next-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
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 needs to contain appropriate source-specific
entries.</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 title="Residual issues">
<t>In an HNCP network, in which one router on each LAN advertises all
prefixes and the others do not, 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 LAN but in a
different subnet). In some scenarios, where the local network is a
highly constrained or lossy wireless network, this extra hop may be a
significant performance handicap.</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, who has suggested
important text, plus Ole Troan, Pierre Pfister, Toerless Eckert, Mikael
Abrahamsson, and Juliusz Chroboczek.</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>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:20 |