draft-ietf-v6ops-slaac-renum-05.txt   rfc8978.txt 
IPv6 Operations Working Group (v6ops) F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft SI6 Networks Request for Comments: 8978 SI6 Networks
Intended status: Informational J. Zorz Category: Informational J. Žorž
Expires: May 6, 2021 6connect ISSN: 2070-1721 6connect
R. Patterson R. Patterson
Sky UK Sky UK
November 2, 2020 March 2021
Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events Renumbering Events
draft-ietf-v6ops-slaac-renum-05
Abstract Abstract
In scenarios where network configuration information related to IPv6 In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit and reliable signaling prefixes becomes invalid without any explicit and reliable signaling
of that condition (such as when a Customer Edge router crashes and of that condition (such as when a Customer Edge router crashes and
reboots without knowledge of the previously-employed prefixes), nodes reboots without knowledge of the previously employed prefixes), hosts
on the local network may continue using stale prefixes for an on the local network may continue using stale prefixes for an
unacceptably long time (on the order of several days), thus resulting unacceptably long time (on the order of several days), thus resulting
in connectivity problems. This document describes this issue and in connectivity problems. This document describes this issue and
discusses operational workarounds that may help to improve network discusses operational workarounds that may help to improve network
robustness. Additionally, it highlights areas where further work may robustness. Additionally, it highlights areas where further work may
be needed. be needed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on May 6, 2021. 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 Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 5 2. Analysis of the Problem
2.1. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . 5 2.1. Use of Dynamic Prefixes
2.2. Default Timer Values in IPv6 Stateless Address 2.2. Default PIO Lifetime Values in IPv6 Stateless Address
Autoconfiguration (SLAAC) . . . . . . . . . . . . . . . . 6 Autoconfiguration (SLAAC)
2.3. Recovering from Stale Network Configuration Information . 7 2.3. Recovering from Stale Network Configuration Information
2.4. Lack of Explicit Signaling about Stale Information . . . 7 2.4. Lack of Explicit Signaling about Stale Information
2.5. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 8 2.5. Interaction between DHCPv6-PD and SLAAC
3. Operational Mitigations . . . . . . . . . . . . . . . . . . . 8 3. Operational Mitigations
3.1. Stable Prefixes . . . . . . . . . . . . . . . . . . . . . 8 3.1. Stable Prefixes
3.2. SLAAC Parameter Tweaking . . . . . . . . . . . . . . . . 8 3.2. SLAAC Parameter Tweaking
4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Future Work
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses
1. Introduction 1. Introduction
IPv6 Stateless address autoconfiguration (SLAAC) [RFC4862] conveys IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862] conveys
information about prefixes to be employed for address configuration information about prefixes to be employed for address configuration
via Prefix Information Options (PIOs) sent in Router Advertisement via Prefix Information Options (PIOs) sent in Router Advertisement
(RA) messages. IPv6 largely assumes prefix stability, with network (RA) messages. IPv6 largely assumes prefix stability, with network
renumbering only taking place in a planned manner, with old/stale renumbering only taking place in a planned manner: old prefixes are
prefixes being phased-out via reduced prefix lifetimes, and new deprecated (and eventually invalidated) via reduced prefix lifetimes
prefixes (with longer lifetimes) being introduced at the same time. and new prefixes are introduced (with longer lifetimes) at the same
However, there are several scenarios that may lead to the so-called time. However, there are several scenarios that may lead to the so-
"flash-renumbering" events, where the prefix employed by a network called "flash-renumbering" events, where a prefix employed by a
suddenly becomes invalid and replaced by a new prefix. In some of network suddenly becomes invalid and replaced by a new prefix. In
these scenarios, the local router producing the network renumbering some of these scenarios, the local router producing the network
event may try to deprecate the currently-employed prefixes (by renumbering event may try to deprecate (and eventually invalidate)
explicitly signaling the network about the renumbering event), the currently employed prefix (by explicitly signaling the network
whereas in other scenarios it may be unable to do so. about the renumbering event), whereas in other scenarios, it may be
unable to do so.
In scenarios where network configuration information related to IPv6 In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit and reliable signaling prefixes becomes invalid without any explicit and reliable signaling
of that condition, nodes on the local network may continue using of that condition, hosts on the local network may continue using
stale prefixes for an unacceptably long period of time, thus stale prefixes for an unacceptably long period of time, thus
resulting in connectivity problems. resulting in connectivity problems.
Scenarios where this problem may arise include, but are not limited Scenarios where this problem may arise include, but are not limited
to, the following: to, the following:
o The most common IPv6 deployment scenario for residential or small * The most common IPv6 deployment scenario for residential or small
office networks, where a Customer Edge (CE) router employs DHCPv6 office networks, where a Customer Edge (CE) router employs DHCPv6
Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from
an Internet Service Provider (ISP), and a sub-prefix of the leased an Internet Service Provider (ISP), and a sub-prefix of the leased
prefix is advertised on the LAN-side of the CE router via prefix is advertised on the LAN side of the CE router via
Stateless Address Autoconfiguration (SLAAC) [RFC4862]. In Stateless Address Autoconfiguration (SLAAC) [RFC4862]. In
scenarios where the CE router crashes and reboots, the CE may scenarios where the CE router crashes and reboots, the CE router
obtain (via DHCPv6-PD) a different prefix from the one previously may obtain (via DHCPv6-PD) a different prefix from the one
leased, and therefore advertise (via SLAAC) the new prefix on the previously leased and therefore advertise (via SLAAC) a new sub-
LAN side. Hosts will typically configure addresses for the new prefix on the LAN side. Hosts will typically configure addresses
prefix, but will normally retain and may actively employ the for the new sub-prefix but will also normally retain and may
addresses configured for the previously-advertised prefix, since actively employ the addresses configured for the previously
their associated Preferred Lifetime and Valid Lifetime allow them advertised sub-prefix, since their associated Preferred Lifetime
to do so. and Valid Lifetime allow them to do so.
o A router (e.g. Customer Edge router) advertises autoconfiguration * A router (e.g., Customer Edge router) advertises autoconfiguration
prefixes corresponding to prefixes learned via DHCPv6-PD with prefixes (corresponding to prefixes learned via DHCPv6-PD) with
constant PIO lifetimes that are not synchronized with the constant PIO lifetimes that are not synchronized with the
DHCPv6-PD lease time (even though Section 6.3 of [RFC8415] DHCPv6-PD lease time (even though Section 6.3 of [RFC8415]
requires such synchronization). While this behavior violates the requires such synchronization). While this behavior violates the
aforementioned requirement from [RFC8415], it is not an unusual aforementioned requirement from [RFC8415], it is not an unusual
behavior, particularly when e.g. DHCPv6-PD is implemented in a behavior. For example, this is particularly true for
different software module than the SLAAC router component. implementations in which DHCPv6-PD is implemented in a different
software module than SLAAC.
o A switch-port the host is connected to is moved to another subnet * A switch-port that a host is connected to is moved to another
(VLAN) as a result of manual switch-port reconfiguration or 802.1x subnet (VLAN) as a result of manual switch-port reconfiguration or
re-authentication. There has been evidence that some 802.1x 802.1x reauthentication. There has been evidence that some 802.1x
supplicants do not reset network settings after successful 802.1x supplicants do not reset network settings after successful 802.1x
authentication. So if a host fails 802.1x authentication for some authentication. If a host fails 802.1x authentication for some
reason, is placed in a "quarantine" VLAN and is successfully reason, it may be placed in a "quarantine" VLAN; if successfully
authenticated later on, it might end up having IPv6 addresses from authenticated later on, the host may end up having IPv6 addresses
both the old ("quarantine") and the new VLANs. from both the old ("quarantine") and new VLANs.
o During the planned network renumbering, a router is configured to * During a planned network renumbering event, a router is configured
send an RA with the Preferred Lifetime for the "old" Prefix to send an RA including a Prefix Information Option (PIO) for the
Information Option (PIO) set to zero and the new PIO with a non- "old" prefix with the Preferred Lifetime set to zero and the Valid
zero Preferred Lifetime. However, due to unsolicited RAs being 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 sent to a multicast destination address, and multicast being
rather unreliable on busy wifi networks, the RA might not be rather unreliable on busy Wi-Fi networks, the RA might not be
received by local hosts. received by local hosts.
o Automated device config management system performs periodic config * An automated device config management system performs periodic
pushes to network devices. In these scenarios, network devices config pushes to network devices. In these scenarios, network
may simply immediately forget their previous configuration, rather devices may simply immediately forget their previous
than withdrawing it gracefully. If such a push results in configuration, rather than withdraw it gracefully. If such a push
changing the subnet configured on a particular network, hosts results in changing the prefix configured on a particular subnet,
attached to that network would not get notified about the subnet hosts attached to that subnet might not get notified about the
change, and their addresses from the "old" prefix will not be prefix change, and their addresses from the "old" prefix might not
deprecated. A related scenario is the incorrect network be deprecated (and eventually invalidated) in a timely manner. A
renumbering where a network administrator renumbers a network by related scenario is an incorrect network renumbering event, where
simply removing the "old" prefix from the configuration and a network administrator renumbers a network by simply removing the
configuring a new prefix instead. "old" prefix from the configuration and configuring a new prefix
instead.
Lacking any explicit and reliable signaling to deprecate the Lacking any explicit and reliable signaling to deprecate (and
previously-advertised prefixes, hosts may continue to employ the eventually invalidate) the stale prefixes, hosts may continue to
previously-configured addresses, which will typically result in employ the previously configured addresses, which will typically
packets being blackholed (whether because of egress-filtering by the result in packets being filtered or blackholed either on the CE
CE router or ISP) or the return traffic being discarded or routed router or within the ISP network.
elsewhere.
The default values for the "Preferred Lifetime" and "Valid Lifetime" The default values for the Preferred Lifetime and Valid Lifetime of
of PIOs specified in [RFC4861] mean that, in the aforementioned PIOs specified in [RFC4861] mean that, in the aforementioned
scenarios, the stale addresses would be retained, and could be scenarios, the stale addresses would be retained and could be
actively employed for new communications instances, for an actively employed for new communication instances for an unacceptably
unacceptably long period of time (one month, and one week, long period of time (one month and one week, respectively). This
respectively). This could lead to interoperability problems, instead could lead to interoperability problems, instead of hosts
of hosts transitioning to the newly-advertised prefix(es) in a more transitioning to the newly advertised prefix(es) in a more timely
timely manner. manner.
Some devices have implemented ad-hoc mechanisms to address this Some devices have implemented ad hoc mechanisms to address this
problem, such as sending RAs to deprecate apparently-stale prefixes problem, such as sending RAs to deprecate (and eventually invalidate)
when the device receives any packets employing a source address from apparently stale prefixes when the device receives any packets
a prefix not currently advertised for address configuration on the employing a source address from a prefix not currently advertised for
local network [FRITZ]. However, this may introduce other address configuration on the local network [FRITZ]. However, this
interoperability problems, particularly in multihomed/multiprefix may introduce other interoperability problems, particularly in
scenarios. This is a clear indication that advice in this area is multihomed/multi-prefix scenarios. This is a clear indication that
warranted. advice in this area is warranted.
Unresponsiveness to these "flash-renumbering" events is caused by the Unresponsiveness to these flash-renumbering events is caused by the
inability of the network to deprecate stale information, as well as inability of the network to deprecate (and eventually invalidate)
by the inability of hosts to react to network configuration changes stale information as well as by the inability of hosts to react to
in a more timely manner. Clearly, it would be desirable that these network configuration changes in a more timely manner. Clearly, it
flash-renumbering scenarios do not occur, and that, when they do would be desirable that these flash-renumbering events do not occur
occur, that hosts are explicitly and reliably notified of their and that, when they do occur, hosts are explicitly and reliably
occurrence. However, for robustness reasons, it is paramount for notified of their occurrence. However, for robustness reasons, it is
hosts to be able to recover from stale configuration information even paramount for hosts to be able to recover from stale configuration
when these flash-renumbering events occur and the network is unable information even when these flash-renumbering events occur and the
to explicitly and reliably notify hosts about such conditions. network is unable to explicitly and reliably notify hosts about such
conditions.
Section 2 analyzes this problem in more detail. Section 3 describes Section 2 analyzes this problem in more detail. Section 3 describes
possible operational mitigations. Section 4 describes possible possible operational mitigations. Section 4 describes possible
future work to mitigate the aforementioned problem. future work to mitigate the aforementioned problem.
2. Analysis of the Problem 2. Analysis of the Problem
As noted in Section 1, the problems discussed in this document are As noted in Section 1, the problem discussed in this document is
exacerbated by the default values of some protocol parameters and exacerbated by the default values of some protocol parameters and
other factors. The following sections analyze each of them in other factors. The following sections analyze each of them in
detail. detail.
2.1. Use of Dynamic Prefixes 2.1. Use of Dynamic Prefixes
In network scenarios where dynamic prefixes are employed, renumbering In network scenarios where dynamic prefixes are employed, renumbering
events lead to updated network configuration information being events lead to updated network configuration information being
propagated through the network, such that the renumbering events are propagated through the network, such that the renumbering events are
gracefully handled. However, if the renumbering event happens along gracefully handled. However, if the renumbering event happens along
with e.g. loss of configuration state by some of the devices involved with, e.g., loss of configuration state by some of the devices
in the renumbering procedure (e.g., a router crashes, reboots, and involved in the renumbering procedure (e.g., a router crashes,
gets leased a new prefix), this may result in a flash-renumbering reboots, and gets leased a new prefix), this may result in a flash-
event, where new prefixes are introduced without properly phasing out renumbering event, where new prefixes are introduced without properly
the old ones. phasing out the old ones.
In simple residential or small office scenario, the problem discussed In simple residential or small office scenarios, the problem
in this document would be avoided if DHCPv6-PD would lease "stable" discussed in this document would be avoided if DHCPv6-PD leased
prefixes. However, a recent survey [UK-NOF] indicates that 37% of "stable" prefixes. However, a recent survey [UK-NOF] indicates that
the responding ISPs employ dynamic prefixes. That is, dynamic IPv6 37% of the responding ISPs employ dynamic IPv6 prefixes. That is,
prefixes are an operational reality. dynamic IPv6 prefixes are an operational reality.
Deployment reality aside, there are a number of possible issues Deployment reality aside, there are a number of possible issues
associated with stable prefixes: associated with stable prefixes:
o Provisioning systems may be unable to deliver stable IPv6 * Provisioning systems may be unable to deliver stable IPv6
prefixes. prefixes.
o While an ISP might lease stable prefixes to the home or small * While an ISP might lease stable prefixes to the home or small
office, the Customer Edge router might in turn lease sub-prefixes office, the Customer Edge router might in turn lease sub-prefixes
of these prefixes to other internal network devices. Unless the of these prefixes to other internal network devices. Unless the
associated lease databases are stored on non-volatile memory, associated lease databases are stored on non-volatile memory,
these internal devices might be leased dynamic sub-prefixes of the these internal devices might get leased dynamic sub-prefixes of
stable prefix leased by the ISP. In other words, every time a the stable prefix leased by the ISP. In other words, every time a
prefix is leased there is the potential for the resulting prefixes prefix is leased, there is the potential for the resulting
to become dynamic, even if the device leasing sub-prefixes has prefixes to become dynamic, even if the device leasing sub-
been leased a stable prefix by its upstream router. prefixes has been leased a stable prefix by its upstream router.
o While there is a range of information that may be employed to * While there is a range of information that may be employed to
correlate network activity [RFC7721], the use of stable prefixes correlate network activity [RFC7721], the use of stable prefixes
clearly simplifies network activity correlation, and may clearly simplifies network activity correlation and may reduce the
essentially render features such as "temporary addresses" effectiveness of "temporary addresses" [RFC8981].
[RFC4941] irrelevant.
o There may be existing advice for ISPs to deliver dynamic IPv6 * There might be existing advice for ISPs to deliver dynamic IPv6
prefixes *by default* (see e.g. [GERMAN-DP]) over privacy prefixes *by default* (e.g., see [GERMAN-DP]) over privacy
concerns associated with stable prefixes. 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 For a number of reasons (such as the ones stated above), IPv6
deployments may employ dynamic prefixes (even at the expense of the deployments might employ dynamic prefixes (even at the expense of the
issues discussed in this document), and that there might be scenarios issues discussed in this document), and there might be scenarios in
in which the dynamics of a network are such that the network exhibits which the dynamics of a network are such that the network exhibits
the behaviour of dynamic prefixes. Rather than trying to regulate the behavior of dynamic prefixes. Rather than trying to regulate how
how operators may run their networks, this document aims at improving operators may run their networks, this document aims at improving
network robustness in the deployed Internet. network robustness in the deployed Internet.
2.2. Default Timer Values in IPv6 Stateless Address Autoconfiguration 2.2. Default PIO Lifetime Values in IPv6 Stateless Address
(SLAAC) Autoconfiguration (SLAAC)
The impact of the issue discussed in this document is a function of The impact of the issue discussed in this document is a function of
the lifetime values employed for the PIO lifetimes, since these the lifetime values employed for PIOs, since these values determine
values determine for how long the corresponding addresses will be for how long the corresponding addresses will be preferred and
preferred and considered valid. Thus, when the problem discussed in considered valid. Thus, when the problem discussed in this document
this document is experienced, the longer the PIO lifetimes, the is experienced, the longer the PIO lifetimes, the higher the impact.
higher the impact.
[RFC4861] specifies the following default PIO lifetime values: [RFC4861] specifies the following default PIO lifetime values:
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) * Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) * Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
Under problematic circumstances, such as where the corresponding Under problematic circumstances, such as when the corresponding
network information has become stale without any explicit and network information has become stale without any explicit and
reliable signal from the network (as described in Section 1), it reliable signal from the network (as described in Section 1), it
could take hosts up to 7 days (one week) to deprecate the could take hosts up to 7 days (one week) to deprecate the
corresponding addresses, and up to 30 days (one month) to eventually corresponding addresses and up to 30 days (one month) to eventually
invalidate and remove any addresses configured for the stale prefix. invalidate and remove any addresses configured for the stale prefix.
This means that it will typically take hosts an unacceptably long This means that it will typically take hosts an unacceptably long
period of time (on the order of several days) to recover from these period of time (on the order of several days) to recover from these
scenarios. scenarios.
2.3. Recovering from Stale Network Configuration Information 2.3. Recovering from Stale Network Configuration Information
SLAAC hosts are unable to recover from stale network configuration SLAAC hosts are unable to recover from stale network configuration
information for a number of reasons: information, since:
o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an * In scenarios where SLAAC routers explicitly signal the renumbering
unauthenticated RA may never reduce the "RemainingLifetime" to event, hosts will typically deprecate, but not invalidate, the
less than two hours. If the RemainingLifetime of an address is stale addresses, since item "e)" of Section 5.5.3 of [RFC4862]
smaller than 2 hours, then a Valid Lifetime smaller than 2 hours specifies that an unauthenticated RA may never reduce the valid
will be ignored. The Preferred Lifetime of an address can be lifetime of an address to less than two hours. Communication with
reduced to any value to avoid using a stale prefix for new the new "users" of the stale prefix will not be possible, since
communications. the stale prefix will still be considered "on-link" by the local
hosts.
o In the absence of explicit signalling from SLAAC routers (such as * In the absence of explicit signaling from SLAAC routers, SLAAC
sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts hosts will typically fail to recover from stale configuration
fail to recover from stale configuration information in a timely information in a timely manner, since hosts would need to rely on
manner. However, when a network element is able to explicitly the last Preferred Lifetime and Valid Lifetime advertised for the
signal the renumbering event, it will only be able to deprecate stale prefix, for the corresponding addresses to become deprecated
the stale prefix, but not to invalidate the prefix in question. and subsequently invalidated. Please see Section 2.2 of this
Therefore, communication with the new "owners" of the stale prefix document for a discussion of the default PIO lifetime values.
will not be possible, since the stale prefix will still be
considered "on-link".
2.4. Lack of Explicit Signaling about Stale Information 2.4. Lack of Explicit Signaling about Stale Information
Whenever prefix information has changed, a SLAAC router should not Whenever prefix information has changed, a SLAAC router should
only advertise the new information, but should also advertise the advertise not only the new information but also the stale information
stale information with appropriate lifetime values (both "Preferred with appropriate lifetime values (both the Preferred Lifetime and the
Lifetime" and "Valid Lifetime" set to 0). This would provide Valid Lifetime set to 0). This would provide explicit signaling to
explicit signaling to SLAAC hosts to remove the stale information SLAAC hosts to remove the stale information (including configured
(including configured addresses and routes). However, in scenarios addresses and routes). However, in certain scenarios, such as when a
such as when a CE router crashes and reboots, the CE router may have CE router crashes and reboots, the CE router may have no knowledge
no knowledge about the previously-advertised prefixes, and thus may about the previously advertised prefixes and thus might be unable to
be unable to advertise them with appropriate lifetimes (in order to advertise them with appropriate lifetimes (in order to deprecate and
deprecate them). eventually invalidate them).
However, we note that, as discussed in Section 2.3, PIOs with small In any case, we note that, as discussed in Section 2.3, PIOs with
Valid Lifetimes in unauthenticated RAs will not lower the Valid small Valid Lifetimes in unauthenticated RAs will not lower the Valid
Lifetime to any value shorter than two hours (as per [RFC4862]). Lifetime to any value shorter than two hours (as per [RFC4862]).
Therefore, even if a SLAAC router tried to explicitly signal the Therefore, even if a SLAAC router tried to explicitly signal the
network about the stale configuration information via unauthenticated network about the stale configuration information via unauthenticated
RAs, implementations compliant with [RFC4862] would deprecate the RAs, implementations compliant with [RFC4862] would deprecate the
corresponding prefixes, but would fail to invalidate them. corresponding prefixes but would fail to invalidate them.
NOTE: | NOTE:
Some implementations have been updated to honor small PIO |
lifetimes values, as proposed in [I-D.ietf-6man-slaac-renum]. For | Some implementations have been updated to honor small PIO
example, please see [Linux-update]. | lifetimes values, as proposed in [RENUM-RXN]. For example,
| please see [Linux-update].
2.5. Interaction Between DHCPv6-PD and SLAAC 2.5. Interaction between DHCPv6-PD and SLAAC
While DHCPv6-PD is normally employed along with SLAAC, the While DHCPv6-PD is normally employed along with SLAAC, the
interaction between the two protocols is largely unspecified. Not interaction between the two protocols is largely unspecified. Not
unusually, the two protocols are implemented in two different unusually, the two protocols are implemented in two different
software components with the interface between the two implemented by software components, with the interface between the two implemented
some sort of script that feeds the SLAAC implementation with values by means of some sort of script that feeds the SLAAC implementation
learned from DHCPv6-PD. with values learned from DHCPv6-PD.
At times, the prefix lease time is fed as a constant value to the At times, the prefix lease time is fed as a constant value to the
SLAAC router implementation, meaning that, eventually, the prefix SLAAC router implementation, meaning that, eventually, the prefix
lifetime advertised on the LAN side will span *past* the DHCPv6-PD lifetimes advertised on the LAN side will span *past* the DHCPv6-PD
lease time. This is clearly incorrect, since the SLAAC router lease time. This is clearly incorrect, since the SLAAC router
implementation would be allowing the use of such prefixes for a implementation would be allowing the use of such prefixes for a
longer time than it has been granted usage of those prefixes via period of time that is longer than the one they have been leased for
DHCPv6-PD. via DHCPv6-PD.
3. Operational Mitigations 3. Operational Mitigations
The following subsections discuss possible operational workarounds The following subsections discuss possible operational workarounds
for the aforementioned problems. for the aforementioned problems.
3.1. Stable Prefixes 3.1. Stable Prefixes
As noted in Section 2.1, the use of stable prefixes would eliminate 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 the issue in *some* of the scenarios discussed in Section 1 of this
document, such as the typical home network deployment. However, even document, such as the typical home network deployment. However, as
in such scenarios, there might be reasons for which an administrator noted in Section 2.1, there might be reasons for which an
may want or may need to employ dynamic prefixes administrator may want or may need to employ dynamic prefixes.
3.2. SLAAC Parameter Tweaking 3.2. SLAAC Parameter Tweaking
An operator may wish to override some SLAAC parameters such that, An operator may wish to override some SLAAC parameters such that,
under normal circumstances, the timers will be refreshed/reset, but under normal circumstances, the associated timers will be refreshed/
in the presence of network faults (such as the one discussed in this reset, but in the presence of network faults (such as the one
document), the timers go off and trigger some fault recovering action discussed in this document), the associated timers go off and trigger
(e.g. deprecate and subsequently invalidate stale addresses). some fault recovering action (e.g., deprecate and eventually
invalidate stale addresses).
The following router configuration variables from [RFC4861] The following router configuration variables from [RFC4861]
(corresponding to the "lifetime" parameters of PIOs) could be (corresponding to the "lifetime" parameters of PIOs) could be
overridden as follows: overridden as follows:
AdvPreferredLifetime: 2700 seconds (45 minutes) * AdvPreferredLifetime: 2700 seconds (45 minutes)
AdvValidLifetime: 5400 seconds (90 minutes)
NOTES:
The aforementioned values for AdvPreferredLifetime and * AdvValidLifetime: 5400 seconds (90 minutes)
AdvValidLifetime are expected to be appropriate for most networks.
In some networks, particularly where the operator has complete
control of prefix allocation and where hosts on the network may
spend long periods sleeping (e.g., sensors with limited battery),
longer values may be appropriate.
A CE router advertising a sub-prefix of a prefix leased via | NOTES:
DHCPv6-PD will periodically refresh the Preferred Lifetime and the |
Valid Lifetime of an advertised prefix to AdvPreferredLifetime and | The aforementioned values for AdvPreferredLifetime and
AdvValidLifetime, respectively, as long as the resulting lifetime | AdvValidLifetime are expected to be appropriate for most
of the corresponding prefixes does not extend past the DHCPv6-PD | networks. In some networks, particularly those where the
lease time [I-D.ietf-v6ops-cpe-slaac-renum]. | operator has complete control of prefix allocation and where
| hosts on the network may spend long periods of time sleeping
| (e.g., sensors with limited battery), longer values may be
| appropriate.
|
| A CE router advertising a sub-prefix of a prefix leased via
| DHCPv6-PD will periodically refresh the Preferred Lifetime and
| the Valid Lifetime of an advertised prefix to
| AdvPreferredLifetime and AdvValidLifetime, respectively, as
| long as the resulting lifetimes of the corresponding prefixes
| do not extend past the DHCPv6-PD lease time [RENUM-CPE].
RATIONALE: RATIONALE:
* In the context of [RFC8028], where it is clear that use of * In the context of [RFC8028], where it is clear that use of
addresses configured for a given prefix is tied to using the addresses configured for a given prefix is tied to using the next-
next-hop router that advertised the prefix, it does not make hop router that advertised the prefix, it does not make sense for
sense for the "Preferred Lifetime" of a PIO to be larger than the Preferred Lifetime of a PIO to be larger than the Router
the "Router Lifetime" (AdvDefaultLifetime) of the corresponding Lifetime (AdvDefaultLifetime) of the corresponding Router
Router Advertisement messages. The "Valid Lifetime" is set to Advertisement messages. The Valid Lifetime is set to a larger
a much larger value to cope with transient network problems. value to cope with transient network problems.
* Lacking RAs that refresh information, addresses configured for * Lacking RAs that refresh information, addresses configured for
advertised prefixes become deprecated in a more timely manner, advertised prefixes become deprecated in a more timely manner;
and thus Rule 3 of [RFC6724] causes other configured addresses therefore, Rule 3 of [RFC6724] causes other configured addresses
(if available) to be used instead. (if available) to be used instead.
* We note that lowering the default values for the "Valid * Reducing the Valid Lifetime of PIOs helps reduce the amount of
Lifetime" helps reduce the amount of time a host may maintain time a host may maintain stale information and the amount of time
stale information and the amount of time an advertising router an advertising router would need to advertise stale prefixes to
would need to advertise stale prefixes to deprecate them, while invalidate them. Reducing the Preferred Lifetime of PIOs helps
reducing the default "Preferred Lifetime" would reduce the reduce the amount of time it takes for a host to prefer other
amount of time it takes for a host to prefer other working working prefixes (see Section 12 of [RFC4861]). However, we note
prefixes (see Section 12 of [RFC4861]). However, while the that while the values suggested in this section are an improvement
values suggested in this section are an improvement over the over the default values specified in [RFC4861], they represent a
default values specified in [RFC4861], they represent a trade- trade-off among a number of factors, including responsiveness,
off among a number of factors, including responsiveness, possible impact on the battery life of connected devices
possible impact on the battery life of connected devices [RFC7772], etc. Thus, they may or may not provide sufficient
[RFC7772], etc. Thus, they may or may not provide sufficient mitigation to the problem discussed in this document.
mitigation to the problem discussed in this document.
4. Future Work 4. Future Work
Improvement in Customer Edge Routers [RFC7084] such that they can Improvements in Customer Edge routers [RFC7084], such that they can
signal the network about stale prefixes and deprecate them signal hosts about stale prefixes to deprecate (and eventually
accordingly can help mitigate the problem discussed in this document invalidate) them accordingly, can help mitigate the problem discussed
for the "home network" scenario. Such work is currently being in this document for the "home network" scenario. Such work is
pursued in [I-D.ietf-v6ops-cpe-slaac-renum]. currently being pursued in [RENUM-CPE].
Improvements in the SLAAC protocol [RFC4862] and other algorithms Improvements in the SLAAC protocol [RFC4862] and some IPv6-related
such as "Default Address Selection for IPv6" [RFC6724] would help algorithms, such as "Default Address Selection for Internet Protocol
improve network robustness. Such work is currently being pursued in Version 6 (IPv6)" [RFC6724], would help improve network robustness.
[I-D.ietf-6man-slaac-renum]. Such work is currently being pursued in [RENUM-RXN].
The aforementioned work is considered out of the scope of this The aforementioned work is considered out of the scope of this
present document, which only focuses on documenting the problem and present document, which only focuses on documenting the problem and
discussing operational mitigations. discussing operational mitigations.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
This document discusses a problem that may arise in scenarios where This document discusses a problem that may arise in scenarios where
flash-renumbering events occur, and proposes workarounds to mitigate flash-renumbering events occur and proposes workarounds to mitigate
the aforementioned problems. This document does not introduce any the aforementioned problem. This document does not introduce any new
new security issues, and thus the same security considerations as for security issues; therefore, the same security considerations as for
[RFC4861] and [RFC4862] apply. [RFC4861] and [RFC4862] apply.
7. Acknowledgments 7. References
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, Eric Vyncke, Klaas Wierenga, Robert Wilton, and Dale
Worley, for providing valuable comments on earlier 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 [I-D.linkova-6man-default-addr-selection-update],
and also in [RIPE-690]. Section 1 borrows text from
[I-D.linkova-6man-default-addr-selection-update], authored by Jen
Linkova.
8. References
8.1. Normative References 7.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
skipping to change at page 11, line 41 skipping to change at line 491
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
8.2. Informative References 7.2. Informative References
[DEFAULT-ADDR]
Linkova, J., "Default Address Selection and Subnet
Renumbering", Work in Progress, Internet-Draft, draft-
linkova-6man-default-addr-selection-update-00, 30 March
2017, <https://tools.ietf.org/html/draft-linkova-6man-
default-addr-selection-update-00>.
[FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network
(updated with solution)", SI6 Networks Blog, February (updated with solution)", SI6 Networks, February 2016,
2016, <https://www.si6networks.com/2016/02/16/quiz-weird- <https://www.si6networks.com/2016/02/16/quiz-weird-ipv6-
ipv6-traffic-on-the-local-network-updated-with-solution/>. traffic-on-the-local-network-updated-with-solution/>.
[GERMAN-DP] [GERMAN-DP]
BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im BFDI, "Einführung von IPv6: Hinweise für Provider im
Privatkundengeschaft und Herstellere", Entschliessung der Privatkundengeschäft und Hersteller" [Introduction of
84. Konferenz der Datenschutzbeauftragten des Bundes und IPv6: Notes for providers in the consumer market and
der Lander am 7./8. November 2012 in Frankfurt (Oder), manufacturers], Entschliessung der 84. Konferenz der
November 2012, Datenschutzbeauftragten des Bundes und der Lander
[Resolution of the 84th Conference of the Federal and
State Commissioners for Data Protection], November 2012,
<http://www.bfdi.bund.de/SharedDocs/Publikationen/ <http://www.bfdi.bund.de/SharedDocs/Publikationen/
Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv Entschliessungssammlung/DSBundLaender/84DSK_EinfuehrungIPv
6.pdf?__blob=publicationFile>. 6.pdf?__blob=publicationFile>.
[I-D.ietf-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-ietf-6man-slaac-
renum-01 (work in progress), August 2020.
[I-D.ietf-v6ops-cpe-slaac-renum]
Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving
the Reaction of Customer Edge Routers to Renumbering
Events", draft-ietf-v6ops-cpe-slaac-renum-05 (work in
progress), September 2020.
[I-D.linkova-6man-default-addr-selection-update]
Linkova, J., "Default Address Selection and Subnet
Renumbering", draft-linkova-6man-default-addr-selection-
update-00 (work in progress), March 2017.
[Linux-update] [Linux-update]
Gont, F., "[net-next] ipv6: Honor all IPv6 PIO Valid Gont, F., "Subject: [net-next] ipv6: Honor all IPv6 PIO
Lifetime values", Post to the netdev mailing-list Valid Lifetime values", message to the netdev mailing
http://vger.kernel.org/vger-lists.html, April 2020, list, 19 April 2020,
<https://patchwork.ozlabs.org/project/netdev/ <https://patchwork.ozlabs.org/project/netdev/
patch/20200419122457.GA971@archlinux- patch/20200419122457.GA971@archlinux-
current.localdomain/>. current.localdomain/>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RENUM-CPE]
Extensions for Stateless Address Autoconfiguration in Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, the Reaction of Customer Edge Routers to IPv6 Renumbering
<https://www.rfc-editor.org/info/rfc4941>. Events", Work in Progress, Internet-Draft, draft-ietf-
v6ops-cpe-slaac-renum-07, 16 February 2021,
<https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-
renum-07>.
[RENUM-RXN]
Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", Work in Progress, Internet-
Draft, draft-ietf-6man-slaac-renum-02, 19 January 2021,
<https://tools.ietf.org/html/draft-ietf-6man-slaac-renum-
02>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>. <https://www.rfc-editor.org/info/rfc7084>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772, Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016, DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>. <https://www.rfc-editor.org/info/rfc7772>.
[RIPE-690] [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, "Temporary Address Extensions for Stateless Address
J., Doering, G., Palet, J., Linkova, J., Balbinot, L., Autoconfiguration in IPv6", RFC 8981,
Meynell, K., and L. Howard, "Best Current Operational DOI 10.17487/RFC8981, February 2021,
Practice for Operators: IPv6 prefix assignment for end- <https://www.rfc-editor.org/info/rfc8981>.
users - persistent vs non-persistent, and what size to
choose", RIPE 690, October 2017, [RIPE-690] Žorž, J., Steffann, S., Dražumerič, P., Townsley, M.,
Alston, A., Doering, G., Palet Martinez, J., Linkova, J.,
Balbinot, L., Meynell, K., and L. Howard, "Best Current
Operational Practice for Operators: IPv6 prefix assignment
for end-users - persistent vs non-persistent, and what
size to choose", RIPE 690, October 2017,
<https://www.ripe.net/publications/docs/ripe-690>. <https://www.ripe.net/publications/docs/ripe-690>.
[UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household [UK-NOF] Palet Martinez, J., "IPv6 Deployment Survey and BCOP", UK
Services) How IPv6 is being deployed?", UK NOF 39, January NOF 39, January 2018,
2018, <https://indico.uknof.org.uk/event/41/contributions/542/>.
<https://indico.uknof.org.uk/event/41/contributions/542/
attachments/712/866/bcop-ipv6-prefix-v9.pdf>. Acknowledgments
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.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
Segurola y Habana 4310, 7mo Piso Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires Villa Devoto
Ciudad Autónoma de Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Jan Zorz Jan Žorž
6connect 6connect, Inc.
Email: jan@connect.com Email: jan@6connect.com
Richard Patterson Richard Patterson
Sky UK Sky UK
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
 End of changes. 80 change blocks. 
345 lines changed or deleted 357 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/