idnits 2.17.1 draft-ietf-6man-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 draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4862, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2020) is 1368 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 319, but not defined == Unused Reference: 'RFC8028' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC8504' is defined on line 521, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-cpe-slaac-renum-03 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance (6man) Working Group F. Gont 3 Internet-Draft SI6 Networks 4 Updates: 4861, 4862 (if approved) J. Zorz 5 Intended status: Standards Track Go6 Institute 6 Expires: January 28, 2021 R. Patterson 7 Sky UK 8 July 27, 2020 10 Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) 11 to Flash Renumbering Events 12 draft-ietf-6man-slaac-renum-00 14 Abstract 16 In renumbering scenarios where an IPv6 prefix suddenly becomes 17 invalid, hosts on the local network will continue using stale 18 prefixes for an unacceptably long period of time, thus resulting in 19 connectivity problems. This document improves the reaction of IPv6 20 Stateless Address Autoconfiguration to such renumbering scenarios. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 28, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. SLAAC reaction to Flash-renumbering Events . . . . . . . . . 4 59 3.1. Renumbering without Explicit Signaling . . . . . . . . . 4 60 3.2. Renumbering with Explicit Signaling . . . . . . . . . . . 5 61 4. Improvements to Stateless Address Autoconfiguration (SLAAC) . 6 62 4.1. More Appropriate Lifetime Values . . . . . . . . . . . . 7 63 4.1.1. Router Configuration Variables . . . . . . . . . . . 7 64 4.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 7 65 4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 7 66 4.3. Interface Initialization . . . . . . . . . . . . . . . . 7 67 4.4. Conveying Information in Router Advertisement (RA) 68 Messages . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.5. Recovery from Stale Configuration Information without 70 Explicit Signaling . . . . . . . . . . . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 73 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 8 74 6.1.1. Router Configuration Variables . . . . . . . . . . . 8 75 6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 8 76 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 9 77 6.2.1. NetworkManager . . . . . . . . . . . . . . . . . . . 9 78 6.3. Conveying Information in Router Advertisement (RA) 79 Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.4. Recovery from Stale Configuration Information without 81 Explicit Signaling . . . . . . . . . . . . . . . . . . . 9 82 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 9 83 6.5. Other mitigations implemented in products . . . . . . . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 9.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 13 90 A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 14 91 A.2. On a Possible Improvement to Source Address Selection . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 IPv6 network renumbering is expected to take place in a planned 97 manner, with old/stale prefixes being phased-out via reduced prefix 98 lifetimes while new prefixes (with normal lifetimes) are introduced. 99 However, there are a number of scenarios that may lead to the so- 100 called "flash-renumbering" events, where the prefix being employed on 101 a network suddenly becomes invalid and replaced by a new prefix 102 [I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local 103 network will continue using stale prefixes for an unacceptably long 104 period of time, thus resulting in connectivity problems. 105 [I-D.ietf-v6ops-slaac-renum] discusses this problem in detail. 107 In some scenarios, the local router producing the network renumbering 108 event may try to deprecate the currently-employed prefixes (thus 109 explicitly signaling the network about the renumbering event), 110 whereas in other scenarios it may be unaware about the renumbering 111 event and thus unable signal hosts about it. 113 From the perspective of a Stateless Address Autoconfiguration (SLAAC) 114 host, there are two different (but related) problems to be solved: 116 o Avoiding the use of stale addresses for new communication 117 instances 119 o Performing "garbage collection" for the stale prefixes (and 120 related network configuration information) 122 Clearly, if a host has both working and stale addresses, it is 123 paramount that it employs working addresses for new communication 124 instances. Additionally, a host should also perform garbage 125 collection for the stale prefixes/addresses, since they not only tie 126 system resources, but also prevent communication with the new 127 "owners" of the stale prefixes. 129 2. Terminology 131 The term "globally reachable" is used in this document as defined in 132 [RFC8190]. 134 The term "Global Unicast Address" (or its acronym "GUA") is used 135 throughout this document to refer to "globally reachable" [RFC8190] 136 addresses. That is, when used throughout this document, GUAs do NOT 137 include Unique Local Addresses (ULAs) [RFC4193]. Similarly, the term 138 "Global Unicast prefix" (or "GUA prefix") is employed throughout this 139 document to refer to network prefixes that specify GUAs, and does NOT 140 include the ULA prefix (FC00::/7) [RFC4193]. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. SLAAC reaction to Flash-renumbering Events 150 As noted in Section 1, in some scenarios the router triggering the 151 renumbering event may be able to explicitly signal the network about 152 this event, while in other scenarios the renumbered hosts may need to 153 infer a renumbering event is taking place. The following subsections 154 analyze specific considerations for each of these scenarios. 156 3.1. Renumbering without Explicit Signaling 158 In the absence of explicit signalling from SLAAC routers (such as 159 sending Prefix Information Options (PIOs) with small lifetimes to 160 deprecate the stale prefixes), stale prefixes will remain preferred 161 and valid according to the Preferred Lifetime and Valid Lifetime 162 values (respectively) of the last received PIO. IPv6 SLAAC employs 163 the following default values for PIOs: 165 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 167 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 169 This means that, in the absence of explicit signaling by a SLAAC 170 router to deprecate a prefix, it will take a host 7 days (one week) 171 to deprecate the corresponding addresses, and 30 days (one month) to 172 eventually remove any addresses configured for the stale prefix. 173 Clearly, for any practical purposes, employing such long default 174 values is the equivalent of not using any timers at all, since taking 175 7 days or 30 days (respectively) to recover from a network problem is 176 simply unacceptable. 178 Use of more appropriate timers in Router Advertisement messages can 179 help limit the amount of time that hosts will maintain stale 180 configuration information. Additionally, hosts are normally in a 181 position to infer that a prefix has become stale -- for example, if a 182 given router ceases to advertise an existing prefix and at the same 183 time starts to advertise a new prefix. 185 Section 4.1.1 recommends the use of more appropriate lifetimes for 186 PIOs, while Section 4.1.2 proposes to cap the accepted Valid Lifetime 187 and Preferred Lifetime values at hosts, such that more appropriate 188 values are employed even in the presence of legacy routers. 190 Section 4.5 specifies a local policy that SLAAC hosts can implement 191 to heuristically infer that network configuration information has 192 changed, such that stale configuration information can be phased out. 194 3.2. Renumbering with Explicit Signaling 196 In scenarios where a local router is aware about the renumbering 197 event, it may try to phase out the stale network configuration 198 information. In these scenarios, there are two aspects to be 199 considered: 201 o The amount of time during which the router should continue trying 202 to deprecate the stale network configuration information 204 o The ability of SLAAC hosts to phase out stale configuration in a 205 timelier manner. 207 In the absence of Router Advertisements (RAs) that include PIOs that 208 would reduce the Valid Lifetime and Preferred Lifetime of a prefix, 209 hosts would normally employ the lifetime values from PIO options of 210 the last received RA messages. Since the network could be 211 partitioned for an arbitrarily long period of time, a router would 212 need to try to deprecate a prefix for the amount of time employed for 213 the "Preferred Lifetime", and try to invalidate the prefix for the 214 amount of time employed for the "Valid Lifetime" (see Section 12 of 215 [RFC4861]). 217 NOTE: 218 Once the number of seconds in the original "Preferred Lifetime" 219 have elapsed, all hosts would have deprecated the corresponding 220 addresses anyway, while once the number of seconds in the "Valid 221 Lifetime" have elapsed, the corresponding addresses would be 222 invalidated and removed. 224 Thus, use of more appropriate default lifetimes for PIOs, as proposed 225 in Section 4.1.1, would reduce the amount of time a stale prefix 226 would need to be announced as such by a router in order to make sure 227 that it is deprecated/invalidated. 229 In scenarios where a router has positive knowledge that a prefix has 230 become invalid and thus could signal this condition to local hosts, 231 the current specifications will prevent SLAAC hosts from fully 232 recovering from such stale information. Item "e)" of Section 5.5.3 233 of [RFC4862] specifies that an RA may never reduce the 234 "RemainingLifetime" to less than two hours. Additionally, if the 235 RemainingLifetime of an address is smaller than 2 hours, then a Valid 236 Lifetime smaller than 2 hours will be ignored. The inability to 237 invalidate a stale prefix would prevent communication with the new 238 "owners" of the stale prefix, and thus is highly undesirable. On the 239 other hand, the Preferred Lifetime of an address *can* be reduced to 240 any value to avoid the use of a stale prefix for new communications. 242 Section 4.2 updates [RFC4862] such that this restriction in removed, 243 and hosts react to the advertised "Valid Lifetime" (even if it is 244 smaller than 2 hours). 246 Finally, Section 4.3 recommends that routers disseminate network 247 configuration information when a network interface is initialized, 248 such that possibly new configuration information propagates in a 249 timelier manner. 251 4. Improvements to Stateless Address Autoconfiguration (SLAAC) 253 The following subsections update [RFC4861] and [RFC4862], such that 254 the problem discussed in this document is mitigated. The 255 aforementioned updates are mostly orthogonal, and mitigate different 256 aspects of SLAAC that prevent a timely reaction to flash renumbering 257 events. 259 o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs 260 (Section 4.1.1): 261 This helps limit the amount of time a host will employ stale 262 information, and also limits the amount of time a router needs to 263 try to obsolete stale information. 265 o Cap the received Valid Lifetime and Preferred Lifetime of PIOs 266 (Section 4.1.2): 267 This helps limit the amount of time a host will employ stale 268 information, even in the presence of legacy ([RFC4861]) routers. 270 o Honor PIOs with small Valid Lifetimes (Section 4.2): 271 This allows routers to invalidate stale prefixes, since otherwise 272 [RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime 273 smaller than two hours. 275 o Recommend routers to retransmit configuration information upon 276 interface initialization/reinitialization (Section 4.3): 277 This helps spread the new information in a timelier manner, and 278 also deprecate stale information via host-side heuristics (see 279 Section 4.5). 281 o Recommend routers to always send all options (i.e. the complete 282 configuration information) in RA messages, and in the smallest 283 possible number of packets (Section 4.4): 285 This helps propagate the same information to all hosts, and also 286 allows hosts to better infer that information missing in RA 287 messages has become stale (see Section 4.5). 289 o Infer stale network configuration information from received RAs 290 (Section 4.5): 291 This allows hosts to deprecate stale network configuration 292 information, even in the absence of explicit signaling. 294 4.1. More Appropriate Lifetime Values 296 4.1.1. Router Configuration Variables 298 [TBD] 300 4.1.2. Processing of PIO Lifetimes at Hosts 302 [TBD] 304 4.2. Honor Small PIO Valid Lifetimes 306 [TBD] 308 4.3. Interface Initialization 310 [TBD] 312 4.4. Conveying Information in Router Advertisement (RA) Messages 314 [TBD] 316 4.5. Recovery from Stale Configuration Information without Explicit 317 Signaling 319 [TBD] 321 5. IANA Considerations 323 This document has no actions for IANA. 325 6. Implementation Status 327 [NOTE: This section is to be removed by the RFC-Editor before this 328 document is published as an RFC.] 330 This section summarizes the implementation status of the updates 331 proposed in this document. In some cases, they correspond to 332 variants of the mitigations proposed in this document (e.g., use of 333 reduced default lifetimes for PIOs, albeit using different values 334 than those recommended in this document). In such cases, we believe 335 these implementations signal the intent to deal with the problems 336 described in [I-D.ietf-v6ops-slaac-renum] while lacking any guidance 337 on the best possible approach to do it. 339 6.1. More Appropriate Lifetime Values 341 6.1.1. Router Configuration Variables 343 6.1.1.1. rad(8) 345 We have produced a patch for OpenBSD's rad(8) [rad] that employs the 346 default lifetimes recommended in this document, albeit it has not yet 347 been committed to the tree. The patch is available at: 348 . 350 6.1.1.2. radvd(8) 352 The radvd(8) daemon [radvd], normally employed by Linux-based router 353 implementations, currently employs different default lifetimes than 354 those recommended in [RFC4861]. radvd(8) employs the following 355 default values [radvd.conf]: 357 o Preferred Lifetime: 14400 seconds (4 hours) 359 o Valid Lifetime: 86400 seconds (1 day) 361 This is not following the specific recommendation in this document, 362 bu is already a deviation from the current standards. 364 6.1.2. Processing of PIO Lifetimes at Hosts 366 6.1.2.1. NetworkManager 368 NetworkManager [NetworkManager], user-space SLAAC implementation 369 employed by some Linux-based operating systems (such as Fedora or 370 Ubuntu), caps the lifetimes of the received PIOs as recommended in 371 this document. 373 6.1.2.2. slaacd(8) 375 slaacd(8) [slaacd], a user-space SLAAC implementation employed by 376 OpenBSD, caps the lifetimes of the received PIOs as recommended in 377 this document. 379 6.1.2.3. systemd-networkd 381 systemd-networkd [systemd], a user-space SLAAC implementation 382 employed by some Linux-based operating systems, caps the lifetimes of 383 the received PIOs as recommended in this document. 385 6.2. Honor Small PIO Valid Lifetimes 387 6.2.1. NetworkManager 389 NetworkManager [NetworkManager] processes RA messages with a Valid 390 Lifetime smaller than two hours as recommended in this document. 392 6.3. Conveying Information in Router Advertisement (RA) Messages 394 We know of no implementation that splits network configuration 395 information into multiple RA messages. 397 6.4. Recovery from Stale Configuration Information without Explicit 398 Signaling 400 6.4.1. dhcpcd(8) 402 The dhcpcd(8) daemon [dhcpcd], a user-space SLAAC implementation 403 employed by some Linux-based and BSD-derived operating systems, will 404 set the Preferred Lifetime of addresses corresponding to a given 405 prefix to 0 when a single RA from the router that previously 406 advertised the prefix fails to advertise the corresponding prefix. 407 However, it does not affect the corresponding Valid Lifetime. 408 Therefore, it can be considered a partial implementation of this 409 feature. 411 6.5. Other mitigations implemented in products 413 [FRITZ] is a Customer Edge Router that tries to deprecate stale 414 prefixes by advertising stale prefixes with a Preferred Lifetime of 415 0, and a Valid Lifetime of 2 hours (or less). There are two things 416 to note with respect to this implementation: 418 o Rather than recording prefixes on stable storage (as recommended 419 in [I-D.ietf-v6ops-cpe-slaac-renum]), this implementation checks 420 the source address of IPv6 packets, and assumes that usage of any 421 address that does not correspond to a prefix currently-advertised 422 by the Customer Edge Router is the result of stale network 423 configuration information. Hence, upon receipt of a packet that 424 employs a source address that does not correspond to a currently- 425 advertised prefix, this implementation will start advertising the 426 corresponding prefix with small lifetimes, with the intent of 427 deprecating it. 429 o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 430 of [RFC4862] (discussed in Section 4.2 of this document), upon 431 first occurrence of a stale prefix, this implementation will 432 employ a decreasing Valid Lifetime, starting from 2 hours (7200 433 seconds), as opposed to a Valid Lifetime of 0. 435 7. Security Considerations 437 When it comes to the algorithm in Section 4.5, an attacker could 438 impersonate the legitimate router and send an RA that does not 439 advertise legitimate prefixes being employed in the local network. 440 This cause the corresponding addresses to become deprecated. 441 However, the addresses would not become invalid since normal 442 unsolicited RA messages would refresh the "Preferred Lifetime" and 443 "Valid Lifetime" of such addresses. 445 However, an attacker that can impersonate a router could more easily 446 deprecate addresses by advertising the legitimate prefixes with the 447 "Preferred Lifetime" set to 0, or perform a plethora of other 448 possible of Denial of Service attacks based on forged RA messages. 449 Therefore, when attacks based on forged RA packets are a concern, 450 technologies such as RA-Guard [RFC6105] [RFC7113] should be deployed. 452 Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts may 453 help limit the duration of the effects of non-sustained attacks that 454 employ forged RAs with PIOs, since hosts would now recover in a 455 timelier manner. 457 8. Acknowledgments 459 The authors would like to thank (in alphabetical order) Mikael 460 Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Owen 461 DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob Hinden, 462 Philip Homburg, Lee Howard, Christian Huitema, Erik Kline, Jen 463 Linkova, Albert Manfredi, Roy Marples, Florian Obser, Jordi Palet 464 Martinez, Michael Richardson, Hiroki Sato, Mark Smith, Hannes 465 Frederic Sowa, Tarko Tikan, Ole Troan, and Loganaden Velvindron, for 466 providing valuable comments on earlier versions of this document. 468 The algorithm specified in Section 4.5 is the result of mailing-list 469 discussions over previous versions of this document with Philip 470 Homburg. 472 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 473 for a discussion of these issues, which led to the publication of 474 [I-D.ietf-v6ops-slaac-renum], and eventually to this document. 476 Fernando would also like to thank Brian Carpenter who, over the 477 years, has answered many questions and provided valuable comments 478 that has benefited his protocol-related work. 480 The problem discussed in this document has been previously documented 481 by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], 482 and also in [RIPE-690]. 484 9. References 486 9.1. Normative References 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 494 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 495 . 497 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 498 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 499 DOI 10.17487/RFC4861, September 2007, 500 . 502 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 503 Address Autoconfiguration", RFC 4862, 504 DOI 10.17487/RFC4862, September 2007, 505 . 507 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 508 Hosts in a Multi-Prefix Network", RFC 8028, 509 DOI 10.17487/RFC8028, November 2016, 510 . 512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 513 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 514 May 2017, . 516 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 517 "Updates to the Special-Purpose IP Address Registries", 518 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 519 . 521 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 522 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 523 January 2019, . 525 9.2. Informative References 527 [dhcpcd] Marples, R., "dhcpcd - a DHCP client", 528 . 530 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 531 (updated with solution)", SI6 Networks Blog, February 532 2016, . 535 [I-D.ietf-v6ops-cpe-slaac-renum] 536 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 537 the Reaction of Customer Edge Routers to Renumbering 538 Events", draft-ietf-v6ops-cpe-slaac-renum-03 (work in 539 progress), May 2020. 541 [I-D.ietf-v6ops-slaac-renum] 542 Gont, F., Zorz, J., and R. Patterson, "Reaction of 543 Stateless Address Autoconfiguration (SLAAC) to Flash- 544 Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work 545 in progress), May 2020. 547 [I-D.linkova-6man-default-addr-selection-update] 548 Linkova, J., "Default Address Selection and Subnet 549 Renumbering", draft-linkova-6man-default-addr-selection- 550 update-00 (work in progress), March 2017. 552 [NetworkManager] 553 NetworkManager, "NetworkManager web site", 554 . 556 [rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)", 557 . 559 [radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router 560 Advertisement Daemon (radvd)", 561 . 563 [radvd.conf] 564 Hawkins, R. and R. Johnson, "radvd.conf - configuration 565 file of the router advertisement daemon", 566 . 569 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 570 Defeating Denial of Service Attacks which employ IP Source 571 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 572 May 2000, . 574 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 575 DOI 10.17487/RFC5927, July 2010, 576 . 578 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 579 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 580 DOI 10.17487/RFC6105, February 2011, 581 . 583 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 584 "Default Address Selection for Internet Protocol Version 6 585 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 586 . 588 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 589 Advertisement Guard (RA-Guard)", RFC 7113, 590 DOI 10.17487/RFC7113, February 2014, 591 . 593 [RIPE-690] 594 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 595 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 596 Meynell, K., and L. Howard, "Best Current Operational 597 Practice for Operators: IPv6 prefix assignment for end- 598 users - persistent vs non-persistent, and what size to 599 choose", RIPE 690, October 2017, 600 . 602 [slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)", 603 . 605 [systemd] systemd, "systemd web site", . 607 Appendix A. Analysis of Some Suggested Workarounds 609 [This section is to be removed before publication of this document as 610 an RFC]. 612 During the discussion of this document, some alternative workarounds 613 were suggested on the 6man mailing-list. The following subsections 614 analyze these suggested workarounds, in the hopes of avoiding 615 rehashing the same discussions. 617 A.1. On a Possible Reaction to ICMPv6 Error Messages 619 It has been suggested that if configured addresses become stale, a 620 CPE enforcing ingress/egress filtering (BCP38) ([RFC2827]) could send 621 ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed 622 ingress/egress policy) error messages to the sending node, and that, 623 upon receipt of such error messages, the sending node could perform 624 heuristics that might help to mitigate the problem discussed in this 625 document. 627 The aforementioned proposal has a number of drawbacks and 628 limitations: 630 o It assumes that the CPE routers enforce ingress/egress filtering 631 [RFC2827]. While this is desirable behaviour, it cannot be relied 632 upon. 634 o It assumes that if the CPE enforces ingress/egress filtering, the 635 CPE will signal the packet drops to the sending node with ICMPv6 636 Type 1 (Destination Unreachable) Code 5 (Source address failed 637 ingress/egress policy) error messages. While this may be 638 desirable, [RFC2827] does not suggest signaling the packet drops 639 with ICMPv6 error messages, let alone the use of specific error 640 messages (such as Type 1 Code 5) as suggested. 642 o ICMPv6 Type 1 Code 5 could be interpreted as the employed address 643 being stale, but also as a selected route being inappropriate/ 644 suboptimal. If the later, deprecating addresses or invalidating 645 addresses upon receipt of these error messages would be 646 inappropriate. 648 o Reacting to these error messages would create a new attack vector 649 that could be exploited from remote networks. This is of 650 particular concern since ICMP-based attacks do not even require 651 that the Source Address of the attack packets be spoofed 652 [RFC5927]. 654 A.2. On a Possible Improvement to Source Address Selection 656 [RFC6724] specifies source address selection (SAS) for IPv6. 657 Conceptually, it sorts the candidate set of source addresses for a 658 given destination, based on a number of pair-wise comparison rules 659 that must be successively applied until there is a "winning" address. 661 An implementation might improve source address selection, and prefer 662 the most-recently advertised information. In order to incorporate 663 the "freshness" of information in source address selection, an 664 implementation would be updated as follows: 666 o The node is assumed to maintain a timer/counter that is updated at 667 least once per second. For example, the time(2) function from 668 unix-like systems could be employed for this purpose. 670 o The local information associated with each prefix advertised via 671 RAs on the local network is augmented with a "LastAdvertised" 672 timestamp value. Whenever an RA with a PIO with the "A" bit set 673 for such prefix is received, the "LastAdvertised" timestamp is 674 updated with the current value of the timer/counter. 676 o [RFC6724] is updated such that this rule is incorporated: 678 Rule 7.5: Prefer fresh information If one of the two source 679 addresses corresponds to a prefix that has been more recently 680 advertised, say LastAdvertised(SA) > LastAdvertised(SA), then 681 prefer that address (SA in our case). 683 A clear benefit of this approach is that a host will normally prefer 684 "fresh" addresses over possibly stale addresses. 686 However, there are a number of drawbacks associated with this 687 approach: 689 o In scenarios where multiple prefixes are being advertised on the 690 same LAN segment, the new SAS rule is *guaranteed* to result in 691 non-deterministic behaviour, with hosts frequently changing the 692 default source address. This is certainly not desirable from a 693 troubleshooting perspective. 695 o Since the rule must be incorporated before "Rule 8: Use longest 696 matching prefix" from [RFC6724], it may lead to suboptimal paths. 698 o This new rule may help to improve the selection of a source 699 address, but it does not help with the housekeeping (garbage 700 collection) of configured information: 702 * If the stale prefix is re-used in another network, nodes 703 employing stale addresses and routes for this prefix will be 704 unable to communicate with the new "owner" of the prefix, since 705 the stale prefix will most likely be considered "on-link". 707 * Given that the currently recommended default value for the 708 "Valid Lifetime" of PIOs is 2592000 seconds (30 days), it would 709 take too long for hosts to remove the configured addresses and 710 routes for the stale prefix. While the proposed update in 711 Section 4.1 of this document would mitigate this problem, the 712 lifetimes advertised by the local SLAAC router are not under 713 the control of hosts. 715 As a result, updating IPv6 source address selection does not relieve 716 nodes from improving their SLAAC implementations as specified in 717 Section 4, if at all desirable. On the other hand, the algorithm 718 specified in Section 4.5 would result in Rule 3 of [RFC6724] 719 employing fresh addresses, without leading to non-deterministic 720 behaviour. 722 Authors' Addresses 724 Fernando Gont 725 SI6 Networks 726 Segurola y Habana 4310, 7mo Piso 727 Villa Devoto, Ciudad Autonoma de Buenos Aires 728 Argentina 730 Email: fgont@si6networks.com 731 URI: https://www.si6networks.com 733 Jan Zorz 734 Go6 Institute 735 Frankovo naselje 165 736 Skofja Loka 4220 737 Slovenia 739 Email: jan@go6.si 740 URI: https://www.go6.si 742 Richard Patterson 743 Sky UK 745 Email: richard.patterson@sky.uk