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

<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="no" ?> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-v6ops-slaac-renum-05">
   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">

   <!-- xml2rfc v2v3 conversion 3.5.0 -->
   <front>
     <title abbrev="Reaction to Renumbering Events">Reaction of IPv6 Stateless
Address Autoconfiguration (SLAAC) to Flash-Renumbering Events</title>
     <seriesInfo name="RFC" value="8978"/>
     <author fullname="Fernando Gont" initials="F." surname="Gont">
       <organization abbrev="SI6 Networks">SI6 Networks</organization>
       <address>
	 <postal>
	   <street>Segurola y Habana 4310, 7mo Piso</street>
<!--          <code>1706</code> -->
	   <city>Villa Devoto</city>
	   <region>Ciudad Autonoma Autónoma 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>
     <author fullname="Jan Zorz" Žorž" initials="J." surname="Zorz"> surname="Žorž">
       <organization abbrev="6connect">6connect</organization> abbrev="6connect">6connect, Inc.</organization>
       <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> -->
	 <email>jan@6connect.com</email>

       </address>
     </author>
     <author initials="R." surname="Patterson" fullname="Richard Patterson">
       <organization>Sky UK</organization>
       <address>
	 <email>richard.patterson@sky.uk</email>
       </address>
     </author>

    <date/>
     <date month="March" year="2021"/>
     <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>
     <workgroup>v6ops</workgroup>
 <keyword>IPv6</keyword>
 <keyword>problem</keyword>
 <keyword>address</keyword>
 <keyword>prefix delegation</keyword>
 <keyword>DHCPv6</keyword>
 <keyword>stale prefixes</keyword>
 <keyword>old prefixes</keyword>

     <abstract>
      <t><!--A very common IPv6 deployment scenario is that in which a CPE router employs DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one prefix from within the leased prefix is advertised on a local network via SLAAC. -->In
       <t>In scenarios where network configuration information
related to IPv6 prefixes becomes invalid without any explicit and reliable
signaling of that condition (such as when a Customer Edge router crashes and
reboots without knowledge of the previously-employed previously employed prefixes), nodes hosts on the
local network may continue using stale prefixes for an unacceptably long time
(on the order of several days), thus resulting in connectivity problems. This
document describes this issue and discusses operational workarounds that may
help to improve network robustness. Additionally, it highlights areas where
further work may be needed.</t>
     </abstract>
   </front>
   <middle>
     <section anchor="intro" title="Introduction"> numbered="true" toc="default">
       <name>Introduction</name>
       <t>IPv6 Stateless address autoconfiguration Address Autoconfiguration (SLAAC) <xref target="RFC4862"/>
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, with old/stale manner: old
prefixes being phased-out are deprecated (and eventually invalidated) via reduced prefix lifetimes, lifetimes and new prefixes  are introduced (with
longer lifetimes) being introduced at the same time. However, there are several
scenarios that may lead to the so-called "flash-renumbering" events, where the 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 prefixes currently employed prefix (by
explicitly signaling the network about the renumbering event), whereas in other scenarios
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 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:

<list style="symbols">

<t>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"/> 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 LAN side of the CE router via Stateless Address
Autoconfiguration (SLAAC) <xref target="RFC4862"/>. 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, leased and therefore
advertise (via SLAAC) the a new prefix sub-prefix on the LAN side. Hosts will typically
configure addresses for the new prefix, sub-prefix but will also normally retain and may
actively employ the addresses configured for the previously-advertised prefix, previously advertised sub-prefix,
since their associated Preferred Lifetime and Valid Lifetime allow them to do so.</t>

