Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering EventsSI6 NetworksSegurola y Habana 4310, 7mo PisoVilla DevotoCiudad Autónoma de Buenos AiresArgentinafgont@si6networks.comhttps://www.si6networks.com6connect, Inc.jan@6connect.comSky UKrichard.patterson@sky.uk
Operations and Management
v6opsIPv6problemaddressprefix delegationDHCPv6stale prefixesold prefixesIn 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
. Introduction
. Analysis of the Problem
. Use of Dynamic Prefixes
. Default PIO Lifetime Values in IPv6 Stateless Address Autoconfiguration (SLAAC)
. Recovering from Stale Network Configuration Information
. Lack of Explicit Signaling about Stale Information
. Interaction between DHCPv6-PD and SLAAC
. Operational Mitigations
. Stable Prefixes
. SLAAC Parameter Tweaking
. Future Work
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionIPv6 Stateless Address Autoconfiguration (SLAAC) 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) to request a
prefix from an Internet Service Provider (ISP), and a sub-prefix of the leased
prefix is advertised on the LAN side of the CE router via Stateless Address
Autoconfiguration (SLAAC) . In
scenarios where the CE router crashes and reboots, the CE router may obtain (via
DHCPv6-PD) a different prefix from the one previously leased and therefore
advertise (via SLAAC) a new sub-prefix on the LAN side. Hosts will typically
configure addresses for the new sub-prefix but will also normally retain and may
actively employ the addresses configured for the previously advertised sub-prefix,
since their associated Preferred Lifetime and Valid Lifetime allow them to do
so.
A router (e.g., Customer Edge router) advertises autoconfiguration
prefixes (corresponding to prefixes learned via DHCPv6-PD) with constant PIO
lifetimes that are not synchronized with the DHCPv6-PD lease time (even though
requires such
synchronization). While this behavior violates the aforementioned requirement
from , it is not an unusual behavior.
For example, this is particularly true for implementations in which DHCPv6-PD is implemented in a different software module
than SLAAC.
A switch-port that a host is connected to is moved to another subnet (VLAN) as a result of manual switch-port reconfiguration or 802.1x reauthentication. There has been evidence that
some 802.1x supplicants do not reset network settings after
successful 802.1x authentication. If a host fails 802.1x authentication for some reason, it may be placed in a "quarantine" VLAN; if successfully authenticated later on, the host may end up having IPv6 addresses from both the old ("quarantine") and new VLANs.
During a planned network renumbering event, a router is configured to
send an RA including a Prefix Information
Option (PIO) for the "old" prefix with the Preferred Lifetime set to zero and the Valid Lifetime set to a small value, as well as a PIO for the new prefix with default lifetimes.
However, due to unsolicited RAs being sent to a multicast destination address,
and multicast being rather unreliable on busy Wi-Fi networks, the RA might not
be received by local hosts.
An automated device config management system performs periodic config
pushes to network devices. In these scenarios, network devices may simply immediately
forget their previous configuration, rather than withdraw it gracefully. If such a push results in
changing the prefix configured on a particular subnet, hosts
attached to that subnet might not get notified about the prefix
change, and their addresses from the "old" prefix might not be
deprecated (and eventually invalidated) in a timely manner. A related scenario is an incorrect network renumbering event, where a network administrator renumbers a network by simply
removing the "old" prefix from the configuration and configuring a
new prefix instead.
Lacking any explicit and reliable signaling to deprecate (and eventually invalidate) the stale prefixes, hosts may continue to employ the previously configured addresses, which will typically result in packets being filtered or blackholed either on the CE router or within the ISP network. The default values for the Preferred Lifetime and Valid Lifetime of
PIOs specified in mean that, in the
aforementioned scenarios, the stale addresses would be retained and could be
actively employed for new communication instances for an unacceptably long
period of time (one month and one week, respectively). This could lead to
interoperability problems, instead of hosts transitioning to the
newly advertised prefix(es) in a more timely manner.Some devices have implemented ad hoc mechanisms to address this
problem, such as sending RAs to deprecate (and eventually invalidate) apparently stale prefixes when the
device receives any packets employing a source address from a prefix not
currently advertised for address configuration on the local network . However, this may introduce other
interoperability problems, particularly in multihomed/multi-prefix
scenarios. This is a clear indication that advice in this area is
warranted.Unresponsiveness to these flash-renumbering events is caused by the
inability of the network to deprecate (and eventually invalidate) stale information as well as by the
inability of hosts to react to network configuration changes in a more timely
manner. Clearly, it would be desirable that these flash-renumbering events
do not occur and that, when they do occur, hosts are explicitly and
reliably notified of their occurrence. However, for robustness reasons, it is
paramount for hosts to be able to recover from stale configuration information
even when these flash-renumbering events occur and the network is unable to
explicitly and reliably notify hosts about such conditions. analyzes this problem in
more detail. describes possible
operational mitigations. describes
possible future work to mitigate the aforementioned problem.Analysis of the ProblemAs noted in , the problem discussed in this document is exacerbated by the default values of some protocol parameters and other factors. The following sections analyze each of them in detail.Use of Dynamic PrefixesIn network scenarios where dynamic prefixes are employed, renumbering events lead to updated network configuration information being propagated through the network, such that the renumbering events are gracefully handled. However, if the renumbering event happens along with, e.g., loss of configuration state by some of the devices involved in the renumbering procedure (e.g., a router crashes, reboots, and gets leased a new prefix), this may result in a flash-renumbering event, where new prefixes are introduced without properly phasing out the old ones.In simple residential or small office scenarios, the problem discussed in this document would be avoided if DHCPv6-PD leased "stable" prefixes. However, a recent survey indicates that 37% of the responding ISPs employ dynamic IPv6 prefixes. That is, dynamic IPv6 prefixes are an operational reality.Deployment reality aside, there are a number of possible issues associated with stable prefixes:
Provisioning systems may be unable to deliver stable IPv6 prefixes.
While an ISP might lease stable prefixes to the home or small
office, the Customer Edge router might in turn lease sub-prefixes of these
prefixes to other internal network devices. Unless the associated lease
databases are stored on non-volatile memory, these internal devices might get
leased dynamic sub-prefixes of the stable prefix leased by the ISP. In other
words, every time a prefix is leased, there is the potential for the resulting
prefixes to become dynamic, even if the device leasing sub-prefixes has been
leased a stable prefix by its upstream router.
While there is a range of information that may be employed to
correlate network activity , the use
of stable prefixes clearly simplifies network activity correlation and may reduce
the effectiveness of "temporary addresses" .
There might be existing advice for ISPs to deliver dynamic IPv6
prefixes by default (e.g., see ) over privacy concerns associated with stable prefixes.
There might be scalability and performance drawbacks of either a disaggregated distributed routing topology or a centralized topology, which are often required to provide stable prefixes, i.e., distributing more-specific routes or summarizing routes at centralized locations.
For a number of reasons (such as the ones stated above), IPv6 deployments might 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.Default PIO Lifetime Values in IPv6 Stateless Address Autoconfiguration (SLAAC)The impact of the issue discussed in this document is a function of the lifetime values employed for PIOs, since these values determine for how long the corresponding addresses will be preferred and considered valid. Thus, when the problem discussed in this document is experienced, the longer the PIO lifetimes, the higher the impact. specifies the following default PIO lifetime values:
Under problematic circumstances, such as when the corresponding network information has become stale without any explicit and reliable signal from the network (as described in ), it could take hosts up to 7 days
(one week) to deprecate the corresponding addresses and up to 30 days (one
month) to eventually invalidate and remove any addresses configured
for the stale prefix. This means that it will typically take hosts
an unacceptably long period of time (on the order of several days) to
recover from these scenarios. Recovering from Stale Network Configuration InformationSLAAC hosts are unable to recover from stale network configuration information, since:
In scenarios where SLAAC routers explicitly signal the
renumbering event, hosts will typically deprecate, but not
invalidate, the stale addresses, since item "e)" of specifies that an unauthenticated RA may never reduce
the valid lifetime of an address to less than two hours.
Communication with the new "users" of the stale prefix
will not be possible, since the stale prefix will still be
considered "on-link" by the local hosts.
In the absence of explicit signaling from SLAAC routers, SLAAC
hosts will typically fail to recover from stale configuration
information in a timely manner, since hosts would need to rely
on the last Preferred Lifetime and Valid Lifetime advertised
for the stale prefix, for the corresponding addresses to become
deprecated and subsequently invalidated. Please see of
this document for a discussion of the default PIO lifetime values.
Lack of Explicit Signaling about Stale InformationWhenever prefix information has changed, a SLAAC router should advertise not only the new information but also the
stale information with appropriate lifetime values (both the Preferred
Lifetime and the Valid Lifetime set to 0). This would provide explicit
signaling to SLAAC hosts to remove the stale information (including
configured addresses and routes). However, in certain scenarios, such as when a CE router crashes and reboots, the CE
router may have no knowledge about the previously advertised prefixes and thus
might be unable to advertise them with appropriate lifetimes (in order to
deprecate and eventually invalidate them). In any case, we note that, as discussed in , PIOs with small Valid Lifetimes in unauthenticated RAs will
not lower the Valid Lifetime to any value shorter than two hours (as per ). Therefore, even if a SLAAC router tried
to explicitly signal the network about the stale configuration information via
unauthenticated RAs, implementations compliant with would deprecate the corresponding prefixes but would fail
to invalidate them. Interaction between DHCPv6-PD and SLAACWhile DHCPv6-PD is normally employed along with SLAAC, the interaction between the two protocols is largely unspecified. Not unusually, the two protocols are implemented in two different software components, with the interface between the two implemented by means of some sort of script that feeds the SLAAC implementation with values learned from DHCPv6-PD.At times, the prefix lease time is fed as a constant value to the
SLAAC router implementation, meaning that, eventually, the prefix lifetimes
advertised on the LAN side will span past the DHCPv6-PD lease
time. This is clearly incorrect, since the SLAAC router implementation would be
allowing the use of such prefixes for a period of time that is longer than the one they have been leased for via DHCPv6-PD. Operational MitigationsThe following subsections discuss possible operational workarounds
for the aforementioned problems.
Stable PrefixesAs noted in , the use of
stable prefixes would eliminate the issue in some of the
scenarios discussed in of this
document, such as the typical home network deployment. However, as noted in , there might be reasons for which an administrator may want or may
need to employ dynamic prefixes.SLAAC Parameter TweakingAn operator may wish to override some SLAAC parameters such that,
under normal circumstances, the associated timers will be refreshed/reset, but in the
presence of network faults (such as the one discussed in this document), the
associated timers go off and trigger some fault recovering action (e.g., deprecate and
eventually invalidate stale addresses).The following router configuration variables from (corresponding to the "lifetime" parameters
of PIOs) could be overridden as follows:
AdvPreferredLifetime: 2700 seconds (45 minutes)
AdvValidLifetime: 5400 seconds (90 minutes)
RATIONALE:
In the context of ,
where it is clear that use of addresses configured for a given prefix is tied
to using the next-hop router that advertised the prefix, it does not make sense
for the Preferred Lifetime of a PIO to be larger than the Router Lifetime
(AdvDefaultLifetime) of the corresponding Router Advertisement messages. The
Valid Lifetime is set to a larger value to cope with transient network
problems.
Lacking RAs that refresh information, addresses configured for advertised
prefixes become deprecated in a more timely manner; therefore, Rule 3 of causes other configured addresses (if
available) to be used instead.
Reducing the Valid Lifetime of PIOs helps reduce the amount of time a host may maintain stale information
and the amount of time an advertising router would need to advertise stale
prefixes to invalidate them. Reducing the Preferred Lifetime of PIOs helps reduce the amount of time it takes for a host to prefer other working
prefixes (see ). However, we note that while the values suggested in this section are an
improvement over the default values specified in , they represent a trade-off among a number of factors,
including responsiveness, possible impact on the battery life of connected
devices , etc. Thus, they may or may
not provide sufficient mitigation to the problem discussed in this
document.
Future WorkImprovements in Customer Edge routers , such that they can signal hosts about stale prefixes
to deprecate (and eventually invalidate) them accordingly, can help mitigate the problem discussed in this
document for the "home network" scenario. Such work is currently being pursued
in .Improvements in the SLAAC protocol and some IPv6-related algorithms, such as "Default Address Selection for
Internet Protocol Version 6 (IPv6)" , would help improve network
robustness. Such work is currently being pursued in .The aforementioned work is considered out of the scope of this
present document, which only focuses on documenting the problem and discussing
operational mitigations.IANA ConsiderationsThis document has no IANA actions.Security ConsiderationsThis document discusses a problem that may arise in scenarios where
flash-renumbering events occur and proposes workarounds to mitigate the
aforementioned problem. This document does not introduce any new security
issues; therefore, the same security considerations as for and apply.ReferencesNormative ReferencesNeighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]IPv6 Stateless Address AutoconfigurationThis document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]Default Address Selection for Internet Protocol Version 6 (IPv6)This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]First-Hop Router Selection by Hosts in a Multi-Prefix NetworkThis document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.Dynamic Host Configuration Protocol for IPv6 (DHCPv6)This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.Informative ReferencesDefault Address Selection and Subnet Renumbering This document discusses some scenarios when IPv6 hosts might not be
able to properly detect the fact the network they are connected to
has changed IPv6 addressing. It proposes changes to the Default
Address Selection algorithm defined in [RFC6724] to mitigate the
impact of the abovementioned failure scenarios as well as provides
recommendations for sending Prefix Information Options (PIO). It
updated [RFC6724].
Work in ProgressQuiz: Weird IPv6 Traffic on the Local Network (updated with solution)SI6 NetworksSegurola y Habana 4310, 7mo PisoVilla DevotoCiudad Autonoma de Buenos AiresArgentina+54 11 4650 8472fgont@si6networks.comhttps://www.si6networks.comSI6 Networks"Einführung von IPv6: Hinweise für Provider im Privatkundengeschäft und Hersteller" [Introduction of IPv6: Notes for providers in the consumer market and manufacturers]BFDIEntschliessung der 84. Konferenz der Datenschutzbeauftragten des Bundes und der Lander [Resolution of the 84th Conference of the Federal and State Commissioners for Data Protection]Subject: [net-next] ipv6: Honor all IPv6 PIO Valid Lifetime valuesmessage to the netdev mailing listImproving the Reaction of Customer Edge Routers to IPv6 Renumbering EventsSI6 Networks6connectSky UKCisco This document specifies improvements to Customer Edge Routers that
help mitigate the problems that may arise when network configuration
information becomes invalid, without any explicit signaling of that
condition to the local nodes. This document updates RFC7084.
Work in ProgressImproving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering EventsSI6 Networks6connectSky UK 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.
Work in ProgressBasic Requirements for IPv6 Customer Edge RoutersThis document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The document obsoletes RFC 6204.Security and Privacy Considerations for IPv6 Address Generation MechanismsThis document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.Reducing Energy Consumption of Router AdvertisementsFrequent Router Advertisement messages can severely impact host power consumption. This document recommends operational practices to avoid such impact.Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to chooseIPv6 Deployment Survey and BCOPAcknowledgmentsThe authors would like to thank (in alphabetical order) , ,
, ,
, ,
, ,
, ,
, , , , , , , and
for providing valuable comments on
earlier draft versions of this document.The authors would like to thank (in alphabetical order) , ,
, , , , , , , , , , , , , , ,
, ,
, and
for providing valuable comments on a previous document on which this
document is based.Fernando would like to thank and for a discussion of these issues. Fernando would
also like to thank who, over the
years, has answered many questions and provided valuable comments that
have benefited his protocol-related work.The problem discussed in this document has been previously documented
by in and also in .
borrows text
from , authored by .Authors' AddressesSI6 NetworksSegurola y Habana 4310, 7mo PisoVilla DevotoCiudad Autónoma de Buenos AiresArgentinafgont@si6networks.comhttps://www.si6networks.com6connect, Inc.jan@6connect.comSky UKrichard.patterson@sky.uk