<?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="bcp" xmlns:xi="http://www.w3.org/2001/XInclude" updates="7084" ipr="trust200902"
docName="draft-ietf-v6ops-cpe-slaac-renum-08"> docName="draft-ietf-v6ops-cpe-slaac-renum-08" number="9096" obsoletes="" submissionType="IETF"
category="bcp" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>

    <title abbrev="Reaction to abbrev="CE Requirements for Renumbering Events">Improving the
    Reaction of Customer Edge Routers to IPv6 Renumbering Events</title>
    <seriesInfo name="RFC" value="9096"/>
    <seriesInfo name="BCP" value="234"/>
    <author fullname="Fernando Gont" initials="F." surname="Gont">
      <organization abbrev="SI6 Networks">SI6 Networks</organization>
      <address>
        <postal>
	  <extaddr>7mo Piso</extaddr>
	  <street>Segurola y Habana 4310, 7mo Piso</street> 4310</street>
          <city>Villa Devoto</city>
          <region>Ciudad Autonoma de Buenos Aires</region>
          <country>Argentina</country>
        </postal>
        <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@6connect.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>
    <author fullname="Bernie Volz" initials="B" surname="Volz">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization> abbrev="Individual Contributor">Individual Contributor</organization>
      <address>
        <postal>
          <street>300 Beaver Brook Rd</street>
          <city>Boxborough, MA 01719</city>
          <country>USA</country>
          <street>116 Hawkins Pond Road</street>
          <city>Center Harbor</city>
	  <region>NH</region>
	  <code>03226</code>
          <country>United States of America</country>
        </postal>
        <email>volz@cisco.com</email>
        <email>bevolz@gmail.com</email>
      </address>
    </author>

    <date/>
    <date year="2021" month="August" />
    <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>

 <keyword>IPv6</keyword>
 <keyword>problem</keyword>
 <keyword>address</keyword>
 <keyword>prefix delegation</keyword>
 <keyword>DHCPv6</keyword>
 <keyword>stale prefixes</keyword>
 <keyword>old prefixes</keyword>

<keyword/>

    <abstract>
      <t>
This document specifies improvements to Customer Edge Routers routers that help mitigate the problems that may arise when network configuration information becomes invalid, invalid without any explicit signaling of that condition to the local nodes. This document updates RFC7084. RFC 7084.
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>In scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router (CE) router crashes and reboots without knowledge of the previously-employed previously employed configuration information), hosts on the local network will continue using stale information for an unacceptably long period of time, thus resulting in connectivity problems. This problem is documented in detail in <xref target="RFC8978"/>.</t> target="RFC8978" format="default"/>.</t>
      <t>This document specifies improvements to Customer Edge (CE) Routers CE routers that help mitigate the aforementioned problem for residential and small office scenarios. It specifies recommendations for the default behavior of CE Routers, and routers but does not preclude the availability of configuration knobs that might allow an operator or user to manually-configure manually configure the CE Router router to deviate from these recommendations. This document updates RFC7084. RFC 7084.
</t>
    </section>
    <section anchor="reqs-language" title="Requirements Language">
<t>The numbered="true" toc="default">
      <name>Requirements Language</name>

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

    </section>
    <section anchor="CPE" title="Improved numbered="true" toc="default">
      <name>Improved Customer Edge Router Behavior"> Behavior</name>
      <t>This section specifies and clarifies requirements for Customer Edge Routers CE routers that can help mitigate the problem discussed in <xref target="intro"/>, target="intro" format="default"/>, particularly when they employ prefixes learned via DHCPv6-Prefix DHCPv6 Prefix Delegation (DHCPv6-PD) <xref target="RFC8415"/> target="RFC8415" format="default"/> on the WAN-side WAN side with Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862"/> target="RFC4862" format="default"/> or DHCPv6 <xref target="RFC8415"/> target="RFC8415" format="default"/> on the LAN-side. LAN side. The recommendations in this document help improve robustness at the Customer Edge Router CE router (on which the user or ISP may have no control), control) and do not preclude implementation of host-side improvements such as those specified in <xref target="I-D.ietf-6man-slaac-renum"/>.</t> target="I-D.ietf-6man-slaac-renum" format="default"/>.</t>

      <t>This document specifies additional WAN-side prefix-delegation (WPD) requirements to those specified in <xref target="RFC7084"/>:

	<list style="symbols">

		<t>WPD-9: CE target="RFC7084" format="default"/>:

      </t>