<t>A
so.</li>
	 <li>A router (e.g. (e.g., Customer Edge router) advertises autoconfiguration
 prefixes corresponding (corresponding to prefixes learned via DHCPv6-PD DHCPv6-PD) with constant PIO
 lifetimes that are not synchronized with the DHCPv6-PD lease time (even though Section 6.3 of
 <xref target="RFC8415"/> target="RFC8415" sectionFormat="of" section="6.3"/> requires such
 synchronization). While this behavior violates the aforementioned requirement
 from <xref target="RFC8415"/>, target="RFC8415" format="default"/>, it is not an unusual behavior, behavior.
For example, this is particularly when e.g. true for implementations in which DHCPv6-PD is implemented in a different software module
 than the SLAAC router component.
</t>

<t>A SLAAC.</li>

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

<t>During the VLANs.</li>
	 <li>During a planned network renumbering, renumbering event, a router is configured to
       send an RA with the Preferred Lifetime for the "old" including a Prefix Information
 Option (PIO) for the "old" prefix with the Preferred Lifetime set to zero and the new Valid Lifetime set to a small value, as well as a PIO for the new prefix with a non-zero Preferred Lifetime. default lifetimes.
 However, due to unsolicited RAs being sent to a multicast destination address,
 and multicast being rather unreliable on busy wifi Wi-Fi networks, the RA might not
 be received by local hosts.
</t>

<t>Automated hosts.</li>
	 <li>An automated device config management system performs periodic config
 pushes to network devices.  In these scenarios, network devices may simply immediately
 forget their previous configuration, rather than withdrawing withdraw it gracefully.  If such a push results in
       changing the subnet prefix configured on a particular network, subnet, hosts
       attached to that network would subnet might not get notified about the subnet prefix
       change, and their addresses from the "old" prefix will might not be
      deprecated.
       deprecated (and eventually invalidated) in a timely manner.  A related scenario is the 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.
</t>

</list>
</t>
 </li>
       </ul>
       <t>
Lacking any explicit and reliable signaling to deprecate (and eventually invalidate) the previously-advertised stale prefixes, hosts may continue to employ the previously-configured previously configured addresses, which will typically result in packets being filtered or blackholed (whether because of egress-filtering by either on the CE router or ISP) or within the return traffic being discarded or routed elsewhere. ISP network. </t>
       <t>The default values for the "Preferred Lifetime" Preferred Lifetime and "Valid Lifetime" Valid Lifetime of
PIOs specified in <xref target="RFC4861"/> target="RFC4861" format="default"/> mean that, in the
aforementioned scenarios, the stale addresses would be retained, retained and could be
actively employed for new communications instances, communication instances for an unacceptably long
period of time (one month, month and one week, respectively). This could lead to
interoperability problems, instead of hosts transitioning to the newly-advertised
newly advertised prefix(es) in a more timely manner.</t>
       <t>Some devices have implemented ad-hoc ad hoc mechanisms to address this
problem, such as sending RAs to deprecate apparently-stale (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"/>.
target="FRITZ" format="default"/>. However, this may introduce other
interoperability problems, particularly in multihomed/multiprefix multihomed/multi-prefix
scenarios. This is a clear indication that advice in this area is
warranted.</t>
       <t>Unresponsiveness to these "flash-renumbering" flash-renumbering events is caused by the
inability of the network to deprecate (and eventually invalidate) stale information, information 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 scenarios events
do not occur, occur and that, when they do occur, that 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"/> target="problem" format="default"/> analyzes this problem in
more detail. <xref target="Solutions"/> target="Solutions" format="default"/> describes possible
operational mitigations. <xref target="futurework"/> target="futurework" format="default"/> 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 anchor="problem" numbered="true" toc="default">
       <name>Analysis of the Problem</name>
       <t>As noted in <xref target="intro"/>, target="intro" format="default"/>, the problems problem discussed in this document are is exacerbated by the default values of some protocol parameters and other factors. The following sections analyze each of them in detail.</t>
       <section anchor="ops" title="Use numbered="true" toc="default">
	 <name>Use of Dynamic Prefixes"> Prefixes</name>
	 <t>In network scenarios where dynamic prefixes are employed, renumbering events lead to updated network configuration information being propagated through the network, such that the renumbering events are gracefully handled. However, if the renumbering event happens along with e.g. with, e.g., loss of configuration state by some 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 ones.</t>
	 <t>In simple residential or small office scenario, scenarios, the problem discussed in this document would be avoided if DHCPv6-PD would lease leased "stable" prefixes. However, a recent survey <xref target="UK-NOF"/> target="UK-NOF" format="default"/> indicates that 37% of the responding ISPs employ dynamic IPv6 prefixes. That is, dynamic IPv6 prefixes are an operational reality.</t>
	 <t>Deployment reality aside, there are a number of possible issues associated with stable prefixes:
	<list style="symbols">
		<t>Provisioning
	 </t>
	 <ul spacing="normal">
	   <li>Provisioning systems may be unable to deliver stable IPv6 prefixes.</t>

<t>While 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 be get
leased dynamic sub-prefixes of the stable prefix leased by the ISP. In other
words, every time a prefix is leased 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.
</t>
		<t>While </li>
	   <li>While there is a range of information that may be employed to
correlate network activity <xref target="RFC7721"/>, target="RFC7721" format="default"/>, the use
of stable prefixes clearly simplifies network activity correlation, correlation and may essentially render features such as reduce
the effectiveness of "temporary addresses" <xref target="RFC4941"/> irrelevant. </t>

		<t>There may
target="RFC8981" format="default"/>. </li>
	   <li>There might be existing advice for ISPs to deliver dynamic IPv6
prefixes *by default* (see e.g. <strong>by default</strong> (e.g., see <xref target="GERMAN-DP"/>) target="GERMAN-DP"
format="default"/>) over privacy concerns associated with stable prefixes.</t>
	</list>
	</t> 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 routes or summarizing routes at centralized locations.</li>
	 </ul>
	 <t>For a number of reasons (such as the ones stated above), IPv6 deployments may might employ dynamic prefixes (even at the expense of the issues discussed in this document), and that there might be scenarios in which the dynamics of a network are such that the network exhibits the behaviour behavior of dynamic prefixes. Rather than trying to regulate how operators may run their networks, this document aims at improving network robustness in the deployed Internet.</t>
       </section>
       <section title="Default Timer anchor="timer-problem" numbered="true" toc="default">
	 <name>Default PIO Lifetime 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 manner.</t>
--> (SLAAC)</name>
 <t>The impact of the issue discussed in this document is a function of the lifetime values employed for the PIO lifetimes, PIOs, since these values determine for how long the corresponding addresses will be preferred and considered valid. Thus, when the problem discussed in this document is experienced, the longer the PIO lifetimes, the higher the impact.</t>
	 <t><xref target="RFC4861"/> target="RFC4861" format="default"/> specifies the following default PIO lifetime values:
<list style="symbols">
<t>Preferred
 </t>
	 <ul spacing="normal">
	   <li>Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)</t>
<t>Valid days)</li>
	   <li>Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)</t>
