<?xml version="1.0" encoding="US-ASCII"?>
<!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" ?>

<rfc updates="4191, 4861, 4862, 8106" category="std"  ipr="trust200902"
docName="draft-ietf-6man-slaac-renum-04">
  <front>
    <title abbrev="Reaction to Renumbering Events">Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events</title>


    <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 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" initials="J." surname="Zorz">


      <organization abbrev="6connect">6connect</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> -->
      </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>Internet</area>
    <workgroup>IPv6 Maintenance (6man) Working Group</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 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 renumbering scenarios where an IPv6 prefix suddenly becomes invalid, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such renumbering scenarios.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction">
<t>IPv6 network renumbering is usually assumed to take place in a planned manner, with old/stale prefixes being phased-out via reduced prefix lifetimes while new prefixes (with normal lifetimes) are introduced. However, there are a number of scenarios that may lead to the so-called "flash-renumbering" events, where the prefix being employed on a network suddenly becomes invalid and replaced by a new prefix <xref target="RFC8978"/>.  In such scenarios, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. <xref target="RFC8978"/> discusses this problem in detail.</t>


<t>In some scenarios, the local router triggering the network renumbering event may try to deprecate the currently-employed prefixes (by  explicitly signaling the network about the renumbering event), whereas in other scenarios the renumbering event may happen inadvertently,  without the router explicitly signaling the scenario to local hosts.</t>


<t>From the perspective of a Stateless Address Autoconfiguration (SLAAC) host, there are two different (but related) problems to be solved:
<list style="symbols">
<t>Avoiding the use of stale addresses for new communication instances</t>
<t>Performing "garbage collection" for stale prefixes and related network configuration information</t>
</list>
</t>

<t>Clearly, if a host has both working and stale addresses, it is paramount that it employs working addresses for new communication instances. Additionally, a host should also perform garbage collection for the stale prefixes/addresses, since they not only unnecessarily tie system resources, but also prevent communication with the new "owners" of the stale prefixes.</t>

</section>

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


<t>The term "globally reachable" is used in this document as defined in <xref target="RFC8190"/>.
</t> 

<t>The term "Global Unicast Address" (or its acronym "GUA") is used throughout this document to refer to "globally reachable" <xref target="RFC8190"/> addresses. That is, when used throughout this document, GUAs do NOT include Unique Local Addresses (ULAs) <xref target="RFC4193"/>. Similarly, the term "Global Unicast prefix" (or "GUA prefix") is employed throughout this document to refer to network prefixes that specify GUAs, and does NOT include the ULA prefix (FC00::/7) <xref target="RFC4193"/>.
</t> 



<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <xref target='RFC2119' /> <xref target='RFC8174' /> when, and only when, they
      appear in all capitals, as shown here.
</t>

</section>


<section title="SLAAC reaction to Flash-renumbering Events" anchor="problem">

<t>As noted in <xref target="intro"/>, in some scenarios the router triggering the renumbering event may be able to explicitly signal this event, while in other scenarios the renumbered hosts may need to infer a renumbering event is taking place. The following subsections analyze specific considerations for each of these scenarios.</t>

<section title="Renumbering without Explicit Signaling">

<t>In the absence of explicit signalling from SLAAC routers (such as sending Prefix Information Options (PIOs) with small lifetimes to deprecate stale prefixes), stale prefixes will remain preferred and valid according to the Preferred Lifetime and Valid Lifetime parameters (respectively) of the last received PIO. <xref target="RFC4861"/> specifies the following default values for PIOs:
<list style="symbols">
<t>Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)</t>
<t>Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)</t>
</list>


</t>

<t>This means that, in the absence of explicit signaling by a SLAAC router to deprecate a prefix, it will take a host 7 days (one week) to deprecate the corresponding addresses, and 30 days (one month) to eventually remove any addresses configured for the stale prefix. Clearly, for any practical purposes, employing such long default values is generally unacceptable for most deployment scenarios that may experience flash-renumbering events.

<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
<xref target="RFC8978"/> provides an operational recommendation for Customer Edge (CE) routers to override the standard default Preferred Lifetime (AdvPreferredLifetime) and Valid Lifetime (AdvValidLifetime) to 2700 seconds (45 minutes) and 5400 seconds (90 minutes), respectively, thus improving the state of affairs for CE router scenarios.
</t>
</list>
</t>

<t>Use of more appropriate timers in Router Advertisement messages can help limit the amount of time that hosts will maintain stale configuration information. Additionally, hosts may normally in a position to infer whether a prefix has become stale -- for example, if a router ceases to advertise an existing prefix while it continues to advertise other prefixes.</t>

<t><xref target="router-config"/> formally updates <xref target="RFC4861"/> to use of more appropriate (i.e., shorter) default lifetimes for PIOs, while <xref target="stale-config"/> specifies a local policy that SLAAC hosts may implement to infer that network configuration information has changed, such that stale configuration information can be phased out.</t>

<!--
<t><xref target="router-config"/> recommends the use of more appropriate lifetimes for PIOs, while <xref target="hosts-config"/> proposes to cap the accepted Valid Lifetime and Preferred Lifetime values at hosts, such that more appropriate values are employed even in the presence of legacy routers.</t>

<t><xref target="stale-config"/> specifies a local policy that SLAAC hosts can implement to heuristically infer that network configuration information has changed, such that stale configuration information can be phased out.</t>
-->
</section>


<section title="Renumbering with Explicit Signaling">

<t>In scenarios where a local router is aware about the renumbering event, it may try to phase out the stale network configuration information. In these scenarios, there are two aspects to be considered:
<list style="symbols">
<t>The amount of time during which the router should continue trying to deprecate the stale network configuration information</t>
<t>The ability of SLAAC hosts to phase out stale configuration in a timelier manner.</t>
</list>
</t>

