idnits 2.17.1 draft-ietf-v6ops-cpe-slaac-renum-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 27, 2020) is 1427 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group (v6ops) F. Gont 3 Internet-Draft SI6 Networks 4 Updates: 7084 (if approved) J. Zorz 5 Intended status: Informational Go6 Institute 6 Expires: November 28, 2020 R. Patterson 7 Sky UK 8 B. Volz 9 Cisco 10 May 27, 2020 12 Improving the Reaction of Customer Edge Routers to Renumbering Events 13 draft-ietf-v6ops-cpe-slaac-renum-03 15 Abstract 17 In scenarios where network configuration information becomes invalid 18 without any explicit signaling of that condition (such as when a 19 Customer Edge Router crashes and reboots without knowledge of the 20 previously-employed configuration information), hosts on the local 21 network will continue using stale network configuration information 22 for an unacceptably long period of time, thus resulting in 23 connectivity problems. This document specifies improvements to 24 Customer Edge Routers that help mitigate the aforementioned problem 25 for typical residential and small office scenarios. This document 26 updates RFC7084. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 28, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Improved Customer Edge Router Behavior . . . . . . . . . . . 3 65 3.1. Interface Between WAN-side and LAN-side . . . . . . . . . 4 66 3.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 67 3.3. Signaling Stale Configuration Information . . . . . . . . 6 68 4. Recommended Option Lifetimes Configuration Values . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 In scenarios where network configuration information becomes invalid 80 without any explicit signaling of that condition, nodes on the local 81 network will continue using stale information for an unacceptably 82 long period of time, thus resulting in connectivity problems. This 83 problem is documented in detail in [I-D.ietf-v6ops-slaac-renum]. 85 This document specifies improvements to Customer Edge (CE) Routers 86 that help mitigate the aforementioned problem for residential and 87 small office scenarios. It specifies recommendations for the default 88 behavior of CE Routers, and does not preclude the availability of 89 configuration knobs that might allow an operator or user to manually- 90 configure the CE Router to deviate from these recommendations. This 91 document updates RFC7084. 93 2. Requirements Language 95 Take careful note: Unlike other IETF documents, the key words "MUST", 96 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 97 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as 98 described in [RFC2119]. This document uses these keywords not 99 strictly for the purpose of interoperability, but rather for the 100 purpose of establishing industry-common baseline functionality. As 101 such, the document points to several other specifications (preferable 102 in RFC or stable form) to provide additional guidance to implementers 103 regarding any protocol implementation required to produce a 104 successful CE router that interoperates successfully with a 105 particular subset of currently deploying and planned common IPv6 106 access networks. 108 Note: the aforementioned terms are used in exactly the same way as in 109 [RFC7084], with the above explanation copied verbatim from 110 Section 1.1 of [RFC7084]. 112 3. Improved Customer Edge Router Behavior 114 This section specifies and clarifies requirements for Customer Edge 115 Routers that can help mitigate the problem discussed in Section 1, 116 particularly when they employ prefixes learned via DHCPv6-Prefix 117 Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless 118 Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on 119 the LAN-side. The recommendations in this document help improve 120 robustness at the Customer Edge Router (on which the user or ISP may 121 have no control), and do not preclude implementation of host-side 122 improvements such as those specified in [I-D.gont-6man-slaac-renum]. 124 This document specifies additional LAN-side requirements to 125 requirements L-1 through L-14 specified in [RFC7084]: 127 o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign 128 addresses or delegate prefixes via DHCPv6 on the LAN-side, 129 employing lifetimes that exceed the remaining lifetimes of the 130 corresponding prefixes learned from the WAN-side via DHCPv6-PD. 131 For more details, see Section 3.1. 133 o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes 134 and capped DHCPv6 IA Address Option and IA Prefix Option 135 lifetimes, as specified in Section 3.2. 137 o L-17: CE routers MUST signal stale configuration information as 138 specified in Section 3.3. 140 o L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 141 messages upon reboot events. 143 3.1. Interface Between WAN-side and LAN-side 145 The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information 146 Options (PIOs) [RFC4861] corresponding to prefixes learned via 147 DHCPv6-PD MUST NOT span past the remaining preferred and valid 148 lifetimes of the corresponding DHCPv6-PD prefixes. This means that 149 the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be 150 dynamically adjusted such that they never span past the remaining 151 preferred and valid lifetimes of the corresponding prefixes delegated 152 via DHCPv6-PD on the WAN-side. 154 Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA 155 Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on 156 the LAN-side MUST NOT span past the remaining preferred and valid 157 lifetimes of the corresponding prefixes leased via DHCPv6-PD on the 158 WAN-side. This means that the advertised "Preferred Lifetime" and 159 "Valid Lifetime" MUST be dynamically adjusted such that the 160 advertised lifetimes never span past the remaining preferred and 161 valid lifetimes of the corresponding prefixes delegated to the CE 162 Router on the WAN-side via DHCPv6-PD. 164 This document RECOMMENDS that CE Routers providing stateful address 165 configuration via DHCPv6 sets the DHCPv6 IA Address Option preferred- 166 lifetime to the lesser of the remaining preferred lifetime and 167 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 168 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 170 This document RECOMMENDS that a CE Router providing DHCPv6-PD on the 171 LAN-side sets the DHCPv6 IA Prefix Option preferred-lifetime to the 172 lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, 173 and the valid-lifetime of the same option to the lesser of the 174 remaining valid lifetime and ND_VALID_LIMIT. 176 RATIONALE: 178 * The lifetime values employed for the "Preferred Lifetime" 179 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 180 of SLAAC Prefix Information Options must never be larger than 181 the remaining lifetimes for the corresponding prefix (as 182 learned via DHCPv6-PD on the WAN-side). This is in line with 183 the requirement from Section 6.3 of [RFC8415], which states 184 that "if the delegated prefix or a prefix derived from it is 185 advertised for stateless address autoconfiguration [RFC4862], 186 the advertised preferred and valid lifetimes MUST NOT exceed 187 the corresponding remaining lifetimes of the delegated prefix." 189 * The lifetime values of prefixes advertised on the LAN-side via 190 SLAAC must be dynamically updated (rather than static values), 191 since otherwise the advertised lifetimes would eventually span 192 past the DHCPv6-PD lifetimes. 194 * The same considerations apply for the valid-lifetime and 195 preferred-lifetime of IA Address Options and IA Prefix Options 196 employed with DHCPv6 on the LAN-side. 198 3.2. LAN-side Option Lifetimes 200 CE Routers SHOULD override the default PIO "Preferred Lifetime" and 201 "Valid Lifetime" values from [RFC4861], and employ shorter lifetime 202 values to improve the robustness to renumbering events, while 203 complying with the requirements from Section 2.1 of this document and 204 the recommendations in [RFC7772]. 206 This document RECOMMENDS that CE router set the Router Lifetime to 207 ND_PREFERRED_LIMIT. This document also RECOMMENDS that the CE router 208 set the PIO Preferred Lifetime to the lesser of the remaining 209 preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the 210 PIO Valid Lifetime to the lesser of the remaining valid lifetime and 211 ND_VALID_LIMIT. Additionally, this document RECOMMENDS that the 212 Route Lifetime of Route Information Options (RIOs) [RFC4191], the 213 Lifetime of Recursive DNS Search Options (RDNSSO) [RFC8106], and the 214 Lifetime of DNS Search List Options (DNSSLO) [RFC8106] be set to the 215 lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option 216 (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of 217 these options are included in Router Advertisement messages. 219 This document RECOMMENDS that a CE Router providing stateful address 220 configuration via DHCPv6 set the DHCPv6 IA Address Option preferred- 221 lifetime to the lesser of the remaining preferred lifetime (see 222 Section 3.1) and ND_PREFERRED_LIMIT, and the valid-lifetime of the 223 same option to the lesser of the remaining valid lifetime and 224 ND_VALID_LIMIT. 226 This document RECOMMENDS that a CE Router providing DHCPv6-PD on the 227 LAN-side set the DHCPv6 IA Prefix Option preferred-lifetime to the 228 lesser of the remaining preferred lifetime (see Section 3.1) and 229 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 230 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 232 RATIONALE: 234 * The Valid Lifetime and Preferred Lifetime of PIOs have direct 235 impact on three different aspects: 237 + The amount of time hosts may end up employing stale network 238 configuration information (see 239 [I-D.ietf-v6ops-slaac-renum]). 241 + The amount of time CE Routers need to persist trying to 242 deprecate stale network configuration information (e.g. to 243 handle cases where nodes miss Router Advertisements and thus 244 still consider the stale information as valid). 246 + The amount of information that a CE Routers need to maintain 247 when e.g. multiple crash-and-reboot events occur in the 248 timespan represented by the option lifetimes employed on the 249 LAN-side. 251 * CE Routers need not employ the (possibly long) DHCPv6-PD 252 lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs 253 sent in Router Advertisements messages to advertise sub- 254 prefixes of the leased prefix. Instead, CPE Routers SHOULD use 255 shorter values for the Valid Lifetime and Preferred Lifetime of 256 PIOs, since subsequent Router Advertisement messages will 257 nevertheless refresh the associated lifetimes, leading to the 258 same effective lifetimes as specified by the WAN-side DHCPv6-PD 259 lifetimes. 261 * Similarly, CE Routers need not employ the (possibly long) 262 DHCPv6-PD lifetimes for the valid-lifetime and preferred- 263 lifetime of IA Address Options and IA Prefix Option employed by 264 DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 265 clients will lead to the same effective lifetimes as specified 266 by the WAN-side DHCPv6-PD lifetimes. 268 3.3. Signaling Stale Configuration Information 270 In order to phase-out stale SLAAC configuration information: 272 o A CE router sending RAs that advertise dynamically-learned 273 prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, 274 the list of prefixes being advertised on each network segment, and 275 the state of the "A" and "L" flags of the corresponding PIOs. 277 o Upon changes to the advertised prefixes, and after bootstrapping, 278 the CE router advertising prefix information via SLAAC SHOULD 279 proceed as follows: 281 * Any prefixes that were previously advertised via Router 282 Advertisement (RA) messages, but that have now become stale, 283 MUST be advertised with a "Valid Lifetime" and a "Preferred 284 Lifetime" set to 0, and the "A" and "L" bits unchanged. 286 * The aforementioned advertisement SHOULD be performed for at 287 least the "Valid Lifetime" previously employed for such prefix. 288 Note: If requirement L-16 (Section 3.2) is followed, the Valid 289 Lifetime need not be saved and the prefix can simply be 290 advertised for a period of ND_VALID_LIMIT. 292 o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- 293 lifetime MUST advertise the corresponding sub-prefixes (as they 294 would be generated for the same leased prefix with a non-zero 295 lifetime) with a PIO with both the Preferred Lifetime and the 296 Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD 297 valid-lifetime, or for period of ND_VALID_LIMIT if the recommended 298 lifetimes from Section 3.2 are employed. 300 This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 301 (address assignment or prefix delegation), the following behavior be 302 implemented: 304 o The CE Router SHOULD record, on stable storage, the DHCPv6 address 305 and delegated-prefix bindings corresponding to the LAN-side. 307 o If the CE Router finds that the prefix to be employed for address 308 assignment and/or prefix delegation has changed (e.g., upon a 309 crash-and-reboot event) or the CE Router receives DHCPv6 Prefix 310 Delegations with 0 lifetimes, the CE Router MUST: 312 * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 313 lifetimes for any address assignments or prefix delegations for 314 the deprecated prefixes for at least the valid-lifetime 315 previously employed for them, or for a period of ND_VALID_LIMIT 316 if the recommended lifetimes from Section 3.2 are employed. 318 * Initiate sending Reconfigure messages (if possible - i.e., 319 client requests Reconfigure support and the CE Router offers 320 it) to the those clients with address assignments or prefix 321 delegations for the deprecated prefixes. 323 RATIONALE: 325 * IPv6 network renumbering is expected to take place in a planned 326 manner, with old/stale prefixes being phased-out via reduced 327 prefix lifetimes while new prefixes (with normal lifetimes) are 328 introduced. However, there are a number of scenarios that may 329 lead to the so-called "flash-renumbering" events, where the 330 prefix being employed on a network suddenly becomes invalid and 331 replaced by a new prefix [I-D.ietf-v6ops-slaac-renum]. One of 332 such scenarios is that in which a DHCPv6 server employs dynamic 333 prefixes, and the Customer Edge Router crashes and reboots. 335 The requirements in this section are meant to allow Customer 336 Edge Routers to deprecate stale information in such scenarios. 338 * The recommendations in this section expand from requirement 339 L-13 in Section 4.3 of [RFC7084]. 341 * Host configuring addresses via SLAAC on the local network may 342 employ addresses configured for the previously advertised 343 prefixes for at most the "Valid Lifetime" of the corresponding 344 PIO of the last received Router Advertisement message. Since 345 Router Advertisement messages may be lost or fail to be 346 received for various reasons, Customer Edge Routers need to try 347 to deprecate stale prefixes for a period of time equal to the 348 "Valid Lifetime" of the PIO employed when originally 349 advertising the prefix. 351 * The requirement in this section is conveyed as a "SHOULD" (as 352 opposed to a "MUST"), since we acknowledge that the requirement 353 to store information on stable storage may represent a 354 challenge for some implementations. 356 * Advertising DHCPv6-leased prefixes with zero lifetimes on the 357 LAN-side would handle the case where a CE Router has no stable 358 storage but receives the prefixes via DHCPv6 with 0 lifetimes. 360 4. Recommended Option Lifetimes Configuration Values 362 o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) 364 o ND_VALID_LIMIT: 5400 seconds (90 minutes) 366 5. IANA Considerations 368 This document has no actions for IANA. 370 6. Security Considerations 372 This document discusses a problem that may arise in scenarios where 373 dynamic IPv6 prefixes are employed, and proposes improvements to 374 Customer Edge Routers [RFC7084] to mitigate the problem for 375 residential or small office scenarios. It does not introduce new 376 security issues. 378 7. Acknowledgments 380 The authors would like to thank Owen DeLong, Philip Homburg, and Ted 381 Lemon, for their valuable help in improving this document via 382 successive detailed reviews. 384 The authors would like to thank Mikael Abrahamsson, Brian Carpenter, 385 Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Erik Kline, 386 Olorunloba Olopade, Mark Smith, Job Snijders, Sander Steffann, Ole 387 Troan, Loganaden Velvindron, Timothy Winters, and Chongfeng Xie, for 388 providing valuable comments on earlier versions of this document. 390 The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim 391 Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick 392 Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, 393 Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael 394 Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for 395 providing valuable comments on [I-D.gont-6man-slaac-renum], on which 396 this document is based. 398 Fernando would also like to thank Brian Carpenter who, over the 399 years, has answered many questions and provided valuable comments 400 that has benefited his protocol-related work. 402 8. References 404 8.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 412 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 413 November 2005, . 415 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 416 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 417 DOI 10.17487/RFC4861, September 2007, 418 . 420 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 421 Address Autoconfiguration", RFC 4862, 422 DOI 10.17487/RFC4862, September 2007, 423 . 425 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 426 Consumption of Router Advertisements", BCP 202, RFC 7772, 427 DOI 10.17487/RFC7772, February 2016, 428 . 430 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 431 "IPv6 Router Advertisement Options for DNS Configuration", 432 RFC 8106, DOI 10.17487/RFC8106, March 2017, 433 . 435 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 436 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 437 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 438 RFC 8415, DOI 10.17487/RFC8415, November 2018, 439 . 441 8.2. Informative References 443 [I-D.gont-6man-slaac-renum] 444 Gont, F., Zorz, J., and R. Patterson, "Improving the 445 Robustness of Stateless Address Autoconfiguration (SLAAC) 446 to Flash Renumbering Events", draft-gont-6man-slaac- 447 renum-08 (work in progress), May 2020. 449 [I-D.ietf-v6ops-slaac-renum] 450 Gont, F., Zorz, J., and R. Patterson, "Reaction of 451 Stateless Address Autoconfiguration (SLAAC) to Flash- 452 Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work 453 in progress), May 2020. 455 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 456 Requirements for IPv6 Customer Edge Routers", RFC 7084, 457 DOI 10.17487/RFC7084, November 2013, 458 . 460 Authors' Addresses 462 Fernando Gont 463 SI6 Networks 464 Segurola y Habana 4310, 7mo Piso 465 Villa Devoto, Ciudad Autonoma de Buenos Aires 466 Argentina 468 Email: fgont@si6networks.com 469 URI: https://www.si6networks.com 470 Jan Zorz 471 Go6 Institute 472 Frankovo naselje 165 473 Skofja Loka 4220 474 Slovenia 476 Email: jan@go6.si 477 URI: https://www.go6.si 479 Richard Patterson 480 Sky UK 482 Email: richard.patterson@sky.uk 484 Bernie Volz 485 Cisco Systems, Inc. 486 1414 Massachusetts Ave 487 Boxborough, MA 01719 488 USA 490 Email: volz@cisco.com