</list>
</t> days)</li>
	 </ul>
	 <t>Under problematic circumstances, such as where when the corresponding network information has become stale without any explicit and reliable signal from the network (as described in <xref target="intro"/>), target="intro" format="default"/>), it could take hosts up to 7 days
    (one week) to deprecate the corresponding addresses, 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 equivalent of not using any timers at all, since taking 7 days or 30 days (respectively) 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 anchor="hosts-problem" numbered="true" toc="default">
	 <name>Recovering from Stale Network Configuration Information" anchor="hosts-problem"> Information</name>
	 <t>SLAAC hosts are unable to recover from stale network configuration information for a number of reasons:
<list style="symbols">
<t>Item information, since:
 </t>
	 <ul spacing="normal">
	   <li>In scenarios where SLAAC routers explicitly signal the
     renumbering event, hosts will typically deprecate, but not
     invalidate, the stale addresses, since item "e)" of Section 5.5.3 of <xref target="RFC4862"/> target="RFC4862" sectionFormat="of"
     section="5.5.3"/> specifies that an unauthenticated RA may never reduce
     the "RemainingLifetime" valid lifetime of an address to less than two hours. If
     Communication with the RemainingLifetime new "users" of an address is smaller than 2 hours, then a Valid Lifetime smaller than 2 hours the stale prefix
     will not be ignored. The Preferred Lifetime of an address can be reduced to any value to avoid using a possible, since the stale prefix for new communications.
</t>
<t>In will still be
     considered "on-link" by the local hosts.</li>
	   <li>In the absence of explicit signalling signaling from SLAAC routers (such as sending PIOs with a "Preferred Lifetime" set to 0), routers, SLAAC
     hosts will typically fail to recover from stale configuration
     information in a timely manner. However, when a network element is able manner, since hosts would need to explicitly signal rely
     on the renumbering event, it will only be able to deprecate last Preferred Lifetime and Valid Lifetime advertised
     for the stale prefix, but not to invalidate the prefix in question. Therefore, communication with the new "owners" of the stale prefix will not be possible, since for the stale prefix will still be considered "on-link".
</t>
</list>
</t>
<!--
<t><xref target="stale-config"/> corresponding addresses to become
     deprecated and subsequently invalidated. Please see <xref target="timer-problem"
     format="default"/> of
     this document specifies for a local policy that SLAAC hosts can implement to heuristically infer that network configuration information has changed and recover from stale prefixes.</t>