<t>Since the network could be become partitioned at any arbitrary time and for an arbitrarily long period of time, routers need to contemplate the possible scenario where hosts receive an RA message, and the network subsequently becomes partitioned. This means that in order to reliably deprecate stale information, a router would should try to deprecate a prefix for a period of time equal "Preferred Lifetime" used when advertising the prefix, and try to invalidate the prefix for a period of time equal to the "Valid Lifetime" (see Section 12 of <xref target="RFC4861"/>) used when advertising the prefix. 
</t>
<t>
<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
Once the number of seconds in the original "Preferred Lifetime" have elapsed, all hosts would have deprecated the corresponding addresses anyway, while once the number of seconds in the "Valid Lifetime" have elapsed, the corresponding addresses would be invalidated and removed.
</t>
</list>
</t>
<t>Thus, use of more appropriate default lifetimes for PIOs, as proposed in <xref target="router-config"/>, would reduce the amount of time a stale prefix would need to be announced as such by a router in order to ensure that it is deprecated/invalidated.</t>


<t>In scenarios where a router has positive knowledge that a prefix has become invalid and thus could signal this condition to local hosts, the current specifications will prevent SLAAC hosts from fully recovering from such stale information: Item "e)" of Section 5.5.3 of <xref target="RFC4862"/> specifies that an RA may never reduce the "RemainingLifetime" to less than two hours. Additionally, if the RemainingLifetime of an address is smaller than 2 hours, then a Valid Lifetime smaller than 2 hours will be ignored. The inability to invalidate a stale prefix may prevent communication with the new "owners" of a prefix, and thus is highly undesirable. On the other hand, the Preferred Lifetime of an address *may* be reduced to any value to avoid the use of a stale prefix for new communications. 
</t>
<t><xref target="sig-stale-config"/> formally updates <xref target="RFC4862"/> to remove this restriction, such that hosts may react to the advertised "Valid Lifetime" even if it is smaller than 2 hours.</t>
<t>Finally, <xref target="init"/> recommends that routers disseminate network configuration information when a network interface is initialized, such that new configuration information propagates in a timelier manner.</t>
</section>


</section>


      <section title="Improvements to Stateless Address Autoconfiguration (SLAAC)" anchor="slaac-improvements">

<!-- XXX: En el algoritmo me queda revisar cuando LTA se setea a 0. Y ahora escribir el resumen de las mitigaciones -->

<t>
The following subsections update <xref target="RFC4861"/> and <xref target="RFC4862"/>, such that the problem discussed in this document is mitigated. The updates in the following subsections are mostly orthogonal, and mitigate different aspects of SLAAC that prevent a timely reaction to flash renumbering events.

<list style="symbols">
<t>Reduce the default Valid Lifetime and Preferred Lifetime of PIOs (<xref target="router-config"/>): 
<vspace blankLines="0" />This helps limits the amount of time a host may employ stale information, and also limits the amount of time a router needs to try to deprecate stale information.</t>
<!--
<t>Cap the received Valid Lifetime and Preferred Lifetime of PIOs (<xref target="hosts-config"/>): 
<vspace blankLines="0" />This helps limit the amount of time a host will employ stale information, even in the presence of legacy (<xref target="RFC4861"/>) routers.</t>
-->
<t>Honor PIOs with small Valid Lifetimes (<xref target="sig-stale-config"/>): 
<vspace blankLines="0" />This allows routers to invalidate stale prefixes, since otherwise <xref target="RFC4861"/> would prevent hosts from honoring PIOs with a Valid Lifetime smaller than two hours.</t>
<t>Recommend routers to retransmit configuration information upon interface initialization/reinitialization (<xref target="init"/>): 
<vspace blankLines="0" />This helps spread the new information in a timelier manner, and also deprecate stale information via host-side heuristics (see <xref target="stale-config"/>).</t>
<t>Recommend routers to always send all options (i.e. the complete configuration information) in RA messages, and in the smallest possible number of packets (<xref target="ras"/>): 
<vspace blankLines="0" />This helps propagate the same information to all hosts, and also allows hosts to better infer that information missing in RA messages has become stale (see <xref target="stale-config"/>).</t>
<t>Infer stale network configuration information from received RAs (<xref target="stale-config"/>): 
<vspace blankLines="0" />This allows hosts to deprecate stale network configuration information, even in the absence of explicit signaling.</t>
</list>
</t>



<section title="More Appropriate Lifetime Values" anchor="timers">

<section title="Router Configuration Variables" anchor="router-config">

<t>This document formally updates <xref target="RFC4861"/> to modify the default values of the Preferred Lifetime and the Valid Lifetime of PIOs as follows:
<list style="symbols">
<t>AdvPreferredLifetime: ND_DEFAULT_PREFERRED_LIFETIME</t>
<t>AdvValidLifetime: ND_DEFAULT_VALID_LIFETIME</t>
</list>
</t>

<t>This document formally updates <xref target="RFC4191"/> to specify the default Route Lifetime of Route Information Options (RIOs) as follows:
<list style="symbols">
<t>Route Lifetime: Default: ND_DEFAULT_PREFERRED_LIFETIME</t>
</list>
</t>

<t>This document formally updates <xref target="RFC8106"/> to modify the default Lifetime of Recursive DNS Server Options as:
<list style="symbols">
<t>Lifetime: Default: ND_DEFAULT_PREFERRED_LIFETIME</t>
</list>
</t>

<t>Additionally, this document formally updates <xref target="RFC8106"/> to modify the default Lifetime of DNS Search List Options as:
<list style="symbols">
<t>Lifetime: Default: ND_DEFAULT_PREFERRED_LIFETIME</t>
</list>
</t>


