idnits 2.17.1 draft-ietf-6man-slaac-renum-01.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 (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 (August 26, 2020) is 1338 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 380, but not defined == Unused Reference: 'RFC8028' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'RFC8504' is defined on line 587, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-cpe-slaac-renum-04 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-03 -- Obsolete informational reference (is this intentional?): RFC 1971 (Obsoleted by RFC 2462) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 5 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 6connect 6 Expires: February 27, 2021 R. Patterson 7 Sky UK 8 August 26, 2020 10 Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) 11 to Flash Renumbering Events 12 draft-ietf-6man-slaac-renum-01 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 February 27, 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 . . . . . . . . . . . . . . . . 8 67 4.4. Conveying Information in Router Advertisement (RA) 68 Messages . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.5. Recovery from Stale Configuration Information without 70 Explicit Signaling . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 73 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 9 74 6.1.1. Router Configuration Variables . . . . . . . . . . . 9 75 6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 9 76 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 10 77 6.2.1. Linux Kernel . . . . . . . . . . . . . . . . . . . . 10 78 6.2.2. NetworkManager . . . . . . . . . . . . . . . . . . . 10 79 6.3. Conveying Information in Router Advertisement (RA) 80 Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6.4. Recovery from Stale Configuration Information without 82 Explicit Signaling . . . . . . . . . . . . . . . . . . . 10 83 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 10 84 6.5. Other mitigations implemented in products . . . . . . . . 11 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 89 9.2. Informative References . . . . . . . . . . . . . . . . . 13 90 Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 15 91 A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 15 92 A.2. On a Possible Improvement to Source Address Selection . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 IPv6 network renumbering is expected to take place in a planned 98 manner, with old/stale prefixes being phased-out via reduced prefix 99 lifetimes while new prefixes (with normal lifetimes) are introduced. 100 However, there are a number of scenarios that may lead to the so- 101 called "flash-renumbering" events, where the prefix being employed on 102 a network suddenly becomes invalid and replaced by a new prefix 103 [I-D.ietf-v6ops-slaac-renum]. In such scenarios, hosts on the local 104 network will continue using stale prefixes for an unacceptably long 105 period of time, thus resulting in connectivity problems. 106 [I-D.ietf-v6ops-slaac-renum] discusses this problem in detail. 108 In some scenarios, the local router producing the network renumbering 109 event may try to deprecate the currently-employed prefixes (thus 110 explicitly signaling the network about the renumbering event), 111 whereas in other scenarios it may be unaware about the renumbering 112 event and thus unable signal hosts about it. 114 From the perspective of a Stateless Address Autoconfiguration (SLAAC) 115 host, there are two different (but related) problems to be solved: 117 o Avoiding the use of stale addresses for new communication 118 instances 120 o Performing "garbage collection" for the stale prefixes (and 121 related network configuration information) 123 Clearly, if a host has both working and stale addresses, it is 124 paramount that it employs working addresses for new communication 125 instances. Additionally, a host should also perform garbage 126 collection for the stale prefixes/addresses, since they not only tie 127 system resources, but also prevent communication with the new 128 "owners" of the stale prefixes. 130 2. Terminology 132 The term "globally reachable" is used in this document as defined in 133 [RFC8190]. 135 The term "Global Unicast Address" (or its acronym "GUA") is used 136 throughout this document to refer to "globally reachable" [RFC8190] 137 addresses. That is, when used throughout this document, GUAs do NOT 138 include Unique Local Addresses (ULAs) [RFC4193]. Similarly, the term 139 "Global Unicast prefix" (or "GUA prefix") is employed throughout this 140 document to refer to network prefixes that specify GUAs, and does NOT 141 include the ULA prefix (FC00::/7) [RFC4193]. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 3. SLAAC reaction to Flash-renumbering Events 151 As noted in Section 1, in some scenarios the router triggering the 152 renumbering event may be able to explicitly signal the network about 153 this event, while in other scenarios the renumbered hosts may need to 154 infer a renumbering event is taking place. The following subsections 155 analyze specific considerations for each of these scenarios. 157 3.1. Renumbering without Explicit Signaling 159 In the absence of explicit signalling from SLAAC routers (such as 160 sending Prefix Information Options (PIOs) with small lifetimes to 161 deprecate the stale prefixes), stale prefixes will remain preferred 162 and valid according to the Preferred Lifetime and Valid Lifetime 163 values (respectively) of the last received PIO. IPv6 SLAAC employs 164 the following default values for PIOs: 166 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 168 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 170 This means that, in the absence of explicit signaling by a SLAAC 171 router to deprecate a prefix, it will take a host 7 days (one week) 172 to deprecate the corresponding addresses, and 30 days (one month) to 173 eventually remove any addresses configured for the stale prefix. 174 Clearly, for any practical purposes, employing such long default 175 values is the equivalent of not using any timers at all, since taking 176 7 days or 30 days (respectively) to recover from a network problem is 177 simply unacceptable. 179 Use of more appropriate timers in Router Advertisement messages can 180 help limit the amount of time that hosts will maintain stale 181 configuration information. Additionally, hosts are normally in a 182 position to infer that a prefix has become stale -- for example, if a 183 given router ceases to advertise an existing prefix and at the same 184 time starts to advertise a new prefix. 186 Section 4.1.1 recommends the use of more appropriate lifetimes for 187 PIOs, while Section 4.1.2 proposes to cap the accepted Valid Lifetime 188 and Preferred Lifetime values at hosts, such that more appropriate 189 values are employed even in the presence of legacy routers. 191 Section 4.5 specifies a local policy that SLAAC hosts can implement 192 to heuristically infer that network configuration information has 193 changed, such that stale configuration information can be phased out. 195 3.2. Renumbering with Explicit Signaling 197 In scenarios where a local router is aware about the renumbering 198 event, it may try to phase out the stale network configuration 199 information. In these scenarios, there are two aspects to be 200 considered: 202 o The amount of time during which the router should continue trying 203 to deprecate the stale network configuration information 205 o The ability of SLAAC hosts to phase out stale configuration in a 206 timelier manner. 208 In the absence of Router Advertisements (RAs) that include PIOs that 209 would reduce the Valid Lifetime and Preferred Lifetime of a prefix, 210 hosts would normally employ the lifetime values from PIO options of 211 the last received RA messages. Since the network could be 212 partitioned for an arbitrarily long period of time, a router would 213 need to try to deprecate a prefix for the amount of time employed for 214 the "Preferred Lifetime", and try to invalidate the prefix for the 215 amount of time employed for the "Valid Lifetime" (see Section 12 of 216 [RFC4861]). 218 NOTE: 219 Once the number of seconds in the original "Preferred Lifetime" 220 have elapsed, all hosts would have deprecated the corresponding 221 addresses anyway, while once the number of seconds in the "Valid 222 Lifetime" have elapsed, the corresponding addresses would be 223 invalidated and removed. 225 Thus, use of more appropriate default lifetimes for PIOs, as proposed 226 in Section 4.1.1, would reduce the amount of time a stale prefix 227 would need to be announced as such by a router in order to make sure 228 that it is deprecated/invalidated. 230 In scenarios where a router has positive knowledge that a prefix has 231 become invalid and thus could signal this condition to local hosts, 232 the current specifications will prevent SLAAC hosts from fully 233 recovering from such stale information. Item "e)" of Section 5.5.3 234 of [RFC4862] specifies that an RA may never reduce the 235 "RemainingLifetime" to less than two hours. Additionally, if the 236 RemainingLifetime of an address is smaller than 2 hours, then a Valid 237 Lifetime smaller than 2 hours will be ignored. The inability to 238 invalidate a stale prefix would prevent communication with the new 239 "owners" of the stale prefix, and thus is highly undesirable. On the 240 other hand, the Preferred Lifetime of an address *can* be reduced to 241 any value to avoid the use of a stale prefix for new communications. 243 Section 4.2 updates [RFC4862] such that this restriction in removed, 244 and hosts react to the advertised "Valid Lifetime" (even if it is 245 smaller than 2 hours). 247 Finally, Section 4.3 recommends that routers disseminate network 248 configuration information when a network interface is initialized, 249 such that possibly new configuration information propagates in a 250 timelier manner. 252 4. Improvements to Stateless Address Autoconfiguration (SLAAC) 254 The following subsections update [RFC4861] and [RFC4862], such that 255 the problem discussed in this document is mitigated. The 256 aforementioned updates are mostly orthogonal, and mitigate different 257 aspects of SLAAC that prevent a timely reaction to flash renumbering 258 events. 260 o Reduce the default Valid Lifetime and Preferred Lifetime of PIOs 261 (Section 4.1.1): 262 This helps limit the amount of time a host will employ stale 263 information, and also limits the amount of time a router needs to 264 try to obsolete stale information. 266 o Cap the received Valid Lifetime and Preferred Lifetime of PIOs 267 (Section 4.1.2): 268 This helps limit the amount of time a host will employ stale 269 information, even in the presence of legacy ([RFC4861]) routers. 271 o Honor PIOs with small Valid Lifetimes (Section 4.2): 272 This allows routers to invalidate stale prefixes, since otherwise 273 [RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime 274 smaller than two hours. 276 o Recommend routers to retransmit configuration information upon 277 interface initialization/reinitialization (Section 4.3): 278 This helps spread the new information in a timelier manner, and 279 also deprecate stale information via host-side heuristics (see 280 Section 4.5). 282 o Recommend routers to always send all options (i.e. the complete 283 configuration information) in RA messages, and in the smallest 284 possible number of packets (Section 4.4): 286 This helps propagate the same information to all hosts, and also 287 allows hosts to better infer that information missing in RA 288 messages has become stale (see Section 4.5). 290 o Infer stale network configuration information from received RAs 291 (Section 4.5): 292 This allows hosts to deprecate stale network configuration 293 information, even in the absence of explicit signaling. 295 4.1. More Appropriate Lifetime Values 297 4.1.1. Router Configuration Variables 299 [TBD] 301 4.1.2. Processing of PIO Lifetimes at Hosts 303 [TBD] 305 4.2. Honor Small PIO Valid Lifetimes 307 The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is 308 replaced with the following text: 310 e) If the advertised prefix is equal to the prefix of an address 311 configured by stateless autoconfiguration in the list, the valid 312 lifetime and the preferred lifetime of the address should be 313 updated by processing the Valid Lifetime and the Preferred 314 Lifetime (respectively) in the received advertisement. 316 NOTE: 317 "Processing" the Valid Lifetime and Preferred Lifetime includes 318 capping the received values as specified in Section 4.1.2 of this 319 document. 321 RATIONALE: 323 * This change allows hosts to react to the information provided 324 by a router that has positive knowledge that a prefix has 325 become invalid. 327 * The behavior described in RFC4862 had been incorporated during 328 the revision of the original IPv6 Stateless Address 329 Autoconfiguration specification ([RFC1971]). At the time, the 330 IPNG working group decided to mitigate the attack vector 331 represented by Prefix Information Options with very short 332 lifetimes, on the premise these packets represented a bigger 333 risk than other ND-based attack vectors [IPNG-minutes]. 335 While reconsidering the trade-offs represented by such 336 decision, we conclude that the drawbacks of mitigating the 337 aforementioned attack vector outweigh the possible benefits. 339 In scenarios where RA-based attacks are of concern, proper 340 mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND 341 [RFC3971] should be implemented. 343 4.3. Interface Initialization 345 When an interface is initialized, it is paramount that network 346 configuration information is spread on the corresponding network 347 (particularly in scenarios where an interface has been re- 348 initialized, and the conveyed information has changed). Thus, this 349 document replaces the following text from Section 6.2.4 of [RFC4861]: 351 In such cases, the router MAY transmit up to 352 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using 353 the same rules as when an interface becomes an advertising 354 interface. 356 with: 358 In such cases, the router SHOULD transmit 359 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using 360 the same rules as when an interface becomes an advertising 361 interface. 363 RATIONALE: 365 * Use of stale information can lead to interoperability problems. 366 Therefore, it is important that new configuration information 367 propagates in a timelier manner to all hosts. 369 NOTE: 370 [I-D.ietf-v6ops-cpe-slaac-renum] specifies recommendations for CPE 371 routers to deprecate any stale network configuration information. 373 4.4. Conveying Information in Router Advertisement (RA) Messages 375 [TBD] 377 4.5. Recovery from Stale Configuration Information without Explicit 378 Signaling 380 [TBD] 382 5. IANA Considerations 384 This document has no actions for IANA. 386 6. Implementation Status 388 [NOTE: This section is to be removed by the RFC-Editor before this 389 document is published as an RFC.] 391 This section summarizes the implementation status of the updates 392 proposed in this document. In some cases, they correspond to 393 variants of the mitigations proposed in this document (e.g., use of 394 reduced default lifetimes for PIOs, albeit using different values 395 than those recommended in this document). In such cases, we believe 396 these implementations signal the intent to deal with the problems 397 described in [I-D.ietf-v6ops-slaac-renum] while lacking any guidance 398 on the best possible approach to do it. 400 6.1. More Appropriate Lifetime Values 402 6.1.1. Router Configuration Variables 404 6.1.1.1. rad(8) 406 We have produced a patch for OpenBSD's rad(8) [rad] that employs the 407 default lifetimes recommended in this document, albeit it has not yet 408 been committed to the tree. The patch is available at: 409 . 411 6.1.1.2. radvd(8) 413 The radvd(8) daemon [radvd], normally employed by Linux-based router 414 implementations, currently employs different default lifetimes than 415 those recommended in [RFC4861]. radvd(8) employs the following 416 default values [radvd.conf]: 418 o Preferred Lifetime: 14400 seconds (4 hours) 420 o Valid Lifetime: 86400 seconds (1 day) 422 This is not following the specific recommendation in this document, 423 bu is already a deviation from the current standards. 425 6.1.2. Processing of PIO Lifetimes at Hosts 426 6.1.2.1. NetworkManager 428 NetworkManager [NetworkManager], user-space SLAAC implementation 429 employed by some Linux-based operating systems (such as Fedora or 430 Ubuntu), caps the lifetimes of the received PIOs as recommended in 431 this document. 433 6.1.2.2. slaacd(8) 435 slaacd(8) [slaacd], a user-space SLAAC implementation employed by 436 OpenBSD, caps the lifetimes of the received PIOs as recommended in 437 this document. 439 6.1.2.3. systemd-networkd 441 systemd-networkd [systemd], a user-space SLAAC implementation 442 employed by some Linux-based operating systems, caps the lifetimes of 443 the received PIOs as recommended in this document. 445 6.2. Honor Small PIO Valid Lifetimes 447 6.2.1. Linux Kernel 449 A Linux kernel implementation of this document has been committed to 450 the net-next tree. The implementation was produced in April 2020 by 451 Fernando Gont . The corresponding patch can 452 be found at: 455 6.2.2. NetworkManager 457 NetworkManager [NetworkManager] processes RA messages with a Valid 458 Lifetime smaller than two hours as recommended in this document. 460 6.3. Conveying Information in Router Advertisement (RA) Messages 462 We know of no implementation that splits network configuration 463 information into multiple RA messages. 465 6.4. Recovery from Stale Configuration Information without Explicit 466 Signaling 468 6.4.1. dhcpcd(8) 470 The dhcpcd(8) daemon [dhcpcd], a user-space SLAAC implementation 471 employed by some Linux-based and BSD-derived operating systems, will 472 set the Preferred Lifetime of addresses corresponding to a given 473 prefix to 0 when a single RA from the router that previously 474 advertised the prefix fails to advertise the corresponding prefix. 475 However, it does not affect the corresponding Valid Lifetime. 476 Therefore, it can be considered a partial implementation of this 477 feature. 479 6.5. Other mitigations implemented in products 481 [FRITZ] is a Customer Edge Router that tries to deprecate stale 482 prefixes by advertising stale prefixes with a Preferred Lifetime of 483 0, and a Valid Lifetime of 2 hours (or less). There are two things 484 to note with respect to this implementation: 486 o Rather than recording prefixes on stable storage (as recommended 487 in [I-D.ietf-v6ops-cpe-slaac-renum]), this implementation checks 488 the source address of IPv6 packets, and assumes that usage of any 489 address that does not correspond to a prefix currently-advertised 490 by the Customer Edge Router is the result of stale network 491 configuration information. Hence, upon receipt of a packet that 492 employs a source address that does not correspond to a currently- 493 advertised prefix, this implementation will start advertising the 494 corresponding prefix with small lifetimes, with the intent of 495 deprecating it. 497 o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 498 of [RFC4862] (discussed in Section 4.2 of this document), upon 499 first occurrence of a stale prefix, this implementation will 500 employ a decreasing Valid Lifetime, starting from 2 hours (7200 501 seconds), as opposed to a Valid Lifetime of 0. 503 7. Security Considerations 505 The protocol update in Section 4.2 could allow an on-link attacker to 506 perform a Denial of Service attack againts local hosts, by sending a 507 forged RA with a PIO with a Valid Lifetime of 0. Upon receipt of 508 that packet, local hosts would invalidate the corresponding prefix, 509 and therefore remove any addresses configured for that prefix, 510 possibly terminating e.g. TCP connections employing such addresses. 511 However, an attacker may achieve similar effects via a number for ND- 512 based attack vectors, such as directing traffic to a non-existing 513 node until ongoing TCP connections time out, or performing a ND-based 514 man-in-the-middle (MITM) attack and subsequently forging TCP RST 515 segments to cause on-going TCP connections to be aborted. Thus, for 516 all practical purposes, this attack vector does not really represent 517 a greater risk than other ND attack vectors. As noted in Section 4.2 518 , in scenarios where RA-based attacks are of concern, proper 519 mitigations such as RA-Guard [RFC6105] [RFC7113] or SEND [RFC3971] 520 should be implemented. 522 8. Acknowledgments 524 The authors would like to thank (in alphabetical order) Mikael 525 Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Lorenzo 526 Colitti, Owen DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob 527 Hinden, Philip Homburg, Lee Howard, Christian Huitema, Tatuya Jinmei, 528 Erik Kline, Ted Lemon, Jen Linkova, Albert Manfredi, Roy Marples, 529 Florian Obser, Jordi Palet Martinez, Michael Richardson, Hiroki Sato, 530 Mark Smith, Hannes Frederic Sowa, Dave Thaler, Tarko Tikan, Ole 531 Troan, Eduard Vasilenko, and Loganaden Velvindron, for providing 532 valuable comments on earlier versions of this document. 534 The algorithm specified in Section 4.5 is the result of mailing-list 535 discussions over previous versions of this document with Philip 536 Homburg. 538 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 539 for a discussion of these issues, which led to the publication of 540 [I-D.ietf-v6ops-slaac-renum], and eventually to this document. 542 Fernando would also like to thank Brian Carpenter who, over the 543 years, has answered many questions and provided valuable comments 544 that has benefited his protocol-related work. 546 The problem discussed in this document has been previously documented 547 by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], 548 and also in [RIPE-690]. 550 9. References 552 9.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, 556 DOI 10.17487/RFC2119, March 1997, 557 . 559 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 560 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 561 . 563 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 564 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 565 DOI 10.17487/RFC4861, September 2007, 566 . 568 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 569 Address Autoconfiguration", RFC 4862, 570 DOI 10.17487/RFC4862, September 2007, 571 . 573 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 574 Hosts in a Multi-Prefix Network", RFC 8028, 575 DOI 10.17487/RFC8028, November 2016, 576 . 578 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 579 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 580 May 2017, . 582 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 583 "Updates to the Special-Purpose IP Address Registries", 584 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 585 . 587 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 588 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 589 January 2019, . 591 9.2. Informative References 593 [dhcpcd] Marples, R., "dhcpcd - a DHCP client", 594 . 596 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 597 (updated with solution)", SI6 Networks Blog, February 598 2016, . 601 [I-D.ietf-v6ops-cpe-slaac-renum] 602 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 603 the Reaction of Customer Edge Routers to Renumbering 604 Events", draft-ietf-v6ops-cpe-slaac-renum-04 (work in 605 progress), August 2020. 607 [I-D.ietf-v6ops-slaac-renum] 608 Gont, F., Zorz, J., and R. Patterson, "Reaction of 609 Stateless Address Autoconfiguration (SLAAC) to Flash- 610 Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work 611 in progress), August 2020. 613 [I-D.linkova-6man-default-addr-selection-update] 614 Linkova, J., "Default Address Selection and Subnet 615 Renumbering", draft-linkova-6man-default-addr-selection- 616 update-00 (work in progress), March 2017. 618 [IPNG-minutes] 619 IETF, "IPNG working group (ipngwg) Meeting Minutes", 620 Proceedings of the thirty-eightt Internet Engineering Task 621 Force , April 1997, . 624 [NetworkManager] 625 NetworkManager, "NetworkManager web site", 626 . 628 [rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)", 629 . 631 [radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router 632 Advertisement Daemon (radvd)", 633 . 635 [radvd.conf] 636 Hawkins, R. and R. Johnson, "radvd.conf - configuration 637 file of the router advertisement daemon", 638 . 641 [RFC1971] Thomson, S. and T. Narten, "IPv6 Stateless Address 642 Autoconfiguration", RFC 1971, DOI 10.17487/RFC1971, August 643 1996, . 645 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 646 Defeating Denial of Service Attacks which employ IP Source 647 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 648 May 2000, . 650 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 651 "SEcure Neighbor Discovery (SEND)", RFC 3971, 652 DOI 10.17487/RFC3971, March 2005, 653 . 655 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 656 DOI 10.17487/RFC5927, July 2010, 657 . 659 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 660 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 661 DOI 10.17487/RFC6105, February 2011, 662 . 664 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 665 "Default Address Selection for Internet Protocol Version 6 666 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 667 . 669 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 670 Advertisement Guard (RA-Guard)", RFC 7113, 671 DOI 10.17487/RFC7113, February 2014, 672 . 674 [RIPE-690] 675 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 676 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 677 Meynell, K., and L. Howard, "Best Current Operational 678 Practice for Operators: IPv6 prefix assignment for end- 679 users - persistent vs non-persistent, and what size to 680 choose", RIPE 690, October 2017, 681 . 683 [slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)", 684 . 686 [systemd] systemd, "systemd web site", . 688 Appendix A. Analysis of Some Suggested Workarounds 690 [This section is to be removed before publication of this document as 691 an RFC]. 693 During the discussion of this document, some alternative workarounds 694 were suggested on the 6man mailing-list. The following subsections 695 analyze these suggested workarounds, in the hopes of avoiding 696 rehashing the same discussions. 698 A.1. On a Possible Reaction to ICMPv6 Error Messages 700 It has been suggested that if configured addresses become stale, a 701 CPE enforcing ingress/egress filtering (BCP38) ([RFC2827]) could send 702 ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed 703 ingress/egress policy) error messages to the sending node, and that, 704 upon receipt of such error messages, the sending node could perform 705 heuristics that might help to mitigate the problem discussed in this 706 document. 708 The aforementioned proposal has a number of drawbacks and 709 limitations: 711 o It assumes that the CPE routers enforce ingress/egress filtering 712 [RFC2827]. While this is desirable behaviour, it cannot be relied 713 upon. 715 o It assumes that if the CPE enforces ingress/egress filtering, the 716 CPE will signal the packet drops to the sending node with ICMPv6 717 Type 1 (Destination Unreachable) Code 5 (Source address failed 718 ingress/egress policy) error messages. While this may be 719 desirable, [RFC2827] does not suggest signaling the packet drops 720 with ICMPv6 error messages, let alone the use of specific error 721 messages (such as Type 1 Code 5) as suggested. 723 o ICMPv6 Type 1 Code 5 could be interpreted as the employed address 724 being stale, but also as a selected route being inappropriate/ 725 suboptimal. If the later, deprecating addresses or invalidating 726 addresses upon receipt of these error messages would be 727 inappropriate. 729 o Reacting to these error messages would create a new attack vector 730 that could be exploited from remote networks. This is of 731 particular concern since ICMP-based attacks do not even require 732 that the Source Address of the attack packets be spoofed 733 [RFC5927]. 735 A.2. On a Possible Improvement to Source Address Selection 737 [RFC6724] specifies source address selection (SAS) for IPv6. 738 Conceptually, it sorts the candidate set of source addresses for a 739 given destination, based on a number of pair-wise comparison rules 740 that must be successively applied until there is a "winning" address. 742 An implementation might improve source address selection, and prefer 743 the most-recently advertised information. In order to incorporate 744 the "freshness" of information in source address selection, an 745 implementation would be updated as follows: 747 o The node is assumed to maintain a timer/counter that is updated at 748 least once per second. For example, the time(2) function from 749 unix-like systems could be employed for this purpose. 751 o The local information associated with each prefix advertised via 752 RAs on the local network is augmented with a "LastAdvertised" 753 timestamp value. Whenever an RA with a PIO with the "A" bit set 754 for such prefix is received, the "LastAdvertised" timestamp is 755 updated with the current value of the timer/counter. 757 o [RFC6724] is updated such that this rule is incorporated: 759 Rule 7.5: Prefer fresh information If one of the two source 760 addresses corresponds to a prefix that has been more recently 761 advertised, say LastAdvertised(SA) > LastAdvertised(SA), then 762 prefer that address (SA in our case). 764 A clear benefit of this approach is that a host will normally prefer 765 "fresh" addresses over possibly stale addresses. 767 However, there are a number of drawbacks associated with this 768 approach: 770 o In scenarios where multiple prefixes are being advertised on the 771 same LAN segment, the new SAS rule is *guaranteed* to result in 772 non-deterministic behaviour, with hosts frequently changing the 773 default source address. This is certainly not desirable from a 774 troubleshooting perspective. 776 o Since the rule must be incorporated before "Rule 8: Use longest 777 matching prefix" from [RFC6724], it may lead to suboptimal paths. 779 o This new rule may help to improve the selection of a source 780 address, but it does not help with the housekeeping (garbage 781 collection) of configured information: 783 * If the stale prefix is re-used in another network, nodes 784 employing stale addresses and routes for this prefix will be 785 unable to communicate with the new "owner" of the prefix, since 786 the stale prefix will most likely be considered "on-link". 788 * Given that the currently recommended default value for the 789 "Valid Lifetime" of PIOs is 2592000 seconds (30 days), it would 790 take too long for hosts to remove the configured addresses and 791 routes for the stale prefix. While the proposed update in 792 Section 4.1 of this document would mitigate this problem, the 793 lifetimes advertised by the local SLAAC router are not under 794 the control of hosts. 796 As a result, updating IPv6 source address selection does not relieve 797 nodes from improving their SLAAC implementations as specified in 798 Section 4, if at all desirable. On the other hand, the algorithm 799 specified in Section 4.5 would result in Rule 3 of [RFC6724] 800 employing fresh addresses, without leading to non-deterministic 801 behaviour. 803 Authors' Addresses 805 Fernando Gont 806 SI6 Networks 807 Segurola y Habana 4310, 7mo Piso 808 Villa Devoto, Ciudad Autonoma de Buenos Aires 809 Argentina 811 Email: fgont@si6networks.com 812 URI: https://www.si6networks.com 814 Jan Zorz 815 6connect 817 Email: jan@connect.com 819 Richard Patterson 820 Sky UK 822 Email: richard.patterson@sky.uk