2.1.Use of Dynamic Prefixes

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:¶

• Provisioning systems may be unable to deliver stable IPv6 prefixes.¶
• While an ISP might lease stable prefixes to the home or smalloffice, the Customer Edge router might in turn lease sub-prefixes of theseprefixes to other internal network devices. Unless the associated leasedatabases are stored on non-volatile memory, these internal devices might getleased dynamic sub-prefixes of the stable prefix leased by the ISP. In otherwords, every time a prefix is leased, there is the potential for the resultingprefixes to become dynamic, even if the device leasing sub-prefixes has beenleased a stable prefix by its upstream router.¶
• While there is a range of information that may be employed tocorrelate network activity[RFC7721], the useof stable prefixes clearly simplifies network activity correlation and may reduce the effectiveness of "temporary addresses"[RFC8981].¶
• There might be existing advice for ISPs to deliver dynamic IPv6prefixesby default (e.g., see[GERMAN-DP]) 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.¶

2.2.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.¶

[RFC4861] specifies the following default PIO lifetime values:¶

• Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)¶
• Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)¶

Under problematic circumstances, such as when the corresponding network information has become stale without any explicit and reliable signal from the network (as described inSection 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.¶

2.3.Recovering from Stale Network Configuration Information

SLAAC 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)" ofSection 5.5.3 of [RFC4862] 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 seeSection 2.2 of this document for a discussion of the default PIO lifetime values.¶

2.4.Lack of Explicit Signaling about Stale Information

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 CErouter may have no knowledge about the previously advertised prefixes and thusmight be unable to advertise them with appropriate lifetimes (in order todeprecate and eventually invalidate them).¶

In any case, we note that, as discussed inSection 2.3, PIOs with small Valid Lifetimes in unauthenticated RAs willnot lower the Valid Lifetime to any value shorter than two hours (as per[RFC4862]). Therefore, even if a SLAAC router triedto explicitly signal the network about the stale configuration information viaunauthenticated RAs, implementations compliant with[RFC4862] would deprecate the corresponding prefixes but would failto invalidate them.¶

NOTE:¶

Some implementations have been updated to honor small PIO lifetimesvalues, as proposed in[RENUM-RXN]. For example, please see[Linux-update].¶

2.5.Interaction between DHCPv6-PD and SLAAC

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 theSLAAC router implementation, meaning that, eventually, the prefix lifetimesadvertised on the LAN side will spanpast the DHCPv6-PD leasetime. This is clearly incorrect, since the SLAAC router implementation would beallowing the use of such prefixes for a period of time that is longer than the one they have been leased for via DHCPv6-PD.¶

3.2.SLAAC Parameter Tweaking

An operator may wish to override some SLAAC parameters such that,under normal circumstances, the associated timers will be refreshed/reset, but in thepresence of network faults (such as the one discussed in this document), theassociated timers go off and trigger some fault recovering action (e.g., deprecate andeventually invalidate stale addresses).¶

The following router configuration variables from[RFC4861] (corresponding to the "lifetime" parametersof PIOs) could be overridden as follows:¶

• AdvPreferredLifetime: 2700 seconds (45 minutes)¶
• AdvValidLifetime: 5400 seconds (90 minutes)¶

NOTES:¶

The aforementioned values for AdvPreferredLifetime and AdvValidLifetime areexpected to be appropriate for most networks. In some networks, particularlythose where the operator has complete control of prefix allocation and where hosts onthe network may spend long periods of time sleeping (e.g., sensors with limitedbattery), longer values may be appropriate.¶

A CE router advertising a sub-prefix of a prefix leased via DHCPv6-PD willperiodically refresh the Preferred Lifetime and the Valid Lifetime of anadvertised prefix to AdvPreferredLifetime and AdvValidLifetime, respectively,as long as the resulting lifetimes of the corresponding prefixes do not extendpast the DHCPv6-PD lease time[RENUM-CPE].¶

RATIONALE:¶

• In the context of[RFC8028],where it is clear that use of addresses configured for a given prefix is tiedto using the next-hop router that advertised the prefix, it does not make sensefor the Preferred Lifetime of a PIO to be larger than the Router Lifetime(AdvDefaultLifetime) of the corresponding Router Advertisement messages. TheValid Lifetime is set to a larger value to cope with transient networkproblems.¶
• Lacking RAs that refresh information, addresses configured for advertisedprefixes become deprecated in a more timely manner; therefore, Rule 3 of[RFC6724] causes other configured addresses (ifavailable) 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 (seeSection 12 of [RFC4861]). However, we note that while the values suggested in this section are an improvement over the default values specified in[RFC4861], they represent a trade-off among a number of factors, including responsiveness, possible impact on the battery life of connected devices[RFC7772], etc. Thus, they may or may not provide sufficient mitigation to the problem discussed in this document.¶