</section>

<section title="Default Neighbor Discovery Lifetime Variables" anchor="default-values">
<t>This document defines the following variables to be employed for the default lifetimes of Neighbor Discovery options (please see <xref target="router-config"/> above):

<list style="symbols">
<t>ND_DEFAULT_PREFERRED_LIFETIME: max(AdvDefaultLifetime, 3 * MaxRtrAdvInterval)</t>
<t>ND_DEFAULT_VALID_LIFETIME: 2 * ND_DEFAULT_PREFERRED_LIFETIME</t>
</list>
</t>

<t>where:</t>
<t>
<list style="hanging">
	<t hangText="AdvDefaultLifetime:"><vspace blankLines="0" />Router configuration variable specified in <xref target="RFC4861"/>, which specifies the value to be placed in the Router Lifetime field of Router Advertisements sent from the interface, in seconds.</t>

	<t hangText="MaxRtrAdvInterval:"><vspace blankLines="0" />Router configuration variable specified in <xref target="RFC4861"/>, which specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. </t>
	
	<t hangText="max():"><vspace blankLines="0" />A function that computes the maximum of its arguments.</t>
	</list>
</t>

<t>
<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
<t>The expression above computes of maximum among AdvDefaultLifetime and "3 * MaxRtrAdvInterval" (the default value of AdvDefaultLifetime, as per <xref target="RFC4861"/>) to accommodate the case where an operator might simply want to disable one local router for maintenance, while still having the router advertise SLAAC configuration information.
</t>

<xref target="RFC4861"/> specifies the default value of MaxRtrAdvInterval as 600 seconds, and the default value of AdvDefaultLifetime as 3 * MaxRtrAdvInterval. Therefore, when employing default values for MaxRtrAdvInterval and AdvDefaultLifetime, the 
default values of ND_DEFAULT_PREFERRED_LIFETIME and ND_DEFAULT_VALID_LIFETIME become 1800 seconds (30 minutes) and 3600 seconds (1 one hour), respectively. We note that when implementing BCP202 <xref target="RFC7772"/>, AdvDefaultLifetime will typically be in the range of 45-90 minutes, and therefore the value of ND_DEFAULT_PREFERRED_LIFETIME will be in the range 45-90 minutes, while the value of ND_DEFAULT_VALID_LIFETIME will be in the range of 90-180 minutes.
</t>
</list>
</t>

</section>

</section>

  


<section title="Honor Small PIO Valid Lifetimes" anchor="sig-stale-config">

<t>The entire item "e)" (pp. 19-20) from Section 5.5.3 of <xref target="RFC4862"/> is replaced with the following text:
<list style="hanging">
<t>e)  If the advertised prefix is equal to the prefix of an address
      configured by stateless autoconfiguration in the list, the
      valid lifetime and the preferred lifetime of the address should 
      be updated by processing the Valid Lifetime and the Preferred
      Lifetime (respectively) in the received advertisement.
</t>
</list>
</t>

<!--
<t>
<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
"Processing" the Valid Lifetime and Preferred Lifetime includes capping the received values as specified in <xref target="hosts-config"/> of this document.
</t>
</list>
</t>
-->





<t>
<list style="hanging">
<t hangText="RATIONALE:">
<list style="symbols">
<t>
This change allows hosts to react to the signal provided by a router that has positive knowledge that a prefix has become invalid.
</t>
<t>
The behavior described in <xref target="RFC4862"/> had been incorporated during
         the revision of the original IPv6 Stateless Address
         Autoconfiguration specification (<xref target="RFC1971"/>). At the time, the
         IPNG working group decided to mitigate the attack vector
         represented by Prefix Information Options with very short
         lifetimes, on the premise that these packets represented a bigger
         risk than other ND-based attack vectors <xref target="IPNG-minutes"/>.
<vspace blankLines="1" />
         While reconsidering the trade-offs represented by such
         decision, we conclude that the drawbacks of the aforementioned mitigation outweigh the possible benefits.
<vspace blankLines="1" />
         In scenarios where RA-based attacks are of concern, proper
         mitigations such as RA-Guard <xref target="RFC6105"/> <xref target="RFC7113"/> or SEND <xref target="RFC3971"/> should be
         implemented. 
</t>      
<!--
<t>Attacks aiming at disabling an advertised prefix via a Valid Lifetime of 0 are not really more harmful than other attacks that can be performed via forged RA messages, such as those aiming at completely disabling a next-hop router via an RA that advertises a Router Lifetime of 0, or  performing a Denial of Service (DoS) attack by advertising illegitimate prefixes via PIOs. In scenarios where RA-based attacks are of concern, proper mitigations such as RA-Guard <xref target="RFC6105"/> <xref target="RFC7113"/> should be implemented.
</t>

-->
</list>
</t>
</list>
</t>

</section>


<section title="Interface Initialization" anchor="init">



<t>When an interface is initialized, it is paramount that network configuration information is spread on the corresponding network (particularly in scenarios where an interface has been re-initialized, and the conveyed information has changed). Thus, this document replaces the following text from Section 6.2.4 of <xref target="RFC4861"/>:
<list style="hanging">

<t>

   In such cases, the router MAY transmit up to
   MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the
   same rules as when an interface becomes an advertising interface.
</t>
</list>

with:

<list style="hanging">
<t>
   In such cases, the router SHOULD transmit 
   MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the
   same rules as when an interface becomes an advertising interface.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="RATIONALE:">
<list style="symbols">
<t>Use of stale information can lead to interoperability problems. Therefore, it is important that new configuration information propagates in a timelier manner to all hosts.</t>
</list>
</t>
</list>
</t>

