One document matched: draft-ietf-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-ietf-6man-multi-homed-host-02" ipr="trust200902" updates="4861">
<front>
<title abbrev="Host routing in a multi-prefix network">Routing packets
from hosts 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 document describes expected IPv6 host behavior in a network that
has more than one prefix, each allocated by an upstream network that
implements BCP 38 ingress filtering, when the host has multiple routers
to choose from. It also applies to other scenarios such as the usage of
stateful firewalls that effectively act as address-based filters.</t>
<t>This host behavior 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 multiple
provider-allocated addresses, that the host has elected to use a source
address in a given prefix, and that some but not all neighboring routers
are advertising that prefix in their Router Advertisement Prefix
Information Options, this document specifies to which router a host
should present its transmission. It updates RFC 4861.</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 and Applicability">
<t>This document 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> ingress 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>
Various aspects of this issue, and possible solution approaches, are discussed in the document <xref target="RFC7157">IPv6 Multihoming without Network Address Translation</xref>.
</t>
<t>BCP 38 filtering by ISPs is not the only scenario where such behavior
is valuable. Implementations that combine existing recommendations, such
as <xref target="RFC6092"/> <xref target="RFC7084"/> can also result in
such filtering. Another case is when the connections to the upstream
networks include stateful firewalls, such that return packets in a
stream will be discarded if they do not return via the firewall that
created state for the outgoing packets. A similar cause of such discards
is unicast reverse path forwarding (uRPF) <xref target="RFC3704"/>.</t>
<t>In this document, the term "filter" is used for simplicity to cover
all such cases. In any case, one cannot assume the host to be aware
whether an ingress filter, a stateful firewall, or any other type of
filter is in place. Therefore, the only consistent solution is to
implement the features defined in this document.</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 is consistent with <xref target="RFC4861"/>. Nevertheless, implementers of Sections 5.2, 6.2.3,
6.3.4 and 8 of RFC 4861 will need to extend their implementations
accordingly. This specification is fully consistent with <xref target="RFC6724"/> and implementers will need to add support for its
Rule 5.5. Hosts that do not support these features may fail to
communicate in the presence of filters as described above.</t>
<section anchor="model" title="Host Model">
<t>It could be argued that the proposal of this document, which is to
send messages using a source address in a given prefix to the router
that advertised the prefix in its RA, is a form of <xref target="RFC1122"/>'s Strong ES (e.g. Host) Model, discussed in section
3.3.4.2 of that document. In short, <xref target="RFC1122"/>
identifies two basic models, in which the "strong host" model models
the host as a set of hosts in one chassis, each of which uses a single
address on a single interface, and always both sends and receives on
that interface, and the "weak host" model treats the host as one
system with zero or more addresses on every interface, and capable of
using any interface for any communication. As noted there, neither
model is completely satisfactory. For example, a host with an
addressless interface and a default route pointing to the interface
will necessarily send packets using any address using that interface,
and therefore be a de facto weak host. If the router upstream
from such a host implements <xref target="RFC2827">BCP 38 Ingress
Filtering</xref>, such as by implementing uRPF on each interface, the
router will prevent communication by weak hosts.</t>
<figure anchor="MIF" title="Hypothetical MIF interconnection">
<artwork align="center"><![CDATA[+-----------------+
| |
| MIF Router +---/--- other interfaces
| |
+---+---------+---+
| | Two interfaces sharing a prefix
--+-+-- --+-+--
| |
+--+---------+--+
| MIF Host |
+---------------+
]]></artwork>
</figure>
<t>The proposal also differs slightly from <xref target="RFC1122"/>'s
language of the Strong Host Model. The statement is that the packet
will go to the router that advertised a given prefix, but doesn't
state what interface that might happen on. Hence, if the router is a
MIF router and is using the same prefix on two or more LANs shared by
the host (as in <xref target="MIF"/>), the host might use each of
those LANs and meet the requirement. The Strong Host Model is not
stated in those terms, but in terms of the interface used, and would
find a MIF router quite confusing: <list style="empty">
<t>(A) A host [MUST] silently discard an incoming datagram whose
destination address does not correspond to the physical interface
through which it is received.</t>
<t>(B) A host [MUST] restrict itself to sending (non-source-
routed) IP datagrams only through the physical interface that
corresponds to the IP source address of the datagrams.</t>
</list></t>
<t>However, comparing the presumptive route lookup mechanisms in each
model, this proposal is indeed most similar to the Strong Host Model,
as is any source/destination routing paradigm. <list style="hanging">
<t hangText="Strong:">route(src IP addr, dest IP addr, TOS) ->
gateway</t>
<t hangText="Weak:">route(dest IP addr, TOS) -> gateway,
interface</t>
</list></t>
<t>In the hypothetical MIF model suggested in <xref target="MIF"/>,
the address fails to identify a single interface, but it does identify
a single gateway.</t>
</section>
<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 on-link for 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 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. </t>
<t>In some circumstances both L and A might be zero. If SLAAC is not wanted
(A=0) and there is no reason to announce an on-link prefix (L=0), a PIO
SHOULD be sent to inform hosts that the prefix is source-routed by the
router in question. Although this does not violate the existing standard
<xref target="RFC4861"/>, such a PIO has not previously been common, and it
is possible that existing host implementations simply ignore such a
PIO or that a router implementation rejects such a PIO as a
configuration error. Newer implementations that support this mechanism
will need to be updated accordingly: a host SHOULD NOT ignore a PIO
simply because both L and A flags are cleared; a router SHOULD be able
to send such a PIO.</t>
</section>
<section title="Expectations of multihomed networks">
<t>The direct implication of <xref target="host_expects"/> is that, if
the network uses a routing protocol, the routing protocols used in
multihomed networks SHOULD implement source-prefix based egress
routing. Network designs exist that can usefully limit themselves to
static routing (such as a simple tree network), or may internally use
no routers at all, such as a single LAN with two CE routers, each of
which leads to a different upstream network.</t>
</section>
</section>
<section anchor="network_expects" title="Reasonable expectations of the host">
<section title="Interpreting Router Advertisements">
<t>As described in <xref target="RFC4191"/> and <xref target="RFC4861"/>, a Router Advertisement may contain zero or more
Prefix information Options (PIOs), zero or more Route Information
Options (RIOs), or a Default Router List. In their original intent,
these indicate general information to a host: "these are your default
routers", "you might create or be configured with an address in this
prefix", or "this router would be a good place to send traffic
directed to a given destination prefix". In a multi-homed network
implementing source/destination routing, the interpretation of a
default router list or an RIO has to be modified with the words "if
the source address is in one of the prefixes I advertise in a PIO".
Additionally, the PIO must be reinterpreted to also imply that the
advertising router would be a reasonable first hop for any packet
using a source address in any advertised prefix.</t>
<figure anchor="BobAlice" title="PIOs, RIOs, and Default Routes">
<artwork align="center"><![CDATA[
+---------+ |
( ISP A ) - + Bob-A +--+ +-----+
+---------+ / +---------+ +--+ |
| | / | | |
| Alice +---/---( The Internet ) | Bob |
| | \ | | |
+---------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+
+---------+ |
]]></artwork>
</figure>
<t>The implications bear consideration. Imagine, <xref target="BobAlice"/>, that hosts Alice and Bob are in communication,
Bob's network is multihomed, and Bob's first hop routers are Bob-A (to
upstream ISP A advertising prefix A') and Bob-B (to upstream network B
and advertising prefix B'). If Bob is responding to a message from
Alice, his choice of source address is forced to be the address Alice
used as a destination (which we may presume to have been in prefix
A'). Hence, Bob created or was assigned an address in A', and can only
reasonably send traffic using it to Bob-A as a first hop router. If
there were several instances of Bob-A and one had advertised itself as
a default router or as having a route to Alice, that is the router Bob
should choose. If none of Bob-A have advertised that but Bob-B has, it
is irrelevant; Bob is using the address allocated in A' and courts a
BCP 38 discard if he doesn't send the packet to Bob-A.</t>
<t>In the special case that Bob is initiating the conversation, an RIO
might, however, influence source address choice. Bob could presumably
use any address allocated to him, in this case his address in A' or
B'. If Bob-B has advertised an RIO for Alice's prefix and Bob-A has
not, Bob MAY take that fact into account in address selection -
choosing an address that would allow him to make use of the RIO.</t>
</section>
<section title="Default Router Selection">
<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>
</section>
<section title="Source Address Selection">
<t>There is an interaction with <xref target="RFC6724">Default Address
Selection</xref>. A host following the recommendation in the previous
section will store information about which next-hops advertised which
prefixes. Rule 5.5 of RFC 6724 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 therefore
be applicable in a host following the recommendation in the previous
section.</t>
</section>
<section title="Redirects">
<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="History">
<t>Some modern hosts maintain history, in terms of what has previously
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
might include a next hop address for use when a packet is sent to the
indicated address.</t>
<t>When such a host makes a successful exchange with a remote
destination using a particular address pair, and the host has
previously received a PIO that matches the source address, 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>
</section>
</section>
<section title="Residual issues">
<t>Consider a network where routers on a link run a routing protocol and
are configured with the same information. Thus, 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.
It is intended to avoid connectivity issues in the presence of BCP 38
ingress filters or stateful firewalls combined with multihoming.</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, David Farmer, Dusan Mudric,
Tadahisa Okimoto, Pierre Pfister, Mark Smith,
and James Woodyatt.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4191" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.6724" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.7217" ?>
<?rfc include="reference.RFC.6092" ?>
<?rfc include="reference.RFC.7084" ?>
<?rfc include="reference.RFC.7157" ?>
</references>
<section anchor="log" title="Change Log (RFC Editor: please delete)">
<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>
<t hangText="Version 03:">More clarifications after more WG
discussions, especially adding stateful firewalls, uRPF, and more
precise discussion of RFC 4861, 2015-09-03.</t>
<t hangText="Version 04:">Responds to various comments including
<list style="symbols">
<t>Questions regarding RFC 1122's strong and weak host models.
This model is, strictly speaking, neither, but is most similar
to the strong host model.</t>
<t>Some wording errors.</t>
<t>Requests for discussion of the handling of the RIO, PIO, and
Default Router List in an RA.</t>
</list></t>
<t hangText="WG Versions 00-02:">More clarifications after more WG
discussions, 2015-11-03.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:01:06 |