draft-ietf-v6ops-cpe-slaac-renum-01.txt   draft-ietf-v6ops-cpe-slaac-renum-02.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 Updates: 7084 (if approved) J. Zorz
Expires: September 10, 2020 Go6 Institute Intended status: Informational Go6 Institute
R. Patterson Expires: November 19, 2020 R. Patterson
Sky UK Sky UK
March 9, 2020 B. Volz
Cisco
May 18, 2020
Improving the Reaction of Customer Edge Routers to Renumbering Events Improving the Reaction of Customer Edge Routers to Renumbering Events
draft-ietf-v6ops-cpe-slaac-renum-01 draft-ietf-v6ops-cpe-slaac-renum-02
Abstract Abstract
In scenarios where network configuration information related to IPv6 In scenarios where network configuration information becomes invalid
prefixes becomes invalid without any explicit signaling of that without any explicit signaling of that condition (such as when a
condition (such as when a Customer Edge Router crashes and reboots Customer Edge Router crashes and reboots without knowledge of the
without knowledge of the previously-employed prefixes), hosts on the previously-employed configuration information), hosts on the local
local network will continue using stale prefixes for an unacceptably network will continue using stale network configuration information
long period of time, thus resulting in connectivity problems. This for an unacceptably long period of time, thus resulting in
document specifies improvements to Customer Edge Routers that help connectivity problems. This document specifies improvements to
mitigate the aforementioned problem for typical residential and small Customer Edge Routers that help mitigate the aforementioned problem
office scenarios. for typical residential and small office scenarios. This document
updates RFC7084.
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 September 10, 2020. This Internet-Draft will expire on November 19, 2020.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Improved Customer Edge Router Behavior . . . . . . . . . . . 2 2. Improved Customer Edge Router Behavior . . . . . . . . . . . 2
2.1. Interface Between DHCPv6-PD and SLAAC . . . . . . . . . . 3 2.1. Interface Between WAN-side and LAN-side . . . . . . . . . 3
2.2. Signaling Stale Configuration Information . . . . . . . . 3 2.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 2.3. Signaling Stale Configuration Information . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 3. Recommended Option Lifetimes Configuration Values . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
In scenarios where network configuration information related to IPv6 In scenarios where network configuration information becomes invalid
prefixes becomes invalid without any explicit signaling of that without any explicit signaling of that condition, nodes on the local
condition, nodes on the local network will continue using stale network will continue using stale information for an unacceptably
prefixes for an unacceptably long period of time, thus resulting in long period of time, thus resulting in connectivity problems. This
connectivity problems. This problem is documented in detail in problem is documented in detail in [I-D.ietf-v6ops-slaac-renum].
[I-D.gont-v6ops-slaac-renum].
This document specifies improvements to Customer Edge (CE) Routers This document specifies improvements to Customer Edge (CE) Routers
that help mitigate the aforementioned problem for residential or that help mitigate the aforementioned problem for residential and
small office scenarios. small office scenarios. This document updates RFC7084.
2. Improved Customer Edge Router Behavior 2. Improved Customer Edge Router Behavior
This section specifies and clarifies requirements for Customer Edge This section specifies and clarifies requirements for Customer Edge
Routers -- particularly when they advertise with Stateless Address Routers that can help mitigate the problem discussed in Section 1,
Autoconfiguration (SLAAC) [RFC4862] prefixes learned via particularly when they employ prefixes learned via DHCPv6-Prefix
DHCPv6-Prefix Delegation (DHCPv6-PD) [RFC8415] or prefixes derived Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless
from them -- that can help mitigate the problem discussed in Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on
Section 1. This would obviously make robustness dependent on the the LAN-side. The recommendations in this document help improve
Customer Edge Router (on which the user or ISP may have no control), robustness at the Customer Edge Router (on which the user or ISP may
as opposed to the host itself. have no control), and do not preclude implementation of host-side
improvements such as those specified in [I-D.gont-6man-slaac-renum].
The updated behaviour is as follows: This document specifies additional LAN-side requirements to
requirements L-1 through L-14 specified in [RFC7084]:
o CE routers MUST signal stale configuration information as o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign
specified in Section 2.2 addresses or delegate prefixes via DHCPv6 on the LAN-side,
employing lifetimes that exceed the remaining lifetimes of the
corresponding prefixes learned from the WAN-side via DHCPv6-PD.
For more details, see Section 2.1.
o CE routers MUST implement the DHCPv6-PD/SLAAC interface specified o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes
in Section 2.1 and capped DHCPv6 IA Address Option and IA Prefix Option
lifetimes, as specified in Section 2.2.
o CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE o L-17: CE routers MUST signal stale configuration information as
messages upon reboot events specified in Section 2.3.
2.1. Interface Between DHCPv6-PD and SLAAC o L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE
messages upon reboot events.
2.1. Interface Between WAN-side and LAN-side
The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information
Options (PIOs) [RFC4861] corresponding to prefixes learned via Options (PIOs) [RFC4861] corresponding to prefixes learned via
DHCPv6-PD MUST NOT span past the lease time of the DHCPv6-PD DHCPv6-PD MUST NOT span past the remaining preferred and valid
prefixes. This means that the advertised "Preferred Lifetime" and lifetimes of the corresponding DHCPv6-PD prefixes. This means that
the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be
dynamically adjusted such that they never span past the remaining
preferred and valid lifetimes of the corresponding prefixes delegated
via DHCPv6-PD on the WAN-side.
Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA
Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on
the LAN-side MUST NOT span past the remaining preferred and valid
lifetimes of the corresponding prefixes leased via DHCPv6-PD on the
WAN-side. This means that the advertised "Preferred Lifetime" and
"Valid Lifetime" MUST be dynamically adjusted such that the "Valid Lifetime" MUST be dynamically adjusted such that the
advertised lifetimes never span past the lease time of the prefixes advertised lifetimes never span past the remaining preferred and
delegated via DHCPv6-PD. valid lifetimes of the corresponding prefixes delegated to the CE
Router on the WAN-side via DHCPv6-PD.
This is in line with these existing requirements from other This document RECOMMENDS that CE Routers providing stateful address
specifications, which we reference here for clarity: configuration via DHCPv6 sets the DHCPv6 IA Address Option preferred-
lifetime to the lesser of the remaining preferred lifetime and
ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the
lesser of the remaining valid lifetime and ND_VALID_LIMIT.
o [RFC8415] specifies, in Section 6.3, that "if the delegated prefix This document RECOMMENDS that a CE Router providing DHCPv6-PD on the
or a prefix derived from it is advertised for stateless address LAN-side sets the DHCPv6 IA Prefix Option preferred-lifetime to the
autoconfiguration [RFC4862], the advertised preferred and valid lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT,
lifetimes MUST NOT exceed the corresponding remaining lifetimes of and the valid-lifetime of the same option to the lesser of the
the delegated prefix." remaining valid lifetime and ND_VALID_LIMIT.
RATIONALE: RATIONALE:
* The lifetime values employed for the "Preferred Lifetime" * The lifetime values employed for the "Preferred Lifetime"
(AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime)
should never be larger than the remaining lease time for the of SLAAC Prefix Information Options must never be larger than
corresponding prefix (as learned via DHCPv6-PD). the remaining lifetimes for the corresponding prefix (as
learned via DHCPv6-PD on the WAN-side). This is in line with
the requirement from Section 6.3 of [RFC8415], which states
that "if the delegated prefix or a prefix derived from it is
advertised for stateless address autoconfiguration [RFC4862],
the advertised preferred and valid lifetimes MUST NOT exceed
the corresponding remaining lifetimes of the delegated prefix."
* The lifetime values advertised for prefixes corresponding to a * The lifetime values of prefixes advertised on the LAN-side via
prefix leased via DHCPv6-PD should be dynamically updated SLAAC must be dynamically updated (rather than static values),
(rather than static values), since otherwise the advertised since otherwise the advertised lifetimes would eventually span
lifetimes would eventually span past the DHCPv6-PD lease time. past the DHCPv6-PD lifetimes.
2.2. Signaling Stale Configuration Information * The same considerations apply for the valid-lifetime and
preferred-lifetime of IA Address Options and IA Prefix Options
employed with DHCPv6 on the LAN-side.
In order to phase-out stale configuration information: 2.2. LAN-side Option Lifetimes
CE Routers SHOULD override the default PIO "Preferred Lifetime" and
"Valid Lifetime" values from [RFC4861], and employ shorter lifetime
values to improve the robustness to renumbering events, while
complying with the requirements from Section 2.1 of this document and
the recommendations in [RFC7772].
This document RECOMMENDS that CE router set the Router Lifetime to
ND_PREFERRED_LIMIT. This document also RECOMMENDS that the CE router
set the PIO Preferred Lifetime to the lesser of the remaining
preferred lifetime (see Section 2.1) and ND_PREFERRED_LIMIT, and the
PIO Valid Lifetime to the lesser of the remaining valid lifetime and
ND_VALID_LIMIT. Additionally, this document RECOMMENDS that the
Route Lifetime of Route Information Options (RIOs) [RFC4191], the
Lifetime of Recursive DNS Search Options (RDNSSO) [RFC8106], and the
Lifetime of DNS Search List Options (DNSSLO) [RFC8106] be set to the
lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option
(received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of
these options are included in Router Advertisement messages.
This document RECOMMENDS that a CE Router providing stateful address
configuration via DHCPv6 set the DHCPv6 IA Address Option preferred-
lifetime to the lesser of the remaining preferred lifetime (see
Section 2.1) and ND_PREFERRED_LIMIT, and the valid-lifetime of the
same option to the lesser of the remaining valid lifetime and
ND_VALID_LIMIT.
This document RECOMMENDS that a CE Router providing DHCPv6-PD on the
LAN-side set the DHCPv6 IA Prefix Option preferred-lifetime to the
lesser of the remaining preferred lifetime (see Section 2.1) and
ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the
lesser of the remaining valid lifetime and ND_VALID_LIMIT.
RATIONALE:
* The Valid Lifetime and Preferred Lifetime of PIOs have direct
impact on three different aspects:
+ The amount of time hosts may end up employing stale network
configuration information (see
[I-D.ietf-v6ops-slaac-renum]).
+ The amount of time CE Routers need to persist trying to
deprecate stale network configuration information (e.g. to
handle cases where nodes miss Router Advertisements and thus
still consider the stale information as valid).
+ The amount of information that a CE Routers need to maintain
when e.g. multiple crash-and-reboot events occur in the
timespan represented by the option lifetimes employed on the
LAN-side.
* CE Routers need not employ the (possibly long) DHCPv6-PD
lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs
sent in Router Advertisements messages to advertise sub-
prefixes of the leased prefix. Instead, CPE Routers SHOULD use
shorter values for the Valid Lifetime and Preferred Lifetime of
PIOs, since subsequent Router Advertisement messages will
nevertheless refresh the associated lifetimes, leading to the
same effective lifetimes as specified by the WAN-side DHCPv6-PD
lifetimes.
* Similarly, CE Routers need not employ the (possibly long)
DHCPv6-PD lifetimes for the valid-lifetime and preferred-
lifetime of IA Address Options and IA Prefix Option employed by
DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6
clients will lead to the same effective lifetimes as specified
by the WAN-side DHCPv6-PD lifetimes.
2.3. Signaling Stale Configuration Information
In order to phase-out stale SLAAC configuration information:
o A CE router sending RAs that advertise dynamically-learned o A CE router sending RAs that advertise dynamically-learned
prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage,
stable storage, the list of prefixes being advertised on each the list of prefixes being advertised on each network segment, and
network segment, and the "A" and "L" flags of the corresponding the state of the "A" and "L" flags of the corresponding PIOs.
PIOs.
o Upon changes to the advertised prefixes, and after bootstrapping, o Upon changes to the advertised prefixes, and after bootstrapping,
the CE router advertising prefix information via SLAAC should the CE router advertising prefix information via SLAAC SHOULD
proceed as follows: proceed as follows:
* Any prefixes that were previously advertised via Router * Any prefixes that were previously advertised via Router
Advertisement (RA) messages, but that have now become stale, Advertisement (RA) messages, but that have now become stale,
MUST be advertised with a "Valid Lifetime" and a "Preferred MUST be advertised with a "Valid Lifetime" and a "Preferred
Lifetime" set to 0, and the "A" and "L" bits unchanged. Lifetime" set to 0, and the "A" and "L" bits unchanged.
* The aforementioned advertisement SHOULD be performed for at * The aforementioned advertisement SHOULD be performed for at
least the "Valid Lifetime" previously employed for such prefix. least the "Valid Lifetime" previously employed for such prefix.
Note: If requirement L-16 (Section 2.2) is followed, the Valid
Lifetime need not be saved and the prefix can simply be
advertised for a period of ND_VALID_LIMIT.
The aforementioned improved behaviour assumes compliance with the o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid-
following existing requirements from other specifications, which we lifetime MUST advertise the corresponding sub-prefixes (as they
reference here for clarity: would be generated for the same leased prefix with a non-zero
lifetime) with a PIO with both the Preferred Lifetime and the
Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD
valid-lifetime, or for period of ND_VALID_LIMIT if the recommended
lifetimes from Section 2.2 are employed.
o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6
the delegated prefix changes (i.e., the current prefix is replaced (address assignment or prefix delegation), the following behavior be
with a new prefix without any overlapping time period), "the IPv6 implemented:
CE router MUST immediately advertise the old prefix with a
Preferred Lifetime of zero and a Valid Lifetime of either a) zero
or b) the lower of the current Valid Lifetime and two hours (which
must be decremented in real time) in a Router Advertisement
message as described in Section 5.5.3, (e) of [RFC4862]"
3. IANA Considerations o The CE Router SHOULD record, on stable storage, the DHCPv6 address
and delegated-prefix bindings corresponding to the LAN-side.
o If the CE Router finds that the prefix to be employed for address
assignment and/or prefix delegation has changed (e.g., upon a
crash-and-reboot event) or the CE Router receives DHCPv6 Prefix
Delegations with 0 lifetimes, the CE Router MUST:
* In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
lifetimes for any address assignments or prefix delegations for
the deprecated prefixes for at least the valid-lifetime
previously employed for them, or for a period of ND_VALID_LIMIT
if the recommended lifetimes from Section 2.2 are employed.
* Initiate sending Reconfigure messages (if possible - i.e.,
client requests Reconfigure support and the CE Router offers
it) to the those clients with address assignments or prefix
delegations for the deprecated prefixes.
RATIONALE:
* IPv6 network renumbering is expected to take place in a planned
manner, with old/stale prefixes being phased-out via reduced
prefix lifetimes while new prefixes (with normal lifetimes) are
introduced. However, there are a number of scenarios that may
lead to the so-called "flash-renumbering" events, where the
prefix being employed on a network suddenly becomes invalid and
replaced by a new prefix [I-D.ietf-v6ops-slaac-renum]. One of
such scenarios is that in which a DHCPv6 server employs dynamic
prefixes, and the Customer Edge Router crashes and reboots.
The requirements in this section are meant to allow Customer
Edge Routers to deprecate stale information in such scenarios.
* The recommendations in this section expand from requirement
L-13 in Section 4.3 of [RFC7084].
* Host configuring addresses via SLAAC on the local network may
employ addresses configured for the previously advertised
prefixes for at most the "Valid Lifetime" of the corresponding
PIO of the last received Router Advertisement message. Since
Router Advertisement messages may be lost or fail to be
received for various reasons, Customer Edge Routers need to try
to deprecate stale prefixes for a period of time equal to the
"Valid Lifetime" of the PIO employed when originally
advertising the prefix.
* The requirement in this section is conveyed as a "SHOULD" (as
opposed to a "MUST"), since we acknowledge that the requirement
to store information on stable storage may represent a
challenge for some implementations.
* Advertising DHCPv6-leased prefixes with zero lifetimes on the
LAN-side would handle the case where a CE Router has no stable
storage but receives the prefixes via DHCPv6 with 0 lifetimes.
3. Recommended Option Lifetimes Configuration Values
o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)
o ND_VALID_LIMIT: 5400 seconds (90 minutes)
4. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
4. Security Considerations 5. Security Considerations
This document discusses a problem that may arise in scenarios where This document discusses a problem that may arise in scenarios where
dynamic IPv6 prefixes are employed, and proposes improvements to dynamic IPv6 prefixes are employed, and proposes improvements to
Customer Edge Routers [RFC7084] to mitigate the problem for Customer Edge Routers [RFC7084] to mitigate the problem for
residential or small office scenarios. It does not introduce new residential or small office scenarios. It does not introduce new
security issues. security issues.
5. Acknowledgments 6. Acknowledgments
The authors would lie to thank (in alphabetical order) Mikael The authors would like to thank Owen DeLong, Philip Homburg, and Ted
Abrahamsson, Luis Balbinot, Tim Chown, Brian Carpenter, Owen DeLong, Lemon, for their valuable help in improving this document via
Gert Doering, Steinar Haug, Nick Hilliard, Philip Homburg, Lee successive detailed reviews.
Howard, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet
Martinez, Richard Patterson, Michael Richardson, Mark Smith, Job
Snijders, Tarko Tikan, and Ole Troan, for providing valuable comments
on [I-D.gont-6man-slaac-renum], on which this document is
based.earlier versions of this document.
Fernando would like to thank Alejandro D'Egidio and Sander Steffann The authors would like to thank Mikael Abrahamsson, Brian Carpenter,
for a discussion of these issues. Fernando would also like to thank Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Erik Kline,
Brian Carpenter who, over the years, has answered many questions and Olorunloba Olopade, Mark Smith, Job Snijders, Sander Steffann, Ole
provided valuable comments that has benefited his protocol-related Troan, Loganaden Velvindron, Timothy Winters, and Chongfeng Xie, for
work. providing valuable comments on earlier versions of this document.
6. References The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim
Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick
Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon,
Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael
Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for
providing valuable comments on [I-D.gont-6man-slaac-renum], on which
this document is based.
6.1. Normative References Fernando would also like to thank Brian Carpenter who, over the
years, has answered many questions and provided valuable comments
that has benefited his protocol-related work.
7. References
7.1. Normative References
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[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>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[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>.
6.2. Informative References 7.2. Informative References
[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-02 (work in progress), February 2020. renum-07 (work in progress), April 2020.
[I-D.gont-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-gont-v6ops-slaac-renum-02 (work Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work
in progress), February 2020. in progress), May 2020.
[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>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
skipping to change at line 264 skipping to change at page 10, line 34
Skofja Loka 4220 Skofja Loka 4220
Slovenia Slovenia
Email: jan@go6.si Email: jan@go6.si
URI: https://www.go6.si URI: https://www.go6.si
Richard Patterson Richard Patterson
Sky UK Sky UK
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
Bernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA 01719
USA
Email: volz@cisco.com
 End of changes. 40 change blocks. 
105 lines changed or deleted 295 lines changed or added

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