--- 1/draft-ietf-v6ops-cpe-slaac-renum-05.txt 2020-12-11 10:13:13.612032029 -0800 +++ 2/draft-ietf-v6ops-cpe-slaac-renum-06.txt 2020-12-11 10:13:13.640032741 -0800 @@ -1,23 +1,23 @@ IPv6 Operations Working Group (v6ops) F. Gont Internet-Draft SI6 Networks Updates: 7084 (if approved) J. Zorz -Intended status: Informational 6connect -Expires: April 1, 2021 R. Patterson +Intended status: Best Current Practice 6connect +Expires: June 14, 2021 R. Patterson Sky UK B. Volz Cisco - September 28, 2020 + December 11, 2020 Improving the Reaction of Customer Edge Routers to Renumbering Events - draft-ietf-v6ops-cpe-slaac-renum-05 + draft-ietf-v6ops-cpe-slaac-renum-06 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 April 1, 2021. + This Internet-Draft will expire on June 14, 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 @@ -55,26 +55,26 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 3 3.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 3.3. Signaling Stale Configuration Information . . . . . . . . 6 4. Recommended Option Lifetimes Configuration Values . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction In scenarios where network configuration information becomes invalid without any explicit signaling of that condition, nodes on the local @@ -85,36 +85,25 @@ This document specifies improvements to Customer Edge (CE) Routers that help mitigate the aforementioned problem for residential and small office scenarios. It specifies recommendations for the default behavior of CE Routers, and does not preclude the availability of configuration knobs that might allow an operator or user to manually- configure the CE Router to deviate from these recommendations. This document updates RFC7084. 2. Requirements Language - Take careful note: Unlike other IETF documents, the key words "MUST", - "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", - "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as - described in [RFC2119]. This document uses these keywords not - strictly for the purpose of interoperability, but rather for the - purpose of establishing industry-common baseline functionality. As - such, the document points to several other specifications (preferable - in RFC or stable form) to provide additional guidance to implementers - regarding any protocol implementation required to produce a - successful CE router that interoperates successfully with a - particular subset of currently deploying and planned common IPv6 - access networks. - - Note: the aforementioned terms are used in exactly the same way as in - [RFC7084], with the above explanation copied verbatim from - Section 1.1 of [RFC7084]. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. 3. Improved Customer Edge Router Behavior This section specifies and clarifies requirements for Customer Edge Routers that can help mitigate the problem discussed in Section 1, particularly when they employ prefixes learned via DHCPv6-Prefix Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on the LAN-side. The recommendations in this document help improve robustness at the Customer Edge Router (on which the user or ISP may @@ -391,27 +380,27 @@ successive detailed reviews. The authors would like to thank Mikael Abrahamsson, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade, 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 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. + The authors would like 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 have benefited his protocol-related work. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -436,20 +425,24 @@ [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, . [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, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . 8.2. Informative References [I-D.gont-6man-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Improving the @@ -459,43 +452,43 @@ [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-01 (work in progress), August 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-03 (work - in progress), August 2020. + Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work + in progress), November 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, . Authors' Addresses 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 6connect - Email: jan@connect.com + Email: jan@6connect.com Richard Patterson Sky UK Email: richard.patterson@sky.uk Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719