IPv6 Maintenance (6man) Working Group F. Gont Internet-Draft SI6 Networks Updates: 4862 (if approved) J. Zorz Intended status: Standards Track 6connect Expires: 29 October 2023 R. Patterson Sky UK 27 April 2023 Lifetime Avoidance Algorithm draft-gont-6man-lta-00 Abstract In renumbering scenarios where an IPv6 prefix suddenly becomes invalid, hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document specifies an algorithm that allows host implementations to infer when configuraton information has changed, such that they can phase stale information out in a timelier manner. 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 29 October 2023. Copyright Notice Copyright (c) 2023 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 carefully, as they describe your rights Gont, et al. Expires 29 October 2023 [Page 1] Internet-Draft LTA Algorithm April 2023 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Lifetime Avoidance (LTA) Algorithm . . . . . . . . . . . . . 3 3.1. Target Neighbor Discovery Options . . . . . . . . . . . . 4 3.2. Local State Information and Configuration Variables . . . 4 3.3. Algorithm Specification . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In scenarios where network configuration information becomes invalid without any explicit signaling of that condition, hosts on the local network will continue using stale SLAAC [RFC4862] information for an unacceptably long period of time, thus resulting in connectivity problems. This problem has been discussed in detail in [RFC8978]. This document specifies and algorithm that allows SLAAC host implementations to infer when configuraton information has become stale, such that they can phase out stale information in a timelier manner. 2. Terminology 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. Gont, et al. Expires 29 October 2023 [Page 2] Internet-Draft LTA Algorithm April 2023 3. Lifetime Avoidance (LTA) Algorithm This section specifies an algorithm, "Lifetime Avoidance" (LTA) algorithm, that allows hosts to infer that previously-advertised configuration information (such as autoconfiguration prefixes) has become stale, such that the stale information can be deprecated in a timelier manner. Most of the value of this algorithm is in being able to mitigate the problem discussed in [RFC8978] at hosts themselves, without relying on changes in SLAAC router implementations. The algorithm consists of two conceptual building-blocks: * Detection of possible configuration change * Validation/Refresh of configuration information Possible configuration changes can be inferred when a SLAAC router (as identified by its link-local address) ceases to advertise a previously-advertised information. Therefore, hosts can record what configuration information has been advertised by each local router, and infer a configuration change when a router ceases to advertise previously-advertises configuration information. Inscenarios where possible configuration changes have been detected, hosts should poll the local router via unicasted Router Solicitations (RS) to verify that the router in question has indeed ceased to advertise the aforementioned information. If this condition is confirmed, the corresponding configuration information should be discarded. In the context of multi-prefix/multi-router networks [RFC8028] [RFC8504], SLAAC configuration information should be associated with each advertising router. Thus, when a router ceases to advertise some configuration information: * If this was the only router advertising the aforementioned information, the information should be discarded. * If other routers were advertising the aforementioned information, it should simply be dis-associated with the router that ceased to advertise it, and the fate of this information (and configured resources) should depend solely on the routers that continue advertising it. Implementation of this kind of heuristic allows a timelier reaction to network configuration changes even in scenarios where there is no explicit signaling from the network, thus improving robustness. Gont, et al. Expires 29 October 2023 [Page 3] Internet-Draft LTA Algorithm April 2023 [RFC4861] does not require routers to convey all RA options in the same message. Therefore, the algorithm specified in this section is designed such that it can cope with this corner case that, while not found in the deployed Internet, is allowed by [RFC4861]. 3.1. Target Neighbor Discovery Options The LTA algorithm SHOULD be applied to the following Neighbor Discovery options: * Prefix Information Option [RFC4861] * Route Information Option (RIO) [RFC4191] * DNS Search Options (RDNSSO) [RFC8106] * DNS Search List Options (DNSSLO) [RFC8106] 3.2. Local State Information and Configuration Variables In the context of multi-prefix/multi-router networks [RFC8028] [RFC8504], each option from Section 3.1 is associated with each advertising SLAAC router. Therefore, hosts should record what configuration information has been advertised by each local router. NOTE: Throughout this specification, each router is identified by its link-local address. Additionally, hosts associate with piece of configuration information received via SLAAC options a timestamp (INFO_LAST variable below) that records the time at which this information was last advertised by a particular router. NOTE: While not strictly required, we note that existing implementations may already record a timestamp representing when a piece of information was advertised by a given router as a possible implementation approach to be able to compute the remaining lifetime of that piece of information. The algorithm specified in this document employs the following variables: LTA_MODE: A boolean variable associated with each SLAAC advertising router that specifies whether the local host is currently performing the LTA algorithm for that router. It is initialized to FALSE. Gont, et al. Expires 29 October 2023 [Page 4] Internet-Draft LTA Algorithm April 2023 LTA_LAST: A variable associated with each SLAAC advertising router that stores the time (in seconds) when the local host last entered the LTA algorithm for this router. It is initialized to 0. RS_LAST: A variable associated with each SLAAC advertising router that stores the time (in seconds) when the local host last sent a unicasted Router Solicitation to the router in question. It is initialized to 0. RS_COUNT: A variable associated with each SLAAC advertising router that stores the number of unicasted Router Solicitations that have been sent to the corresponding router since the last time the LTA algorithm was executed. It is initialized to 0. RS_COUNT_MAX: A configuration variable specifying the maximum number of unicasted Router Solicitations that a host will send to a SLAAC advertising router as part of the LTA algorithm. It defaults to 1. RS_RNDTIME: A host-wide variable specifying a random amount of time that the host should wait before sending the first unicasted Router Solicitation message to a SLAAC router as part of the LTA algorithm. It should be initialized to a value in the range from 0 to 5 seconds when the system is bootstrapped. RS_TIMEOUT: A host-wide variable specifying the amount of time to wait for a response to a unicasted Router Solicitation sent as part of the LTA algorithm. It defaults to 3 seconds. INFO_LAST: A timestamp associated with each piece of SLAAC information (from Section 3.1) received from each SLAAC advertising router. Gont, et al. Expires 29 October 2023 [Page 5] Internet-Draft LTA Algorithm April 2023 NOTE: In most cases (e.g., Prefix Information Options and Route Information Options) each neighbor discovery option carries one atomic piece of SLAAC information. In other cases (notably Recursive DNS Server Option [RFC8106] and DNS Search List Option [RFC8106]), a single neighbor discovery option carries multiple atomic pieces of information (i.e., a host might want to prune some recursive DNS server addresses, but not others). This is why this document refers to "piece of SLAAC information" rather than "Negihbor Discovery option" (since one option might carry multiple pieces of information). RA_WIN: A host-wide configuration variable specifying a time window over which a SLAAC advertising router may convey all SLAAC configuration information. It is meant to cope with the theoretical case where a router may spread SLAAC information over several RA messages. It defaults to 3 seconds. LTA_CYCLE: This variable accounts for the maximum time that may elapse for the entire LTA algorithm to complete. Its value is computed as: LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT. 3.3. Algorithm Specification Initialization when a new SLAAC advertising router is learned: LTA_MODE=FALSE LTA_LAST=0 RS_LAST=0 RS_COUNT=0 LTA_CYCLE=RA_WIN+RS_RNDTIME+RS_COUNT_MAX*RS_TIMEOUT Upon receipt of a Router Advertisement message, and after normal processing of the message, perform the following actions: TIME= time() For each piece of SLAAC configuration information advertised by this router in the received RA: INFO_LAST= TIME IF LTA_MODE==FALSE && TIME > (LTA_LAST+LTA_CYCLE) IF this RA is missing any previously-advertised information: LTA_MODE=TRUE LTA_LAST=TIME Gont, et al. Expires 29 October 2023 [Page 6] Internet-Draft LTA Algorithm April 2023 RATIONALE: The goal of checking "(LTA_LAST+LTA_CYCLE)" is to prevent the host from re-entering the LTA_mode in a short period of time in the theoretical corner-case where: 1. The local router spreads information into multiple RA packets, and one of such packets gets lost, thus triggering the LTA mode. 2. The host sends a unicasted solicitation to the local router as part of the LTA mode. 3. The router spreads the response into multiple packets, and e.g. the first of such packets completes all the missing information, thus exiting the LTA mode. 4. One of the remaining RAs of this "batch" would otherwise trigger the LTA mode again. Thus, the above check only allows the LTA mode to be triggered once every LTA_CYCLE seconds. Time-driven events: IF LTA_MODE==TRUE: TIME=time() IF TIME > (LTA_LAST + LTA_CYCLE) Disaasociate any options for which INFO_LAST < LTA_LAST LTA_MODE= FALSE RS_COUNT= 0 ELSE IF TIME > (LTA_LAST + RA_WIN + RS_RNDTIME) && TIME > (RS_LAST + RS_TIMEOUT) && RS_COUNT < RS_COUNT_MAX: IF for all options INFO_LAST >= LTA_LAST LTA_MODE= FALSE RS_COUNT= 0 ELSE SendRS() RS_LAST=TIME RS_COUNT++ NOTES: Gont, et al. Expires 29 October 2023 [Page 7] Internet-Draft LTA Algorithm April 2023 * time() is a monotonically-increasing counter that is incremented once per second, and is employed in this algorithm to measure time. * SendRS() is a function sends a unicasted Router Solicitation message to the target router (subject to sending rules in [RFC4861]). RATIONALE: After a whole LTA_CYCLE has elapsed (i.e., "TIME > (LTA_LAST + LTA_CYCLE)"), SLAAC information that has not been refreshed since the LTA mode was entered should be disassociated with the router for which the LTA algorithm has been performed. While in the LTA mode, before probing the local router with a unicasted RS, we double-check if all the missing information has been completed/refreshed since the LTA mode was entered. In such case, the LTA mode is exited and the algorithm finished, thus avoiding sending unnecessary RS packets to the local router. Otherwise, a unicasted RS is sent to the local router for which the LTA algorithm is being performed. [IETF-6MAN-114] illustrates the most common scenarios. 4. IANA Considerations This document has no actions for IANA. 5. Security Considerations An attacker could for Router Advertisement messages wit missing Neighbor Discovery options (such as PIOs), to trigger the algorithm specified in this document, with te goal of illegitimatelly causing valid prefixes to be removed. In any case, and for all practical purposes, this attack vector does not really represent any greater risk than other ND attack vectors. In scenarios where RA-based attacks are of concern, proper mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND [RFC3971] should be implemented. 6. Acknowledgments The authors would like to thank (in alphabetical order) [TBD], for providing valuable comments on earlier versions of this document. Gont, et al. Expires 29 October 2023 [Page 8] Internet-Draft LTA Algorithm April 2023 Fernando would like to thank Alejandro D'Egidio and Sander Steffann for a discussion of these issues, which led to the publication of [RFC8978], and eventually to this document. 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. 7. References 7.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, . [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, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . 7.2. Informative References Gont, et al. Expires 29 October 2023 [Page 9] Internet-Draft LTA Algorithm April 2023 [IETF-6MAN-114] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", 6man WG meeting IETF 114, 2022, . [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, . [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, . [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, . [RFC8978] Gont, F., Žorž, J., and R. Patterson, "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events", RFC 8978, DOI 10.17487/RFC8978, March 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 Gont, et al. Expires 29 October 2023 [Page 10] Internet-Draft LTA Algorithm April 2023 Jan Zorz 6connect Email: jan@connect.com Richard Patterson Sky UK Email: richard.patterson@sky.uk Gont, et al. Expires 29 October 2023 [Page 11]