Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events
RFC 8978

Document Type RFC - Informational (March 2021; No errata)
Authors Fernando Gont  , Jan Zorz  , Richard Patterson 
Last updated 2021-03-10
Replaces draft-gont-v6ops-slaac-renum
Stream Internet Engineering Task Force (IETF)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Owen DeLong
Shepherd write-up Show (last changed 2020-07-07)
IESG IESG state RFC 8978 (Informational)
Action Holders
Consensus Boilerplate Yes
Telechat date
Responsible AD Warren Kumari
Send notices to Owen DeLong <>,
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 8978                                  SI6 Networks
Category: Informational                                          J. Žorž
ISSN: 2070-1721                                                 6connect
                                                            R. Patterson
                                                                  Sky UK
                                                              March 2021

 Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-
                           Renumbering Events


   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), hosts
   on the local network may continue using stale prefixes for an
   unacceptably long time (on the order of several days), thus resulting
   in connectivity problems.  This document describes this issue and
   discusses operational workarounds that may help to improve network
   robustness.  Additionally, it highlights areas where further work may
   be needed.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Analysis of the Problem
     2.1.  Use of Dynamic Prefixes
     2.2.  Default PIO Lifetime Values in IPv6 Stateless Address
           Autoconfiguration (SLAAC)
     2.3.  Recovering from Stale Network Configuration Information
     2.4.  Lack of Explicit Signaling about Stale Information
     2.5.  Interaction between DHCPv6-PD and SLAAC
   3.  Operational Mitigations
     3.1.  Stable Prefixes
     3.2.  SLAAC Parameter Tweaking
   4.  Future Work
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Authors' Addresses

1.  Introduction

   IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] conveys
   information about prefixes to be employed for address configuration
   via Prefix Information Options (PIOs) sent in Router Advertisement
   (RA) messages.  IPv6 largely assumes prefix stability, with network
   renumbering only taking place in a planned manner: old prefixes are
   deprecated (and eventually invalidated) via reduced prefix lifetimes
   and new prefixes are introduced (with longer lifetimes) at the same
   time.  However, there are several scenarios that may lead to the so-
   called "flash-renumbering" events, where a prefix employed by a
   network suddenly becomes invalid and replaced by a new prefix.  In
   some of these scenarios, the local router producing the network
   renumbering event may try to deprecate (and eventually invalidate)
   the currently employed prefix (by explicitly signaling the network
   about the renumbering event), whereas in other scenarios, it may be
   unable to do so.

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

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

   *  The most common IPv6 deployment scenario for residential or small
      office networks, where a Customer Edge (CE) router employs DHCPv6
      Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from
Show full document text