<dl>

<dt>WPD-9:</dt>
<dd>CE routers SHOULD NOT <bcp14>SHOULD NOT</bcp14> automatically send DHCPv6-PD RELEASE
messages upon reboot restart events. See <xref target="dhcpv6-release"/> for further details.</t>
<!-- OLD text, changed in response to Ben Kaduk's comments
		<t>WPD-10: CE Routers MUST by default use a stable IAID value that does not change between CE Router restarts, DHCPv6 client restarts, or interface state changes. e.g., Transient PPP interfaces. See <xref target="dhcpv6-iaid"/> target="dhcpv6-release"
format="default"/> for further details.</t>
-->

<t>WPD-10: CE Routers MUST details.
</dd>

<dt>WPD-10:</dt>
<dd>CE routers <bcp14>MUST</bcp14> by default use a WAN-side IAID Identity
Association IDentifier (IAID) value that is stable between CE Router router restarts,
DHCPv6 client restarts, or interface state changes (e.g., Transient transient PPP
interfaces), unless the CE Router router employs the IAID techniques discussed in Section 4.5 of
<xref target="RFC7844"/>. target="RFC7844" sectionFormat="of" section="4.5" format="default"/>.
See <xref target="dhcpv6-iaid"/> target="dhcpv6-iaid" format="default"/> for further details.
</t>

	</list>

</t>
</dd>

</dl>

      <t>This document also replaces LAN-side requirement L-13 from <xref target="RFC7084"/> target="RFC7084" format="default"/> with:

<list style="symbols">
		<t>L-13: CE

</t>

<dl>
<dt>L-13:</dt>
<dd>CE routers MUST <bcp14>MUST</bcp14> signal stale configuration information as
specified in <xref target="sig-stale-config"/>.</t>
</list>
</t> target="sig-stale-config" format="default"/>.
</dd>

</dl>

      <t>Finally, this document specifies the following additional LAN-side requirements to those from <xref target="RFC7084"/>:

	<list style="symbols">
		<t>L-15: target="RFC7084" format="default"/>:

      </t>

<dl>

<dt>L-15:</dt>
<dd>

CE routers MUST NOT <bcp14>MUST NOT</bcp14> advertise prefixes via SLAAC or assign
addresses or delegate prefixes via DHCPv6 on the LAN-side, employing LAN side using lifetimes that
exceed the remaining lifetimes of the corresponding prefixes learned from on the WAN-side
WAN side via DHCPv6-PD.  For more details, see <xref target="dhcpv6-pd-slaac"/>.</t>
		<t>L-16: CE target="dhcpv6-pd-slaac"
format="default"/>.
</dd>

<dt>L-16:
</dt>
<dd>CE routers SHOULD <bcp14>SHOULD</bcp14> advertise capped SLAAC option lifetimes and lifetimes,
capped DHCPv6 IA Address Option and IA Prefix Option lifetimes, as specified in <xref target="lan-lifetimes"/>.</t>
	</list>
</t>

<!--
XXX: OLD
<t>This document specifies additional LAN-side requirements to requirements L-1 through L-14 specified in <xref target="RFC7084"/>:

	<list style="symbols">
		<t>L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign addresses or delegate prefixes via DHCPv6 on the LAN-side, employing lifetimes that exceed the remaining lifetimes of the corresponding prefixes learned from the WAN-side via DHCPv6-PD. For more details, see <xref target="dhcpv6-pd-slaac"/>.</t>
		<t>L-16: CE routers SHOULD advertise capped SLAAC option lifetimes lifetimes, and capped DHCPv6 IA Address Option and IA Prefix Option option lifetimes, as specified
in <xref target="lan-lifetimes"/>.</t>
		<t>L-17: CE routers MUST signal stale configuration information as specified in <xref target="sig-stale-config"/>.</t>
		<t>L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot events. See <xref target="dhcpv6-release"/> for further details.</t>
	</list>
</t>
--> target="lan-lifetimes" format="default"/>.
</dd>

</dl>

    <section title="Automatic anchor="dhcpv6-release" numbered="true" toc="default">
        <name>Automatic DHCPv6 RELEASEs" anchor="dhcpv6-release"> RELEASEs</name>
        <t>
	  Some CE Routers routers are known to automatically send DHCPv6-PD RELEASE
	  messages upon reboot restart events. However, this may inadvertently
	  trigger a flash-renumbering scenario, along with the associated
	  problems discussed in <xref target="RFC8978"/>, target="RFC8978" format="default"/>,
	  that this document attempts to mitigate.
	</t>
        <t>
