draft-ietf-v6ops-slaac-renum-02.txt   draft-ietf-v6ops-slaac-renum-03.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: November 6, 2020 Go6 Institute Expires: February 26, 2021 6connect
R. Patterson R. Patterson
Sky UK Sky UK
May 5, 2020 August 25, 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-02 draft-ietf-v6ops-slaac-renum-03
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 period of continue using stale prefixes for an unacceptably long time, thus
time, thus resulting in connectivity problems. This document resulting in connectivity problems. This document documents this
documents this problem, and discusses operational workarounds that issue and discusses operational workarounds that may help to improve
may help to improve network robustness. Additionally, it highlights network robustness. Additionally, it highlights areas where further
areas where further work may be needed. 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 November 6, 2020. This Internet-Draft will expire on February 26, 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 43 skipping to change at page 2, line 43
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
IPv6 largely assumes prefix stability, with network renumbering only IPv6 largely assumes prefix stability, with network renumbering only
taking place in a planned manner, with old/stale prefixes being taking place in a planned manner, with old/stale prefixes being
phased-out via reduced prefix lifetimes, and new prefixes (with phased-out via reduced prefix lifetimes, and new prefixes (with
longer lifetimes) being introduced at the same time. However, there longer lifetimes) being introduced at the same time. However, there
are a number of scenarios that may lead to the so-called "flash- are several scenarios that may lead to the so-called "flash-
renumbering" events, where the prefix employed by a network suddenly renumbering" events, where the prefix employed by a network suddenly
becomes invalid and replaced by a new prefix. In some of these becomes invalid and replaced by a new prefix. In some of these
scenarios, the local router producing the network renumbering event scenarios, the local router producing the network renumbering event
may try to deprecate the currently-employed prefixes (by explicitly may try to deprecate the currently-employed prefixes (by explicitly
signaling the network about the renumbering event), whereas in other signaling the network about the renumbering event), whereas in other
scenarios it may be unable to do so. 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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 be scenarios where the CPE router crashes and reboots, the CPE may
leased (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 normally 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 actively employ the addresses
configured for the previously-advertised prefix, since their configured for the previously-advertised prefix, since their
associated Preferred Lifetime and Valid Lifetime allow them to do associated Preferred Lifetime and Valid Lifetime allow them to do
so. so.
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 periodical o Automated device config management system performs periodic config
config push to network devices. If such a push results in pushes to network devices. If such a push results in changing the
changing the /64 subnet configured on a particular network, hosts subnet configured on a particular network, hosts attached to that
attached to that network would not get notified about the subnet network would not get notified about the subnet change, and their
change and their addresses from the "old" prefix will not addresses from the "old" prefix will not be deprecated. A related
deprecated. A related scenario is the incorrect network scenario is the incorrect network renumbering where a network
renumbering where a network administrator renumbers a network by administrator renumbers a network by simply removing the "old"
simply removing the "old" prefix from the configuration and prefix from the configuration and configuring a new prefix
configuring a new prefix instead. instead.
Lacking any explicit signaling to "deprecate" the previously-
advertised prefixes, hosts may continue to employ the previously-
configured addresses which will typically result in packets being
blackholed -- whether because of egress-filtering by the CPE or ISP,
or because responses to such packets be discarded or routed
elsewhere.
We note that the default values for the "Valid Lifetime" and Lacking any explicit signaling to deprecate the previously-advertised
"Preferred Lifetime" of PIOs, as specified in [RFC4861], are: prefixes, hosts may continue to employ the previously-configured
addresses, which will typically result in packets being blackholed --
whether because of egress-filtering by the CPE or ISP, or packets
being discarded or routed elsewhere.
o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 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 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 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 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 invalidate 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 timelier 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 notified of their occurrence.
However, for robustness reasons it is also paramount for hosts to be However, for robustness reasons, it is paramount for hosts to be able
able to recover from stale configuration information even when these to recover from stale configuration information even when these
flash-renumbering events occur and the network is unable to flash-renumbering events occur and the network is unable to
explicitly notify hosts about such condition. explicitly notify hosts about such conditions.
Section 2 analysis 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 better 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 problem discussed in this document As noted in Section 1, the problems discussed in this document are
exacerbated by a number of different parameters and behaviours. Each exacerbated by the default values of some protocol parameters and
of the following sections analyze each of them in detail. other factors. The following sections analyze each of them in
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 the residential or small office scenario, the problem discussed in
this document would be avoided if DHCPv6-PD would lease "stable" 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
skipping to change at page 5, line 35 skipping to change at page 5, line 36
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.
The authors of this document understand that, for a number of reasons For a number of reasons (such as the ones stated above), IPv6
(such as the ones stated above), IPv6 deployments may employ dynamic deployments may employ dynamic prefixes (even at the expense of the
prefixes (even at the expense of the issues discussed in this issues discussed in this document), and that there might be scenarios
document), and that there might be scenarios in which the dynamics of in which the dynamics of a network are such that the network exhibits
a network are such that the network exhibits the behaviour of dynamic the behaviour of dynamic prefixes. Rather than trying to regulate
prefixes. Rather than trying to regulate how operators may run their how operators may run their networks, this document aims at improving
networks, this document aims at improving network robustness in the network robustness in the deployed Internet.
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 Many protocols, from different layers, normally employ timers. The
general logic is as follows: general logic is as follows:
o A timer is set with a value such that, under normal conditions, o A timer is set with a value such that, under normal conditions,
the timer does *not* go off. the timer does *not* go off.
o Whenever a fault condition arises, the timer goes off, and the o Whenever a fault condition arises, the timer goes off, and the
protocol can perform fault recovery protocol can perform fault recovery
One common example for the use of timers is when implementing One use of timers is when implementing reliability mechanisms where a
reliability mechanisms where a packet is transmitted, and unless a packet is transmitted, and, unless a response is received, a timer
response is received, a retransmission timer will go off to trigger will fire to trigger retransmission of the original packet.
retransmission of the original packet.
For obvious reasons, the whole point of using timers is that in For obvious reasons, the whole point of using timers in this way is
problematic scenarios, they will go off, and trigger some recovery that, in problematic scenarios, they trigger some recovery action.
action.
However, IPv6 SLAAC employs, for PIOs, these default values: 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 normal network conditions, these timers will be reset/refreshed
to the default values. However, under problematic circumstances such to the default values. However, under problematic circumstances,
as where the corresponding network information has become stale such as where the corresponding network information has become stale
without any explicit signal from the network (as described in without any explicit signal from the network (as described in
Section 1), it will take a host 7 days (one week) to deprecate the Section 1), it will take a host 7 days (one week) to deprecate the
corresponding addresses, and 30 days (one month) to eventually corresponding addresses, and 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.
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
Preferred Lifetime of an address can be reduced to any value to Preferred Lifetime of an address can be reduced to any value to
avoid the use of a stale prefix to be employed for new avoid using a stale prefix for new communications.
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), such that there is explicit Lifetime" and "Valid Lifetime" set to 0). This would provide
signaling to SLAAC hosts to remove the stale information (including explicit signaling to SLAAC hosts to remove the stale information
configured addresses and routes). However, in scenarios such as when (including configured addresses and routes). However, in scenarios
a CPE router crashes and reboots, the CPE router may have no such as when a CPE router crashes and reboots, the CPE router may
knowledge about the previously-advertised prefixes, and thus may be have no knowledge about the previously-advertised prefixes, and thus
unable to advertise them with appropriate lifetimes (in order to may be unable to advertise them with appropriate lifetimes (in order
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 were to explicitly signal the network about the stale
configuration information via RAs, such signaling would be mostly configuration information via RAs, such signaling would be mostly
ignored. ignored.
2.5. Interaction Between DHCPv6-PD and SLAAC 2.5. Interaction Between DHCPv6-PD and SLAAC
skipping to change at page 8, line 17 skipping to change at page 8, line 17
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 (including some packet loss), the timers
will be refreshed/reset, but in the presence of network faults (such will be refreshed/reset, but in the presence of network faults (such
as network configuration information becoming stale without explicit as network configuration information becoming stale without explicit
signaling), the timers go off and trigger some fault recovering signaling), the timers go off and trigger some fault recovering
action (such as deprecating the corresponding addresses and action (such as deprecating the corresponding addresses and
subsequently invalidating/removing them). subsequently invalidating/removing them).
The following router configuration variables (corresponding to the The following router configuration variables from [RFC4861]
"lifetime" parameters in PIOs) could be overridden as follows: (corresponding to the "lifetime" parameters of PIOs) could be
overridden as follows:
AdvValidLifetime: 48 * AdvDefaultLifetime (86400 seconds) AdvPreferredLifetime: 2700 seconds (45 minutes)
AdvPreferredLifetime: AdvDefaultLifetime (1800 seconds) AdvValidLifetime: 5400 seconds (90 minutes)
NOTES: NOTES:
A CPE router advertising a sub-prefix of a prefixed leased via A CPE router advertising a sub-prefix of a prefixed 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. 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.
skipping to change at page 9, line 21 skipping to change at page 9, line 22
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
such as "Default Address Selection for IPv6" [RFC6724] would help such as "Default Address Selection for IPv6" [RFC6724] would help
improve network robustness. Such work is currently being pursued in improve network robustness. Such work is currently being pursued in
[I-D.gont-6man-slaac-renum]. [I-D.ietf-6man-slaac-renum].
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 actions for IANA.
6. Security Considerations 6. Security Considerations
skipping to change at page 9, line 44 skipping to change at page 9, line 45
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 lie 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,
Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael Warren Kumari, Albert Manfredi, Jordi Palet Martinez, Richard
Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for providing Patterson, Michael Richardson, Mark Smith, Tarko Tikan, and Ole
valuable comments on [I-D.gont-6man-slaac-renum], on which this Troan, for providing valuable comments on
document is based. [I-D.gont-6man-slaac-renum], on which this 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 has 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
[I-D.linkova-6man-default-addr-selection-update], authored by Jen [I-D.linkova-6man-default-addr-selection-update], authored by Jen
Linkova. Linkova.
8. References 8. References
skipping to change at page 10, line 47 skipping to change at page 10, line 48
[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 8.2. Informative References
[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 Blog, February
2016, <http://blog.si6networks.com/2016/02/quiz-weird- 2016, <https://www.si6networks.com/2016/02/16/quiz-weird-
ipv6-traffic-on-local-network.html>. ipv6-traffic-on-the-local-network-updated-with-solution/>.
[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] [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-07 (work in progress), April 2020. renum-08 (work in progress), May 2020.
[I-D.ietf-v6ops-cpe-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
Reaction of Customer Edge Routers to Renumbering Events", Robustness of Stateless Address Autoconfiguration (SLAAC)
draft-ietf-v6ops-cpe-slaac-renum-01 (work in progress), to Flash Renumbering Events", draft-ietf-6man-slaac-
March 2020. renum-00 (work in progress), July 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-04 (work in
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.
[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>.
skipping to change at page 12, line 32 skipping to change at page 12, line 32
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
Go6 Institute 6connect
Frankovo naselje 165 Frankovo naselje 165
Skofja Loka 4220 Skofja Loka 4220
Slovenia Slovenia
Email: jan@go6.si Email: jan@zorz.si
URI: https://www.go6.si 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. 38 change blocks. 
89 lines changed or deleted 92 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/