| RFC 8978 | Reaction to Renumbering Events | March 2021 |
| Gont, et al. | Informational | [Page] |
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.¶
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 https://www.rfc-editor.org/info/rfc8978.¶
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 (https://trustee.ietf.org/license-info) 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.¶
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:¶
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 [RFC4861] 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 [FRITZ]. 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.¶
Section 2 analyzes this problem in more detail. Section 3 describes possible operational mitigations. Section 4 describes possible future work to mitigate the aforementioned problem.¶
As noted in Section 1, 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.¶
In 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 [UK-NOF] 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:¶
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.¶
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.¶
[RFC4861] 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 Section 1), 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.¶
SLAAC hosts are unable to recover from stale network configuration information, since:¶
Whenever 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 Section 2.3, PIOs with small Valid Lifetimes in unauthenticated RAs will not lower the Valid Lifetime to any value shorter than two hours (as per [RFC4862]). Therefore, even if a SLAAC router tried to explicitly signal the network about the stale configuration information via unauthenticated RAs, implementations compliant with [RFC4862] would deprecate the corresponding prefixes but would fail to invalidate them.¶
While 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.¶
The following subsections discuss possible operational workarounds for the aforementioned problems.¶
As noted in Section 2.1, the use of stable prefixes would eliminate the issue in some of the scenarios discussed in Section 1 of this document, such as the typical home network deployment. However, as noted in Section 2.1, there might be reasons for which an administrator may want or may need to employ dynamic prefixes.¶
An 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 [RFC4861] (corresponding to the "lifetime" parameters of PIOs) could be overridden as follows:¶
RATIONALE:¶
Improvements in Customer Edge routers [RFC7084], 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 [RENUM-CPE].¶
Improvements in the SLAAC protocol [RFC4862] and some IPv6-related algorithms, such as "Default Address Selection for Internet Protocol Version 6 (IPv6)" [RFC6724], would help improve network robustness. Such work is currently being pursued in [RENUM-RXN].¶
The aforementioned work is considered out of the scope of this present document, which only focuses on documenting the problem and discussing operational mitigations.¶
This document has no IANA actions.¶
This 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 [RFC4861] and [RFC4862] apply.¶
The authors would like to thank (in alphabetical order) Brian Carpenter, Alissa Cooper, Roman Danyliw, Owen DeLong, Martin Duke, Guillermo Gont, Philip Homburg, Sheng Jiang, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Warren Kumari, Ted Lemon, Juergen Schoenwaelder, Éric Vyncke, Klaas Wierenga, Robert Wilton, and Dale Worley for providing valuable comments on earlier draft versions of this document.¶
The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, Uesley Correa, Owen DeLong, Gert Doering, Martin Duke, Fernando Frediani, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez, Michael Richardson, Mark Smith, Tarko Tikan, and Ole Troan for providing valuable comments on a previous document on which this document is based.¶
Fernando would like to thank Alejandro D'Egidio and Sander Steffann for a discussion of these issues. Fernando would also like to thank Brian Carpenter 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 Jen Linkova in [DEFAULT-ADDR] and also in [RIPE-690]. Section 1 borrows text from [DEFAULT-ADDR], authored by Jen Linkova.¶