As a result, requirement WPD-9 from <xref target="CPE"/> target="CPE" format="default"/>
specifies that CE routers SHOULD NOT <bcp14>SHOULD NOT</bcp14> automatically send
DHCPv6-PD RELEASE messages upon reboot restart events.
</t>
      </section>
      <section title="Stability anchor="dhcpv6-iaid" numbered="true" toc="default">
        <name>Stability of IAIDs" anchor="dhcpv6-iaid"> IAIDs</name>
        <t>
   <xref target="RFC8415"/> target="RFC8415" format="default"/> requires that the IAID for an IA MUST
   <bcp14>MUST</bcp14> be consistent across restarts of the DHCP
   client. However, some popular CE Routers routers are known to select new random IAIDs e.g. everytime
   IAIDs, e.g., every time the underlying PPP session is established. established or when
   the device is rebooted. This could be the result of extrapolating the
   behavior described in <xref target="RFC7844"/>, target="RFC7844" format="default"/> or simply a
   consequence of not storing IAIDs on stable storage along with failing failure to
   employ an algorithm that consistently generates the same IAID upon
   reboots. Thus, requirement WPD-10 from <xref target="CPE"/> target="CPE"
   format="default"/> prevents CE Routers routers from inadvertently triggering
   flash-renumbering events on the local network.
</t>
      </section>
      <section title="Interface Between WAN-side anchor="dhcpv6-pd-slaac" numbered="true" toc="default">
        <name>Interface between the WAN Side and LAN-side" anchor="dhcpv6-pd-slaac"> LAN Side</name>
        <t>The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
        Options (PIOs) <xref target="RFC4861"/> target="RFC4861" format="default"/> corresponding
        to prefixes learned via DHCPv6-PD MUST NOT on the WAN side <bcp14>MUST
        NOT</bcp14> span past the remaining preferred and valid lifetimes of
        the corresponding DHCPv6-PD prefixes. This means that the "Preferred
        Lifetime" and the "Valid Lifetime" advertised in PIOs by the CE router MUST
        <bcp14>MUST</bcp14> be dynamically adjusted such that they never span
        past the remaining preferred and valid lifetimes of the corresponding
        prefixes delegated via DHCPv6-PD on the WAN-side.</t> WAN side.</t>
        <t>Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6
        IA Address Options options and DHCPv6 IA Prefix Options options employed with DHCPv6
        on the LAN-side MUST NOT LAN side <bcp14>MUST NOT</bcp14> span past the remaining
        preferred and valid lifetimes of the corresponding prefixes leased learned
        via DHCPv6-PD on the WAN-side. WAN side. This means that the
        "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA Address Options options
        and DHCPv6 IA Prefix Options options employed with DHCPv6 on the LAN-side MUST LAN side
        <bcp14>MUST</bcp14> be dynamically adjusted such that they never span
        past the remaining preferred and valid lifetimes of the corresponding
        prefixes delegated to the CE router on the WAN-side WAN side via DHCPv6-PD.</t>

<!--
XXX This was repeated in the next section, and hence removed from here.

<t>CE Routers providing stateful address configuration via DHCPv6 SHOULD set the DHCPv6 IA Address Option preferred-lifetime to the lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of the remaining valid lifetime and ND_VALID_LIMIT.

	<list style="hanging">
	<t hangText="NOTE:">
			ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in <xref target="parameters"/></t>
	</list>

</t>

<t>
CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 IA Prefix Option preferred-lifetime to the lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of the remaining valid lifetime and ND_VALID_LIMIT.

