idnits 2.17.1 draft-gont-v6ops-slaac-renum-00.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 385: '... o CPE routers MUST signal stale con...' RFC 2119 keyword, line 388: '... o CPE routers MUST implement the DH...' RFC 2119 keyword, line 391: '... o CPE routers SHOULD NOT automatica...' RFC 2119 keyword, line 399: '...v6-PD) on an interface MUST record, on...' RFC 2119 keyword, line 408: '...tended for address configuration, MUST...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2019) is 1748 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 (-08) exists of draft-gont-6man-slaac-renum-01 Summary: 2 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 Intended status: Informational J. Zorz 5 Expires: January 7, 2020 6 R. Patterson 7 Sky UK 8 July 6, 2019 10 Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering 11 Events 12 draft-gont-v6ops-slaac-renum-00 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 period of 21 time, thus resulting in connectivity problems. This document 22 analyzes these problem scenarios, and discusses operational 23 workarounds to improve network robustness. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 4 61 2.1. Default Timer Values in IPv6 Stateless Address 62 Autoconfiguration (SLAAC) . . . . . . . . . . . . . . . . 5 63 2.2. Recovering from Stale Network Configuration Information . 5 64 2.3. Lack of Explicit Signaling about Stale Information . . . 6 65 2.4. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 6 66 2.5. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . 6 67 3. Possible workarounds . . . . . . . . . . . . . . . . . . . . 7 68 3.1. SLAAC Parameter Tweaking . . . . . . . . . . . . . . . . 7 69 3.2. Improved CPE behavior . . . . . . . . . . . . . . . . . . 8 70 3.2.1. Signaling Stale Configuration Information . . . . . . 9 71 3.2.2. Interaction Between DHCPv6-PD and SLAAC . . . . . . . 10 72 4. Summary of Operational Mitigations . . . . . . . . . . . . . 10 73 4.1. Networks . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.2. CPE routers . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 IPv6 largely assumes prefix stability, with network renumbering only 87 taking place in a planned manner, with old/stale prefixes being 88 phased-out via reduced prefix lifetimes, and new prefixes (with 89 longer lifetimes) being introduced at the same time. However, there 90 are a number of scenarios that may lead to the so-called "flash- 91 renumbering", where the prefix being employed on a network suddenly 92 becomes invalid and replaced by a new prefix. In some of these 93 scenarios, the local router producing the network renumbering may be 94 able and try to deprecate the currently-employed prefixes (thus 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 signaling of that 100 condition, nodes on the local network will continue using stale 101 prefixes for an unacceptably long period of time, thus resulting in 102 connectivity problems. 104 Scenarios where this problem may arise include, but are not limited 105 to, the following: 107 o The most common deployment scenario for IPv6 in home networks is 108 that in which a CPE router employs DHCPv6 Prefix Delegation 109 (DHCPv6-PD) [RFC8415] to request a prefix from an Internet Service 110 Provider (ISP), and a sub-prefix of the leased prefix is 111 advertised on the LAN-side of the CPE router via Stateless Address 112 Autoconfiguration (SLAAC) [RFC4862]. In scenarios where the CPE 113 router crashes and reboots, the CPE may be leased (via DHCPv6-PD) 114 a different prefix from the one previously leased, and therefore 115 advertise (via SLAAC) the new prefix on the LAN side. Hosts will 116 normally configure an address for the new prefix, but will 117 normally retain and actively employ the previously-configured 118 addresses, since their associated Preferred Lifetime and Valid 119 Lifetime allow them to do so. 121 o A switch-port the host is connected to is moved to another subnet 122 (VLAN) as a result of manual switch-port reconfiguration or 802.1x 123 re-authentication. In particular there has been evidence that 124 some 802.1x supplicants do not reset network settings after 125 successful 802.1x authentication. So if a host had failed 802.1x 126 authentication for some reason, was placed in a "quarantine" VLAN 127 and then got successfully authenticated later on, it might end up 128 having IPv6 addresses from both old ("quarantine") and new VLANs. 130 o During the planned network renumbering a router is configured to 131 send an RA with the Preferred Lifetime for the "old" PIO set to 132 zero and the new PIO having non-zero preferred lifetime. However, 133 due to unsolicited RAs being sent as all-hosts multicast and 134 multicast being rather unreliable on busy wifi network, the RA is 135 not received by a host (or set of hosts). 137 o Automated device config management system performs periodical 138 config push to network devices. If such a push results in 139 changing /64 subnet configured on a particular network, hosts 140 attached to that network would not get notified about the subnet 141 change and their addresses from the "old" prefix are not 142 deprecated. The related case is incorrectly performed renumbering 143 when a network administrator is renumbering a network by simply 144 removing the "old" prefix from the configuration and configuring a 145 new prefix instead. 147 Lacking any explicit signaling to "obsolete" the previously- 148 configured addresses (for the now invalid/stale prefix), hosts may 149 continue employing the previously-configured addresses which will 150 typically result in packets being blackholed -- whether because of 151 egress-filtering by the CPE or ISP, or because responses to such 152 packets will be discarded or routed elsewhere. 154 The default values for the "Valid Lifetime" and "Preferred Lifetime" 155 of Prefix Information Options (PIOs), as specified in [RFC4861], are: 157 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 159 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 161 This means that in the aforementioned scenarios, the stale addresses 162 would be retained for unacceptably long period of time, thus leading 163 to interoperability problems, instead of nodes transitioning to the 164 newly-advertised prefix(es) in a timelier manner. 166 Some devices have implemented mechanisms to address this problem, 167 such as sending RAs to invalidate the apparently stale prefixes when 168 the device receives any packets employing a source address from a 169 prefix not being advertised for address configuration [FRITZ]. 170 However, this may introduce other interoperability problems, 171 particularly in multihomed/multiprefix scenarios. This is clear 172 indication that advice in this area is warranted. 174 Unresponsiveness to these "flash-renumbering" events is caused by the 175 inability of the network to deprecate stale information, as well as 176 by the inability of hosts to react to network configuration changes 177 in a timelier manner. Clearly, it would be desirable that these 178 flash-renumbering scenarios do not occur, and that, when they do 179 occur, that hosts are explicitly notified of their occurrence. 180 However, for robustness reasons it is also paramount for hosts to be 181 able to recover from stale configuration information even when these 182 flash-renumbering events occur and the network is unable to 183 explicitly notify hosts about such condition. 185 Section 2 analysis this problem in more detail. Section 3 proposes 186 workarounds to improve network robustness. 188 2. Analysis of the Problem 190 As noted in Section 1, the problem discussed in this document 191 exacerbated by a number of different parameters and behaviours. Each 192 of the following sections analyze each of them in detail. 194 2.1. Default Timer Values in IPv6 Stateless Address Autoconfiguration 195 (SLAAC) 197 Many protocols, from different layers, normally employ timers. The 198 general logic is as follows: 200 o A timer is set with a value such that, under normal conditions, 201 the timer does *not* go off. 203 o Whenever a fault condition arises, the timer goes off, and the 204 protocol can perform fault recovery 206 One common example for the use of timers is when implementing 207 reliability mechanisms where a packet is transmitted, and unless a 208 response is received, a retransmission timer will go off to trigger 209 retransmission of the original packet. 211 For obvious reasons, the whole point of using timers is that in 212 problematic scenarios, they will go off, and trigger some recovery 213 action. 215 However, IPv6 SLAAC employs, for PIOs, these default values: 217 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 219 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 221 Under normal network conditions, these timers will be reset/refreshed 222 to the default values. However, under problematic circumstances such 223 as where the corresponding network information has become stale 224 without any explicit signal from the network (as described in 225 Section 1), it will take a host 7 days (one week) to un-prefer the 226 corresponding addresses, and 30 days (one month) to eventually remove 227 any addresses configured for the stale prefix. 229 2.2. Recovering from Stale Network Configuration Information 231 SLAAC hosts are unable to recover from stale network configuration 232 information for a number of reasons: 234 o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an RA may 235 never reduce the "RemainingLifetime" more than to two hours. If 236 the RemainingLifetime of an address is smaller than 2 hours, then 237 a Valid Lifetime smaller than 2 hours will be ignored. The 238 Preferred Lifetime of an address can be reduced to any value to 239 avoid the use of a stale prefix to be employed for new 240 communications. 242 o In the absence of explicit signalling from SLAAC routers (such as 243 sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts 244 fail to recover from stale configuration information in a timely 245 manner. However, when a network element is able to explicitly 246 signal the renumbering event, it will only be able to "un-prefer" 247 the stale prefix, but not to invalidate the prefix in question. 248 Therefore, communication with the new "owners" of the stale prefix 249 will not be possible, since the stale prefix will still be 250 considered "on-link". 252 2.3. Lack of Explicit Signaling about Stale Information 254 Whenever prefix information has changed, a SLAAC router should not 255 only advertise the new information, but should also advertise the 256 stale information with appropriate lifetime values (both "Preferred 257 Lifetime" and "Valid Lifetime" set to 0), such that there is explicit 258 signaling to SLAAC hosts to remove the stale information (including 259 configured addresses and routes). 261 However, as discussed in Section 2.2, PIOs with small Valid Lifetimes 262 will not lower the Valid Lifetime to any value shorter than two hours 263 (as per [RFC4862]). Therefore, even if a SLAAC router were to 264 explicitly signal the network about the stale configuration 265 information via RAs, such signaling would be mostly ignored. 267 2.4. Interaction Between DHCPv6-PD and SLAAC 269 While DHCPv6-PD is normally employed along with SLAAC, the 270 interaction between the two protocols is largely unspecified. Not 271 unusually, the two protocols are implemented in two different 272 software components with the interface between the two implemented by 273 some sort of script that feeds the SLAAC implementation with values 274 learned from DHCPv6-PD. 276 At times, the prefix lease time is fed as a constant value to the 277 SLAAC router implementation, meaning that, eventually, the prefix 278 lifetime advertised on the LAN side will span *past* the DHCPv6-PD 279 lease time. This is clearly incorrect, since the SLAAC router 280 implementation would be allowing the use of such prefixes for a 281 longer time than it has been granted usage of those prefixes via 282 DHCPv6-PD. 284 2.5. Use of Dynamic Prefixes 286 The problem discussed in this document would be avoided if DHCPv6-PD 287 would lease "stable" prefixes. However, a recent survey [UK-NOF] 288 indicates that 37% of the responding ISPs employ dynamic prefixes. 289 That is, dynamic IPv6 prefixes are an operational reality. 291 Deployment reality aside, there are a number of possible issues 292 associated with stable prefixes: 294 o Provisioning systems may be unable to deliver stable IPv6 295 prefixes. 297 o While there is a range of information that may be employed to 298 correlate network activity [RFC7721], the use of stable prefixes 299 clearly simplifies network activity correlation, and may 300 essentially render features such as "temporary addresses" 301 [RFC4941] irrelevant. 303 o There may be existing advice for ISPs to deliver dynamic IPv6 304 prefixes *by default* (see e.g. [GERMAN-DP]) over the privacy 305 concerns associated with stable prefixes. 307 The authors of this document understand that, for a number of reasons 308 (such as the ones stated above), IPv6 deployments may employ dynamic 309 prefixes (even at the expense of the issues discussed in this 310 document), and that there might be scenarios in which the dynamics of 311 a network are such that the network exhibits the behaviour of dynamic 312 prefixes. Rather than try to preclude how operators may run their 313 networks, this document aims at improving network robustness in the 314 deployed Internet. 316 3. Possible workarounds 318 The following subsections discuss possible operational workarounds 319 for the aforementioned problem. 321 Section 3.2 specifies the interaction between DHCPv6-PD and SLAAC, 322 such that devices such as CPEs may be in a better position to convey 323 current network information to hosts on the LAN-side. For obvious 324 reasons (legacy CPEs, etc.), this improved behaviour cannot be relied 325 upon for mitigating the problem described in Section 1. However, it 326 does contribute to more robust IPv6 networks. 328 Finally, Section 2.5 analyzes the trade-offs of employing stable vs. 329 dynamic network prefixes. 331 3.1. SLAAC Parameter Tweaking 333 An operator may wish to override some SLAAC parameters such that, 334 under normal circumstances (including some packet loss), the timers 335 will be refreshed/reset, but in the presence of network faults (such 336 as network configuration information becoming stale without explicit 337 signaling), the timers go off and trigger some fault recovering 338 action (such as un-preferring the corresponding addresses and 339 subsequently removing them). 341 The following router configuration variables (corresponding to the 342 "lifetime" parameters in PIOs) could be overridden as follows: 344 AdvValidLifetime: 1.5 * AdvDefaultLifetime 346 AdvPreferredLifetime: AdvDefaultLifetime 348 NOTE: A CPE router advertising a sub-prefix of a prefixed leased via 349 DHCPv6-PD will periodically refresh the Preferred Lifetime and the 350 Valid Lifetime of an advertised prefix to AdvPreferredLifetime and 351 AdvValidLifetime, respectively, as long as the resulting lifetime 352 of the corresponding prefixes does not extend past the DHCPv6-PD 353 lease time. 355 RATIONALE: 357 * In the context of [RFC8028], where it is clear that use of 358 addresses configured for a given prefix is tied to using the 359 next-hop router that advertised the prefix, neither the 360 "Preferred Lifetime" or the "Valid Lifetime" of a PIO should 361 never be larger than the "Router Lifetime" (AdvDefaultLifetime) 362 of Router Advertisement messages. 364 * Lacking RAs that refresh information, addresses configured for 365 advertised prefixes become un-preferred in a timelier manner, 366 and thus Rule 3 of [RFC6724] causes other configured addresses 367 (if available) to be used instead. 369 * Reducing the Valid Lifetime and Preferred Lifetimes of PIOs 370 limits the amount of time hosts may use stale prefixes, and 371 also limits the amount of time that a stale prefix needs to be 372 advertised with a lifetime of "0" on the local network (see 373 Section 12 of [RFC4861]). 375 3.2. Improved CPE behavior 377 This section specifies and clarifies requirements for CPE routers 378 (particularly when they advertise prefixes learned via DHCPv6-PD) 379 that can help mitigate the problem discussed in Section 1. This 380 would obviously make robustness dependent on the CPE (on which the 381 user or ISP may have no control), as opposed to the host itself. 383 The updated behaviour is as follows: 385 o CPE routers MUST signal stale configuration information as 386 specified in Section 3.2.1 388 o CPE routers MUST implement the DHCPv6-PD/SLAAC interface specified 389 in Section 3.2.2. 391 o CPE routers SHOULD NOT automatically send DHCPv6-PD RELEASE 392 messages upon reboot events. 394 3.2.1. Signaling Stale Configuration Information 396 In order to phase-out stale configuration information: 398 o A CPE router sending RAs that advertise dynamically-learned 399 prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on 400 stable storage, the list of prefixes being advertised on each 401 network segment. 403 o Upon changes to the advertised prefixes, and after bootstrapping, 404 the CPE router advertising prefix information via SLAAC should 405 proceed as follows: 407 * Any prefixes that were previously advertised via SLAAC, but 408 that are not currently intended for address configuration, MUST 409 be advertised with a PIO option with the "A" bit set to 1 and 410 the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 412 * Any prefixes that were previously advertised via SLAAC as "on- 413 link", but that are not currently not considered "on-link", 414 MUST be advertised with a PIO option with the "L" bit set to 1 415 and the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 417 * If both of the previous conditions are met (a prefix was 418 previously advertised with both the "A" and "L" bits set, but 419 is currently *not* intended for address configuration and is 420 *not* considered on-link), the prefix MUST be advertised with a 421 PIO option with both the "A" and "L" bits set to 1 and the 422 "Valid Lifetime" and a "Preferred Lifetime" set to 0. That is. 423 the advertisements of the previous two steps can be coalesced 424 into a single one with both the "A" and "L" bits set. 426 * The aforementioned advertisement SHOULD be performed for at 427 least the "Valid Lifetime" previously employed for such prefix. 429 The aforementioned improved behaviour assumes compliance with the 430 following existing requirements from other specifications, which we 431 reference here for clarity: 433 o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when 434 the delegated prefix changes (i.e., the current prefix is replaced 435 with a new prefix without any overlapping time period), "the IPv6 436 CE router MUST immediately advertise the old prefix with a 437 Preferred Lifetime of zero and a Valid Lifetime of either a) zero 438 or b) the lower of the current Valid Lifetime and two hours (which 439 must be decremented in real time) in a Router Advertisement 440 message as described in Section 5.5.3, (e) of [RFC4862]" 442 3.2.2. Interaction Between DHCPv6-PD and SLAAC 444 The "Preferred Lifetime" and "Valid Lifetime" of PIOs corresponding 445 to prefixes learned via DHCPv6-PD MUST NOT span past the lease time 446 of the DHCPv6-PD prefixes. This means that the advertised "Preferred 447 Lifetime" and "Valid Lifetime" MUST be dynamically adjusted such that 448 the advertised lifetimes never span past the lease time of the 449 prefixes delegated via DHCPv6-PD. 451 This is in line with these existing requirements from other 452 specifications, which we reference here for clarity: 454 o [RFC8415] specifies, in Section 6.3, that "if the delegated prefix 455 or a prefix derived from it is advertised for stateless address 456 autoconfiguration [RFC4862], the advertised preferred and valid 457 lifetimes MUST NOT exceed the corresponding remaining lifetimes of 458 the delegated prefix." 460 RATIONALE: 462 * The lifetime values employed for the "Preferred Lifetime" 463 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) 464 should never be larger than the remaining lease time for the 465 corresponding prefix (as learned via DHCPv6-PD). 467 * The lifetime values advertised for prefixes corresponding to a 468 prefix leased via DHCPv6-PD should be dynamically updated 469 (rather than static values), since otherwise the advertised 470 lifetimes would eventually span past the DHCPv6-PD lease time. 472 4. Summary of Operational Mitigations 474 4.1. Networks 476 o Employ shorter values for the Preferred Lifetime and Valid 477 Lifetime in PIOs 479 o Employ stable network prefixes where possible and desirable 481 4.2. CPE routers 483 o Implement the interface between DHCPv6-PD and SLAAC as appropriate 485 o Refrain from unnecessarily issuing DHCPv6-PD RELEASE commands upon 486 reboots 488 o Record DHCPv6-PD leases on stable storage (when possible) and 489 phase-out stale information when needed 491 5. Future Work 493 This document proposes operational mitigations to the discussed 494 problem. Improvements in the SLAAC protocol and algorithms "Default 495 Address Selection for IPv6" may achieve improved network robustness 496 and should be considered by relevant Working Groups (see e.g. 497 [I-D.gont-6man-slaac-renum]). Such work is considered out of the 498 scope of this present document, which focuses on documenting the 499 problem and proposing operational mitigations. 501 6. IANA Considerations 503 This document has no actions for IANA. 505 7. Security Considerations 507 This document discusses a problem that may arise in scenarios where 508 dynamic IPv6 prefixes are employed, and proposes workarounds to 509 mitigate the aforementioned problems. The security and privacy 510 implications of IPv6 addresses are discussed in [RFC7721]. 512 8. Acknowledgments 514 The authors would lie to thank (in alphabetical order) Mikael 515 Abrahamsson, Luis Balbinot, Brian Carpenter, Gert Doering, Nick 516 Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Albert 517 Manfredi, Jordi Palet Martinez, Richard Patterson, Michael 518 Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for providing 519 valuable comments on [I-D.gont-6man-slaac-renum], on which this 520 document is based.earlier versions of this document. 522 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 523 for a discussion of these issues. Fernando would also like to thank 524 Brian Carpenter who, over the years, has answered many questions and 525 provided valuable comments that has benefited his protocol-related 526 work. 528 The problem discussed in this document has been previously documented 529 by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], 530 and also in [RIPE-690]. Section 1 borrows text from 531 [I-D.linkova-6man-default-addr-selection-update], authored by Jen 532 Linkova. 534 9. References 536 9.1. Normative References 538 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 539 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 540 DOI 10.17487/RFC4861, September 2007, 541 . 543 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 544 Address Autoconfiguration", RFC 4862, 545 DOI 10.17487/RFC4862, September 2007, 546 . 548 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 549 Extensions for Stateless Address Autoconfiguration in 550 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 551 . 553 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 554 Hosts in a Multi-Prefix Network", RFC 8028, 555 DOI 10.17487/RFC8028, November 2016, 556 . 558 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 559 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 560 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 561 RFC 8415, DOI 10.17487/RFC8415, November 2018, 562 . 564 9.2. Informative References 566 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 567 (updated with solution)", SI6 Networks Blog, February 568 2016, . 571 [GERMAN-DP] 572 BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im 573 Privatkundengeschaft und Herstellere", Entschliessung der 574 84. Konferenz der Datenschutzbeauftragten des Bundes und 575 der Lander am 7./8. November 2012 in Frankfurt (Oder), 576 November 2012, 577 . 581 [I-D.gont-6man-slaac-renum] 582 Gont, F. and J. Zorz, "Reaction of Stateless Address 583 Autoconfiguration (SLAAC) to Renumbering Events", draft- 584 gont-6man-slaac-renum-01 (work in progress), February 585 2019. 587 [I-D.linkova-6man-default-addr-selection-update] 588 Linkova, J., "Default Address Selection and Subnet 589 Renumbering", draft-linkova-6man-default-addr-selection- 590 update-00 (work in progress), March 2017. 592 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 593 "Default Address Selection for Internet Protocol Version 6 594 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 595 . 597 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 598 Requirements for IPv6 Customer Edge Routers", RFC 7084, 599 DOI 10.17487/RFC7084, November 2013, 600 . 602 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 603 Considerations for IPv6 Address Generation Mechanisms", 604 RFC 7721, DOI 10.17487/RFC7721, March 2016, 605 . 607 [RIPE-690] 608 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 609 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 610 Meynell, K., and L. Howard, "Best Current Operational 611 Practice for Operators: IPv6 prefix assignment for end- 612 users - persistent vs non-persistent, and what size to 613 choose", RIPE 690, October 2017, 614 . 616 [UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household 617 Services) How IPv6 is being deployed?", UK NOF 39, January 618 2018, 619 . 622 Authors' Addresses 624 Fernando Gont 625 SI6 Networks 626 Segurola y Habana 4310, 7mo Piso 627 Villa Devoto, Ciudad Autonoma de Buenos Aires 628 Argentina 630 Phone: +54 11 4650 8472 631 Email: fgont@si6networks.com 632 URI: https://www.si6networks.com 634 Jan Zorz 635 Frankovo n. 165 636 Skofja Loka 637 Slovenia 639 Email: jan@go6.si 641 Richard Patterson 642 Sky UK 644 Email: richard.patterson@sky.uk