idnits 2.17.1 draft-ietf-v6ops-cpe-slaac-renum-05.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 (September 28, 2020) is 1303 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-6man-slaac-renum-01 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-03 Summary: 0 errors (**), 0 flaws (~~), 4 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 6connect 6 Expires: April 1, 2021 R. Patterson 7 Sky UK 8 B. Volz 9 Cisco 10 September 28, 2020 12 Improving the Reaction of Customer Edge Routers to Renumbering Events 13 draft-ietf-v6ops-cpe-slaac-renum-05 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 April 1, 2021. 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 . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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.ietf-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 CE Routers providing stateful address configuration via DHCPv6 SHOULD 165 set the DHCPv6 IA Address Option preferred-lifetime to the lesser of 166 the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the 167 valid-lifetime of the same option to the lesser of the remaining 168 valid lifetime and ND_VALID_LIMIT. 170 CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 171 IA Prefix Option preferred-lifetime to the lesser of the remaining 172 preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of 173 the same option to the lesser of the remaining valid lifetime and 174 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 otherwise the advertised lifetimes would eventually span past 192 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 CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. CE 207 routers SHOULD also set the PIO Preferred Lifetime to the lesser of 208 the remaining preferred lifetime (see Section 3.1) and 209 ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the 210 remaining valid lifetime and ND_VALID_LIMIT. Additionally, the Route 211 Lifetime of Route Information Options (RIOs) [RFC4191], the Lifetime 212 of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime 213 of DNS Search List Options (DNSSLO) [RFC8106] SHOULD be set to the 214 lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option 215 (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of 216 these options are included in Router Advertisement messages. 218 CE Routers providing stateful address configuration via DHCPv6 SHOULD 219 set the DHCPv6 IA Address Option preferred-lifetime to the lesser of 220 the remaining preferred lifetime (see Section 3.1) and 221 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 222 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 224 CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 225 IA Prefix Option preferred-lifetime to the lesser of the remaining 226 preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the 227 valid-lifetime of the same option to the lesser of the remaining 228 valid lifetime and ND_VALID_LIMIT. 230 RATIONALE: 232 * The Valid Lifetime and Preferred Lifetime of PIOs have a direct 233 impact on three different aspects: 235 + The amount of time hosts may end up employing stale network 236 configuration information (see 237 [I-D.ietf-v6ops-slaac-renum]). 239 + The amount of time CE Routers need to persist trying to 240 deprecate stale network configuration information (e.g. to 241 handle cases where nodes miss Router Advertisements and thus 242 still consider the stale information as valid). 244 + The amount of information that CE Routers need to maintain 245 when e.g. multiple crash-and-reboot events occur in the 246 timespan represented by the option lifetimes employed on the 247 LAN-side. 249 * CE Routers need not employ the (possibly long) DHCPv6-PD 250 lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs 251 sent in Router Advertisements messages to advertise sub- 252 prefixes of the leased prefix. Instead, CPE Routers SHOULD use 253 shorter values for the Valid Lifetime and Preferred Lifetime of 254 PIOs, since subsequent Router Advertisement messages will 255 nevertheless refresh the associated lifetimes, leading to the 256 same effective lifetimes as specified by the WAN-side DHCPv6-PD 257 lifetimes. 259 * Similarly, CE Routers need not employ the (possibly long) 260 DHCPv6-PD lifetimes for the valid-lifetime and preferred- 261 lifetime of IA Address Options and IA Prefix Option employed by 262 DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 263 clients will lead to the same effective lifetimes as specified 264 by the WAN-side DHCPv6-PD lifetimes. 266 3.3. Signaling Stale Configuration Information 268 In order to phase-out stale SLAAC configuration information: 270 o A CE router sending RAs that advertise dynamically-learned 271 prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, 272 the list of prefixes being advertised on each network segment, and 273 the state of the "A" and "L" flags of the corresponding PIOs. 275 o Upon changes to the advertised prefixes, and after bootstrapping, 276 the CE Router advertising prefix information via SLAAC proceeds as 277 follows: 279 * Any prefixes that were previously advertised via Router 280 Advertisement (RA) messages, but that have now become stale, 281 MUST be advertised with a "Valid Lifetime" and a "Preferred 282 Lifetime" set to 0, and the "A" and "L" bits unchanged. 284 * The aforementioned advertisement SHOULD be performed for at 285 least the "Valid Lifetime" previously employed for such prefix. 286 Note: If requirement L-16 (Section 3.2) is followed, the Valid 287 Lifetime need not be saved and the prefix can simply be 288 advertised for a period of ND_VALID_LIMIT. 290 o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- 291 lifetime MUST advertise the corresponding sub-prefixes (as they 292 would be generated for the same leased prefix with a non-zero 293 lifetime) with a PIO with both the Preferred Lifetime and the 294 Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD 295 valid-lifetime, or for a period of ND_VALID_LIMIT if the 296 recommended lifetimes from Section 3.2 are employed. 298 If a CE Router provides LAN-side DHCPv6 (address assignment or prefix 299 delegation), then: 301 o The CE Router SHOULD record, on stable storage, the DHCPv6 address 302 and delegated-prefix bindings corresponding to the LAN-side. 304 o If the CE Router finds that the prefix to be employed for address 305 assignment and/or prefix delegation has changed (e.g., upon a 306 crash-and-reboot event) or the CE Router receives DHCPv6 Prefix 307 Delegations with 0 lifetimes, the CE Router MUST: 309 * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 310 lifetimes for any address assignments or prefix delegations for 311 the deprecated prefixes for at least the valid-lifetime 312 previously employed for them, or for a period of ND_VALID_LIMIT 313 if the recommended lifetimes from Section 3.2 are employed. 315 * Initiate sending Reconfigure messages (if possible - i.e., 316 client requests Reconfigure support and the CE Router offers 317 it) to those clients with address assignments or prefix 318 delegations for the deprecated prefixes. 320 RATIONALE: 322 * IPv6 network renumbering is expected to take place in a planned 323 manner, with old/stale prefixes being phased-out via reduced 324 prefix lifetimes while new prefixes (with normal lifetimes) are 325 introduced. However, a number of scenarios may lead to the so- 326 called "flash-renumbering" events, where the prefix being 327 employed on a network suddenly becomes invalid and replaced by 328 a new prefix [I-D.ietf-v6ops-slaac-renum]. One such scenario 329 is when a DHCPv6 server employs dynamic prefixes and the 330 Customer Edge Router crashes and reboots. The requirements in 331 this section are meant to allow Customer Edge Routers to 332 deprecate stale information in such scenarios. 334 * The recommendations in this section expand from requirement 335 L-13 in Section 4.3 of [RFC7084]. 337 * Host configuring addresses via SLAAC on the local network may 338 employ addresses configured for the previously advertised 339 prefixes for at most the "Valid Lifetime" of the corresponding 340 PIO of the last received Router Advertisement message. Since 341 Router Advertisement messages may be lost or fail to be 342 received for various reasons, Customer Edge Routers need to try 343 to deprecate stale prefixes for a period of time equal to the 344 "Valid Lifetime" of the PIO employed when originally 345 advertising the prefix. 347 * The requirement in this section is conveyed as a "SHOULD" (as 348 opposed to a "MUST"), since we acknowledge that the requirement 349 to store information on stable storage may represent a 350 challenge for some implementations. 352 * Advertising DHCPv6-leased prefixes with zero lifetimes on the 353 LAN-side would handle the case where a CE Router has no stable 354 storage but receives the prefixes via DHCPv6 with 0 lifetimes. 356 4. Recommended Option Lifetimes Configuration Values 358 o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) 360 o ND_VALID_LIMIT: 5400 seconds (90 minutes) 362 RATIONALE: 363 These values represent a trade-off among a number of factors, 364 including responsiveness and possible impact on the battery life 365 of connected devices [RFC7772]. 367 ND_PREFERRED_LIMIT is set according to the recommendations in 368 [RFC7772] for Router Lifetime, following the rationale from 369 Section 3.2 of [I-D.ietf-v6ops-slaac-renum]. 371 ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some 372 additional leeway before configuration information is finally 373 discarded by the host. 375 5. IANA Considerations 377 This document has no actions for IANA. 379 6. Security Considerations 381 This document discusses a problem that may arise in scenarios where 382 dynamic IPv6 prefixes are employed, and proposes improvements to 383 Customer Edge Routers [RFC7084] to mitigate the problem for 384 residential or small office scenarios. It does not introduce new 385 security issues. 387 7. Acknowledgments 389 The authors would like to thank Owen DeLong, Philip Homburg, and Ted 390 Lemon, for their valuable help in improving this document via 391 successive detailed reviews. 393 The authors would like to thank Mikael Abrahamsson, Brian Carpenter, 394 Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo 395 Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade, 396 Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan, 397 Loganaden Velvindron, Timothy Winters, Christopher Wood, and 398 Chongfeng Xie, for providing valuable comments on earlier versions of 399 this document. 401 The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim 402 Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick 403 Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, 404 Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael 405 Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for 406 providing valuable comments on [I-D.gont-6man-slaac-renum], on which 407 this document is based. 409 Fernando would also like to thank Brian Carpenter who, over the 410 years, has answered many questions and provided valuable comments 411 that have benefited his protocol-related work. 413 8. References 415 8.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 423 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 424 November 2005, . 426 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 427 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 428 DOI 10.17487/RFC4861, September 2007, 429 . 431 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 432 Address Autoconfiguration", RFC 4862, 433 DOI 10.17487/RFC4862, September 2007, 434 . 436 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 437 Consumption of Router Advertisements", BCP 202, RFC 7772, 438 DOI 10.17487/RFC7772, February 2016, 439 . 441 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 442 "IPv6 Router Advertisement Options for DNS Configuration", 443 RFC 8106, DOI 10.17487/RFC8106, March 2017, 444 . 446 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 447 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 448 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 449 RFC 8415, DOI 10.17487/RFC8415, November 2018, 450 . 452 8.2. Informative References 454 [I-D.gont-6man-slaac-renum] 455 Gont, F., Zorz, J., and R. Patterson, "Improving the 456 Robustness of Stateless Address Autoconfiguration (SLAAC) 457 to Flash Renumbering Events", draft-gont-6man-slaac- 458 renum-08 (work in progress), May 2020. 460 [I-D.ietf-6man-slaac-renum] 461 Gont, F., Zorz, J., and R. Patterson, "Improving the 462 Robustness of Stateless Address Autoconfiguration (SLAAC) 463 to Flash Renumbering Events", draft-ietf-6man-slaac- 464 renum-01 (work in progress), August 2020. 466 [I-D.ietf-v6ops-slaac-renum] 467 Gont, F., Zorz, J., and R. Patterson, "Reaction of 468 Stateless Address Autoconfiguration (SLAAC) to Flash- 469 Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work 470 in progress), August 2020. 472 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 473 Requirements for IPv6 Customer Edge Routers", RFC 7084, 474 DOI 10.17487/RFC7084, November 2013, 475 . 477 Authors' Addresses 479 Fernando Gont 480 SI6 Networks 481 Segurola y Habana 4310, 7mo Piso 482 Villa Devoto, Ciudad Autonoma de Buenos Aires 483 Argentina 485 Email: fgont@si6networks.com 486 URI: https://www.si6networks.com 488 Jan Zorz 489 6connect 491 Email: jan@connect.com 493 Richard Patterson 494 Sky UK 496 Email: richard.patterson@sky.uk 498 Bernie Volz 499 Cisco Systems, Inc. 500 1414 Massachusetts Ave 501 Boxborough, MA 01719 502 USA 504 Email: volz@cisco.com