--> discussion of the default PIO lifetime values.</li>
	 </ul>

 </section>
       <section title="Lack anchor="cpe-problem" numbered="true" toc="default">
	 <name>Lack of Explicit Signaling about Stale Information" anchor="cpe-problem"> Information</name>
	 <t>Whenever prefix information has changed, a SLAAC router should advertise not only advertise the new information, information but should also advertise the
 stale information with appropriate lifetime values (both "Preferred
Lifetime" the Preferred
 Lifetime and "Valid Lifetime" 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 scenarios certain scenarios, such as when a CE router crashes and reboots, the CE
router may have no knowledge about the previously-advertised prefixes, previously advertised prefixes and thus may
might be unable to advertise them with appropriate lifetimes (in order to
deprecate and eventually invalidate them). </t>
<t>However,
	 <t>In any case, we note that, as discussed in <xref target="hosts-problem"/>, target="hosts-problem"
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"/>).
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"/> target="RFC4862"
format="default"/> would deprecate the corresponding prefixes, prefixes but would fail
to invalidate them.

<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
Some </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"/>. target="I-D.ietf-6man-slaac-renum"
format="default"/>. For example, please see <xref target="Linux-update"/>.
</t>
</list>
</t>

<!--
<t><xref target="sig-stale-config"/> updates the SLAAC specification such that routers explicitly notify SLAAC hosts about the stale network configuration information, and hosts can recover from it upon receipt of such notifications. <xref target="CPE"/> specifies the corresponding requirements for CPE routers.</t>
--> target="Linux-update"
format="default"/>.</t>
	 </aside>

 </section>
       <section title="Interaction Between anchor="dhcpv6-pd-slaac-problem" numbered="true" toc="default">
	 <name>Interaction between DHCPv6-PD and SLAAC" anchor="dhcpv6-pd-slaac-problem"> SLAAC</name>
	 <t>While DHCPv6-PD is normally employed along with SLAAC, the interaction between the two protocols is largely unspecified. Not unusually, the two protocols are implemented in two different software components components, with the interface between the two implemented by means of 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 router implementation, meaning that, eventually, the prefix lifetime lifetimes
advertised on the LAN side will span *past* <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 longer period of time that is longer than it has the one they have been granted usage of those prefixes leased for via DHCPv6-PD. </t>

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

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

       </t>
       <section title="Stable Prefixes"> numbered="true" toc="default">
	 <name>Stable Prefixes</name>
	 <t>As noted in <xref target="ops"/>, target="ops" format="default"/>, the use of
stable prefixes would eliminate the issue in *some* <strong>some</strong> of the
scenarios discussed in <xref target="intro"/> target="intro" format="default"/> of this
document, such as the typical home network deployment. However, even as noted in such scenarios, <xref target="ops" format="default"/>, there might be reasons for which an administrator may want or may
need to employ dynamic prefixes</t> prefixes.</t>
       </section>
       <section title="SLAAC anchor="host-side" numbered="true" toc="default">
	 <name>SLAAC Parameter Tweaking" anchor="host-side"> 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 in 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. (e.g., deprecate and subsequently
eventually invalidate stale addresses).
</t>

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

<list>
<t>AdvPreferredLifetime: follows:</t>
	 <ul spacing="normal">
	   <li>AdvPreferredLifetime: 2700 seconds (45 minutes)</t>
<t>AdvValidLifetime: minutes)</li>
	   <li>AdvValidLifetime: 5400 seconds (90 minutes)</t>
</list>
</t>

<t>
<list style="hanging">
<t hangText="NOTES:"><vspace blankLines="0" />
The minutes)</li>
	 </ul>

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

<t>The aforementioned values for AdvPreferredLifetime and AdvValidLifetime are
expected to be appropriate for most networks. In some networks, particularly
those where the operator has complete control of prefix allocation and where hosts on
the network may spend long periods of time sleeping (e.g., sensors with limited
battery), longer values may be appropriate.
</t> 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 lifetime lifetimes of the corresponding prefixes does do not extend
past the DHCPv6-PD lease time <xref target="I-D.ietf-v6ops-cpe-slaac-renum"/>.
</t>
</list> target="I-D.ietf-v6ops-cpe-slaac-renum"
format="default"/>. </t>

<t>
<list style="hanging">
<t hangText="RATIONALE:">
<list style="symbols">
<t>In

 </aside>
	   <t>RATIONALE:</t>
	     <ul spacing="normal">
	       <li>In the context of <xref target="RFC8028"/>, target="RFC8028" format="default"/>,