<t>
<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
<xref target="RFC9096"/> specifies recommendations for CPE routers to signal any stale network configuration information.</t>
</list>
</t>


</section>


<section title="Conveying Information in Router Advertisement (RA) Messages" anchor="ras">

<t>Intentionally omitting information in Router Advertisements may prevent the propagation of such information, and may represent a challenge for hosts that need to infer whether they have received a complete set of SLAAC configuration information. As a result, this section recommends that, to the extent that is possible, RA messages contain a complete set of SLAAC information.
</t>

<t>This document replaces the following text from Section 6.2.3 of <xref target="RFC4861"/>:
<list style="hanging">

<t>
   A router MAY choose not to include some or all options when sending
   unsolicited Router Advertisements.  For example, if prefix lifetimes
   are much longer than AdvDefaultLifetime, including them every few
   advertisements may be sufficient.  However, when responding to a
   Router Solicitation or while sending the first few initial
   unsolicited advertisements, a router SHOULD include all options so
   that all information (e.g., prefixes) is propagated quickly during
   system initialization.</t>

<t>
   If including all options causes the size of an advertisement to
   exceed the link MTU, multiple advertisements can be sent, each
   containing a subset of the options.
</t>
</list>

with:

<list style="hanging">

<t>
   When sending Router Advertisements, a router SHOULD include all 
   options.</t>
<t>
   If including all options would cause the size of an advertisement 
   to exceed the link MTU, multiple advertisements can be sent, each
   containing a subset of the options. In all cases, routers SHOULD
   convey all information using the smallest possible number of 
   packets, and convey options of the same type in the same 
   packet to the extent possible.
</t>
</list>
</t>
<t>
<list style="hanging">
<t hangText="RATIONALE:">
<list style="symbols">
<t>Sending information in the smallest possible number of packets was somewhat already implied by the original text in <xref target="RFC4861"/>. Including all options when sending RAs leads to simpler code (as opposed to dealing with special cases where specific information is intentionally omitted), and also helps hosts infer when they have received a complete set of SLAAC configuration information. Note that while <xref target="RFC4861"/> allowed some RAs to omit some options, to the best of the authors' knowledge, all SLAAC router implementations  always send all options in the smallest possible number of packets. Therefore, this section simply aligns the protocol specifications with existing implementation practice.</t>
</list>
</t>
</list>
</t>

</section>


<section title="Recovery from Stale Configuration Information without Explicit Signaling" anchor="stale-config">

<t>TBD</t>
<!--
<t>This section specifies an algorithm, "Lifetime Avoidance Algorithm" (LTA), that allows hosts to infer when previously-advertised information (such as autoconfiguration prefixes) has become stale, such that the stale configuration information can be deprecated in a timelier manner. Most of the value of this algorithm is in being able to mitigate the problem discussed in <xref target="RFC8978"/>  at hosts themselves, without relying on updates of the behavior of local routers.</t>


<t>The algorithm consists of two conceptual building-blocks:
<list style="symbols">
<t>Detection of possible configuration change</t>
<t>Validation/Refresh of configuration information</t>
</list>
</t>


<t>Possible configuration changes can be inferred when a SLAAC router (as identified by its link-local address) ceases to advertise a previously-advertised information. In such scenarios, nodes should poll the local router via unicasted Router Solicitations (RS) to verify that the router in question has indeed ceased to advertise the aforementioned information. And, in such cases the associated configuration information may be discarded.</t>

<t>Please note that in the context of multi-prefix/multi-router networks <xref target="RFC8028"/> <xref target="RFC8504"/>, SLAAC configuration information should be associated with each advertising router. Thus, when a router ceases to advertise some configuration information:
<list style="symbols">
<t>If this was the only router advertising the aforementioned information, the associated information should be discarded. </t>
<t>If other routers were advertising the aforementioned information, this information should simply be dis-associated with the router that ceased to advertise it, and the fate of this information (and configured resources) should depend solely on the routers that continue advertising it.
</t>
</list>
</t>

<t>Implementation of this kind of heuristic allows a timelier reaction to network configuration changes even in scenarios where there is no explicit signaling from the network, thus improving robustness.
</t>

<t>As discussed in <xref target="ras"/>, <xref target="RFC4861"/> does not require routers to convey all RA options in the same message. Therefore, the algorithm specified in this section is designed such that it can cope with this corner case that, while not found in the deployed Internet, could still theoretically exist.</t>

<section title="Target Neighbor Discovery Options" anchor="target-options">

<t>The LTA algorithm SHOULD be applied to the following Neighbor Discovery options:
<list style="symbols">
<t>Prefix Information Option <xref target="RFC4861"/></t>
<t>Route Information Option (RIO) <xref target="RFC4191"/></t>
<t>DNS Search Options (RDNSSO) <xref target="RFC8106"/></t>
<t>DNS Search List Options (DNSSLO) <xref target="RFC8106"/></t>
</list>
</t>

</section>


<section title="Configuration Variables and Local State Information" anchor="local-info">
<t>In the context of multi-prefix/multi-router networks <xref target="RFC8028"/> <xref target="RFC8504"/>, each option from <xref target="target-options"/> is associated with each advertising SLAAC router.
<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
Throughout this specification, each router is identified by its link-local address.</t>
</list>

Additionally, hosts will augment state information for each option with a timestamp (OPT_LAST variable bellow) that records the time at which the option was last advertised by a particular router.
<list style="hanging">
<t hangText="NOTE:"><vspace blankLines="0" />
While not strictly required, we note that existing implementations may already record the last time an option was advertised by a given router as a possible implementation approach to be able to compute the remaining lifetime of the option.</t>
</list>
</t>

