draft-ietf-6man-multi-homed-host-07.txt   draft-ietf-6man-multi-homed-host-08.txt 
IPv6 Maintenance F. Baker IPv6 Maintenance F. Baker
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 4861 (if approved) B. Carpenter Updates: 4861 (if approved) B. Carpenter
Intended status: Standards Track Univ. of Auckland Intended status: Standards Track Univ. of Auckland
Expires: December 25, 2016 June 23, 2016 Expires: February 20, 2017 August 19, 2016
Routing packets from hosts in a multi-prefix network First-hop router selection by hosts in a multi-prefix network
draft-ietf-6man-multi-homed-host-07 draft-ietf-6man-multi-homed-host-08
Abstract Abstract
This document describes expected IPv6 host behavior in a scenario This document describes expected IPv6 host behavior in a scenario
that has more than one prefix, each allocated by an upstream network that has more than one prefix, each allocated by an upstream network
that implements BCP 38 ingress filtering, when the host has multiple that is assumed to implement BCP 38 ingress filtering, when the host
routers to choose from. It also applies to other scenarios such as has multiple routers to choose from. It also applies to other
the usage of stateful firewalls that effectively act as address-based scenarios such as the usage of stateful firewalls that effectively
filters. This host behavior may interact with source address act as address-based filters. Host behavior in choosing a first-hop
selection in a given implementation, but logically follows it. Given router may interact with source address selection in a given
that the network or host is, or appears to be, multihomed with 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 multiple provider-allocated addresses, that the host has elected to
use a source address in a given prefix, and that some but not all use a source address in a given prefix, and that some but not all
neighboring routers are advertising that prefix in their Router neighboring routers are advertising that prefix in their Router
Advertisement Prefix Information Options, this document specifies to Advertisement Prefix Information Options, this document specifies to
which router a host should present its transmission. It updates RFC which router a host should present its transmission. It updates RFC
4861. 4861.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 44 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2016. This Internet-Draft will expire on February 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Sending context expected by the host . . . . . . . . . . . . 5 2. Sending context expected by the host . . . . . . . . . . . . 5
2.1. Expectations the host has of the network . . . . . . . . 5 2.1. Expectations the host has of the network . . . . . . . . 5
2.2. Expectations of multihomed networks . . . . . . . . . . . 7 2.2. Expectations of multihomed networks . . . . . . . . . . . 7
3. Reasonable expectations of the host . . . . . . . . . . . . . 7 3. Reasonable expectations of the host . . . . . . . . . . . . . 7
3.1. Interpreting Router Advertisements . . . . . . . . . . . 7 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7
3.2. Default Router Selection . . . . . . . . . . . . . . . . 8 3.2. Default Router Selection . . . . . . . . . . . . . . . . 8
3.3. Source Address Selection . . . . . . . . . . . . . . . . 9 3.3. Source Address Selection . . . . . . . . . . . . . . . . 9
3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 12 Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction and Applicability 1. Introduction and Applicability
This document describes the expected behavior of an IPv6 [RFC2460] This document describes the expected behavior of an IPv6 [RFC2460]
host in a network that has more than one prefix, each allocated by an host in a network that has more than one prefix, each allocated by an
upstream network that implements BCP 38 [RFC2827] ingress filtering, upstream network that is assumed to implement BCP 38 [RFC2827]
and in which the host is presented with a choice of routers. It ingress filtering, and in which the host is presented with a choice
expects that the network will implement some form of egress routing, of routers. It expects that the network will implement some form of
so that packets sent to a host outside the local network from a given egress routing, so that packets sent to a host outside the local
ISP's prefix will go to that ISP. If the packet is sent to the wrong network from a given ISP's prefix will go to that ISP. If the packet
egress, it is liable to be discarded by the BCP 38 filter. However, is sent to the wrong egress, it is liable to be discarded by the BCP
the mechanics of egress routing once the packet leaves the host are 38 filter. However, the mechanics of egress routing once the packet
out of scope. The question here is how the host interacts with that leaves the host are out of scope. The question here is how the host
network. interacts with that network.
Various aspects of this issue, and possible solution approaches, are Various aspects of this issue, and possible solution approaches, are
discussed in the document IPv6 Multihoming without Network Address discussed in the document IPv6 Multihoming without Network Address
Translation [RFC7157]. Translation [RFC7157].
BCP 38 filtering by ISPs is not the only scenario where such behavior BCP 38 filtering by ISPs is not the only scenario where such behavior
is valuable. Implementations that combine existing recommendations, is valuable. Implementations that combine existing recommendations,
such as [RFC6092] [RFC7084] can also result in such filtering. such as [RFC6092] [RFC7084] can also result in such filtering.
Another case is when the connections to the upstream networks include Another case is when the connections to the upstream networks include
stateful firewalls, such that return packets in a stream will be stateful firewalls, such that return packets in a stream will be
discarded if they do not return via the firewall that created state discarded if they do not return via the firewall that created state
for the outgoing packets. A similar cause of such discards is for the outgoing packets. A similar cause of such discards is
unicast reverse path forwarding (uRPF) [RFC3704]. unicast reverse path forwarding (uRPF) [RFC3704].
In this document, the term "filter" is used for simplicity to cover 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 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 whether an ingress filter, a stateful firewall, or any other type of
filter is in place. Therefore, the only consistent solution is to filter is in place. Therefore, the only known consistent solution is
implement the features defined in this document. to implement the features defined in this document.
Note that, apart from ensuring that a message with a given source 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 address is given to a first-hop router that appears to know about the
prefix in question, this specification is consistent with [RFC4861]. prefix in question, this specification is consistent with [RFC4861].
Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC Nevertheless, implementers of Sections 6.2.3, 6.3.4, 6.3.6 and 8.1 of
4861 will need to extend their implementations accordingly. This RFC 4861 should extend their implementations accordingly. This
specification is fully consistent with [RFC6724] and implementers specification is fully consistent with [RFC6724] and depends on
will need to add support for its Rule 5.5. Hosts that do not support support for its Rule 5.5 (see Section 3.3). Hosts that do not
these features may fail to communicate in the presence of filters as support these features may fail to communicate in the presence of
described above. filters as described above.
1.1. Host Model 1.1. Host Model
It could be argued that the proposal of this document, which is to 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 send messages using a source address in a given prefix to the router
that advertised the prefix in its Router Advertisement (RA), is a that advertised the prefix in its Router Advertisement (RA), is a
form of [RFC1122]'s Strong End System (ES, e.g. Host) Model, form of [RFC1122]'s Strong End System (ES, e.g. Host) Model,
discussed in section 3.3.4.2 of that document. In short, [RFC1122] discussed in section 3.3.4.2 of that document. In short, [RFC1122]
identifies two basic models, in which the "strong host" model models 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 the host as a set of hosts in one chassis, each of which uses a
skipping to change at page 4, line 12 skipping to change at page 4, line 12
capable of using any interface for any communication. As noted capable of using any interface for any communication. As noted
there, neither model is completely satisfactory. For example, a host there, neither model is completely satisfactory. For example, a host
with a link-local-only interface and a default route pointing to that with a link-local-only interface and a default route pointing to that
interface will necessarily send packets using that interface but with interface will necessarily send packets using that interface but with
a source address derived from some other interface, and will a source address derived from some other interface, and will
therefore be a de facto weak host. If the router upstream from such therefore be a de facto weak host. If the router upstream from such
a host implements BCP 38 Ingress Filtering [RFC2827], such as by a host implements BCP 38 Ingress Filtering [RFC2827], such as by
implementing uRPF on each interface, the router might prevent implementing uRPF on each interface, the router might prevent
communication by weak hosts. communication by weak hosts.
+-----------------+ +-----------------+
| | | |
| MIF Router +---/--- other interfaces | MIF Router +---/--- other interfaces
| | | |
+---+---------+---+ +---+---------+---+
| | Two interfaces sharing a prefix | | Two interfaces using same prefix
--+-+-- --+-+-- --+-+-- --+-+--
| | | |
+--+---------+--+ +--+---------+--+
| MIF Host | | MIF Host |
+---------------+ +---------------+
Figure 1: Hypothetical MIF interconnection Figure 1: Hypothetical MIF interconnection
The proposal also differs slightly from [RFC1122]'s language of the The proposal also differs slightly from [RFC1122]'s language of the
Strong Host Model. The statement is that the packet will go to 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 router that advertised a given prefix, but doesn't state what
interface that might happen on. Hence, if the router is a multi- interface that might happen on. Hence, if the router is a multi-
interface (MIF) router and is using the same prefix on two or more interface (MIF) router and is using the same prefix on two or more
LANs shared by the host (as in Figure 1), the host might use each of LANs shared by the host (as in Figure 1), the host might use each of
those LANs and meet the requirement. The Strong Host Model is not 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 stated in those terms, but in terms of the interface used, and would
find a MIF router quite confusing: find such a MIF router quite confusing:
(A) A host MUST silently discard an incoming datagram whose (A) A host MUST silently discard an incoming datagram whose
destination address does not correspond to the physical interface destination address does not correspond to the physical interface
through which it is received. through which it is received.
(B) A host MUST restrict itself to sending (non-source- routed) IP (B) A host MUST restrict itself to sending (non-source- routed) IP
datagrams only through the physical interface that corresponds to datagrams only through the physical interface that corresponds to
the IP source address of the datagrams. the IP source address of the datagrams.
However, comparing the presumptive route lookup mechanisms in each However, comparing the presumptive route lookup mechanisms in each
skipping to change at page 5, line 19 skipping to change at page 5, line 19
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Sending context expected by the host 2. Sending context expected by the host
2.1. Expectations the host has of the network 2.1. Expectations the host has of the network
A host receives prefixes in a Router Advertisement [RFC4861], which A host receives prefixes in a Router Advertisement [RFC4861], which
goes on to identify whether they are usable by SLAAC [RFC4862] goes on to identify whether they are usable by SLAAC [RFC4862] with
[RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the any type of interface identifier [RFC4941] [RFC7217]. When no
Router Advertisement would normally signal the availability of DHCPv6 prefixes are usable for SLAAC, the Router Advertisement would
[RFC3315] and the host would use it to configure its addresses. In normally signal the availability of DHCPv6 [RFC3315] and the host
the latter case (or if both SLAAC and DHCPv6 are used on the same would use it to configure its addresses. In the latter case (or if
link for some reason) it will generally be the case that the both SLAAC and DHCPv6 are used on the same link for some reason) it
configured addresses match one of the prefixes advertised in a Router will generally be the case that the configured addresses match one of
Advertisement that are supposed to be on-link for that link. 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 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 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 two or more routers, one for each upstream network, or a host that is
served by disjoint networks on separate interfaces. In such a served by disjoint networks on separate interfaces. In such a
network, especially the latter, there is not necessarily a routing network, especially the latter, there is not necessarily a routing
protocol, and the two routers may not even know that the other is a 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 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 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 each other's RAs and form an address in the other router's prefix
skipping to change at page 6, line 43 skipping to change at page 6, line 43
the Router Advertisement, this implies that, in any network with the Router Advertisement, this implies that, in any network with
hosts using multiple prefixes, each prefix SHOULD be advertised via a hosts using multiple prefixes, each prefix SHOULD be advertised via a
Prefix Information Option (PIO) [RFC4861] by one of the attached Prefix Information Option (PIO) [RFC4861] by one of the attached
routers, even if addresses are being assigned using DHCPv6. A router routers, even if addresses are being assigned using DHCPv6. A router
that advertises a prefix indicates that it is able to appropriately that advertises a prefix indicates that it is able to appropriately
route packets with source addresses within that prefix, regardless of route packets with source addresses within that prefix, regardless of
the setting of the L and A flags in the PIO. 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 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 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 (L=0), a PIO SHOULD be sent to inform hosts that they should use the
source-routed by the router in question. Although this does not router in question as the first hop for packets with source addresses
violate the existing standard [RFC4861], such a PIO has not in the PIO prefix. Although this does not violate the existing
previously been common, and it is possible that existing host standard [RFC4861], such a PIO has not previously been common, and it
implementations simply ignore such a PIO or that a router is possible that existing host implementations simply ignore such a
implementation rejects such a PIO as a configuration error. Newer PIO or that existing router implementations are not capable of
implementations that support this mechanism will need to be updated sending such a PIO. Newer implementations that support this
accordingly: a host SHOULD NOT ignore a PIO simply because both L and mechanism should be updated accordingly:
A flags are cleared; a router SHOULD be able to send such a PIO.
o A host SHOULD NOT ignore a PIO simply because both L and A flags
are cleared (extending Section 6.3.4 of [RFC4861]).
o A router SHOULD be able to send such a PIO (extending
Section 6.2.3 of [RFC4861]).
2.2. Expectations of multihomed networks 2.2. Expectations of multihomed networks
The direct implication of Section 2.1 is that, if the network uses a The mechanism specified in this document requires some form of
routing protocol, the routing protocols used in multihomed networks support from the routing protocols used in multihomed networks. One
SHOULD implement source-prefix based egress routing, for example as such way of providing the requisite support in routing protocols is
described in [I-D.ietf-rtgwg-dst-src-routing]. Network designs exist described in a routing protocol independent fashion
that can usefully limit themselves to static routing (such as a [I-D.ietf-rtgwg-dst-src-routing]. Network designs exist that can
simple tree network), or may internally use no routers at all, such usefully limit themselves to static routing (such as a simple tree
as a single LAN with two CE routers, each of which leads to a network), or may internally use no routers at all, such as a single
different upstream network. LAN with two CE routers, each of which leads to a different upstream
network.
3. Reasonable expectations of the host 3. Reasonable expectations of the host
3.1. Interpreting Router Advertisements 3.1. Interpreting Router Advertisements
As described in [RFC4191] and [RFC4861], a Router Advertisement may As described in [RFC4191] and [RFC4861], a Router Advertisement may
contain zero or more Prefix information Options (PIOs), or zero or contain zero or more Prefix information Options (PIOs), or zero or
more Route Information Options (RIOs). In their original intent, more Route Information Options (RIOs). In their original intent,
these indicate general information to a host: "the router whose these indicate general information to a host: "the router whose
address is found in the source address field of this packet is one of 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", 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 or "this router would be a good place to send traffic directed to a
given destination prefix". In a multi-homed network implementing given destination prefix". In a multi-prefix network with multiple
source/destination routing, the interpretation of default router or exits, the host's characterization of each default router SHOULD
an RIO has to be modified with the words "if the source address is in include the prefixes it has announced (extending Section 6.3.4 of
one of the prefixes I advertise in a PIO". Additionally, the PIO [RFC4861]). In other words, the PIO is reinterpreted to also imply
must be reinterpreted to also imply that the advertising router would that the advertising router would be a reasonable first hop for any
be a reasonable first hop for any packet using a source address in packet using a source address in any advertised prefix, regardless of
any advertised prefix. Default Router Preference.
+---------+ | +---------+ |
( ISP A ) - + Bob-A +--+ +-----+ ( ISP A ) - + Bob-A +--+ +-----+
+-------+ / +---------+ +--+ | +-------+ / +---------+ +--+ |
| | / | | | | | / | | |
| Alice +--/--( The Internet ) | Bob | | Alice +--/--( The Internet ) | Bob |
| | \ | | | | | \ | | |
+-------+ \ +---------+ +--+ | +-------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+ ( ISP B ) - + Bob-B +--+ +-----+
+---------+ | +---------+ |
Figure 3: PIOs, RIOs, and Default Routes Figure 3: PIOs, RIOs, and Default Routes
The implications bear consideration. Imagine, Figure 3, that hosts The implications bear consideration. Imagine, Figure 3, that hosts
Alice and Bob are in communication. Bob's network consists at least 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 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 between them; it may be much larger, for example a campus or
corporate network. Bob's network is therefore multihomed, and Bob's corporate network. Bob's network is therefore multihomed, and Bob's
first hop routers are Bob-A (to upstream ISP A advertising prefix PA) first hop routers are Bob-A (to upstream ISP A advertising prefix PA)
and Bob-B (to upstream network B and advertising prefix PB). If Bob and Bob-B (to upstream network B and advertising prefix PB). We
is responding to a message from Alice, his choice of source address assume that Bob is not applying Rule 5.5 of [RFC6724]. If Bob is
is forced to be the address Alice used as a destination (which we may 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 presume to have been in prefix PA). Hence, Bob created or was
assigned an address in PA, and can only reasonably send traffic using assigned an address in PA, and can only reasonably send traffic using
it to Bob-A as a first hop router. If there were several instances it to Bob-A as a first hop router. If there are several routers in
of Bob-A and one had advertised itself as a default router or as Bob's network advertising the prefix PA (referred to as Bob-Ax
having a route to Alice, that is the router Bob should choose. If routers), then Bob should choose its first-hop router only from among
none of Bob-A have advertised that but Bob-B has, it is irrelevant; 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 [RFC4191]. 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 Bob is using the address allocated in PA and courts a BCP 38 discard
if he doesn't send the packet to Bob-A. if he doesn't send the packet to Bob-A.
In the special case that Bob is initiating the conversation, an RIO In the special case that Bob is initiating the conversation, an RIO
might, however, influence source address choice. Bob could might, however, influence source address choice. Bob could
presumably use any address allocated to him, in this case his address 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 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 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 selection - choosing an address that would allow him to make use of
the RIO. the RIO.
3.2. Default Router Selection 3.2. Default Router Selection
Default Router Selection is modified as follows: A host SHOULD select Default Router Selection (Section 6.3.6 of [RFC4861]) is extended as
default routers for each prefix it is assigned an address in. follows: A host SHOULD select default routers for each prefix it is
Routers that have advertised the prefix in its Router Advertisement assigned an address in. Routers that have advertised the prefix in
message SHOULD be preferred over routers that do not advertise the its Router Advertisement message SHOULD be preferred over routers
prefix. (If no router has advertised the prefix in an RA, normal that do not advertise the prefix, regardless of Default Router
routing metrics will apply. An example is a host connected to the Preference. Note that this document does not change the way in which
Internet via one router, and at the same time connected by a VPN to a default router preferences are communicated [RFC4191].
private domain which is also connected to the global Internet.)
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 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 address in one of those prefixes and has no history directing it
otherwise, it SHOULD send it to the indicated default router. In the otherwise, it SHOULD send it to the indicated default router. In the
"simplest" network described in Section 2.1, that would get it to the "simplest" network described in Section 2.1, that would get it to the
only router that is directly capable of getting it to the right ISP. 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 This will also apply in more complex networks, even when more than
one physical or virtual interface is involved. one physical or virtual interface is involved.
In more complex cases, wherein routers advertise RAs for multiple In more complex cases, wherein routers advertise RAs for multiple
skipping to change at page 9, line 13 skipping to change at page 9, line 25
thing. thing.
3.3. Source Address Selection 3.3. Source Address Selection
There is an interaction with Default Address Selection [RFC6724]. A There is an interaction with Default Address Selection [RFC6724]. A
host following the recommendation in the previous section will store host following the recommendation in the previous section will store
information about which next-hops advertised which prefixes. Rule information about which next-hops advertised which prefixes. Rule
5.5 of RFC 6724 states that the source address used to send to a 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 given destination address should if possible be chosen from a prefix
known to be advertised by the next-hop router for that destination. known to be advertised by the next-hop router for that destination.
This selection rule would therefore be applicable in a host following This selection rule SHOULD therefore be implemented in a host
the recommendation in the previous section. following the recommendation in the previous section.
3.4. Redirects 3.4. Redirects
There is potential for adverse interaction with any off-link Redirect There is potential for adverse interaction with any off-link Redirect
(Redirect for a destination that is not on-link) message sent by a (Redirect for a destination that is not on-link) message sent by a
router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply
off-link redirects only for the specific pair of source and off-link redirects only for the specific pair of source and
destination addresses concerned, so the host's Destination Cache may destination addresses concerned, so the host's Destination Cache
need to contain appropriate source-specific entries. might need to contain appropriate source-specific entries. This
extends the validity check specified in Section 8.1 of [RFC4861].
3.5. History 3.5. History
Some modern hosts maintain history, in terms of what has previously 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 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 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 might include a next hop address for use when a packet is sent to the
indicated address. indicated address.
When such a host makes a successful exchange with a remote When such a host makes a successful exchange with a remote
skipping to change at page 10, line 22 skipping to change at page 10, line 34
In such a case it is particularly important that hosts take the In such a case it is particularly important that hosts take the
responsibility to memorize and select the best first-hop as described responsibility to memorize and select the best first-hop as described
in Section 3. in Section 3.
5. IANA Considerations 5. IANA Considerations
This memo asks the IANA for no new parameters. This memo asks the IANA for no new parameters.
6. Security Considerations 6. Security Considerations
This document does not create any new security or privacy exposures. This document is intended to avoid connectivity issues in the
It is intended to avoid connectivity issues in the presence of BCP 38 presence of BCP 38 ingress filters or stateful firewalls combined
ingress filters or stateful firewalls combined with multihoming. 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, however: with the current There might be a small privacy improvement: with the current
practice, a multihomed host that sends packets with the wrong address practice, a multihomed host that sends packets with the wrong address
to an upstream router or network discloses the prefix of one upstream to an upstream router or network discloses the prefix of one upstream
to the other upstream network. This practice reduces the probability to the other upstream network. This practice reduces the probability
of that occurrence. of that occurrence.
7. Acknowledgements 7. Acknowledgements
Comments were received from Jinmei Tatuya and Ole Troan, who have Comments were received from Jinmei Tatuya and Ole Troan, who have
suggested important text, plus Mikael Abrahamsson, Steven Barth, suggested important text, plus Mikael Abrahamsson, Steven Barth,
Carlos Bernardos Cano, Zhen Cao, Juliusz Chroboczek, Toerless Eckert, Carlos Bernardos Cano, Chris Bowers, Zhen Cao, Juliusz Chroboczek,
David Farmer, Dusan Mudric, Tadahisa Okimoto, Pierre Pfister, Behcet Toerless Eckert, David Farmer, Bob Hinden, Ben Laurie, Dusan Mudric,
Sarikaya, Mark Smith, Bob Hinden, and James Woodyatt. Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith and
James Woodyatt.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 16 skipping to change at page 13, line 37
Default Router List in an RA. Default Router List in an RA.
WG Versions 00-02: More clarifications after more WG discussions, WG Versions 00-02: More clarifications after more WG discussions,
2015-11-03. 2015-11-03.
WG Version 03: A final clarification re uRPF, 2015-12-15. WG Version 03: A final clarification re uRPF, 2015-12-15.
WG Versions 04-07: Various clarifications and review comments, WG Versions 04-07: Various clarifications and review comments,
2016-06-23. 2016-06-23.
WG Version 08: Fixes for IETF Last Call and IESG comments,
2016-08-15.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: fred@cisco.com Email: fred@cisco.com
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com Email: brian.e.carpenter@gmail.com
 End of changes. 26 change blocks. 
103 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/