idnits 2.17.1 draft-ietf-v6ops-cpe-slaac-renum-07.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 (February 16, 2021) is 1163 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-02 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: August 20, 2021 R. Patterson 7 Sky UK 8 B. Volz 9 Cisco 10 February 16, 2021 12 Improving the Reaction of Customer Edge Routers to IPv6 Renumbering 13 Events 14 draft-ietf-v6ops-cpe-slaac-renum-07 16 Abstract 18 This document specifies improvements to Customer Edge Routers that 19 help mitigate the problems that may arise when network configuration 20 information becomes invalid, without any explicit signaling of that 21 condition to the local nodes. This document updates RFC7084. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 20, 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 59 3. Improved Customer Edge Router Behavior . . . . . . . . . . . 3 60 3.1. Automatic DHCPv6 RELEASEs . . . . . . . . . . . . . . . . 4 61 3.2. Stability of IAIDs . . . . . . . . . . . . . . . . . . . 4 62 3.3. Interface Between WAN-side and LAN-side . . . . . . . . . 4 63 3.4. LAN-side Option Lifetimes . . . . . . . . . . . . . . . . 5 64 3.5. Signaling Stale Configuration Information . . . . . . . . 7 65 4. Recommended Option Lifetimes Configuration Values . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 In scenarios where network configuration information becomes invalid 77 without any explicit signaling of that condition (such as when a 78 Customer Edge Router crashes and reboots without knowledge of the 79 previously-employed configuration information), hosts 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. It specifies recommendations for the default 87 behavior of CE Routers, and does not preclude the availability of 88 configuration knobs that might allow an operator or user to manually- 89 configure the CE Router to deviate from these recommendations. This 90 document updates RFC7084. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 3. Improved Customer Edge Router Behavior 102 This section specifies and clarifies requirements for Customer Edge 103 Routers that can help mitigate the problem discussed in Section 1, 104 particularly when they employ prefixes learned via DHCPv6-Prefix 105 Delegation (DHCPv6-PD) [RFC8415] on the WAN-side with Stateless 106 Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on 107 the LAN-side. The recommendations in this document help improve 108 robustness at the Customer Edge Router (on which the user or ISP may 109 have no control), and do not preclude implementation of host-side 110 improvements such as those specified in [I-D.ietf-6man-slaac-renum]. 112 This document specifies additional prefix-delegation requirements to 113 those specified in [RFC7084]: 115 o WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 116 messages upon reboot events. See Section 3.1 for further details. 118 o WPD-10: CE Routers MUST by default use a stable IAID value that 119 does not change between CE Router restarts, DHCPv6 client 120 restarts, or interface state changes. e.g., Transient PPP 121 interfaces. See Section 3.2 for further details. 123 This document also replaces LAN-side requirement L-13 from [RFC7084] 124 with: 126 o L-13: CE routers MUST signal stale configuration information as 127 specified in Section 3.5. 129 Finally, this document specifies the following additional LAN-side 130 requirements to those from [RFC7084]: 132 o L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign 133 addresses or delegate prefixes via DHCPv6 on the LAN-side, 134 employing lifetimes that exceed the remaining lifetimes of the 135 corresponding prefixes learned from the WAN-side via DHCPv6-PD. 136 For more details, see Section 3.3. 138 o L-16: CE routers SHOULD advertise capped SLAAC option lifetimes 139 and capped DHCPv6 IA Address Option and IA Prefix Option 140 lifetimes, as specified in Section 3.4. 142 3.1. Automatic DHCPv6 RELEASEs 144 Some CE Routers are known to automatically send DHCPv6-PD RELEASE 145 messages upon reboot events. However, this may inadvertently trigger 146 a flash-renumbering scenario, along with the associated problems 147 discussed in [I-D.ietf-v6ops-slaac-renum], that this document 148 attempts to mitigate. 150 As a result, requirement WPD-9 from Section 3 specifies that CE 151 routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon 152 reboot events. 154 3.2. Stability of IAIDs 156 [RFC8415] requires that the IAID for an IA MUST be consistent across 157 restarts of the DHCP client. However, some popular CE Routers are 158 known to select new random IAIDs e.g. everytime the underlying PPP 159 session is established. This could be the result of extrapolating 160 the behavior described in [RFC7844], or simply a consequence of not 161 storing IAIDs on stable storage along with failing to employ an 162 algorithm that consistently generates the same IAID upon reboots. 163 Thus, requirement WPD-10 from Section 3 prevents CE Routers from 164 inadvertently triggering flash-renumbering events on the local 165 network. 167 3.3. Interface Between WAN-side and LAN-side 169 The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information 170 Options (PIOs) [RFC4861] corresponding to prefixes learned via 171 DHCPv6-PD MUST NOT span past the remaining preferred and valid 172 lifetimes of the corresponding DHCPv6-PD prefixes. This means that 173 the "Preferred Lifetime" and the "Valid Lifetime" advertised in PIOs 174 by the CE router MUST be dynamically adjusted such that they never 175 span past the remaining preferred and valid lifetimes of the 176 corresponding prefixes delegated via DHCPv6-PD on the WAN-side. 178 Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA 179 Address Options and DHCPv6 IA Prefix Options employed with DHCPv6 on 180 the LAN-side MUST NOT span past the remaining preferred and valid 181 lifetimes of the corresponding prefixes leased via DHCPv6-PD on the 182 WAN-side. This means that the "preferred-lifetime" and "valid- 183 lifetime" of DHCPv6 IA Address Options and DHCPv6 IA Prefix Options 184 employed with DHCPv6 on the LAN-side MUST be dynamically adjusted 185 such that they never span past the remaining preferred and valid 186 lifetimes of the corresponding prefixes delegated to the CE router on 187 the WAN-side via DHCPv6-PD. 189 RATIONALE: 191 * The lifetime values employed for the "Preferred Lifetime" 192 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 193 of SLAAC Prefix Information Options must never be larger than 194 the remaining lifetimes for the corresponding prefix (as 195 learned via DHCPv6-PD on the WAN-side). This is in line with 196 the requirement from Section 6.3 of [RFC8415], which states 197 that "if the delegated prefix or a prefix derived from it is 198 advertised for stateless address autoconfiguration [RFC4862], 199 the advertised preferred and valid lifetimes MUST NOT exceed 200 the corresponding remaining lifetimes of the delegated prefix." 202 * The lifetime values of prefixes advertised on the LAN-side via 203 SLAAC must be dynamically updated (rather than static values), 204 otherwise the advertised lifetimes would eventually span past 205 the DHCPv6-PD lifetimes. 207 * The same considerations apply for the valid-lifetime and 208 preferred-lifetime of IA Address Options and IA Prefix Options 209 employed with DHCPv6 on the LAN-side. 211 3.4. LAN-side Option Lifetimes 213 CE Routers SHOULD override the default lifetime values of Neighbor 214 Discovery options that depend in any way on changes in the prefix 215 employed for address configuration on the LAN-side, and employ 216 shorter lifetime values to improve the robustness to renumbering 217 events, while complying with the requirements from Section 3.3 of 218 this document and the recommendations in [RFC7772]. 220 CE Routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. 222 CE Routers SHOULD also set the PIO Preferred Lifetime to the lesser 223 of the remaining preferred lifetime (see Section 3.3) and 224 ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the 225 remaining valid lifetime and ND_VALID_LIMIT. Additionally, the Route 226 Lifetime of Route Information Options (RIOs) [RFC4191], the Lifetime 227 of Recursive DNS Search Options (RDNSSO) [RFC8106], and the Lifetime 228 of DNS Search List Options (DNSSLO) [RFC8106] SHOULD be set to the 229 lesser of the longest valid-lifetime in a DHCPv6 IA Prefix Option 230 (received via DHCPv6 on the WAN-side) and ND_VALID_LIMIT, if any of 231 these options are included in Router Advertisement messages. 233 NOTES: In scenarios where the valid-lifetime and the preferred- 234 lifetime of the prefix leased via DHCPv6 on the WAN-side are 235 always larger than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, 236 respectively, the lifetime values advertised on the LAN-side will 237 not experience actual changes. 239 The above text refers to the Neighbor Discovery Options that are 240 typically employed by CE Routers. A CE Router may need to apply 241 the same policy for setting the lifetime of other Neighbor 242 Discovery options it employs, if and where applicable. 244 CE Routers providing stateful address configuration via DHCPv6 SHOULD 245 set the DHCPv6 IA Address Option preferred-lifetime to the lesser of 246 the remaining preferred lifetime (see Section 3.3) and 247 ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the 248 lesser of the remaining valid lifetime and ND_VALID_LIMIT. 250 CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 251 IA Prefix Option preferred-lifetime to the lesser of the remaining 252 preferred lifetime (see Section 3.3) and ND_PREFERRED_LIMIT, and the 253 valid-lifetime of the same option to the lesser of the remaining 254 valid lifetime and ND_VALID_LIMIT. 256 RATIONALE: 258 * The Valid Lifetime and Preferred Lifetime of PIOs have a direct 259 impact on three different aspects: 261 + The amount of time hosts may end up employing stale network 262 configuration information (see 263 [I-D.ietf-v6ops-slaac-renum]). 265 + The amount of time CE Routers need to persist trying to 266 deprecate stale network configuration information (e.g. to 267 handle cases where hosts miss Router Advertisements and thus 268 still consider the stale information as valid). 270 + The amount of information that CE Routers need to maintain 271 when e.g. multiple crash-and-reboot events occur in the 272 timespan represented by the option lifetimes employed on the 273 LAN-side. 275 * CE Routers need not employ the (possibly long) WAN-side 276 DHCPv6-PD lifetimes for the Valid Lifetime and Preferred 277 Lifetime of PIOs sent in Router Advertisements messages to 278 advertise sub-prefixes of the leased prefix. Instead, CE 279 Routers SHOULD use shorter values for the Valid Lifetime and 280 Preferred Lifetime of PIOs, since subsequent Router 281 Advertisement messages will nevertheless refresh the associated 282 lifetimes, leading to the same effective lifetimes as specified 283 by the WAN-side DHCPv6-PD lifetimes. 285 * Similarly, CE Routers need not employ the (possibly long) WAN- 286 side DHCPv6-PD lifetimes for the valid-lifetime and preferred- 287 lifetime of IA Address Options and IA Prefix Option employed by 288 DHCPv6 on the LAN-side, since the renewal of bindings by DHCPv6 289 clients will lead to the same effective lifetimes as specified 290 by the WAN-side DHCPv6-PD lifetimes. 292 3.5. Signaling Stale Configuration Information 294 When a CE Router provides LAN-side address-configuration information 295 via SLAAC: 297 o A CE Router sending RAs that advertise dynamically-learned 298 prefixes (e.g. via DHCPv6-PD) SHOULD record, on stable storage, 299 the list of prefixes being advertised via PIOs on each network 300 segment, and the state of the "A" and "L" flags of the 301 corresponding PIOs. 303 o Upon changes to the advertised prefixes, and after bootstrapping, 304 the CE Router advertising prefix information via SLAAC proceeds as 305 follows: 307 * Any prefixes that were previously advertised by the CE Router 308 via PIOs in RA messages, but that have now become stale, MUST 309 be advertised with a PIO that has the "Valid Lifetime" and the 310 "Preferred Lifetime" set to 0, and the "A" and "L" bits 311 unchanged. 313 * The aforementioned advertisement MUST be performed for at least 314 the "Valid Lifetime" previously employed for such prefix. The 315 CE Router MUST advertise this information with unsolicited 316 Router Advertisements as described in Section 6.2.4 of 317 [RFC4861], and MAY advertise this information via unicast 318 Router Advertisements when possible and applicable. 320 + Note: If requirement L-16 (Section 3.4) is followed, the 321 Valid Lifetime need not be saved and the stale prefix can 322 simply be advertised for a period of ND_VALID_LIMIT. 324 o CE Routers receiving DHCPv6 Prefix Delegations with a 0 valid- 325 lifetime MUST advertise the corresponding sub-prefixes (as they 326 would be generated for the same leased prefix with a non-zero 327 lifetime) with a PIO with both the Preferred Lifetime and the 328 Valid Lifetime set to 0, for at least the WAN-side DHCPv6-PD 329 valid-lifetime, or for a period of ND_VALID_LIMIT if the 330 recommended lifetimes from Section 3.4 are employed. 332 When a CE Router provides LAN-side DHCPv6 (address assignment or 333 prefix delegation), then: 335 o The CE Router SHOULD record, on stable storage, the DHCPv6 address 336 and delegated-prefix bindings corresponding to the LAN-side. 338 o If the CE Router finds that the prefix to be employed for address 339 assignment and/or prefix delegation has changed (e.g., upon a 340 crash-and-reboot event) or the CE Router receives DHCPv6 Prefix 341 Delegations with 0 lifetimes, the CE Router MUST: 343 * In Replies to DHCPv6 Request, Renew, and Rebind messages, send 344 IA Address Options or IA Prefix Options (as appropriate) for 345 any address assignments or prefix delegations for the 346 deprecated prefixes. The aforementioned options MUST be sent 347 with both the valid-lifetime and the preferred-lifetime set to 348 0, for at least the valid-lifetime originally employed for 349 them, or for a period of ND_VALID_LIMIT if the recommended 350 lifetimes from Section 3.4 are employed. 352 * Initiate sending Reconfigure messages (if possible - i.e., 353 client requests Reconfigure support and the CE Router offers 354 it) to those clients with address assignments or prefix 355 delegations for the deprecated prefixes. 357 RATIONALE: 359 * IPv6 network renumbering is expected to take place in a planned 360 manner, with old/stale prefixes being phased-out via reduced 361 prefix lifetimes while new prefixes (with normal lifetimes) are 362 introduced. However, a number of scenarios may lead to the so- 363 called "flash-renumbering" events, where the prefix being 364 employed on a network suddenly becomes invalid and replaced by 365 a new prefix [I-D.ietf-v6ops-slaac-renum]. One such scenario 366 is when a DHCPv6 server employs dynamic prefixes and the 367 Customer Edge Router crashes and reboots. The requirements in 368 this section are meant to allow Customer Edge Routers to 369 deprecate stale information in such scenarios. 371 * The recommendations in this section expand from requirement 372 L-13 in Section 4.3 of [RFC7084], and Section 6.3 of [RFC8415]. 374 * Host configuring addresses via SLAAC on the local network may 375 employ addresses configured for the previously advertised 376 prefixes for at most the "Valid Lifetime" of the corresponding 377 PIO of the last received Router Advertisement message. Since 378 Router Advertisement messages may be lost or fail to be 379 received for various reasons, Customer Edge Routers need to try 380 to deprecate stale prefixes for a period of time equal to the 381 "Valid Lifetime" of the PIO employed when originally 382 advertising the prefix. 384 * The requirement in this section is conveyed as a "SHOULD" (as 385 opposed to a "MUST"), since the requirement to store 386 information on stable storage may represent a challenge for 387 some implementations. 389 * Advertising DHCPv6-leased prefixes with zero lifetimes on the 390 LAN-side would handle the case where a CE Router has no stable 391 storage but receives the prefixes via DHCPv6 with 0 lifetimes. 393 * The above text does not include DHCPv6 Advertise messages sent 394 in response to DHCPv6 Solicit messages, since Section 18.3.9 of 395 [RFC8415] requires that a DHCPv6 server that is not going to 396 assign an address or delegated prefix received as a hint in the 397 Solicit message MUST NOT include that address or delegated 398 prefix in the Advertise message. Additionally, any subsequent 399 Request messages will trigger the response specified in this 400 section, and therefore cause the address or prefix to be 401 deprecated. 403 4. Recommended Option Lifetimes Configuration Values 405 o ND_PREFERRED_LIMIT: 2700 seconds (45 minutes) 407 o ND_VALID_LIMIT: 5400 seconds (90 minutes) 409 RATIONALE: 410 These values represent a trade-off among a number of factors, 411 including responsiveness and possible impact on the battery life 412 of connected devices [RFC7772]. 414 ND_PREFERRED_LIMIT is set according to the recommendations in 415 [RFC7772] for Router Lifetime, following the rationale from 416 Section 3.2 of [I-D.ietf-v6ops-slaac-renum]. 418 ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some 419 additional leeway before configuration information is finally 420 discarded by the host. 422 5. IANA Considerations 424 This document has no actions for IANA. 426 6. Security Considerations 428 This document discusses a problem that may arise in scenarios where 429 dynamic IPv6 prefixes are employed, and proposes improvements to 430 Customer Edge Routers [RFC7084] to mitigate the problem for 431 residential or small office scenarios. It does not introduce new 432 security issues, and thus the same security considerations as for 433 [RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply. 435 7. Acknowledgments 437 The authors would like to thank Owen DeLong, Philip Homburg, Erik 438 Kline, and Ted Lemon, for their valuable help in improving this 439 document via successive detailed reviews. 441 The authors would like to thank Mikael Abrahamsson, Luis Balbinot, 442 Tim Chown, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Gert 443 Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick 444 Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk, 445 Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade, 446 Jordi Palet Martinez, Richard Patterson, Pete Resnick, Michael 447 Richardson, Mark Smith, Job Snijders, Sander Steffann, Tarko Tikan, 448 Ole Troan, Loganaden Velvindron, Eric Vyncke, Robert Wilton, Timothy 449 Winters, Christopher Wood, and Chongfeng Xie, for providing valuable 450 comments on earlier versions of this document. 452 Fernando would also like to thank Brian Carpenter who, over the 453 years, has answered many questions and provided valuable comments 454 that have benefited his protocol-related work. 456 8. References 458 8.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 466 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 467 November 2005, . 469 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 470 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 471 DOI 10.17487/RFC4861, September 2007, 472 . 474 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 475 Address Autoconfiguration", RFC 4862, 476 DOI 10.17487/RFC4862, September 2007, 477 . 479 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 480 Consumption of Router Advertisements", BCP 202, RFC 7772, 481 DOI 10.17487/RFC7772, February 2016, 482 . 484 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 485 Profiles for DHCP Clients", RFC 7844, 486 DOI 10.17487/RFC7844, May 2016, 487 . 489 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 490 "IPv6 Router Advertisement Options for DNS Configuration", 491 RFC 8106, DOI 10.17487/RFC8106, March 2017, 492 . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 499 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 500 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 501 RFC 8415, DOI 10.17487/RFC8415, November 2018, 502 . 504 8.2. Informative References 506 [I-D.ietf-6man-slaac-renum] 507 Gont, F., Zorz, J., and R. Patterson, "Improving the 508 Robustness of Stateless Address Autoconfiguration (SLAAC) 509 to Flash Renumbering Events", draft-ietf-6man-slaac- 510 renum-02 (work in progress), January 2021. 512 [I-D.ietf-v6ops-slaac-renum] 513 Gont, F., Zorz, J., and R. Patterson, "Reaction of 514 Stateless Address Autoconfiguration (SLAAC) to Flash- 515 Renumbering Events", draft-ietf-v6ops-slaac-renum-05 (work 516 in progress), November 2020. 518 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 519 Requirements for IPv6 Customer Edge Routers", RFC 7084, 520 DOI 10.17487/RFC7084, November 2013, 521 . 523 Authors' Addresses 525 Fernando Gont 526 SI6 Networks 527 Segurola y Habana 4310, 7mo Piso 528 Villa Devoto, Ciudad Autonoma de Buenos Aires 529 Argentina 531 Email: fgont@si6networks.com 532 URI: https://www.si6networks.com 534 Jan Zorz 535 6connect 537 Email: jan@6connect.com 539 Richard Patterson 540 Sky UK 542 Email: richard.patterson@sky.uk 544 Bernie Volz 545 Cisco Systems, Inc. 546 300 Beaver Brook Rd 547 Boxborough, MA 01719 548 USA 550 Email: volz@cisco.com