draft-ietf-6man-multi-homed-host-02.txt   draft-ietf-6man-multi-homed-host-03.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: May 6, 2016 November 3, 2015 Expires: June 17, 2016 December 15, 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-02 draft-ietf-6man-multi-homed-host-03
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. This host behavior may interact with source address
selection in a given implementation, but logically follows it. Given
This host behavior may interact with source address selection in a that the network or host is, or appears to be, multihomed with
given implementation, but logically follows it. Given that the multiple provider-allocated addresses, that the host has elected to
network or host is, or appears to be, multihomed with multiple use a source address in a given prefix, and that some but not all
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 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 6, 2016. This Internet-Draft will expire on June 17, 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 42 skipping to change at page 2, line 42
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 (RFC Editor: please delete) . . . . . . . 12 Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 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
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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.
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 will prevent communication by weak hosts. the router might prevent communication by weak hosts.
+-----------------+ +-----------------+
| | | |
| MIF Router +---/--- other interfaces | MIF Router +---/--- other interfaces
| | | |
+---+---------+---+ +---+---------+---+
| | Two interfaces sharing a prefix | | Two interfaces sharing a prefix
--+-+-- --+-+-- --+-+-- --+-+--
| | | |
+--+---------+--+ +--+---------+--+
skipping to change at page 7, line 9 skipping to change at page 7, line 9
implementations simply ignore such a PIO or that a router implementations simply ignore such a PIO or that a router
implementation rejects such a PIO as a configuration error. Newer implementation rejects such a PIO as a configuration error. Newer
implementations that support this mechanism will need to be updated implementations that support this mechanism will need to be updated
accordingly: a host SHOULD NOT ignore a PIO simply because both L and 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. 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, for example as
exist that can usefully limit themselves to static routing (such as a described in [I-D.ietf-rtgwg-dst-src-routing]. 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 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 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, Mark Smith, 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 11, line 12 skipping to change at page 11, line 17
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(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]
Lamparter, D., "Destination/Source Routing", draft-ietf-
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/RFC1122, October 1989, DOI 10.17487/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>.
skipping to change at page 12, line 43 skipping to change at page 13, line 5
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, 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.
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. 11 change blocks. 
15 lines changed or deleted 22 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/