<t>The algorithm employs the following variables:
<list style="hanging">
<t hangText="LTA_MODE:">
<vspace blankLines="0" />
A boolean variable associated with each SLAAC advertising router that specifies whether the local host is currently performing the LTA algorithm for that router. It is initialized to FALSE.
</t>
<t hangText="LTA_LAST:">
<vspace blankLines="0" />
A variable associated with each SLAAC advertising router that stores the time (in seconds) when the local host last entered the LTA algorithm for this router. It is initialized to 0.
</t>

<t hangText="RS_LAST:">
<vspace blankLines="0" />
A variable associated with each SLAAC advertising router that stores the time (in seconds) when the local host last sent a unicasted Router Solicitation to the router in question. It is initialized to 0.
</t>

<t hangText="RS_COUNT:">
<vspace blankLines="0" />
A variable associated with each SLAAC advertising router that stores the number of unicasted Router Solicitations that have been set to the associated router since the last time the LTA algorithm was executed. It is initialized to 0.
</t>

<t hangText="RS_COUNT_MAX:">
<vspace blankLines="0" />
A configuration variable specifying the maximum number of unicasted Router Solicitations that a host will send to a SLAAC advertising router as part of the LTA algorithm. It defaults to 1.
</t>


<t hangText="RS_RNDTIME:">
<vspace blankLines="0" />
A host-wide variable specifying a random amount of time the host should wait before sending the first unicasted Router Solicitation message to a SLAAC router as part of the LTA algorithm. It should be initialized to a value in the range from 0 to 10 seconds when the system is bootstrapped.
</t>

<t hangText="RS_TIMEOUT:">
<vspace blankLines="0" />
A host-wide variable specifying the amount of time to wait for a response to a unicasted Router Solicitation sent as part of the LTA algorithm.
</t>

<t hangText="OPT_LAST:">
<vspace blankLines="0" />
A timestamp associated with each option (from <xref target="target-options"/>) received from each SLAAC advertising router. It is set to the current system time.
</t>

<t hangText="RA_WIN:">
<vspace blankLines="0" />
A host-wide configuration variable specifying a time window over which a SLAAC advertising router may convey all SLAAC configuration information. It is meant to cope with the theoretical case where a router may spread SLAAC information over several RA messages. 
It defaults to 3 seconds.
</t>

<t hangText="LTA_CYCLE:">
<vspace blankLines="0" />
This variable accounts for the maximum time that may elapse for the entire LTA algorithm. It is used as a shortcut throughout the algorithm. Its value is computed as: LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT.
</t>

</list>
</t>

</section>



<section title="Algorithm specification" anchor="protocol-spec">

<section title="State machine">

<t>STATE=NONE, INPUT= Initialize(), NEXT_STATE=LISTENING
<list style="symbols">
	<t>LTA_MODE=FALSE</t>
	<t>LTA_LAST=0</t>
	<t>RS_LAST=0</t>
	<t>RS_COUNT=0</t>
	<t>LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT</t>
</list>

<t>STATE=LISTENING, INPUT=Router Advertisement is received</t>
<list>
<t>Perform normal processing of RA message</t>

</list>

</section>


<section title="Algorithm Specification">

<t>Initialization when a new SLAAC advertising router is learned:</t>

    <t>
    <figure><artwork>
    LTA_MODE=FALSE
    LTA_LAST=0
    RS_LAST=0
    RS_COUNT=0
    LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT
    </artwork>
    </figure>

    </t>


   
<t>Upon receipt of a Router Advertisement message, and after normal processing of the message, perform the following actions:</t>

    <t>
    <figure><artwork>
    TIME= time()
   
    For each option advertised by this router in the received RA:
        OPT_LAST= time()


    IF LTA_MODE==FALSE &amp;&amp; TIME &gt; (LTA_LAST+LTA_CYCLE)
        IF the RA is missing any previously-received information:
	    LTA_MODE=TRUE
	    LTA_LAST=TIME
    </artwork>
    </figure>

    </t>


<t>Time-driven events:</t>


    <t>
    <figure><artwork>
    IF LTA_MODE==TRUE:
        TIME=time()
        
        IF TIME > (LTA_LAST + RA_WIN + RS_RNDTIME) &amp;&amp; TIME &gt; 
                (RS_LAST + RS_TIMEOUT) &amp;&amp; RS_COUNT &lt; RS_COUNT_MAX:
            SendRS()
            RS_LAST=TIME
            RS_COUNT++
            
        IF TIME &gt;  (LTA_LAST + LTA_CYCLE)
            Disaasociate any options for which OPT_LAST &lt; LTA_LAST
            LTA_MODE= FALSE
            RS_COUNT=0
    </artwork>
    </figure>

    </t>
 

<t>NOTES:
<list style="symbols">
<t>time() is a monotonically-increasing counter that is incremented once per second, and is employed to measure time.</t>

<t>SendRS() is a function sends a unicasted Router Solicitation message to the target router (subject to sending rules in <xref target="RFC4861"/>).</t>
</list>

</t>

</section>

-->
      </section>
</section>




    <section title="IANA Considerations">
      <t>
This document has no actions for IANA.
</t>
    </section>


<section title="Implementation Status">
<t>[NOTE: This section is to be removed by the RFC-Editor before this document is published as an RFC.]</t>

<t>This section summarizes the implementation status of the updates proposed in this document. In some cases, they correspond to variants of the mitigations proposed in this document (e.g., use of reduced default lifetimes for PIOs, albeit using different values than those recommended in this document). In such cases, we believe these implementations signal the intent to deal with the problems described in <xref target="RFC8978"/> while lacking any guidance on the best possible approach to do it.
</t>


