--- 1/draft-ietf-v6ops-cpe-slaac-renum-04.txt 2020-09-28 06:13:32.498385620 -0700 +++ 2/draft-ietf-v6ops-cpe-slaac-renum-05.txt 2020-09-28 06:13:32.518385888 -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 6connect -Expires: February 26, 2021 R. Patterson +Expires: April 1, 2021 R. Patterson Sky UK B. Volz Cisco - August 25, 2020 + September 28, 2020 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 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 February 26, 2021. + This Internet-Draft will expire on April 1, 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 @@ -59,27 +59,27 @@ 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.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 3.3. Signaling Stale Configuration Information . . . . . . . . 6 4. Recommended Option Lifetimes Configuration Values . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 network will continue using stale information for an unacceptably long period of time, thus resulting in connectivity problems. This problem is documented in detail in [I-D.ietf-v6ops-slaac-renum]. This document specifies improvements to Customer Edge (CE) Routers @@ -112,21 +112,21 @@ 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 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 requirements L-1 through L-14 specified in [RFC7084]: o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign 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 3.1. @@ -154,31 +154,31 @@ 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 advertised lifetimes never span past the remaining preferred and valid lifetimes of the corresponding prefixes delegated to the CE Router on the WAN-side via DHCPv6-PD. - This document RECOMMENDS that CE Routers providing stateful address - 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. + CE Routers providing stateful address configuration via DHCPv6 SHOULD + set 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. - This document RECOMMENDS that a CE Router providing DHCPv6-PD on the - LAN-side sets the DHCPv6 IA Prefix 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. + 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 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 lifetime values employed for the "Preferred Lifetime" (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) of SLAAC Prefix Information Options must never be larger than 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 @@ -196,46 +196,44 @@ 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 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 + CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. CE + routers SHOULD also 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, 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] SHOULD 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 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 + CE Routers providing stateful address configuration via DHCPv6 SHOULD + set the DHCPv6 IA Address 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. + 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: * 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 @@ -268,45 +266,44 @@ 3.3. Signaling Stale Configuration Information In order to phase-out stale SLAAC configuration information: o A CE router sending RAs that advertise dynamically-learned prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, the list of prefixes being advertised on each network segment, and the state of the "A" and "L" flags of the corresponding PIOs. o Upon changes to the advertised prefixes, and after bootstrapping, - the CE router advertising prefix information via SLAAC SHOULD - proceed as follows: + the CE Router advertising prefix information via SLAAC proceeds as + follows: * Any prefixes that were previously advertised via Router Advertisement (RA) messages, but that have now become stale, MUST be advertised with a "Valid Lifetime" and a "Preferred Lifetime" set to 0, and the "A" and "L" bits unchanged. * The aforementioned advertisement SHOULD be performed for at 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 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: + If a CE Router provides LAN-side DHCPv6 (address assignment or prefix + delegation), then: 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 @@ -355,42 +352,56 @@ * 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. 4. Recommended Option Lifetimes Configuration Values o ND_PREFERRED_LIMIT: 2700 seconds (45 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 This document has no actions for IANA. 6. Security Considerations This document discusses a problem that may arise in scenarios where dynamic IPv6 prefixes are employed, and proposes improvements to Customer Edge Routers [RFC7084] to mitigate the problem for residential or small office scenarios. It does not introduce new 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, - Warren Kumari, Olorunloba Olopade, Mark Smith, Job Snijders, Sander - Steffann, Ole Troan, Loganaden Velvindron, Timothy Winters, and + 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. @@ -443,27 +454,27 @@ [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. + 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-02 (work - in progress), May 2020. + Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work + in progress), August 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 @@ -466,25 +477,25 @@ 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@zorz.si - URI: https://www.6connect.com/ + Email: jan@connect.com Richard Patterson Sky UK Email: richard.patterson@sky.uk Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719