</t>
-->

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

 <t>RATIONALE:</t>
            <ul spacing="normal">
              <li>The lifetime values employed for the "Preferred Lifetime"
              (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime)
              of SLAAC Prefix Information Options must never be larger than
              the remaining lifetimes for of the corresponding prefix prefixes (as learned
              via DHCPv6-PD on the WAN-side). WAN side). This is in line with the
              requirement from Section 6.3 of <xref target="RFC8415"/>, target="RFC8415" sectionFormat="of"
              section="6.3" format="default"/>, which states that "if states:</li></ul>

	      <blockquote>In particular, if the
              delegated prefix or a prefix derived from it is advertised for
              stateless address autoconfiguration <xref target="RFC4862"/>, target="RFC4862"
              format="default"/>, the advertised preferred and valid lifetimes MUST NOT
              <bcp14>MUST NOT</bcp14> exceed the corresponding remaining
              lifetimes of the delegated prefix."</t>
			<t>The prefix.</blockquote>

	      <ul spacing="normal">
              <li>The lifetime values of prefixes advertised on the LAN-side LAN side
              via SLAAC must be dynamically updated (rather than static values), otherwise
              values); otherwise, the advertised lifetimes would eventually
              span past the DHCPv6-PD lifetimes.</t>
			<t>The lifetimes.</li>

              <li>The same considerations apply for the valid-lifetime "valid-lifetime" and preferred-lifetime
              "preferred-lifetime" of IA Address Options options and IA Prefix Options options
              employed with DHCPv6 on the LAN-side.</t>
		</list>
	</t>
	</list>
</t> LAN side.</li>
              </ul>

      </section>
      <section title="LAN-side anchor="lan-lifetimes" numbered="true" toc="default">
        <name>LAN-Side Option Lifetimes" anchor="lan-lifetimes"> Lifetimes</name>
        <t>
CE Routers SHOULD routers <bcp14>SHOULD</bcp14> override the default lifetime values of Neighbor Discovery options that depend in any way on changes in the prefix employed for address configuration on the LAN-side, LAN side, and employ shorter lifetime values to improve the robustness to renumbering events, while complying with the requirements from <xref target="dhcpv6-pd-slaac"/> target="dhcpv6-pd-slaac" format="default"/> of this document and the recommendations in <xref target="RFC7772"/>. target="RFC7772" format="default"/>.
</t>
        <t>CE Routers SHOULD routers <bcp14>SHOULD</bcp14> set the "Router Lifetime" of
        Router Lifetime Advertisement (RA) messages to ND_PREFERRED_LIMIT.</t>

        <t>CE Routers SHOULD routers <bcp14>SHOULD</bcp14> also set the PIO Preferred Lifetime "Preferred
        Lifetime" to the lesser of the remaining preferred lifetime of the
        corresponding prefix (see <xref target="dhcpv6-pd-slaac"/>) target="dhcpv6-pd-slaac"
        format="default"/>) and ND_PREFERRED_LIMIT, and set the PIO Valid Lifetime "Valid
        Lifetime" to the lesser of the remaining valid lifetime of the
        corresponding prefix and ND_VALID_LIMIT.

 Additionally, the Route Lifetime "Route Lifetime" of Route Information Options (RIOs) <xref
 target="RFC4191"/>, the Lifetime "Lifetime" of Recursive DNS Search Options (RDNSSO) Server (RDNSS) options
 <xref target="RFC8106"/>, and the Lifetime "Lifetime" of DNS Search List Options (DNSSLO) (DNSSL) options
 <xref target="RFC8106"/> SHOULD <bcp14>SHOULD</bcp14> be set to the lesser of the
 longest valid-lifetime in remaining valid lifetime of a DHCPv6 IA Prefix Option (received prefix (leased via DHCPv6 on
 the WAN-side) WAN side) and ND_VALID_LIMIT, if any of these options are included in
 Router Advertisement messages.

<list style="hanging">

</t>

<t hangText="NOTES:"> indent="3">
NOTE: In scenarios where the valid-lifetime valid lifetime and the preferred-lifetime preferred lifetime of the prefix leased
prefixes learned via DHCPv6 on the WAN-side WAN side are always larger than
ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, the lifetime values
advertised on the LAN-side LAN side will not experience actual changes.
</t>
<t>The

<t>
The above text refers to the Neighbor Discovery Options options that are typically
employed by CE Routers. routers. A CE Router router may need to apply the same policy for
setting the lifetime of other Neighbor Discovery options it employs, if and
where applicable.
</t>
</list>
</t>

        <t>CE Routers routers providing stateful address configuration via DHCPv6 SHOULD
        <bcp14>SHOULD</bcp14> set the "preferred-lifetime" of a DHCPv6 IA
        Address Option preferred-lifetime option to the lesser of the remaining preferred lifetime of
        the corresponding prefix (see <xref target="dhcpv6-pd-slaac"/>) target="dhcpv6-pd-slaac"
        format="default"/>) and ND_PREFERRED_LIMIT, and set the valid-lifetime
        "valid-lifetime" of the same option to the lesser of the remaining
        valid lifetime of the corresponding prefix and ND_VALID_LIMIT.