<section title="More Appropriate Lifetime Values" anchor="impl-timers">

<section title="Router Configuration Variables" anchor="impl-router-config">
<section title="rad(8)">
<t>We have produced a patch for OpenBSD's rad(8) <xref target="rad"/> that employs the default lifetimes recommended in this document, albeit it has not yet been committed to the tree. The patch is available at: &lt;https://www.gont.com.ar/code/fgont-patch-rad-pio-lifetimes.txt&gt;.
</t>
</section>

<section title="radvd(8)">
<t>The radvd(8) daemon <xref target="radvd"/>, normally employed by Linux-based router implementations, currently employs different default lifetimes than those recommended in <xref target="RFC4861"/>. radvd(8) employs the following default values <xref target="radvd.conf"/>:
<list style="symbols">
<t>Preferred Lifetime: 14400 seconds (4 hours)</t>
<t>Valid Lifetime: 86400 seconds (1 day)</t>
</list>
</t>
<t>This is not following the specific recommendation in this document, bu is already a deviation from the current standards.</t>
</section>
</section>

<!--
<section title="Processing of PIO Lifetimes at Hosts" anchor="impl-hosts-config">
<section title="NetworkManager">
<t>NetworkManager <xref target="NetworkManager"/>, user-space SLAAC implementation employed by some Linux-based operating systems (such as Fedora or Ubuntu), caps the lifetimes of the received PIOs as recommended in this document.</t>
</section>
<section title="slaacd(8)">
<t>slaacd(8) <xref target="slaacd"/>, a user-space SLAAC implementation employed by OpenBSD, caps the lifetimes of the received PIOs as recommended in this document.</t>
</section>
<section title="systemd-networkd">
<t>systemd-networkd <xref target="systemd"/>, a user-space SLAAC implementation employed by some Linux-based operating systems, caps the lifetimes of the received PIOs as recommended in this document.</t>
</section>
</section>
-->

</section>
<section title="Honor Small PIO Valid Lifetimes" anchor="impl-sig-stale-config">
<section title="Linux Kernel">
<t>A Linux kernel implementation of this document has been committed to the net-next tree. The implementation was produced in April 2020 by Fernando Gont &lt;fgont@si6networks.com&gt;. The corresponding patch can be found at: &lt;https://patchwork.ozlabs.org/project/netdev/patch/20200419122457.GA971@archlinux-current.localdomain/&gt;</t>
</section>

<section title="NetworkManager">
<t>NetworkManager <xref target="NetworkManager"/> processes RA messages with a Valid Lifetime smaller than two hours as recommended in this document.</t>
</section>
</section>

<section title="Conveying Information in Router Advertisement (RA) Messages" anchor="impl-ras">
<t>We know of no implementation that splits network configuration information into multiple RA messages.</t>
</section>


<section title="Recovery from Stale Configuration Information without Explicit Signaling" anchor="impl-stale-config">

<section title="dhcpcd(8)">
<t>The dhcpcd(8) daemon <xref target="dhcpcd"/>, a user-space SLAAC implementation employed by some Linux-based and BSD-derived operating systems, will set the Preferred Lifetime of addresses corresponding to a given prefix to 0 when a single RA from the router that previously advertised the prefix fails to advertise the corresponding prefix. However, it does not affect the corresponding Valid Lifetime. Therefore, it can be considered a partial implementation of this feature.</t>
</section>

</section>



<section title="Other mitigations implemented in products">
<t><xref target="FRITZ"/> is a Customer Edge Router that tries to deprecate stale prefixes by advertising stale prefixes with a Preferred Lifetime of 0, and a Valid Lifetime of 2 hours (or less). There are two things to note with respect to this implementation:
<list style="symbols">
<t>Rather than recording prefixes on stable storage (as recommended in <xref target="RFC9096"/>), this implementation checks the source address of IPv6 packets, and assumes that usage of any address that does not correspond to a prefix currently-advertised by the Customer Edge Router is the result of stale network configuration information. Hence, upon receipt of a packet that employs a source address that does not correspond to a currently-advertised prefix, this implementation will start advertising the corresponding prefix with small lifetimes, with the intent of deprecating it.</t>
<t>Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 of <xref target="RFC4862"/> (discussed in <xref target="sig-stale-config"/> of this document), upon first occurrence of a stale prefix, this implementation will employ a decreasing Valid Lifetime, starting from 2 hours (7200 seconds), as opposed to a Valid Lifetime of 0.</t>
</list>
</t>
</section>
</section>



    <section title="Security Considerations">

         <t>The protocol update in <xref target="sig-stale-config"/> could allow an on-link
         attacker to perform a Denial of Service attack against local hosts,
         by sending a forged RA with a PIO with a Valid Lifetime of 0.
         Upon receipt of that packet, local hosts would invalidate the
         corresponding prefix, and therefore remove any addresses
         configured for that prefix, possibly terminating e.g. associated TCP
         connections. However, an attacker may
         achieve similar effects via a number other Neighbor Discovery (ND) attack
         vectors, such as directing traffic to a non-existing node until 
         ongoing TCP connections time out,
         or performing a ND-based man-in-the-middle (MITM) attack and
         subsequently forging TCP RST segments to cause on-going TCP
         connections to be reset. Thus, for all practical purposes,
         this attack vector does not really represent any greater risk
         than other ND attack vectors. As noted in <xref target="sig-stale-config"/> , in scenarios where RA-based attacks
         are of concern, proper
         mitigations such as RA-Guard <xref target="RFC6105"/> <xref target="RFC7113"/> or SEND <xref target="RFC3971"/> should be
         implemented. 
         </t>
