draft-ietf-v6ops-cpe-slaac-renum-04.txt   draft-ietf-v6ops-cpe-slaac-renum-05.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Updates: 7084 (if approved) J. Zorz Updates: 7084 (if approved) J. Zorz
Intended status: Informational 6connect Intended status: Informational 6connect
Expires: February 26, 2021 R. Patterson Expires: April 1, 2021 R. Patterson
Sky UK Sky UK
B. Volz B. Volz
Cisco Cisco
August 25, 2020 September 28, 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-04 draft-ietf-v6ops-cpe-slaac-renum-05
Abstract Abstract
In scenarios where network configuration information becomes invalid In scenarios where network configuration information becomes invalid
without any explicit signaling of that condition (such as when a without any explicit signaling of that condition (such as when a
Customer Edge Router crashes and reboots without knowledge of the Customer Edge Router crashes and reboots without knowledge of the
previously-employed configuration information), hosts on the local previously-employed configuration information), hosts on the local
network will continue using stale network configuration information network will continue using stale network configuration information
for an unacceptably long period of time, thus resulting in for an unacceptably long period of time, thus resulting in
connectivity problems. This document specifies improvements to connectivity problems. This document specifies improvements to
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 26, 2021. This Internet-Draft will expire on April 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Improved Customer Edge Router Behavior . . . . . . . . . . . 3 3. Improved Customer Edge Router Behavior . . . . . . . . . . . 3
3.1. Interface Between WAN-side and LAN-side . . . . . . . . . 4 3.1. Interface Between WAN-side and LAN-side . . . . . . . . . 4
3.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 3.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5
3.3. Signaling Stale Configuration Information . . . . . . . . 6 3.3. Signaling Stale Configuration Information . . . . . . . . 6
4. Recommended Option Lifetimes Configuration Values . . . . . . 8 4. Recommended Option Lifetimes Configuration Values . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In scenarios where network configuration information becomes invalid In scenarios where network configuration information becomes invalid
without any explicit signaling of that condition, nodes on the local without any explicit signaling of that condition, nodes on the local
network will continue using stale information for an unacceptably network will continue using stale information for an unacceptably
long period of time, thus resulting in connectivity problems. This long period of time, thus resulting in connectivity problems. This
problem is documented in detail in [I-D.ietf-v6ops-slaac-renum]. problem is documented in detail in [I-D.ietf-v6ops-slaac-renum].
This document specifies improvements to Customer Edge (CE) Routers This document specifies improvements to Customer Edge (CE) Routers
skipping to change at page 3, line 34 skipping to change at page 3, line 34
3. Improved Customer Edge Router Behavior 3. Improved Customer Edge Router Behavior
This section specifies and clarifies requirements for Customer Edge This section specifies and clarifies requirements for Customer Edge
Routers that can help mitigate the problem discussed in Section 1, Routers that can help mitigate the problem discussed in Section 1,
particularly when they employ prefixes learned via DHCPv6-Prefix particularly when they employ prefixes learned via DHCPv6-Prefix
Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless
Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on
the LAN-side. The recommendations in this document help improve the LAN-side. The recommendations in this document help improve
robustness at the Customer Edge Router (on which the user or ISP may robustness at the Customer Edge Router (on which the user or ISP may
have no control), and do not preclude implementation of host-side have no control), and do not preclude implementation of host-side
improvements such as those specified in [I-D.gont-6man-slaac-renum]. improvements such as those specified in [I-D.ietf-6man-slaac-renum].
This document specifies additional LAN-side requirements to This document specifies additional LAN-side requirements to
requirements L-1 through L-14 specified in [RFC7084]: requirements L-1 through L-14 specified in [RFC7084]:
o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign
addresses or delegate prefixes via DHCPv6 on the LAN-side, addresses or delegate prefixes via DHCPv6 on the LAN-side,
employing lifetimes that exceed the remaining lifetimes of the employing lifetimes that exceed the remaining lifetimes of the
corresponding prefixes learned from the WAN-side via DHCPv6-PD. corresponding prefixes learned from the WAN-side via DHCPv6-PD.
For more details, see Section 3.1. For more details, see Section 3.1.
skipping to change at page 4, line 29 skipping to change at page 4, line 29
Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA
Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on
the LAN-side MUST NOT span past the remaining preferred and valid the LAN-side MUST NOT span past the remaining preferred and valid
lifetimes of the corresponding prefixes leased via DHCPv6-PD on the lifetimes of the corresponding prefixes leased via DHCPv6-PD on the
WAN-side. This means that the advertised "Preferred Lifetime" and 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 remaining preferred and advertised lifetimes never span past the remaining preferred and
valid lifetimes of the corresponding prefixes delegated to the CE valid lifetimes of the corresponding prefixes delegated to the CE
Router on the WAN-side via DHCPv6-PD. Router on the WAN-side via DHCPv6-PD.
This document RECOMMENDS that CE Routers providing stateful address CE Routers providing stateful address configuration via DHCPv6 SHOULD
configuration via DHCPv6 sets the DHCPv6 IA Address Option preferred- set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
lifetime to the lesser of the remaining preferred lifetime and the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the
ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the valid-lifetime of the same option to the lesser of the remaining
lesser of the remaining valid lifetime and ND_VALID_LIMIT. valid lifetime and ND_VALID_LIMIT.
This document RECOMMENDS that a CE Router providing DHCPv6-PD on the CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6
LAN-side sets the DHCPv6 IA Prefix Option preferred-lifetime to the IA Prefix Option preferred-lifetime to the lesser of the remaining
lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of
and the valid-lifetime of the same option to the lesser of the the same option to the lesser of the remaining valid lifetime and
remaining valid lifetime and ND_VALID_LIMIT. 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)
of SLAAC Prefix Information Options must never be larger than of SLAAC Prefix Information Options must never be larger than
the remaining lifetimes for the corresponding prefix (as the remaining lifetimes for the corresponding prefix (as
learned via DHCPv6-PD on the WAN-side). This is in line with learned via DHCPv6-PD on the WAN-side). This is in line with
the requirement from Section 6.3 of [RFC8415], which states the requirement from Section 6.3 of [RFC8415], which states
that "if the delegated prefix or a prefix derived from it is that "if the delegated prefix or a prefix derived from it is
skipping to change at page 5, line 22 skipping to change at page 5, line 22
employed with DHCPv6 on the LAN-side. employed with DHCPv6 on the LAN-side.
3.2. LAN-side Option Lifetimes 3.2. LAN-side Option Lifetimes
CE Routers SHOULD override the default PIO "Preferred Lifetime" and CE Routers SHOULD override the default PIO "Preferred Lifetime" and
"Valid Lifetime" values from [RFC4861], and employ shorter lifetime "Valid Lifetime" values from [RFC4861], and employ shorter lifetime
values to improve the robustness to renumbering events, while values to improve the robustness to renumbering events, while
complying with the requirements from Section 2.1 of this document and complying with the requirements from Section 2.1 of this document and
the recommendations in [RFC7772]. the recommendations in [RFC7772].
This document RECOMMENDS that CE routers set the Router Lifetime to CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. CE
ND_PREFERRED_LIMIT. This document also RECOMMENDS that the CE router routers SHOULD also set the PIO Preferred Lifetime to the lesser of
set the PIO Preferred Lifetime to the lesser of the remaining the remaining preferred lifetime (see Section 3.1) and
preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the
PIO Valid Lifetime to the lesser of the remaining valid lifetime and remaining valid lifetime and ND_VALID_LIMIT. Additionally, the Route
ND_VALID_LIMIT. Additionally, this document RECOMMENDS that the Lifetime of Route Information Options (RIOs) [RFC4191], the Lifetime
Route Lifetime of Route Information Options (RIOs) [RFC4191], the of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime
Lifetime of Recursive DNS Search Options (RDNSSO) [RFC8106], and the of DNS Search List Options (DNSSLO) [RFC8106] SHOULD be set to 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 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 (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of
these options are included in Router Advertisement messages. these options are included in Router Advertisement messages.
This document RECOMMENDS that a CE Router providing stateful address CE Routers providing stateful address configuration via DHCPv6 SHOULD
configuration via DHCPv6 set the DHCPv6 IA Address Option preferred- set the DHCPv6 IA Address Option preferred-lifetime to the lesser of
lifetime to the lesser of the remaining preferred lifetime (see the remaining preferred lifetime (see Section 3.1) and
Section 3.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 3.1) and
ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the
lesser of the remaining valid lifetime and ND_VALID_LIMIT. lesser of the remaining valid lifetime and ND_VALID_LIMIT.
CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6
IA Prefix Option preferred-lifetime to the lesser of the remaining
preferred lifetime (see Section 3.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: RATIONALE:
* The Valid Lifetime and Preferred Lifetime of PIOs have a direct * The Valid Lifetime and Preferred Lifetime of PIOs have a direct
impact on three different aspects: impact on three different aspects:
+ The amount of time hosts may end up employing stale network + The amount of time hosts may end up employing stale network
configuration information (see configuration information (see
[I-D.ietf-v6ops-slaac-renum]). [I-D.ietf-v6ops-slaac-renum]).
+ The amount of time CE Routers need to persist trying to + The amount of time CE Routers need to persist trying to
skipping to change at page 6, line 46 skipping to change at page 6, line 46
3.3. Signaling Stale Configuration Information 3.3. Signaling Stale Configuration Information
In order to phase-out stale SLAAC 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) SHOULD record, on stable storage, prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage,
the list of prefixes being advertised on each network segment, and the list of prefixes being advertised on each network segment, and
the state of the "A" and "L" flags of the corresponding PIOs. the state of the "A" and "L" flags of the corresponding 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 proceeds as
proceed as follows: 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 3.2) is followed, the Valid Note: If requirement L-16 (Section 3.2) is followed, the Valid
Lifetime need not be saved and the prefix can simply be Lifetime need not be saved and the prefix can simply be
advertised for a period of ND_VALID_LIMIT. advertised for a period of ND_VALID_LIMIT.
o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid-
lifetime MUST advertise the corresponding sub-prefixes (as they lifetime MUST advertise the corresponding sub-prefixes (as they
would be generated for the same leased prefix with a non-zero would be generated for the same leased prefix with a non-zero
lifetime) with a PIO with both the Preferred Lifetime and the 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 set to 0, for at least the WAN-side DHCPv6-PD
valid-lifetime, or for a period of ND_VALID_LIMIT if the valid-lifetime, or for a period of ND_VALID_LIMIT if the
recommended lifetimes from Section 3.2 are employed. recommended lifetimes from Section 3.2 are employed.
This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 If a CE Router provides LAN-side DHCPv6 (address assignment or prefix
(address assignment or prefix delegation), the following behavior be delegation), then:
implemented:
o The CE Router SHOULD record, on stable storage, the DHCPv6 address o The CE Router SHOULD record, on stable storage, the DHCPv6 address
and delegated-prefix bindings corresponding to the LAN-side. and delegated-prefix bindings corresponding to the LAN-side.
o If the CE Router finds that the prefix to be employed for address 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 assignment and/or prefix delegation has changed (e.g., upon a
crash-and-reboot event) or the CE Router receives DHCPv6 Prefix crash-and-reboot event) or the CE Router receives DHCPv6 Prefix
Delegations with 0 lifetimes, the CE Router MUST: Delegations with 0 lifetimes, the CE Router MUST:
* In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0
skipping to change at page 8, line 35 skipping to change at page 8, line 35
* Advertising DHCPv6-leased prefixes with zero lifetimes on the * Advertising DHCPv6-leased prefixes with zero lifetimes on the
LAN-side would handle the case where a CE Router has no stable LAN-side would handle the case where a CE Router has no stable
storage but receives the prefixes via DHCPv6 with 0 lifetimes. storage but receives the prefixes via DHCPv6 with 0 lifetimes.
4. Recommended Option Lifetimes Configuration Values 4. Recommended Option Lifetimes Configuration Values
o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)
o ND_VALID_LIMIT: 5400 seconds (90 minutes) o ND_VALID_LIMIT: 5400 seconds (90 minutes)
RATIONALE:
These values represent a trade-off among a number of factors,
including responsiveness and possible impact on the battery life
of connected devices [RFC7772].
ND_PREFERRED_LIMIT is set according to the recommendations in
[RFC7772] for Router Lifetime, following the rationale from
Section 3.2 of [I-D.ietf-v6ops-slaac-renum].
ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some
additional leeway before configuration information is finally
discarded by the host.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Security Considerations 6. Security Considerations
This document discusses a problem that may arise in scenarios where This document discusses a problem that may arise in scenarios where
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.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Owen DeLong, Philip Homburg, and Ted The authors would like to thank Owen DeLong, Philip Homburg, and Ted
Lemon, for their valuable help in improving this document via Lemon, for their valuable help in improving this document via
successive detailed reviews. successive detailed reviews.
The authors would like to thank Mikael Abrahamsson, Brian Carpenter, The authors would like to thank Mikael Abrahamsson, Brian Carpenter,
Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Erik Kline, Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo
Warren Kumari, Olorunloba Olopade, Mark Smith, Job Snijders, Sander Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade,
Steffann, Ole Troan, Loganaden Velvindron, Timothy Winters, and Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan,
Loganaden Velvindron, Timothy Winters, Christopher Wood, and
Chongfeng Xie, for providing valuable comments on earlier versions of Chongfeng Xie, for providing valuable comments on earlier versions of
this document. this document.
The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim
Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick
Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon,
Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael
Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for
providing valuable comments on [I-D.gont-6man-slaac-renum], on which providing valuable comments on [I-D.gont-6man-slaac-renum], on which
this document is based. this document is based.
skipping to change at page 10, line 28 skipping to change at page 10, line 47
[I-D.gont-6man-slaac-renum] [I-D.gont-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC) Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-gont-6man-slaac- to Flash Renumbering Events", draft-gont-6man-slaac-
renum-08 (work in progress), May 2020. renum-08 (work in progress), May 2020.
[I-D.ietf-6man-slaac-renum] [I-D.ietf-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC) Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-ietf-6man-slaac- to Flash Renumbering Events", draft-ietf-6man-slaac-
renum-00 (work in progress), July 2020. renum-01 (work in progress), August 2020.
[I-D.ietf-v6ops-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-02 (work Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work
in progress), May 2020. in progress), August 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 page 11, line 4 skipping to change at page 11, line 26
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks SI6 Networks
Segurola y Habana 4310, 7mo Piso Segurola y Habana 4310, 7mo Piso
Villa Devoto, Ciudad Autonoma de Buenos Aires Villa Devoto, Ciudad Autonoma de Buenos Aires
Argentina Argentina
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: https://www.si6networks.com URI: https://www.si6networks.com
Jan Zorz Jan Zorz
6connect 6connect
Email: jan@zorz.si Email: jan@connect.com
URI: https://www.6connect.com/
Richard Patterson Richard Patterson
Sky UK Sky UK
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
Bernie Volz Bernie Volz
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
 End of changes. 20 change blocks. 
51 lines changed or deleted 62 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/