draft-ietf-6man-slaac-renum-01.txt   draft-ietf-6man-slaac-renum-02.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Updates: 4861, 4862 (if approved) J. Zorz Updates: 4861, 4862 (if approved) J. Zorz
Intended status: Standards Track 6connect Intended status: Standards Track 6connect
Expires: February 27, 2021 R. Patterson Expires: July 23, 2021 R. Patterson
Sky UK Sky UK
August 26, 2020 January 19, 2021
Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) Improving the Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events to Flash Renumbering Events
draft-ietf-6man-slaac-renum-01 draft-ietf-6man-slaac-renum-02
Abstract Abstract
In renumbering scenarios where an IPv6 prefix suddenly becomes In renumbering scenarios where an IPv6 prefix suddenly becomes
invalid, hosts on the local network will continue using stale invalid, hosts 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. This document improves the reaction of IPv6 connectivity problems. This document improves the reaction of IPv6
Stateless Address Autoconfiguration to such renumbering scenarios. Stateless Address Autoconfiguration to such renumbering scenarios.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 27, 2021. This Internet-Draft will expire on July 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4 3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4
3.1. Renumbering without Explicit Signaling . . . . . . . . . 4 3.1. Renumbering without Explicit Signaling . . . . . . . . . 4
3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5 3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5
4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6 4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6
4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7 4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7
4.1.1. Router Configuration Variables . . . . . . . . . . . 7 4.1.1. Router Configuration Variables . . . . . . . . . . . 7
4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7 4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 8
4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7 4.3. Interface Initialization . . . . . . . . . . . . . . . . 9
4.3. Interface Initialization . . . . . . . . . . . . . . . . 8
4.4. Conveying Information in Router Advertisement (RA) 4.4. Conveying Information in Router Advertisement (RA)
Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 Messages . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Recovery from Stale Configuration Information without 4.5. Recovery from Stale Configuration Information without
Explicit Signaling . . . . . . . . . . . . . . . . . . . 8 Explicit Signaling . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 10
6.1.1. Router Configuration Variables . . . . . . . . . . . 9 6.1.1. Router Configuration Variables . . . . . . . . . . . 10
6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 11
6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10 6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10 6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 11
6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10
6.3. Conveying Information in Router Advertisement (RA) 6.3. Conveying Information in Router Advertisement (RA)
Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 Messages . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Recovery from Stale Configuration Information without 6.4. Recovery from Stale Configuration Information without
Explicit Signaling . . . . . . . . . . . . . . . . . . . 10 Explicit Signaling . . . . . . . . . . . . . . . . . . . 11
6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 11
6.5. Other mitigations implemented in products . . . . . . . . 11 6.5. Other mitigations implemented in products . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15 Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 16
A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15 A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 16
A.2. On a Possible Improvement to Source Address Selection . . 16 A.2. On a Possible Improvement to Source Address Selection . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
IPv6 network renumbering is expected to take place in a planned IPv6 network renumbering is expected to take place in a planned
manner, with old/stale prefixes being phased-out via reduced prefix manner, with old/stale prefixes being phased-out via reduced prefix
lifetimes while new prefixes (with normal lifetimes) are introduced. lifetimes while new prefixes (with normal lifetimes) are introduced.
However, there are a number of scenarios that may lead to the so- However, there are a number of scenarios that may lead to the so-
called "flash-renumbering" events, where the prefix being employed on called "flash-renumbering" events, where the prefix being employed on
a network suddenly becomes invalid and replaced by a new prefix a network suddenly becomes invalid and replaced by a new prefix
skipping to change at page 4, line 48 skipping to change at page 4, line 48
7 days or 30 days (respectively) to recover from a network problem is 7 days or 30 days (respectively) to recover from a network problem is
simply unacceptable. simply unacceptable.
Use of more appropriate timers in Router Advertisement messages can Use of more appropriate timers in Router Advertisement messages can
help limit the amount of time that hosts will maintain stale help limit the amount of time that hosts will maintain stale
configuration information. Additionally, hosts are normally in a configuration information. Additionally, hosts are normally in a
position to infer that a prefix has become stale -- for example, if a position to infer that a prefix has become stale -- for example, if a
given router ceases to advertise an existing prefix and at the same given router ceases to advertise an existing prefix and at the same
time starts to advertise a new prefix. time starts to advertise a new prefix.
Section 4.1.1 recommends the use of more appropriate lifetimes for Section 4.1.1 recommends the use of more appropriate default
PIOs, while Section 4.1.2 proposes to cap the accepted Valid Lifetime lifetimes for PIOs, while Section 4.5 specifies a local policy that
and Preferred Lifetime values at hosts, such that more appropriate SLAAC hosts can implement to heuristically infer that network
values are employed even in the presence of legacy routers. configuration information has changed, such that stale configuration
information can be phased out.
Section 4.5 specifies a local policy that SLAAC hosts can implement
to heuristically infer that network configuration information has
changed, such that stale configuration information can be phased out.
3.2. Renumbering with Explicit Signaling 3.2. Renumbering with Explicit Signaling
In scenarios where a local router is aware about the renumbering In scenarios where a local router is aware about the renumbering
event, it may try to phase out the stale network configuration event, it may try to phase out the stale network configuration
information. In these scenarios, there are two aspects to be information. In these scenarios, there are two aspects to be
considered: considered:
o The amount of time during which the router should continue trying o The amount of time during which the router should continue trying
to deprecate the stale network configuration information to deprecate the stale network configuration information
skipping to change at page 6, line 31 skipping to change at page 6, line 28
aforementioned updates are mostly orthogonal, and mitigate different aforementioned updates are mostly orthogonal, and mitigate different
aspects of SLAAC that prevent a timely reaction to flash renumbering aspects of SLAAC that prevent a timely reaction to flash renumbering
events. events.
o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs
(Section 4.1.1): (Section 4.1.1):
This helps limit the amount of time a host will employ stale This helps limit the amount of time a host will employ stale
information, and also limits the amount of time a router needs to information, and also limits the amount of time a router needs to
try to obsolete stale information. try to obsolete stale information.
o Cap the received Valid Lifetime and Preferred Lifetime of PIOs
(Section 4.1.2):
This helps limit the amount of time a host will employ stale
information, even in the presence of legacy ([RFC4861]) routers.
o Honor PIOs with small Valid Lifetimes (Section 4.2): o Honor PIOs with small Valid Lifetimes (Section 4.2):
This allows routers to invalidate stale prefixes, since otherwise This allows routers to invalidate stale prefixes, since otherwise
[RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime [RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime
smaller than two hours. smaller than two hours.
o Recommend routers to retransmit configuration information upon o Recommend routers to retransmit configuration information upon
interface initialization/reinitialization (Section 4.3): interface initialization/reinitialization (Section 4.3):
This helps spread the new information in a timelier manner, and This helps spread the new information in a timelier manner, and
also deprecate stale information via host-side heuristics (see also deprecate stale information via host-side heuristics (see
Section 4.5). Section 4.5).
skipping to change at page 7, line 18 skipping to change at page 7, line 9
o Infer stale network configuration information from received RAs o Infer stale network configuration information from received RAs
(Section 4.5): (Section 4.5):
This allows hosts to deprecate stale network configuration This allows hosts to deprecate stale network configuration
information, even in the absence of explicit signaling. information, even in the absence of explicit signaling.
4.1. More Appropriate Lifetime Values 4.1. More Appropriate Lifetime Values
4.1.1. Router Configuration Variables 4.1.1. Router Configuration Variables
[TBD] The default values of the Preferred Lifetime and the Valid Lifetime
of PIOs are updated as follows:
4.1.2. Processing of PIO Lifetimes at Hosts AdvPreferredLifetime: max(AdvDefaultLifetime, 3 *
MaxRtrAdvInterval)
[TBD] AdvValidLifetime: 2 * AdvPreferredLifetime
where:
AdvPreferredLifetime:
Value to be placed in the "Preferred Lifetime" field of the PIO.
AdvValidLifetime:
Value to be placed in the "Valid Lifetime" field of the PIO.
AdvDefaultLifetime:
Value to be placed in the "Router Lifetime" field of the Router
Advertisement message that will carry the PIO.
max():
A function that computes the maximum of its arguments.
NOTE:
[RFC4861] specifies the default value of MaxRtrAdvInterval as 600
seconds, and the default value of AdvDefaultLifetime as 3 *
MaxRtrAdvInterval. Therefore, when employing default values for
MaxRtrAdvInterval and AdvDefaultLifetime, the default values of
AdvPreferredLifetime and AdvValidLifetime become 1800 seconds (30
minutes) and 3600 seconds (1 one hour), respectively. We note
that when implementing BCP202 [RFC7772], AdvDefaultLifetime will
typically be in the range of 45-90 minutes, and therefore the
default value of AdvPreferredLifetime will be in the range 45-90
minutes, while the default value of AdvValidLifetime will be in
the range of 90-180 minutes.
RATIONALE:
* The default values of the PIO lifetimes should be such that,
under normal circumstances (including some packet loss), the
associated timers are refreshed/reset, but in the presence of
network failures (such as network configuration information
becoming stale), some fault recovering action (such as
deprecating the corresponding addresses and subsequently
removing them) is triggered.
* In the context of [RFC8028], where it is clear that the use of
addresses configured for a given prefix is tied to the next-hop
router that advertised the prefix, the "Preferred Lifetime" of
a PIO should not be larger than the "Router Lifetime" of Router
Advertisement messages. Some leeway should be provided for the
"Valid Lifetime" of PIOs, to cope with transient network
problems. As a result, this document updates [RFC4861] such
that the default Valid Lifetime (AdvValidLifetime) and the
default Preferred Lifetime (AdvPreferredLifetime) of PIOs are
specified as a function of the "Router Lifetime"
(AdvDefaultLifetime) of Router Advertisement messages. In the
absence of RAs that refresh information, addresses configured
for previously-advertised prefixes become deprecated in a
timelier manner, and thus Rule 3 of [RFC6724] will cause other
configured addresses (if available) to be preferred.
* The expression above computes the maximum between
AdvDefaultLifetime and "3 * MaxRtrAdvInterval" (the default
value of AdvDefaultLifetime, as per [RFC4861]) to cope with the
case where an operator might simply want to disable one local
router for maintenance, without disabling the use of the
corresponding prefixes on the local network (e.g., on a multi-
router network). [RFC4862] implementations would otherwise
deprecate the corresponding prefixes. Similarly, [RFC8028]
implementations would likely behave in the same way.
4.2. Honor Small PIO Valid Lifetimes 4.2. Honor Small PIO Valid Lifetimes
The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is
replaced with the following text: replaced with the following text:
e) If the advertised prefix is equal to the prefix of an address e) If the advertised prefix is equal to the prefix of an address
configured by stateless autoconfiguration in the list, the valid configured by stateless autoconfiguration in the list, the valid
lifetime and the preferred lifetime of the address should be lifetime and the preferred lifetime of the address should be
updated by processing the Valid Lifetime and the Preferred updated by processing the Valid Lifetime and the Preferred
Lifetime (respectively) in the received advertisement. Lifetime (respectively) in the received advertisement.
NOTE:
"Processing" the Valid Lifetime and Preferred Lifetime includes
capping the received values as specified in Section 4.1.2 of this
document.
RATIONALE: RATIONALE:
* This change allows hosts to react to the information provided * This change allows hosts to react to the information provided
by a router that has positive knowledge that a prefix has by a router that has positive knowledge that a prefix has
become invalid. become invalid.
* The behavior described in RFC4862 had been incorporated during * The behavior described in RFC4862 had been incorporated during
the revision of the original IPv6 Stateless Address the revision of the original IPv6 Stateless Address
Autoconfiguration specification ([RFC1971]). At the time, the Autoconfiguration specification ([RFC1971]). At the time, the
IPNG working group decided to mitigate the attack vector IPNG working group decided to mitigate the attack vector
skipping to change at page 9, line 44 skipping to change at page 11, line 4
6.1.1.2. radvd(8) 6.1.1.2. radvd(8)
The radvd(8) daemon [radvd], normally employed by Linux-based router The radvd(8) daemon [radvd], normally employed by Linux-based router
implementations, currently employs different default lifetimes than implementations, currently employs different default lifetimes than
those recommended in [RFC4861]. radvd(8) employs the following those recommended in [RFC4861]. radvd(8) employs the following
default values [radvd.conf]: default values [radvd.conf]:
o Preferred Lifetime: 14400 seconds (4 hours) o Preferred Lifetime: 14400 seconds (4 hours)
o Valid Lifetime: 86400 seconds (1 day) o Valid Lifetime: 86400 seconds (1 day)
This is not following the specific recommendation in this document, This is not following the specific recommendation in this document,
bu is already a deviation from the current standards. bu is already a deviation from the current standards.
6.1.2. Processing of PIO Lifetimes at Hosts
6.1.2.1. NetworkManager
NetworkManager [NetworkManager], user-space SLAAC implementation
employed by some Linux-based operating systems (such as Fedora or
Ubuntu), caps the lifetimes of the received PIOs as recommended in
this document.
6.1.2.2. slaacd(8)
slaacd(8) [slaacd], a user-space SLAAC implementation employed by
OpenBSD, caps the lifetimes of the received PIOs as recommended in
this document.
6.1.2.3. systemd-networkd
systemd-networkd [systemd], a user-space SLAAC implementation
employed by some Linux-based operating systems, caps the lifetimes of
the received PIOs as recommended in this document.
6.2. Honor Small PIO Valid Lifetimes 6.2. Honor Small PIO Valid Lifetimes
6.2.1. Linux Kernel 6.2.1. Linux Kernel
A Linux kernel implementation of this document has been committed to A Linux kernel implementation of this document has been committed to
the net-next tree. The implementation was produced in April 2020 by the net-next tree. The implementation was produced in April 2020 by
Fernando Gont <fgont@si6networks.com>. The corresponding patch can Fernando Gont <fgont@si6networks.com>. The corresponding patch can
be found at: <https://patchwork.ozlabs.org/project/netdev/ be found at: <https://patchwork.ozlabs.org/project/netdev/
patch/20200419122457.GA971@archlinux-current.localdomain/> patch/20200419122457.GA971@archlinux-current.localdomain/>
skipping to change at page 11, line 36 skipping to change at page 12, line 20
o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3
of [RFC4862] (discussed in Section 4.2 of this document), upon of [RFC4862] (discussed in Section 4.2 of this document), upon
first occurrence of a stale prefix, this implementation will first occurrence of a stale prefix, this implementation will
employ a decreasing Valid Lifetime, starting from 2 hours (7200 employ a decreasing Valid Lifetime, starting from 2 hours (7200
seconds), as opposed to a Valid Lifetime of 0. seconds), as opposed to a Valid Lifetime of 0.
7. Security Considerations 7. Security Considerations
The protocol update in Section 4.2 could allow an on-link attacker to The protocol update in Section 4.2 could allow an on-link attacker to
perform a Denial of Service attack againts local hosts, by sending a perform a Denial of Service attack against local hosts, by sending a
forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of
that packet, local hosts would invalidate the corresponding prefix, that packet, local hosts would invalidate the corresponding prefix,
and therefore remove any addresses configured for that prefix, and therefore remove any addresses configured for that prefix,
possibly terminating e.g. TCP connections employing such addresses. possibly terminating e.g. TCP connections employing such addresses.
However, an attacker may achieve similar effects via a number for ND- However, an attacker may achieve similar effects via a number for ND-
based attack vectors, such as directing traffic to a non-existing based attack vectors, such as directing traffic to a non-existing
node until ongoing TCP connections time out, or performing a ND-based node until ongoing TCP connections time out, or performing a ND-based
man-in-the-middle (MITM) attack and subsequently forging TCP RST man-in-the-middle (MITM) attack and subsequently forging TCP RST
segments to cause on-going TCP connections to be aborted. Thus, for segments to cause on-going TCP connections to be aborted. Thus, for
all practical purposes, this attack vector does not really represent all practical purposes, this attack vector does not really represent
skipping to change at page 12, line 29 skipping to change at page 13, line 13
Homburg. Homburg.
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, which led to the publication of for a discussion of these issues, which led to the publication of
[I-D.ietf-v6ops-slaac-renum], and eventually to this document. [I-D.ietf-v6ops-slaac-renum], and eventually to this document.
Fernando would also like to thank Brian Carpenter who, over the Fernando would also like to thank Brian Carpenter who, over the
years, has answered many questions and provided valuable comments years, has answered many questions and provided valuable comments
that has benefited his protocol-related work. that has benefited his protocol-related work.
The problem discussed in this document has been previously documented
by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update],
and also in [RIPE-690].
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
skipping to change at page 13, line 10 skipping to change at page 13, line 36
[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>.
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries", "Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/info/rfc8190>. <https://www.rfc-editor.org/info/rfc8190>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
9.2. Informative References 9.2. Informative References
[dhcpcd] Marples, R., "dhcpcd - a DHCP client", [dhcpcd] Marples, R., "dhcpcd - a DHCP client",
<https://roy.marples.name/projects/dhcpcd/>. <https://roy.marples.name/projects/dhcpcd/>.
[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, <https://www.si6networks.com/2016/02/16/quiz-weird- 2016, <https://www.si6networks.com/2016/02/16/quiz-weird-
ipv6-traffic-on-the-local-network-updated-with-solution/>. ipv6-traffic-on-the-local-network-updated-with-solution/>.
[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-06 (work in
progress), August 2020. progress), December 2020.
[I-D.ietf-v6ops-slaac-renum] [I-D.ietf-v6ops-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Reaction of Gont, F., Zorz, J., and R. Patterson, "Reaction of
Stateless Address Autoconfiguration (SLAAC) to Flash- Stateless Address Autoconfiguration (SLAAC) to Flash-
Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work
in progress), August 2020. in progress), November 2020.
[I-D.linkova-6man-default-addr-selection-update]
Linkova, J., "Default Address Selection and Subnet
Renumbering", draft-linkova-6man-default-addr-selection-
update-00 (work in progress), March 2017.
[IPNG-minutes] [IPNG-minutes]
IETF, "IPNG working group (ipngwg) Meeting Minutes", IETF, "IPNG working group (ipngwg) Meeting Minutes",
Proceedings of the thirty-eightt Internet Engineering Task Proceedings of the thirty-eightt Internet Engineering Task
Force , April 1997, <https://www.ietf.org/ Force , April 1997, <https://www.ietf.org/
proceedings/38/97apr-final/xrtftr47.htm>. proceedings/38/97apr-final/xrtftr47.htm>.
[NetworkManager] [NetworkManager]
NetworkManager, "NetworkManager web site", NetworkManager, "NetworkManager web site",
<https://wiki.gnome.org/Projects/NetworkManager>. <https://wiki.gnome.org/Projects/NetworkManager>.
skipping to change at page 15, line 20 skipping to change at page 15, line 44
[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>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router [RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, Advertisement Guard (RA-Guard)", RFC 7113,
DOI 10.17487/RFC7113, February 2014, DOI 10.17487/RFC7113, February 2014,
<https://www.rfc-editor.org/info/rfc7113>. <https://www.rfc-editor.org/info/rfc7113>.
[RIPE-690]
Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston,
J., Doering, G., Palet, J., Linkova, J., Balbinot, L.,
Meynell, K., and L. Howard, "Best Current Operational
Practice for Operators: IPv6 prefix assignment for end-
users - persistent vs non-persistent, and what size to
choose", RIPE 690, October 2017,
<https://www.ripe.net/publications/docs/ripe-690>.
[slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)", [slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)",
<https://cvsweb.openbsd.org/src/usr.sbin/slaacd/>. <https://cvsweb.openbsd.org/src/usr.sbin/slaacd/>.
[systemd] systemd, "systemd web site", <https://systemd.io/>. [systemd] systemd, "systemd web site", <https://systemd.io/>.
Appendix A. Analysis of Some Suggested Workarounds Appendix A. Analysis of Some Suggested Workarounds
[This section is to be removed before publication of this document as [This section is to be removed before publication of this document as
an RFC]. an RFC].
 End of changes. 27 change blocks. 
97 lines changed or deleted 110 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/