</t>
        <t>
CE Routers routers providing DHCPv6-PD on the LAN-side SHOULD LAN side <bcp14>SHOULD</bcp14> set the
"preferred-lifetime" of a DHCPv6 IA Prefix Option preferred-lifetime option to the lesser of the
remaining preferred lifetime of the corresponding prefix (see <xref target="dhcpv6-pd-slaac"/>)
target="dhcpv6-pd-slaac" format="default"/>) and ND_PREFERRED_LIMIT, and set
the valid-lifetime "valid-lifetime" of the same option to the lesser of the remaining valid
lifetime of the corresponding prefix and ND_VALID_LIMIT.
</t>

<t>
<list style="hanging">
<t hangText="RATIONALE:">
<list style="symbols">
          <t>RATIONALE:</t>
            <ul spacing="normal">
              <li>
                <t>The Valid Lifetime "Valid Lifetime" and Preferred Lifetime "Preferred Lifetime" of PIOs have a
                direct impact on three different aspects:
	<list style="symbols">
		<t>The
                </t>
                <ul spacing="normal">
                  <li>The amount of time hosts may end up employing stale
                  network configuration information (see <xref target="RFC8978"/>).</t>
		<t>The
                  target="RFC8978" format="default"/>).</li>
                  <li>The amount of time CE Routers routers need to persist trying to
                  deprecate stale network configuration information (e.g. (e.g., to
                  handle cases where hosts miss Router Advertisements Advertisement messages
                  and thus still consider the stale information as valid).</t>
		<t>The
                  valid).</li>
                  <li>The amount of information that CE Routers routers need to
                  maintain when e.g. when, e.g., multiple crash-and-reboot events occur
                  in the timespan time span represented by the option lifetimes employed
                  on the LAN-side.</t>
	</list>
</t>

<t> LAN side.</li>
                </ul>
              </li>
              <li>
		CE Routers routers need not employ the (possibly long) WAN-side
		DHCPv6-PD lifetimes for the Valid Lifetime "Valid Lifetime" and Preferred Lifetime "Preferred
		Lifetime" of PIOs sent in Router Advertisements Advertisement messages to
		advertise sub-prefixes of the leased prefix. Instead, CE Routers SHOULD
		routers <bcp14>SHOULD</bcp14> use shorter values for the Valid Lifetime "Valid
		Lifetime" and Preferred Lifetime "Preferred Lifetime" of PIOs, since subsequent
		Router Advertisement messages will nevertheless refresh the
		associated lifetimes, leading to the same effective lifetimes
		as specified by the WAN-side DHCPv6-PD lifetimes.
</t>
<t>
</li>
              <li>
Similarly, CE Routers routers need not employ the (possibly long) WAN-side DHCPv6-PD lifetimes for the valid-lifetime "valid-lifetime" and preferred-lifetime "preferred-lifetime" of IA Address Options options and IA Prefix Option options employed by DHCPv6 on the LAN-side, LAN side, since the renewal of bindings by DHCPv6 clients will lead to the same effective lifetimes as specified by the WAN-side DHCPv6-PD lifetimes.
</t>

