draft-ietf-6man-multi-homed-host-01.txt   draft-ietf-6man-multi-homed-host-02.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: April 17, 2016 October 15, 2015 Expires: May 6, 2016 November 3, 2015
Routing packets from hosts in a multi-prefix network Routing packets from hosts in a multi-prefix network
draft-ietf-6man-multi-homed-host-01 draft-ietf-6man-multi-homed-host-02
Abstract Abstract
This document describes expected IPv6 host behavior in a network that This document describes expected IPv6 host behavior in a network 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 implements BCP 38 ingress filtering, when the host has multiple
routers to choose from. It also applies to other scenarios such as routers to choose from. It also applies to other scenarios such as
the usage of stateful firewalls that effectively act as address-based the usage of stateful firewalls that effectively act as address-based
filters. filters.
skipping to change at page 1, line 46 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 April 17, 2016. This Internet-Draft will expire on May 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 41 skipping to change at page 2, line 41
3.3. Source Address Selection . . . . . . . . . . . . . . . . 8 3.3. Source Address Selection . . . . . . . . . . . . . . . . 8
3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 implements BCP 38 [RFC2827] ingress filtering,
and in which the host is presented with a choice of routers. It and in which the host is presented with a choice of routers. It
expects that the network will implement some form of egress routing, 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 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 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, 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 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 out of scope. The question here is how the host interacts with that
network. network.
Various aspects of this issue, and possible solution approaches, are
discussed in the document IPv6 Multihoming without Network Address
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
skipping to change at page 3, line 50 skipping to change at page 4, line 6
In short, [RFC1122] identifies two basic models, in which the "strong In short, [RFC1122] identifies two basic models, in which the "strong
host" model models the host as a set of hosts in one chassis, each of 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 which uses a single address on a single interface, and always both
sends and receives on that interface, and the "weak host" model sends and receives on that interface, and the "weak host" model
treats the host as one system with zero or more addresses on every treats the host as one system with zero or more addresses on every
interface, and capable of using any interface for any communication. interface, and capable of using any interface for any communication.
As noted there, neither model is completely satisfactory. For As noted there, neither model is completely satisfactory. For
example, a host with an addressless interface and a default route example, a host with an addressless interface and a default route
pointing to the interface will necessarily send packets using any pointing to the interface will necessarily send packets using any
address using that interface, and therefore be a de facto weak host. address using that interface, and therefore be a de facto weak host.
However, if the router upstream from the host implements BCP 38 If the router upstream from such a host implements BCP 38 Ingress
Ingress Filtering [RFC2827], such as by implementing uRPF on each Filtering [RFC2827], such as by implementing uRPF on each interface,
interface, the router is configured to only permit communication by the router will prevent communication by weak hosts.
strong hosts.
+-----------------+ +-----------------+
| | | |
| MIF Router +---/--- other interfaces | MIF Router +---/--- other interfaces
| | | |
+---+---------+---+ +---+---------+---+
| | Two interfaces sharing a prefix | | Two interfaces sharing a prefix
--+-+-- --+-+-- --+-+-- --+-+--
| | | |
+--+---------+--+ +--+---------+--+
skipping to change at page 5, line 23 skipping to change at page 5, line 26
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]
[RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the
Router Advertisement would normally signal the availability of DHCPv6 Router Advertisement would normally signal the availability of DHCPv6
[RFC3315] and the host would use it to configure its addresses. In [RFC3315] 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 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 link for some reason) it will be generally the case that the
configured addresses match one of the prefixes advertised in a Router configured addresses match one of the prefixes advertised in a Router
Advertisement that are supposed to be in that link. 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 39 skipping to change at page 6, line 39
not "wrong", but can be inefficient. Therefore the host would do not "wrong", but can be inefficient. Therefore the host would do
well to select the appropriate router itself. well to select the appropriate router itself.
Since the host derives fundamental default routing information from Since the host derives fundamental default routing information from
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. In some circumstances the setting of the L and A flags in the PIO.
both L and A might be zero.
Although this does not violate the existing standard [RFC4861], such In some circumstances both L and A might be zero. If SLAAC is not
a PIO has not previously been common, and it is possible that wanted (A=0) and there is no reason to announce an on-link prefix
existing host implementations simply ignore such a PIO or that a (L=0), a PIO SHOULD be sent to inform hosts that the prefix is
router implementation rejects such a PIO as a configuration error. source-routed by the router in question. Although this does not
Newer implementations that support this mechanism will need to be violate the existing standard [RFC4861], such a PIO has not
updated accordingly: a host SHOULD NOT ignore a PIO simply because previously been common, and it is possible that existing host
both L and A flags are cleared; a router SHOULD be able to send such implementations simply ignore such a PIO or that a router
a PIO. 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.
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 direct implication of Section 2.1 is that, if the network uses a
routing protocol, the routing protocols used in multihomed networks routing protocol, the routing protocols used in multihomed networks
SHOULD implement source-prefix based egress routing. Network designs SHOULD implement source-prefix based egress routing. Network designs
exist that can usefully limit themselves to static routing (such a a exist that can usefully limit themselves to static routing (such as a
simple tree network), or may internally use no routers at all, such 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 as a single LAN with two CE routers, each of which leads to a
different upstream network. 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), zero or more contain zero or more Prefix information Options (PIOs), zero or more
skipping to change at page 8, line 46 skipping to change at page 8, line 46
In more complex cases, wherein routers advertise RAs for multiple In more complex cases, wherein routers advertise RAs for multiple
prefixes whether or not they have direct or isolated upstream prefixes whether or not they have direct or isolated upstream
connectivity, the host is dependent on the routing system already. connectivity, the host is dependent on the routing system already.
If the host gives the packet to a router advertising its source 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 prefix, it should be able to depend on the router to do the right
thing. thing.
3.3. Source Address Selection 3.3. Source Address Selection
There is an interaction with Default Address Selection [RFC6724]. There is an interaction with Default Address Selection [RFC6724]. A
Rule 5.5 of that specification states that the source address used to host following the recommendation in the previous section will store
send to a given destination address should if possible be chosen from information about which next-hops advertised which prefixes. Rule
a prefix known to be advertised by the first-hop router for that 5.5 of RFC 6724 states that the source address used to send to a
destination. This selection rule would be applicable in a host given destination address should if possible be chosen from a prefix
following the recommendation in the previous section. 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.
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 GUA destination that is not on-link) message sent by (Redirect for a GUA destination that is not on-link) message sent by
a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD
apply off-link redirects only for the specific pair of source and apply 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 may
need to contain appropriate source-specific entries. need to contain appropriate source-specific entries.
skipping to change at page 10, line 25 skipping to change at page 10, line 29
There might be a small privacy improvement, however: with the current There might be a small privacy improvement, however: 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,
Juliusz Chroboczek, Toerless Eckert, David Farmer, Pierre Pfister, Juliusz Chroboczek, Toerless Eckert, David Farmer, Dusan Mudric,
Mark Smith, Dusan Mudric, and James Woodyatt. Tadahisa Okimoto, Pierre Pfister, 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 12, line 5 skipping to change at page 12, line 5
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011, DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>. <http://www.rfc-editor.org/info/rfc6092>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>. <http://www.rfc-editor.org/info/rfc7084>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<http://www.rfc-editor.org/info/rfc7157>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
Appendix A. Change Log Appendix A. Change Log (RFC Editor: please delete)
Initial Version: 2015-08-05 Initial Version: 2015-08-05
Version 01: Update text on PIOs, added text on Redirects, and Version 01: Update text on PIOs, added text on Redirects, and
clarified the concept of a "simple" network, 2015-08-13. clarified the concept of a "simple" network, 2015-08-13.
Version 02: Clarifications after WG discussions, 2015-08-19. Version 02: Clarifications after WG discussions, 2015-08-19.
Version 03: More clarifications after more WG discussions, Version 03: More clarifications after more WG discussions,
especially adding stateful firewalls, uRPF, and more precise especially adding stateful firewalls, uRPF, and more precise
skipping to change at page 12, line 35 skipping to change at page 12, line 40
* Questions regarding RFC 1122's strong and weak host models. * Questions regarding RFC 1122's strong and weak host models.
This model is, strictly speaking, neither, but is most similar This model is, strictly speaking, neither, but is most similar
to the strong host model. to the strong host model.
* Some wording errors. * Some wording errors.
* Requests for discussion of the handling of the RIO, PIO, and * Requests for discussion of the handling of the RIO, PIO, and
Default Router List in an RA. Default Router List in an RA.
WG Versions 00-02: More clarifications after more WG discussions,
2015-11-03.
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. 16 change blocks. 
30 lines changed or deleted 45 lines changed or added

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