draft-ietf-v6ops-cpe-slaac-renum-03.txt   draft-ietf-v6ops-cpe-slaac-renum-04.txt 
IPv6 Operations Working Group (v6ops) F. Gont IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft SI6 Networks Internet-Draft SI6 Networks
Updates: 7084 (if approved) J. Zorz Updates: 7084 (if approved) J. Zorz
Intended status: Informational Go6 Institute Intended status: Informational 6connect
Expires: November 28, 2020 R. Patterson Expires: February 26, 2021 R. Patterson
Sky UK Sky UK
B. Volz B. Volz
Cisco Cisco
May 27, 2020 August 25, 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-03 draft-ietf-v6ops-cpe-slaac-renum-04
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 November 28, 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 5, line 7 skipping to change at page 5, line 7
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
advertised for stateless address autoconfiguration [RFC4862], advertised for stateless address autoconfiguration [RFC4862],
the advertised preferred and valid lifetimes MUST NOT exceed the advertised preferred and valid lifetimes MUST NOT exceed
the corresponding remaining lifetimes of the delegated prefix." the corresponding remaining lifetimes of the delegated prefix."
* The lifetime values of prefixes advertised on the LAN-side via * The lifetime values of prefixes advertised on the LAN-side via
SLAAC must be dynamically updated (rather than static values), SLAAC must be dynamically updated (rather than static values),
since otherwise the advertised lifetimes would eventually span otherwise the advertised lifetimes would eventually span past
past the DHCPv6-PD lifetimes. the DHCPv6-PD lifetimes.
* The same considerations apply for the valid-lifetime and * The same considerations apply for the valid-lifetime and
preferred-lifetime of IA Address Options and IA Prefix Options preferred-lifetime of IA Address Options and IA Prefix Options
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 router set the Router Lifetime to This document RECOMMENDS that CE routers set the Router Lifetime to
ND_PREFERRED_LIMIT. This document also RECOMMENDS that the CE router ND_PREFERRED_LIMIT. This document also RECOMMENDS that the CE router
set the PIO Preferred Lifetime to the lesser of the remaining set the PIO Preferred Lifetime to the lesser of the remaining
preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the
PIO Valid Lifetime to the lesser of the remaining valid lifetime and PIO Valid Lifetime to the lesser of the remaining valid lifetime and
ND_VALID_LIMIT. Additionally, this document RECOMMENDS that the ND_VALID_LIMIT. Additionally, this document RECOMMENDS that the
Route Lifetime of Route Information Options (RIOs) [RFC4191], the Route Lifetime of Route Information Options (RIOs) [RFC4191], the
Lifetime of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime of Recursive DNS Search Options (RDNSSO) [RFC8106], and the
Lifetime of DNS Search List Options (DNSSLO) [RFC8106] 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
skipping to change at page 5, line 50 skipping to change at page 5, line 50
ND_VALID_LIMIT. ND_VALID_LIMIT.
This document RECOMMENDS that a CE Router providing DHCPv6-PD on the This document RECOMMENDS that a CE Router providing DHCPv6-PD on the
LAN-side set the DHCPv6 IA Prefix Option preferred-lifetime to the LAN-side set the DHCPv6 IA Prefix Option preferred-lifetime to the
lesser of the remaining preferred lifetime (see Section 3.1) and 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.
RATIONALE: RATIONALE:
* The Valid Lifetime and Preferred Lifetime of PIOs have 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
deprecate stale network configuration information (e.g. to deprecate stale network configuration information (e.g. to
handle cases where nodes miss Router Advertisements and thus handle cases where nodes miss Router Advertisements and thus
still consider the stale information as valid). still consider the stale information as valid).
+ The amount of information that a CE Routers need to maintain + The amount of information that CE Routers need to maintain
when e.g. multiple crash-and-reboot events occur in the when e.g. multiple crash-and-reboot events occur in the
timespan represented by the option lifetimes employed on the timespan represented by the option lifetimes employed on the
LAN-side. LAN-side.
* CE Routers need not employ the (possibly long) DHCPv6-PD * CE Routers need not employ the (possibly long) DHCPv6-PD
lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs
sent in Router Advertisements messages to advertise sub- sent in Router Advertisements messages to advertise sub-
prefixes of the leased prefix. Instead, CPE Routers SHOULD use prefixes of the leased prefix. Instead, CPE Routers SHOULD use
shorter values for the Valid Lifetime and Preferred Lifetime of shorter values for the Valid Lifetime and Preferred Lifetime of
PIOs, since subsequent Router Advertisement messages will PIOs, since subsequent Router Advertisement messages will
skipping to change at page 7, line 16 skipping to change at page 7, line 16
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 period of ND_VALID_LIMIT if the recommended valid-lifetime, or for a period of ND_VALID_LIMIT if the
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 This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6
(address assignment or prefix delegation), the following behavior be (address assignment or prefix delegation), the following behavior be
implemented: 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
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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
lifetimes for any address assignments or prefix delegations for lifetimes for any address assignments or prefix delegations for
the deprecated prefixes for at least the valid-lifetime the deprecated prefixes for at least the valid-lifetime
previously employed for them, or for a period of ND_VALID_LIMIT previously employed for them, or for a period of ND_VALID_LIMIT
if the recommended lifetimes from Section 3.2 are employed. if the recommended lifetimes from Section 3.2 are employed.
* Initiate sending Reconfigure messages (if possible - i.e., * Initiate sending Reconfigure messages (if possible - i.e.,
client requests Reconfigure support and the CE Router offers client requests Reconfigure support and the CE Router offers
it) to the those clients with address assignments or prefix it) to those clients with address assignments or prefix
delegations for the deprecated prefixes. delegations for the deprecated prefixes.
RATIONALE: RATIONALE:
* 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 manner, with old/stale prefixes being phased-out via reduced
prefix lifetimes while new prefixes (with normal lifetimes) are prefix lifetimes while new prefixes (with normal lifetimes) are
introduced. However, there are a number of scenarios that may introduced. However, a number of scenarios may lead to the so-
lead to the so-called "flash-renumbering" events, where the called "flash-renumbering" events, where the prefix being
prefix being employed on a network suddenly becomes invalid and employed on a network suddenly becomes invalid and replaced by
replaced by a new prefix [I-D.ietf-v6ops-slaac-renum]. One of a new prefix [I-D.ietf-v6ops-slaac-renum]. One such scenario
such scenarios is that in which a DHCPv6 server employs dynamic is when a DHCPv6 server employs dynamic prefixes and the
prefixes, and the Customer Edge Router crashes and reboots. Customer Edge Router crashes and reboots. The requirements in
this section are meant to allow Customer Edge Routers to
The requirements in this section are meant to allow Customer deprecate stale information in such scenarios.
Edge Routers to deprecate stale information in such scenarios.
* The recommendations in this section expand from requirement * The recommendations in this section expand from requirement
L-13 in Section 4.3 of [RFC7084]. L-13 in Section 4.3 of [RFC7084].
* Host configuring addresses via SLAAC on the local network may * Host configuring addresses via SLAAC on the local network may
employ addresses configured for the previously advertised employ addresses configured for the previously advertised
prefixes for at most the "Valid Lifetime" of the corresponding prefixes for at most the "Valid Lifetime" of the corresponding
PIO of the last received Router Advertisement message. Since PIO of the last received Router Advertisement message. Since
Router Advertisement messages may be lost or fail to be Router Advertisement messages may be lost or fail to be
received for various reasons, Customer Edge Routers need to try received for various reasons, Customer Edge Routers need to try
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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, Erik Kline,
Olorunloba Olopade, Mark Smith, Job Snijders, Sander Steffann, Ole Warren Kumari, Olorunloba Olopade, Mark Smith, Job Snijders, Sander
Troan, Loganaden Velvindron, Timothy Winters, and Chongfeng Xie, for Steffann, Ole Troan, Loganaden Velvindron, Timothy Winters, and
providing valuable comments on earlier versions of this document. Chongfeng Xie, for providing valuable comments on earlier versions of
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.
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 have benefited his protocol-related work.
8. References 8. References
8.1. Normative References 8.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>.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
8.2. Informative References 8.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-08 (work in progress), May 2020. renum-08 (work in progress), May 2020.
[I-D.ietf-6man-slaac-renum]
Gont, F., Zorz, J., and R. Patterson, "Improving the
Robustness of Stateless Address Autoconfiguration (SLAAC)
to Flash Renumbering Events", draft-ietf-6man-slaac-
renum-00 (work in progress), July 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-02 (work
in progress), May 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>.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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
Skofja Loka 4220
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
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. 16 change blocks. 
32 lines changed or deleted 35 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/