< draft-baker-6man-multi-homed-host-02.txt		draft-baker-6man-multi-homed-host-03.txt >
	IPv6 Maintenance F. Baker		IPv6 Maintenance F. Baker
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track B. Carpenter		Updates: 4861 (if approved) B. Carpenter
	Expires: February 22, 2016 Univ. of Auckland		Intended status: Standards Track Univ. of Auckland
	August 21, 2015		Expires: March 6, 2016 September 3, 2015
	Host routing in a multi-prefix network		Host routing in a multi-prefix network
	draft-baker-6man-multi-homed-host-02		draft-baker-6man-multi-homed-host-03
	Abstract		Abstract
	This note describes expected host behavior in a network that has more		This note describes expected IPv6 host behavior in a network that has
	than one prefix, each allocated by an upstream network that		more than one prefix, each allocated by an upstream network that
	implements BCP 38 filtering, when the host has multiple routers to		implements BCP 38 ingress filtering, when the host has multiple
	choose from.		routers to choose from. It also applies to other scenarios such as
			the usage of stateful firewalls that effectively act as address-based
			filters.
	This may interact with source address selection in a given		This host behavior may interact with source address selection in a
	implementation, but logically follows it - given that the network or		given implementation, but logically follows it. Given that the
	host is or appears to be multihomed with PA addresses, the host has		network or host is, or appears to be, multihomed with multiple
	elected to use source address in a given prefix, and some but not all		provider-allocated addresses, that the host has elected to use a
	neighboring routers are advertising that prefix in their RA PIOs, to		source address in a given prefix, and that some but not all
	which router should a host present its transmission?		neighboring routers are advertising that prefix in their Router
			Advertisement Prefix Information Options, this document specifies to
			which router a host should present its transmission. It updates RFC
			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 February 22, 2016.		This Internet-Draft will expire on March 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction and Applicability . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Sending context expected by the host . . . . . . . . . . . . 3		2. Sending context expected by the host . . . . . . . . . . . . 3
	2.1. Expectations the host has of the network . . . . . . . . 3		2.1. Expectations the host has of the network . . . . . . . . 3
	2.2. Expectations of multihomed networks . . . . . . . . . . . 4		2.2. Expectations of multihomed networks . . . . . . . . . . . 5
	3. Reasonable expectations of the host . . . . . . . . . . . . . 4		3. Reasonable expectations of the host . . . . . . . . . . . . . 5
			3.1. Default Router Selection . . . . . . . . . . . . . . . . 5
			3.2. Source Address Selection . . . . . . . . . . . . . . . . 5
			3.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6
			3.4. History . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 6		4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction and Applicability
	This note describes the expected behavior of an IPv6 [RFC2460] host		This note describes the expected behavior of an IPv6 [RFC2460] host
	in a network that has more than one prefix, each allocated by an		in a network that has more than one prefix, each allocated by an
	upstream network that implements BCP 38 [RFC2827] filtering, and in		upstream network that implements BCP 38 [RFC2827] ingress filtering,
	which the host is presented with a choice of routers. It expects		and in which the host is presented with a choice of routers. It
	that the network will implement some form of egress routing, so that		expects that the network will implement some form of egress routing,
	packets sent to a host outside the local network from a given ISP's		so that packets sent to a host outside the local network from a given
	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.
			BCP 38 filtering by ISPs is not the only scenario where such behavior
			is valuable. The combination of existing recommendations for home
			gateways [RFC6092] [RFC7084] can also result in such filtering.
			Another case is when the connections to the upstream networks include
			stateful firewalls, such that return packets in a stream will be
			discarded if they do not return via the firewall that created state
			for the outgoing packets. A similar cause of such discards is
			unicast reverse path forwarding (uRPF) [RFC3704].
			In this document, the term "filter" is used for simplicity to cover
			all such cases. In any case, one cannot assume the host to be aware
			whether an ingress filter, a stateful firewall, or any other type of
			filter is in place. Therefore, the only safe solution is to
			implement the features defined in this document.
	Note that, apart from ensuring that a message with a given source		Note that, apart from ensuring that a message with a given source
	address is given to a first-hop router that appears to know about the		address is given to a first-hop router that appears to know about the
	prefix in question, this specification provides no new guidance over		prefix in question, this specification is consistent with [RFC4861].
	that in [RFC4861].		Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC
			4861 will need to extend their implementations accordingly. This
			specification is fully consistent with [RFC6724] and implementers
			will need to add support for its Rule 5.5. Hosts that do not support
			these features may fail to communicate in the presence of filters as
			described above.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Sending context expected by the host		2. Sending context expected by the host
	2.1. Expectations the host has of the network		2.1. Expectations the host has of the network
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 39 ¶
	+----+----+ +--------+		+----+----+ +--------+
	| Host |		| Host |
	+---------+		+---------+
	Common LAN Case Disjoint LAN Case		Common LAN Case Disjoint LAN Case
	(Multihomed Network) (Multihomed Host)		(Multihomed Network) (Multihomed Host)
	Figure 1: Two simple networks		Figure 1: Two simple networks
	If there is no routing protocol among those routers, there is no		If there is no routing protocol among those routers, there is no
	mechanism by which packets can be deterministically forwarded between		mechanism by which packets can be deterministically forwarded between
	the routers (as described in BCP 84 [RFC3704]) in order to avoid BCP		the routers (as described in BCP 84 [RFC3704]) in order to avoid
	38 filters. Even if there was routing, it would result in an		filters. Even if there was routing, it would result in an indirect
	indirect route, rather than a direct route originating with the host;		route, rather than a direct route originating with the host; this is
	this is not "wrong", but can be inefficient. Therefore the host		not "wrong", but can be inefficient. Therefore the host would do
	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. In some circumstances
	both L and A might be zero.		both L and A might be zero.
			Although this does not violate the existing standard [RFC4861], such
			a PIO has not previously been common, and it is possible that
			existing host implementations simply ignore such a PIO or that a
			router 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 routing protocols used		The direct implication of Section 2.1 is that routing protocols used
	in multihomed networks SHOULD be capable of source-prefix based		in multihomed networks SHOULD be capable of source-prefix based
	egress routing, and that multihomed networks SHOULD deploy them.		egress routing, and that multihomed networks SHOULD deploy them.
	3. Reasonable expectations of the host		3. Reasonable expectations of the host
	Modern hosts maintain a fair bit of history, in terms of what has		3.1. Default Router Selection
	historically 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 includes a next hop address for use when a packet is
	sent to the indicated address.
	When a host makes a successful exchange with a remote destination
	using a particular source address, and the host has received a PIO
	that matches that source address in an RA, then the host SHOULD
	include the prefix in such history, whatever the setting of the L and
	A flags in the PIO. On subsequent attempts to communicate with that
	destination, if it has an address in that prefix at that time, a host
	MAY use an address in the remembered prefix for the session.
	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
	prefix.		prefix.
	As a result of doing so, when a host sends a packet using a source		As a result of doing so, when a host sends a packet using a source
	address in one of those prefixes and has no history directing it		address in one of those prefixes and has no history directing it
	otherwise, it SHOULD send it to the indicated default router. In the		otherwise, it SHOULD send it to the indicated default router. In the
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 47 ¶
	This will also apply in more complex networks, even when more than		This will also apply in more complex networks, even when more than
	one physical or virtual interface is involved.		one physical or virtual interface is involved.
	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.2. Source Address Selection
	There is an interaction with Default Address Selection [RFC6724].		There is an interaction with Default Address Selection [RFC6724].
	Rule 5.5 of that specification states that the source address used to		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		send to a given destination address should if possible be chosen from
	a prefix known to be advertised by the first-hop router for that		a prefix known to be advertised by the first-hop router for that
	destination. This selection rule would be applicable in a host		destination. This selection rule would be applicable in a host
	following the recommendation in the previous paragraph.		following the recommendation in the previous paragraph.
			3.3. 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.
			3.4. History
			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
			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
			indicated address.
			When such a host makes a successful exchange with a remote
			destination using a particular address pair, and the host has
			previously received a PIO that matches the source address, then the
			host SHOULD include the prefix in such history, whatever the setting
			of the L and A flags in the PIO. On subsequent attempts to
			communicate with that destination, if it has an address in that
			prefix at that time, a host MAY use an address in the remembered
			prefix for the session.
	4. Residual issues		4. Residual issues
	In a network where routers on a link run a routing protocol and are		Consider a network where routers on a link run a routing protocol and
	configured with the same information. That is on each link all		are configured with the same information. Thus, on each link all
	routers advertise all prefixes on the link, the assumption that		routers advertise all prefixes on the link. The assumption that
	packets will be forwarded to the appropriate egress by the local		packets will be forwarded to the appropriate egress by the local
	routing system might cause at least one extra hop in 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		network (from the host to the wrong router, and from there to another
	router on the same link).		router on the same link).
	In a slightly more complex situation such as the disjoint LAN case of		In a slightly more complex situation such as the disjoint LAN case of
	Figure 1, which happens to be one of the authors' home plus corporate		Figure 1, which happens to be one of the authors' home plus corporate
	home-office configuration, the two upstream routers might be on		home-office configuration, the two upstream routers might be on
	different LANs and therefore different subnets (e.g., the host is		different LANs and therefore different subnets (e.g., the host is
	itself multi-homed). In that case, there is no way for the "wrong"		itself multi-homed). In that case, there is no way for the "wrong"
	skipping to change at page 6, line 34 ¶		skipping to change at page 7, line 16 ¶
	responsibility to memorize and select the best first-hop as described		responsibility to memorize and select the best first-hop as described
	in Section 3.		in Section 3.
	5. IANA Considerations		5. IANA Considerations
	This memo asks the IANA for no new parameters.		This memo asks the IANA for no new parameters.
	6. Security Considerations		6. Security Considerations
	This document does not create any new security or privacy exposures.		This document does not create any new security or privacy exposures.
			It is intended to avoid connectivity issues in the presence of BCP 38
			ingress filters or stateful firewalls combined with multihoming.
	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, Pierre Pfister, Mark Smith, and		Juliusz Chroboczek, Toerless Eckert, David Farmer, Pierre Pfister,
	Dusan Mudric.		Mark Smith, Dusan Mudric, 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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/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>.
			[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>.
			[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>.
	8.2. Informative References		8.2. Informative References
	[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>.
	[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		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, DOI 10.17487/		Address Autoconfiguration", RFC 4862,
	RFC4862, September 2007,		DOI 10.17487/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>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
	"Default Address Selection for Internet Protocol Version 6		Capabilities in Customer Premises Equipment (CPE) for
	(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,		Providing Residential IPv6 Internet Service", RFC 6092,
	<http://www.rfc-editor.org/info/rfc6724>.		DOI 10.17487/RFC6092, January 2011,
			<http://www.rfc-editor.org/info/rfc6092>.
			[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
			Requirements for IPv6 Customer Edge Routers", RFC 7084,
			DOI 10.17487/RFC7084, November 2013,
			<http://www.rfc-editor.org/info/rfc7084>.
	[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, DOI 10.17487/		Autoconfiguration (SLAAC)", RFC 7217,
	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
	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,
			especially adding stateful firewalls, uRPF, and more precise
			discussion of RFC 4861, 2015-09-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
End of changes. 30 change blocks.
	71 lines changed or deleted		136 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/