Host routing in a
multi-prefix network
Cisco Systems
Santa Barbara
93117
California
USA
fred@cisco.com
Department of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
Internet Engineering Task Force
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.
This note describes the expected behavior of an IPv6 host in a network that has more than one
prefix, each allocated by an upstream network that implements BCP 38 filtering. 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.
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 on-link prefixes in a Router
Advertisement, which goes on to identify preference order among
them and whether they are usable by SLAAC
, or whether they must
be assigned using DHCPv6.
The simplest multihomed network implementation might be a LAN with
one or more hosts on it and two or more routers, one for each upstream
network. In such a network, there is no routing protocol, and the two
routers may not even know that the other is a router as opposed to a
host, apart from the fact that it is emitting Router Advertisements
(RAs). 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.
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 BCP 84) 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.
Therefore the host needs to select the appropriate router itself.
Since the host derives fundamental default routing information from
the RA, this implies that, on any network with multiple prefixes, each
prefix SHOULD be advertised by one of the attached routers, even if
addresses are being assigned using DHCPv6.
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. This includes a
next hop address for use when a packet is sent to the indicated
address.
A host SHOULD include the prefix it used in a successful exchange
with a remote address or prefix in such history. On subsequent attempts
to communicate with that remote address, if it has such an address at
that time, a host MAY use its address in the remembered prefix for the
exchange.
A host SHOULD select a "default gateway" for each prefix it uses to
obtain one of its own addresses. 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
, that would get it to the only router that
is 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.
There is an interaction with Default Address
Selection. 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.
The direct implication of is that
routing protocols used in multihomed networks SHOULD be capable of
source-prefix based egress routing, and that multihomed networks SHOULD
deploy them.
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.
In a slightly more complex situation, 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.
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 does not create any new security or privacy
exposures.