First-hop router selection by hosts in a multi-prefix networkSanta BarbaraCaliforniaUSADepartment of Computer ScienceUniversity of AucklandPB 92019Auckland1142New Zealandbrian.e.carpenter@gmail.com
Internet
IPv6 MaintenanceThis document describes expected IPv6 host behavior in a scenario that
has more than one prefix, each allocated by an upstream network that is
assumed to implement 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. Host
behavior in choosing a first-hop router may interact with source address
selection in a given implementation. However, the selection of the source
address for a packet is done before the first-hop router for that packet
is chosen. 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.This document describes the expected behavior of an IPv6
host in a network that has more than one prefix, each allocated by an upstream network
that is assumed to implement BCP 38 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.Various aspects of this issue, and possible solution approaches, are
discussed in the document IPv6 Multihoming
without Network Address Translation.BCP 38 filtering by ISPs is not the only scenario where such behavior
is valuable. Implementations that combine existing recommendations, such
as 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) .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 known consistent solution is to
implement the features defined in this document.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 .
Nevertheless, implementers of Sections 6.2.3, 6.3.4, 6.3.6 and 8.1 of RFC 4861
should extend their implementations accordingly.
This specification is fully consistent with and
depends on support for its
Rule 5.5 (see ). Hosts that do not support these features may fail to
communicate in the presence of filters as described above.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 Router Advertisement (RA), is a form of
's Strong End System (ES, e.g. Host) Model, discussed in section
3.3.4.2 of that document. In short,
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 a
link-local-only interface and a default route pointing to that
interface will necessarily send packets using that
interface but with a source address derived from some other interface,
and will therefore be a de facto weak host. If the router
upstream from such a host implements BCP 38
Ingress Filtering, such as by implementing uRPF on each
interface, the router might prevent communication by weak hosts.The proposal also differs slightly from 's
language for the Strong Host Model. The proposal is that the packet
will go to a router that advertised a given prefix, but does not
specify what interface that might happen on. Hence, if the router is a
multi-interface (MIF) router and is using a common prefix spanning two or
more LANs shared by the host (as in ), the host
might use either of those LANs, according to this proposal. The Strong Host
Model is not stated in those terms, but in terms of the interface
used. A Strong host would treat such a MIF router as two separate routers when obeying
the rules from RFC 1122 as they apply in the Strong case: (A) A host MUST silently discard an incoming datagram whose
destination address does not correspond to the physical interface
through which it is received.(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.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. route(src IP addr, dest IP addr, TOS) ->
gatewayroute(dest IP addr, TOS) -> gateway,
interfaceIn the hypothetical MIF model suggested in ,
the address fails to identify a single interface, but it does identify
a single gateway.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 .A host receives prefixes in a Router
Advertisement, which goes on to identify whether they are
usable by SLAAC with any type
of interface identifier . When no prefixes are usable for SLAAC, the
Router Advertisement would normally signal the availability of
DHCPv6 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 generally be 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.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 , 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.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 BCP 84) 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.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) 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. 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 they should use the
router in question as the first hop for packets with source addresses
in the PIO prefix. An example case is the MIF router in ,
which could send PIOs with A=L=0 for the common prefix.
Although this does not
violate the existing standard ,
such a PIO has not previously been common, and it is possible that existing host
implementations simply ignore such a PIO or that existing router
implementations are not capable of sending such a PIO. Newer
implementations that support this mechanism should be updated
accordingly:
A host SHOULD NOT ignore a PIO simply because both L and
A flags are cleared (extending Section 6.3.4 of ).A router SHOULD be able to send such a PIO
(extending Section 6.2.3 of ).The mechanism specified in this document requires some form of support
from the routing protocols used in multihomed networks. One such way of
providing the requisite support in routing protocols is described in
a routing protocol independent fashion .
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.As described in and ,
a Router Advertisement may contain zero or more
Prefix information Options (PIOs), or zero or more Route Information
Options (RIOs). In their original intent, these indicate general
information to a host: "the router whose address is found in the
source address field of this packet is one of your default routers",
"you might create 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-prefix network with multiple exits, the host's characterization
of each default router SHOULD include the prefixes it
has announced (extending Section 6.3.4 of ).
In other words, the PIO is 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, regardless of Default Router Preference.The implications bear consideration. Imagine, , that hosts Alice and Bob are in communication.
Bob's network consists at least of Bob (the computer), 2 routers
(Bob-A and Bob-B), and the links between them; it may be much larger, for
example a campus or corporate network.
Bob's network is therefore multihomed, and Bob's first hop routers are Bob-A (to
upstream ISP A advertising prefix PA) and Bob-B (to upstream network B
and advertising prefix PB). We assume that Bob is not applying Rule 5.5
of . 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
PA). Hence, Bob created or was assigned an address in PA, and can only
reasonably send traffic using it to Bob-A as a first hop router.
If there are several routers in Bob's network advertising the prefix PA
(referred to as Bob-Ax routers), then Bob should choose its first-hop
router only from among those routers. From among the multiple Bob-Ax
routers, Bob should choose the first-hop router based on the criteria
specified in Section 3 of . If none of the
Bob-Ax routers has advertised an RA with a non-zero Router Lifetime or
an RIO with a non-zero Route Lifetime that includes Alice, but router Bob-B
has, it is irrelevant. Bob is using the address allocated in PA and
courts a BCP 38 discard if he doesn't send the packet to Bob-A.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 PA or
PB. 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.Default Router Selection (Section 6.3.6 of )
is extended 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, regardless of Default Router Preference. Note that this
document does not change the way in which default router
preferences are communicated .If no router has advertised the prefix in an RA, normal
routing metrics will apply. An example is a host connected to the Internet via
one router, and at the same time connected by a VPN to a private
domain which is also connected to the global Internet.As a result of this, 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 , 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.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.There is an interaction with Default Address
Selection. 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 SHOULD therefore be implemented in a
host following the recommendation in the previous section.There is potential for adverse interaction with any off-link
Redirect (Redirect for a destination that is not on-link) message sent
by a router in accordance with Section 8 of .
Hosts SHOULD apply off-link redirects only for the specific pair of
source and destination addresses concerned, so the host's Destination
Cache might need to contain appropriate source-specific entries.
This extends the validity check specified in Section 8.1 of
.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.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.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).In a slightly more complex situation such as the disjoint LAN case of
, for example a 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.In such a case it is particularly important that hosts take the
responsibility to memorize and select the best first-hop as described in
.This memo asks the IANA for no new parameters.This document is intended to avoid connectivity issues in the presence of BCP 38
ingress filters or stateful firewalls combined with multihoming.
It does not in itself create any new security or privacy exposures.
However, since the solution is designed to ensure that routing occurs correctly
in situations where it previously failed, this might result in unexpected
exposure of networks that were previously unreachable.There might be a small privacy improvement: 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.Comments were received from Jinmei Tatuya and Ole Troan, who have
suggested important text, plus Mikael Abrahamsson, Steven Barth,
Carlos Bernardos Cano, Chris Bowers, Zhen Cao, Juliusz
Chroboczek, Toerless Eckert, David Farmer, Bob Hinden, Ben Laurie, Dusan Mudric,
Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith
and James Woodyatt.2015-08-05Update text on PIOs, added text on
Redirects, and clarified the concept of a "simple" network,
2015-08-13.Clarifications after WG discussions,
2015-08-19.More clarifications after more WG
discussions, especially adding stateful firewalls, uRPF, and more
precise discussion of RFC 4861, 2015-09-03.Responds to various comments including
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.Some wording errors.Requests for discussion of the handling of the RIO, PIO, and
Default Router List in an RA.More clarifications after more WG
discussions, 2015-11-03.A final clarification re uRPF,
2015-12-15.Various clarifications and review comments,
2016-06-23.Fixes for IETF Last Call and IESG comments,
2016-08-15.