</list>
</t>
</list>
</t>
</li>
            </ul>

      </section>
      <section title="Signaling anchor="sig-stale-config" numbered="true" toc="default">
        <name>Signaling Stale Configuration Information" anchor="sig-stale-config"> Information</name>
        <t>When a CE Router router provides LAN-side address-configuration information via SLAAC:

	<list style="symbols">
		<t>A

        </t>
        <ul spacing="normal">
          <li>A CE Router router sending RAs that advertise dynamically-learned prefixes (e.g. belonging to a
          dynamically learned prefix (e.g., via DHCPv6-PD) SHOULD
          <bcp14>SHOULD</bcp14> record, on stable storage, the list of
          prefixes being advertised via PIOs on each network segment, segment and the
          state of the "A" and "L" flags of the corresponding PIOs.</t> PIOs.</li>
          <li>
            <t>Upon changes to the advertised prefixes, and after
            bootstrapping, the CE Router router advertising prefix information via
            SLAAC proceeds as follows:
			<list style="symbols">
				<t>Any
            </t>
            <ul spacing="normal">
              <li>Any prefixes that were previously advertised by the CE Router
              router via PIOs in RA messages, but that have now become stale, MUST
              <bcp14>MUST</bcp14> be advertised with a PIO PIOs that has have the "Valid
              Lifetime" and the "Preferred Lifetime" set to 0, 0 and the "A" and
              "L" bits unchanged.
				</t>
				</li>
              <li>
                <t>The aforementioned advertisement MUST advertisements <bcp14>MUST</bcp14> be
                performed for at least the "Valid Lifetime" previously
                employed for such prefix. prefixes. The CE Router MUST router <bcp14>MUST</bcp14>
                advertise this information with unsolicited Router Advertisements
                Advertisement messages, as described in Section 6.2.4 of <xref target="RFC4861"/>, target="RFC4861"
                sectionFormat="of" section="6.2.4" format="default"/>, and MAY
                <bcp14>MAY</bcp14> advertise this information via unicast
                Router Advertisements Advertisement messages when possible and applicable.

<list><t>Note:

</t>
                <ul spacing="normal" empty="true">
                  <li>NOTE: If requirement L-16 (<xref target="lan-lifetimes"/>) target="CPE"
                  format="default"/>) is followed, the Valid Lifetime "Valid Lifetime" need
                  not be saved saved, and the stale prefix can simply be advertised
                  for a period of ND_VALID_LIMIT.</t>
</list>

</t>
			</list>
		</t>
<t>CE Routers ND_VALID_LIMIT.</li>

                </ul>
              </li>
            </ul>
          </li>
          <li>CE routers receiving DHCPv6 IA Prefix Delegations options with a 0 valid-lifetime MUST
          "valid-lifetime" <bcp14>MUST</bcp14> advertise the corresponding
          sub-prefixes (as they would be generated for the same leased prefix
          with a non-zero lifetime) with a PIO PIOs with both the Preferred Lifetime "Preferred
          Lifetime" and the Valid Lifetime "Valid Lifetime" set to 0, for at least the
          WAN-side DHCPv6-PD valid-lifetime, "valid-lifetime", or for a period of
          ND_VALID_LIMIT if the recommended lifetimes from <xref target="lan-lifetimes"/>
          target="lan-lifetimes" format="default"/> are employed.</t>
	</list>
</t> employed.</li>
        </ul>
        <t>
	  When a CE Router router provides LAN-side DHCPv6 (address assignment or
	  prefix delegation), then:

<list style="symbols">
<t>The

</t>
        <ul spacing="normal">
          <li>The CE Router SHOULD router <bcp14>SHOULD</bcp14> record, on stable storage,
          the DHCPv6 address and delegated-prefix bindings corresponding to
          the LAN-side.</t> LAN side.</li>
          <li>
            <t>If the CE Router router finds that the prefix to be employed for
            address assignment and/or prefix delegation has changed (e.g.,
            upon a crash-and-reboot event) or the CE Router router receives DHCPv6 IA
            Prefix Delegations options with 0 lifetimes, the CE Router MUST:
	<list style="symbols">
		 <t>In router
            <bcp14>MUST</bcp14>:
            </t>
            <ul spacing="normal">
              <li>In Replies to DHCPv6 Request, Renew, and Rebind messages,
              send IA Address Options options or IA Prefix Options options (as appropriate)
              for any address assignments or prefix delegations for the deprecated stale
              prefixes. The aforementioned options MUST <bcp14>MUST</bcp14> be sent
              with both the valid-lifetime "valid-lifetime" and the preferred-lifetime "preferred-lifetime" set
              to 0, for at least the valid-lifetime "valid-lifetime" originally employed for
              them, or for a period of ND_VALID_LIMIT if the recommended
              lifetimes from <xref target="lan-lifetimes"/> target="lan-lifetimes" format="default"/>
              are employed.
		</t>
		<t>Initiate
		</li>
              <li><t>Initiate sending Reconfigure messages (if messages, if possible - i.e., (i.e.,
              client requests Reconfigure support and the CE Router router offers it)
              it), to those clients with address assignments or prefix
              delegations for the deprecated prefixes.
		</t>
	</list>
