<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

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

   <!-- xml2rfc v2v3 conversion 3.5.0 -->
   <front>
     <title abbrev="Reaction to Renumbering Events">Reaction of Stateless
Address Autoconfiguration (SLAAC) to Flash-Renumbering Events</title> 
     <seriesInfo name="RFC" value="8978"/>
     <author fullname="Fernando Gont" initials="F." surname="Gont">
       <organization abbrev="SI6 Networks">SI6 Networks</organization>
       <address>
	 <postal>
	   <street>Segurola y Habana 4310</street>
	   <extaddr>7mo Piso</extaddr>
          <!-- <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@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>
     <date year="2020" month="December" />
     <area>Operations and Management</area>
     <workgroup>IPv6 Operations Working Group (v6ops)</workgroup>

 <keyword>example</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 scenarios where network configuration information
related to IPv6 prefixes becomes invalid without any explicit and reliable
signaling of that condition (such as when a Customer Edge router crashes and
reboots without knowledge of the previously employed prefixes), nodes on the
local network may continue using stale prefixes for an unacceptably long time
(on the order of several days), thus resulting in connectivity problems. This
document describes this issue and discusses operational workarounds that may
help to improve network robustness. Additionally, it highlights areas where
further work may be needed.</t> 
     </abstract>
   </front>
   <middle>
     <section anchor="intro" numbered="true" toc="default">
       <name>Introduction</name>
       <t>IPv6 Stateless Address Autoconfiguration (SLAAC) <xref
target="RFC4862" format="default"/> conveys information about prefixes to be
employed for address configuration via Prefix Information Options (PIOs) sent
in Router Advertisement (RA) messages. IPv6 largely assumes prefix stability,
with network renumbering only taking place in a planned manner, old/stale
prefixes being phased out via reduced prefix lifetimes, and new prefixes (with
longer lifetimes) being introduced at the same time. However, there are several
scenarios that may lead to the so-called "flash-renumbering" events, where the
prefix employed by a network suddenly becomes invalid and replaced by a new
prefix. In some of these scenarios, the local router producing the network
renumbering event may try to deprecate the currently employed prefixes (by
explicitly signaling the network about the renumbering event), whereas in other
scenarios, it may be unable to do so.</t> 
<t>[snip]</t>
<ul>
	   <li>There may be existing advice for ISPs to deliver dynamic IPv6
prefixes <strong>by default</strong> (e.g., see <xref target="GERMAN-DP2"
format="default"/>) over privacy concerns associated with stable prefixes.</li> 
	 </ul>
	 <t>For a number of reasons (such as the ones stated above), IPv6 deployments may employ dynamic prefixes (even at the expense of the issues discussed in this document), and there might be scenarios in which the dynamics of a network are such that the network exhibits the behavior of dynamic prefixes. Rather than trying to regulate how operators may run their networks, this document aims at improving network robustness in the deployed Internet.</t>
       </section>
   </middle>
<back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
	</references>
      <references>
        <name>Informative References</name>

        <reference anchor="GERMAN-DP2" target="http://www.bfdi.bund.de/SharedDocs/Publikationen/Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv6.pdf?__blob=publicationFile">
          <front>
            <title ascii="Introduction of IPv6: notes for providers in the private sector and manufacturers">Einführung von IPv6 Hinweise für Provider im Privatkundengeschäft und Hersteller</title>
            <author>
              <organization>BFDI</organization>
            </author>
            <date month="November" year="2012"/>
          </front>
          <refcontent>Entschliessung der 84. Konferenz der Datenschutzbeauftragten des Bundes und der Lander</refcontent>
        </reference>

        </references>
        </references>

  </back>
</rfc>