<!--
<t>When it comes to the algorithm in <xref target="stale-config"/>, an attacker could impersonate the legitimate router and send an RA that does not advertise legitimate prefixes being employed in the local network. This cause the corresponding addresses to become deprecated. However, the addresses would not become invalid since normal unsolicited RA messages would refresh the "Preferred Lifetime" and "Valid Lifetime" of such addresses.</t>

<t>However, an attacker that can impersonate a router could more easily deprecate addresses by advertising the legitimate prefixes with the "Preferred Lifetime" set to 0, or perform a plethora of other possible of Denial of Service attacks based on forged RA messages. Therefore, when attacks based on forged RA packets are a concern, technologies such as RA-Guard <xref target="RFC6105"/> <xref target="RFC7113"/> should be deployed.</t>

<t>Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts may help limit the duration of the effects of non-sustained attacks that employ forged RAs with PIOs, since hosts would now recover in a timelier manner.</t>
-->
    </section>



<section title="Acknowledgments">
<t>The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Lorenzo Colitti, Owen DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob Hinden, Philip Homburg, Lee Howard, Christian Huitema, Tatuya Jinmei, Erik Kline, Ted Lemon, Jen Linkova, Albert Manfredi, Roy Marples, Florian Obser, Jordi Palet Martinez, Michael Richardson, Hiroki Sato, Mark Smith, Hannes Frederic Sowa, Dave Thaler, Tarko Tikan, Ole Troan, Eduard Vasilenko, and Loganaden Velvindron, for providing valuable comments on earlier versions of this document.</t>

<t>The algorithm specified in <xref target="stale-config"/> is the result of mailing-list discussions over previous versions of this document with Philip Homburg.</t>

<t>Fernando would like to thank <!--Niloofar Adeli (Shatel, Iran), -->Alejandro D'Egidio and Sander Steffann for a discussion of these issues, which led to the publication of <xref target="RFC8978"/>, and eventually to this document.</t>
<t>Fernando would also like to thank Brian Carpenter who, over the years, has answered many questions and provided valuable comments that has 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"/>.</t>
      -->
      
    </section>

  </middle>
  <back>

    <references title="Normative References">
	<?rfc include="reference.RFC.2119" ?>
 
	<?rfc include="reference.RFC.4193" ?>
 

<!--	<?rfc include="reference.RFC.4291" ?> -->
	<?rfc include="reference.RFC.8028" ?>
	<?rfc include="reference.RFC.4861" ?>
	<?rfc include="reference.RFC.4862" ?>
	<?rfc include="reference.RFC.7772" ?>
	<?rfc include="reference.RFC.8174" ?>
 	<?rfc include="reference.RFC.8190" ?>  

	<?rfc include="reference.RFC.8504" ?>

	</references>





    <references title="Informative References">

	<!-- Original ND spec -->
	<?rfc include="reference.RFC.1971" ?>
	
	<!-- SEND -->
	<?rfc include="reference.RFC.3971" ?>

	<reference anchor="IPNG-minutes" target="https://www.ietf.org/proceedings/38/97apr-final/xrtftr47.htm">
		<front>
	
			<title>IPNG working group (ipngwg) Meeting Minutes</title>


			<author>
				<organization>IETF</organization>
			</author>




			<date month="April" year="1997"/>
		</front>
		<!-- April 7-11, 1997 -->
		<seriesInfo name="Proceedings of the thirty-eightt Internet Engineering Task Force" value=""/>
	</reference>
	

	<?rfc include="reference.RFC.2827" ?>
	<?rfc include="reference.RFC.4191" ?>
	<?rfc include="reference.RFC.8106" ?>
	
	<?rfc include="reference.RFC.5927" ?>
	<?rfc include="reference.RFC.6105" ?>
	<?rfc include="reference.RFC.6724" ?>
<!--	<?rfc include="reference.RFC.7084" ?>  CPE -->
	<?rfc include="reference.RFC.7113" ?>
<!--
	<?rfc include="reference.I-D.linkova-6man-default-addr-selection-update" ?>
-->

	<?rfc include="reference.RFC.8978" ?>
	<?rfc include="reference.RFC.9096" ?>

	<reference anchor="dhcpcd" target="https://roy.marples.name/projects/dhcpcd/">
		<front>
			<title>dhcpcd - a DHCP client</title>


    <author fullname="Roy Marples" initials="R." surname="Marples">

    </author>

			<date/>
		</front>

	</reference>

	<reference anchor="radvd" target="http://www.litech.org/radvd/">
		<front>
			<title>Linux IPv6 Router Advertisement Daemon (radvd)</title>


    <author fullname="Reuben Hawkins" initials="R." surname="Hawkins">

    </author>

    <author fullname="Robin Johnson" initials="R." surname="Johnson">

    </author>
			<date/>
		</front>

	</reference>


	<reference anchor="NetworkManager" target="https://wiki.gnome.org/Projects/NetworkManager">
		<front>
			<title>NetworkManager web site</title>


    <author fullname="NetworkManager" initials="" surname="NetworkManager">

    </author>


			<date/>
		</front>

	</reference>


	<reference anchor="systemd" target="https://systemd.io/">
		<front>
			<title>systemd web site</title>


    <author fullname="systemd" initials="" surname="systemd">

    </author>


			<date/>
		</front>

	</reference>




	<reference anchor="rad" target="https://cvsweb.openbsd.org/src/usr.sbin/rad/">
		<front>
			<title>OpenBSD Router Advertisement Daemon - rad(8)</title>


    <author fullname="Florian Obser" initials="F." surname="Obser">

    </author>


			<date/>
		</front>

	</reference>

	<reference anchor="slaacd" target="https://cvsweb.openbsd.org/src/usr.sbin/slaacd/">
		<front>
			<title>OpenBSD SLAAC Daemon - slaacd(8)</title>


    <author fullname="Florian Obser" initials="F." surname="Obser">

    </author>


			<date/>
		</front>

	</reference>

	<reference anchor="radvd.conf" target="https://github.com/reubenhwk/radvd/blob/master/radvd.conf.5.man">
		<front>
			<title>radvd.conf - configuration file of the router advertisement daemon</title>


    <author fullname="Reuben Hawkins" initials="R." surname="Hawkins">

    </author>

    <author fullname="Robin Johnson" initials="R." surname="Johnson">

    </author>
			<date/>
		</front>

	</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"/>
	</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" 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>
