draft-ietf-6man-multi-homed-host-03.txt   draft-ietf-6man-multi-homed-host-04.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: June 17, 2016 December 15, 2015 Expires: August 21, 2016 February 18, 2016
Routing packets from hosts in a multi-prefix network Routing packets from hosts in a multi-prefix network
draft-ietf-6man-multi-homed-host-03 draft-ietf-6man-multi-homed-host-04
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. This host behavior may interact with source address filters. This host behavior may interact with source address
selection in a given implementation, but logically follows it. Given selection in a given implementation, but logically follows it. Given
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 June 17, 2016. This Internet-Draft will expire on August 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 51 skipping to change at page 3, line 51
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 RA, is a form of [RFC1122]'s Strong that advertised the prefix in its RA, is a form of [RFC1122]'s Strong
ES (e.g. Host) Model, discussed in section 3.3.4.2 of that document. ES (e.g. Host) Model, discussed in section 3.3.4.2 of that document.
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 a link-local-only 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.
If the router upstream from such a host implements BCP 38 Ingress If the router upstream from such a host implements BCP 38 Ingress
Filtering [RFC2827], such as by implementing uRPF on each interface, Filtering [RFC2827], such as by implementing uRPF on each interface,
the router might prevent communication by weak hosts. the router might prevent communication by weak hosts.
+-----------------+ +-----------------+
| | | |
| MIF Router +---/--- other interfaces | MIF Router +---/--- other interfaces
| | | |
skipping to change at page 7, line 21 skipping to change at page 7, line 21
that can usefully limit themselves to static routing (such as a 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), or zero or
Route Information Options (RIOs), or a Default Router List. In their more Route Information Options (RIOs). In their original intent,
original intent, these indicate general information to a host: "these these indicate general information to a host: "the router whose
are your default routers", "you might create or be configured with an address is found in the source address field of this packet is your
address in this prefix", or "this router would be a good place to default router", "you might create an address in this prefix", or
send traffic directed to a given destination prefix". In a multi- "this router would be a good place to send traffic directed to a
homed network implementing source/destination routing, the given destination prefix". In a multi-homed network implementing
interpretation of a default router list or an RIO has to be modified source/destination routing, the interpretation of default router or
with the words "if the source address is in one of the prefixes I an RIO has to be modified with the words "if the source address is in
advertise in a PIO". Additionally, the PIO must be reinterpreted to one of the prefixes I advertise in a PIO". Additionally, the PIO
also imply that the advertising router would be a reasonable first must be reinterpreted to also imply that the advertising router would
hop for any packet using a source address in any advertised prefix. be a reasonable first hop for any packet using a source address in
any advertised prefix.
+---------+ | +---------+ |
( 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 is multihomed, and 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 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 prefix PA) and Bob-B (to upstream network B and advertising prefix
B'). If Bob is responding to a message from Alice, his choice of PB). If Bob is responding to a message from Alice, his choice of
source address is forced to be the address Alice used as a source address is forced to be the address Alice used as a
destination (which we may presume to have been in prefix A'). Hence, destination (which we may presume to have been in prefix PA). Hence,
Bob created or was assigned an address in A', and can only reasonably 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 were 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 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 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 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 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. 38 discard 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 A' or B'. 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 is modified as follows: A host SHOULD select
default routers for each prefix it is assigned an address in. default routers for each prefix it is assigned an address in.
Routers that have advertised the prefix in its Router Advertisement Routers that have advertised the prefix in its Router Advertisement
message SHOULD be preferred over routers that do not advertise the message SHOULD be preferred over routers that do not advertise the
skipping to change at page 9, line 5 skipping to change at page 9, line 4
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 would therefore be applicable in a host following
the recommendation in the previous section. 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 destination that is not on-link) message sent by a
a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply
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 may
need to contain appropriate source-specific entries. need to contain appropriate source-specific entries.
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.
skipping to change at page 10, line 30 skipping to change at page 10, line 30
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, Dusan Mudric, Juliusz Chroboczek, Toerless Eckert, David Farmer, Dusan Mudric,
Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith, and Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith, Bob
James Woodyatt. Hinden, 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/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>. November 2005, <http://www.rfc-editor.org/info/rfc4191>.
skipping to change at page 11, line 22 skipping to change at page 11, line 22
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-rtgwg-dst-src-routing] [I-D.ietf-rtgwg-dst-src-routing]
Lamparter, D., "Destination/Source Routing", draft-ietf- Lamparter, D., "Destination/Source Routing", draft-ietf-
rtgwg-dst-src-routing-00 (work in progress), October 2015. rtgwg-dst-src-routing-00 (work in progress), October 2015.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122, DOI 10.17487/
DOI 10.17487/RFC1122, October 1989, RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <http://www.rfc-editor.org/info/rfc3704>. 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862, DOI 10.17487/
DOI 10.17487/RFC4862, September 2007, RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
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,
skipping to change at page 12, line 23 skipping to change at page 12, line 23
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., [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
and D. Wing, "IPv6 Multihoming without Network Address and D. Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
<http://www.rfc-editor.org/info/rfc7157>. <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/
DOI 10.17487/RFC7217, April 2014, RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
Appendix A. Change Log (RFC Editor: please delete) 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.
 End of changes. 18 change blocks. 
45 lines changed or deleted 47 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/