Diff: rfc8978xml2.original.xml

	rfc8978xml2.original.xml	rfc8978.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

	<?rfc subcompact="no" ?>
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc strict="no" ?>

	<rfc category="info" ipr="trust200902"
	docName="draft-ietf-v6ops-slaac-renum-05">
	<front>
	<title abbrev="Reaction to Renumbering Events">Reaction of Stateless Address
	Autoconfiguration (SLAAC) to Flash-Renumbering Events</title>


	<author fullname="Fernando Gont" initials="F." surname="Gont">	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
		docName="draft-ietf-v6ops-slaac-renum-05" number="8978" obsoletes=""
		updates="" submissionType="IETF" category="info" consensus="true"
		xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">


	<organization abbrev="SI6 Networks">SI6 Networks</organization>	<!-- xml2rfc v2v3 conversion 3.5.0 -->
	<address>	<front>
	<postal>	<title abbrev="Reaction to Renumbering Events">Reaction of IPv6 Stateless
	<street>Segurola y Habana 4310, 7mo Piso</street>	Address Autoconfiguration (SLAAC) to Flash-Renumbering Events</title>
	<!-- <code>1706</code> -->	<seriesInfo name="RFC" value="8978"/>
	<city>Villa Devoto</city>	<author fullname="Fernando Gont" initials="F." surname="Gont">
	<region>Ciudad Autonoma de Buenos Aires</region>	<organization abbrev="SI6 Networks">SI6 Networks</organization>
	<country>Argentina</country>	<address>
	</postal>	<postal>
	<!-- <phone>+54 11 4650 8472</phone> -->	<street>Segurola y Habana 4310, 7mo Piso</street>
	<email>fgont@si6networks.com</email>	<city>Villa Devoto</city>
	<uri>https://www.si6networks.com</uri>	<region>Ciudad Autónoma de Buenos Aires</region>
		<country>Argentina</country>
		</postal>
		<email>fgont@si6networks.com</email>
		<uri>https://www.si6networks.com</uri>
	</address>	</address>

	</author>	</author>
		<author fullname="Jan Žorž" initials="J." surname="Žorž">
	<author fullname="Jan Zorz" initials="J." surname="Zorz">	<organization abbrev="6connect">6connect, Inc.</organization>
		<address>
	<organization abbrev="6connect">6connect</organization>	<email>jan@6connect.com</email>

	<address>
	<!--
	<postal>
	<street>Frankovo naselje 165</street>
	<code>4220</code>
	<city>Skofja Loka</city>

	<country>Slovenia</country>
	</postal> -->
	<email>jan@connect.com</email>
	<!-- <uri>https://www.6connect.com/</uri> -->
	</address>
	</author>

	<author initials="R." surname="Patterson" fullname="Richard Patterson">

	<organization>Sky UK</organization>

	<address>

	<email>richard.patterson@sky.uk</email>

	</address>

	</author>

	<date/>

	<area>Operations and Management</area>
	<workgroup>IPv6 Operations Working Group (v6ops)</workgroup>

	<!-- [rfced] Please insert any keywords (beyond those that appear in
	the title) for use on http://www.rfc-editor.org/search.html. -->

	<keyword></keyword>

	<abstract>
	<t><!--A very common IPv6 deployment scenario is that in which a CPE route
	r employs DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one pr
	efix from within the leased prefix is advertised on a local network via SLAAC. -
	->In scenarios where network configuration information related to IPv6 prefixes
	becomes invalid without any explicit and reliable signaling of that condition (s
	uch as when a Customer Edge router crashes and reboots without knowledge of the
	previously-employed prefixes), nodes on the local network may continue using sta
	le prefixes for an unacceptably long time (on the order of several days), thus r
	esulting in connectivity problems. This document describes this issue and discus
	ses operational workarounds that may help to improve network robustness. Additio
	nally, it highlights areas where further work may be needed.</t>
	</abstract>
	</front>
	<middle>
	<section anchor="intro" title="Introduction">
	<t>IPv6 Stateless address autoconfiguration (SLAAC) <xref target="RFC4862"/> con
	veys information about prefixes to be employed for address configuration via Pre
	fix Information Options (PIOs) sent in Router Advertisement (RA) messages. IPv6
	largely assumes prefix stability, with network renumbering only taking place in
	a planned manner, with old/stale prefixes being phased-out via reduced prefix li
	fetimes, and new prefixes (with longer lifetimes) being introduced at the same t
	ime. However, there are several scenarios that may lead to the so-called "flash-
	renumbering" events, where the prefix employed by a network suddenly becomes inv
	alid and replaced by a new prefix. In some of these scenarios, the local router
	producing the network renumbering event may try to deprecate the currently-emplo
	yed prefixes (by explicitly signaling the network about the renumbering event),
	whereas in other scenarios it may be unable to do so.</t>

	<t>In scenarios where network configuration information related to IPv6 prefixes
	becomes invalid without any explicit and reliable signaling of that condition,
	nodes on the local network may continue using stale prefixes for an unacceptably
	long period of time, thus resulting in connectivity problems.</t>

	<t>Scenarios where this problem may arise include, but are not limited to,
	the following:

	<list style="symbols">

	<t>The most common IPv6 deployment scenario for residential or small office netw
	orks, where a Customer Edge (CE) router employs DHCPv6 Prefix Delegation (DHCPv6
	-PD) <xref target="RFC8415"/> to request a prefix from an Internet Service Provi
	der (ISP), and a sub-prefix of the leased prefix is advertised on the LAN-side o
	f the CE router via Stateless Address Autoconfiguration (SLAAC) <xref target="RF
	C4862"/>.
	In scenarios where the CE router crashes and reboots, the CE may obtain (via DHC
	Pv6-PD) a different prefix from the one previously
	leased, and therefore advertise (via SLAAC) the new prefix on the LAN side. Host
	s will typically configure addresses for the new prefix, but will normally retai
	n and may actively employ the addresses configured for the previously-advertised
	prefix, since their associated Preferred Lifetime and Valid Lifetime allow them
	to do so.</t>

	<t>A router (e.g. Customer Edge router) advertises autoconfiguration
	prefixes corresponding to prefixes learned via DHCPv6-PD with constant PIO
	lifetimes that are not synchronized with the DHCPv6-PD lease time (even though S
	ection 6.3 of <xref target="RFC8415"/> requires such synchronization). While thi
	s behavior violates the
	aforementioned requirement from <xref target="RFC8415"/>, it is not an unusual b
	ehavior,
	particularly when e.g. DHCPv6-PD is implemented in a different software
	module than the SLAAC router component.
	</t>

	<t>A switch-port the host is connected to is moved to another subnet
	(VLAN) as a result of manual switch-port reconfiguration or 802.1x
	re-authentication. There has been evidence that
	some 802.1x supplicants do not reset network settings after
	successful 802.1x authentication. So if a host fails 802.1x
	authentication for some reason, is placed in a "quarantine" VLAN
	and is successfully authenticated later on, it might end up
	having IPv6 addresses from both the old ("quarantine") and the new VLANs.
	</t>

	<t>During the planned network renumbering, a router is configured to
	send an RA with the Preferred Lifetime for the "old" Prefix Information Op
	tion (PIO) set to zero
	and the new PIO with a non-zero Preferred Lifetime. However, due
	to unsolicited RAs being sent to a multicast destination address, and mult
	icast being rather unreliable on busy wifi networks, the RA
	might not be received by local hosts.
	</t>

	<t>Automated device config management system performs periodic config
	pushes to network devices. In these scenarios, network devices may simply immed
	iately
	forget their previous configuration, rather than withdrawing it gracefully. If
	such a push results in
	changing the subnet configured on a particular network, hosts
	attached to that network would not get notified about the subnet
	change, and their addresses from the "old" prefix will not be
	deprecated. A related scenario is the incorrect network renumbering where
	a network administrator renumbers a network by simply
	removing the "old" prefix from the configuration and configuring a
	new prefix instead.
	</t>

	</list>
	</t>

	<t>
	Lacking any explicit and reliable signaling to deprecate the previously-advertis
	ed prefixes, hosts may continue to employ the previously-configured addresses, w
	hich will typically result in packets being blackholed (whether because of egres
	s-filtering by the CE router or ISP) or the return traffic being discarded or ro
	uted elsewhere.
	</t>

	<t>The default values for the "Preferred Lifetime" and "Valid Lifetime" of PIOs
	specified in <xref target="RFC4861"/> mean that, in the aforementioned scenarios
	, the stale addresses would be retained, and could be actively employed for new
	communications instances, for an unacceptably long period of time (one month, an
	d one week, respectively). This could lead to interoperability problems, instead
	of hosts transitioning to the newly-advertised prefix(es) in a more timely mann
	er.</t>

	<t>Some devices have implemented ad-hoc mechanisms to address this problem, such
	as sending RAs to deprecate apparently-stale prefixes when the device receives
	any packets employing a source address from a prefix not currently advertised fo
	r address configuration on the local network <xref target="FRITZ"/>. However, th
	is may introduce other interoperability problems, particularly in multihomed/mul
	tiprefix scenarios. This is a clear indication that advice in this area is warra
	nted.</t>

	<t>Unresponsiveness to these "flash-renumbering" events is caused by the inabili
	ty of the network to deprecate stale information, as well as by the inability of
	hosts to react to network configuration changes in a more timely manner. Clearl
	y, it would be desirable that these flash-renumbering scenarios do not occur, an
	d that, when they do occur, that hosts are explicitly and reliably notified of t
	heir occurrence. However, for robustness reasons, it is paramount for hosts to b
	e able to recover from stale configuration information even when these flash-ren
	umbering events occur and the network is unable to explicitly and reliably notif
	y hosts about such conditions.
	</t>
	<t><xref target="problem"/> analyzes this problem in more detail. <xref target="
	Solutions"/> describes possible operational mitigations. <xref target="futurewor
	k"/> describes possible future work to mitigate the aforementioned problem.</t>
	</section>

	<!--
	<section title="Terminology" anchor="term">

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" in this document are to be interpreted as
	described in
	<xref target='RFC2119' />.</t>
	</section>


	<section title="Analysis of the Problem" anchor="problem">
	<t>As noted in <xref target="intro"/>, the problems discussed in this document a
	re exacerbated by the default values of some protocol parameters and other facto
	rs. The following sections analyze each of them in detail.</t>

	<section anchor="ops" title="Use of Dynamic Prefixes">

	<t>In network scenarios where dynamic prefixes are employed, renumbering eve
	nts lead to updated network configuration information being propagated through t
	he network, such that the renumbering events are gracefully handled. However, if
	the renumbering event happens along with e.g. loss of configuration state by so
	me of the devices involved in the renumbering procedure (e.g., a router crashes,
	reboots, and gets leased a new prefix), this may result in a flash-renumbering
	event, where new prefixes are introduced without properly phasing out the old on
	es.</t>

	<t>In simple residential or small office scenario, the problem discussed
	in this document would be avoided if DHCPv6-PD would lease "stable" prefixes. Ho
	wever, a recent survey <xref target="UK-NOF"/> indicates that 37% of the respond
	ing ISPs employ dynamic prefixes. That is, dynamic IPv6 prefixes are an operatio
	nal reality.</t>

	<t>Deployment reality aside, there are a number of possible issues associated wi
	th stable prefixes:
	<list style="symbols">
	<t>Provisioning systems may be unable to deliver stable IPv6 pref
	ixes.</t>

	<t>While an ISP might lease stable prefixes to the home or small office, the Cus
	tomer Edge router might in turn lease sub-prefixes of these prefixes to other in
	ternal network devices. Unless the associated lease databases are stored on non-
	volatile memory, these internal devices might be leased dynamic sub-prefixes of
	the stable prefix leased by the ISP. In other words, every time a prefix is leas
	ed there is the potential for the resulting prefixes to become dynamic, even if
	the device leasing sub-prefixes has been leased a stable prefix by its upstream
	router.
	</t>
	<t>While there is a range of information that may be employed to
	correlate network activity <xref target="RFC7721"/>, the use of stable prefixes
	clearly simplifies network activity correlation, and may essentially render feat
	ures such as "temporary addresses" <xref target="RFC4941"/> irrelevant. </t>

	<t>There may be existing advice for ISPs to deliver dynamic IPv6
	prefixes by default (see e.g. <xref target="GERMAN-DP"/>) over privacy concern
	s associated with stable prefixes.</t>
	</list>
	</t>

	<t>For a number of reasons (such as the ones stated above), IPv6 deployments may
	employ dynamic prefixes (even at the expense of the issues discussed in this do
	cument), and that there might be scenarios in which the dynamics of a network ar
	e such that the network exhibits the behaviour of dynamic prefixes. Rather than
	trying to regulate how operators may run their networks, this document aims at i
	mproving network robustness in the deployed Internet.</t>
	</section>

	<section title="Default Timer Values in IPv6 Stateless Address Autoconfiguration
	(SLAAC)" anchor="timer-problem">
	<!--
	<t>One common use of timers is when implementing reliability mechanisms where a
	packet is
	transmitted, and, unless a response is received, a timer will fire to
	trigger retransmission of the original packet.</t>

	<t>For obvious reasons, the whole point of using timers in this way is
	that, in problematic scenarios, they trigger some recovery action in a timely ma
	nner.</t>

	<t>The impact of the issue discussed in this document is a function of the lifet
	ime values employed for the PIO lifetimes, since these values determine for how
	long the corresponding addresses will be preferred and considered valid. Thus, w
	hen the problem discussed in this document is experienced, the longer the PIO li
	fetimes, the higher the impact.</t>

	<t><xref target="RFC4861"/> specifies the following default PIO lifetime values:
	<list style="symbols">
	<t>Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)</t>
	<t>Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)</t>
	</list>
	</t>

	<t>Under problematic circumstances, such as where the corresponding network info
	rmation has become stale without any explicit and reliable signal from the netwo
	rk (as described in <xref target="intro"/>), it could take hosts up to 7 days
	(one week) to deprecate the corresponding addresses, and up to 30 days (one
	month) to eventually invalidate and remove any addresses configured
	for the stale prefix. This means that it will typically take hosts
	an unacceptably long period of time (on the order of several days) to
	recover from these scenarios. </t>

	<!--
	<t>Clearly, for any practical purposes, employing such long default values is eq
	uivalent of not using any timers at all, since taking 7 days or 30 days (respect
	ively) to recover from a network problem is simply unacceptable.</t>

	<!--

	MaxRtrAdvInterval: 300 seconds (5 minutes)
	MinRtrAdvInterval: 0.33 * MaxRtrAdvInterval = 99 seconds
	AdvDefaultLifetime: 3 * MaxRtrAdvInterval (no mayor a 9000) = 900 (15 minutes)
	*********

	Current values:
	AdvDefaultLifetime: 3 * 600 = 1800 = 30 minutes
	<!-- <t><xref target="timers"/> of this document updates the SLAAC specification
	to employ shorter timer values.</t> -->
	</section>

	<section title="Recovering from Stale Network Configuration Information" anchor=
	"hosts-problem">
	<t>SLAAC hosts are unable to recover from stale network configuration informatio
	n for a number of reasons:
	<list style="symbols">
	<t>Item "e)" of Section 5.5.3 of <xref target="RFC4862"/> specifies that an unau
	thenticated RA may never reduce the "RemainingLifetime" to less than two hours.
	If the RemainingLifetime of an address is smaller than 2 hours, then a Valid Lif
	etime smaller than 2 hours will be ignored. The Preferred Lifetime of an address
	can be reduced to any value to avoid using a stale prefix for new communication
	s.
	</t>
	<t>In the absence of explicit signalling from SLAAC routers (such as sending PIO
	s with a "Preferred Lifetime" set to 0), SLAAC hosts fail to recover from stale
	configuration information in a timely manner. However, when a network element is
	able to explicitly signal the renumbering event, it will only be able to deprec
	ate the stale prefix, but not to invalidate the prefix in question. Therefore, c
	ommunication with the new "owners" of the stale prefix will not be possible, sin
	ce the stale prefix will still be considered "on-link".
	</t>
	</list>
	</t>
	<!--
	<t><xref target="stale-config"/> of this document specifies a local policy that
	SLAAC hosts can implement to heuristically infer that network configuration info
	rmation has changed and recover from stale prefixes.</t>
	</section>

	<section title="Lack of Explicit Signaling about Stale Information" anchor="cpe-
	problem">
	<t>Whenever prefix information has changed, a SLAAC router should not only adver
	tise the new information, but should also advertise the
	stale information with appropriate lifetime values (both "Preferred
	Lifetime" and "Valid Lifetime" set to 0). This would provide explicit
	signaling to SLAAC hosts to remove the stale information (including
	configured addresses and routes).

	However, in scenarios such as when a CE router crashes and reboots, the CE rout
	er may have no knowledge about the previously-advertised prefixes, and thus may
	be unable to advertise them with appropriate lifetimes (in order to deprecate th
	em).
	</t>
	<t>However, we note that, as discussed in <xref target="hosts-problem"/>, PIOs w
	ith small Valid Lifetimes in unauthenticated RAs will not lower the Valid Lifeti
	me to any value shorter than two hours (as per <xref target="RFC4862"/>). Theref
	ore, even if a SLAAC router tried to explicitly signal the network about the sta
	le configuration information via unauthenticated RAs, implementations compliant
	with <xref target="RFC4862"/> would deprecate the corresponding prefixes, but wo
	uld fail to invalidate them.

	<list style="hanging">
	<t hangText="NOTE:"><vspace blankLines="0" />
	Some implementations have been updated to honor small PIO lifetimes values, as p
	roposed in <xref target="I-D.ietf-6man-slaac-renum"/>. For example, please see <
	xref target="Linux-update"/>.
	</t>
	</list>
	</t>

	<!--
	<t><xref target="sig-stale-config"/> updates the SLAAC specification such that r
	outers explicitly notify SLAAC hosts about the stale network configuration infor
	mation, and hosts can recover from it upon receipt of such notifications. <xref
	target="CPE"/> specifies the corresponding requirements for CPE routers.</t>
	</section>

	<section title="Interaction Between DHCPv6-PD and SLAAC" anchor="dhcpv6-pd-slaac
	-problem">
	<t>While DHCPv6-PD is normally employed along with SLAAC, the interaction betwee
	n the two protocols is largely unspecified. Not unusually, the two protocols are
	implemented in two different software components with the interface between the
	two implemented by some sort of script that feeds the SLAAC implementation with
	values learned from DHCPv6-PD.</t>

	<t>At times, the prefix lease time is fed as a constant value to the SLAAC route
	r implementation, meaning that, eventually, the prefix lifetime advertised on th
	e LAN side will span past the DHCPv6-PD lease time. This is clearly incorrect,
	since the SLAAC router implementation would be allowing the use of such prefixe
	s for a longer time than it has been granted usage of those prefixes via DHCPv6-
	PD. </t>

	<!--
	<t><xref target="dhcpv6-pd-slaac"/> of this document specifies this aspect of th
	e interaction between DHCPv6-PD and SLAAC.</t>
	</section>

	</section>

	<section anchor="Solutions" title="Operational Mitigations">
	<t>The following subsections discuss possible operational workarounds for
	the aforementioned problems. <!-- <xref target="host-side"/> specifies modifica
	tions to SLAAC which include the use of more appropriate lifetime values and a m
	echanism for hosts to infer when a previously-advertised prefix has become stale
	. This modification leads to more robust behaviour even for existing deployments
	. --></t>

	<section title="Stable Prefixes">
	<t>As noted in <xref target="ops"/>, the use of stable prefixes would eliminate
	the issue in some of the scenarios discussed in <xref target="intro"/> of this
	document, such as the typical home network deployment. However, even in such sc
	enarios, there might be reasons for which an administrator may want or may need
	to employ dynamic prefixes</t>
	</section>

	<section title="SLAAC Parameter Tweaking" anchor="host-side">
	<t>An operator may wish to override some SLAAC parameters such that, under norma
	l circumstances, the timers will be refreshed/reset, but in the presence of netw
	ork faults (such as the one discussed in this document), the timers go off and t
	rigger some fault recovering action (e.g. deprecate and subsequently invalidate
	stale addresses).
	</t>

	<t>
	The following router configuration variables from <xref target="RFC4861"/> (corr
	esponding to the "lifetime" parameters of PIOs) could be overridden as follows:

	<list>
	<t>AdvPreferredLifetime: 2700 seconds (45 minutes)</t>
	<t>AdvValidLifetime: 5400 seconds (90 minutes)</t>
	</list>
	</t>


	<t>	</address>
	<list style="hanging">	</author>
	<t hangText="NOTES:"><vspace blankLines="0" />	<author initials="R." surname="Patterson" fullname="Richard Patterson">
	The aforementioned values for AdvPreferredLifetime and AdvValidLifetime are expe	<organization>Sky UK</organization>
	cted to be appropriate for most networks. In some networks, particularly where t	<address>
	he operator has complete control of prefix allocation and where hosts on the net	<email>richard.patterson@sky.uk</email>
	work may spend long periods sleeping (e.g., sensors with limited battery), longe	</address>
	r values may be appropriate.	</author>
	</t>	<date month="March" year="2021"/>
	<t>	<area>Operations and Management</area>
	A CE router advertising a sub-prefix of a prefix leased via DHCPv6-PD will perio	<workgroup>v6ops</workgroup>
	dically refresh the Preferred Lifetime and the Valid Lifetime of an advertised p	<keyword>IPv6</keyword>
	refix to AdvPreferredLifetime and AdvValidLifetime, respectively, as long as the	<keyword>problem</keyword>
	resulting lifetime of the corresponding prefixes does not extend past the DHCPv	<keyword>address</keyword>
	6-PD lease time <xref target="I-D.ietf-v6ops-cpe-slaac-renum"/>.	<keyword>prefix delegation</keyword>
	</t>	<keyword>DHCPv6</keyword>
	</list>	<keyword>stale prefixes</keyword>
	</t>	<keyword>old prefixes</keyword>


	<t>	<abstract>
	<list style="hanging">	<t>In scenarios where network configuration information
	<t hangText="RATIONALE:">	related to IPv6 prefixes becomes invalid without any explicit and reliable
	<list style="symbols">	signaling of that condition (such as when a Customer Edge router crashes and
	<t>In the context of <xref target="RFC8028"/>, where it is clear that use of add	reboots without knowledge of the previously employed prefixes), hosts on the
	resses configured for a given prefix is tied to using the next-hop router that a	local network may continue using stale prefixes for an unacceptably long time
	dvertised the prefix, it does not make sense for the "Preferred Lifetime" of a P	(on the order of several days), thus resulting in connectivity problems. This
	IO to be larger than the "Router Lifetime" (AdvDefaultLifetime) of the correspon	document describes this issue and discusses operational workarounds that may
	ding Router Advertisement messages. The "Valid Lifetime" is set to a much larger	help to improve network robustness. Additionally, it highlights areas where
	value to cope with transient network problems.</t>	further work may be needed.</t>
	<!--	</abstract>
	<t>As a result, this document updates <xref target="RFC4861"/> such that the def	</front>
	ault Valid Lifetime (AdvValidLifetime) and Preferred Lifetime (AdvPreferredLifet	<middle>
	ime) of PIOs are specified as a function of the "Router Lifetime" (AdvDefaultLif	<section anchor="intro" numbered="true" toc="default">
	etime) of Router Advertisement messages.</t>	<name>Introduction</name>
		<t>IPv6 Stateless Address Autoconfiguration (SLAAC) <xref
		target="RFC4862" format="default"/> conveys information about prefixes to be
		employed for address configuration via Prefix Information Options (PIOs) sent
		in Router Advertisement (RA) messages. IPv6 largely assumes prefix stability,
		with network renumbering only taking place in a planned manner: old
		prefixes are deprecated (and eventually invalidated) via reduced prefix lifetime
		s and new prefixes are introduced (with
		longer lifetimes) at the same time. However, there are several
		scenarios that may lead to the so-called "flash-renumbering" events, where a
		prefix employed by a network suddenly becomes invalid and replaced by a new
		prefix. In some of these scenarios, the local router producing the network
		renumbering event may try to deprecate (and eventually invalidate) the currently
		employed prefix (by
		explicitly signaling the network about the renumbering event), whereas in other
		scenarios, it may be unable to do so.</t>
		<t>In scenarios where network configuration information related to IPv6
		prefixes becomes invalid without any explicit and reliable signaling of that
		condition, hosts on the local network may continue using stale prefixes for an
		unacceptably long period of time, thus resulting in connectivity problems.</t>
		<t>Scenarios where this problem may arise include, but are not limited to
		, the following:</t>
		<ul spacing="normal">
		<li>The most common IPv6 deployment scenario for residential or small
		office networks, where a Customer Edge (CE) router employs DHCPv6 Prefix
		Delegation (DHCPv6-PD) <xref target="RFC8415" format="default"/> to request a
		prefix from an Internet Service Provider (ISP), and a sub-prefix of the leased
		prefix is advertised on the LAN side of the CE router via Stateless Address
		Autoconfiguration (SLAAC) <xref target="RFC4862" format="default"/>. In
		scenarios where the CE router crashes and reboots, the CE router may obtain (via
		DHCPv6-PD) a different prefix from the one previously leased and therefore
		advertise (via SLAAC) a new sub-prefix on the LAN side. Hosts will typically
		configure addresses for the new sub-prefix but will also normally retain and may
		actively employ the addresses configured for the previously advertised sub-prefi
		x,
		since their associated Preferred Lifetime and Valid Lifetime allow them to do
		so.</li>
		<li>A router (e.g., Customer Edge router) advertises autoconfiguration
		prefixes (corresponding to prefixes learned via DHCPv6-PD) with constant PIO
		lifetimes that are not synchronized with the DHCPv6-PD lease time (even though
		<xref target="RFC8415" sectionFormat="of" section="6.3"/> requires such
		synchronization). While this behavior violates the aforementioned requirement
		from <xref target="RFC8415" format="default"/>, it is not an unusual behavior.
		For example, this is particularly true for implementations in which DHCPv6-PD is
		implemented in a different software module
		than SLAAC.</li>


	<t>Lacking RAs that refresh information, addresses configured for advertised pre	<li>A switch-port that a host is connected to is moved to another subnet
	fixes become deprecated in a more timely manner, and thus Rule 3 of <xref target	(VLAN) as a result of manual switch-port reconfiguration or 802.1x reauthentica
	="RFC6724"/> causes other configured addresses (if available) to be used instead	tion. There has been evidence that
	.</t>	some 802.1x supplicants do not reset network settings after
		successful 802.1x authentication. If a host fails 802.1x authentication
		for some reason, it may be placed in a "quarantine" VLAN; if successfully authen
		ticated later on, the host may end up having IPv6 addresses from both the old ("
		quarantine") and new VLANs.</li>
		<li>During a planned network renumbering event, a router is configured t
		o
		send an RA including a Prefix Information
		Option (PIO) for the "old" prefix with the Preferred Lifetime set to zero and t
		he Valid Lifetime set to a small value, as well as a PIO for the new prefix with
		default lifetimes.
		However, due to unsolicited RAs being sent to a multicast destination address,
		and multicast being rather unreliable on busy Wi-Fi networks, the RA might not
		be received by local hosts.</li>
		<li>An automated device config management system performs periodic confi
		g
		pushes to network devices. In these scenarios, network devices may simply imme
		diately
		forget their previous configuration, rather than withdraw it gracefully. If su
		ch a push results in
		changing the prefix configured on a particular subnet, hosts
		attached to that subnet might not get notified about the prefix
		change, and their addresses from the "old" prefix might not be
		deprecated (and eventually invalidated) in a timely manner. A related sc
		enario is an incorrect network renumbering event, where a network administrator
		renumbers a network by simply
		removing the "old" prefix from the configuration and configuring a
		new prefix instead.
		</li>
		</ul>
		<t>
		Lacking any explicit and reliable signaling to deprecate (and eventually invalid
		ate) the stale prefixes, hosts may continue to employ the previously configured
		addresses, which will typically result in packets being filtered or blackholed e
		ither on the CE router or within the ISP network. </t>
		<t>The default values for the Preferred Lifetime and Valid Lifetime of
		PIOs specified in <xref target="RFC4861" format="default"/> mean that, in the
		aforementioned scenarios, the stale addresses would be retained and could be
		actively employed for new communication instances for an unacceptably long
		period of time (one month and one week, respectively). This could lead to
		interoperability problems, instead of hosts transitioning to the
		newly advertised prefix(es) in a more timely manner.</t>
		<t>Some devices have implemented ad hoc mechanisms to address this
		problem, such as sending RAs to deprecate (and eventually invalidate) apparently
		stale prefixes when the
		device receives any packets employing a source address from a prefix not
		currently advertised for address configuration on the local network <xref
		target="FRITZ" format="default"/>. However, this may introduce other
		interoperability problems, particularly in multihomed/multi-prefix
		scenarios. This is a clear indication that advice in this area is
		warranted.</t>
		<t>Unresponsiveness to these flash-renumbering events is caused by the
		inability of the network to deprecate (and eventually invalidate) stale informat
		ion as well as by the
		inability of hosts to react to network configuration changes in a more timely
		manner. Clearly, it would be desirable that these flash-renumbering events
		do not occur and that, when they do occur, hosts are explicitly and
		reliably notified of their occurrence. However, for robustness reasons, it is
		paramount for hosts to be able to recover from stale configuration information
		even when these flash-renumbering events occur and the network is unable to
		explicitly and reliably notify hosts about such conditions. </t>
		<t><xref target="problem" format="default"/> analyzes this problem in
		more detail. <xref target="Solutions" format="default"/> describes possible
		operational mitigations. <xref target="futurework" format="default"/> describes
		possible future work to mitigate the aforementioned problem.</t>
		</section>
		<section anchor="problem" numbered="true" toc="default">
		<name>Analysis of the Problem</name>
		<t>As noted in <xref target="intro" format="default"/>, the problem discu
		ssed in this document is exacerbated by the default values of some protocol para
		meters and other factors. The following sections analyze each of them in detail.
		</t>
		<section anchor="ops" numbered="true" toc="default">
		<name>Use of Dynamic Prefixes</name>
		<t>In network scenarios where dynamic prefixes are employed, renumbering
		events lead to updated network configuration information being propagated throu
		gh the network, such that the renumbering events are gracefully handled. However
		, if the renumbering event happens along with, e.g., loss of configuration state
		by some of the devices involved in the renumbering procedure (e.g., a router cr
		ashes, reboots, and gets leased a new prefix), this may result in a flash-renumb
		ering event, where new prefixes are introduced without properly phasing out the
		old ones.</t>
		<t>In simple residential or small office scenarios, the problem discusse
		d in this document would be avoided if DHCPv6-PD leased "stable" prefixes. Howev
		er, a recent survey <xref target="UK-NOF" format="default"/> indicates that 37%
		of the responding ISPs employ dynamic IPv6 prefixes. That is, dynamic IPv6 prefi
		xes are an operational reality.</t>
		<t>Deployment reality aside, there are a number of possible issues assoc
		iated with stable prefixes:
		</t>
		<ul spacing="normal">
		<li>Provisioning systems may be unable to deliver stable IPv6 prefixes
		.</li>
		<li>While an ISP might lease stable prefixes to the home or small
		office, the Customer Edge router might in turn lease sub-prefixes of these
		prefixes to other internal network devices. Unless the associated lease
		databases are stored on non-volatile memory, these internal devices might get
		leased dynamic sub-prefixes of the stable prefix leased by the ISP. In other
		words, every time a prefix is leased, there is the potential for the resulting
		prefixes to become dynamic, even if the device leasing sub-prefixes has been
		leased a stable prefix by its upstream router. </li>
		<li>While there is a range of information that may be employed to
		correlate network activity <xref target="RFC7721" format="default"/>, the use
		of stable prefixes clearly simplifies network activity correlation and may reduc
		e
		the effectiveness of "temporary addresses" <xref
		target="RFC8981" format="default"/>. </li>
		<li>There might be existing advice for ISPs to deliver dynamic IPv6
		prefixes <strong>by default</strong> (e.g., see <xref target="GERMAN-DP"
		format="default"/>) over privacy concerns associated with stable prefixes.</li>
		<li>There might be scalability and performance drawbacks of either a
		disaggregated distributed routing topology or a centralized topology, which are
		often required to provide stable prefixes, i.e., distributing more-specific rout
		es or summarizing routes at centralized locations.</li>
		</ul>
		<t>For a number of reasons (such as the ones stated above), IPv6 deploym
		ents might employ dynamic prefixes (even at the expense of the issues discussed
		in this document), and there might be scenarios in which the dynamics of a netwo
		rk are such that the network exhibits the behavior of dynamic prefixes. Rather t
		han trying to regulate how operators may run their networks, this document aims
		at improving network robustness in the deployed Internet.</t>
		</section>
		<section anchor="timer-problem" numbered="true" toc="default">
		<name>Default PIO Lifetime Values in IPv6 Stateless Address Autoconfigur
		ation (SLAAC)</name>
		<t>The impact of the issue discussed in this document is a function of the life
		time values employed for PIOs, since these values determine for how long the cor
		responding addresses will be preferred and considered valid. Thus, when the prob
		lem discussed in this document is experienced, the longer the PIO lifetimes, the
		higher the impact.</t>
		<t><xref target="RFC4861" format="default"/> specifies the following def
		ault PIO lifetime values:
		</t>
		<ul spacing="normal">
		<li>Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
		</li>
		<li>Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)</li>
		</ul>
		<t>Under problematic circumstances, such as when the corresponding netwo
		rk information has become stale without any explicit and reliable signal from th
		e network (as described in <xref target="intro" format="default"/>), it could ta
		ke hosts up to 7 days
		(one week) to deprecate the corresponding addresses and up to 30 days (one
		month) to eventually invalidate and remove any addresses configured
		for the stale prefix. This means that it will typically take hosts
		an unacceptably long period of time (on the order of several days) to
		recover from these scenarios. </t>


	<t>We note that lowering the default values for the "Valid Lifetime" helps reduc	</section>
	e the amount of time a host may maintain stale information and the amount of tim	<section anchor="hosts-problem" numbered="true" toc="default">
	e an advertising router would need to advertise stale prefixes to deprecate them	<name>Recovering from Stale Network Configuration Information</name>
	, while reducing the default "Preferred Lifetime" would reduce the amount of tim	<t>SLAAC hosts are unable to recover from stale network configuration in
	e it takes for a host to prefer other working prefixes (see Section 12 of <xref	formation, since:
	target="RFC4861"/>). However, while the values suggested in this section are an	</t>
	improvement over the default values specified in <xref target="RFC4861"/>, they	<ul spacing="normal">
	represent a trade-off among a number of factors, including responsiveness, possi	<li>In scenarios where SLAAC routers explicitly signal the
	ble impact on the battery life of connected devices <xref target="RFC7772"/>, et	renumbering event, hosts will typically deprecate, but not
	c. Thus, they may or may not provide sufficient mitigation to the problem discus	invalidate, the stale addresses, since item "e)" of <xref target="RFC4862"
	sed in this document.</t>	sectionFormat="of"
	</list>	section="5.5.3"/> specifies that an unauthenticated RA may never reduce
	</t>	the valid lifetime of an address to less than two hours.
	</list>	Communication with the new "users" of the stale prefix
	</t>	will not be possible, since the stale prefix will still be
	</section>	considered "on-link" by the local hosts.</li>
		<li>In the absence of explicit signaling from SLAAC routers, SLAAC
		hosts will typically fail to recover from stale configuration
		information in a timely manner, since hosts would need to rely
		on the last Preferred Lifetime and Valid Lifetime advertised
		for the stale prefix, for the corresponding addresses to become
		deprecated and subsequently invalidated. Please see <xref target="timer-pro
		blem"
		format="default"/> of
		this document for a discussion of the default PIO lifetime values.</li>
		</ul>


	</section>	</section>
		<section anchor="cpe-problem" numbered="true" toc="default">
		<name>Lack of Explicit Signaling about Stale Information</name>
		<t>Whenever prefix information has changed, a SLAAC router should advert
		ise not only the new information but also the
		stale information with appropriate lifetime values (both the Preferred
		Lifetime and the Valid Lifetime set to 0). This would provide explicit
		signaling to SLAAC hosts to remove the stale information (including
		configured addresses and routes). However, in certain scenarios, such as when a
		CE router crashes and reboots, the CE
		router may have no knowledge about the previously advertised prefixes and thus
		might be unable to advertise them with appropriate lifetimes (in order to
		deprecate and eventually invalidate them). </t>
		<t>In any case, we note that, as discussed in <xref target="hosts-proble
		m"
		format="default"/>, PIOs with small Valid Lifetimes in unauthenticated RAs will
		not lower the Valid Lifetime to any value shorter than two hours (as per <xref
		target="RFC4862" format="default"/>). Therefore, even if a SLAAC router tried
		to explicitly signal the network about the stale configuration information via
		unauthenticated RAs, implementations compliant with <xref target="RFC4862"
		format="default"/> would deprecate the corresponding prefixes but would fail
		to invalidate them. </t>
		<aside>
		<t>NOTE: </t>
		<t>Some implementations have been updated to honor small PIO lifetimes
		values, as proposed in <xref target="I-D.ietf-6man-slaac-renum"
		format="default"/>. For example, please see <xref target="Linux-update"
		format="default"/>.</t>
		</aside>


	<section title="Future Work" anchor="futurework">	</section>
	<t>Improvement in Customer Edge Routers <xref target="RFC7084"/> such that	<section anchor="dhcpv6-pd-slaac-problem" numbered="true" toc="default">
	they can signal the network about stale prefixes and deprecate them accordingly	<name>Interaction between DHCPv6-PD and SLAAC</name>
	can help mitigate the problem discussed in this document for the "home network"	<t>While DHCPv6-PD is normally employed along with SLAAC, the interactio
	scenario. Such work is currently being pursued in <xref target="I-D.ietf-v6ops-	n between the two protocols is largely unspecified. Not unusually, the two proto
	cpe-slaac-renum"/>.</t>	cols are implemented in two different software components, with the interface be
		tween the two implemented by means of some sort of script that feeds the SLAAC i
		mplementation with values learned from DHCPv6-PD.</t>
		<t>At times, the prefix lease time is fed as a constant value to the
		SLAAC router implementation, meaning that, eventually, the prefix lifetimes
		advertised on the LAN side will span <strong>past</strong> the DHCPv6-PD lease
		time. This is clearly incorrect, since the SLAAC router implementation would be
		allowing the use of such prefixes for a period of time that is longer than the o
		ne they have been leased for via DHCPv6-PD. </t>


	<t>Improvements in the SLAAC protocol <xref target="RFC4862"/> and other algorit	</section>
	hms such as "Default Address Selection for IPv6" <xref target="RFC6724"/> would	</section>
	help improve network robustness. Such work is currently being pursued in <xref t	<section anchor="Solutions" numbered="true" toc="default">
	arget="I-D.ietf-6man-slaac-renum"/>.</t>	<name>Operational Mitigations</name>
		<t>The following subsections discuss possible operational workarounds
		for the aforementioned problems.


	<t>The aforementioned work is considered out of the scope of this present docume	</t>
	nt, which only focuses on documenting the problem and discussing operational mit	<section numbered="true" toc="default">
	igations.</t>	<name>Stable Prefixes</name>
		<t>As noted in <xref target="ops" format="default"/>, the use of
		stable prefixes would eliminate the issue in <strong>some</strong> of the
		scenarios discussed in <xref target="intro" format="default"/> of this
		document, such as the typical home network deployment. However, as noted in <xre
		f target="ops" format="default"/>, there might be reasons for which an administr
		ator may want or may
		need to employ dynamic prefixes.</t>
		</section>
		<section anchor="host-side" numbered="true" toc="default">
		<name>SLAAC Parameter Tweaking</name>
		<t>An operator may wish to override some SLAAC parameters such that,
		under normal circumstances, the associated timers will be refreshed/reset, but i
		n the
		presence of network faults (such as the one discussed in this document), the
		associated timers go off and trigger some fault recovering action (e.g., depreca
		te and
		eventually invalidate stale addresses).</t>
		<t>The following router configuration variables from <xref
		target="RFC4861" format="default"/> (corresponding to the "lifetime" parameters
		of PIOs) could be overridden as follows:</t>
		<ul spacing="normal">
		<li>AdvPreferredLifetime: 2700 seconds (45 minutes)</li>
		<li>AdvValidLifetime: 5400 seconds (90 minutes)</li>
		</ul>


	</section>	<aside>
		<t>NOTES:</t>


	<section title="IANA Considerations">	<t>The aforementioned values for AdvPreferredLifetime and AdvValidLifetime are
	<t>	expected to be appropriate for most networks. In some networks, particularly
	This document has no actions for IANA.	those where the operator has complete control of prefix allocation and where hos
	</t>	ts on
	</section>	the network may spend long periods of time sleeping (e.g., sensors with limited
		battery), longer values may be appropriate.</t>
		<t>
		A CE router advertising a sub-prefix of a prefix leased via DHCPv6-PD will
		periodically refresh the Preferred Lifetime and the Valid Lifetime of an
		advertised prefix to AdvPreferredLifetime and AdvValidLifetime, respectively,
		as long as the resulting lifetimes of the corresponding prefixes do not extend
		past the DHCPv6-PD lease time <xref target="I-D.ietf-v6ops-cpe-slaac-renum"
		format="default"/>. </t>


	<section title="Security Considerations">	</aside>
	<t>This document discusses a problem that may arise in scenarios where fla	<t>RATIONALE:</t>
	sh-renumbering events occur, and proposes workarounds to mitigate the aforementi	<ul spacing="normal">
	oned problems. This document does not introduce any new security issues, and thu	<li>In the context of <xref target="RFC8028" format="default"/>,
	s the same security considerations as for <xref target="RFC4861"/> and <xref tar	where it is clear that use of addresses configured for a given prefix is tied
	get="RFC4862"/> apply.</t>	to using the next-hop router that advertised the prefix, it does not make sense
		for the Preferred Lifetime of a PIO to be larger than the Router Lifetime
		(AdvDefaultLifetime) of the corresponding Router Advertisement messages. The
		Valid Lifetime is set to a larger value to cope with transient network
		problems.</li>


		<li>Lacking RAs that refresh information, addresses configured for advertised
		prefixes become deprecated in a more timely manner; therefore, Rule 3 of <xref
		target="RFC6724" format="default"/> causes other configured addresses (if
		available) to be used instead.</li>
		<li>Reducing the Valid Lifetime of PIOs helps reduce the amount of
		time a host may maintain stale information
		and the amount of time an advertising router would need to advertise stale
		prefixes to invalidate them. Reducing the Preferred Lifetime of PIOs helps redu
		ce the amount of time it takes for a host to prefer other working
		prefixes (see <xref target="RFC4861" sectionFormat="of"
		section="12"/>). However, we note that while the values suggested in this secti
		on are an
		improvement over the default values specified in <xref target="RFC4861"
		format="default"/>, they represent a trade-off among a number of factors,
		including responsiveness, possible impact on the battery life of connected
		devices <xref target="RFC7772" format="default"/>, etc. Thus, they may or may
		not provide sufficient mitigation to the problem discussed in this
		document.</li>
		</ul>
		</section>
		</section>
		<section anchor="futurework" numbered="true" toc="default">
		<name>Future Work</name>
		<t>Improvements in Customer Edge routers <xref target="RFC7084"
		format="default"/>, such that they can signal hosts about stale prefixes
		to deprecate (and eventually invalidate) them accordingly, can help mitigate the
		problem discussed in this
		document for the "home network" scenario. Such work is currently being pursued
		in <xref target="I-D.ietf-v6ops-cpe-slaac-renum" format="default"/>.</t>
		<t>Improvements in the SLAAC protocol <xref target="RFC4862"
		format="default"/> and some IPv6-related algorithms, such as "Default Address Se
		lection for
		Internet Protocol Version 6 (IPv6)" <xref target="RFC6724" format="default"/>, w
		ould help improve network
		robustness. Such work is currently being pursued in <xref
		target="I-D.ietf-6man-slaac-renum" format="default"/>.</t>
		<t>The aforementioned work is considered out of the scope of this
		present document, which only focuses on documenting the problem and discussing
		operational mitigations.</t>
		</section>
		<section numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>This document has no IANA actions.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Acknowledgments">	<name>Security Considerations</name>
		<t>This document discusses a problem that may arise in scenarios where
	<t>The authors would like to thank (in alphabetical order) Brian Carpenter, Alis	flash-renumbering events occur and proposes workarounds to mitigate the
	sa Cooper, Roman Danyliw, Owen DeLong, Martin Duke, Guillermo Gont, Philip Hombu	aforementioned problem. This document does not introduce any new security
	rg, Sheng Jiang, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Warren Kumari, Te	issues; therefore, the same security considerations as for <xref target="RFC4861
	d Lemon, Juergen Schoenwaelder, Eric Vyncke, Klaas Wierenga, Robert Wilton, and	" format="default"/> and <xref target="RFC4862" format="default"/> apply.</t>
	Dale Worley, for providing valuable comments on earlier versions of this documen
	t.</t>

	<t>The authors would like to thank (in alphabetical order) Mikael Abrahamsson, L
	uis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, Uesley Correa, Owen DeLo
	ng, Gert Doering, Martin Duke, Fernando Frediani, Steinar Haug, Nick Hilliard, P
	hilip Homburg, Lee Howard, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi
	Palet Martinez, Michael Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for
	providing valuable comments on a previous document on which this document is bas
	ed.</t>

	<t>Fernando would like to thank <!--Niloofar Adeli (Shatel, Iran), -->Alejandro
	D'Egidio and Sander Steffann for a discussion of these issues. Fernando would al
	so like to thank Brian Carpenter who, over the years, has answered many question
	s and provided valuable comments that have benefited his protocol-related work.<
	/t>

	<t>The problem discussed in this document has been previously documented b
	y Jen Linkova in <xref target="I-D.linkova-6man-default-addr-selection-update"/>
	, and also in <xref target="RIPE-690"/>. <xref target="intro"/> borrows text fro
	m <xref target="I-D.linkova-6man-default-addr-selection-update"/>, authored by J
	en Linkova.</t>
	</section>	</section>


	</middle>	</middle>
	<back>	<back>


	<references title="Normative References">	<displayreference target="I-D.linkova-6man-default-addr-selection-update" to="DE
	<!-- <?rfc include="reference.RFC.2119" ?> -->	FAULT-ADDR"/>
	<?rfc include="reference.RFC.8415" ?>	<displayreference target="I-D.ietf-6man-slaac-renum" to="RENUM-RXN"/>
		<displayreference target="I-D.ietf-v6ops-cpe-slaac-renum" to="RENUM-CPE"/>
	<?rfc include="reference.RFC.4861" ?>
	<?rfc include="reference.RFC.4862" ?>


	<?rfc include="reference.RFC.8028" ?>	<references>
	<?rfc include="reference.RFC.6724" ?>	<name>References</name>
	<!-- <?rfc include="reference.RFC.8504" ?> -->	<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.8415.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4861.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4862.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8028.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6724.xml"/>
	</references>	</references>

		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8981.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.7084.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
		C.7721.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7772.xml"/>


	<references title="Informative References">	<!-- [I-D.linkova-6man-default-addr-selection-update] IESG state Expired -->
	<?rfc include="reference.RFC.4941" ?>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
		.linkova-6man-default-addr-selection-update.xml"/>
	<!-- <?rfc include="reference.RFC.2827" ?> -->
	<!-- <?rfc include="reference.RFC.5927" ?> -->
	<!-- <?rfc include="reference.RFC.6105" ?> -->

	<?rfc include="reference.RFC.7084" ?>
	<!-- <?rfc include="reference.RFC.7113" ?> -->
	<?rfc include="reference.RFC.7721" ?>
	<?rfc include="reference.RFC.7772" ?>
	<?rfc include="reference.I-D.linkova-6man-default-addr-selection-update"
	?>
	<?rfc include="reference.I-D.ietf-6man-slaac-renum" ?>

	<?rfc include="reference.I-D.ietf-v6ops-cpe-slaac-renum" ?>

	<reference anchor="Linux-update" target="https://patchwork.ozlabs.org/pro
	ject/netdev/patch/20200419122457.GA971@archlinux-current.localdomain/">
	<front>
	<title>[net-next] ipv6: Honor all IPv6 PIO Valid Lifetime
	values</title>

	<author fullname="Fernando Gont" initials="F." surname="Gont">

	<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks</organization>
	<address>
	<postal>
	<street>Segurola y Habana 4310, 7mo Piso</street>
	<!-- <code>1706</code> -->
	<city>Villa Devoto</city>
	<region>Ciudad Autonoma de Buenos Aires</region>
	<country>Argentina</country>
	</postal>
	<phone>+54 11 4650 8472</phone>
	<email>fgont@si6networks.com</email>
	<uri>https://www.si6networks.com</uri>
	</address>
	</author>

	<date month="April" year="2020"/>
	</front>
	<seriesInfo name="Post to the netdev mailing-list" value="http://
	vger.kernel.org/vger-lists.html"/>
	</reference>

	<reference anchor="GERMAN-DP" target="http://www.bfdi.bund.de/SharedDocs/
	Publikationen/Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv6.pdf?__
	blob=publicationFile">
	<front>
	<title>Einfuhrung von IPv6 Hinweise fur Provider im Priva
	tkundengeschaft und Herstellere</title>


	<author>	<!-- [I-D.ietf-6man-slaac-renum] IESG state I-D Exists -->
	<organization>BFDI</organization>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	</author>	.ietf-6man-slaac-renum.xml"/>


	<date month="November" year="2012"/>	<!-- [I-D.ietf-v6ops-cpe-slaac-renum] IESG state IESG Evaluation::Revised I-D Ne
	</front>	eded -->
	<seriesInfo name="Entschliessung der 84. Konferenz der Datenschut	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
	zbeauftragten des Bundes und der Lander" value="am 7./8. November 2012 in Frankf	.ietf-v6ops-cpe-slaac-renum.xml"/>
	urt (Oder)"/>
	</reference>


	<reference anchor="FRITZ" target="https://www.si6networks.com/2016/02/16/	<reference anchor="Linux-update" target="https://patchwork.ozlabs.org/pr
	quiz-weird-ipv6-traffic-on-the-local-network-updated-with-solution/">	oject/netdev/patch/20200419122457.GA971@archlinux-current.localdomain/">
	<front>	<front>
	<title>Quiz: Weird IPv6 Traffic on the Local Network (upd	<title>Subject: [net-next] ipv6: Honor all IPv6 PIO Valid Lifetime v
	ated with solution)</title>	alues</title>
		<author fullname="Fernando Gont" initials="F." surname="Gont">
		</author>
		<date day="19" month="April" year="2020"/>
		</front>
		<refcontent>message to the netdev mailing list</refcontent>
		</reference>


	<author fullname="Fernando Gont" initials="F." surname="Gont">	<reference anchor="GERMAN-DP" quoteTitle="false" target="http://www.bfdi
		.bund.de/SharedDocs/Publikationen/Entschliessungssammlung/DSBundLaender/84DSK_Ei
		nfuehrungIPv6.pdf?__blob=publicationFile">
		<front>
		<title>"Einführung von IPv6: Hinweise für Provider im Privatkundenge
		schäft und Hersteller" [Introduction of IPv6: Notes for providers in the consume
		r market and manufacturers]</title>
		<author>
		<organization>BFDI</organization>
		</author>
		<date month="November" year="2012"/>
		</front>
		<refcontent>Entschliessung der 84. Konferenz der Datenschutzbeauftragt
		en des Bundes und der Lander [Resolution of the 84th Conference of the Federal a
		nd State Commissioners for Data Protection]</refcontent>
		</reference>


	<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks</organization>	<reference anchor="FRITZ" target="https://www.si6networks.com/2016/02/16
	<address>	/quiz-weird-ipv6-traffic-on-the-local-network-updated-with-solution/">
	<postal>	<front>
	<street>Segurola y Habana 4310, 7mo Piso</street>	<title>Quiz: Weird IPv6 Traffic on the Local Network (updated with s
	<!-- <code>1706</code> -->	olution)</title>
		<author fullname="Fernando Gont" initials="F." surname="Gont">
		<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks</organi
		zation>
		<address>
		<postal>
		<street>Segurola y Habana 4310, 7mo Piso</street>
	<city>Villa Devoto</city>	<city>Villa Devoto</city>

	<region>Ciudad Autonoma de Buenos Aires</region>	<region>Ciudad Autonoma de Buenos Aires</region>
	<country>Argentina</country>	<country>Argentina</country>
	</postal>	</postal>
	<phone>+54 11 4650 8472</phone>	<phone>+54 11 4650 8472</phone>
	<email>fgont@si6networks.com</email>	<email>fgont@si6networks.com</email>
	<uri>https://www.si6networks.com</uri>	<uri>https://www.si6networks.com</uri>
	</address>	</address>
	</author>	</author>
		<date month="February" year="2016"/>
	<date month="February" year="2016"/>	</front>
	</front>	<refcontent>SI6 Networks</refcontent>
	<seriesInfo name="SI6 Networks" value="Blog"/>	</reference>
	</reference>

	<reference anchor="RIPE-690" target="https://www.ripe.net/publications/do
	cs/ripe-690">
	<front>
	<title>Best Current Operational Practice for Operators: I
	Pv6 prefix assignment for end-users - persistent vs non-persistent, and what siz
	e to choose</title>

	<author fullname="Jan Zorz" initials="J." surname="Zorz">

	</author>

	<author fullname="Sander Steffannz" initials="S." surname="Zorz">

	</author>
	<author fullname="Primoz Drazumeric" initials="P." surname="Drazumeric">

	</author>
	<author fullname="Mark Townsley" initials="M." surname="Townsley">

	</author>
	<author fullname="Andrew Alston" initials="J." surname="Alston">

	</author>
	<author fullname="Gert Doering" initials="G." surname="Doering">

	</author>
	<author fullname="Jordi Palet" initials="J." surname="Palet">

	</author>
	<author fullname="Jen Linkova" initials="J." surname="Linkova">

	</author>

	<author fullname="Luis Balbinot" initials="L." surname="Balbinot">

	</author>

	<author fullname="Kevin Meynell" initials="K." surname="Meynell">

	</author>

	<author fullname="Lee Howard" initials="L." surname="Howard">

	</author>

	<date month="October" year="2017"/>
	</front>
	<seriesInfo name="RIPE" value="690"/>
	</reference>

	<reference anchor="UK-NOF" target="https://indico.uknof.org.uk/event/41/c
	ontributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf">
	<front>
	<title>IPv6 Deployment Survey (Residential/Household Serv
	ices) How IPv6 is being deployed?</title>

	<author fullname="Jordi Palet" initials="J." surname="Palet">

	</author>


	<date month="January" year="2018"/>	<reference anchor="RIPE-690" target="https://www.ripe.net/publications/d
	</front>	ocs/ripe-690">
	<seriesInfo name="UK NOF" value="39"/>	<front>
	</reference>	<title>Best Current Operational Practice for Operators: IPv6 prefix
		assignment for end-users - persistent vs non-persistent, and what size to choose
		</title>
		<author fullname="Jan Žorž" initials="J." surname="Žorž"></author>
		<author fullname="Sander Steffann" initials="S." surname="Steffann">
		</author>
		<author fullname="Primož Dražumeric" initials="P." surname="Dražumer
		ič"></author>
		<author fullname="Mark Townsley" initials="M." surname="Townsley"></
		author>
		<author fullname="Andrew Alston" initials="A." surname="Alston"></au
		thor>
		<author fullname="Gert Doering" initials="G." surname="Doering"></au
		thor>
		<author fullname="Jordi Palet Martinez" initials="J." surname="Palet
		Martinez"></author>
		<author fullname="Jen Linkova" initials="J." surname="Linkova"></aut
		hor>
		<author fullname="Luis Balbinot" initials="L." surname="Balbinot"></
		author>
		<author fullname="Kevin Meynell" initials="K." surname="Meynell"></a
		uthor>
		<author fullname="Lee Howard" initials="L." surname="Howard"></autho
		r>
		<date month="October" year="2017"/>
		</front>
		<seriesInfo name="RIPE" value="690"/>
		</reference>


		<reference anchor="UK-NOF" target="https://indico.uknof.org.uk/event/41/
		contributions/542/">
		<front>
		<title>IPv6 Deployment Survey and BCOP</title>
		<author fullname="Jordi Palet Martinez" initials="J." surname="Palet
		Martinez"></author>
		<date month="January" year="2018"/>
		</front>
		<seriesInfo name="UK NOF" value="39"/>
		</reference>
		</references>
	</references>	</references>

		<section numbered="false" toc="default">
		<name>Acknowledgments</name>
		<t>The authors would like to thank (in alphabetical order) <contact
		fullname="Brian Carpenter"/>, <contact fullname="Alissa Cooper"/>,
		<contact fullname="Roman Danyliw"/>, <contact fullname="Owen DeLong"/>,
		<contact fullname="Martin Duke"/>, <contact fullname="Guillermo Gont"/>,
		<contact fullname="Philip Homburg"/>, <contact fullname="Sheng Jiang"/>,
		<contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>,
		<contact fullname="Murray Kucherawy"/>, <contact fullname="Warren
		Kumari"/>, <contact fullname="Ted Lemon"/>, <contact fullname="Juergen
		Schoenwaelder"/>, <contact fullname="Éric Vyncke"/>, <contact
		fullname="Klaas Wierenga"/>, <contact fullname="Robert Wilton"/>, and
		<contact fullname="Dale Worley"/> for providing valuable comments on
		earlier draft versions of this document.</t>
		<t>The authors would like to thank (in alphabetical order) <contact
		fullname="Mikael Abrahamsson"/>, <contact fullname="Luis Balbinot"/>,
		<contact fullname="Brian Carpenter"/>, <contact fullname="Tassos
		Chatzithomaoglou"/>, <contact fullname="Uesley Correa"/>, <contact
		fullname="Owen DeLong"/>, <contact fullname="Gert Doering"/>, <contact
		fullname="Martin Duke"/>, <contact fullname="Fernando Frediani"/>, <contac
		t
		fullname="Steinar Haug"/>, <contact fullname="Nick Hilliard"/>, <contact
		fullname="Philip Homburg"/>, <contact fullname="Lee Howard"/>, <contact
		fullname="Christian Huitema"/>, <contact fullname="Ted Lemon"/>, <contact
		fullname="Albert Manfredi"/>, <contact fullname="Jordi Palet Martinez"/>,
		<contact fullname="Michael Richardson"/>, <contact fullname="Mark Smith"/>
		,
		<contact fullname="Tarko Tikan"/>, and <contact fullname="Ole Troan"/>
		for providing valuable comments on a previous document on which this
		document is based.</t>
		<t>Fernando would like to thank <contact fullname="Alejandro D'Egidio"/> a
		nd <contact
		fullname="Sander Steffann"/> for a discussion of these issues. Fernando wo
		uld
		also like to thank <contact fullname="Brian Carpenter"/> who, over the
		years, has answered many questions and provided valuable comments that
		have benefited his protocol-related work.</t>
		<t>The problem discussed in this document has been previously documented
		by <contact fullname="Jen Linkova"/> in <xref
		target="I-D.linkova-6man-default-addr-selection-update"
		format="default"/> and also in <xref target="RIPE-690"
		format="default"/>.
		<xref target="intro" format="default"/> borrows text
		from <xref target="I-D.linkova-6man-default-addr-selection-update"
		format="default"/>, authored by <contact fullname="Jen Linkova"/>.</t>
		</section>

	</back>	</back>
	</rfc>	</rfc>

	<!--
	Local Variables:
	mode:xml
	End:
	=-->

End of changes. 32 change blocks.
	716 lines changed or deleted	608 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/