idnits 2.17.1 draft-gont-v6ops-slaac-renum-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 20, 2020) is 1517 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-02 Summary: 1 error (**), 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: August 23, 2020 Go6 Institute 6 R. Patterson 7 Sky UK 8 February 20, 2020 10 Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- 11 Renumbering Events 12 draft-gont-v6ops-slaac-renum-02 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 documents this problem, and discusses operational workarounds that 23 may help to improve network robustness. Additionally, it highlights 24 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 August 23, 2020. 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) . . . . . . . . . . . . . . . . 5 65 2.3. Recovering from Stale Network Configuration Information . 6 66 2.4. Lack of Explicit Signaling about Stale Information . . . 7 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 . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 IPv6 largely assumes prefix stability, with network renumbering only 83 taking place in a planned manner, with old/stale prefixes being 84 phased-out via reduced prefix lifetimes, and new prefixes (with 85 longer lifetimes) being introduced at the same time. However, there 86 are a number of scenarios that may lead to the so-called "flash- 87 renumbering" events, where the prefix employed by a network suddenly 88 becomes invalid and replaced by a new prefix. In some of these 89 scenarios, the local router producing the network renumbering event 90 may try to deprecate the currently-employed prefixes (by explicitly 91 signaling the network about the renumbering event), whereas in other 92 scenarios it may be unable to do so. 94 In scenarios where network configuration information related to IPv6 95 prefixes becomes invalid without any explicit signaling of that 96 condition, nodes on the local network will continue using stale 97 prefixes for an unacceptably long period of time, thus resulting in 98 connectivity problems. 100 Scenarios where this problem may arise include, but are not limited 101 to, the following: 103 o The most common IPv6 deployment scenario for residential or small 104 office networks is that in which a CPE router employs DHCPv6 105 Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from 106 an Internet Service Provider (ISP), and a sub-prefix of the leased 107 prefix is advertised on the LAN-side of the CPE router via 108 Stateless Address Autoconfiguration (SLAAC) [RFC4862]. In 109 scenarios where the CPE router crashes and reboots, the CPE may be 110 leased (via DHCPv6-PD) a different prefix from the one previously 111 leased, and therefore advertise (via SLAAC) the new prefix on the 112 LAN side. Hosts will normally configure addresses for the new 113 prefix, but will normally retain and actively employ the addresses 114 configured for the previously-advertised prefix, since their 115 associated Preferred Lifetime and Valid Lifetime allow them to do 116 so. 118 o A switch-port the host is connected to may be moved to another 119 subnet (VLAN) as a result of manual switch-port reconfiguration or 120 802.1x re-authentication. In particular there has been evidence 121 that some 802.1x supplicants do not reset network settings after 122 successful 802.1x authentication. So if a host had failed 802.1x 123 authentication for some reason, was placed in a "quarantine" VLAN 124 and then got successfully authenticated later on, it might end up 125 having IPv6 addresses from both old ("quarantine") and new VLANs. 127 o During the planned network renumbering, a router may be configured 128 to send an RA with the Preferred Lifetime for the "old" Prefix 129 Information Option (PIO) set to zero and the new PIO having non- 130 zero preferred lifetime. However, due to unsolicited RAs being 131 sent as all-hosts multicast and multicast being rather unreliable 132 on busy wifi networks, the RA may not be received by a host (or 133 set of hosts). 135 o Automated device config management system performs periodical 136 config push to network devices. If such a push results in 137 changing the /64 subnet configured on a particular network, hosts 138 attached to that network would not get notified about the subnet 139 change and their addresses from the "old" prefix will not 140 deprecated. A related scenario is the incorrect network 141 renumbering where a network administrator renumbers a network by 142 simply removing the "old" prefix from the configuration and 143 configuring a new prefix instead. 145 Lacking any explicit signaling to "deprecate" the previously- 146 advertised prefixes, hosts may continue to employ the previously- 147 configured addresses which will typically result in packets being 148 blackholed -- whether because of egress-filtering by the CPE or ISP, 149 or because responses to such packets be discarded or routed 150 elsewhere. 152 We note that the default values for the "Valid Lifetime" and 153 "Preferred Lifetime" of PIOs, as specified in [RFC4861], are: 155 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 157 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 159 This means that in the aforementioned scenarios, the stale addresses 160 would be retained and also actively employed for new communications 161 instances for unacceptably long period of time (one month, and one 162 week, respectively), leading to interoperability problems, instead of 163 hosts transitioning to the newly-advertised prefix(es) in a timelier 164 manner. 166 Some devices have implemented ad-hoc mechanisms to address this 167 problem, such as sending RAs to invalidate apparently-stale prefixes 168 when the device receives any packets employing a source address from 169 a prefix not currently advertised for address configuration on the 170 local network [FRITZ]. However, this may introduce other 171 interoperability problems, particularly in multihomed/multiprefix 172 scenarios. This is clear indication that advice in this area is 173 warranted. 175 Unresponsiveness to these "flash-renumbering" events is caused by the 176 inability of the network to deprecate stale information, as well as 177 by the inability of hosts to react to network configuration changes 178 in a timelier manner. Clearly, it would be desirable that these 179 flash-renumbering scenarios do not occur, and that, when they do 180 occur, that hosts are explicitly notified of their occurrence. 181 However, for robustness reasons it is also paramount for hosts to be 182 able to recover from stale configuration information even when these 183 flash-renumbering events occur and the network is unable to 184 explicitly notify hosts about such condition. 186 Section 2 analysis this problem in more detail. Section 3 describes 187 possible operational mitigations. Section 4 describes possible 188 future work to better mitigate the aforementioned problem. 190 2. Analysis of the Problem 192 As noted in Section 1, the problem discussed in this document 193 exacerbated by a number of different parameters and behaviours. Each 194 of the following sections analyze each of them in detail. 196 2.1. Use of Dynamic Prefixes 198 In the residential or small office scenario, the problem discussed in 199 this document would be avoided if DHCPv6-PD would lease "stable" 200 prefixes. However, a recent survey [UK-NOF] indicates that 37% of 201 the responding ISPs employ dynamic prefixes. That is, dynamic IPv6 202 prefixes are an operational reality. 204 Deployment reality aside, there are a number of possible issues 205 associated with stable prefixes: 207 o Provisioning systems may be unable to deliver stable IPv6 208 prefixes. 210 o While there is a range of information that may be employed to 211 correlate network activity [RFC7721], the use of stable prefixes 212 clearly simplifies network activity correlation, and may 213 essentially render features such as "temporary addresses" 214 [RFC4941] irrelevant. 216 o There may be existing advice for ISPs to deliver dynamic IPv6 217 prefixes *by default* (see e.g. [GERMAN-DP]) over privacy 218 concerns associated with stable prefixes. 220 The authors of this document understand that, for a number of reasons 221 (such as the ones stated above), IPv6 deployments may employ dynamic 222 prefixes (even at the expense of the issues discussed in this 223 document), and that there might be scenarios in which the dynamics of 224 a network are such that the network exhibits the behaviour of dynamic 225 prefixes. Rather than try to preclude how operators may run their 226 networks, this document aims at improving network robustness in the 227 deployed Internet. 229 2.2. Default Timer Values in IPv6 Stateless Address Autoconfiguration 230 (SLAAC) 232 Many protocols, from different layers, normally employ timers. The 233 general logic is as follows: 235 o A timer is set with a value such that, under normal conditions, 236 the timer does *not* go off. 238 o Whenever a fault condition arises, the timer goes off, and the 239 protocol can perform fault recovery 241 One common example for the use of timers is when implementing 242 reliability mechanisms where a packet is transmitted, and unless a 243 response is received, a retransmission timer will go off to trigger 244 retransmission of the original packet. 246 For obvious reasons, the whole point of using timers is that in 247 problematic scenarios, they will go off, and trigger some recovery 248 action. 250 However, IPv6 SLAAC employs, for PIOs, these default values: 252 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 254 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 256 Under normal network conditions, these timers will be reset/refreshed 257 to the default values. However, under problematic circumstances such 258 as where the corresponding network information has become stale 259 without any explicit signal from the network (as described in 260 Section 1), it will take a host 7 days (one week) to un-prefer the 261 corresponding addresses, and 30 days (one month) to eventually 262 invalidate and remove any addresses configured for the stale prefix. 264 2.3. Recovering from Stale Network Configuration Information 266 SLAAC hosts are unable to recover from stale network configuration 267 information for a number of reasons: 269 o Item "e)" of Section 5.5.3 of [RFC4862] specifies that an RA may 270 never reduce the "RemainingLifetime" more than to two hours. If 271 the RemainingLifetime of an address is smaller than 2 hours, then 272 a Valid Lifetime smaller than 2 hours will be ignored. The 273 Preferred Lifetime of an address can be reduced to any value to 274 avoid the use of a stale prefix to be employed for new 275 communications. 277 o In the absence of explicit signalling from SLAAC routers (such as 278 sending PIOs with a "Preferred Lifetime" set to 0), SLAAC hosts 279 fail to recover from stale configuration information in a timely 280 manner. However, when a network element is able to explicitly 281 signal the renumbering event, it will only be able to "un-prefer" 282 the stale prefix, but not to invalidate the prefix in question. 283 Therefore, communication with the new "owners" of the stale prefix 284 will not be possible, since the stale prefix will still be 285 considered "on-link". 287 2.4. Lack of Explicit Signaling about Stale Information 289 Whenever prefix information has changed, a SLAAC router should not 290 only advertise the new information, but should also advertise the 291 stale information with appropriate lifetime values (both "Preferred 292 Lifetime" and "Valid Lifetime" set to 0), such that there is explicit 293 signaling to SLAAC hosts to remove the stale information (including 294 configured addresses and routes). However, in scenarios such as when 295 a CPE router crashes and reboots, the CPE router may have no 296 knowledge about the previously-advertised prefixes, and thus may be 297 unable to advertise them with appropriate lifetimes (in order to 298 deprecate them). 300 However, we note that, as discussed in Section 2.3, PIOs with small 301 Valid Lifetimes will not lower the Valid Lifetime to any value 302 shorter than two hours (as per [RFC4862]). Therefore, even if a 303 SLAAC router were to explicitly signal the network about the stale 304 configuration information via RAs, such signaling would be mostly 305 ignored. 307 2.5. Interaction Between DHCPv6-PD and SLAAC 309 While DHCPv6-PD is normally employed along with SLAAC, the 310 interaction between the two protocols is largely unspecified. Not 311 unusually, the two protocols are implemented in two different 312 software components with the interface between the two implemented by 313 some sort of script that feeds the SLAAC implementation with values 314 learned from DHCPv6-PD. 316 At times, the prefix lease time is fed as a constant value to the 317 SLAAC router implementation, meaning that, eventually, the prefix 318 lifetime advertised on the LAN side will span *past* the DHCPv6-PD 319 lease time. This is clearly incorrect, since the SLAAC router 320 implementation would be allowing the use of such prefixes for a 321 longer time than it has been granted usage of those prefixes via 322 DHCPv6-PD. 324 3. Operational Mitigations 326 The following subsections discuss possible operational workarounds 327 for the aforementioned problem. 329 3.1. Stable Prefixes 331 As noted in Section 2.1, the use of stable prefixes would eliminate 332 the issue in *some* of the scenarios discussed in Section 1 of this 333 document, such as the typical home network deployment. However, even 334 in such scenarios, there might be reasons for which an administrator 335 may want or may need to employ dynamic prefixes 337 3.2. SLAAC Parameter Tweaking 339 An operator may wish to override some SLAAC parameters such that, 340 under normal circumstances (including some packet loss), the timers 341 will be refreshed/reset, but in the presence of network faults (such 342 as network configuration information becoming stale without explicit 343 signaling), the timers go off and trigger some fault recovering 344 action (such as un-preferring the corresponding addresses and 345 subsequently removing them). 347 The following router configuration variables (corresponding to the 348 "lifetime" parameters in PIOs) could be overridden as follows: 350 AdvValidLifetime: 48 * AdvDefaultLifetime (86400 seconds) 352 AdvPreferredLifetime: AdvDefaultLifetime (1800 seconds) 354 NOTES: A CPE router advertising a sub-prefix of a prefixed leased 355 via DHCPv6-PD will periodically refresh the Preferred Lifetime and 356 the Valid Lifetime of an advertised prefix to AdvPreferredLifetime 357 and AdvValidLifetime, respectively, as long as the resulting 358 lifetime of the corresponding prefixes does not extend past the 359 DHCPv6-PD lease time. 361 RATIONALE: 363 * In the context of [RFC8028], where it is clear that use of 364 addresses configured for a given prefix is tied to using the 365 next-hop router that advertised the prefix, it does not make 366 sense for the "Preferred Lifetime" of a PIO to be larger than 367 the "Router Lifetime" (AdvDefaultLifetime) of the corresponding 368 Router Advertisement messages. The "Valid Lifetime" is set to 369 a much larger value to cope with transient network problems. 371 * Lacking RAs that refresh information, addresses configured for 372 advertised prefixes become un-preferred in a timelier manner, 373 and thus Rule 3 of [RFC6724] causes other configured addresses 374 (if available) to be used instead. 376 * We note that lowering the default values for the "Valid 377 Lifetime" helps reduce the amount of time a host may maintain 378 stale information and the amount of time an advertising router 379 would need to advertise stale prefixes to deprecate them, while 380 reducing the default "Preferred Lifetime" would reduce the 381 amount of time it takes for a host to prefer other working 382 prefixes (see Section 12 of [RFC4861]). However, while the 383 aforementioned values are an improvement over the default 384 values specified in [RFC4861], they will not lead to a timely 385 recovery from the problem discussed in this document. 387 4. Future Work 389 Improvement in Customer Edge Routers [RFC7084] such that they can 390 signal the network about stale prefixes and deprecate them 391 accordingly can help mitigate the problem discussed in this document 392 for the "home network" scenario. Such work is currently being 393 pursued in [I-D.gont-v6ops-cpe-slaac-renum]. 395 Improvements in the SLAAC protocol [RFC4862] and other algorithms 396 such as "Default Address Selection for IPv6" [RFC6724] would help 397 improve network robustness. Such work is currently being pursued in 398 [I-D.gont-6man-slaac-renum]. 400 The aforementioned work is considered out of the scope of this 401 present document, which only focuses on documenting the problem and 402 discussing operational mitigations. 404 5. IANA Considerations 406 This document has no actions for IANA. 408 6. Security Considerations 410 This document discusses a problem that may arise in scenarios where 411 flash-renumbering events occur, and proposes workarounds to mitigate 412 the aforementioned problems. This document does not introduce any 413 new security issues. 415 7. Acknowledgments 417 The authors would lie to thank (in alphabetical order) Mikael 418 Abrahamsson, Luis Balbinot, Brian Carpenter, Tassos Chatzithomaoglou, 419 Uesley Correa, Owen DeLong, Gert Doering, Fernando Frediani, Steinar 420 Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, 421 Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael 422 Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for providing 423 valuable comments on [I-D.gont-6man-slaac-renum], on which this 424 document is based. 426 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 427 for a discussion of these issues. Fernando would also like to thank 428 Brian Carpenter who, over the years, has answered many questions and 429 provided valuable comments that has benefited his protocol-related 430 work. 432 The problem discussed in this document has been previously documented 433 by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], 434 and also in [RIPE-690]. Section 1 borrows text from 435 [I-D.linkova-6man-default-addr-selection-update], authored by Jen 436 Linkova. 438 8. References 440 8.1. Normative References 442 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 443 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 444 DOI 10.17487/RFC4861, September 2007, 445 . 447 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 448 Address Autoconfiguration", RFC 4862, 449 DOI 10.17487/RFC4862, September 2007, 450 . 452 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 453 Extensions for Stateless Address Autoconfiguration in 454 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 455 . 457 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 458 Hosts in a Multi-Prefix Network", RFC 8028, 459 DOI 10.17487/RFC8028, November 2016, 460 . 462 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 463 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 464 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 465 RFC 8415, DOI 10.17487/RFC8415, November 2018, 466 . 468 8.2. Informative References 470 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 471 (updated with solution)", SI6 Networks Blog, February 472 2016, . 475 [GERMAN-DP] 476 BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im 477 Privatkundengeschaft und Herstellere", Entschliessung der 478 84. Konferenz der Datenschutzbeauftragten des Bundes und 479 der Lander am 7./8. November 2012 in Frankfurt (Oder), 480 November 2012, 481 . 485 [I-D.gont-6man-slaac-renum] 486 Gont, F., Zorz, J., and R. Patterson, "Improving the 487 Robustness of Stateless Address Autoconfiguration (SLAAC) 488 to Flash Renumbering Events", draft-gont-6man-slaac- 489 renum-02 (work in progress), February 2020. 491 [I-D.gont-v6ops-cpe-slaac-renum] 492 Gont, F., Zorz, J., and R. Patterson, "Improving the 493 Reaction of Customer Edge Routers to Renumbering Events", 494 draft-gont-v6ops-cpe-slaac-renum-00 (work in progress), 495 November 2019. 497 [I-D.linkova-6man-default-addr-selection-update] 498 Linkova, J., "Default Address Selection and Subnet 499 Renumbering", draft-linkova-6man-default-addr-selection- 500 update-00 (work in progress), March 2017. 502 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 503 "Default Address Selection for Internet Protocol Version 6 504 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 505 . 507 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 508 Requirements for IPv6 Customer Edge Routers", RFC 7084, 509 DOI 10.17487/RFC7084, November 2013, 510 . 512 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 513 Considerations for IPv6 Address Generation Mechanisms", 514 RFC 7721, DOI 10.17487/RFC7721, March 2016, 515 . 517 [RIPE-690] 518 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 519 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 520 Meynell, K., and L. Howard, "Best Current Operational 521 Practice for Operators: IPv6 prefix assignment for end- 522 users - persistent vs non-persistent, and what size to 523 choose", RIPE 690, October 2017, 524 . 526 [UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household 527 Services) How IPv6 is being deployed?", UK NOF 39, January 528 2018, 529 . 532 Authors' Addresses 534 Fernando Gont 535 SI6 Networks 536 Segurola y Habana 4310, 7mo Piso 537 Villa Devoto, Ciudad Autonoma de Buenos Aires 538 Argentina 540 Email: fgont@si6networks.com 541 URI: https://www.si6networks.com 543 Jan Zorz 544 Go6 Institute 545 Frankovo naselje 165 546 Skofja Loka 4220 547 Slovenia 549 Email: jan@go6.si 550 URI: https://www.go6.si 552 Richard Patterson 553 Sky UK 555 Email: richard.patterson@sky.uk