draft-ietf-6man-multi-homed-host-08.txt   draft-ietf-6man-multi-homed-host-09.txt 
IPv6 Maintenance F. Baker IPv6 Maintenance F. Baker
Internet-Draft Cisco Systems Internet-Draft
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: February 20, 2017 August 19, 2016 Expires: February 24, 2017 August 23, 2016
First-hop router selection by hosts in a multi-prefix network First-hop router selection by hosts in a multi-prefix network
draft-ietf-6man-multi-homed-host-08 draft-ietf-6man-multi-homed-host-09
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 is assumed to implement BCP 38 ingress filtering, when the host that is assumed to implement BCP 38 ingress filtering, when the host
has multiple routers to choose from. It also applies to other has multiple routers to choose from. It also applies to other
scenarios such as the usage of stateful firewalls that effectively scenarios such as the usage of stateful firewalls that effectively
act as address-based filters. Host behavior in choosing a first-hop act as address-based filters. Host behavior in choosing a first-hop
router may interact with source address selection in a given router may interact with source address selection in a given
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 February 20, 2017. This Internet-Draft will expire on February 24, 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 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 using same prefix | | Two interfaces with subnets
--+-+-- --+-+-- | | from a common 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 for the
Strong Host Model. The statement is that the packet will go to the Strong Host Model. The proposal is that the packet will go to a
router that advertised a given prefix, but doesn't state what router that advertised a given prefix, but does not specify 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 a common prefix spanning two or
LANs shared by the host (as in Figure 1), the host might use each of more LANs shared by the host (as in Figure 1), the host might use
those LANs and meet the requirement. The Strong Host Model is not either of those LANs, according to this proposal. The Strong Host
stated in those terms, but in terms of the interface used, and would Model is not stated in those terms, but in terms of the interface
find such a MIF router quite confusing: used. A Strong host would treat such a MIF router as two separate
routers when obeying the rules from RFC 1122 as they apply in the
Strong case:
(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 6, line 45 skipping to change at page 6, line 45
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 they should use the (L=0), a PIO SHOULD be sent to inform hosts that they should use the
router in question as the first hop for packets with source addresses router in question as the first hop for packets with source addresses
in the PIO prefix. Although this does not violate the existing in the PIO prefix. An example case is the MIF router in Figure 1,
standard [RFC4861], such a PIO has not previously been common, and it which could send PIOs with A=L=0 for the common prefix. Although
is possible that existing host implementations simply ignore such a this does not violate the existing standard [RFC4861], such a PIO has
PIO or that existing router implementations are not capable of not previously been common, and it is possible that existing host
sending such a PIO. Newer implementations that support this implementations simply ignore such a PIO or that existing router
mechanism should be updated accordingly: implementations are not capable of sending such a PIO. Newer
implementations that support this mechanism should be updated
accordingly:
o A host SHOULD NOT ignore a PIO simply because both L and A flags o A host SHOULD NOT ignore a PIO simply because both L and A flags
are cleared (extending Section 6.3.4 of [RFC4861]). are cleared (extending Section 6.3.4 of [RFC4861]).
o A router SHOULD be able to send such a PIO (extending o A router SHOULD be able to send such a PIO (extending
Section 6.2.3 of [RFC4861]). Section 6.2.3 of [RFC4861]).
2.2. Expectations of multihomed networks 2.2. Expectations of multihomed networks
The mechanism specified in this document requires some form of The mechanism specified in this document requires some form of
skipping to change at page 13, line 37 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, WG Version 08-09: Fixes for IETF Last Call and IESG comments,
2016-08-15. 2016-08-15.
Authors' Addresses Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Santa Barbara, California
Santa Barbara, California 93117
USA USA
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. 
34 lines changed or deleted 36 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/