</t>
</list>
</t>

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

		<t>IPv6 stale prefixes.</t>
		</li>
            </ul>
	  </li>
	</ul>

            <t>RATIONALE:</t>
            <ul spacing="normal">
              <li>IPv6 network renumbering is expected to take place in a
              planned manner, manner with old/stale prefixes being phased-out phased out via
              reduced prefix lifetimes while new prefixes (with normal
              lifetimes) are introduced. However, a number of scenarios may
              lead to the so-called "flash-renumbering" events, where the a prefix
              being employed on a network suddenly becomes invalid and
              replaced by a new prefix <xref target="RFC8978"/>. target="RFC8978"
              format="default"/>. One such scenario is when a DHCPv6 server an Internet
              Service Provider (ISP) employs dynamic prefixes and the Customer Edge Router CE
              router crashes and reboots. The requirements in this section are
              meant to allow Customer Edge Routers CE routers to deprecate stale information in such
              scenarios.
		</t>

		<t>The
		</li>
              <li>The recommendations in this section expand from requirement
              L-13 in Section 4.3 of <xref target="RFC7084"/>, target="RFC7084" sectionFormat="of" section="4.3"
              format="default"/> and Section 6.3 of <xref target="RFC8415"/>.</t>

		<t>Host target="RFC8415"
              sectionFormat="of" section="6.3" format="default"/>.</li>
              <li>Hosts configuring addresses via SLAAC on the local network
              may employ addresses configured for the previously advertised
              prefixes for at most the "Valid Lifetime" of the corresponding PIO
              PIOs of the last received Router Advertisement message. messages. Since
              Router Advertisement messages may be lost or fail to be received
              for various reasons, Customer Edge Routers CE routers need to try to
              deprecate stale prefixes for a period of time equal to the
              "Valid Lifetime" of the PIO employed when originally advertising
              the prefix.</t>

		<t>The requirement prefix.</li>
              <li>The requirements in this section is conveyed as a "SHOULD" (as opposed to a "MUST"), since the requirement to store information on
              stable storage are conveyed as "<bcp14>SHOULD</bcp14>" (as
              opposed to "<bcp14>MUST</bcp14>"), since they may represent a
              challenge for some implementations.</t>
<t>Advertising implementations.</li>
              <li>Advertising DHCPv6-leased prefixes with zero lifetimes on
              the LAN-side LAN side would handle the case where a CE Router router has no
              stable storage but receives the prefixes via DHCPv6 with 0 lifetimes.</t>

   <t>The
              lifetimes.</li>
              <li>The above text does not include DHCPv6 Advertise messages
              sent in response to DHCPv6 Solicit messages, since Section 18.3.9 of <xref target="RFC8415"/>
              target="RFC8415" sectionFormat="of" section="18.3.9"
              format="default"/> requires that a DHCPv6 server that is not
              going to assign an address or delegated prefix received as a
              hint in the Solicit message MUST NOT <bcp14>MUST NOT</bcp14> include that
              address or delegated prefix in the Advertise
              message. Additionally, any subsequent Request messages will
              trigger the response specified in this section, section and therefore
              cause the address or prefix to be
   deprecated.</t>

	</list>
</t>
</list>
</t> deprecated.</li>
            </ul>

      </section>
    </section>
    <section title="Recommended anchor="parameters" numbered="true" toc="default">
      <name>Recommended Option Lifetimes Configuration Values" anchor="parameters">
<t>
<list style="symbols">
<t>ND_PREFERRED_LIMIT: Values</name>
      <ul spacing="normal">
        <li>ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)</t>
<t>ND_VALID_LIMIT: minutes)</li>
        <li>ND_VALID_LIMIT: 5400 seconds (90 minutes)</t>
</list>
</t>

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

        <t>RATIONALE:</t>
        <ul empty="false">
	<li>These values represent a trade-off among a number of factors, including responsiveness and possible impact on the battery life of connected devices <xref target="RFC7772"/>.
		</t>
		<t>ND_PREFERRED_LIMIT target="RFC7772" format="default"/>.
		</li>

        <li>ND_PREFERRED_LIMIT is set according to the recommendations in
        <xref target="RFC7772"/> target="RFC7772" format="default"/> for Router Lifetime, the "Router Lifetime",
        following the rationale from Section 3.2 of <xref target="RFC8978"/>.</t>
		<t>ND_VALID_LIMIT target="RFC8978" sectionFormat="of"
        section="3.2" format="default"/>.</li>

        <li>ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some additional leeway before configuration information is finally discarded by the host.</t>
	</list>
</t> hosts.</li>
      </ul>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
