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