draft-ietf-6man-slaac-renum-01.txt		draft-ietf-6man-slaac-renum-02.txt
	IPv6 Maintenance (6man) Working Group F. Gont		IPv6 Maintenance (6man) Working Group F. Gont
	Internet-Draft SI6 Networks		Internet-Draft SI6 Networks
	Updates: 4861, 4862 (if approved) J. Zorz		Updates: 4861, 4862 (if approved) J. Zorz
	Intended status: Standards Track 6connect		Intended status: Standards Track 6connect
	Expires: February 27, 2021 R. Patterson		Expires: July 23, 2021 R. Patterson
	Sky UK		Sky UK
	August 26, 2020		January 19, 2021
	Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)		Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)
	to Flash Renumbering Events		to Flash Renumbering Events
	draft-ietf-6man-slaac-renum-01		draft-ietf-6man-slaac-renum-02
	Abstract		Abstract
	In renumbering scenarios where an IPv6 prefix suddenly becomes		In renumbering scenarios where an IPv6 prefix suddenly becomes
	invalid, hosts on the local network will continue using stale		invalid, hosts on the local network will continue using stale
	prefixes for an unacceptably long period of time, thus resulting in		prefixes for an unacceptably long period of time, thus resulting in
	connectivity problems. This document improves the reaction of IPv6		connectivity problems. This document improves the reaction of IPv6
	Stateless Address Autoconfiguration to such renumbering scenarios.		Stateless Address Autoconfiguration to such renumbering scenarios.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 27, 2021.		This Internet-Draft will expire on July 23, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4		3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4
	3.1. Renumbering without Explicit Signaling . . . . . . . . . 4		3.1. Renumbering without Explicit Signaling . . . . . . . . . 4
	3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5		3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5
	4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6		4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6
	4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7		4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7
	4.1.1. Router Configuration Variables . . . . . . . . . . . 7		4.1.1. Router Configuration Variables . . . . . . . . . . . 7
	4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7		4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 8
	4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7		4.3. Interface Initialization . . . . . . . . . . . . . . . . 9
	4.3. Interface Initialization . . . . . . . . . . . . . . . . 8
	4.4. Conveying Information in Router Advertisement (RA)		4.4. Conveying Information in Router Advertisement (RA)
	Messages . . . . . . . . . . . . . . . . . . . . . . . . 8		Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.5. Recovery from Stale Configuration Information without		4.5. Recovery from Stale Configuration Information without
	Explicit Signaling . . . . . . . . . . . . . . . . . . . 8		Explicit Signaling . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9		6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
	6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9		6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 10
	6.1.1. Router Configuration Variables . . . . . . . . . . . 9		6.1.1. Router Configuration Variables . . . . . . . . . . . 10
	6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9		6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 11
	6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10		6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 11
	6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10		6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 11
	6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10
	6.3. Conveying Information in Router Advertisement (RA)		6.3. Conveying Information in Router Advertisement (RA)
	Messages . . . . . . . . . . . . . . . . . . . . . . . . 10		Messages . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.4. Recovery from Stale Configuration Information without		6.4. Recovery from Stale Configuration Information without
	Explicit Signaling . . . . . . . . . . . . . . . . . . . 10		Explicit Signaling . . . . . . . . . . . . . . . . . . . 11
	6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10		6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 11
	6.5. Other mitigations implemented in products . . . . . . . . 11		6.5. Other mitigations implemented in products . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15		Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 16
	A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15		A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 16
	A.2. On a Possible Improvement to Source Address Selection . . 16		A.2. On a Possible Improvement to Source Address Selection . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	IPv6 network renumbering is expected to take place in a planned		IPv6 network renumbering is expected to take place in a planned
	manner, with old/stale prefixes being phased-out via reduced prefix		manner, with old/stale prefixes being phased-out via reduced prefix
	lifetimes while new prefixes (with normal lifetimes) are introduced.		lifetimes while new prefixes (with normal lifetimes) are introduced.
	However, there are a number of scenarios that may lead to the so-		However, there are a number of scenarios that may lead to the so-
	called "flash-renumbering" events, where the prefix being employed on		called "flash-renumbering" events, where the prefix being employed on
	a network suddenly becomes invalid and replaced by a new prefix		a network suddenly becomes invalid and replaced by a new prefix
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 48 ¶
	7 days or 30 days (respectively) to recover from a network problem is		7 days or 30 days (respectively) to recover from a network problem is
	simply unacceptable.		simply unacceptable.
	Use of more appropriate timers in Router Advertisement messages can		Use of more appropriate timers in Router Advertisement messages can
	help limit the amount of time that hosts will maintain stale		help limit the amount of time that hosts will maintain stale
	configuration information. Additionally, hosts are normally in a		configuration information. Additionally, hosts are normally in a
	position to infer that a prefix has become stale -- for example, if a		position to infer that a prefix has become stale -- for example, if a
	given router ceases to advertise an existing prefix and at the same		given router ceases to advertise an existing prefix and at the same
	time starts to advertise a new prefix.		time starts to advertise a new prefix.
	Section 4.1.1 recommends the use of more appropriate lifetimes for		Section 4.1.1 recommends the use of more appropriate default
	PIOs, while Section 4.1.2 proposes to cap the accepted Valid Lifetime		lifetimes for PIOs, while Section 4.5 specifies a local policy that
	and Preferred Lifetime values at hosts, such that more appropriate		SLAAC hosts can implement to heuristically infer that network
	values are employed even in the presence of legacy routers.		configuration information has changed, such that stale configuration
			information can be phased out.
	Section 4.5 specifies a local policy that SLAAC hosts can implement
	to heuristically infer that network configuration information has
	changed, such that stale configuration information can be phased out.
	3.2. Renumbering with Explicit Signaling		3.2. Renumbering with Explicit Signaling
	In scenarios where a local router is aware about the renumbering		In scenarios where a local router is aware about the renumbering
	event, it may try to phase out the stale network configuration		event, it may try to phase out the stale network configuration
	information. In these scenarios, there are two aspects to be		information. In these scenarios, there are two aspects to be
	considered:		considered:
	o The amount of time during which the router should continue trying		o The amount of time during which the router should continue trying
	to deprecate the stale network configuration information		to deprecate the stale network configuration information
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 28 ¶
	aforementioned updates are mostly orthogonal, and mitigate different		aforementioned updates are mostly orthogonal, and mitigate different
	aspects of SLAAC that prevent a timely reaction to flash renumbering		aspects of SLAAC that prevent a timely reaction to flash renumbering
	events.		events.
	o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs		o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs
	(Section 4.1.1):		(Section 4.1.1):
	This helps limit the amount of time a host will employ stale		This helps limit the amount of time a host will employ stale
	information, and also limits the amount of time a router needs to		information, and also limits the amount of time a router needs to
	try to obsolete stale information.		try to obsolete stale information.
	o Cap the received Valid Lifetime and Preferred Lifetime of PIOs
	(Section 4.1.2):
	This helps limit the amount of time a host will employ stale
	information, even in the presence of legacy ([RFC4861]) routers.
	o Honor PIOs with small Valid Lifetimes (Section 4.2):		o Honor PIOs with small Valid Lifetimes (Section 4.2):
	This allows routers to invalidate stale prefixes, since otherwise		This allows routers to invalidate stale prefixes, since otherwise
	[RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime		[RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime
	smaller than two hours.		smaller than two hours.
	o Recommend routers to retransmit configuration information upon		o Recommend routers to retransmit configuration information upon
	interface initialization/reinitialization (Section 4.3):		interface initialization/reinitialization (Section 4.3):
	This helps spread the new information in a timelier manner, and		This helps spread the new information in a timelier manner, and
	also deprecate stale information via host-side heuristics (see		also deprecate stale information via host-side heuristics (see
	Section 4.5).		Section 4.5).
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 9 ¶
	o Infer stale network configuration information from received RAs		o Infer stale network configuration information from received RAs
	(Section 4.5):		(Section 4.5):
	This allows hosts to deprecate stale network configuration		This allows hosts to deprecate stale network configuration
	information, even in the absence of explicit signaling.		information, even in the absence of explicit signaling.
	4.1. More Appropriate Lifetime Values		4.1. More Appropriate Lifetime Values
	4.1.1. Router Configuration Variables		4.1.1. Router Configuration Variables
	[TBD]		The default values of the Preferred Lifetime and the Valid Lifetime
			of PIOs are updated as follows:
	4.1.2. Processing of PIO Lifetimes at Hosts		AdvPreferredLifetime: max(AdvDefaultLifetime, 3 *
			MaxRtrAdvInterval)
	[TBD]		AdvValidLifetime: 2 * AdvPreferredLifetime
			where:
			AdvPreferredLifetime:
			Value to be placed in the "Preferred Lifetime" field of the PIO.
			AdvValidLifetime:
			Value to be placed in the "Valid Lifetime" field of the PIO.
			AdvDefaultLifetime:
			Value to be placed in the "Router Lifetime" field of the Router
			Advertisement message that will carry the PIO.
			max():
			A function that computes the maximum of its arguments.
			NOTE:
			[RFC4861] specifies the default value of MaxRtrAdvInterval as 600
			seconds, and the default value of AdvDefaultLifetime as 3 *
			MaxRtrAdvInterval. Therefore, when employing default values for
			MaxRtrAdvInterval and AdvDefaultLifetime, the default values of
			AdvPreferredLifetime and AdvValidLifetime become 1800 seconds (30
			minutes) and 3600 seconds (1 one hour), respectively. We note
			that when implementing BCP202 [RFC7772], AdvDefaultLifetime will
			typically be in the range of 45-90 minutes, and therefore the
			default value of AdvPreferredLifetime will be in the range 45-90
			minutes, while the default value of AdvValidLifetime will be in
			the range of 90-180 minutes.
			RATIONALE:
			* The default values of the PIO lifetimes should be such that,
			under normal circumstances (including some packet loss), the
			associated timers are refreshed/reset, but in the presence of
			network failures (such as network configuration information
			becoming stale), some fault recovering action (such as
			deprecating the corresponding addresses and subsequently
			removing them) is triggered.
			* In the context of [RFC8028], where it is clear that the use of
			addresses configured for a given prefix is tied to the next-hop
			router that advertised the prefix, the "Preferred Lifetime" of
			a PIO should not be larger than the "Router Lifetime" of Router
			Advertisement messages. Some leeway should be provided for the
			"Valid Lifetime" of PIOs, to cope with transient network
			problems. As a result, this document updates [RFC4861] such
			that the default Valid Lifetime (AdvValidLifetime) and the
			default Preferred Lifetime (AdvPreferredLifetime) of PIOs are
			specified as a function of the "Router Lifetime"
			(AdvDefaultLifetime) of Router Advertisement messages. In the
			absence of RAs that refresh information, addresses configured
			for previously-advertised prefixes become deprecated in a
			timelier manner, and thus Rule 3 of [RFC6724] will cause other
			configured addresses (if available) to be preferred.
			* The expression above computes the maximum between
			AdvDefaultLifetime and "3 * MaxRtrAdvInterval" (the default
			value of AdvDefaultLifetime, as per [RFC4861]) to cope with the
			case where an operator might simply want to disable one local
			router for maintenance, without disabling the use of the
			corresponding prefixes on the local network (e.g., on a multi-
			router network). [RFC4862] implementations would otherwise
			deprecate the corresponding prefixes. Similarly, [RFC8028]
			implementations would likely behave in the same way.
	4.2. Honor Small PIO Valid Lifetimes		4.2. Honor Small PIO Valid Lifetimes
	The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is		The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is
	replaced with the following text:		replaced with the following text:
	e) If the advertised prefix is equal to the prefix of an address		e) If the advertised prefix is equal to the prefix of an address
	configured by stateless autoconfiguration in the list, the valid		configured by stateless autoconfiguration in the list, the valid
	lifetime and the preferred lifetime of the address should be		lifetime and the preferred lifetime of the address should be
	updated by processing the Valid Lifetime and the Preferred		updated by processing the Valid Lifetime and the Preferred
	Lifetime (respectively) in the received advertisement.		Lifetime (respectively) in the received advertisement.
	NOTE:
	"Processing" the Valid Lifetime and Preferred Lifetime includes
	capping the received values as specified in Section 4.1.2 of this
	document.
	RATIONALE:		RATIONALE:
	* This change allows hosts to react to the information provided		* This change allows hosts to react to the information provided
	by a router that has positive knowledge that a prefix has		by a router that has positive knowledge that a prefix has
	become invalid.		become invalid.
	* The behavior described in RFC4862 had been incorporated during		* The behavior described in RFC4862 had been incorporated during
	the revision of the original IPv6 Stateless Address		the revision of the original IPv6 Stateless Address
	Autoconfiguration specification ([RFC1971]). At the time, the		Autoconfiguration specification ([RFC1971]). At the time, the
	IPNG working group decided to mitigate the attack vector		IPNG working group decided to mitigate the attack vector
	skipping to change at page 9, line 44 ¶		skipping to change at page 11, line 4 ¶
	6.1.1.2. radvd(8)		6.1.1.2. radvd(8)
	The radvd(8) daemon [radvd], normally employed by Linux-based router		The radvd(8) daemon [radvd], normally employed by Linux-based router
	implementations, currently employs different default lifetimes than		implementations, currently employs different default lifetimes than
	those recommended in [RFC4861]. radvd(8) employs the following		those recommended in [RFC4861]. radvd(8) employs the following
	default values [radvd.conf]:		default values [radvd.conf]:
	o Preferred Lifetime: 14400 seconds (4 hours)		o Preferred Lifetime: 14400 seconds (4 hours)
	o Valid Lifetime: 86400 seconds (1 day)		o Valid Lifetime: 86400 seconds (1 day)
	This is not following the specific recommendation in this document,		This is not following the specific recommendation in this document,
	bu is already a deviation from the current standards.		bu is already a deviation from the current standards.
	6.1.2. Processing of PIO Lifetimes at Hosts
	6.1.2.1. NetworkManager
	NetworkManager [NetworkManager], user-space SLAAC implementation
	employed by some Linux-based operating systems (such as Fedora or
	Ubuntu), caps the lifetimes of the received PIOs as recommended in
	this document.
	6.1.2.2. slaacd(8)
	slaacd(8) [slaacd], a user-space SLAAC implementation employed by
	OpenBSD, caps the lifetimes of the received PIOs as recommended in
	this document.
	6.1.2.3. systemd-networkd
	systemd-networkd [systemd], a user-space SLAAC implementation
	employed by some Linux-based operating systems, caps the lifetimes of
	the received PIOs as recommended in this document.
	6.2. Honor Small PIO Valid Lifetimes		6.2. Honor Small PIO Valid Lifetimes
	6.2.1. Linux Kernel		6.2.1. Linux Kernel
	A Linux kernel implementation of this document has been committed to		A Linux kernel implementation of this document has been committed to
	the net-next tree. The implementation was produced in April 2020 by		the net-next tree. The implementation was produced in April 2020 by
	Fernando Gont <fgont@si6networks.com>. The corresponding patch can		Fernando Gont <fgont@si6networks.com>. The corresponding patch can
	be found at: <https://patchwork.ozlabs.org/project/netdev/		be found at: <https://patchwork.ozlabs.org/project/netdev/
	patch/20200419122457.GA971@archlinux-current.localdomain/>		patch/20200419122457.GA971@archlinux-current.localdomain/>
	skipping to change at page 11, line 36 ¶		skipping to change at page 12, line 20 ¶
	o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3		o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3
	of [RFC4862] (discussed in Section 4.2 of this document), upon		of [RFC4862] (discussed in Section 4.2 of this document), upon
	first occurrence of a stale prefix, this implementation will		first occurrence of a stale prefix, this implementation will
	employ a decreasing Valid Lifetime, starting from 2 hours (7200		employ a decreasing Valid Lifetime, starting from 2 hours (7200
	seconds), as opposed to a Valid Lifetime of 0.		seconds), as opposed to a Valid Lifetime of 0.
	7. Security Considerations		7. Security Considerations
	The protocol update in Section 4.2 could allow an on-link attacker to		The protocol update in Section 4.2 could allow an on-link attacker to
	perform a Denial of Service attack againts local hosts, by sending a		perform a Denial of Service attack against local hosts, by sending a
	forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of		forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of
	that packet, local hosts would invalidate the corresponding prefix,		that packet, local hosts would invalidate the corresponding prefix,
	and therefore remove any addresses configured for that prefix,		and therefore remove any addresses configured for that prefix,
	possibly terminating e.g. TCP connections employing such addresses.		possibly terminating e.g. TCP connections employing such addresses.
	However, an attacker may achieve similar effects via a number for ND-		However, an attacker may achieve similar effects via a number for ND-
	based attack vectors, such as directing traffic to a non-existing		based attack vectors, such as directing traffic to a non-existing
	node until ongoing TCP connections time out, or performing a ND-based		node until ongoing TCP connections time out, or performing a ND-based
	man-in-the-middle (MITM) attack and subsequently forging TCP RST		man-in-the-middle (MITM) attack and subsequently forging TCP RST
	segments to cause on-going TCP connections to be aborted. Thus, for		segments to cause on-going TCP connections to be aborted. Thus, for
	all practical purposes, this attack vector does not really represent		all practical purposes, this attack vector does not really represent
	skipping to change at page 12, line 29 ¶		skipping to change at page 13, line 13 ¶
	Homburg.		Homburg.
	Fernando would like to thank Alejandro D'Egidio and Sander Steffann		Fernando would like to thank Alejandro D'Egidio and Sander Steffann
	for a discussion of these issues, which led to the publication of		for a discussion of these issues, which led to the publication of
	[I-D.ietf-v6ops-slaac-renum], and eventually to this document.		[I-D.ietf-v6ops-slaac-renum], and eventually to this document.
	Fernando would also like to thank Brian Carpenter who, over the		Fernando would also like to thank Brian Carpenter who, over the
	years, has answered many questions and provided valuable comments		years, has answered many questions and provided valuable comments
	that has benefited his protocol-related work.		that has benefited his protocol-related work.
	The problem discussed in this document has been previously documented
	by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update],
	and also in [RIPE-690].
	9. References		9. References
	9.1. Normative References		9.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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast		[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 36 ¶
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<https://www.rfc-editor.org/info/rfc4861>.		<https://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,		Address Autoconfiguration", RFC 4862,
	DOI 10.17487/RFC4862, September 2007,		DOI 10.17487/RFC4862, September 2007,
	<https://www.rfc-editor.org/info/rfc4862>.		<https://www.rfc-editor.org/info/rfc4862>.
			[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
			Consumption of Router Advertisements", BCP 202, RFC 7772,
			DOI 10.17487/RFC7772, February 2016,
			<https://www.rfc-editor.org/info/rfc7772>.
	[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by		[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
	Hosts in a Multi-Prefix Network", RFC 8028,		Hosts in a Multi-Prefix Network", RFC 8028,
	DOI 10.17487/RFC8028, November 2016,		DOI 10.17487/RFC8028, November 2016,
	<https://www.rfc-editor.org/info/rfc8028>.		<https://www.rfc-editor.org/info/rfc8028>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,		[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
	"Updates to the Special-Purpose IP Address Registries",		"Updates to the Special-Purpose IP Address Registries",
	BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,		BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
	<https://www.rfc-editor.org/info/rfc8190>.		<https://www.rfc-editor.org/info/rfc8190>.
	[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
	Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
	January 2019, <https://www.rfc-editor.org/info/rfc8504>.
	9.2. Informative References		9.2. Informative References
	[dhcpcd] Marples, R., "dhcpcd - a DHCP client",		[dhcpcd] Marples, R., "dhcpcd - a DHCP client",
	<https://roy.marples.name/projects/dhcpcd/>.		<https://roy.marples.name/projects/dhcpcd/>.
	[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network		[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network
	(updated with solution)", SI6 Networks Blog, February		(updated with solution)", SI6 Networks Blog, February
	2016, <https://www.si6networks.com/2016/02/16/quiz-weird-		2016, <https://www.si6networks.com/2016/02/16/quiz-weird-
	ipv6-traffic-on-the-local-network-updated-with-solution/>.		ipv6-traffic-on-the-local-network-updated-with-solution/>.
	[I-D.ietf-v6ops-cpe-slaac-renum]		[I-D.ietf-v6ops-cpe-slaac-renum]
	Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving		Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving
	the Reaction of Customer Edge Routers to Renumbering		the Reaction of Customer Edge Routers to Renumbering
	Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in		Events", draft-ietf-v6ops-cpe-slaac-renum-06 (work in
	progress), August 2020.		progress), December 2020.
	[I-D.ietf-v6ops-slaac-renum]		[I-D.ietf-v6ops-slaac-renum]
	Gont, F., Zorz, J., and R. Patterson, "Reaction of		Gont, F., Zorz, J., and R. Patterson, "Reaction of
	Stateless Address Autoconfiguration (SLAAC) to Flash-		Stateless Address Autoconfiguration (SLAAC) to Flash-
	Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work		Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work
	in progress), August 2020.		in progress), November 2020.
	[I-D.linkova-6man-default-addr-selection-update]
	Linkova, J., "Default Address Selection and Subnet
	Renumbering", draft-linkova-6man-default-addr-selection-
	update-00 (work in progress), March 2017.
	[IPNG-minutes]		[IPNG-minutes]
	IETF, "IPNG working group (ipngwg) Meeting Minutes",		IETF, "IPNG working group (ipngwg) Meeting Minutes",
	Proceedings of the thirty-eightt Internet Engineering Task		Proceedings of the thirty-eightt Internet Engineering Task
	Force , April 1997, <https://www.ietf.org/		Force , April 1997, <https://www.ietf.org/
	proceedings/38/97apr-final/xrtftr47.htm>.		proceedings/38/97apr-final/xrtftr47.htm>.
	[NetworkManager]		[NetworkManager]
	NetworkManager, "NetworkManager web site",		NetworkManager, "NetworkManager web site",
	<https://wiki.gnome.org/Projects/NetworkManager>.		<https://wiki.gnome.org/Projects/NetworkManager>.
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 44 ¶
	[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,
	<https://www.rfc-editor.org/info/rfc6724>.		<https://www.rfc-editor.org/info/rfc6724>.
	[RFC7113] Gont, F., "Implementation Advice for IPv6 Router		[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
	Advertisement Guard (RA-Guard)", RFC 7113,		Advertisement Guard (RA-Guard)", RFC 7113,
	DOI 10.17487/RFC7113, February 2014,		DOI 10.17487/RFC7113, February 2014,
	<https://www.rfc-editor.org/info/rfc7113>.		<https://www.rfc-editor.org/info/rfc7113>.
	[RIPE-690]
	Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston,
	J., Doering, G., Palet, J., Linkova, J., Balbinot, L.,
	Meynell, K., and L. Howard, "Best Current Operational
	Practice for Operators: IPv6 prefix assignment for end-
	users - persistent vs non-persistent, and what size to
	choose", RIPE 690, October 2017,
	<https://www.ripe.net/publications/docs/ripe-690>.
	[slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)",		[slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)",
	<https://cvsweb.openbsd.org/src/usr.sbin/slaacd/>.		<https://cvsweb.openbsd.org/src/usr.sbin/slaacd/>.
	[systemd] systemd, "systemd web site", <https://systemd.io/>.		[systemd] systemd, "systemd web site", <https://systemd.io/>.
	Appendix A. Analysis of Some Suggested Workarounds		Appendix A. Analysis of Some Suggested Workarounds
	[This section is to be removed before publication of this document as		[This section is to be removed before publication of this document as
	an RFC].		an RFC].
End of changes. 27 change blocks.
	97 lines changed or deleted		110 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/