where it is clear that use of addresses configured for a given prefix is tied
to using the next-hop router that advertised the prefix, it does not make sense
for the "Preferred Lifetime" Preferred Lifetime of a PIO to be larger than the "Router Lifetime" Router Lifetime
(AdvDefaultLifetime) of the corresponding Router Advertisement messages. The "Valid Lifetime"
Valid Lifetime is set to a much larger value to cope with transient network problems.</t>
<!--
<t>As a result, this document updates <xref target="RFC4861"/> such that the default Valid Lifetime (AdvValidLifetime) and Preferred Lifetime (AdvPreferredLifetime) of PIOs are specified as a function of the "Router Lifetime" (AdvDefaultLifetime) of Router Advertisement messages.</t>
-->

<t>Lacking
problems.</li>

 <li>Lacking RAs that refresh information, addresses configured for advertised
prefixes become deprecated in a more timely manner, and thus manner; therefore, Rule 3 of <xref target="RFC6724"/>
target="RFC6724" format="default"/> causes other configured addresses (if
available) to be used instead.</t>

<t>We note that lowering the default values for instead.</li>
	       <li>Reducing the "Valid Lifetime" 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 deprecate them, while reducing invalidate them. Reducing the default "Preferred Lifetime" would Preferred Lifetime of PIOs helps reduce the amount of time it takes for a host to prefer other working
 prefixes (see Section 12 of <xref target="RFC4861"/>). target="RFC4861" sectionFormat="of"
 section="12"/>). However, we note that while the values suggested in this section are an
 improvement over the default values specified in <xref target="RFC4861"/>, 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"/>, target="RFC7772" format="default"/>, etc. Thus, they may or may
 not provide sufficient mitigation to the problem discussed in this document.</t>
</list>
</t>
</list>
</t>
 document.</li>
	     </ul>
       </section>
     </section>
     <section title="Future Work" anchor="futurework">
      <t>Improvement anchor="futurework" numbered="true" toc="default">
       <name>Future Work</name>
       <t>Improvements in Customer Edge Routers routers <xref target="RFC7084"/> target="RFC7084"
format="default"/>, such that they can signal the network hosts about stale prefixes and
to deprecate (and eventually invalidate) them accordingly 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"/>.</t> target="I-D.ietf-v6ops-cpe-slaac-renum" format="default"/>.</t>
       <t>Improvements in the SLAAC protocol <xref target="RFC4862"/> target="RFC4862"
format="default"/> and other algorithms some IPv6-related algorithms, such as "Default Address Selection for IPv6"
Internet Protocol Version 6 (IPv6)" <xref target="RFC6724"/> target="RFC6724" format="default"/>, would help improve network
robustness. Such work is currently being pursued in <xref target="I-D.ietf-6man-slaac-renum"/>.</t>
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 title="IANA Considerations">
      <t>
This numbered="true" toc="default">
       <name>IANA Considerations</name>
       <t>This document has no actions for IANA.
</t> IANA actions.</t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document discusses a problem that may arise in scenarios where
flash-renumbering events occur, occur and proposes workarounds to mitigate the
aforementioned problems. problem. This document does not introduce any new security issues, and thus
issues; therefore, the same security considerations as for <xref target="RFC4861"/> target="RFC4861" format="default"/> and <xref target="RFC4862"/> target="RFC4862" format="default"/> apply.</t>
    </section>

<section title="Acknowledgments">

<t>The authors would like to thank (in alphabetical order) Brian Carpenter, Alissa Cooper, Roman Danyliw, Owen DeLong, Martin Duke, Guillermo Gont, Philip Homburg, Sheng Jiang, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Warren Kumari, Ted Lemon, Juergen Schoenwaelder, Eric Vyncke, Klaas Wierenga, Robert Wilton, and Dale Worley, for providing valuable comments on earlier versions of this document.</t>

<t>The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, Uesley Correa, Owen DeLong, Gert Doering, Martin Duke, Fernando Frediani, Steinar Haug, Nick Hilliard, Philip 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 based.</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 also like to thank 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 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 from <xref target="I-D.linkova-6man-default-addr-selection-update"/>, authored by Jen Linkova.</t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
<!--	<?rfc include="reference.RFC.2119" ?> -->
	<?rfc include="reference.RFC.8415" ?>

	<?rfc include="reference.RFC.4861" ?>
	<?rfc include="reference.RFC.4862" ?>

	<?rfc include="reference.RFC.8028" ?>
	<?rfc include="reference.RFC.6724" ?>
