--- 1/draft-ietf-6man-slaac-renum-01.txt 2021-01-19 18:13:10.331653802 -0800 +++ 2/draft-ietf-6man-slaac-renum-02.txt 2021-01-19 18:13:10.371654815 -0800 @@ -1,22 +1,22 @@ IPv6 Maintenance (6man) Working Group F. Gont Internet-Draft SI6 Networks Updates: 4861, 4862 (if approved) J. Zorz Intended status: Standards Track 6connect -Expires: February 27, 2021 R. Patterson +Expires: July 23, 2021 R. Patterson Sky UK - August 26, 2020 + January 19, 2021 Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events - draft-ietf-6man-slaac-renum-01 + draft-ietf-6man-slaac-renum-02 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 improves the reaction of IPv6 Stateless Address Autoconfiguration to such renumbering scenarios. Status of This Memo @@ -27,25 +27,25 @@ 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 27, 2021. + This Internet-Draft will expire on July 23, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + 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 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 @@ -54,49 +54,47 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4 3.1. Renumbering without Explicit Signaling . . . . . . . . . 4 3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5 4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6 4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7 4.1.1. Router Configuration Variables . . . . . . . . . . . 7 - 4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7 - 4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7 - 4.3. Interface Initialization . . . . . . . . . . . . . . . . 8 + 4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 8 + 4.3. Interface Initialization . . . . . . . . . . . . . . . . 9 4.4. Conveying Information in Router Advertisement (RA) - Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 + Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Recovery from Stale Configuration Information without - Explicit Signaling . . . . . . . . . . . . . . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 - 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9 - 6.1.1. Router Configuration Variables . . . . . . . . . . . 9 - 6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9 - 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10 - 6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10 - 6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10 + Explicit Signaling . . . . . . . . . . . . . . . . . . . 10 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 + 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 10 + 6.1.1. Router Configuration Variables . . . . . . . . . . . 10 + 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 11 + 6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 11 + 6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 11 6.3. Conveying Information in Router Advertisement (RA) - Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 + Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. Recovery from Stale Configuration Information without - Explicit Signaling . . . . . . . . . . . . . . . . . . . 10 - 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10 + Explicit Signaling . . . . . . . . . . . . . . . . . . . 11 + 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Other mitigations implemented in products . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 - 9.2. Informative References . . . . . . . . . . . . . . . . . 13 - Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15 - A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15 - A.2. On a Possible Improvement to Source Address Selection . . 16 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 16 + A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 16 + A.2. On a Possible Improvement to Source Address Selection . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction 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 @@ -176,28 +174,25 @@ 7 days or 30 days (respectively) to recover from a network problem is simply unacceptable. Use of more appropriate timers in Router Advertisement messages can help limit the amount of time that hosts will maintain stale configuration information. Additionally, hosts are normally in a position to infer that a prefix has become stale -- for example, if a given router ceases to advertise an existing prefix and at the same time starts to advertise a new prefix. - Section 4.1.1 recommends the use of more appropriate lifetimes for - PIOs, while Section 4.1.2 proposes to cap the accepted Valid Lifetime - and Preferred Lifetime values at hosts, such that more appropriate - values are employed even in the presence of legacy routers. - - Section 4.5 specifies a local policy that SLAAC hosts can implement - to heuristically infer that network configuration information has - changed, such that stale configuration information can be phased out. + Section 4.1.1 recommends the use of more appropriate default + lifetimes for PIOs, while Section 4.5 specifies a local policy that + SLAAC hosts can implement to heuristically infer that network + configuration information has changed, such that stale configuration + information can be phased out. 3.2. Renumbering with Explicit Signaling In scenarios where a local router is aware about the renumbering event, it may try to phase out the stale network configuration information. In these scenarios, there are two aspects to be considered: o The amount of time during which the router should continue trying to deprecate the stale network configuration information @@ -256,25 +251,20 @@ aforementioned updates are mostly orthogonal, and mitigate different aspects of SLAAC that prevent a timely reaction to flash renumbering events. o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs (Section 4.1.1): This helps limit the amount of time a host will employ stale information, and also limits the amount of time a router needs to try to obsolete stale information. - o Cap the received Valid Lifetime and Preferred Lifetime of PIOs - (Section 4.1.2): - This helps limit the amount of time a host will employ stale - information, even in the presence of legacy ([RFC4861]) routers. - o Honor PIOs with small Valid Lifetimes (Section 4.2): This allows routers to invalidate stale prefixes, since otherwise [RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime smaller than two hours. o Recommend routers to retransmit configuration information upon interface initialization/reinitialization (Section 4.3): This helps spread the new information in a timelier manner, and also deprecate stale information via host-side heuristics (see Section 4.5). @@ -289,42 +278,103 @@ o Infer stale network configuration information from received RAs (Section 4.5): This allows hosts to deprecate stale network configuration information, even in the absence of explicit signaling. 4.1. More Appropriate Lifetime Values 4.1.1. Router Configuration Variables - [TBD] + The default values of the Preferred Lifetime and the Valid Lifetime + of PIOs are updated as follows: -4.1.2. Processing of PIO Lifetimes at Hosts + AdvPreferredLifetime: max(AdvDefaultLifetime, 3 * + MaxRtrAdvInterval) - [TBD] + AdvValidLifetime: 2 * AdvPreferredLifetime + + where: + + AdvPreferredLifetime: + Value to be placed in the "Preferred Lifetime" field of the PIO. + + AdvValidLifetime: + Value to be placed in the "Valid Lifetime" field of the PIO. + + AdvDefaultLifetime: + Value to be placed in the "Router Lifetime" field of the Router + Advertisement message that will carry the PIO. + + max(): + A function that computes the maximum of its arguments. + + NOTE: + [RFC4861] specifies the default value of MaxRtrAdvInterval as 600 + seconds, and the default value of AdvDefaultLifetime as 3 * + MaxRtrAdvInterval. Therefore, when employing default values for + MaxRtrAdvInterval and AdvDefaultLifetime, the default values of + AdvPreferredLifetime and AdvValidLifetime become 1800 seconds (30 + minutes) and 3600 seconds (1 one hour), respectively. We note + that when implementing BCP202 [RFC7772], AdvDefaultLifetime will + typically be in the range of 45-90 minutes, and therefore the + default value of AdvPreferredLifetime will be in the range 45-90 + minutes, while the default value of AdvValidLifetime will be in + the range of 90-180 minutes. + + RATIONALE: + + * The default values of the PIO lifetimes should be such that, + under normal circumstances (including some packet loss), the + associated timers are refreshed/reset, but in the presence of + network failures (such as network configuration information + becoming stale), some fault recovering action (such as + deprecating the corresponding addresses and subsequently + removing them) is triggered. + + * In the context of [RFC8028], where it is clear that the use of + addresses configured for a given prefix is tied to the next-hop + router that advertised the prefix, the "Preferred Lifetime" of + a PIO should not be larger than the "Router Lifetime" of Router + Advertisement messages. Some leeway should be provided for the + "Valid Lifetime" of PIOs, to cope with transient network + problems. As a result, this document updates [RFC4861] such + that the default Valid Lifetime (AdvValidLifetime) and the + default Preferred Lifetime (AdvPreferredLifetime) of PIOs are + specified as a function of the "Router Lifetime" + (AdvDefaultLifetime) of Router Advertisement messages. In the + absence of RAs that refresh information, addresses configured + for previously-advertised prefixes become deprecated in a + timelier manner, and thus Rule 3 of [RFC6724] will cause other + configured addresses (if available) to be preferred. + + * The expression above computes the maximum between + AdvDefaultLifetime and "3 * MaxRtrAdvInterval" (the default + value of AdvDefaultLifetime, as per [RFC4861]) to cope with the + case where an operator might simply want to disable one local + router for maintenance, without disabling the use of the + corresponding prefixes on the local network (e.g., on a multi- + router network). [RFC4862] implementations would otherwise + deprecate the corresponding prefixes. Similarly, [RFC8028] + implementations would likely behave in the same way. 4.2. Honor Small PIO Valid Lifetimes The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is replaced with the following text: e) If the advertised prefix is equal to the prefix of an address configured by stateless autoconfiguration in the list, the valid lifetime and the preferred lifetime of the address should be updated by processing the Valid Lifetime and the Preferred Lifetime (respectively) in the received advertisement. - NOTE: - "Processing" the Valid Lifetime and Preferred Lifetime includes - capping the received values as specified in Section 4.1.2 of this - document. - RATIONALE: * This change allows hosts to react to the information provided by a router that has positive knowledge that a prefix has become invalid. * The behavior described in RFC4862 had been incorporated during the revision of the original IPv6 Stateless Address Autoconfiguration specification ([RFC1971]). At the time, the IPNG working group decided to mitigate the attack vector @@ -411,44 +461,23 @@ 6.1.1.2. radvd(8) The radvd(8) daemon [radvd], normally employed by Linux-based router implementations, currently employs different default lifetimes than those recommended in [RFC4861]. radvd(8) employs the following default values [radvd.conf]: o Preferred Lifetime: 14400 seconds (4 hours) o Valid Lifetime: 86400 seconds (1 day) - This is not following the specific recommendation in this document, bu is already a deviation from the current standards. -6.1.2. Processing of PIO Lifetimes at Hosts -6.1.2.1. NetworkManager - - NetworkManager [NetworkManager], user-space SLAAC implementation - employed by some Linux-based operating systems (such as Fedora or - Ubuntu), caps the lifetimes of the received PIOs as recommended in - this document. - -6.1.2.2. slaacd(8) - - slaacd(8) [slaacd], a user-space SLAAC implementation employed by - OpenBSD, caps the lifetimes of the received PIOs as recommended in - this document. - -6.1.2.3. systemd-networkd - - systemd-networkd [systemd], a user-space SLAAC implementation - employed by some Linux-based operating systems, caps the lifetimes of - the received PIOs as recommended in this document. - 6.2. Honor Small PIO Valid Lifetimes 6.2.1. Linux Kernel A Linux kernel implementation of this document has been committed to the net-next tree. The implementation was produced in April 2020 by Fernando Gont . The corresponding patch can be found at: @@ -496,21 +525,21 @@ o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] (discussed in Section 4.2 of this document), upon first occurrence of a stale prefix, this implementation will employ a decreasing Valid Lifetime, starting from 2 hours (7200 seconds), as opposed to a Valid Lifetime of 0. 7. Security Considerations The protocol update in Section 4.2 could allow an on-link attacker to - perform a Denial of Service attack againts local hosts, by sending a + perform a Denial of Service attack against local hosts, by sending a forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of that packet, local hosts would invalidate the corresponding prefix, and therefore remove any addresses configured for that prefix, possibly terminating e.g. TCP connections employing such addresses. However, an attacker may achieve similar effects via a number for ND- based attack vectors, such as directing traffic to a non-existing node until ongoing TCP connections time out, or performing a ND-based man-in-the-middle (MITM) attack and subsequently forging TCP RST segments to cause on-going TCP connections to be aborted. Thus, for all practical purposes, this attack vector does not really represent @@ -536,24 +565,20 @@ Homburg. Fernando would like to thank Alejandro D'Egidio and Sander Steffann for a discussion of these issues, which led to the publication of [I-D.ietf-v6ops-slaac-renum], 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. - The problem discussed in this document has been previously documented - by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], - and also in [RIPE-690]. - 9. References 9.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, . [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast @@ -563,64 +588,60 @@ [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, . + [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy + Consumption of Router Advertisements", BCP 202, RFC 7772, + DOI 10.17487/RFC7772, February 2016, + . + [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, . [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, "Updates to the Special-Purpose IP Address Registries", BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, . - [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node - Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, - January 2019, . - 9.2. Informative References [dhcpcd] Marples, R., "dhcpcd - a DHCP client", . [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network (updated with solution)", SI6 Networks Blog, February 2016, . [I-D.ietf-v6ops-cpe-slaac-renum] Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving the Reaction of Customer Edge Routers to Renumbering - Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in - progress), August 2020. + Events", draft-ietf-v6ops-cpe-slaac-renum-06 (work in + progress), December 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. - - [I-D.linkova-6man-default-addr-selection-update] - Linkova, J., "Default Address Selection and Subnet - Renumbering", draft-linkova-6man-default-addr-selection- - update-00 (work in progress), March 2017. + Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work + in progress), November 2020. [IPNG-minutes] IETF, "IPNG working group (ipngwg) Meeting Minutes", Proceedings of the thirty-eightt Internet Engineering Task Force , April 1997, . [NetworkManager] NetworkManager, "NetworkManager web site", . @@ -664,29 +685,20 @@ [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, . - [RIPE-690] - Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, - J., Doering, G., Palet, J., Linkova, J., Balbinot, L., - Meynell, K., and L. Howard, "Best Current Operational - Practice for Operators: IPv6 prefix assignment for end- - users - persistent vs non-persistent, and what size to - choose", RIPE 690, October 2017, - . - [slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)", . [systemd] systemd, "systemd web site", . Appendix A. Analysis of Some Suggested Workarounds [This section is to be removed before publication of this document as an RFC].