idnits 2.17.00 (12 Aug 2021) /tmp/idnits10499/draft-ietf-v6ops-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 date (November 2, 2020) is 558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ietf-6man-slaac-renum-01 == Outdated reference: draft-ietf-v6ops-cpe-slaac-renum has been published as RFC 9096 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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 Intended status: Informational J. Zorz 5 Expires: May 6, 2021 6connect 6 R. Patterson 7 Sky UK 8 November 2, 2020 10 Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- 11 Renumbering Events 12 draft-ietf-v6ops-slaac-renum-05 14 Abstract 16 In scenarios where network configuration information related to IPv6 17 prefixes becomes invalid without any explicit and reliable signaling 18 of that condition (such as when a Customer Edge router crashes and 19 reboots without knowledge of the previously-employed prefixes), nodes 20 on the local network may continue using stale prefixes for an 21 unacceptably long time (on the order of several days), thus resulting 22 in connectivity problems. This document describes this issue and 23 discusses operational workarounds that may help to improve network 24 robustness. Additionally, it highlights areas where further work may 25 be needed. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 6, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 5 63 2.1. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . 5 64 2.2. Default Timer Values in IPv6 Stateless Address 65 Autoconfiguration (SLAAC) . . . . . . . . . . . . . . . . 6 66 2.3. Recovering from Stale Network Configuration Information . 7 67 2.4. Lack of Explicit Signaling about Stale Information . . . 7 68 2.5. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 8 69 3. Operational Mitigations . . . . . . . . . . . . . . . . . . . 8 70 3.1. Stable Prefixes . . . . . . . . . . . . . . . . . . . . . 8 71 3.2. SLAAC Parameter Tweaking . . . . . . . . . . . . . . . . 8 72 4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 8.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 IPv6 Stateless address autoconfiguration (SLAAC) [RFC4862] conveys 84 information about prefixes to be employed for address configuration 85 via Prefix Information Options (PIOs) sent in Router Advertisement 86 (RA) messages. IPv6 largely assumes prefix stability, with network 87 renumbering only taking place in a planned manner, with old/stale 88 prefixes being phased-out via reduced prefix lifetimes, and new 89 prefixes (with longer lifetimes) being introduced at the same time. 90 However, there are several scenarios that may lead to the so-called 91 "flash-renumbering" events, where the prefix employed by a network 92 suddenly becomes invalid and replaced by a new prefix. In some of 93 these scenarios, the local router producing the network renumbering 94 event may try to deprecate the currently-employed prefixes (by 95 explicitly signaling the network about the renumbering event), 96 whereas in other scenarios it may be unable to do so. 98 In scenarios where network configuration information related to IPv6 99 prefixes becomes invalid without any explicit and reliable signaling 100 of that condition, nodes on the local network may continue using 101 stale prefixes for an unacceptably long period of time, thus 102 resulting in connectivity problems. 104 Scenarios where this problem may arise include, but are not limited 105 to, the following: 107 o The most common IPv6 deployment scenario for residential or small 108 office networks, where a Customer Edge (CE) router employs DHCPv6 109 Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from 110 an Internet Service Provider (ISP), and a sub-prefix of the leased 111 prefix is advertised on the LAN-side of the CE router via 112 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. In 113 scenarios where the CE router crashes and reboots, the CE may 114 obtain (via DHCPv6-PD) a different prefix from the one previously 115 leased, and therefore advertise (via SLAAC) the new prefix on the 116 LAN side. Hosts will typically configure addresses for the new 117 prefix, but will normally retain and may actively employ the 118 addresses configured for the previously-advertised prefix, since 119 their associated Preferred Lifetime and Valid Lifetime allow them 120 to do so. 122 o A router (e.g. Customer Edge router) advertises autoconfiguration 123 prefixes corresponding to prefixes learned via DHCPv6-PD with 124 constant PIO lifetimes that are not synchronized with the 125 DHCPv6-PD lease time (even though Section 6.3 of [RFC8415] 126 requires such synchronization). While this behavior violates the 127 aforementioned requirement from [RFC8415], it is not an unusual 128 behavior, particularly when e.g. DHCPv6-PD is implemented in a 129 different software module than the SLAAC router component. 131 o A switch-port the host is connected to is moved to another subnet 132 (VLAN) as a result of manual switch-port reconfiguration or 802.1x 133 re-authentication. There has been evidence that some 802.1x 134 supplicants do not reset network settings after successful 802.1x 135 authentication. So if a host fails 802.1x authentication for some 136 reason, is placed in a "quarantine" VLAN and is successfully 137 authenticated later on, it might end up having IPv6 addresses from 138 both the old ("quarantine") and the new VLANs. 140 o During the planned network renumbering, a router is configured to 141 send an RA with the Preferred Lifetime for the "old" Prefix 142 Information Option (PIO) set to zero and the new PIO with a non- 143 zero Preferred Lifetime. However, due to unsolicited RAs being 144 sent to a multicast destination address, and multicast being 145 rather unreliable on busy wifi networks, the RA might not be 146 received by local hosts. 148 o Automated device config management system performs periodic config 149 pushes to network devices. In these scenarios, network devices 150 may simply immediately forget their previous configuration, rather 151 than withdrawing it gracefully. If such a push results in 152 changing the subnet configured on a particular network, hosts 153 attached to that network would not get notified about the subnet 154 change, and their addresses from the "old" prefix will not be 155 deprecated. A related scenario is the incorrect network 156 renumbering where a network administrator renumbers a network by 157 simply removing the "old" prefix from the configuration and 158 configuring a new prefix instead. 160 Lacking any explicit and reliable signaling to deprecate the 161 previously-advertised prefixes, hosts may continue to employ the 162 previously-configured addresses, which will typically result in 163 packets being blackholed (whether because of egress-filtering by the 164 CE router or ISP) or the return traffic being discarded or routed 165 elsewhere. 167 The default values for the "Preferred Lifetime" and "Valid Lifetime" 168 of PIOs specified in [RFC4861] mean that, in the aforementioned 169 scenarios, the stale addresses would be retained, and could be 170 actively employed for new communications instances, for an 171 unacceptably long period of time (one month, and one week, 172 respectively). This could lead to interoperability problems, instead 173 of hosts transitioning to the newly-advertised prefix(es) in a more 174 timely manner. 176 Some devices have implemented ad-hoc mechanisms to address this 177 problem, such as sending RAs to deprecate apparently-stale prefixes 178 when the device receives any packets employing a source address from 179 a prefix not currently advertised for address configuration on the 180 local network [FRITZ]. However, this may introduce other 181 interoperability problems, particularly in multihomed/multiprefix 182 scenarios. This is a clear indication that advice in this area is 183 warranted. 185 Unresponsiveness to these "flash-renumbering" events is caused by the 186 inability of the network to deprecate stale information, as well as 187 by the inability of hosts to react to network configuration changes 188 in a more timely manner. Clearly, it would be desirable that these 189 flash-renumbering scenarios do not occur, and that, when they do 190 occur, that hosts are explicitly and reliably notified of their 191 occurrence. However, for robustness reasons, it is paramount for 192 hosts to be able to recover from stale configuration information even 193 when these flash-renumbering events occur and the network is unable 194 to explicitly and reliably notify hosts about such conditions. 196 Section 2 analyzes this problem in more detail. Section 3 describes 197 possible operational mitigations. Section 4 describes possible 198 future work to mitigate the aforementioned problem. 200 2. Analysis of the Problem 202 As noted in Section 1, the problems discussed in this document are 203 exacerbated by the default values of some protocol parameters and 204 other factors. The following sections analyze each of them in 205 detail. 207 2.1. Use of Dynamic Prefixes 209 In network scenarios where dynamic prefixes are employed, renumbering 210 events lead to updated network configuration information being 211 propagated through the network, such that the renumbering events are 212 gracefully handled. However, if the renumbering event happens along 213 with e.g. loss of configuration state by some of the devices involved 214 in the renumbering procedure (e.g., a router crashes, reboots, and 215 gets leased a new prefix), this may result in a flash-renumbering 216 event, where new prefixes are introduced without properly phasing out 217 the old ones. 219 In simple residential or small office scenario, the problem discussed 220 in this document would be avoided if DHCPv6-PD would lease "stable" 221 prefixes. However, a recent survey [UK-NOF] indicates that 37% of 222 the responding ISPs employ dynamic prefixes. That is, dynamic IPv6 223 prefixes are an operational reality. 225 Deployment reality aside, there are a number of possible issues 226 associated with stable prefixes: 228 o Provisioning systems may be unable to deliver stable IPv6 229 prefixes. 231 o While an ISP might lease stable prefixes to the home or small 232 office, the Customer Edge router might in turn lease sub-prefixes 233 of these prefixes to other internal network devices. Unless the 234 associated lease databases are stored on non-volatile memory, 235 these internal devices might be leased dynamic sub-prefixes of the 236 stable prefix leased by the ISP. In other words, every time a 237 prefix is leased there is the potential for the resulting prefixes 238 to become dynamic, even if the device leasing sub-prefixes has 239 been leased a stable prefix by its upstream router. 241 o While there is a range of information that may be employed to 242 correlate network activity [RFC7721], the use of stable prefixes 243 clearly simplifies network activity correlation, and may 244 essentially render features such as "temporary addresses" 245 [RFC4941] irrelevant. 247 o There may be existing advice for ISPs to deliver dynamic IPv6 248 prefixes *by default* (see e.g. [GERMAN-DP]) over privacy 249 concerns associated with stable prefixes. 251 For a number of reasons (such as the ones stated above), IPv6 252 deployments may employ dynamic prefixes (even at the expense of the 253 issues discussed in this document), and that there might be scenarios 254 in which the dynamics of a network are such that the network exhibits 255 the behaviour of dynamic prefixes. Rather than trying to regulate 256 how operators may run their networks, this document aims at improving 257 network robustness in the deployed Internet. 259 2.2. Default Timer Values in IPv6 Stateless Address Autoconfiguration 260 (SLAAC) 262 The impact of the issue discussed in this document is a function of 263 the lifetime values employed for the PIO lifetimes, since these 264 values determine for how long the corresponding addresses will be 265 preferred and considered valid. Thus, when the problem discussed in 266 this document is experienced, the longer the PIO lifetimes, the 267 higher the impact. 269 [RFC4861] specifies the following default PIO lifetime values: 271 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 273 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 275 Under problematic circumstances, such as where the corresponding 276 network information has become stale without any explicit and 277 reliable signal from the network (as described in Section 1), it 278 could take hosts up to 7 days (one week) to deprecate the 279 corresponding addresses, and up to 30 days (one month) to eventually 280 invalidate and remove any addresses configured for the stale prefix. 281 This means that it will typically take hosts an unacceptably long 282 period of time (on the order of several days) to recover from these 283 scenarios. 285 2.3. Recovering from Stale Network Configuration Information 287 SLAAC hosts are unable to recover from stale network configuration 288 information for a number of reasons: 290 o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an 291 unauthenticated RA may never reduce the "RemainingLifetime" to 292 less than two hours. If the RemainingLifetime of an address is 293 smaller than 2 hours, then a Valid Lifetime smaller than 2 hours 294 will be ignored. The Preferred Lifetime of an address can be 295 reduced to any value to avoid using a stale prefix for new 296 communications. 298 o In the absence of explicit signalling from SLAAC routers (such as 299 sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts 300 fail to recover from stale configuration information in a timely 301 manner. However, when a network element is able to explicitly 302 signal the renumbering event, it will only be able to deprecate 303 the stale prefix, but not to invalidate the prefix in question. 304 Therefore, communication with the new "owners" of the stale prefix 305 will not be possible, since the stale prefix will still be 306 considered "on-link". 308 2.4. Lack of Explicit Signaling about Stale Information 310 Whenever prefix information has changed, a SLAAC router should not 311 only advertise the new information, but should also advertise the 312 stale information with appropriate lifetime values (both "Preferred 313 Lifetime" and "Valid Lifetime" set to 0). This would provide 314 explicit signaling to SLAAC hosts to remove the stale information 315 (including configured addresses and routes). However, in scenarios 316 such as when a CE router crashes and reboots, the CE router may have 317 no knowledge about the previously-advertised prefixes, and thus may 318 be unable to advertise them with appropriate lifetimes (in order to 319 deprecate them). 321 However, we note that, as discussed in Section 2.3, PIOs with small 322 Valid Lifetimes in unauthenticated RAs will not lower the Valid 323 Lifetime to any value shorter than two hours (as per [RFC4862]). 324 Therefore, even if a SLAAC router tried to explicitly signal the 325 network about the stale configuration information via unauthenticated 326 RAs, implementations compliant with [RFC4862] would deprecate the 327 corresponding prefixes, but would fail to invalidate them. 329 NOTE: 330 Some implementations have been updated to honor small PIO 331 lifetimes values, as proposed in [I-D.ietf-6man-slaac-renum]. For 332 example, please see [Linux-update]. 334 2.5. Interaction Between DHCPv6-PD and SLAAC 336 While DHCPv6-PD is normally employed along with SLAAC, the 337 interaction between the two protocols is largely unspecified. Not 338 unusually, the two protocols are implemented in two different 339 software components with the interface between the two implemented by 340 some sort of script that feeds the SLAAC implementation with values 341 learned from DHCPv6-PD. 343 At times, the prefix lease time is fed as a constant value to the 344 SLAAC router implementation, meaning that, eventually, the prefix 345 lifetime advertised on the LAN side will span *past* the DHCPv6-PD 346 lease time. This is clearly incorrect, since the SLAAC router 347 implementation would be allowing the use of such prefixes for a 348 longer time than it has been granted usage of those prefixes via 349 DHCPv6-PD. 351 3. Operational Mitigations 353 The following subsections discuss possible operational workarounds 354 for the aforementioned problems. 356 3.1. Stable Prefixes 358 As noted in Section 2.1, the use of stable prefixes would eliminate 359 the issue in *some* of the scenarios discussed in Section 1 of this 360 document, such as the typical home network deployment. However, even 361 in such scenarios, there might be reasons for which an administrator 362 may want or may need to employ dynamic prefixes 364 3.2. SLAAC Parameter Tweaking 366 An operator may wish to override some SLAAC parameters such that, 367 under normal circumstances, the timers will be refreshed/reset, but 368 in the presence of network faults (such as the one discussed in this 369 document), the timers go off and trigger some fault recovering action 370 (e.g. deprecate and subsequently invalidate stale addresses). 372 The following router configuration variables from [RFC4861] 373 (corresponding to the "lifetime" parameters of PIOs) could be 374 overridden as follows: 376 AdvPreferredLifetime: 2700 seconds (45 minutes) 378 AdvValidLifetime: 5400 seconds (90 minutes) 380 NOTES: 382 The aforementioned values for AdvPreferredLifetime and 383 AdvValidLifetime are expected to be appropriate for most networks. 384 In some networks, particularly where the operator has complete 385 control of prefix allocation and where hosts on the network may 386 spend long periods sleeping (e.g., sensors with limited battery), 387 longer values may be appropriate. 389 A CE router advertising a sub-prefix of a prefix leased via 390 DHCPv6-PD will periodically refresh the Preferred Lifetime and the 391 Valid Lifetime of an advertised prefix to AdvPreferredLifetime and 392 AdvValidLifetime, respectively, as long as the resulting lifetime 393 of the corresponding prefixes does not extend past the DHCPv6-PD 394 lease time [I-D.ietf-v6ops-cpe-slaac-renum]. 396 RATIONALE: 398 * In the context of [RFC8028], where it is clear that use of 399 addresses configured for a given prefix is tied to using the 400 next-hop router that advertised the prefix, it does not make 401 sense for the "Preferred Lifetime" of a PIO to be larger than 402 the "Router Lifetime" (AdvDefaultLifetime) of the corresponding 403 Router Advertisement messages. The "Valid Lifetime" is set to 404 a much larger value to cope with transient network problems. 406 * Lacking RAs that refresh information, addresses configured for 407 advertised prefixes become deprecated in a more timely manner, 408 and thus Rule 3 of [RFC6724] causes other configured addresses 409 (if available) to be used instead. 411 * We note that lowering the default values for the "Valid 412 Lifetime" helps reduce the amount of time a host may maintain 413 stale information and the amount of time an advertising router 414 would need to advertise stale prefixes to deprecate them, while 415 reducing the default "Preferred Lifetime" would reduce the 416 amount of time it takes for a host to prefer other working 417 prefixes (see Section 12 of [RFC4861]). However, while the 418 values suggested in this section are an improvement over the 419 default values specified in [RFC4861], they represent a trade- 420 off among a number of factors, including responsiveness, 421 possible impact on the battery life of connected devices 422 [RFC7772], etc. Thus, they may or may not provide sufficient 423 mitigation to the problem discussed in this document. 425 4. Future Work 427 Improvement in Customer Edge Routers [RFC7084] such that they can 428 signal the network about stale prefixes and deprecate them 429 accordingly can help mitigate the problem discussed in this document 430 for the "home network" scenario. Such work is currently being 431 pursued in [I-D.ietf-v6ops-cpe-slaac-renum]. 433 Improvements in the SLAAC protocol [RFC4862] and other algorithms 434 such as "Default Address Selection for IPv6" [RFC6724] would help 435 improve network robustness. Such work is currently being pursued in 436 [I-D.ietf-6man-slaac-renum]. 438 The aforementioned work is considered out of the scope of this 439 present document, which only focuses on documenting the problem and 440 discussing operational mitigations. 442 5. IANA Considerations 444 This document has no actions for IANA. 446 6. Security Considerations 448 This document discusses a problem that may arise in scenarios where 449 flash-renumbering events occur, and proposes workarounds to mitigate 450 the aforementioned problems. This document does not introduce any 451 new security issues, and thus the same security considerations as for 452 [RFC4861] and [RFC4862] apply. 454 7. Acknowledgments 456 The authors would like to thank (in alphabetical order) Brian 457 Carpenter, Alissa Cooper, Roman Danyliw, Owen DeLong, Martin Duke, 458 Guillermo Gont, Philip Homburg, Sheng Jiang, Benjamin Kaduk, Erik 459 Kline, Murray Kucherawy, Warren Kumari, Ted Lemon, Juergen 460 Schoenwaelder, Eric Vyncke, Klaas Wierenga, Robert Wilton, and Dale 461 Worley, for providing valuable comments on earlier versions of this 462 document. 464 The authors would like to thank (in alphabetical order) Mikael 465 Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, 466 Uesley Correa, Owen DeLong, Gert Doering, Martin Duke, Fernando 467 Frediani, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard, 468 Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez, 469 Michael Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for 470 providing valuable comments on a previous document on which this 471 document is based. 473 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 474 for a discussion of these issues. Fernando would also like to thank 475 Brian Carpenter who, over the years, has answered many questions and 476 provided valuable comments that have benefited his protocol-related 477 work. 479 The problem discussed in this document has been previously documented 480 by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], 481 and also in [RIPE-690]. Section 1 borrows text from 482 [I-D.linkova-6man-default-addr-selection-update], authored by Jen 483 Linkova. 485 8. References 487 8.1. Normative References 489 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 490 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 491 DOI 10.17487/RFC4861, September 2007, 492 . 494 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 495 Address Autoconfiguration", RFC 4862, 496 DOI 10.17487/RFC4862, September 2007, 497 . 499 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 500 "Default Address Selection for Internet Protocol Version 6 501 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 502 . 504 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 505 Hosts in a Multi-Prefix Network", RFC 8028, 506 DOI 10.17487/RFC8028, November 2016, 507 . 509 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 510 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 511 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 512 RFC 8415, DOI 10.17487/RFC8415, November 2018, 513 . 515 8.2. Informative References 517 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 518 (updated with solution)", SI6 Networks Blog, February 519 2016, . 522 [GERMAN-DP] 523 BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im 524 Privatkundengeschaft und Herstellere", Entschliessung der 525 84. Konferenz der Datenschutzbeauftragten des Bundes und 526 der Lander am 7./8. November 2012 in Frankfurt (Oder), 527 November 2012, 528 . 532 [I-D.ietf-6man-slaac-renum] 533 Gont, F., Zorz, J., and R. Patterson, "Improving the 534 Robustness of Stateless Address Autoconfiguration (SLAAC) 535 to Flash Renumbering Events", draft-ietf-6man-slaac- 536 renum-01 (work in progress), August 2020. 538 [I-D.ietf-v6ops-cpe-slaac-renum] 539 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 540 the Reaction of Customer Edge Routers to Renumbering 541 Events", draft-ietf-v6ops-cpe-slaac-renum-05 (work in 542 progress), September 2020. 544 [I-D.linkova-6man-default-addr-selection-update] 545 Linkova, J., "Default Address Selection and Subnet 546 Renumbering", draft-linkova-6man-default-addr-selection- 547 update-00 (work in progress), March 2017. 549 [Linux-update] 550 Gont, F., "[net-next] ipv6: Honor all IPv6 PIO Valid 551 Lifetime values", Post to the netdev mailing-list 552 http://vger.kernel.org/vger-lists.html, April 2020, 553 . 557 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 558 Extensions for Stateless Address Autoconfiguration in 559 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 560 . 562 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 563 Requirements for IPv6 Customer Edge Routers", RFC 7084, 564 DOI 10.17487/RFC7084, November 2013, 565 . 567 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 568 Considerations for IPv6 Address Generation Mechanisms", 569 RFC 7721, DOI 10.17487/RFC7721, March 2016, 570 . 572 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 573 Consumption of Router Advertisements", BCP 202, RFC 7772, 574 DOI 10.17487/RFC7772, February 2016, 575 . 577 [RIPE-690] 578 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 579 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 580 Meynell, K., and L. Howard, "Best Current Operational 581 Practice for Operators: IPv6 prefix assignment for end- 582 users - persistent vs non-persistent, and what size to 583 choose", RIPE 690, October 2017, 584 . 586 [UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household 587 Services) How IPv6 is being deployed?", UK NOF 39, January 588 2018, 589 . 592 Authors' Addresses 594 Fernando Gont 595 SI6 Networks 596 Segurola y Habana 4310, 7mo Piso 597 Villa Devoto, Ciudad Autonoma de Buenos Aires 598 Argentina 600 Email: fgont@si6networks.com 601 URI: https://www.si6networks.com 603 Jan Zorz 604 6connect 606 Email: jan@connect.com 608 Richard Patterson 609 Sky UK 611 Email: richard.patterson@sky.uk