draft-ietf-6man-slaac-renum-00.txt		draft-ietf-6man-slaac-renum-01.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 Go6 Institute		Intended status: Standards Track 6connect
	Expires: January 28, 2021 R. Patterson		Expires: February 27, 2021 R. Patterson
	Sky UK		Sky UK
	July 27, 2020		August 26, 2020
	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-00		draft-ietf-6man-slaac-renum-01
	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 January 28, 2021.		This Internet-Draft will expire on February 27, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	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.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7
	4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7		4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7
	4.3. Interface Initialization . . . . . . . . . . . . . . . . 7		4.3. Interface Initialization . . . . . . . . . . . . . . . . 8
	4.4. Conveying Information in Router Advertisement (RA)		4.4. Conveying Information in Router Advertisement (RA)
	Messages . . . . . . . . . . . . . . . . . . . . . . . . 7		Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.5. Recovery from Stale Configuration Information without		4.5. Recovery from Stale Configuration Information without
	Explicit Signaling . . . . . . . . . . . . . . . . . . . 7		Explicit Signaling . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7		6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
	6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 8		6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9
	6.1.1. Router Configuration Variables . . . . . . . . . . . 8		6.1.1. Router Configuration Variables . . . . . . . . . . . 9
	6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 8		6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9
	6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 9		6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10
	6.2.1. NetworkManager . . . . . . . . . . . . . . . . . . . 9		6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10
			6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10
	6.3. Conveying Information in Router Advertisement (RA)		6.3. Conveying Information in Router Advertisement (RA)
	Messages . . . . . . . . . . . . . . . . . . . . . . . . 9		Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. Recovery from Stale Configuration Information without		6.4. Recovery from Stale Configuration Information without
	Explicit Signaling . . . . . . . . . . . . . . . . . . . 9		Explicit Signaling . . . . . . . . . . . . . . . . . . . 10
	6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 9		6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10
	6.5. Other mitigations implemented in products . . . . . . . . 9		6.5. Other mitigations implemented in products . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 13		Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15
	A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 14		A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15
	A.2. On a Possible Improvement to Source Address Selection . . 14		A.2. On a Possible Improvement to Source Address Selection . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		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
	[I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local		[I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	4.1.1. Router Configuration Variables		4.1.1. Router Configuration Variables
	[TBD]		[TBD]
	4.1.2. Processing of PIO Lifetimes at Hosts		4.1.2. Processing of PIO Lifetimes at Hosts
	[TBD]		[TBD]
	4.2. Honor Small PIO Valid Lifetimes		4.2. Honor Small PIO Valid Lifetimes
	[TBD]		The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is
			replaced with the following text:
			e) If the advertised prefix is equal to the prefix of an address
			configured by stateless autoconfiguration in the list, the valid
			lifetime and the preferred lifetime of the address should be
			updated by processing the Valid Lifetime and the Preferred
			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:
			* This change allows hosts to react to the information provided
			by a router that has positive knowledge that a prefix has
			become invalid.
			* The behavior described in RFC4862 had been incorporated during
			the revision of the original IPv6 Stateless Address
			Autoconfiguration specification ([RFC1971]). At the time, the
			IPNG working group decided to mitigate the attack vector
			represented by Prefix Information Options with very short
			lifetimes, on the premise these packets represented a bigger
			risk than other ND-based attack vectors [IPNG-minutes].
			While reconsidering the trade-offs represented by such
			decision, we conclude that the drawbacks of mitigating the
			aforementioned attack vector outweigh the possible benefits.
			In scenarios where RA-based attacks are of concern, proper
			mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND
			[RFC3971] should be implemented.
	4.3. Interface Initialization		4.3. Interface Initialization
	[TBD]		When an interface is initialized, it is paramount that network
			configuration information is spread on the corresponding network
			(particularly in scenarios where an interface has been re-
			initialized, and the conveyed information has changed). Thus, this
			document replaces the following text from Section 6.2.4 of [RFC4861]:
			In such cases, the router MAY transmit up to
			MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
			the same rules as when an interface becomes an advertising
			interface.
			with:
			In such cases, the router SHOULD transmit
			MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using
			the same rules as when an interface becomes an advertising
			interface.
			RATIONALE:
			* Use of stale information can lead to interoperability problems.
			Therefore, it is important that new configuration information
			propagates in a timelier manner to all hosts.
			NOTE:
			[I-D.ietf-v6ops-cpe-slaac-renum] specifies recommendations for CPE
			routers to deprecate any stale network configuration information.
	4.4. Conveying Information in Router Advertisement (RA) Messages		4.4. Conveying Information in Router Advertisement (RA) Messages
	[TBD]		[TBD]
	4.5. Recovery from Stale Configuration Information without Explicit		4.5. Recovery from Stale Configuration Information without Explicit
	Signaling		Signaling
	[TBD]		[TBD]
	skipping to change at page 9, line 13 ¶		skipping to change at page 10, line 25 ¶
	this document.		this document.
	6.1.2.3. systemd-networkd		6.1.2.3. systemd-networkd
	systemd-networkd [systemd], a user-space SLAAC implementation		systemd-networkd [systemd], a user-space SLAAC implementation
	employed by some Linux-based operating systems, caps the lifetimes of		employed by some Linux-based operating systems, caps the lifetimes of
	the received PIOs as recommended in this document.		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. NetworkManager		6.2.1. Linux Kernel
			A Linux kernel implementation of this document has been committed to
			the net-next tree. The implementation was produced in April 2020 by
			Fernando Gont <fgont@si6networks.com>. The corresponding patch can
			be found at: <https://patchwork.ozlabs.org/project/netdev/
			patch/20200419122457.GA971@archlinux-current.localdomain/>
			6.2.2. NetworkManager
	NetworkManager [NetworkManager] processes RA messages with a Valid		NetworkManager [NetworkManager] processes RA messages with a Valid
	Lifetime smaller than two hours as recommended in this document.		Lifetime smaller than two hours as recommended in this document.
	6.3. Conveying Information in Router Advertisement (RA) Messages		6.3. Conveying Information in Router Advertisement (RA) Messages
	We know of no implementation that splits network configuration		We know of no implementation that splits network configuration
	information into multiple RA messages.		information into multiple RA messages.
	6.4. Recovery from Stale Configuration Information without Explicit		6.4. Recovery from Stale Configuration Information without Explicit
	skipping to change at page 10, line 15 ¶		skipping to change at page 11, line 35 ¶
	deprecating it.		deprecating it.
	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
	When it comes to the algorithm in Section 4.5, an attacker could		The protocol update in Section 4.2 could allow an on-link attacker to
	impersonate the legitimate router and send an RA that does not		perform a Denial of Service attack againts local hosts, by sending a
	advertise legitimate prefixes being employed in the local network.		forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of
	This cause the corresponding addresses to become deprecated.		that packet, local hosts would invalidate the corresponding prefix,
	However, the addresses would not become invalid since normal		and therefore remove any addresses configured for that prefix,
	unsolicited RA messages would refresh the "Preferred Lifetime" and		possibly terminating e.g. TCP connections employing such addresses.
	"Valid Lifetime" of such addresses.		However, an attacker may achieve similar effects via a number for ND-
			based attack vectors, such as directing traffic to a non-existing
	However, an attacker that can impersonate a router could more easily		node until ongoing TCP connections time out, or performing a ND-based
	deprecate addresses by advertising the legitimate prefixes with the		man-in-the-middle (MITM) attack and subsequently forging TCP RST
	"Preferred Lifetime" set to 0, or perform a plethora of other		segments to cause on-going TCP connections to be aborted. Thus, for
	possible of Denial of Service attacks based on forged RA messages.		all practical purposes, this attack vector does not really represent
	Therefore, when attacks based on forged RA packets are a concern,		a greater risk than other ND attack vectors. As noted in Section 4.2
	technologies such as RA-Guard [RFC6105] [RFC7113] should be deployed.		, in scenarios where RA-based attacks are of concern, proper
			mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND [RFC3971]
	Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts may		should be implemented.
	help limit the duration of the effects of non-sustained attacks that
	employ forged RAs with PIOs, since hosts would now recover in a
	timelier manner.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank (in alphabetical order) Mikael		The authors would like to thank (in alphabetical order) Mikael
	Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Owen		Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Lorenzo
	DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob Hinden,		Colitti, Owen DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob
	Philip Homburg, Lee Howard, Christian Huitema, Erik Kline, Jen		Hinden, Philip Homburg, Lee Howard, Christian Huitema, Tatuya Jinmei,
	Linkova, Albert Manfredi, Roy Marples, Florian Obser, Jordi Palet		Erik Kline, Ted Lemon, Jen Linkova, Albert Manfredi, Roy Marples,
	Martinez, Michael Richardson, Hiroki Sato, Mark Smith, Hannes		Florian Obser, Jordi Palet Martinez, Michael Richardson, Hiroki Sato,
	Frederic Sowa, Tarko Tikan, Ole Troan, and Loganaden Velvindron, for		Mark Smith, Hannes Frederic Sowa, Dave Thaler, Tarko Tikan, Ole
	providing valuable comments on earlier versions of this document.		Troan, Eduard Vasilenko, and Loganaden Velvindron, for providing
			valuable comments on earlier versions of this document.
	The algorithm specified in Section 4.5 is the result of mailing-list		The algorithm specified in Section 4.5 is the result of mailing-list
	discussions over previous versions of this document with Philip		discussions over previous versions of this document with Philip
	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
	skipping to change at page 12, line 16 ¶		skipping to change at page 13, line 35 ¶
	Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,		Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
	January 2019, <https://www.rfc-editor.org/info/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, <http://blog.si6networks.com/2016/02/quiz-weird-		2016, <https://www.si6networks.com/2016/02/16/quiz-weird-
	ipv6-traffic-on-local-network.html>.		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-03 (work in		Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in
	progress), May 2020.		progress), August 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-02 (work		Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
	in progress), May 2020.		in progress), August 2020.
	[I-D.linkova-6man-default-addr-selection-update]		[I-D.linkova-6man-default-addr-selection-update]
	Linkova, J., "Default Address Selection and Subnet		Linkova, J., "Default Address Selection and Subnet
	Renumbering", draft-linkova-6man-default-addr-selection-		Renumbering", draft-linkova-6man-default-addr-selection-
	update-00 (work in progress), March 2017.		update-00 (work in progress), March 2017.
			[IPNG-minutes]
			IETF, "IPNG working group (ipngwg) Meeting Minutes",
			Proceedings of the thirty-eightt Internet Engineering Task
			Force , April 1997, <https://www.ietf.org/
			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>.
	[rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)",		[rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)",
	<https://cvsweb.openbsd.org/src/usr.sbin/rad/>.		<https://cvsweb.openbsd.org/src/usr.sbin/rad/>.
	[radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router		[radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router
	Advertisement Daemon (radvd)",		Advertisement Daemon (radvd)",
	<http://www.litech.org/radvd/>.		<http://www.litech.org/radvd/>.
	[radvd.conf]		[radvd.conf]
	Hawkins, R. and R. Johnson, "radvd.conf - configuration		Hawkins, R. and R. Johnson, "radvd.conf - configuration
	file of the router advertisement daemon",		file of the router advertisement daemon",
	<https://github.com/reubenhwk/radvd/blob/master/		<https://github.com/reubenhwk/radvd/blob/master/
	radvd.conf.5.man>.		radvd.conf.5.man>.
			[RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address
			Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August
			1996, <https://www.rfc-editor.org/info/rfc1971>.
	[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, <https://www.rfc-editor.org/info/rfc2827>.		May 2000, <https://www.rfc-editor.org/info/rfc2827>.
			[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
			"SEcure Neighbor Discovery (SEND)", RFC 3971,
			DOI 10.17487/RFC3971, March 2005,
			<https://www.rfc-editor.org/info/rfc3971>.
	[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,		[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
	DOI 10.17487/RFC5927, July 2010,		DOI 10.17487/RFC5927, July 2010,
	<https://www.rfc-editor.org/info/rfc5927>.		<https://www.rfc-editor.org/info/rfc5927>.
	[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.		[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
	Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,		Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
	DOI 10.17487/RFC6105, February 2011,		DOI 10.17487/RFC6105, February 2011,
	<https://www.rfc-editor.org/info/rfc6105>.		<https://www.rfc-editor.org/info/rfc6105>.
	[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	skipping to change at page 16, line 24 ¶		skipping to change at page 18, line 17 ¶
	Fernando Gont		Fernando Gont
	SI6 Networks		SI6 Networks
	Segurola y Habana 4310, 7mo Piso		Segurola y Habana 4310, 7mo Piso
	Villa Devoto, Ciudad Autonoma de Buenos Aires		Villa Devoto, Ciudad Autonoma de Buenos Aires
	Argentina		Argentina
	Email: fgont@si6networks.com		Email: fgont@si6networks.com
	URI: https://www.si6networks.com		URI: https://www.si6networks.com
	Jan Zorz		Jan Zorz
	Go6 Institute		6connect
	Frankovo naselje 165
	Skofja Loka 4220
	Slovenia
	Email: jan@go6.si		Email: jan@connect.com
	URI: https://www.go6.si
	Richard Patterson		Richard Patterson
	Sky UK		Sky UK
	Email: richard.patterson@sky.uk		Email: richard.patterson@sky.uk
End of changes. 22 change blocks.
	69 lines changed or deleted		147 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/