idnits 2.17.1 draft-gont-6man-slaac-renum-08.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 (May 18, 2020) is 1401 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) == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-cpe-slaac-renum-02 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-slaac-renum-02 Summary: 0 errors (**), 0 flaws (~~), 3 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: November 19, 2020 R. Patterson 7 Sky UK 8 May 18, 2020 10 Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) 11 to Flash Renumbering Events 12 draft-gont-6man-slaac-renum-08 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 November 19, 2020. 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 . . . . . . . . 8 65 4.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 9 66 4.3. Interface Initialization . . . . . . . . . . . . . . . . 10 67 4.4. Conveying Information in Router Advertisement (RA) 68 Messages . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.5. Recovery from Stale Configuration Information without 70 Explicit Signaling . . . . . . . . . . . . . . . . . . . 11 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 73 6.1. More Appropriate Lifetime Values . . . . . . . . . . . . 16 74 6.1.1. Router Configuration Variables . . . . . . . . . . . 16 75 6.1.2. Processing of PIO Lifetimes at Hosts . . . . . . . . 16 76 6.2. Honor Small PIO Valid Lifetimes . . . . . . . . . . . . . 17 77 6.2.1. NetworkManager . . . . . . . . . . . . . . . . . . . 17 78 6.3. Conveying Information in Router Advertisement (RA) 79 Messages . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.4. Recovery from Stale Configuration Information without 81 Explicit Signaling . . . . . . . . . . . . . . . . . . . 17 82 6.4.1. dhcpcd(8) . . . . . . . . . . . . . . . . . . . . . . 17 83 6.5. Other mitigations implemented in products . . . . . . . . 17 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 88 9.2. Informative References . . . . . . . . . . . . . . . . . 20 89 Appendix A. Analysis of Some Suggested Workarounds . . . . . . . 21 90 A.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 21 91 A.2. On a Possible Improvement to Source Address Selection . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 The default value for the "lifetime" parameters in PIOs is updated as 299 follows: 301 AdvPreferredLifetime: max(AdvDefaultLifetime, 3 * 302 MaxRtrAdvInterval) 304 AdvValidLifetime: 48 * max(AdvDefaultLifetime, 3 * 305 MaxRtrAdvInterval) 307 where: 309 AdvPreferredLifetime: 310 Value to be included in the "Preferred Lifetime" field of the PIO. 312 AdvValidLifetime: 313 Value to be included in the "Valid Lifetime" field of the PIO. 315 AdvDefaultLifetime: 316 Value of the "Router Lifetime" field of the Router Advertisement 317 message that will carry the PIO. 319 max(): 320 A function that outputs the maximum of its arguments. 322 NOTE: 323 [RFC4861] specifies AdvDefaultLifetime as 3 * MaxRtrAdvInterval 324 (which defaults to 600 seconds). This means that, when employing 325 default values for MaxRtrAdvInterval, the Router Lifetime would be 326 set to AdvPreferredLifetime (1800 seconds). Thus, when employing 327 the default values, or when manually setting AdvDefaultLifetime to 328 a value smaller than 1800 seconds, AdvPreferredLifetime and 329 AdvValidLifetime would be set to 1800 seconds (30 minutes) and 330 86400 seconds (1 day), respectively. 332 RATIONALE: 334 * The default values for PIO lifetimes should be such that, under 335 normal circumstances (including some packet loss), the 336 associated timers are refreshed/reset, but in the presence of 337 network failures (such as network configuration information 338 becoming stale), some fault recovering action (such as 339 deprecating the corresponding addresses and subsequently 340 removing them) is triggered. 342 * In the context of [RFC8028], where it is clear that the use of 343 addresses configured for a given prefix is tied to the next-hop 344 router that advertised the prefix, the "Preferred Lifetime" of 345 a PIO should never be larger than the "Router Lifetime" of 346 Router Advertisement messages. Some leeway should be provided 347 for the "Valid Lifetime" to cope with transient network 348 problems. As a result, this document updates [RFC4861] such 349 that the default Valid Lifetime (AdvValidLifetime) and the 350 default Preferred Lifetime (AdvPreferredLifetime) of PIOs are 351 specified as a function of the default "Router Lifetime" 352 (AdvDefaultLifetime) of Router Advertisement messages. In the 353 absence of RAs that refresh information, addresses configured 354 for advertised prefixes become deprecated in a timelier manner, 355 and thus Rule 3 of [RFC6724] will cause other configured 356 addresses (if available) to be preferred. 358 * The expression above computes the maximum between 359 AdvDefaultLifetime and "3 * MaxRtrAdvInterval" (the default 360 value for AdvDefaultLifetime, as per [RFC4861]) to cope with 361 the case where an operator might simply want to disable one 362 local router for maintenance, without disabling the use of the 363 corresponding prefixes on the local network (e.g., on a multi- 364 router network). [RFC4862] implementations would otherwise 365 deprecate the corresponding prefixes. Similarly, [RFC8028] 366 would likely behave in the same way. 368 4.1.2. Processing of PIO Lifetimes at Hosts 370 Hosts SHOULD cap the "Preferred Lifetime" and "Valid Lifetime" of 371 PIOs as follows: 373 o IF (Router Lifetime != 0) AND (Preferred Lifetime != 0xffffffff) 374 AND (Valid Lifetime != 0xffffffff), then: 376 Preferred Lifetime= MIN(Preferred Lifetime, "Router Lifetime") 378 Valid Lifetime= MIN(Valid Lifetime, 48 * "Router Lifetime") 380 RATIONALE: 382 * Capping the lifetimes in PIOs as suggested will not eliminate 383 the problem discussed in this document, but will certainly 384 reduce the amount of time it takes for hosts to converge to 385 updated network configuration information, even when the SLAAC 386 router advertises PIOs with the default values specified in 387 [RFC4861] (as opposed to the new default values specified in 388 Section 4.1.1) or when the corresponding router ceases to send 389 RAs. 391 * A Router Lifetime of 0 has the special meaning of "this router 392 is not to be employed as a default router", and may be employed 393 only to advertise prefixes via SLAAC (but not as a default 394 router). As a result, PIO lifetimes are not capped when Router 395 Lifetime == 0. 397 * A PIO lifetime of 0xffffffff has the special meaning of 398 "infinity", which means that these prefixes (and their 399 corresponding addresses) should never time out. As a result, 400 PIO lifetimes are not capped when the PIO Valid Lifetime == 401 0xffffffff or the PIO Preferred Lifetime == 0xffffffff. 403 4.2. Honor Small PIO Valid Lifetimes 405 The entire item "e)" (pp. 19-20) from Section 5.5.3 of [RFC4862] is 406 replaced with the following text: 408 e) If the advertised prefix is equal to the prefix of an address 409 configured by stateless autoconfiguration in the list, the valid 410 lifetime and the preferred lifetime of the address should be 411 updated by processing the Valid Lifetime and the Preferred 412 Lifetime (respectively) in the received advertisement. 414 NOTE: "Processing" the Valid Lifetime and Preferred Lifetime 415 includes capping the received values as specified in Section 4.1.2 416 of this document. 418 RATIONALE: 420 * This change allows hosts to react to the information provided 421 by a router that has positive knowledge that a prefix has 422 become invalid. 424 * Attacks aiming at disabling an advertised prefix via a Valid 425 Lifetime of 0 are not really more harmful than other attacks 426 that can be performed via forged RA messages, such as those 427 aiming at completely disabling a next-hop router via an RA that 428 advertises a Router Lifetime of 0, or performing a Denial of 429 Service (DoS) attack by advertising illegitimate prefixes via 430 PIOs. In scenarios where RA-based attacks are of concern, 431 proper mitigations such as RA-Guard [RFC6105] [RFC7113] should 432 be implemented. 434 4.3. Interface Initialization 436 When an interface is initialized, it is paramount that network 437 configuration information is spread on the corresponding network 438 (particularly in scenarios where an interface has been re- 439 initialized, and the conveyed information has changed). Thus, this 440 document replaces the following text from Section 6.2.4 of [RFC4861]: 442 In such cases, the router MAY transmit up to 443 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using 444 the same rules as when an interface becomes an advertising 445 interface. 447 with: 449 In such cases, the router SHOULD transmit 450 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using 451 the same rules as when an interface becomes an advertising 452 interface. 454 RATIONALE: 456 * Use of stale information can lead to interoperability problems. 457 Therefore, it is paramount that new configuration information 458 propagates in a timelier manner to all hosts. 460 NOTE: 461 [I-D.ietf-v6ops-cpe-slaac-renum] specifies recommendations for CPE 462 routers to deprecate any stale network configuration information. 464 4.4. Conveying Information in Router Advertisement (RA) Messages 466 Intentionally omitting information in Router Advertisements may 467 prevent the propagation of such information. To the best of the 468 authors' knowledge, SLAAC routers always send all options in the 469 smallest possible number of packets, so this section simply more 470 clearly aligns the existing specifications with existing 471 implementations. 473 This document replaces the following text from Section 6.2.3 of 474 [RFC4861]: 476 A router MAY choose not to include some or all options when 477 sending unsolicited Router Advertisements. For example, if prefix 478 lifetimes are much longer than AdvDefaultLifetime, including them 479 every few advertisements may be sufficient. However, when 480 responding to a Router Solicitation or while sending the first few 481 initial unsolicited advertisements, a router SHOULD include all 482 options so that all information (e.g., prefixes) is propagated 483 quickly during system initialization. 485 If including all options causes the size of an advertisement to 486 exceed the link MTU, multiple advertisements can be sent, each 487 containing a subset of the options. 489 with: 491 When sending Router Advertisements, a router SHOULD include all 492 options. 494 If including all options causes the size of an advertisement to 495 exceed the link MTU, multiple advertisements can be sent, each 496 containing a subset of the options. In all cases, routers SHOULD 497 convey all information using the smallest possible number of 498 packets. 500 RATIONALE: 502 * Sending information in the smallest possible number of packets 503 was somewhat already implied from the original text in 504 [RFC4861], and in this respect the proposed update just adds 505 clarity. Including all options when sending RAs both leads to 506 simpler code (as opposed to dealing with special cases where 507 specific information is intentionally omitted), and also helps 508 hosts infer network configuration changes in a timelier manner. 509 Note that while [RFC4861] allowed some RAs to omit some 510 options, the authors of this document know of no implementation 511 of such behavior. Therefore, the proposed change simply 512 reflects existing practice. 514 4.5. Recovery from Stale Configuration Information without Explicit 515 Signaling 517 This section specifies an algorithm that allows hosts to infer when a 518 previously-advertised prefix has become stale, such that previously- 519 configured addresses are "phased-out" and the host can transition to 520 the newly-advertised prefixes in a timelier manner. Most of the 521 value of this algorithm is in being able to mitigate the problem 522 discussed in [I-D.ietf-v6ops-slaac-renum] at hosts themselves, 523 without relying on updates of local routers. 525 Hosts can normally infer when network configuration information has 526 changed. For example, if a SLAAC router (as identified by its link- 527 local address) has ceased to advertise a previously-advertised prefix 528 and has also started to advertise new prefixes via PIOs, this should 529 be considered an indication that network configuration information 530 has changed. Implementation of this kind of heuristic allows a 531 timelier reaction to network configuration changes even in scenarios 532 where there is no explicit signaling from the network -- thus 533 improving robustness. 535 The basic premise behind these algorithms is that, when a router 536 advertises new prefixes for address configuration (i.e., PIOs with 537 the "A" bit set), but fails to advertise the previously-advertised 538 prefixes, this is an indication that previously-advertised prefixes 539 have become stale. Therefore, if this was the only router 540 advertising the prefix, configured addresses for the stale prefixes 541 should be deprecated (such that they are not employed for new 542 communication instances), and they should eventually be removed (if 543 this condition persists). If other routers were advertising the same 544 prefix, the prefix should simply be dis-associated with the router 545 that ceased to advertise it, and the fate of the corresponding 546 addresses should depend on the routers that continue advertising the 547 prefix. 549 The algorithm specified in this section updates the state of 550 configured addresses upon receipt of an RA that, while carrying PIOs, 551 fails to advertise a previously-advertised prefix. Namely, such an 552 RA reduces the "Preferred Lifetime" of the corresponding addresses, 553 to cause such addresses to be quickly deprecated, while accommodating 554 the case where the advertising router might be sending SLAAC options 555 in multiple separate packets. Similarly, the "Valid Lifetime" of 556 such addresses is reduced, such that the addresses are invalidated in 557 a timelier manner, while still providing some leeway for the local 558 router to re-advertise the corresponding prefix. 560 Local information maintained for each prefix advertised by each 561 router is augmented with one variable named "LTA_LA" (Lifetime 562 Avoidance_Last Advertised), that records the last time a given prefix 563 has been advertised by a given router. 565 NOTE: 566 While not strictly required, we note that existing implementations 567 may already record the last time a prefix has been advertised by a 568 given router as a possible implementation approach to be able to 569 compute the remaining lifetime of an address. 571 Hosts are already expected to keep track of which router has 572 advertised which prefix in order to be able to properly select the 573 first-hop router in multiple-prefix networks [RFC8028] [RFC8504]. 574 Throughout this specification, each router is identified by its 575 link-local address. 577 This algorithm employs two configuration variables: 579 LTA_DEPRECATE: 580 A time value (in seconds) to set the "Preferred Lifetime" of 581 addresses corresponding to a given prefix, when a received RA 582 suggests that such addresses might have become stale. It defaults 583 to LTA_DEPRECATE_DEFAULT, which this document specifies as 5 584 seconds. This value is a rough estimate of the maximum amount of 585 time to send a "batch" of RA messages that advertise the complete 586 set of SLAAC information. [NOTE: We believe this variable could 587 be set to a value even smaller than this] 589 LTA_INVALID: 590 A time value (in seconds) to set the "Valid Lifetime" of addresses 591 corresponding to a given prefix, and the "Valid Lifetime" of a 592 prefix (for on-link determination), when a received RA suggests 593 that such addresses and prefix might have become stale. It 594 defaults to LTA_INVALID_DEFAULT, which this document specifies as 595 1800 seconds (which corresponds to the largest possible value for 596 MaxRtrAdvInterval [RFC4861]). [NOTE: We believe that it would be 597 possible to set this variable to smaller values, but just opted 598 for the most conservative setting]. 600 After normal processing of Router Advertisement messages, Router 601 Advertisements that contain at least one PIO MUST be processed as 602 follows: 604 o For each prefix prefix advertised by a PIO with the "A" flag set, 605 proceed as follows: 607 * LTA_LA = current_time() 609 o If the RA advertises at least one Global Unicast Prefix then, for 610 each Global Unicast prefix that had been previously advertised by 611 this router but that is not advertised by a PIO in the received 612 RA, proceed as follows: 614 * IF current_time() >= (LTA_LA + LTA_DEPRECATE) && 615 Preferred Lifetime > LTA_DEPRECATE && Valid Lifetime > 616 LTA_INVALID, then: 618 + IF this is the only router advertising this prefix, set the 619 "Preferred Lifetime" and the "Valid Lifetime" of IPv6 620 addresses corresponding to this prefix to LTA_DEPRECATE and 621 LTA_INVALID, respectively. Additionally, set the "Valid 622 Lifetime" associated with this prefix (for on-link 623 determination) to LTA_INVALID. 625 + ELSE IF this prefix has been advertised my multiple 626 neighboring routers, simply disassociate this prefix with 627 this particular router. This will cause the fate of this 628 prefix to depend on the other routers. 630 o If the RA advertises at least one Unique Local [RFC4193] prefix 631 then, for each Unique Local prefix that had been previously 632 advertised by this router but that is not advertised by a PIO in 633 the received RA, proceed as follows: 635 * IF current_time() >= (LTA_LA + LTA_DEPRECATE) && 636 Preferred Lifetime > LTA_DEPRECATE && Valid Lifetime > 637 LTA_INVALID, then: 639 + IF this is the only router advertising this prefix, set the 640 "Preferred Lifetime" and the "Valid Lifetime" of IPv6 641 addresses corresponding to this prefix to LTA_DEPRECATE and 642 LTA_INVALID, respectively. Additionally, set the "Valid 643 Lifetime" associated with this prefix (for on-link 644 determination) to LTA_INVALID. 646 + ELSE IF this prefix has been advertised my multiple 647 neighboring routers, simply disassociate this prefix with 648 this particular router. This will cause the fate of this 649 prefix to depend on the other routers. 651 NOTES: 653 o current_time() is a monotonically-increasing counter that is 654 incremented once per second, and is employed to measure time. 656 o The processing of RAs that do not contain any PIOs with the "A" 657 bit set remains unaffected. 659 o If the only prefix that has so far been advertised on the local 660 network is the prefix that has become stale, and there is no other 661 prefix being advertised, the traditional processing is unaffected 662 (the mechanism discussed in this document will *never* be 663 triggered because received RAs will not contain other PIOs with 664 the "A" bit set). The rationale here is that it is better to have 665 some address, than no address at all. 667 o Only RAs that advertise Global Unicast prefixes may deprecate 668 Global Unicast Addresses (GUAs), while only RAs that advertise 669 Unique Local prefixes may deprecate Unique Local Addresses (ULAs). 671 o The specified modification takes the conservative approach of 672 setting the "Preferred Lifetime" to LTA_DEPRECATE to allow for 673 SLAAC information to be conveyed in multiple RA messages (that can 674 be sent during a window of LTA_DEPRECATE seconds), and setting the 675 "Valid Lifetime" to LTA_INVALID (to accommodate for possible 676 packet loss, and transient problems). Once the addresses for this 677 prefix have been removed, associated routes incorporated by the 678 original RA messages SHOULD also be removed. 680 o In cases where this scenario has been triggered by a CPE router 681 crashing and rebooting, it would take hosts LTA_DEPRECATE seconds 682 to mark the corresponding addresses as "not preferred", and 683 LTA_INVALID to completely remove such addresses from the system -- 684 that is, 5 seconds and 600 seconds, respectively. 686 o The pseudo-code above checks that "Preferred Lifetime > 687 LTA_DEPRECATE && Valid Lifetime > LTA_INVALID" to prevent 688 subsequent RA packets that do not contain a specific PIO PIO from 689 resetting the corresponding Preferred Lifetime and Valid Lifetime 690 to LTA_DEPRECATE and LTA_INVALID (respectively) once they have 691 already been reduced by this algorithm. Otherwise, the Preferred 692 Lifetime and Valid Lifetime might never get decremented to 0 as 693 expected. 695 5. IANA Considerations 697 This document has no actions for IANA. 699 6. Implementation Status 701 [NOTE: This section is to be removed by the RFC-Editor before this 702 document is published as an RFC.] 704 This section summarizes the implementation status of the updates 705 proposed in this document. In some cases, they correspond to 706 variants of the mitigations proposed in this document (e.g., use of 707 reduced default lifetimes for PIOs, albeit using different values 708 than those recommended in this document). In such cases, we believe 709 these implementations signal the intent to deal with the problems 710 described in [I-D.ietf-v6ops-slaac-renum] while lacking any guidance 711 on the best possible approach to do it. 713 6.1. More Appropriate Lifetime Values 715 6.1.1. Router Configuration Variables 717 6.1.1.1. rad(8) 719 We have produced a patch for OpenBSD's rad(8) [rad] that employs the 720 default lifetimes recommended in this document, albeit it has not yet 721 been committed to the tree. The patch is available at: 722 . 724 6.1.1.2. radvd(8) 726 The radvd(8) daemon [radvd], normally employed by Linux-based router 727 implementations, currently employs different default lifetimes than 728 those recommended in [RFC4861]. radvd(8) employs the following 729 default values [radvd.conf]: 731 o Preferred Lifetime: 14400 seconds (4 hours) 733 o Valid Lifetime: 86400 seconds (1 day) 735 This is not following the specific recommendation in this document, 736 bu is already a deviation from the current standards. 738 6.1.2. Processing of PIO Lifetimes at Hosts 740 6.1.2.1. NetworkManager 742 NetworkManager [NetworkManager], user-space SLAAC implementation 743 employed by some Linux-based operating systems (such as Fedora or 744 Ubuntu), caps the lifetimes of the received PIOs as recommended in 745 this document. 747 6.1.2.2. slaacd(8) 749 slaacd(8) [slaacd], a user-space SLAAC implementation employed by 750 OpenBSD, caps the lifetimes of the received PIOs as recommended in 751 this document. 753 6.1.2.3. systemd-networkd 755 systemd-networkd [systemd], a user-space SLAAC implementation 756 employed by some Linux-based operating systems, caps the lifetimes of 757 the received PIOs as recommended in this document. 759 6.2. Honor Small PIO Valid Lifetimes 761 6.2.1. NetworkManager 763 NetworkManager [NetworkManager] processes RA messages with a Valid 764 Lifetime smaller than two hours as recommended in this document. 766 6.3. Conveying Information in Router Advertisement (RA) Messages 768 We know of no implementation that splits network configuration 769 information into multiple RA messages. 771 6.4. Recovery from Stale Configuration Information without Explicit 772 Signaling 774 6.4.1. dhcpcd(8) 776 The dhcpcd(8) daemon [dhcpcd], a user-space SLAAC implementation 777 employed by some Linux-based and BSD-derived operating systems, will 778 set the Preferred Lifetime of addresses corresponding to a given 779 prefix to 0 when a single RA from the router that previously 780 advertised the prefix fails to advertise the corresponding prefix. 781 However, it does not affect the corresponding Valid Lifetime. 782 Therefore, it can be considered a partial implementation of this 783 feature. 785 6.5. Other mitigations implemented in products 787 [FRITZ] is a Customer Edge Router that tries to deprecate stale 788 prefixes by advertising stale prefixes with a Preferred Lifetime of 789 0, and a Valid Lifetime of 2 hours (or less). There are two things 790 to note with respect to this implementation: 792 o Rather than recording prefixes on stable storage (as recommended 793 in [I-D.ietf-v6ops-cpe-slaac-renum]), this implementation checks 794 the source address of IPv6 packets, and assumes that usage of any 795 address that does not correspond to a prefix currently-advertised 796 by the Customer Edge Router is the result of stale network 797 configuration information. Hence, upon receipt of a packet that 798 employs a source address that does not correspond to a currently- 799 advertised prefix, this implementation will start advertising the 800 corresponding prefix with small lifetimes, with the intent of 801 deprecating it. 803 o Possibly as a result of item "e)" (pp. 19-20) from Section 5.5.3 804 of [RFC4862] (discussed in Section 4.2 of this document), upon 805 first occurrence of a stale prefix, this implementation will 806 employ a decreasing Valid Lifetime, starting from 2 hours (7200 807 seconds), as opposed to a Valid Lifetime of 0. 809 7. Security Considerations 811 When it comes to the algorithm in Section 4.5, an attacker could 812 impersonate the legitimate router and send an RA that does not 813 advertise legitimate prefixes being employed in the local network. 814 This cause the corresponding addresses to become deprecated. 815 However, the addresses would not become invalid since normal 816 unsolicited RA messages would refresh the "Preferred Lifetime" and 817 "Valid Lifetime" of such addresses. 819 However, an attacker that can impersonate a router could more easily 820 deprecate addresses by advertising the legitimate prefixes with the 821 "Preferred Lifetime" set to 0, or perform a plethora of other 822 possible of Denial of Service attacks based on forged RA messages. 823 Therefore, when attacks based on forged RA packets are a concern, 824 technologies such as RA-Guard [RFC6105] [RFC7113] should be deployed. 826 Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts may 827 help limit the duration of the effects of non-sustained attacks that 828 employ forged RAs with PIOs, since hosts would now recover in a 829 timelier manner. 831 8. Acknowledgments 833 The authors would like to thank (in alphabetical order) Mikael 834 Abrahamsson, Tore Anderson, Luis Balbinot, Brian Carpenter, Owen 835 DeLong, Gert Doering, Thomas Haller, Nick Hilliard, Bob Hinden, 836 Philip Homburg, Lee Howard, Christian Huitema, Erik Kline, Jen 837 Linkova, Albert Manfredi, Roy Marples, Florian Obser, Jordi Palet 838 Martinez, Michael Richardson, Hiroki Sato, Mark Smith, Hannes 839 Frederic Sowa, Tarko Tikan, Ole Troan, and Loganaden Velvindron, for 840 providing valuable comments on earlier versions of this document. 842 The algorithm specified in Section 4.5 is the result of mailing-list 843 discussions over previous versions of this document with Philip 844 Homburg. 846 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 847 for a discussion of these issues, which led to the publication of 848 [I-D.ietf-v6ops-slaac-renum], and eventually to this document. 850 Fernando would also like to thank Brian Carpenter who, over the 851 years, has answered many questions and provided valuable comments 852 that has benefited his protocol-related work. 854 The problem discussed in this document has been previously documented 855 by Jen Linkova in [I-D.linkova-6man-default-addr-selection-update], 856 and also in [RIPE-690]. 858 9. References 860 9.1. Normative References 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, 864 DOI 10.17487/RFC2119, March 1997, 865 . 867 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 868 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 869 . 871 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 872 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 873 DOI 10.17487/RFC4861, September 2007, 874 . 876 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 877 Address Autoconfiguration", RFC 4862, 878 DOI 10.17487/RFC4862, September 2007, 879 . 881 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 882 Hosts in a Multi-Prefix Network", RFC 8028, 883 DOI 10.17487/RFC8028, November 2016, 884 . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 891 "Updates to the Special-Purpose IP Address Registries", 892 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 893 . 895 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 896 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 897 January 2019, . 899 9.2. Informative References 901 [dhcpcd] Marples, R., "dhcpcd - a DHCP client", 902 . 904 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 905 (updated with solution)", SI6 Networks Blog, February 906 2016, . 909 [I-D.ietf-v6ops-cpe-slaac-renum] 910 Gont, F., Zorz, J., Patterson, R., and B. Volz, "Improving 911 the Reaction of Customer Edge Routers to Renumbering 912 Events", draft-ietf-v6ops-cpe-slaac-renum-02 (work in 913 progress), May 2020. 915 [I-D.ietf-v6ops-slaac-renum] 916 Gont, F., Zorz, J., and R. Patterson, "Reaction of 917 Stateless Address Autoconfiguration (SLAAC) to Flash- 918 Renumbering Events", draft-ietf-v6ops-slaac-renum-02 (work 919 in progress), May 2020. 921 [I-D.linkova-6man-default-addr-selection-update] 922 Linkova, J., "Default Address Selection and Subnet 923 Renumbering", draft-linkova-6man-default-addr-selection- 924 update-00 (work in progress), March 2017. 926 [NetworkManager] 927 NetworkManager, "NetworkManager web site", 928 . 930 [rad] Obser, F., "OpenBSD Router Advertisement Daemon - rad(8)", 931 . 933 [radvd] Hawkins, R. and R. Johnson, "Linux IPv6 Router 934 Advertisement Daemon (radvd)", 935 . 937 [radvd.conf] 938 Hawkins, R. and R. Johnson, "radvd.conf - configuration 939 file of the router advertisement daemon", 940 . 943 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 944 Defeating Denial of Service Attacks which employ IP Source 945 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 946 May 2000, . 948 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 949 DOI 10.17487/RFC5927, July 2010, 950 . 952 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 953 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 954 DOI 10.17487/RFC6105, February 2011, 955 . 957 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 958 "Default Address Selection for Internet Protocol Version 6 959 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 960 . 962 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 963 Advertisement Guard (RA-Guard)", RFC 7113, 964 DOI 10.17487/RFC7113, February 2014, 965 . 967 [RIPE-690] 968 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 969 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 970 Meynell, K., and L. Howard, "Best Current Operational 971 Practice for Operators: IPv6 prefix assignment for end- 972 users - persistent vs non-persistent, and what size to 973 choose", RIPE 690, October 2017, 974 . 976 [slaacd] Obser, F., "OpenBSD SLAAC Daemon - slaacd(8)", 977 . 979 [systemd] systemd, "systemd web site", . 981 Appendix A. Analysis of Some Suggested Workarounds 983 [This section is to be removed before publication of this document as 984 an RFC]. 986 During the discussion of this document, some alternative workarounds 987 were suggested on the 6man mailing-list. The following subsections 988 analyze these suggested workarounds, in the hopes of avoiding 989 rehashing the same discussions. 991 A.1. On a Possible Reaction to ICMPv6 Error Messages 993 It has been suggested that if configured addresses become stale, a 994 CPE enforcing ingress/egress filtering (BCP38) ([RFC2827]) could send 995 ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed 996 ingress/egress policy) error messages to the sending node, and that, 997 upon receipt of such error messages, the sending node could perform 998 heuristics that might help to mitigate the problem discussed in this 999 document. 1001 The aforementioned proposal has a number of drawbacks and 1002 limitations: 1004 o It assumes that the CPE routers enforce ingress/egress filtering 1005 [RFC2827]. While this is desirable behaviour, it cannot be relied 1006 upon. 1008 o It assumes that if the CPE enforces ingress/egress filtering, the 1009 CPE will signal the packet drops to the sending node with ICMPv6 1010 Type 1 (Destination Unreachable) Code 5 (Source address failed 1011 ingress/egress policy) error messages. While this may be 1012 desirable, [RFC2827] does not suggest signaling the packet drops 1013 with ICMPv6 error messages, let alone the use of specific error 1014 messages (such as Type 1 Code 5) as suggested. 1016 o ICMPv6 Type 1 Code 5 could be interpreted as the employed address 1017 being stale, but also as a selected route being inappropriate/ 1018 suboptimal. If the later, deprecating addresses or invalidating 1019 addresses upon receipt of these error messages would be 1020 inappropriate. 1022 o Reacting to these error messages would create a new attack vector 1023 that could be exploited from remote networks. This is of 1024 particular concern since ICMP-based attacks do not even require 1025 that the Source Address of the attack packets be spoofed 1026 [RFC5927]. 1028 A.2. On a Possible Improvement to Source Address Selection 1030 [RFC6724] specifies source address selection (SAS) for IPv6. 1031 Conceptually, it sorts the candidate set of source addresses for a 1032 given destination, based on a number of pair-wise comparison rules 1033 that must be successively applied until there is a "winning" address. 1035 An implementation might improve source address selection, and prefer 1036 the most-recently advertised information. In order to incorporate 1037 the "freshness" of information in source address selection, an 1038 implementation would be updated as follows: 1040 o The node is assumed to maintain a timer/counter that is updated at 1041 least once per second. For example, the time(2) function from 1042 unix-like systems could be employed for this purpose. 1044 o The local information associated with each prefix advertised via 1045 RAs on the local network is augmented with a "LastAdvertised" 1046 timestamp value. Whenever an RA with a PIO with the "A" bit set 1047 for such prefix is received, the "LastAdvertised" timestamp is 1048 updated with the current value of the timer/counter. 1050 o [RFC6724] is updated such that this rule is incorporated: 1052 Rule 7.5: Prefer fresh information If one of the two source 1053 addresses corresponds to a prefix that has been more recently 1054 advertised, say LastAdvertised(SA) > LastAdvertised(SA), then 1055 prefer that address (SA in our case). 1057 A clear benefit of this approach is that a host will normally prefer 1058 "fresh" addresses over possibly stale addresses. 1060 However, there are a number of drawbacks associated with this 1061 approach: 1063 o In scenarios where multiple prefixes are being advertised on the 1064 same LAN segment, the new SAS rule is *guaranteed* to result in 1065 non-deterministic behaviour, with hosts frequently changing the 1066 default source address. This is certainly not desirable from a 1067 troubleshooting perspective. 1069 o Since the rule must be incorporated before "Rule 8: Use longest 1070 matching prefix" from [RFC6724], it may lead to suboptimal paths. 1072 o This new rule may help to improve the selection of a source 1073 address, but it does not help with the housekeeping (garbage 1074 collection) of configured information: 1076 * If the stale prefix is re-used in another network, nodes 1077 employing stale addresses and routes for this prefix will be 1078 unable to communicate with the new "owner" of the prefix, since 1079 the stale prefix will most likely be considered "on-link". 1081 * Given that the currently recommended default value for the 1082 "Valid Lifetime" of PIOs is 2592000 seconds (30 days), it would 1083 take too long for hosts to remove the configured addresses and 1084 routes for the stale prefix. While the proposed update in 1085 Section 4.1 of this document would mitigate this problem, the 1086 lifetimes advertised by the local SLAAC router are not under 1087 the control of hosts. 1089 As a result, updating IPv6 source address selection does not relieve 1090 nodes from improving their SLAAC implementations as specified in 1091 Section 4, if at all desirable. On the other hand, the algorithm 1092 specified in Section 4.5 would result in Rule 3 of [RFC6724] 1093 employing fresh addresses, without leading to non-deterministic 1094 behaviour. 1096 Authors' Addresses 1098 Fernando Gont 1099 SI6 Networks 1100 Segurola y Habana 4310, 7mo Piso 1101 Villa Devoto, Ciudad Autonoma de Buenos Aires 1102 Argentina 1104 Email: fgont@si6networks.com 1105 URI: https://www.si6networks.com 1107 Jan Zorz 1108 Go6 Institute 1109 Frankovo naselje 165 1110 Skofja Loka 4220 1111 Slovenia 1113 Email: jan@go6.si 1114 URI: https://www.go6.si 1116 Richard Patterson 1117 Sky UK 1119 Email: richard.patterson@sky.uk