Network Working Group F. Baker
Internet-Draft Cisco Systems
Intended status: Standards Track B. Carpenter
Expires: February 6, 2016 Univ. of Auckland
August 5, 2015
Host routing in a multi-prefix network
draft-baker-6man-multi-homed-host-00
Abstract
This note describes expected host behavior in a network that has more
than one prefix, each allocated by an upstream network that
implements BCP 38 filtering.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Baker & Carpenter Expires February 6, 2016 [Page 1]
Internet-Draft Host routing in a multi-prefix network August 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Expectations the host has of the network . . . . . . . . . . 2
3. Reasonable expectations of the host . . . . . . . . . . . . . 3
4. Expectations of multihomed networks . . . . . . . . . . . . . 4
5. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
9.1. Normative References . . . . . . . . . . . . . . . . . . 4
9.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This note describes the expected behavior of an IPv6 [RFC2460] host
in a network that has more than one prefix, each allocated by an
upstream network that implements BCP 38 [RFC2827] filtering. It
expects that the network will implement some form of egress routing,
so that packets sent to a host outside the local network from a given
ISP's prefix will go to that ISP. If the packet is sent to the wrong
egress, it is liable to be discarded by the BCP 38 filter. However,
the mechanics of egress routing once the packet leaves the host are
out of scope. The question here is how the host interacts with that
network.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Expectations the host has of the network
A host receives on-link prefixes in a Router Advertisement [RFC4861],
which goes on to identify preference order among them and whether
they are usable by SLAAC [RFC4862] [RFC4941] [RFC7217], or whether
they must be assigned using DHCPv6 [RFC3315].
The simplest multihomed network implementation might be a LAN with
one or more hosts on it and two or more routers, one for each
upstream network. In such a network, there is no routing protocol,
and the two routers may not even know that the other is a router as
opposed to a host, apart from the fact that it is emitting Router
Baker & Carpenter Expires February 6, 2016 [Page 2]
Internet-Draft Host routing in a multi-prefix network August 2015
Advertisements (RAs). One might expect that the routers may or may
not receive each other's RAs and form an address in the other
router's prefix. However, all hosts in such a network might be
expected to create an address in each prefix so advertised.
Because there is no routing protocol among those routers, there is no
mechanism by which packets can be deterministically forwarded between
the routers (as described in BCP 84 [RFC3704]) in order to avoid BCP
38 filters. Even if there was, it would be an indirect route, rather
than a direct route originating with the host. Therefore the host
needs to select the appropriate router itself.
Since the host derives fundamental default routing information from
the RA, this implies that, on any network with multiple prefixes,
each prefix SHOULD be advertised by one of the attached routers, even
if addresses are being assigned using DHCPv6.
3. Reasonable expectations of the host
Modern hosts maintain a fair bit of history, in terms of what has
historically worked or not worked for a given address or prefix and
in some cases the effective window and MSS values for TCP. This
includes a next hop address for use when a packet is sent to the
indicated address.
A host SHOULD include the prefix it used in a successful exchange
with a remote address or prefix in such history. On subsequent
attempts to communicate with that remote address, if it has such an
address at that time, a host MAY use its address in the remembered
prefix for the exchange.
A host SHOULD select a "default gateway" for each prefix it uses to
obtain one of its own addresses. That router SHOULD be one of the
routers advertising the prefix in its RA. As a result of doing so,
when a host emits a datagram using a source address in one of those
prefixes and has no history directing it otherwise, it SHOULD send it
to the indicated "default gateway". In the "simplest" network
described in Section 2, that would get it to the only router that is
capable of getting it to the right ISP. This will also apply in more
complex networks, even when more than one physical or virtual
interface is involved.
There is an interaction with Default Address Selection [RFC6724].
Rule 5.5 of that specification states that the source address used to
send to a given destination address should if possible be chosen from
a prefix known to be advertised by the next-hop router for that
destination. This selection rule would be applicable in a host
following the recommendation in the previous paragraph.
Baker & Carpenter Expires February 6, 2016 [Page 3]
Internet-Draft Host routing in a multi-prefix network August 2015
4. Expectations of multihomed networks
The direct implication of Section 2 is that routing protocols used in
multihomed networks SHOULD be capable of source-prefix based egress
routing, and that multihomed networks SHOULD deploy them.
5. Residual issues
The assumption that packets will be forwarded to the appropriate
egress by the local routing system might cause at least one extra hop
in the local network (from the host to the wrong router, and from
there to another router on the same LAN but in a different subnet).
In some scenarios, where the local network is a highly constrained or
lossy wireless network, this extra hop may be a significant
performance handicap.
In a slightly more complex situation, which happens to be one of the
authors' home plus corporate home-office configuration, the two
upstream routers might be on different LANs and therefore different
subnets (e.g., the host is itself multi-homed). In that case, there
is no way for the "wrong" router to detect the existence of the
"right" router, or to route to it.
In such a case it is particularly important that hosts take the
responsibility to memorize and select the best first-hop as described
in Section 3.
6. IANA Considerations
This memo asks the IANA for no new parameters.
7. Security Considerations
This document does not create any new security or privacy exposures.
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Baker & Carpenter Expires February 6, 2016 [Page 4]
Internet-Draft Host routing in a multi-prefix network August 2015
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
9.2. Informative References
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI 10.17487/
RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/
RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
Baker & Carpenter Expires February 6, 2016 [Page 5]
Internet-Draft Host routing in a multi-prefix network August 2015
Appendix A. Change Log
Initial Version: date
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Baker & Carpenter Expires February 6, 2016 [Page 6]