From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9096.txt | 561 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 561 insertions(+) create mode 100644 doc/rfc/rfc9096.txt (limited to 'doc/rfc/rfc9096.txt') diff --git a/doc/rfc/rfc9096.txt b/doc/rfc/rfc9096.txt new file mode 100644 index 0000000..1e1d0b2 --- /dev/null +++ b/doc/rfc/rfc9096.txt @@ -0,0 +1,561 @@ + + + + +Internet Engineering Task Force (IETF) F. Gont +Request for Comments: 9096 SI6 Networks +BCP: 234 J. Žorž +Updates: 7084 6connect +Category: Best Current Practice R. Patterson +ISSN: 2070-1721 Sky UK + B. Volz + Individual Contributor + August 2021 + + + Improving the Reaction of Customer Edge Routers to IPv6 Renumbering + Events + +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 local nodes. This document updates RFC 7084. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9096. + +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 + 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. Requirements Language + 3. Improved Customer Edge Router Behavior + 3.1. Automatic DHCPv6 RELEASEs + 3.2. Stability of IAIDs + 3.3. Interface between the WAN Side and LAN Side + 3.4. LAN-Side Option Lifetimes + 3.5. Signaling Stale Configuration Information + 4. Recommended Option Lifetimes Configuration Values + 5. IANA Considerations + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + In scenarios where network configuration information becomes invalid + without any explicit signaling of that condition (such as when a + Customer Edge (CE) 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 [RFC8978]. + + This document specifies improvements to CE routers that help mitigate + the aforementioned problem for residential and small office + scenarios. It specifies recommendations for the default behavior of + CE routers but 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 RFC 7084. + +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 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 CE 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 CE 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 [6MAN-SLAAC-RENUM]. + + This document specifies additional WAN-side prefix-delegation (WPD) + requirements to those specified in [RFC7084]: + + WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE + messages upon restart events. See Section 3.1 for further + details. + + WPD-10: CE routers MUST by default use a WAN-side Identity + Association IDentifier (IAID) value that is stable between CE + router restarts, DHCPv6 client restarts, or interface state + changes (e.g., transient PPP interfaces), unless the CE router + employs the IAID techniques discussed in Section 4.5 of [RFC7844]. + See Section 3.2 for further details. + + This document also replaces LAN-side requirement L-13 from [RFC7084] + with: + + 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]: + + L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign + addresses or delegate prefixes via DHCPv6 on the LAN side using + lifetimes that exceed the remaining lifetimes of the corresponding + prefixes learned on the WAN side via DHCPv6-PD. For more details, + see Section 3.3. + + L-16: CE routers SHOULD advertise capped SLAAC option lifetimes, + capped DHCPv6 IA Address option lifetimes, and capped IA Prefix + option lifetimes, as specified in Section 3.4. + +3.1. Automatic DHCPv6 RELEASEs + + Some CE routers are known to automatically send DHCPv6-PD RELEASE + messages upon restart events. However, this may inadvertently + trigger a flash-renumbering scenario, along with the associated + problems discussed in [RFC8978], 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 + restart 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., every time the underlying PPP + session is established or when the device is rebooted. 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 failure 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 the WAN Side and LAN Side + + The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information + Options (PIOs) [RFC4861] corresponding to prefixes learned via + DHCPv6-PD on the WAN side 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 learned 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: + + * 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 of the corresponding prefixes (as learned via + DHCPv6-PD on the WAN side). This is in line with the requirement + from Section 6.3 of [RFC8415], which states: + + | In particular, 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" of Router Advertisement + (RA) messages to ND_PREFERRED_LIMIT. + + CE routers SHOULD also set the PIO "Preferred Lifetime" to the lesser + of the remaining preferred lifetime of the corresponding prefix (see + Section 3.3) and ND_PREFERRED_LIMIT, and set the PIO "Valid Lifetime" + to the lesser of the remaining valid lifetime of the corresponding + prefix and ND_VALID_LIMIT. Additionally, the "Route Lifetime" of + Route Information Options (RIOs) [RFC4191], the "Lifetime" of + Recursive DNS Server (RDNSS) options [RFC8106], and the "Lifetime" of + DNS Search List (DNSSL) options [RFC8106] SHOULD be set to the lesser + of the longest remaining valid lifetime of a prefix (leased via + DHCPv6 on the WAN side) and ND_VALID_LIMIT, if any of these options + are included in Router Advertisement messages. + + NOTE: In scenarios where the valid lifetime and the preferred + lifetime of prefixes learned via DHCPv6 on the WAN side are always + larger than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, + the lifetime values advertised on the LAN side will not experience + actual changes. + + 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 "preferred-lifetime" of a DHCPv6 IA Address option to the + lesser of the remaining preferred lifetime of the corresponding + prefix (see Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid- + lifetime" of the same option to the lesser of the remaining valid + lifetime of the corresponding prefix and ND_VALID_LIMIT. + + CE routers providing DHCPv6-PD on the LAN side SHOULD set the + "preferred-lifetime" of a DHCPv6 IA Prefix option to the lesser of + the remaining preferred lifetime of the corresponding prefix (see + Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-lifetime" of + the same option to the lesser of the remaining valid lifetime of the + corresponding prefix 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 [RFC8978]). + + - 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 Advertisement messages 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 time + span 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 Advertisement 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- + lifetime" of IA Address options and IA Prefix options 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 + + When a CE router provides LAN-side address-configuration information + via SLAAC: + + * A CE router sending RAs that advertise prefixes belonging to a + dynamically learned prefix (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. + + * 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 PIOs that have the "Valid Lifetime" and the + "Preferred Lifetime" set to 0 and the "A" and "L" bits + unchanged. + + - The aforementioned advertisements MUST be performed for at + least the "Valid Lifetime" previously employed for such + prefixes. The CE router MUST advertise this information with + unsolicited Router Advertisement messages, as described in + Section 6.2.4 of [RFC4861], and MAY advertise this information + via unicast Router Advertisement messages when possible and + applicable. + + NOTE: If requirement L-16 (Section 3) is followed, the + "Valid Lifetime" need not be saved, and the stale prefix can + simply be advertised for a period of ND_VALID_LIMIT. + + * CE routers receiving DHCPv6 IA Prefix options 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 PIOs 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. + + When a CE router provides LAN-side DHCPv6 (address assignment or + prefix delegation), then: + + * The CE router SHOULD record, on stable storage, the DHCPv6 address + and delegated-prefix bindings corresponding to the LAN side. + + * 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 IA Prefix + options 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 stale + 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 stale 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 a prefix being employed + on a network suddenly becomes invalid and replaced by a new prefix + [RFC8978]. One such scenario is when an Internet Service Provider + (ISP) employs dynamic prefixes and the CE router crashes and + reboots. The requirements in this section are meant to allow CE + 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]. + + * Hosts 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 PIOs of the + last received Router Advertisement messages. Since Router + Advertisement messages may be lost or fail to be received for + various reasons, CE 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. + + * The requirements in this section to store information on stable + storage are conveyed as "SHOULD" (as opposed to "MUST"), since + they 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 + + * ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) + + * 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 the "Router Lifetime", following the rationale from + Section 3.2 of [RFC8978]. + + * ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some + additional leeway before configuration information is finally + discarded by the hosts. + +5. IANA Considerations + + This document has no IANA actions. + +6. Security Considerations + + This document discusses a problem that may arise, e.g., in scenarios + where dynamic IPv6 prefixes are employed, and it proposes + improvements to CE routers [RFC7084] to mitigate the problem for + residential or small office scenarios. It does not introduce new + security issues; thus, the same security considerations as for + [RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply. + +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, + . + + [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, + . + + [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, + . + +7.2. Informative References + + [6MAN-SLAAC-RENUM] + Gont, F., Zorz, J., and R. Patterson, "Improving the + Robustness of Stateless Address Autoconfiguration (SLAAC) + to Flash Renumbering Events", Work in Progress, Internet- + Draft, draft-ietf-6man-slaac-renum-02, 19 January 2021, + . + + [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, + . + + [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, . + +Acknowledgments + + The authors would like to thank Owen DeLong, Philip Homburg, Erik + Kline, 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, + Brian Carpenter, Tim Chown, Lorenzo Colitti, Alejandro D'Egidio, Gert + Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick + Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk, + Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade, + Jordi Palet Martinez, Pete Resnick, Michael Richardson, Mark Smith, + Job Snijders, Sander Steffann, Tarko Tikan, Ole Trøan, Loganaden + Velvindron, Éric Vyncke, Robert Wilton, Timothy Winters, Christopher + Wood, and Chongfeng Xie for providing valuable comments on earlier + draft 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. + +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 Žorž + 6connect + + Email: jan@6connect.com + + + Richard Patterson + Sky UK + + Email: richard.patterson@sky.uk + + + Bernie Volz + Individual Contributor + 116 Hawkins Pond Road + Center Harbor, NH 03226 + United States of America + + Email: bevolz@gmail.com -- cgit v1.2.3