IPv6 Operations Working Group (v6ops) F. Gont Internet-Draft SI6 Networks Updates: 7084 (if approved) J. Zorz Intended status: Best Current Practice 6connect Expires: August 15, 2021 R. Patterson Sky UK B. Volz Cisco February 11, 2021 Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events draft-ietf-v6ops-cpe-slaac-renum-07 Abstract This document specifies improvements to Customer Edge Routers that help mitigate the problems that may arise when network configuration information becomes invalid, without any explicit signaling of that condition to the affected nodes. This document updates RFC7084. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 15, 2021. Copyright Notice Copyright (c) 2021 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 Gont, et al. Expires August 15, 2021 [Page 1] Internet-Draft Reaction to Renumbering Events February 2021 carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . . . . . . 2 3. Improved Customer Edge Router Behavior . . . . . . . . . . . 3 3.1. Automatic DHCPv6 RELEASEs . . . . . . . . . . . . . . . . 4 3.2. Stability of IAIDs . . . . . . . . . . . . . . . . . . . 4 3.3. Interface Between WAN-side and LAN-side . . . . . . . . . 4 3.4. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 3.5. Signaling Stale Configuration Information . . . . . . . . 7 4. Recommended Option Lifetimes Configuration Values . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction 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 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 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 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 Gont, et al. Expires August 15, 2021 [Page 2] Internet-Draft Reaction to Renumbering Events February 2021 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 have no control), and do not preclude implementation of host-side improvements such as those specified in [I-D.ietf-6man-slaac-renum]. This document specifies additional prefix-delegation requirements to those specified in [RFC7084]: o WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot events. See Section 3.1 for further details. o WPD-10: CE Routers MUST by default use a stable IAID value that does not change between CE Router restarts, DHCPv6 client restarts, or interface state changes. e.g., Transient PPP interfaces. See Section 3.2 for further details. This document also replaces LAN-side requirement L-13 from [RFC7084] with: o L-13: CE routers MUST signal stale configuration information as specified in Section 3.5. Finally, this document specifies the following additional LAN-side requirements to those from [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.3. o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes and capped DHCPv6 IA Address Option and IA Prefix Option lifetimes, as specified in Section 3.4. Gont, et al. Expires August 15, 2021 [Page 3] Internet-Draft Reaction to Renumbering Events February 2021 3.1. Automatic DHCPv6 RELEASEs Some CE Routers are known to automatically send DHCPv6-PD RELEASE messages upon reboot events. However, this may inadvertently trigger a flash-renumbering scenario, along with the associated problems discussed in [I-D.ietf-v6ops-slaac-renum], that this document attempts to mitigate. As a result, requirement WPD-9 from Section 3 specifies that CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot events. 3.2. Stability of IAIDs [RFC8415] requires that the IAID for an IA MUST be consistent across restarts of the DHCP client. However, some popular CE Routers are known to select new random IAIDs e.g. everytime the underlying PPP session is established. This could be the result of extrapolating the behavior described in [RFC7844], or simply a consequence of not storing IAIDs on stable storage along with failing to employ an algorithm that consistently generates the same IAID upon reboots. Thus, requirement WPD-10 from Section 3 prevents CE Routers from inadvertently triggering flash-renumbering events on the local network. 3.3. Interface Between WAN-side and LAN-side The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information Options (PIOs) [RFC4861] corresponding to prefixes learned via DHCPv6-PD MUST NOT span past the remaining preferred and valid lifetimes of the corresponding DHCPv6-PD prefixes. This means that the "Preferred Lifetime" and the "Valid Lifetime" advertised in PIOs by the CE router MUST be dynamically adjusted such that they never span past the remaining preferred and valid lifetimes of the corresponding prefixes delegated via DHCPv6-PD on the WAN-side. 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 "preferred-lifetime" and "valid- lifetime" of DHCPv6 IA Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on the LAN-side MUST be dynamically adjusted such that they 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. RATIONALE: Gont, et al. Expires August 15, 2021 [Page 4] Internet-Draft Reaction to Renumbering Events February 2021 * 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 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), 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.4. LAN-side Option Lifetimes CE Routers SHOULD override the default lifetime values of Neighbor Discovery options that depend in any way on changes in the prefix employed for address configuration on the LAN-side, and employ shorter lifetime values to improve the robustness to renumbering events, while complying with the requirements from Section 3.3 of this document and the recommendations in [RFC7772]. 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.3) 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. NOTES: In scenarios where the valid-lifetime and the preferred- lifetime of the prefix leased via DHCPv6 on the WAN-side are always lower than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, the lifetime values advertised on the LAN-side will see not experience actual changes. Gont, et al. Expires August 15, 2021 [Page 5] Internet-Draft Reaction to Renumbering Events February 2021 The above text refers to the Neighbor Discovery Options that are typically employed by CE Routers. A CE Router may need to apply the same policy for setting the lifetime of other Neighbor Discovery options it employs, if and where applicable. 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.3) 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.3) 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 deprecate stale network configuration information (e.g. to handle cases where hosts miss Router Advertisements and thus still consider the stale information as valid). + 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) WAN-side 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, CE Routers SHOULD use shorter values for the Valid Lifetime and Preferred Lifetime of PIOs, since subsequent Router Advertisement messages will nevertheless refresh the associated lifetimes, leading to the same effective lifetimes as specified by the WAN-side DHCPv6-PD lifetimes. * Similarly, CE Routers need not employ the (possibly long) WAN- side DHCPv6-PD lifetimes for the valid-lifetime and preferred- Gont, et al. Expires August 15, 2021 [Page 6] Internet-Draft Reaction to Renumbering Events February 2021 lifetime of IA Address Options and IA Prefix Option employed by DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 clients will lead to the same effective lifetimes as specified by the WAN-side DHCPv6-PD lifetimes. 3.5. Signaling Stale Configuration Information If a CE Router provides LAN-side address-configuration information via SLAAC: 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 via PIOs 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 proceeds as follows: * Any prefixes that were previously advertised by the CE Router via PIOs in RA messages, but that have now become stale, MUST be advertised with a PIO that has the "Valid Lifetime" and the "Preferred Lifetime" set to 0, and the "A" and "L" bits unchanged. * The aforementioned advertisement MUST be performed for at least the "Valid Lifetime" previously employed for such prefix. The CE Router MUST advertise this information with unsolicited Router Advertisements as described in Section 6.2.4 of [RFC4861], and MAY advertise this information via unicast Router Advertisements when possible and applicable. + Note: If requirement L-16 (Section 3.4) is followed, the Valid Lifetime need not be saved and the stale 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.4 are employed. If a CE Router provides LAN-side DHCPv6 (address assignment or prefix delegation), then: Gont, et al. Expires August 15, 2021 [Page 7] Internet-Draft Reaction to Renumbering Events February 2021 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, and Rebind messages, send IA Address Options or IA Prefix Options (as appropriate) for any address assignments or prefix delegations for the deprecated prefixes. The aforementioned options MUST be sent with both the valid-lifetime and the preferred-lifetime set to 0, for at least the valid-lifetime originally employed for them, or for a period of ND_VALID_LIMIT if the recommended lifetimes from Section 3.4 are employed. * Initiate sending Reconfigure messages (if possible - i.e., client requests Reconfigure support and the CE Router offers 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, 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], and Section 6.3 of [RFC8415]. * 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 to deprecate stale prefixes for a period of time equal to the "Valid Lifetime" of the PIO employed when originally advertising the prefix. Gont, et al. Expires August 15, 2021 [Page 8] Internet-Draft Reaction to Renumbering Events February 2021 * The requirement in this section is conveyed as a "SHOULD" (as opposed to a "MUST"), since the requirement to store information on stable storage may represent a challenge for some implementations. * 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. * The above text does not include DHCPv6 Advertise messages sent in response to DHCPv6 Solicit messages, since Section 18.3.9 of [RFC8415] requires that a DHCPv6 server that is not going to assign an address or delegated prefix received as a hint in the Solicit message MUST NOT include that address or delegated prefix in the Advertise message. Additionally, any subsequent Request messages will trigger the response specified in this section, and therefore cause the address or prefix to be deprecated. 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 Gont, et al. Expires August 15, 2021 [Page 9] Internet-Draft Reaction to Renumbering Events February 2021 security issues, and thus the same security considerations as for [RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply. 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, Luis Balbinot, Tim Chown, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Gert Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk, Erik Kline, Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade, Jordi Palet Martinez, Richard Patterson, Pete Resnick, Michael Richardson, Mark Smith, Job Snijders, Sander Steffann, Tarko Tikan, Ole Troan, Loganaden Velvindron, Eric Vyncke, Robert Wilton, Timothy Winters, Christopher Wood, and Chongfeng Xie, for providing valuable comments on earlier versions of this document. 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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . Gont, et al. Expires August 15, 2021 [Page 10] Internet-Draft Reaction to Renumbering Events February 2021 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, . [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 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.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-02 (work in progress), January 2021. [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-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, . Gont, et al. Expires August 15, 2021 [Page 11] Internet-Draft Reaction to Renumbering Events February 2021 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@6connect.com Richard Patterson Sky UK Email: richard.patterson@sky.uk Bernie Volz Cisco Systems, Inc. 300 Beaver Brook Rd Boxborough, MA 01719 USA Email: volz@cisco.com Gont, et al. Expires August 15, 2021 [Page 12]