<!--	<?rfc include="reference.RFC.8504" ?> -->

<displayreference target="I-D.linkova-6man-default-addr-selection-update" to="DEFAULT-ADDR"/>
<displayreference target="I-D.ietf-6man-slaac-renum" to="RENUM-RXN"/>
<displayreference target="I-D.ietf-v6ops-cpe-slaac-renum" to="RENUM-CPE"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8028.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/>
	</references>

    <references title="Informative References">
	<?rfc include="reference.RFC.4941" ?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7772.xml"/>

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

<!--	<?rfc include="reference.RFC.6105" ?> [I-D.ietf-6man-slaac-renum] IESG state I-D Exists -->

	<?rfc include="reference.RFC.7084" ?>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-6man-slaac-renum.xml"/>

<!--	<?rfc include="reference.RFC.7113" ?> [I-D.ietf-v6ops-cpe-slaac-renum] IESG state IESG Evaluation::Revised I-D Needed -->
	<?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" ?>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-v6ops-cpe-slaac-renum.xml"/>

        <reference anchor="Linux-update" target="https://patchwork.ozlabs.org/project/netdev/patch/20200419122457.GA971@archlinux-current.localdomain/">
          <front>
			<title>[net-next]
            <title>Subject: [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 day="19" month="April" year="2020"/>
          </front>
		<seriesInfo name="Post
	  <refcontent>message to the netdev mailing-list" value="http://vger.kernel.org/vger-lists.html"/> mailing list</refcontent>
        </reference>

        <reference anchor="GERMAN-DP" quoteTitle="false" target="http://www.bfdi.bund.de/SharedDocs/Publikationen/Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv6.pdf?__blob=publicationFile">
          <front>
			<title>Einfuhrung
            <title>"Einführung von IPv6 IPv6: Hinweise fur für Provider im Privatkundengeschaft Privatkundengeschäft und Herstellere</title> Hersteller" [Introduction of IPv6: Notes for providers in the consumer market and manufacturers]</title>
            <author>
              <organization>BFDI</organization>
            </author>
            <date month="November" year="2012"/>
          </front>
		<seriesInfo name="Entschliessung
          <refcontent>Entschliessung der 84. Konferenz der Datenschutzbeauftragten des Bundes und der Lander" value="am 7./8. November 2012 in Frankfurt (Oder)"/> Lander [Resolution of the 84th Conference of the Federal and State Commissioners for Data Protection]</refcontent>
        </reference>

        <reference anchor="FRITZ" target="https://www.si6networks.com/2016/02/16/quiz-weird-ipv6-traffic-on-the-local-network-updated-with-solution/">
          <front>
            <title>Quiz: Weird IPv6 Traffic on the Local Network (updated with solution)</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="February" year="2016"/>
          </front>
		<seriesInfo name="SI6 Networks" value="Blog"/>
          <refcontent>SI6 Networks</refcontent>
        </reference>

        <reference anchor="RIPE-690" target="https://www.ripe.net/publications/docs/ripe-690">
          <front>
            <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 Zorz" Žorž" initials="J." surname="Zorz">

    </author> surname="Žorž"></author>
            <author fullname="Sander Steffannz" Steffann" initials="S." surname="Zorz">

    </author> surname="Steffann"></author>
            <author fullname="Primoz Drazumeric" fullname="Primož Dražumeric" initials="P." surname="Drazumeric">

    </author> surname="Dražumerič"></author>
            <author fullname="Mark Townsley" initials="M." surname="Townsley">

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

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

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

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

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

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

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

    </author> 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/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf"> target="https://indico.uknof.org.uk/event/41/contributions/542/">
          <front>
            <title>IPv6 Deployment Survey (Residential/Household Services) How IPv6 is being deployed?</title> and BCOP</title>
            <author fullname="Jordi Palet" Palet Martinez" initials="J." surname="Palet">

    </author> surname="Palet Martinez"></author>
            <date month="January" year="2018"/>
          </front>
          <seriesInfo name="UK NOF" value="39"/>
        </reference>
      </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"/>, <contact
      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"/> and <contact
      fullname="Sander Steffann"/> for a discussion of these issues. Fernando would
      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>
</rfc>
<!--
Local Variables:
mode:xml
End:
=-->