-->






    </references>



<section anchor="other" title="Analysis of Some Suggested Workarounds">
<t>[This section is to be removed before publication of this document as an RFC].</t>
<t>During the discussion of this document, some alternative workarounds were suggested on the 6man mailing-list. The following subsections analyze these suggested workarounds, in the hopes of avoiding rehashing the same discussions.</t>

<section anchor="icmp" title="On a Possible Reaction to ICMPv6 Error Messages">
<t>It has been suggested that if configured addresses become stale, a CPE enforcing ingress/egress filtering (BCP38) (<xref target="RFC2827"/>) could send ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed ingress/egress policy) error messages to the sending node, and that, upon receipt of such error messages, the sending node could perform heuristics that might help to mitigate the problem discussed in this document.</t>

<t>The aforementioned proposal has a number of drawbacks and limitations:
	<list style="symbols">
		<t>It assumes that the CPE routers enforce ingress/egress filtering <xref target="RFC2827"/>. While this is desirable behaviour, it cannot be relied upon.</t>
		<t>It assumes that if the CPE enforces ingress/egress filtering, the CPE will signal the packet drops to the sending node with ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed ingress/egress policy) error messages. While this may be desirable, <xref target="RFC2827"/> does not suggest signaling the packet drops with ICMPv6 error messages, let alone the use of specific error messages (such as Type 1 Code 5) as suggested.</t>
		<t>ICMPv6 Type 1 Code 5 could be interpreted as the employed address being stale, but also as a selected route being inappropriate/suboptimal. If the later, deprecating addresses or invalidating addresses upon receipt of these error messages would be inappropriate.</t>
		<t>Reacting to these error messages would create a new attack vector that could be exploited from remote networks. This is of particular concern since ICMP-based attacks do not even require that the Source Address of the attack packets be spoofed <xref target="RFC5927"/>.</t>
	</list>
</t>
</section>

<section anchor="sas" title="On a Possible Improvement to Source Address Selection">

<t><xref target="RFC6724"/> specifies source address selection (SAS) for IPv6. Conceptually, it sorts the candidate set of source addresses for a given destination, based on a number of pair-wise comparison rules that must be successively applied until there is a "winning" address.</t>

<t>An implementation might improve source address selection, and prefer the most-recently advertised information. In order to incorporate the "freshness" of information in source address selection, an implementation would be updated as follows:
	<list style="symbols">
		<t>The node is assumed to maintain a timer/counter that is updated at least once per second. For example, the time(2) function from unix-like systems could be employed for this purpose.</t>
		<t>The local information associated with each prefix advertised via RAs on the local network is augmented with a "LastAdvertised" timestamp value. Whenever an RA with a PIO with the "A" bit set for such prefix is received, the "LastAdvertised" timestamp is updated with the current value of the timer/counter.</t>
		<t><xref target="RFC6724"/> is updated such that this rule is incorporated:
			<list style="hanging">
				<t hangText="Rule 7.5: Prefer fresh information">
   If one of the two source addresses corresponds to a prefix that has been more recently advertised, say LastAdvertised(SA) > LastAdvertised(SA), then prefer that address (SA in our case).
				</t>
			</list>
		</t>
	</list>
</t>

<t>A clear benefit of this approach is that a host will normally prefer "fresh" addresses over possibly stale addresses.</t>

<t>However, there are a number of drawbacks associated with this approach:
	<list style="symbols">
		<t>In scenarios where multiple prefixes are being advertised on the same LAN segment, the new SAS rule is *guaranteed* to result in non-deterministic behaviour, with hosts frequently changing the default source address. This is certainly not desirable from a troubleshooting perspective.</t>

		<t>Since the rule must be incorporated before "Rule 8: Use longest matching prefix" from <xref target="RFC6724"/>, it may lead to suboptimal paths.
		</t>

		<t>This new rule may help to improve the selection of a source address, but it does not help with the housekeeping (garbage collection) of configured information:
			<list style="symbols">
				<t>If the stale prefix is re-used in another network, nodes employing stale addresses and routes for this prefix will be unable to communicate with the new "owner" of the prefix, since the stale prefix will most likely be considered "on-link".</t>
				<t>Given that the currently recommended default value for the "Valid Lifetime" of PIOs is 2592000 seconds (30 days), it would take too long for hosts to remove the configured addresses and routes for the stale prefix. While the proposed update in <xref target="timers"/> of this document would mitigate this problem, the lifetimes advertised by the local SLAAC router are not under the control of hosts.</t>
			</list>
		</t>



	</list>
</t>

<t>As a result, updating IPv6 source address selection does not relieve nodes from improving their SLAAC implementations as specified in <xref target="slaac-improvements"/>, if at all desirable. On the other hand, the algorithm specified in <xref target="stale-config"/> would result in Rule 3 of <xref target="RFC6724"/> employing fresh addresses, without leading to non-deterministic behaviour.
</t>
</section>
</section>

  </back>
</rfc>
<!--
Local Variables:
mode:xml
End:
=-->
