draft-ietf-v6ops-slaac-renum-03.txt   draft-ietf-v6ops-slaac-renum-04.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: February 26, 2021 6connect Expires: April 1, 2021 6connect
R. Patterson R. Patterson
Sky UK Sky UK
August 25, 2020 September 28, 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-03 draft-ietf-v6ops-slaac-renum-04
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 signaling of that
condition (such as when a CPE crashes and reboots without knowledge condition (such as when a CPE crashes and reboots without knowledge
of the previously-employed prefixes), nodes on the local network will of the previously-employed prefixes), nodes on the local network will
continue using stale prefixes for an unacceptably long time, thus continue using stale prefixes for an unacceptably long time (on the
resulting in connectivity problems. This document documents this order of several days), thus resulting in connectivity problems.
issue and discusses operational workarounds that may help to improve This document documents this issue and discusses operational
network robustness. Additionally, it highlights areas where further workarounds that may help to improve network robustness.
work may be needed. 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 February 26, 2021. This Internet-Draft will expire on April 1, 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 21 skipping to change at page 2, line 21
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
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) . . . . . . . . . . . . . . . . 5 Autoconfiguration (SLAAC) . . . . . . . . . . . . . . . . 6
2.3. Recovering from Stale Network Configuration Information . 6 2.3. Recovering from Stale Network Configuration Information . 6
2.4. Lack of Explicit Signaling about Stale Information . . . 7 2.4. Lack of Explicit Signaling about Stale Information . . . 6
2.5. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 7 2.5. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 7
3. Operational Mitigations . . . . . . . . . . . . . . . . . . . 7 3. Operational Mitigations . . . . . . . . . . . . . . . . . . . 7
3.1. Stable Prefixes . . . . . . . . . . . . . . . . . . . . . 7 3.1. Stable Prefixes . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
IPv6 largely assumes prefix stability, with network renumbering only IPv6 Stateless address autoconfiguration (SLAAC) [RFC4862] conveys
taking place in a planned manner, with old/stale prefixes being information about prefixes to be employed for address configuration
phased-out via reduced prefix lifetimes, and new prefixes (with via Prefix Information Options (PIOs) sent in Router Advertisement
longer lifetimes) being introduced at the same time. However, there (RA) messages. IPv6 largely assumes prefix stability, with network
are several scenarios that may lead to the so-called "flash- renumbering only taking place in a planned manner, with old/stale
renumbering" events, where the prefix employed by a network suddenly prefixes being phased-out via reduced prefix lifetimes, and new
becomes invalid and replaced by a new prefix. In some of these prefixes (with longer lifetimes) being introduced at the same time.
scenarios, the local router producing the network renumbering event However, there are several scenarios that may lead to the so-called
may try to deprecate the currently-employed prefixes (by explicitly "flash-renumbering" events, where the prefix employed by a network
signaling the network about the renumbering event), whereas in other suddenly becomes invalid and replaced by a new prefix. In some of
scenarios it may be unable to do so. these scenarios, the local router producing the network renumbering
event may try to deprecate the currently-employed prefixes (by
explicitly signaling the network about the renumbering event),
whereas in other scenarios it may be unable to do so.
In scenarios where network configuration information related to IPv6 In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit signaling of that prefixes becomes invalid without any explicit signaling of that
condition, nodes on the local network will continue using stale condition, nodes on the local network will continue using stale
prefixes for an unacceptably long period of time, thus resulting in prefixes for an unacceptably long period of time, thus resulting in
connectivity problems. 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 is that in which a CPE 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 CPE 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 CPE router crashes and reboots, the CPE 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 actively employ the addresses prefix, but will normally retain and and may actively employ the
configured for the previously-advertised prefix, since their addresses configured for the previously-advertised prefix, since
associated Preferred Lifetime and Valid Lifetime allow them to do their associated Preferred Lifetime and Valid Lifetime allow them
so. to do so.
o A router (e.g. Customer Edge router) may advertise
autoconfiguration prefixes corresponding to prefixes learned via
DHCPv6-PD with constant PIO lifetimes that are not synchronized
with the DHCPv6-PD lease time (as required in Section 6.3 of
[RFC8415]). While this behavior violates the aforementioned
requirement from [RFC8415], it is not an unusual behavior,
particularly when e.g. DHCPv6-PD is implemented in a 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 may be moved to another
subnet (VLAN) as a result of manual switch-port reconfiguration or subnet (VLAN) as a result of manual switch-port reconfiguration or
802.1x re-authentication. In particular, there has been evidence 802.1x re-authentication. In particular, there has been evidence
that some 802.1x supplicants do not reset network settings after that some 802.1x supplicants do not reset network settings after
successful 802.1x authentication. So if a host had failed 802.1x successful 802.1x authentication. So if a host had failed 802.1x
authentication for some reason, was placed in a "quarantine" VLAN authentication for some reason, was placed in a "quarantine" VLAN
and then got successfully authenticated later on, it might end up and then got successfully authenticated later on, it might end up
having IPv6 addresses from both old ("quarantine") and new VLANs. having IPv6 addresses from both old ("quarantine") and new VLANs.
o During the planned network renumbering, a router may be configured o During the planned network renumbering, a router may be configured
to send an RA with the Preferred Lifetime for the "old" Prefix to 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 having 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 as all-hosts multicast and multicast being rather unreliable
on busy wifi networks, the RA may not be received by a host (or on busy wifi networks, the RA may not be received by a host (or
set of hosts). set of hosts).
o Automated device config management system performs periodic config o Automated device config management system performs periodic config
pushes to network devices. If such a push results in changing the pushes to network devices. In these scenarios, network devices
subnet configured on a particular network, hosts attached to that may simply immediately forget their previous configuration, rather
network would not get notified about the subnet change, and their than withdrawing it gracefully. If such a push results in
addresses from the "old" prefix will not be deprecated. A related changing the subnet configured on a particular network, hosts
scenario is the incorrect network renumbering where a network attached to that network would not get notified about the subnet
administrator renumbers a network by simply removing the "old" change, and their addresses from the "old" prefix will not be
prefix from the configuration and configuring a new prefix deprecated. A related scenario is the incorrect network
instead. renumbering where a network administrator renumbers a network by
simply removing the "old" prefix from the configuration and
configuring a new prefix instead.
Lacking any explicit signaling to deprecate the previously-advertised Lacking any explicit signaling to deprecate the previously-advertised
prefixes, hosts may continue to employ the previously-configured prefixes, hosts may continue to employ the previously-configured
addresses, which will typically result in packets being blackholed -- addresses, which will typically result in packets being blackholed --
whether because of egress-filtering by the CPE or ISP, or packets whether because of egress-filtering by the CPE or ISP, or packets
being discarded or routed elsewhere. being discarded or routed elsewhere.
We note that the default values for the "Preferred Lifetime" and We note that the default values for the "Preferred Lifetime" and
"Valid Lifetime" of PIOs, as specified in [RFC4861], are: "Valid Lifetime" of PIOs, as specified in [RFC4861], are:
skipping to change at page 4, line 26 skipping to change at page 4, line 40
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days)
This means that in the aforementioned scenarios, the stale addresses This means that in the aforementioned scenarios, the stale addresses
would be retained and also actively employed for new communications would be retained and also actively employed for new communications
instances for an unacceptably long period of time (one month, and one instances for an unacceptably long period of time (one month, and one
week, respectively), leading to interoperability problems, instead of week, respectively), leading to interoperability problems, instead of
hosts transitioning to the newly-advertised prefix(es) in a timelier hosts transitioning to the newly-advertised prefix(es) in a timelier
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 invalidate 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
skipping to change at page 5, line 47 skipping to change at page 6, line 10
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)
Many protocols, from different layers, normally employ timers. The IPv6 SLAAC employs the following default PIO lifetime values:
general logic is as follows:
o A timer is set with a value such that, under normal conditions,
the timer does *not* go off.
o Whenever a fault condition arises, the timer goes off, and the
protocol can perform fault recovery
One use of timers is when implementing reliability mechanisms where a
packet is transmitted, and, unless a response is received, a timer
will fire to trigger retransmission of the original packet.
For obvious reasons, the whole point of using timers in this way is
that, in problematic scenarios, they trigger some recovery action.
However, IPv6 SLAAC employs, for PIOs, these default 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 normal network conditions, these timers will be reset/refreshed Under problematic circumstances, such as where the corresponding
to the default values. However, under problematic circumstances, network information has become stale without any explicit signal from
such as where the corresponding network information has become stale the network (as described in Section 1), it will take a host 7 days
without any explicit signal from the network (as described in (one week) to deprecate the corresponding addresses, and 30 days (one
Section 1), it will take a host 7 days (one week) to deprecate the month) to eventually invalidate and remove any addresses configured
corresponding addresses, and 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
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 RA may
never reduce the "RemainingLifetime" to less than two hours. If never reduce the "RemainingLifetime" to less than two hours. If
the RemainingLifetime of an address is smaller than 2 hours, then the RemainingLifetime of an address is smaller than 2 hours, then
a Valid Lifetime smaller than 2 hours will be ignored. The a Valid Lifetime smaller than 2 hours will be ignored. The
skipping to change at page 7, line 21 skipping to change at page 7, line 15
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 CPE router crashes and reboots, the CPE router may
have no knowledge about the previously-advertised prefixes, and thus have no knowledge about the previously-advertised prefixes, and thus
may be unable to advertise them with appropriate lifetimes (in order may be unable to advertise them with appropriate lifetimes (in order
to deprecate them). to 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 will not lower the Valid Lifetime to any value
shorter than two hours (as per [RFC4862]). Therefore, even if a shorter than two hours (as per [RFC4862]). Therefore, even if a
SLAAC router were to explicitly signal the network about the stale SLAAC router tried to explicitly signal the network about the stale
configuration information via RAs, such signaling would be mostly configuration information via RAs, implementations compliant with
ignored. [RFC4862] would deprecate the corresponding prefixes, but would fail
to invalidate them.
NOTE:
Some implementations have been updated to honor small PIO
lifetimes values, as proposed in [I-D.ietf-6man-slaac-renum]. For
example, please see [Linux].
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 9, line 7 skipping to change at page 9, line 7
thus Rule 3 of [RFC6724] causes other configured addresses (if thus Rule 3 of [RFC6724] causes other configured addresses (if
available) to be used instead. 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
aforementioned values are an improvement over the default values suggested in this section are an improvement over the
values specified in [RFC4861], they will not lead to a timely default values specified in [RFC4861], they represent a trade-
recovery from the problem discussed in this document. off among a number of factors, including responsiveness,
possible impact on the battery life of connected devices
[RFC7772], etc. Thus, they may or may not provide sufficient
mitigation to the problem discussed in this document.
4. Future Work 4. Future Work
Improvement in Customer Edge Routers [RFC7084] such that they can Improvement in Customer Edge Routers [RFC7084] such that they can
signal the network about stale prefixes and deprecate them signal the network about stale prefixes and deprecate them
accordingly can help mitigate the problem discussed in this document accordingly can help mitigate the problem discussed in this document
for the "home network" scenario. Such work is currently being for the "home network" scenario. Such work is currently being
pursued in [I-D.ietf-v6ops-cpe-slaac-renum]. pursued in [I-D.ietf-v6ops-cpe-slaac-renum].
Improvements in the SLAAC protocol [RFC4862] and other algorithms Improvements in the SLAAC protocol [RFC4862] and other algorithms
skipping to change at page 9, line 41 skipping to change at page 9, line 44
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.
7. Acknowledgments 7. Acknowledgments
The authors would lie to thank (in alphabetical order) Mikael The authors would like to thank (in alphabetical order) Brian
Carpenter, Owen DeLong, Guillermo Gont, Philip Homburg, Warren
Kumari, Ted Lemon, Juergen Schoenwaelder, Klaas Wierenga, 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, Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou,
Uesley Correa, Owen DeLong, Gert Doering, Fernando Frediani, Steinar Uesley Correa, Owen DeLong, Gert Doering, Fernando Frediani, Steinar
Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema,
Warren Kumari, Albert Manfredi, Jordi Palet Martinez, Richard Ted Lemon, Albert Manfredi, Jordi Palet Martinez, Michael Richardson,
Patterson, Michael Richardson, Mark Smith, Tarko Tikan, and Ole Mark Smith, Tarko Tikan, and Ole Troan, for providing valuable
Troan, for providing valuable comments on comments on [I-D.gont-6man-slaac-renum], on which this document is
[I-D.gont-6man-slaac-renum], on which this document is based. 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 11, line 25 skipping to change at page 11, line 32
[I-D.gont-6man-slaac-renum] [I-D.gont-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-gont-6man-slaac- to Flash Renumbering Events", draft-gont-6man-slaac-
renum-08 (work in progress), May 2020. 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-00 (work in progress), July 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-04 (work in
progress), August 2020. progress), August 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
Lifetime values", Post to the netdev mailing-list
http://vger.kernel.org/vger-lists.html, April 2020,
<https://patchwork.ozlabs.org/project/netdev/
patch/20200419122457.GA971@archlinux-
current.localdomain/>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[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
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>.
[RIPE-690] [RIPE-690]
Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston,
J., Doering, G., Palet, J., Linkova, J., Balbinot, L., J., Doering, G., Palet, J., Linkova, J., Balbinot, L.,
Meynell, K., and L. Howard, "Best Current Operational Meynell, K., and L. Howard, "Best Current Operational
Practice for Operators: IPv6 prefix assignment for end- Practice for Operators: IPv6 prefix assignment for end-
users - persistent vs non-persistent, and what size to users - persistent vs non-persistent, and what size to
choose", RIPE 690, October 2017, 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, J., "IPv6 Deployment Survey (Residential/Household
skipping to change at page 12, line 30 skipping to change at page 13, line 4
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 Autonoma 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 Zorz
6connect 6connect
Frankovo naselje 165
Skofja Loka 4220
Slovenia
Email: jan@zorz.si Email: jan@connect.com
URI: https://www.6connect.com/
Richard Patterson Richard Patterson
Sky UK Sky UK
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
 End of changes. 24 change blocks. 
78 lines changed or deleted 99 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/