idnits 2.17.1 draft-ietf-v6ops-cpe-slaac-renum-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 103: '...L-15: CE routers MUST NOT advertise pr...' RFC 2119 keyword, line 109: '...L-16: CE routers SHOULD advertise capp...' RFC 2119 keyword, line 113: '...L-17: CE routers MUST signal stale con...' RFC 2119 keyword, line 116: '...L-18: CE routers SHOULD NOT automatica...' RFC 2119 keyword, line 123: '... DHCPv6-PD MUST NOT span past the re...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2020) is 1433 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-gont-6man-slaac-renum-07 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-02 Summary: 1 error (**), 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 19, 2020 R. Patterson 7 Sky UK 8 B. Volz 9 Cisco 10 May 18, 2020 12 Improving the Reaction of Customer Edge Routers to Renumbering Events 13 draft-ietf-v6ops-cpe-slaac-renum-02 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 19, 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. Improved Customer Edge Router Behavior . . . . . . . . . . . 2 64 2.1. Interface Between WAN-side and LAN-side . . . . . . . . . 3 65 2.2. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 4 66 2.3. Signaling Stale Configuration Information . . . . . . . . 6 67 3. Recommended Option Lifetimes Configuration Values . . . . . . 8 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 In scenarios where network configuration information becomes invalid 79 without any explicit signaling of that condition, nodes on the local 80 network will continue using stale information for an unacceptably 81 long period of time, thus resulting in connectivity problems. This 82 problem is documented in detail in [I-D.ietf-v6ops-slaac-renum]. 84 This document specifies improvements to Customer Edge (CE) Routers 85 that help mitigate the aforementioned problem for residential and 86 small office scenarios. This document updates RFC7084. 88 2. Improved Customer Edge Router Behavior 90 This section specifies and clarifies requirements for Customer Edge 91 Routers that can help mitigate the problem discussed in Section 1, 92 particularly when they employ prefixes learned via DHCPv6-Prefix 93 Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless 94 Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on 95 the LAN-side. The recommendations in this document help improve 96 robustness at the Customer Edge Router (on which the user or ISP may 97 have no control), and do not preclude implementation of host-side 98 improvements such as those specified in [I-D.gont-6man-slaac-renum]. 100 This document specifies additional LAN-side requirements to 101 requirements L-1 through L-14 specified in [RFC7084]: 103 o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign 104 addresses or delegate prefixes via DHCPv6 on the LAN-side, 105 employing lifetimes that exceed the remaining lifetimes of the 106 corresponding prefixes learned from the WAN-side via DHCPv6-PD. 107 For more details, see Section 2.1. 109 o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes 110 and capped DHCPv6 IA Address Option and IA Prefix Option 111 lifetimes, as specified in Section 2.2. 113 o L-17: CE routers MUST signal stale configuration information as 114 specified in Section 2.3. 116 o L-18: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 117 messages upon reboot events. 119 2.1. Interface Between WAN-side and LAN-side 121 The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information 122 Options (PIOs) [RFC4861] corresponding to prefixes learned via 123 DHCPv6-PD MUST NOT span past the remaining preferred and valid 124 lifetimes of the corresponding DHCPv6-PD prefixes. This means that 125 the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be 126 dynamically adjusted such that they never span past the remaining 127 preferred and valid lifetimes of the corresponding prefixes delegated 128 via DHCPv6-PD on the WAN-side. 130 Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA 131 Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on 132 the LAN-side MUST NOT span past the remaining preferred and valid 133 lifetimes of the corresponding prefixes leased via DHCPv6-PD on the 134 WAN-side. This means that the advertised "Preferred Lifetime" and 135 "Valid Lifetime" MUST be dynamically adjusted such that the 136 advertised lifetimes never span past the remaining preferred and 137 valid lifetimes of the corresponding prefixes delegated to the CE 138 Router on the WAN-side via DHCPv6-PD. 140 This document RECOMMENDS that CE Routers providing stateful address 141 configuration via DHCPv6 sets the DHCPv6 IA Address Option preferred- 142 lifetime to the lesser of the remaining preferred lifetime and 143 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 144 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 146 This document RECOMMENDS that a CE Router providing DHCPv6-PD on the 147 LAN-side sets the DHCPv6 IA Prefix Option preferred-lifetime to the 148 lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, 149 and the valid-lifetime of the same option to the lesser of the 150 remaining valid lifetime and ND_VALID_LIMIT. 152 RATIONALE: 154 * The lifetime values employed for the "Preferred Lifetime" 155 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 156 of SLAAC Prefix Information Options must never be larger than 157 the remaining lifetimes for the corresponding prefix (as 158 learned via DHCPv6-PD on the WAN-side). This is in line with 159 the requirement from Section 6.3 of [RFC8415], which states 160 that "if the delegated prefix or a prefix derived from it is 161 advertised for stateless address autoconfiguration [RFC4862], 162 the advertised preferred and valid lifetimes MUST NOT exceed 163 the corresponding remaining lifetimes of the delegated prefix." 165 * The lifetime values of prefixes advertised on the LAN-side via 166 SLAAC must be dynamically updated (rather than static values), 167 since otherwise the advertised lifetimes would eventually span 168 past the DHCPv6-PD lifetimes. 170 * The same considerations apply for the valid-lifetime and 171 preferred-lifetime of IA Address Options and IA Prefix Options 172 employed with DHCPv6 on the LAN-side. 174 2.2. LAN-side Option Lifetimes 176 CE Routers SHOULD override the default PIO "Preferred Lifetime" and 177 "Valid Lifetime" values from [RFC4861], and employ shorter lifetime 178 values to improve the robustness to renumbering events, while 179 complying with the requirements from Section 2.1 of this document and 180 the recommendations in [RFC7772]. 182 This document RECOMMENDS that CE router set the Router Lifetime to 183 ND_PREFERRED_LIMIT. This document also RECOMMENDS that the CE router 184 set the PIO Preferred Lifetime to the lesser of the remaining 185 preferred lifetime (see Section 2.1) and ND_PREFERRED_LIMIT, and the 186 PIO Valid Lifetime to the lesser of the remaining valid lifetime and 187 ND_VALID_LIMIT. Additionally, this document RECOMMENDS that the 188 Route Lifetime of Route Information Options (RIOs) [RFC4191], the 189 Lifetime of Recursive DNS Search Options (RDNSSO) [RFC8106], and the 190 Lifetime of DNS Search List Options (DNSSLO) [RFC8106] be set to the 191 lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option 192 (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of 193 these options are included in Router Advertisement messages. 195 This document RECOMMENDS that a CE Router providing stateful address 196 configuration via DHCPv6 set the DHCPv6 IA Address Option preferred- 197 lifetime to the lesser of the remaining preferred lifetime (see 198 Section 2.1) and ND_PREFERRED_LIMIT, and the valid-lifetime of the 199 same option to the lesser of the remaining valid lifetime and 200 ND_VALID_LIMIT. 202 This document RECOMMENDS that a CE Router providing DHCPv6-PD on the 203 LAN-side set the DHCPv6 IA Prefix Option preferred-lifetime to the 204 lesser of the remaining preferred lifetime (see Section 2.1) and 205 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 206 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 208 RATIONALE: 210 * The Valid Lifetime and Preferred Lifetime of PIOs have direct 211 impact on three different aspects: 213 + The amount of time hosts may end up employing stale network 214 configuration information (see 215 [I-D.ietf-v6ops-slaac-renum]). 217 + The amount of time CE Routers need to persist trying to 218 deprecate stale network configuration information (e.g. to 219 handle cases where nodes miss Router Advertisements and thus 220 still consider the stale information as valid). 222 + The amount of information that a CE Routers need to maintain 223 when e.g. multiple crash-and-reboot events occur in the 224 timespan represented by the option lifetimes employed on the 225 LAN-side. 227 * CE Routers need not employ the (possibly long) DHCPv6-PD 228 lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs 229 sent in Router Advertisements messages to advertise sub- 230 prefixes of the leased prefix. Instead, CPE Routers SHOULD use 231 shorter values for the Valid Lifetime and Preferred Lifetime of 232 PIOs, since subsequent Router Advertisement messages will 233 nevertheless refresh the associated lifetimes, leading to the 234 same effective lifetimes as specified by the WAN-side DHCPv6-PD 235 lifetimes. 237 * Similarly, CE Routers need not employ the (possibly long) 238 DHCPv6-PD lifetimes for the valid-lifetime and preferred- 239 lifetime of IA Address Options and IA Prefix Option employed by 240 DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 241 clients will lead to the same effective lifetimes as specified 242 by the WAN-side DHCPv6-PD lifetimes. 244 2.3. Signaling Stale Configuration Information 246 In order to phase-out stale SLAAC configuration information: 248 o A CE router sending RAs that advertise dynamically-learned 249 prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, 250 the list of prefixes being advertised on each network segment, and 251 the state of the "A" and "L" flags of the corresponding PIOs. 253 o Upon changes to the advertised prefixes, and after bootstrapping, 254 the CE router advertising prefix information via SLAAC SHOULD 255 proceed as follows: 257 * Any prefixes that were previously advertised via Router 258 Advertisement (RA) messages, but that have now become stale, 259 MUST be advertised with a "Valid Lifetime" and a "Preferred 260 Lifetime" set to 0, and the "A" and "L" bits unchanged. 262 * The aforementioned advertisement SHOULD be performed for at 263 least the "Valid Lifetime" previously employed for such prefix. 264 Note: If requirement L-16 (Section 2.2) is followed, the Valid 265 Lifetime need not be saved and the prefix can simply be 266 advertised for a period of ND_VALID_LIMIT. 268 o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- 269 lifetime MUST advertise the corresponding sub-prefixes (as they 270 would be generated for the same leased prefix with a non-zero 271 lifetime) with a PIO with both the Preferred Lifetime and the 272 Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD 273 valid-lifetime, or for period of ND_VALID_LIMIT if the recommended 274 lifetimes from Section 2.2 are employed. 276 This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 277 (address assignment or prefix delegation), the following behavior be 278 implemented: 280 o The CE Router SHOULD record, on stable storage, the DHCPv6 address 281 and delegated-prefix bindings corresponding to the LAN-side. 283 o If the CE Router finds that the prefix to be employed for address 284 assignment and/or prefix delegation has changed (e.g., upon a 285 crash-and-reboot event) or the CE Router receives DHCPv6 Prefix 286 Delegations with 0 lifetimes, the CE Router MUST: 288 * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 289 lifetimes for any address assignments or prefix delegations for 290 the deprecated prefixes for at least the valid-lifetime 291 previously employed for them, or for a period of ND_VALID_LIMIT 292 if the recommended lifetimes from Section 2.2 are employed. 294 * Initiate sending Reconfigure messages (if possible - i.e., 295 client requests Reconfigure support and the CE Router offers 296 it) to the those clients with address assignments or prefix 297 delegations for the deprecated prefixes. 299 RATIONALE: 301 * IPv6 network renumbering is expected to take place in a planned 302 manner, with old/stale prefixes being phased-out via reduced 303 prefix lifetimes while new prefixes (with normal lifetimes) are 304 introduced. However, there are a number of scenarios that may 305 lead to the so-called "flash-renumbering" events, where the 306 prefix being employed on a network suddenly becomes invalid and 307 replaced by a new prefix [I-D.ietf-v6ops-slaac-renum]. One of 308 such scenarios is that in which a DHCPv6 server employs dynamic 309 prefixes, and the Customer Edge Router crashes and reboots. 310 The requirements in this section are meant to allow Customer 311 Edge Routers to deprecate stale information in such scenarios. 313 * The recommendations in this section expand from requirement 314 L-13 in Section 4.3 of [RFC7084]. 316 * Host configuring addresses via SLAAC on the local network may 317 employ addresses configured for the previously advertised 318 prefixes for at most the "Valid Lifetime" of the corresponding 319 PIO of the last received Router Advertisement message. Since 320 Router Advertisement messages may be lost or fail to be 321 received for various reasons, Customer Edge Routers need to try 322 to deprecate stale prefixes for a period of time equal to the 323 "Valid Lifetime" of the PIO employed when originally 324 advertising the prefix. 326 * The requirement in this section is conveyed as a "SHOULD" (as 327 opposed to a "MUST"), since we acknowledge that the requirement 328 to store information on stable storage may represent a 329 challenge for some implementations. 331 * Advertising DHCPv6-leased prefixes with zero lifetimes on the 332 LAN-side would handle the case where a CE Router has no stable 333 storage but receives the prefixes via DHCPv6 with 0 lifetimes. 335 3. Recommended Option Lifetimes Configuration Values 337 o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) 339 o ND_VALID_LIMIT: 5400 seconds (90 minutes) 341 4. IANA Considerations 343 This document has no actions for IANA. 345 5. Security Considerations 347 This document discusses a problem that may arise in scenarios where 348 dynamic IPv6 prefixes are employed, and proposes improvements to 349 Customer Edge Routers [RFC7084] to mitigate the problem for 350 residential or small office scenarios. It does not introduce new 351 security issues. 353 6. Acknowledgments 355 The authors would like to thank Owen DeLong, Philip Homburg, and Ted 356 Lemon, for their valuable help in improving this document via 357 successive detailed reviews. 359 The authors would like to thank Mikael Abrahamsson, Brian Carpenter, 360 Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Erik Kline, 361 Olorunloba Olopade, Mark Smith, Job Snijders, Sander Steffann, Ole 362 Troan, Loganaden Velvindron, Timothy Winters, and Chongfeng Xie, for 363 providing valuable comments on earlier versions of this document. 365 The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim 366 Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick 367 Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, 368 Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael 369 Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for 370 providing valuable comments on [I-D.gont-6man-slaac-renum], on which 371 this document is based. 373 Fernando would also like to thank Brian Carpenter who, over the 374 years, has answered many questions and provided valuable comments 375 that has benefited his protocol-related work. 377 7. References 379 7.1. Normative References 381 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 382 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 383 November 2005, . 385 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 386 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 387 DOI 10.17487/RFC4861, September 2007, 388 . 390 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 391 Address Autoconfiguration", RFC 4862, 392 DOI 10.17487/RFC4862, September 2007, 393 . 395 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 396 Consumption of Router Advertisements", BCP 202, RFC 7772, 397 DOI 10.17487/RFC7772, February 2016, 398 . 400 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 401 "IPv6 Router Advertisement Options for DNS Configuration", 402 RFC 8106, DOI 10.17487/RFC8106, March 2017, 403 . 405 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 406 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 407 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 408 RFC 8415, DOI 10.17487/RFC8415, November 2018, 409 . 411 7.2. Informative References 413 [I-D.gont-6man-slaac-renum] 414 Gont, F., Zorz, J., and R. Patterson, "Improving the 415 Robustness of Stateless Address Autoconfiguration (SLAAC) 416 to Flash Renumbering Events", draft-gont-6man-slaac- 417 renum-07 (work in progress), April 2020. 419 [I-D.ietf-v6ops-slaac-renum] 420 Gont, F., Zorz, J., and R. Patterson, "Reaction of 421 Stateless Address Autoconfiguration (SLAAC) to Flash- 422 Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work 423 in progress), May 2020. 425 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 426 Requirements for IPv6 Customer Edge Routers", RFC 7084, 427 DOI 10.17487/RFC7084, November 2013, 428 . 430 Authors' Addresses 432 Fernando Gont 433 SI6 Networks 434 Segurola y Habana 4310, 7mo Piso 435 Villa Devoto, Ciudad Autonoma de Buenos Aires 436 Argentina 438 Email: fgont@si6networks.com 439 URI: https://www.si6networks.com 441 Jan Zorz 442 Go6 Institute 443 Frankovo naselje 165 444 Skofja Loka 4220 445 Slovenia 447 Email: jan@go6.si 448 URI: https://www.go6.si 450 Richard Patterson 451 Sky UK 453 Email: richard.patterson@sky.uk 455 Bernie Volz 456 Cisco Systems, Inc. 457 1414 Massachusetts Ave 458 Boxborough, MA 01719 459 USA 461 Email: volz@cisco.com