draft-ietf-v6ops-slaac-renum-04.txt   draft-ietf-v6ops-slaac-renum-05.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Intended status: Informational J. Zorz Intended status: Informational J. Zorz
Expires: April 1, 2021 6connect Expires: May 6, 2021 6connect
R. Patterson R. Patterson
Sky UK Sky UK
September 28, 2020 November 2, 2020
Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events Renumbering Events
draft-ietf-v6ops-slaac-renum-04 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 signaling of that prefixes becomes invalid without any explicit and reliable signaling
condition (such as when a CPE crashes and reboots without knowledge of that condition (such as when a Customer Edge router crashes and
of the previously-employed prefixes), nodes on the local network will reboots without knowledge of the previously-employed prefixes), nodes
continue using stale prefixes for an unacceptably long time (on the on the local network may continue using stale prefixes for an
order of several days), thus resulting in connectivity problems. unacceptably long time (on the order of several days), thus resulting
This document documents this issue and discusses operational in connectivity problems. This document describes this issue and
workarounds that may help to improve network robustness. discusses operational workarounds that may help to improve network
Additionally, it highlights areas where further work may be needed. robustness. Additionally, it highlights areas where further work may
be needed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 1, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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
2. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 5 2. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 5
2.1. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . 5 2.1. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . 5
2.2. Default Timer Values in IPv6 Stateless Address 2.2. Default Timer Values in IPv6 Stateless Address
Autoconfiguration (SLAAC) . . . . . . . . . . . . . . . . 6 Autoconfiguration (SLAAC) . . . . . . . . . . . . . . . . 6
2.3. Recovering from Stale Network Configuration Information . 6 2.3. Recovering from Stale Network Configuration Information . 7
2.4. Lack of Explicit Signaling about Stale Information . . . 6 2.4. Lack of Explicit Signaling about Stale Information . . . 7
2.5. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 7 2.5. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 8
3. Operational Mitigations . . . . . . . . . . . . . . . . . . . 7 3. Operational Mitigations . . . . . . . . . . . . . . . . . . . 8
3.1. Stable Prefixes . . . . . . . . . . . . . . . . . . . . . 7 3.1. Stable Prefixes . . . . . . . . . . . . . . . . . . . . . 8
3.2. SLAAC Parameter Tweaking . . . . . . . . . . . . . . . . 8 3.2. SLAAC Parameter Tweaking . . . . . . . . . . . . . . . . 8
4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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, with old/stale
prefixes being phased-out via reduced prefix lifetimes, and new prefixes being phased-out via reduced prefix lifetimes, and new
prefixes (with longer lifetimes) being introduced at the same time. prefixes (with longer lifetimes) being introduced at the same time.
However, there are several scenarios that may lead to the so-called However, there are several scenarios that may lead to the so-called
"flash-renumbering" events, where the prefix employed by a network "flash-renumbering" events, where the prefix employed by a network
suddenly becomes invalid and replaced by a new prefix. In some of suddenly becomes invalid and replaced by a new prefix. In some of
these scenarios, the local router producing the network renumbering these scenarios, the local router producing the network renumbering
event may try to deprecate the currently-employed prefixes (by event may try to deprecate the currently-employed prefixes (by
explicitly signaling the network about the renumbering event), explicitly signaling the network about the renumbering event),
whereas in other scenarios it may be unable to do so. 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 signaling of that prefixes becomes invalid without any explicit and reliable signaling
condition, nodes on the local network will continue using stale of that condition, nodes on the local network may continue using
prefixes for an unacceptably long period of time, thus resulting in stale prefixes for an unacceptably long period of time, thus
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 o The most common IPv6 deployment scenario for residential or small
office networks is that in which a CPE 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 CPE 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 CPE router crashes and reboots, the CPE may scenarios where the CE router crashes and reboots, the CE may
obtain (via DHCPv6-PD) a different prefix from the one previously obtain (via DHCPv6-PD) a different prefix from the one previously
leased, and therefore advertise (via SLAAC) the new prefix on the leased, and therefore advertise (via SLAAC) the new prefix on the
LAN side. Hosts will typically configure addresses for the new LAN side. Hosts will typically configure addresses for the new
prefix, but will normally retain and and may actively employ the prefix, but will normally retain and may actively employ the
addresses configured for the previously-advertised prefix, since addresses configured for the previously-advertised prefix, since
their associated Preferred Lifetime and Valid Lifetime allow them their associated Preferred Lifetime and Valid Lifetime allow them
to do so. to do so.
o A router (e.g. Customer Edge router) may advertise o A router (e.g. Customer Edge router) advertises autoconfiguration
autoconfiguration prefixes corresponding to prefixes learned via prefixes corresponding to prefixes learned via DHCPv6-PD with
DHCPv6-PD with constant PIO lifetimes that are not synchronized constant PIO lifetimes that are not synchronized with the
with the DHCPv6-PD lease time (as required in Section 6.3 of DHCPv6-PD lease time (even though Section 6.3 of [RFC8415]
[RFC8415]). While this behavior violates the aforementioned requires such synchronization). While this behavior violates the
requirement from [RFC8415], it is not an unusual behavior, aforementioned requirement from [RFC8415], it is not an unusual
particularly when e.g. DHCPv6-PD is implemented in a different behavior, particularly when e.g. DHCPv6-PD is implemented in a
software module than the SLAAC router component. different software module than the SLAAC router component.
o A switch-port the host is connected to may be moved to another o A switch-port the host is connected to is moved to another subnet
subnet (VLAN) as a result of manual switch-port reconfiguration or (VLAN) as a result of manual switch-port reconfiguration or 802.1x
802.1x re-authentication. In particular, there has been evidence re-authentication. There has been evidence that some 802.1x
that some 802.1x supplicants do not reset network settings after supplicants do not reset network settings after successful 802.1x
successful 802.1x authentication. So if a host had failed 802.1x authentication. So if a host fails 802.1x authentication for some
authentication for some reason, was placed in a "quarantine" VLAN reason, is placed in a "quarantine" VLAN and is successfully
and then got successfully authenticated later on, it might end up authenticated later on, it might end up having IPv6 addresses from
having IPv6 addresses from both old ("quarantine") and new VLANs. both the old ("quarantine") and the new VLANs.
o During the planned network renumbering, a router may be configured o During the planned network renumbering, a router is configured to
to send an RA with the Preferred Lifetime for the "old" Prefix send an RA with the Preferred Lifetime for the "old" Prefix
Information Option (PIO) set to zero and the new PIO having non- Information Option (PIO) set to zero and the new PIO with a non-
zero Preferred Lifetime. However, due to unsolicited RAs being zero Preferred Lifetime. However, due to unsolicited RAs being
sent as all-hosts multicast and multicast being rather unreliable sent to a multicast destination address, and multicast being
on busy wifi networks, the RA may not be received by a host (or rather unreliable on busy wifi networks, the RA might not be
set of hosts). received by local hosts.
o Automated device config management system performs periodic config o Automated device config management system performs periodic config
pushes to network devices. In these scenarios, network devices pushes to network devices. In these scenarios, network devices
may simply immediately forget their previous configuration, rather may simply immediately forget their previous configuration, rather
than withdrawing it gracefully. If such a push results in than withdrawing it gracefully. If such a push results in
changing the subnet configured on a particular network, hosts changing the subnet configured on a particular network, hosts
attached to that network would not get notified about the subnet attached to that network would not get notified about the subnet
change, and their addresses from the "old" prefix will not be change, and their addresses from the "old" prefix will not be
deprecated. A related scenario is the incorrect network deprecated. A related scenario is the incorrect network
renumbering where a network administrator renumbers a network by renumbering where a network administrator renumbers a network by
simply removing the "old" prefix from the configuration and simply removing the "old" prefix from the configuration and
configuring a new prefix instead. configuring a new prefix instead.
Lacking any explicit signaling to deprecate the previously-advertised Lacking any explicit and reliable signaling to deprecate the
prefixes, hosts may continue to employ the previously-configured previously-advertised prefixes, hosts may continue to employ the
addresses, which will typically result in packets being blackholed -- previously-configured addresses, which will typically result in
whether because of egress-filtering by the CPE or ISP, or packets packets being blackholed (whether because of egress-filtering by the
being discarded or routed elsewhere. CE router or ISP) or the return traffic being discarded or routed
elsewhere.
We note that the default values for the "Preferred Lifetime" and
"Valid Lifetime" of PIOs, as specified in [RFC4861], are:
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
This means that in the aforementioned scenarios, the stale addresses The default values for the "Preferred Lifetime" and "Valid Lifetime"
would be retained and also actively employed for new communications of PIOs specified in [RFC4861] mean that, in the aforementioned
instances for an unacceptably long period of time (one month, and one scenarios, the stale addresses would be retained, and could be
week, respectively), leading to interoperability problems, instead of actively employed for new communications instances, for an
hosts transitioning to the newly-advertised prefix(es) in a timelier unacceptably long period of time (one month, and one week,
manner. 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 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 apparently-stale prefixes
when the device receives any packets employing a source address from when the device receives any packets employing a source address from
a prefix not currently advertised for address configuration on the a prefix not currently advertised for address configuration on the
local network [FRITZ]. However, this may introduce other local network [FRITZ]. However, this may introduce other
interoperability problems, particularly in multihomed/multiprefix interoperability problems, particularly in multihomed/multiprefix
scenarios. This is a clear indication that advice in this area is scenarios. This is a clear indication that advice in this area is
warranted. 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 stale information, as well as
by the inability of hosts to react to network configuration changes by the inability of hosts to react to network configuration changes
in a timelier manner. Clearly, it would be desirable that these in a more timely manner. Clearly, it would be desirable that these
flash-renumbering scenarios do not occur, and that, when they do flash-renumbering scenarios do not occur, and that, when they do
occur, that hosts are explicitly notified of their occurrence. occur, that hosts are explicitly and reliably notified of their
However, for robustness reasons, it is paramount for hosts to be able occurrence. However, for robustness reasons, it is paramount for
to recover from stale configuration information even when these hosts to be able to recover from stale configuration information even
flash-renumbering events occur and the network is unable to when these flash-renumbering events occur and the network is unable
explicitly notify hosts about such conditions. 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 problems discussed in this document are
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 the residential or small office scenario, the problem discussed in In network scenarios where dynamic prefixes are employed, renumbering
this document would be avoided if DHCPv6-PD would lease "stable" 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 scenario, the problem discussed
in this document would be avoided if DHCPv6-PD would lease "stable"
prefixes. However, a recent survey [UK-NOF] indicates that 37% of prefixes. However, a recent survey [UK-NOF] indicates that 37% of
the responding ISPs employ dynamic prefixes. That is, dynamic IPv6 the responding ISPs employ dynamic prefixes. That is, dynamic IPv6
prefixes are an operational reality. 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 o Provisioning systems may be unable to deliver stable IPv6
prefixes. prefixes.
o 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 be 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.
o While there is a range of information that may be employed to o 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
essentially render features such as "temporary addresses" essentially render features such as "temporary addresses"
[RFC4941] irrelevant. [RFC4941] irrelevant.
o There may be existing advice for ISPs to deliver dynamic IPv6 o There may be existing advice for ISPs to deliver dynamic IPv6
prefixes *by default* (see e.g. [GERMAN-DP]) over privacy prefixes *by default* (see e.g. [GERMAN-DP]) over privacy
concerns associated with stable prefixes. concerns associated with stable prefixes.
skipping to change at page 6, line 10 skipping to change at page 6, line 26
deployments may employ dynamic prefixes (even at the expense of the deployments may 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 that there might be scenarios
in which the dynamics of a network are such that the network exhibits in which the dynamics of a network are such that the network exhibits
the behaviour of dynamic prefixes. Rather than trying to regulate the behaviour of dynamic prefixes. Rather than trying to regulate
how operators may run their networks, this document aims at improving how 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 Timer Values in IPv6 Stateless Address Autoconfiguration
(SLAAC) (SLAAC)
IPv6 SLAAC employs the following default PIO lifetime values: The impact of the issue discussed in this document is a function of
the lifetime values employed for the PIO lifetimes, 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:
o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days)
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
Under problematic circumstances, such as where the corresponding Under problematic circumstances, such as where the corresponding
network information has become stale without any explicit signal from network information has become stale without any explicit and
the network (as described in Section 1), it will take a host 7 days reliable signal from the network (as described in Section 1), it
(one week) to deprecate the corresponding addresses, and 30 days (one could take hosts up to 7 days (one week) to deprecate the
month) to eventually invalidate and remove any addresses configured corresponding addresses, and up to 30 days (one month) to eventually
for the stale prefix. This means that it will typically take hosts invalidate and remove any addresses configured for the stale prefix.
an unacceptably long period of time (on the order of several days) to This means that it will typically take hosts an unacceptably long
recover from these scenarios. period of time (on the order of several days) to recover from these
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 for a number of reasons:
o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an RA may o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an
never reduce the "RemainingLifetime" to less than two hours. If unauthenticated RA may never reduce the "RemainingLifetime" to
the RemainingLifetime of an address is smaller than 2 hours, then less than two hours. If the RemainingLifetime of an address is
a Valid Lifetime smaller than 2 hours will be ignored. The smaller than 2 hours, then a Valid Lifetime smaller than 2 hours
Preferred Lifetime of an address can be reduced to any value to will be ignored. The Preferred Lifetime of an address can be
avoid using a stale prefix for new communications. reduced to any value to avoid using a stale prefix for new
communications.
o In the absence of explicit signalling from SLAAC routers (such as o In the absence of explicit signalling from SLAAC routers (such as
sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts
fail to recover from stale configuration information in a timely fail to recover from stale configuration information in a timely
manner. However, when a network element is able to explicitly manner. However, when a network element is able to explicitly
signal the renumbering event, it will only be able to deprecate signal the renumbering event, it will only be able to deprecate
the stale prefix, but not to invalidate the prefix in question. the stale prefix, but not to invalidate the prefix in question.
Therefore, communication with the new "owners" of the stale prefix Therefore, communication with the new "owners" of the stale prefix
will not be possible, since the stale prefix will still be will not be possible, since the stale prefix will still be
considered "on-link". 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 not
only advertise the new information, but should also advertise the only advertise the new information, but should also advertise the
stale information with appropriate lifetime values (both "Preferred stale information with appropriate lifetime values (both "Preferred
Lifetime" and "Valid Lifetime" set to 0). This would provide Lifetime" and "Valid Lifetime" set to 0). This would provide
explicit signaling to SLAAC hosts to remove the stale information explicit signaling to SLAAC hosts to remove the stale information
(including configured addresses and routes). However, in scenarios (including configured addresses and routes). However, in scenarios
such as when a CPE router crashes and reboots, the CPE router may such as when a CE router crashes and reboots, the CE router may have
have no knowledge about the previously-advertised prefixes, and thus no knowledge about the previously-advertised prefixes, and thus may
may be unable to advertise them with appropriate lifetimes (in order be unable to advertise them with appropriate lifetimes (in order to
to deprecate them). deprecate them).
However, we note that, as discussed in Section 2.3, PIOs with small However, we note that, as discussed in Section 2.3, PIOs with small
Valid Lifetimes will not lower the Valid Lifetime to any value Valid Lifetimes in unauthenticated RAs will not lower the Valid
shorter than two hours (as per [RFC4862]). Therefore, even if a Lifetime to any value shorter than two hours (as per [RFC4862]).
SLAAC router tried to explicitly signal the network about the stale Therefore, even if a SLAAC router tried to explicitly signal the
configuration information via RAs, implementations compliant with network about the stale configuration information via unauthenticated
[RFC4862] would deprecate the corresponding prefixes, but would fail RAs, implementations compliant with [RFC4862] would deprecate the
to invalidate them. corresponding prefixes, but would fail to invalidate them.
NOTE: NOTE:
Some implementations have been updated to honor small PIO Some implementations have been updated to honor small PIO
lifetimes values, as proposed in [I-D.ietf-6man-slaac-renum]. For lifetimes values, as proposed in [I-D.ietf-6man-slaac-renum]. For
example, please see [Linux]. 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 by
some sort of script that feeds the SLAAC implementation with values some sort of script that feeds the SLAAC implementation with values
learned from DHCPv6-PD. learned from DHCPv6-PD.
skipping to change at page 8, line 10 skipping to change at page 8, line 38
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, even
in such scenarios, there might be reasons for which an administrator in such scenarios, there might be reasons for which an administrator
may want or may need to employ dynamic prefixes 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 (including some packet loss), the timers under normal circumstances, the timers will be refreshed/reset, but
will be refreshed/reset, but in the presence of network faults (such in the presence of network faults (such as the one discussed in this
as network configuration information becoming stale without explicit document), the timers go off and trigger some fault recovering action
signaling), the timers go off and trigger some fault recovering (e.g. deprecate and subsequently invalidate stale addresses).
action (such as deprecating the corresponding addresses and
subsequently invalidating/removing them).
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) AdvValidLifetime: 5400 seconds (90 minutes)
NOTES: NOTES:
A CPE router advertising a sub-prefix of a prefixed leased via
The aforementioned values for AdvPreferredLifetime and
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
DHCPv6-PD will periodically refresh the Preferred Lifetime and the DHCPv6-PD will periodically refresh the Preferred Lifetime and the
Valid Lifetime of an advertised prefix to AdvPreferredLifetime and Valid Lifetime of an advertised prefix to AdvPreferredLifetime and
AdvValidLifetime, respectively, as long as the resulting lifetime AdvValidLifetime, respectively, as long as the resulting lifetime
of the corresponding prefixes does not extend past the DHCPv6-PD of the corresponding prefixes does not extend past the DHCPv6-PD
lease time [I-D.ietf-v6ops-cpe-slaac-renum]. lease time [I-D.ietf-v6ops-cpe-slaac-renum].
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-hop router that advertised the prefix, it does not make next-hop router that advertised the prefix, it does not make
sense for the "Preferred Lifetime" of a PIO to be larger than sense for the "Preferred Lifetime" of a PIO to be larger than
the "Router Lifetime" (AdvDefaultLifetime) of the corresponding the "Router Lifetime" (AdvDefaultLifetime) of the corresponding
Router Advertisement messages. The "Valid Lifetime" is set to Router Advertisement messages. The "Valid Lifetime" is set to
a much larger value to cope with transient network problems. a much larger 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 timelier manner, and advertised prefixes become deprecated in a more timely manner,
thus Rule 3 of [RFC6724] causes other configured addresses (if and thus Rule 3 of [RFC6724] causes other configured addresses
available) to be used instead. (if available) to be used instead.
* We note that lowering the default values for the "Valid * We note that lowering the default values for the "Valid
Lifetime" helps reduce the amount of time a host may maintain Lifetime" helps reduce the amount of time a host may maintain
stale information and the amount of time an advertising router stale information and the amount of time an advertising router
would need to advertise stale prefixes to deprecate them, while would need to advertise stale prefixes to deprecate them, while
reducing the default "Preferred Lifetime" would reduce the reducing the default "Preferred Lifetime" would reduce the
amount of time it takes for a host to prefer other working amount of time it takes for a host to prefer other working
prefixes (see Section 12 of [RFC4861]). However, while the prefixes (see Section 12 of [RFC4861]). However, while the
values suggested in this section are an improvement over the values suggested in this section are an improvement over the
default values specified in [RFC4861], they represent a trade- default values specified in [RFC4861], they represent a trade-
skipping to change at page 9, line 40 skipping to change at page 10, line 25
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
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 problems. This document does not introduce any
new security issues. new security issues, and thus the same security considerations as for
[RFC4861] and [RFC4862] apply.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank (in alphabetical order) Brian The authors would like to thank (in alphabetical order) Brian
Carpenter, Owen DeLong, Guillermo Gont, Philip Homburg, Warren Carpenter, Alissa Cooper, Roman Danyliw, Owen DeLong, Martin Duke,
Kumari, Ted Lemon, Juergen Schoenwaelder, Klaas Wierenga, and Dale 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 Worley, for providing valuable comments on earlier versions of this
document. document.
The authors would like to thank (in alphabetical order) Mikael The authors would like to thank (in alphabetical order) Mikael
Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou,
Uesley Correa, Owen DeLong, Gert Doering, Fernando Frediani, Steinar Uesley Correa, Owen DeLong, Gert Doering, Martin Duke, Fernando
Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Frediani, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard,
Ted Lemon, Albert Manfredi, Jordi Palet Martinez, Michael Richardson, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez,
Mark Smith, Tarko Tikan, and Ole Troan, for providing valuable Michael Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for
comments on [I-D.gont-6man-slaac-renum], on which this document is providing valuable comments on a previous document on which this
based. document is based.
Fernando would like to thank Alejandro D'Egidio and Sander Steffann Fernando would like to thank Alejandro D'Egidio and Sander Steffann
for a discussion of these issues. Fernando would also like to thank for a discussion of these issues. Fernando would also like to thank
Brian Carpenter who, over the years, has answered many questions and Brian Carpenter who, over the years, has answered many questions and
provided valuable comments that have benefited his protocol-related provided valuable comments that have benefited his protocol-related
work. work.
The problem discussed in this document has been previously documented The problem discussed in this document has been previously documented
by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update],
and also in [RIPE-690]. Section 1 borrows text from and also in [RIPE-690]. Section 1 borrows text from
skipping to change at page 10, line 37 skipping to change at page 11, line 25
[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>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
Extensions for Stateless Address Autoconfiguration in "Default Address Selection for Internet Protocol Version 6
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
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,
skipping to change at page 11, line 22 skipping to change at page 12, line 15
[GERMAN-DP] [GERMAN-DP]
BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im
Privatkundengeschaft und Herstellere", Entschliessung der Privatkundengeschaft und Herstellere", Entschliessung der
84. Konferenz der Datenschutzbeauftragten des Bundes und 84. Konferenz der Datenschutzbeauftragten des Bundes und
der Lander am 7./8. November 2012 in Frankfurt (Oder), der Lander am 7./8. November 2012 in Frankfurt (Oder),
November 2012, 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.gont-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-gont-6man-slaac-
renum-08 (work in progress), May 2020.
[I-D.ietf-6man-slaac-renum] [I-D.ietf-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC) Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-ietf-6man-slaac- to Flash Renumbering Events", draft-ietf-6man-slaac-
renum-01 (work in progress), August 2020. renum-01 (work in progress), August 2020.
[I-D.ietf-v6ops-cpe-slaac-renum] [I-D.ietf-v6ops-cpe-slaac-renum]
Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving
the Reaction of Customer Edge Routers to Renumbering the Reaction of Customer Edge Routers to Renumbering
Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in Events", draft-ietf-v6ops-cpe-slaac-renum-05 (work in
progress), August 2020. progress), September 2020.
[I-D.linkova-6man-default-addr-selection-update] [I-D.linkova-6man-default-addr-selection-update]
Linkova, J., "Default Address Selection and Subnet Linkova, J., "Default Address Selection and Subnet
Renumbering", draft-linkova-6man-default-addr-selection- Renumbering", draft-linkova-6man-default-addr-selection-
update-00 (work in progress), March 2017. update-00 (work in progress), March 2017.
[Linux] Gont, F., "[net-next] ipv6: Honor all IPv6 PIO Valid [Linux-update]
Gont, F., "[net-next] ipv6: Honor all IPv6 PIO Valid
Lifetime values", Post to the netdev mailing-list Lifetime values", Post to the netdev mailing-list
http://vger.kernel.org/vger-lists.html, April 2020, http://vger.kernel.org/vger-lists.html, 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/>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
"Default Address Selection for Internet Protocol Version 6 Extensions for Stateless Address Autoconfiguration in
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc4941>.
[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>.
 End of changes. 40 change blocks. 
140 lines changed or deleted 170 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/