--- 1/draft-ietf-v6ops-cpe-slaac-renum-03.txt 2020-08-25 04:14:09.424827292 -0700 +++ 2/draft-ietf-v6ops-cpe-slaac-renum-04.txt 2020-08-25 04:14:09.516828530 -0700 @@ -1,23 +1,23 @@ IPv6 Operations Working Group (v6ops) F. Gont Internet-Draft SI6 Networks Updates: 7084 (if approved) J. Zorz -Intended status: Informational Go6 Institute -Expires: November 28, 2020 R. Patterson +Intended status: Informational 6connect +Expires: February 26, 2021 R. Patterson Sky UK B. Volz Cisco - May 27, 2020 + August 25, 2020 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 In scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed configuration information), hosts on the local network will continue using stale network configuration information for an unacceptably long period of time, thus resulting in connectivity problems. This document specifies improvements to @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -181,36 +181,36 @@ 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 of prefixes advertised on the LAN-side via SLAAC must be dynamically updated (rather than static values), - since otherwise the advertised lifetimes would eventually span - past the DHCPv6-PD lifetimes. + otherwise the advertised lifetimes would eventually span past + the DHCPv6-PD lifetimes. * 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. 3.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 + This document RECOMMENDS that CE routers 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 3.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 @@ -224,33 +224,33 @@ 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 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 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: + 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 + + The amount of information that 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 @@ -287,22 +287,22 @@ least the "Valid Lifetime" previously employed for such prefix. Note: If requirement L-16 (Section 3.2) is followed, the Valid Lifetime need not be saved and the prefix can simply be advertised for a period of ND_VALID_LIMIT. o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- lifetime MUST advertise the corresponding sub-prefixes (as they 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 3.2 are employed. + valid-lifetime, or for a period of ND_VALID_LIMIT if the + recommended lifetimes from Section 3.2 are employed. This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 (address assignment or prefix delegation), the following behavior be implemented: 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 @@ -310,37 +310,36 @@ 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 3.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 + it) to 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. + introduced. However, a number of scenarios 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 such scenario + is when 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 @@ -376,35 +375,36 @@ security issues. 7. Acknowledgments The authors would like to thank Owen DeLong, Philip Homburg, and Ted Lemon, for their valuable help in improving this document via successive detailed reviews. The authors would like to thank Mikael Abrahamsson, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Erik Kline, - Olorunloba Olopade, Mark Smith, Job Snijders, Sander Steffann, Ole - Troan, Loganaden Velvindron, Timothy Winters, and Chongfeng Xie, for - providing valuable comments on earlier versions of this document. + Warren Kumari, Olorunloba Olopade, Mark Smith, Job Snijders, Sander + Steffann, Ole Troan, Loganaden Velvindron, Timothy Winters, and + Chongfeng Xie, for providing valuable comments on earlier versions of + this document. 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. 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. + that have benefited his protocol-related work. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -439,20 +439,26 @@ . 8.2. Informative References [I-D.gont-6man-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", draft-gont-6man-slaac- 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] Gont, F., Zorz, J., and R. Patterson, "Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work in progress), May 2020. [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, . @@ -461,27 +467,24 @@ Fernando Gont SI6 Networks Segurola y Habana 4310, 7mo Piso Villa Devoto, Ciudad Autonoma de Buenos Aires Argentina Email: fgont@si6networks.com URI: https://www.si6networks.com Jan Zorz - Go6 Institute - Frankovo naselje 165 - Skofja Loka 4220 - Slovenia + 6connect - Email: jan@go6.si - URI: https://www.go6.si + Email: jan@zorz.si + URI: https://www.6connect.com/ Richard Patterson Sky UK Email: richard.patterson@sky.uk Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719