idnits 2.17.1 draft-ietf-v6ops-cpe-slaac-renum-06.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 date (December 11, 2020) is 1231 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-6man-slaac-renum-01 Summary: 0 errors (**), 0 flaws (~~), 2 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: Best Current Practice 6connect 6 Expires: June 14, 2021 R. Patterson 7 Sky UK 8 B. Volz 9 Cisco 10 December 11, 2020 12 Improving the Reaction of Customer Edge Routers to Renumbering Events 13 draft-ietf-v6ops-cpe-slaac-renum-06 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 June 14, 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 . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Improved Customer Edge Router Behavior 103 This section specifies and clarifies requirements for Customer Edge 104 Routers that can help mitigate the problem discussed in Section 1, 105 particularly when they employ prefixes learned via DHCPv6-Prefix 106 Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless 107 Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on 108 the LAN-side. The recommendations in this document help improve 109 robustness at the Customer Edge Router (on which the user or ISP may 110 have no control), and do not preclude implementation of host-side 111 improvements such as those specified in [I-D.ietf-6man-slaac-renum]. 113 This document specifies additional LAN-side requirements to 114 requirements L-1 through L-14 specified in [RFC7084]: 116 o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign 117 addresses or delegate prefixes via DHCPv6 on the LAN-side, 118 employing lifetimes that exceed the remaining lifetimes of the 119 corresponding prefixes learned from the WAN-side via DHCPv6-PD. 120 For more details, see Section 3.1. 122 o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes 123 and capped DHCPv6 IA Address Option and IA Prefix Option 124 lifetimes, as specified in Section 3.2. 126 o L-17: CE routers MUST signal stale configuration information as 127 specified in Section 3.3. 129 o L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 130 messages upon reboot events. 132 3.1. Interface Between WAN-side and LAN-side 134 The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information 135 Options (PIOs) [RFC4861] corresponding to prefixes learned via 136 DHCPv6-PD MUST NOT span past the remaining preferred and valid 137 lifetimes of the corresponding DHCPv6-PD prefixes. This means that 138 the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be 139 dynamically adjusted such that they never span past the remaining 140 preferred and valid lifetimes of the corresponding prefixes delegated 141 via DHCPv6-PD on the WAN-side. 143 Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA 144 Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on 145 the LAN-side MUST NOT span past the remaining preferred and valid 146 lifetimes of the corresponding prefixes leased via DHCPv6-PD on the 147 WAN-side. This means that the advertised "Preferred Lifetime" and 148 "Valid Lifetime" MUST be dynamically adjusted such that the 149 advertised lifetimes never span past the remaining preferred and 150 valid lifetimes of the corresponding prefixes delegated to the CE 151 Router on the WAN-side via DHCPv6-PD. 153 CE Routers providing stateful address configuration via DHCPv6 SHOULD 154 set the DHCPv6 IA Address Option preferred-lifetime to the lesser of 155 the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the 156 valid-lifetime of the same option to the lesser of the remaining 157 valid lifetime and ND_VALID_LIMIT. 159 CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 160 IA Prefix Option preferred-lifetime to the lesser of the remaining 161 preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of 162 the same option to the lesser of the remaining valid lifetime and 163 ND_VALID_LIMIT. 165 RATIONALE: 167 * The lifetime values employed for the "Preferred Lifetime" 168 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 169 of SLAAC Prefix Information Options must never be larger than 170 the remaining lifetimes for the corresponding prefix (as 171 learned via DHCPv6-PD on the WAN-side). This is in line with 172 the requirement from Section 6.3 of [RFC8415], which states 173 that "if the delegated prefix or a prefix derived from it is 174 advertised for stateless address autoconfiguration [RFC4862], 175 the advertised preferred and valid lifetimes MUST NOT exceed 176 the corresponding remaining lifetimes of the delegated prefix." 178 * The lifetime values of prefixes advertised on the LAN-side via 179 SLAAC must be dynamically updated (rather than static values), 180 otherwise the advertised lifetimes would eventually span past 181 the DHCPv6-PD lifetimes. 183 * The same considerations apply for the valid-lifetime and 184 preferred-lifetime of IA Address Options and IA Prefix Options 185 employed with DHCPv6 on the LAN-side. 187 3.2. LAN-side Option Lifetimes 189 CE Routers SHOULD override the default PIO "Preferred Lifetime" and 190 "Valid Lifetime" values from [RFC4861], and employ shorter lifetime 191 values to improve the robustness to renumbering events, while 192 complying with the requirements from Section 2.1 of this document and 193 the recommendations in [RFC7772]. 195 CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. CE 196 routers SHOULD also set the PIO Preferred Lifetime to the lesser of 197 the remaining preferred lifetime (see Section 3.1) and 198 ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the 199 remaining valid lifetime and ND_VALID_LIMIT. Additionally, the Route 200 Lifetime of Route Information Options (RIOs) [RFC4191], the Lifetime 201 of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime 202 of DNS Search List Options (DNSSLO) [RFC8106] SHOULD be set to the 203 lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option 204 (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of 205 these options are included in Router Advertisement messages. 207 CE Routers providing stateful address configuration via DHCPv6 SHOULD 208 set the DHCPv6 IA Address Option preferred-lifetime to the lesser of 209 the remaining preferred lifetime (see Section 3.1) and 210 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 211 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 213 CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 214 IA Prefix Option preferred-lifetime to the lesser of the remaining 215 preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the 216 valid-lifetime of the same option to the lesser of the remaining 217 valid lifetime and ND_VALID_LIMIT. 219 RATIONALE: 221 * The Valid Lifetime and Preferred Lifetime of PIOs have a direct 222 impact on three different aspects: 224 + The amount of time hosts may end up employing stale network 225 configuration information (see 226 [I-D.ietf-v6ops-slaac-renum]). 228 + The amount of time CE Routers need to persist trying to 229 deprecate stale network configuration information (e.g. to 230 handle cases where nodes miss Router Advertisements and thus 231 still consider the stale information as valid). 233 + The amount of information that CE Routers need to maintain 234 when e.g. multiple crash-and-reboot events occur in the 235 timespan represented by the option lifetimes employed on the 236 LAN-side. 238 * CE Routers need not employ the (possibly long) DHCPv6-PD 239 lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs 240 sent in Router Advertisements messages to advertise sub- 241 prefixes of the leased prefix. Instead, CPE Routers SHOULD use 242 shorter values for the Valid Lifetime and Preferred Lifetime of 243 PIOs, since subsequent Router Advertisement messages will 244 nevertheless refresh the associated lifetimes, leading to the 245 same effective lifetimes as specified by the WAN-side DHCPv6-PD 246 lifetimes. 248 * Similarly, CE Routers need not employ the (possibly long) 249 DHCPv6-PD lifetimes for the valid-lifetime and preferred- 250 lifetime of IA Address Options and IA Prefix Option employed by 251 DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 252 clients will lead to the same effective lifetimes as specified 253 by the WAN-side DHCPv6-PD lifetimes. 255 3.3. Signaling Stale Configuration Information 257 In order to phase-out stale SLAAC configuration information: 259 o A CE router sending RAs that advertise dynamically-learned 260 prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, 261 the list of prefixes being advertised on each network segment, and 262 the state of the "A" and "L" flags of the corresponding PIOs. 264 o Upon changes to the advertised prefixes, and after bootstrapping, 265 the CE Router advertising prefix information via SLAAC proceeds as 266 follows: 268 * Any prefixes that were previously advertised via Router 269 Advertisement (RA) messages, but that have now become stale, 270 MUST be advertised with a "Valid Lifetime" and a "Preferred 271 Lifetime" set to 0, and the "A" and "L" bits unchanged. 273 * The aforementioned advertisement SHOULD be performed for at 274 least the "Valid Lifetime" previously employed for such prefix. 275 Note: If requirement L-16 (Section 3.2) is followed, the Valid 276 Lifetime need not be saved and the prefix can simply be 277 advertised for a period of ND_VALID_LIMIT. 279 o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- 280 lifetime MUST advertise the corresponding sub-prefixes (as they 281 would be generated for the same leased prefix with a non-zero 282 lifetime) with a PIO with both the Preferred Lifetime and the 283 Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD 284 valid-lifetime, or for a period of ND_VALID_LIMIT if the 285 recommended lifetimes from Section 3.2 are employed. 287 If a CE Router provides LAN-side DHCPv6 (address assignment or prefix 288 delegation), then: 290 o The CE Router SHOULD record, on stable storage, the DHCPv6 address 291 and delegated-prefix bindings corresponding to the LAN-side. 293 o If the CE Router finds that the prefix to be employed for address 294 assignment and/or prefix delegation has changed (e.g., upon a 295 crash-and-reboot event) or the CE Router receives DHCPv6 Prefix 296 Delegations with 0 lifetimes, the CE Router MUST: 298 * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 299 lifetimes for any address assignments or prefix delegations for 300 the deprecated prefixes for at least the valid-lifetime 301 previously employed for them, or for a period of ND_VALID_LIMIT 302 if the recommended lifetimes from Section 3.2 are employed. 304 * Initiate sending Reconfigure messages (if possible - i.e., 305 client requests Reconfigure support and the CE Router offers 306 it) to those clients with address assignments or prefix 307 delegations for the deprecated prefixes. 309 RATIONALE: 311 * IPv6 network renumbering is expected to take place in a planned 312 manner, with old/stale prefixes being phased-out via reduced 313 prefix lifetimes while new prefixes (with normal lifetimes) are 314 introduced. However, a number of scenarios may lead to the so- 315 called "flash-renumbering" events, where the prefix being 316 employed on a network suddenly becomes invalid and replaced by 317 a new prefix [I-D.ietf-v6ops-slaac-renum]. One such scenario 318 is when a DHCPv6 server employs dynamic prefixes and the 319 Customer Edge Router crashes and reboots. The requirements in 320 this section are meant to allow Customer Edge Routers to 321 deprecate stale information in such scenarios. 323 * The recommendations in this section expand from requirement 324 L-13 in Section 4.3 of [RFC7084]. 326 * Host configuring addresses via SLAAC on the local network may 327 employ addresses configured for the previously advertised 328 prefixes for at most the "Valid Lifetime" of the corresponding 329 PIO of the last received Router Advertisement message. Since 330 Router Advertisement messages may be lost or fail to be 331 received for various reasons, Customer Edge Routers need to try 332 to deprecate stale prefixes for a period of time equal to the 333 "Valid Lifetime" of the PIO employed when originally 334 advertising the prefix. 336 * The requirement in this section is conveyed as a "SHOULD" (as 337 opposed to a "MUST"), since we acknowledge that the requirement 338 to store information on stable storage may represent a 339 challenge for some implementations. 341 * Advertising DHCPv6-leased prefixes with zero lifetimes on the 342 LAN-side would handle the case where a CE Router has no stable 343 storage but receives the prefixes via DHCPv6 with 0 lifetimes. 345 4. Recommended Option Lifetimes Configuration Values 347 o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) 349 o ND_VALID_LIMIT: 5400 seconds (90 minutes) 351 RATIONALE: 352 These values represent a trade-off among a number of factors, 353 including responsiveness and possible impact on the battery life 354 of connected devices [RFC7772]. 356 ND_PREFERRED_LIMIT is set according to the recommendations in 357 [RFC7772] for Router Lifetime, following the rationale from 358 Section 3.2 of [I-D.ietf-v6ops-slaac-renum]. 360 ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some 361 additional leeway before configuration information is finally 362 discarded by the host. 364 5. IANA Considerations 366 This document has no actions for IANA. 368 6. Security Considerations 370 This document discusses a problem that may arise in scenarios where 371 dynamic IPv6 prefixes are employed, and proposes improvements to 372 Customer Edge Routers [RFC7084] to mitigate the problem for 373 residential or small office scenarios. It does not introduce new 374 security issues. 376 7. Acknowledgments 378 The authors would like to thank Owen DeLong, Philip Homburg, and Ted 379 Lemon, for their valuable help in improving this document via 380 successive detailed reviews. 382 The authors would like to thank Mikael Abrahamsson, Brian Carpenter, 383 Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo 384 Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade, 385 Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan, 386 Loganaden Velvindron, Timothy Winters, Christopher Wood, and 387 Chongfeng Xie, for providing valuable comments on earlier versions of 388 this document. 390 The authors would like to thank Mikael Abrahamsson, Luis Balbinot, 391 Tim Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, 392 Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted 393 Lemon, Albert Manfredi, Jordi Palet Martinez, Richard Patterson, 394 Michael Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole 395 Troan, for providing valuable comments on 396 [I-D.gont-6man-slaac-renum], on which 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 have 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 436 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 437 May 2017, . 439 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 440 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 441 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 442 RFC 8415, DOI 10.17487/RFC8415, November 2018, 443 . 445 8.2. Informative References 447 [I-D.gont-6man-slaac-renum] 448 Gont, F., Zorz, J., and R. Patterson, "Improving the 449 Robustness of Stateless Address Autoconfiguration (SLAAC) 450 to Flash Renumbering Events", draft-gont-6man-slaac- 451 renum-08 (work in progress), May 2020. 453 [I-D.ietf-6man-slaac-renum] 454 Gont, F., Zorz, J., and R. Patterson, "Improving the 455 Robustness of Stateless Address Autoconfiguration (SLAAC) 456 to Flash Renumbering Events", draft-ietf-6man-slaac- 457 renum-01 (work in progress), August 2020. 459 [I-D.ietf-v6ops-slaac-renum] 460 Gont, F., Zorz, J., and R. Patterson, "Reaction of 461 Stateless Address Autoconfiguration (SLAAC) to Flash- 462 Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work 463 in progress), November 2020. 465 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 466 Requirements for IPv6 Customer Edge Routers", RFC 7084, 467 DOI 10.17487/RFC7084, November 2013, 468 . 470 Authors' Addresses 472 Fernando Gont 473 SI6 Networks 474 Segurola y Habana 4310, 7mo Piso 475 Villa Devoto, Ciudad Autonoma de Buenos Aires 476 Argentina 478 Email: fgont@si6networks.com 479 URI: https://www.si6networks.com 481 Jan Zorz 482 6connect 484 Email: jan@6connect.com 486 Richard Patterson 487 Sky UK 489 Email: richard.patterson@sky.uk 491 Bernie Volz 492 Cisco Systems, Inc. 493 1414 Massachusetts Ave 494 Boxborough, MA 01719 495 USA 497 Email: volz@cisco.com