This document has no actions for IANA. 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 arise, e.g., in scenarios where
      dynamic IPv6 prefixes are employed, and it proposes improvements to Customer Edge Routers
      CE routers <xref target="RFC7084"/> target="RFC7084" format="default"/> to
      mitigate the problem for residential or small office scenarios. It does
      not introduce new security issues, and thus issues; thus, the same security
      considerations as for <xref target="RFC4861"/>, target="RFC4861" format="default"/>, <xref target="RFC4862"/>,
      target="RFC4862" format="default"/>, <xref target="RFC7084"/>, target="RFC7084"
      format="default"/>, and <xref target="RFC8415"/> target="RFC8415" format="default"/>
      apply.</t>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-6man-slaac-renum" to="6MAN-SLAAC-RENUM"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml"/>
        <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.7772.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml"/>

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

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8978.xml"/>
      </references>
    </references>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Owen DeLong, Philip Homburg, Erik Kline, and Ted Lemon, <contact fullname="Owen DeLong"/>,
      <contact fullname= "Philip Homburg"/>, <contact fullname="Erik Kline"/>,
      and <contact fullname="Ted Lemon"/> for their valuable help in
      improving this document via successive detailed reviews.
</t>
      <t>The authors would like to thank Mikael Abrahamsson, Luis Balbinot, Tim Chown, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Gert Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk, Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade, Jordi <contact fullname="Mikael
      Abrahamsson"/>, <contact fullname="Luis Balbinot"/>, <contact
      fullname="Brian Carpenter"/>, <contact fullname="Tim Chown"/>, <contact
      fullname="Lorenzo Colitti"/>, <contact fullname="Alejandro D'Egidio"/>,
      <contact fullname="Gert Doering"/>, <contact fullname="Fernando
      Frediani"/>, <contact fullname="Guillermo Gont"/>, <contact
      fullname="Steinar Haug"/>, <contact fullname="Nick Hilliard"/>, <contact
      fullname="Lee Howard"/>, <contact fullname="Christian Huitema"/>,
      <contact fullname="Sheng Jiang"/>, <contact fullname="Benjamin Kaduk"/>,
      <contact fullname="Suresh Krishnan"/>, <contact fullname="Warren
      Kumari"/>, <contact fullname="Albert Manfredi"/>, <contact
      fullname="Olorunloba Olopade"/>, <contact fullname="Jordi Palet Martinez, Richard Patterson, Pete Resnick, Michael Richardson, Mark Smith, Job Snijders, Sander Steffann, Tarko Tikan, Ole Troan, Loganaden Velvindron, Eric Vyncke, Robert Wilton, Timothy Winters, Christopher Wood, and Chongfeng Xie,
      Martinez"/>, <contact fullname="Pete Resnick"/>, <contact
      fullname="Michael Richardson"/>, <contact fullname="Mark Smith"/>,
      <contact fullname="Job Snijders"/>, <contact fullname="Sander
      Steffann"/>, <contact fullname="Tarko Tikan"/>, <contact fullname="Ole
      Troan"/>, <contact fullname="Loganaden Velvindron"/>, <contact
      fullname="Éric Vyncke"/>, <contact fullname="Robert Wilton"/>, <contact
      fullname="Timothy Winters"/>, <contact fullname="Christopher Wood"/>,
      and <contact fullname="Chongfeng Xie"/> for providing valuable comments
      on earlier draft versions of this document.</t>
      <t>Fernando would also like to thank Brian Carpenter <contact fullname="Brian
      Carpenter"/> who, over the years, has answered many questions and
      provided valuable comments that have benefited his protocol-related
      work.</t>
    </section>

  </middle>
  <back>

    <references title="Normative References">
        <?rfc include="reference.RFC.2119" ?>
        <?rfc include="reference.RFC.8174" ?>
	<?rfc include="reference.RFC.4191" ?>
	<?rfc include="reference.RFC.8106" ?>
	<?rfc include="reference.RFC.8415" ?>
	<?rfc include="reference.RFC.4861" ?>
	<?rfc include="reference.RFC.4862" ?>
	<?rfc include="reference.RFC.7772" ?>
	<?rfc include="reference.RFC.7844" ?>
	</references>

    <references title="Informative References">

	<?rfc include="reference.RFC.7084" ?>
	<?rfc include="reference.I-D.ietf-6man-slaac-renum" ?>
	<?rfc include="reference.RFC.8978" ?>

    </references>

  </back>
</rfc>