idnits 2.17.1 draft-gont-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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 18, 2019) is 1891 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) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 / UTN-FRH 4 Updates: 4861, 4862 (if approved) J. Zorz 5 Intended status: Standards Track February 18, 2019 6 Expires: August 22, 2019 8 Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering 9 Events 10 draft-gont-6man-slaac-renum-01 12 Abstract 14 In scenarios where network configuration information related to IPv6 15 prefixes becomes invalid without any explicit signaling of that 16 condition (such as when a CPE crashes and reboots without knowledge 17 of the previously-employed prefixes), nodes on the local network will 18 continue using stale prefixes for an unacceptably long period of 19 time, thus resulting in connectivity problems. This document 20 analyzes these problem scenarios, and proposes workarounds to improve 21 network robustness. This document updates RFC4861 and RFC4862 to 22 allow for a more robust reaction to network configuration changes. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 22, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Analysis of the Problem . . . . . . . . . . . . . . . . . . . 4 61 3.1. Inappropriate Default Timer Values in IPv6 Stateless 62 Address Autoconfiguration (SLAAC) . . . . . . . . . . . . 4 63 3.2. Inability of SLAAC Hosts to Recover from Stale Network 64 Configuration Information . . . . . . . . . . . . . . . . 5 65 3.3. Lack of Explicit Signaling about Stale Information . . . 6 66 3.4. Under-specified Interaction Between DHCPv6-PD and SLAAC . 6 67 4. Use of Dynamic Prefixes . . . . . . . . . . . . . . . . . . . 7 68 5. Possible workarounds . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Improvements to SLAAC . . . . . . . . . . . . . . . . . . 8 70 5.1.1. Default Timer Values . . . . . . . . . . . . . . . . 8 71 5.1.2. Signaling Stale Configuration Information . . . . . . 9 72 5.1.3. Recovery from Stale Configuration Information . . . . 10 73 5.2. Interaction Between DHCPv6-PD and SLAAC . . . . . . . . . 13 74 5.3. Improved CPE behavior . . . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Appendix A. Flowchart for Host Processing of RAs . . . . . . . . 17 82 Appendix B. Sample Timeline for Host Processing of RAs . . . . . 18 83 Appendix C. Analysis of Some Suggested Workarounds . . . . . . . 19 84 C.1. On a Possible Reaction to ICMPv6 Error Messages . . . . . 20 85 C.2. On a Possible Improvement to Source Address Selection . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 88 1. Introduction 90 In scenarios where network configuration information related to IPv6 91 prefixes becomes invalid without any explicit signaling of that 92 condition, nodes on the local network will continue using stale 93 prefixes for an unacceptably long period of time, thus resulting in 94 connectivity problems. 96 There are a number of scenarios where this problem may arise. For 97 example, the most common deployment scenario for IPv6 in home 98 networks is that in which a CPE router employs DHCPv6 Prefix 99 Delegation (DHCPv6-PD) [RFC8415] to request a prefix from the 100 Internet Service Provider (ISP), and a prefix belonging to the leased 101 prefix is advertised on the LAN-side of the CPE via Stateless Address 102 Autoconfiguration (SLAAC) [RFC4862]. In scenarios where the CPE 103 router crashes and reboots, the CPE may be leased (via DHCPv6-PD) a 104 different prefix from the one previously leased, and will therefore 105 advertise (via SLAAC) the new prefix on the LAN side. Hosts will 106 normally configure an address for the new prefix, but will normally 107 retain and actively employ the previously-configured addresses, since 108 their associated Preferred Lifetime and Valid Lifetime allow them to 109 do so. 111 Lacking any explicit signaling to "obsolete" the previously- 112 configured addresses (for the now invalid/stale prefix), hosts may 113 continue employing the previously-configured addresses which will 114 typically result in packets being blackholed -- whether because of 115 egress-filtering by the CPE or ISP, or because responses to such 116 packets will be discarded or routed elsewhere. 118 The default values for the "Valid Lifetime" and "Preferred Lifetime" 119 of Prefix Information Options (PIOs), as specified in [RFC4861], are: 121 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 123 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 125 This means that in the aforementioned scenarios, the stale addresses 126 would be retained for unacceptably long period of time, thus leading 127 to interoperability problems, instead of nodes transitioning to the 128 newly-advertised prefix(es) in a timelier manner. 130 Some devices have implemented mechanisms to address this problem, 131 such as sending RAs to invalidate the apparently stale prefixes when 132 the device receive any packets employing a source address from a 133 prefix not being advertised for address configuration [FRITZ]. 134 However, this may introduce other interoperability problems, 135 particularly in multihomed scenarios. This is yet another indication 136 that advice in this area is warranted. 138 This unresponsiveness is caused by the both the inability of the 139 network to deprecate stale information, as well as by the inability 140 of hosts to react to network configuration changes in a timelier 141 manner. Clearly, it is desirable that behave in a way that hosts are 142 explicitly notified when configuration information has become stale. 143 However, for robustness reasons it is paramount for hosts to be able 144 to recover from stale configuration information even if somehow the 145 network is unable to explictly notify hosts about such condition. 147 Section 3 analysis this problem in more detail. Section 5 proposes 148 workarounds to improve network robustness. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 3. Analysis of the Problem 158 As noted in Section 1, the problem discussed in this document is 159 associated with sub-optimal behaviour and policies of different 160 entities. Each of the following sections analyze each of them in 161 detail. 163 3.1. Inappropriate Default Timer Values in IPv6 Stateless Address 164 Autoconfiguration (SLAAC) 166 Many protocols, from different layers, normally employ timers. The 167 general logic is as follows: 169 o A timer is set with a value that, under normal conditions, the 170 timer does *not* go off. 172 o Whenever a fault condition arises, the timer goes off, and the 173 protocol can perform fault recovery 175 One common example for the use of timers is when implementing 176 reliability mechanisms where a packet is transmitted, and unless a 177 response is received, a retransmission timer will go off to trigger 178 retransmission of the original packet. 180 For obvious reasons, the whole point of using timers is that in 181 problematic scenarios, they will go off, and trigger some recovery 182 action. 184 However, IPv6 SLAAC employs, for PIOs, these default values: 186 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 188 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 190 Under normal network conditions, these timers will be reset/refreshed 191 to the default values. However, under problematic circumstances such 192 as where the corresponding network information has become stale 193 without any explicit signal from the network (as described in 194 Section 1), it will take a host 7 days (one week) to un-prefer the 195 corresponding addresses, and 30 days (one month) to eventually remove 196 any addresses configured for the stale prefix. 198 Clearly, for any practical purposes, employing such long default 199 values is equivalent of not using any timers at all, since taking 7 200 days or 30 days (respectively) to recover from a network problem is 201 simply unacceptable. 203 The default values for these timers should be such that, under normal 204 circumstances (including some packet loss), the timers will be 205 refreshed/rest, but in the presence of network faults (such as 206 network configuration information becoming stale without explicit 207 signaling), the timers go off and trigger some fault recovering 208 action (such as un-preferring the corresponding addresses and 209 subsequently removing them). 211 In the context of [RFC8028], where it is clear that use of addresses 212 configured for a given prefix is mostly tied to using the router that 213 advertised the prefix as a next hop, one could tell that neither the 214 "Preferred Lifetime" or the "Valid Lifetime" of a PIO should ever be 215 longer than the default value for the "Router Lifetime" of Router 216 Advertisement packets. This means that since [RFC4861] specifies the 217 default value for the "Router Lifetime" as: AdvDefaultLifetime: 3 * 218 MaxRtrAdvInterval, and MaxRtrAdvInterval defaults to 600 seconds, the 219 values employed for the "Preferred Lifetime" (AdvPreferredLifetime) 220 and "Valid Lifetime" (AdvValidLifetime) of PIOs should never be 221 larger than 1800 seconds (30 minutes). Capping the lifetimes in PIOs 222 as suggested would not eliminate the problem discussed in this 223 document, but certainly reduces the amount of time it takes for hosts 224 to converge to updated network configuration information. 226 Section 5.1.1 of this document updates the SLAAC specification to 227 employ more appropriate timer values. 229 3.2. Inability of SLAAC Hosts to Recover from Stale Network 230 Configuration Information 232 In the absence of explicit signalling from SLAAC routers (such as 233 sending PIOs with a "Valid Lifetime" set to 0), SLAAC hosts fail to 234 recover from stale configuration information in a timely manner. 235 This is exacerbated by the inappropriate timers employed for the 236 lifetime of PIOs, as discussed in Section 3.1. 238 It is possible to heuristically infer that network configuration 239 information has changed. For example, if the same SLAAC router (as 240 identified by its link-local address) is advertising new prefixes via 241 PIOs, but has ceased to advertise the previously-advertised prefixes, 242 this should be considered an indication that network configuration 243 information has changed. Implementing this kind of heuristics would 244 allow a timelier reaction to network configuration changes even in 245 scenarios where there is no explicit signaling from the network, thus 246 improving robustness. 248 Section 5.1.3 of this document specifies a local policy that SLAAC 249 hosts can implement to recover from stale prefixes. 251 3.3. Lack of Explicit Signaling about Stale Information 253 Whenever prefix information has changed, a SLAAC router should not 254 only advertise the new information, but should also advertise the 255 stale information with appropriate lifetime values (both "Preferred 256 Lifetime" and "Valid Lifetime" set to 0), such that there is explicit 257 signaling to SLAAC hosts to remove the stale information (including 258 configured addresses and routes). 260 In order to cope with the possibility of a SLAAC router crashing and 261 rebooting without any state of the previously-advertised prefixes, a 262 SLAAC router should record on stable storage the information of which 263 prefixes were being advertised on which interfaces, such that upon 264 reboots, such prefixes may be advertised with appropriate lifetimes 265 (both "Preferred Lifetime" and "Valid Lifetime" set to 0) to cause 266 hosts to remove any configuration information derived from previous 267 announcements of such prefixes. 269 Explicit signaling of network configuration changes would eliminate 270 the problem discussed in this document. However, since it is 271 impossible for a host to know whether such explicit signals will be 272 received, they are not relieved from inferring changes in network 273 configuration information, as discussed in Section 3.2. 275 Section 5.1.2 updates the SLAAC specification such that routers 276 explicitly signal stale configuration to SLAAC hosts. Section 5.3 277 specifies the corresponding requirements for CPE routers. 279 3.4. Under-specified Interaction Between DHCPv6-PD and SLAAC 281 While DHCPv6-PD is normally employed along with SLAAC, the 282 interaction between the two protocols is largely unspecified. Not 283 unusually, the two protocols are specified in two different software 284 components with the interface between the two implemented by some 285 sort of script that takes feeds the SLAAC implementation with values 286 learned from DHCPv6-PD. 288 Quite frequently, the prefix lease time is fed as a constant value to 289 the SLAAC router implementation, meaning that eventually the prefix 290 lifetime advertised on the LAN side will span *past* the DHCPv6-PD 291 lease time. This is clearly incorrect, since the SLAAC router 292 implementation would be allowing the use of such prefixes for a 293 longer time than it has been granted usage of those prefixes via 294 DHCPv6-PD. The lifetime values employed for the "Preferred Lifetime" 295 (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) should 296 never be larger than the remaining lease time for the corresponding 297 prefix (as learned via DHCPv6-PD). 299 Section 5.2 of this document specifies this aspect of the interaction 300 between DHCPv6-PD and SLAAC. 302 4. Use of Dynamic Prefixes 304 The problem discussed in this document would be avoided if DHCPv6-PD 305 would lease "stable" prefixes. However, a recent survey [UK-NOF] 306 indicates that 37% of the responding ISPs employ dynamic prefixes. 307 That is, dynamic IPv6 prefixes are an operational reality. 309 Deployment reality aside, there are a number of possible issues 310 associated with stable prefixes: 312 o Provisioning systems may be unable to deliver stable IPv6 313 prefixes. 315 o While there is a range of information that may be employed to 316 correlate network activity [RFC7721], the use of stable prefixes 317 clearly simplifies network activity correlation, and may 318 essentially render features such as "temporary addresses" 319 [RFC4941] irrelevant. 321 o Applicable legislation may require the ISP to deliver dynamic IPv6 322 prefixes *by default* (see e.g. [GERMAN-DP]). 324 The authors of this document understand that, for a number of reasons 325 (such as the ones stated above), IPv6 deployments may employ dynamic 326 prefixes, or there might be scenarios in which the dynamics of a 327 network are such that the network exhibits the behaviour of dynamic 328 prefixes. Rather than try to preclude how operators may run their 329 networks, this document aims at improving network robustness in the 330 deployed Internet. 332 5. Possible workarounds 334 The following subsections discuss possible workarounds for the 335 aforementioned problem. Section 5.1 specifies modifications to SLAAC 336 which include the use of more appropriate lifetime values and a 337 mechanism for hosts to infer when a previously-advertised prefix has 338 become stale. This modification leads to more robust behaviour even 339 for existing deployments. 341 Section 5.3 specifies the interaction between DHCPv6-PD and SLAAC, 342 such that devices such as CPEs may be in a better position to convey 343 current network information to hosts on the LAN-side. For obvious 344 reasons (legacy CPEs, etc.), this improved behaviour cannot be relied 345 upon for mitigating the problem described in Section 1. However, it 346 does contribute to more robust IPv6 networks. 348 Finally, Section 4 analyzes the trade-offs of employing stable vs. 349 dynamic network prefixes. 351 5.1. Improvements to SLAAC 353 5.1.1. Default Timer Values 355 5.1.1.1. Router Configuration Variables 357 The "default" value for the router configuration variable 358 "MaxRtrAdvInterval" (Section 6.2.1 of [RFC4861] is changed to 300 359 seconds (5 minutes). 361 As a result of this change, the default values for two other 362 configuration variables are indirectly modified (since they are 363 specified in relation with MaxRtrAdvInterval): 365 o MinRtrAdvInterval: 0.33 * MaxRtrAdvInterval = 99 seconds 367 o AdvDefaultLifetime: 3 * MaxRtrAdvInterval = 900 seconds (15 368 minutes) 370 Additionally, the default value for the "lifetime" parameters in PIOs 371 is updated as follows: 373 AdvValidLifetime: AdvDefaultLifetime (which according to this 374 specification defaults to 900 seconds / 15 minutes) 376 AdvPreferredLifetime: 0.50 * AdvValidLifetime (which would result 377 in 450 seconds, that is, 7.5 minutes) 379 The motivation of this update is as follows: 381 o Link the lifetimes associated with prefixes to the lifetime of the 382 router advertising the prefixes, since use of advertised prefixes 383 is closely tied to the router that has advertised them (as per 384 [RFC8028]). 386 o Lacking RAs that refresh information, addresses configured for 387 such prefixes would become un-preferred, and thus Rule 3 of 388 [RFC6724] would cause other configured addresses (if available) to 389 be preferred and used instead. 391 o Limit the amount of time that a stale prefix needs to be 392 advertised with a lifetime od "0" on the local network (see 393 Section 12 of [RFC4861]). 395 o Employ default router lifetimes that improve the ability of hosts 396 to recover from fault scenarios. 398 5.1.1.2. Processing of PIO Lifetimes at Hosts 400 Hosts should cap the "Valid Lifetime" and "Preferred Lifetime" of 401 PIOs to the "Router Lifetime" value in the received Router 402 Advertisement. That is, if the "Valid Lifetime" or "Preferred 403 Lifetime" of a PIO is larger than the "Router Lifetime" value of the 404 Router Advertisement carrying the PIO, the corresponding value should 405 be capped to that of the "Router Lifetime" value of the received RA. 407 The motivation for this update is as follows: 409 o Limits the amount of time a host is required to maintain possibly 410 stale information. 412 5.1.2. Signaling Stale Configuration Information 414 In order to phase-out stale configuration information, the SLAAC 415 specification is updated as follows: 417 o A router sending RAs that advertise dynamically-learned prefixes 418 (e.g. via DHCPv6-PD) on an interface MUST record, on stable 419 storage, the list of prefixes being advertised on each network 420 segment. 422 o Upon changes to the advertised prefixes, and after bootstrapping, 423 the router advertising prefix information via SLAAC should proceed 424 as follows: 426 * Any prefixes that were previously advertised via SLAAC, but 427 that are not currently intended for address configuration, MUST 428 be advertised with a PIO option with the "A" bit set to 1 and 429 the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 431 * Any prefixes that were previously advertised via SLAAC as "on- 432 link", but that are not currently not considered "on-link", 433 MUST be advertised with a PIO option with the "L" bit set to 1 434 and the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 436 * If both of the previous conditions are met (a prefix was 437 previously advertised with both the "A" and "L" bits set, but 438 is currently *not* intended for address configuration and is 439 *not* considered on-link), the prefix MUST be advertised with a 440 PIO option with both the "A" and "L" bits set to 1 and the 441 "Valid Lifetime" and a "Preferred Lifetime" set to 0. That is. 442 the advertisements of the previous two steps can be coalesced 443 into a single one with both the "A" and "L" bits set. 445 * The aforementioned advertisement SHOULD be performed for at 446 least the "Valid Lifetime" previously employed for such prefix. 448 Additionally, this document replaces the following text from 449 Section 6.2.4 of [RFC4861]: 451 In such cases, the router MAY transmit up to 452 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using 453 the same rules as when an interface becomes an advertising 454 interface. 456 to: 458 In such cases, the router MUST transmit 459 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using 460 the same rules as when an interface becomes an advertising 461 interface. 463 The rationale for this update is: 465 o Use of stale information can lead to interoperability problems. 466 Therefore, it is paramount that new configuration information is 467 delivered in a timely manner to all hosts. 469 5.1.3. Recovery from Stale Configuration Information 471 The goal of the mechanism specified in this section is to allow hosts 472 to infer when a previously-advertised prefix has become stale, such 473 that previously-configured addresses are "phased-out" and the host 474 can transition to the newly-advertised prefixes in a timelier manner. 476 The basic premise behind the mechanism specified in this section is 477 that, when a router advertises new prefixes for address configuration 478 (PIO with the "A" bit set), but fails to advertise the previously- 479 advertised prefixes, this is an indication that the previously- 480 advertised prefixes have become stale. Therefore, configured 481 addresses for the stale prefixes are initially "un-preferred" (such 482 that they are not employed for new communication instances), and they 483 are subsequently removed (if this condition persists). 485 Local information maintained for each prefix advertised by each 486 router is augmented with one boolean flag named "LTA" (Lifetime 487 Avoidance) that defaults to "FALSE". Note: hosts are already 488 expected to keep track of which router has advertised which prefix in 489 order to be able to properly select the first-hop router in multiple- 490 prefix networks [RFC8028] [RFC8504]. 492 After normal processing of Router Advertisement messages, Router 493 Advertisements that contain at least one PIO MUST be processed as 494 follows: 496 o The LTA flag for each prefix advertised in the current Router 497 Advertisement should be set to "FALSE". 499 o For each prefix that had been previously advertised by this router 500 but that does not have a corresponding PIO with the "A" flag set 501 in the received RA, proceed as follows: 503 * IF the LTA flag is "TRUE", then: 505 + IF there is any address configured for this prefix with a 506 "Preferred Lifetime" larger than 0, set its "Preferred 507 Lifetime" to 0, and the LTA flag of this prefix to "FALSE". 509 + ELSE (all addresses for this prefix have a "Preferred 510 Lifetime" of 0), set the "Valid Lifetime" of all addresses 511 configured for this prefix to 0, and the LTA flag of this 512 prefix to "FALSE". This will cause removal of all addresses 513 for this prefix. Additionally, if the corresponding prefix 514 had been advertised as on-link ("L"=1) by this router, 515 remove any routes to this prefix associated with the network 516 interface card on which the RA packet was received. 518 * ELSE (the LTA flag is "FALSE"): 520 + Set the LTA flag of the corresponding prefix to "TRUE". 522 Appendix B illustrates the packet exchange and operation of the 523 algorithm for a typical scenario. Appendix A provides a flowchart 524 for this algorithm. 526 NOTES: 528 o The aforementioned processing assumes that while network 529 configuration information might be split into multiple RAs, PIOs 530 will be spread among *at most* two RAs. This assumption avoids 531 the use of any timers for this specific purpose. 533 o If the only prefix that has so far been advertised on the local 534 network is the prefix that has become stale, and there is no new 535 prefix being advertised, the traditional processing is unaffected 536 (the mechanism discussed in this document will *never* be 537 triggered because no packets with PIOs with the "A" flag will be 538 received). The logic here is that it is better to have some 539 address, than no address at all. 541 o The processing of RAs that do not contain any PIOs with the "A" 542 bit set remains unaffected. 544 o The specified modification takes the conservative approach of 545 first setting the "Preferred Lifetime" to 0 (such that addresses 546 become non-preferred), and subsequently setting the "Valid 547 Lifetime" to 0 (such as the addresses are completely removed). 548 Once the addresses for this prefix have been removed, routes to 549 this prefix associated with the network interface on which the RA 550 packets were received are also removed. 552 o In cases where this scenario has been triggered by a CPE router 553 crashing and rebooting, it would take hosts less than one minute 554 to mark the corresponding addresses as "not preferred", and less 555 than five minutes to completely remove such addresses from the 556 system. Section 6.2.4 of [RFC4861] specifies that when an 557 interface becomes an advertising interface, the first few 558 unsolicited RAs (up to MAX_INITIAL_RTR_ADVERTISEMENTS, specified 559 as 3) will be sent at intervals of at most 560 MAX_INITIAL_RTR_ADVERT_INTERVAL (specified as 16 seconds). This 561 means that, in the worst-case scenario, it would take hosts 32 562 seconds to mark stale addresses as "not preferred". The fourth 563 unsolicited RA will be sent after a random amount of time between 564 MinRtrAdvInterval (default: 0.33 * MaxRtrAdvInterval) and 565 MaxRtrAdvInterval (default: 600 seconds) has elapsed, thus meaning 566 that the stale addresses would be removed between 3.3 and 10 567 minutes of being marked as "not preferred". 569 5.2. Interaction Between DHCPv6-PD and SLAAC 571 The "Preferred Lifetime" and "Valid Lifetime" of PIOs corresponding 572 to prefixes learned via DHCPv6-PD MUST NOT span past the lease time 573 of the DHCPv6-PD prefixes. This means that the advertised "Preferred 574 Lifetime" and "Valid Lifetime" MUST be dynamically adjusted such that 575 the advertised lifetimes never span past the lease time of the 576 prefixes delegated via DHCPv6-PD. 578 This is in line with these existing requirements from other 579 specifications, which we reference here for clarity: 581 o [RFC8415] specifies, in Section 6.3, that "if the delegated prefix 582 or a prefix derived from it is advertised for stateless address 583 autoconfiguration [RFC4862], the advertised preferred and valid 584 lifetimes MUST NOT exceed the corresponding remaining lifetimes of 585 the delegated prefix." 587 5.3. Improved CPE behavior 589 This section specifies and clarifies requirements for CPE routers 590 (particularly when they advertise prefixes learned via DHCPv6-PD) 591 that can help mitigate the problem discussed in Section 1. This 592 improves the situation for hosts that do not implement the 593 modification specified in Section 5.1 but would obviously make 594 robustness dependent on the CPE (on which the user or ISP may have no 595 control), as opposed to the host itself. This mechanism is mostly 596 orthogonal to the improved host behaviour specified in Section 5.1. 598 The updated behaviour is as follows: 600 o The CPE MUST signal stale configuration information as specified 601 in Section 5.1.2 603 o The CPE MUST implement the DHCPv6-PD/SLAAC interface specified in 604 Section 5.2. 606 The aforementioned improved behaviour assumes compliance with the 607 following existing requirements from other specifications, which we 608 reference here for clarity: 610 o [RFC7084] specifies (requirement LE-13, in Section 4.3) that when 611 the delegated prefix changes (i.e., the current prefix is replaced 612 with a new prefix without any overlapping time period), "the IPv6 613 CE router MUST immediately advertise the old prefix with a 614 Preferred Lifetime of zero and a Valid Lifetime of either a) zero 615 or b) the lower of the current Valid Lifetime and two hours (which 616 must be decremented in real time) in a Router Advertisement 617 message as described in Section 5.5.3, (e) of [RFC4862]" 619 6. IANA Considerations 621 This document has no actions for IANA. 623 7. Security Considerations 625 This document discusses a a problem that may arise in scenarios where 626 dynamic IPv6 prefixes are employed, and proposes workarounds that 627 enable such usage while avoiding interoperability problems. The 628 security and privacy implications of IPv6 addresses are discussed in 629 [RFC7721]. 631 An attacker that could impersonate a router could forge multiple RA 632 packets that contain PIOs of prefixes that are currently not 633 advertised on the local network, to trigger the mechanism specified 634 in this document to cause addresses currently configured for the 635 legitimate prefixes to be removed. However, an attacker that can 636 impersonate a router could more easily achieve the same goal by 637 advertising the legitimate prefixes with both the "Preferred 638 Lifetime" and "Valid Lifetime" set to 0. 640 Capping the "Valid Lifetime" and "Preferred Lifetime" at hosts limit 641 the length of the effects of a non-sustained attack, since hosts 642 would now be able to recover in a timelier manner. 644 Attacks based on forged RA packed can be mitigated with technologies 645 such as RA-Guard [RFC6105] [RFC7113]. 647 8. Acknowledgments 649 The authors would lie to thank (in alphabetical order) Mikael 650 Abrahamsson, Luis Balbinot, Brian Carpenter, Gert Doering, Nick 651 Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Albert 652 Manfredi, Jordi Palet Martinez, Richard Patterson, Michael 653 Richardson, Mark Smith, Tarko Tikan, and Ole Troan, for providing 654 valuable comments on earlier versions of this document. 656 Fernando would like to thank Alejandro D'Egidio and Sander Steffann 657 for a discussion of these issues. 659 The problem discussed in this document has been previously documented 660 in [RIPE-690]. 662 9. References 664 9.1. Normative References 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, 668 DOI 10.17487/RFC2119, March 1997, 669 . 671 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 672 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 673 DOI 10.17487/RFC4861, September 2007, 674 . 676 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 677 Address Autoconfiguration", RFC 4862, 678 DOI 10.17487/RFC4862, September 2007, 679 . 681 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 682 Extensions for Stateless Address Autoconfiguration in 683 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 684 . 686 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 687 Hosts in a Multi-Prefix Network", RFC 8028, 688 DOI 10.17487/RFC8028, November 2016, 689 . 691 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 692 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 693 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 694 RFC 8415, DOI 10.17487/RFC8415, November 2018, 695 . 697 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 698 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 699 January 2019, . 701 9.2. Informative References 703 [FRITZ] Gont, F., "Quiz: Weird IPv6 Traffic on the Local Network 704 (updated with solution)", SI6 Networks Blog, February 705 2016, . 708 [GERMAN-DP] 709 BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im 710 Privatkundengeschaft und Herstellere", Entschliessung der 711 84. Konferenz der Datenschutzbeauftragten des Bundes und 712 der Lander am 7./8. November 2012 in Frankfurt (Oder), 713 November 2012, 714 . 718 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 719 Defeating Denial of Service Attacks which employ IP Source 720 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 721 May 2000, . 723 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, 724 DOI 10.17487/RFC5927, July 2010, 725 . 727 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 728 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 729 DOI 10.17487/RFC6105, February 2011, 730 . 732 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 733 "Default Address Selection for Internet Protocol Version 6 734 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 735 . 737 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 738 Requirements for IPv6 Customer Edge Routers", RFC 7084, 739 DOI 10.17487/RFC7084, November 2013, 740 . 742 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 743 Advertisement Guard (RA-Guard)", RFC 7113, 744 DOI 10.17487/RFC7113, February 2014, 745 . 747 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 748 Considerations for IPv6 Address Generation Mechanisms", 749 RFC 7721, DOI 10.17487/RFC7721, March 2016, 750 . 752 [RIPE-690] 753 Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., Alston, 754 J., Doering, G., Palet, J., Linkova, J., Balbinot, L., 755 Meynell, K., and L. Howard, "Best Current Operational 756 Practice for Operators: IPv6 prefix assignment for end- 757 users - persistent vs non-persistent, and what size to 758 choose", RIPE 690, October 2017, 759 . 761 [UK-NOF] Palet, J., "IPv6 Deployment Survey (Residential/Household 762 Services) How IPv6 is being deployed?", UK NOF 39, January 763 2018, 764 . 767 Appendix A. Flowchart for Host Processing of RAs 769 Conceptually, the mechanism operates as follows: 771 +----------------+ 772 | Normal proc. | 773 | of RA packet | 774 +---------+------+ 775 | 776 v 777 +----------------+ 778 | RA has PIO | No 779 | with A==1? |------> DONE 780 +----------------+ 781 | 782 | Yes 783 v 784 +----------------+ 785 | (For each PIO) | 786 | LTA=TRUE | 787 +----------------+ 788 | 789 v 790 +----------------+ +-----------------+ 791 | (For each Pref | | | 792 | assoc. with | Yes | | 793 | this router) |----->| LTA=FALSE | 794 | Is there corr. | | | 795 | PIO in the RA? | | | 796 +----------------+ +-----------------+ 797 | 798 | No 799 v 800 +----------------+ +-----------------+ +----------------+ 801 | | | (For each addr. | | Valid Lftime=0 | 802 | | Yes | for this Pref.) | Yes | LTA=FALSE | 803 | LTA==TRUE? |----->| |----->| (REM. ADDR!) | 804 | | | Pref Lftime==0? | | ! 805 +----------------+ +-----------------+ +----------------+ 806 | | 807 | No | No 808 v v 809 +----------------+ +-----------------+ 810 | | | Pref. Lftime=0 | 811 | LTA=TRUE | | LTA=FALSE | 812 +----------------+ +-----------------+ 814 Appendix B. Sample Timeline for Host Processing of RAs 816 The following example illustrates a sample packet exchange that 817 illustrates the algorithm specified in Section 5.1: 819 Router Host 820 RA, PIO={2001:DB8:1::/64, L=1, A=1} 821 --------------------------------------> 822 [Host configures addrs 823 for this prefix] 825 RA, PIO={2001:DB8:1::/64, L=1, A=1} 826 --------------------------------------> 827 [Normal proc. of RA] 828 . 829 . 830 [Router reboots] 832 RA, PIO={2001:DB8:2::/64, L=1, A=1} 833 --------------------------------------> {2001:DB8:1::/64, 834 LTA=TRUE} 835 . 836 . 837 RA, PIO={2001:DB8:2::/64, L=1, A=1} 838 --------------------------------------> {2001:DB8:1::/64, 839 LTA=FALSE} 840 Pref. Lftime=0 842 . 843 . 844 RA, PIO={2001:DB8:2::/64, L=1, A=1} 845 --------------------------------------> {2001:DB8:1::/64, 846 LTA=TRUE} 847 . 848 . 849 RA, PIO={2001:DB8:2::/64, L=1, A=1} 850 --------------------------------------> {2001:DB8:1::/64, 851 LTA=FALSE} 852 Valid Lftime=0 853 (Addr. Removed!) 855 Appendix C. Analysis of Some Suggested Workarounds 857 [This section is to be removed before publication of this document as 858 an RFC]. 860 During the discussion of this document, some alternative workarounds 861 were suggested (e.g. on the 6man list). The following subsections 862 analyze these suggested workarounds, in the hopes of avoiding 863 rehashing discussions of such workarounds. 865 C.1. On a Possible Reaction to ICMPv6 Error Messages 867 It has been suggested that if configured addresses become stale, a 868 CPE enforcing ingress/egress filtering BCP38 ([RFC2827]) might send 869 ICMPv6 Type 1 (Destination Unreachable) Code 5 (Source address failed 870 ingress/egress policy) error messages to the sending node, and that, 871 upon receipt of such error messages, the sending node might perform 872 heuristics that might help to mitigate the problem discussed in this 873 document. 875 The aforementioned proposal has a number of drawbacks and 876 limitations: 878 o It assumes that the CPE enforces ingress/egress filtering 879 [RFC2827]. While this is desirable behaviour, it cannot be relied 880 upon. 882 o It assumes that if the CPE enforces ingress/egress filtering, the 883 CPE will signal the packet drops to the sending node with ICMPv6 884 Type 1 (Destination Unreachable) Code 5 (Source address failed 885 ingress/egress policy) error messages. While this may be 886 desirable, [RFC2827] does not suggest signaling the packet drops 887 with ICMPv6 error messages, let alone the use of specific error 888 messages (such as Type 1 Code 5) as suggested. 890 o ICMPv6 Type 1 Code 5 could be interpreted as the employed address 891 to be stale, but also as a selected route being inappropriate/ 892 suboptimal. If the later, un-preferring addresses or removing 893 addresses upon receipt of these error messages would be 894 inappropriate. 896 o Reacting to these error messages would create a new attack vector. 897 This is of particular concern since ICMP-based attack do not even 898 require that the Source Address of the attack packets be spoofed 899 [RFC5927]. 901 C.2. On a Possible Improvement to Source Address Selection 903 [RFC6724] specifies source address selection (SAS) for IPv6. 904 Conceptually, it sorts the candidate set of source addresses for a 905 given destination, based on a number of pair-wise comparison rules 906 that must be successively applied until there is a "winning" address. 908 It has been suggested that an implementation might improve source 909 address selection, and prefer the most-recently advertised 910 information. In order to incorporate the "freshness" of information 911 in source address selection, an implementation would be updated as 912 follows: 914 o The node is assumed to maintain a timer/counter that is updated at 915 least once per second. For example, the time(2) function from 916 unix-like systems could be employed for this purpose. 918 o The local information associated with each prefix advertised via 919 RAs on the local network is augmented with a "LastAdvertised" 920 timestamp value. Whenever an RA with a PIO with the "A" bit set 921 for such prefix is received, the "LastAdvertised" timestamp is 922 updated with the current value of the timer/counter. 924 o [RFC6724] is updated such that this rule is incorporated: 926 Rule 3.5: Prefer fresh information If one of the two source 927 addresses corresponds to a prefix that has been more recently 928 advertised, say LastAdvertised(SA) > LastAdvertised(SA), then 929 prefer that address (SA in our case). 931 There are a number of limitations and drawbacks associated with this 932 approach: 934 o It may help to improve the selection of a source address, but it 935 does not help with the housekeeping of configured information: 937 * If the stale prefix is re-used in another network, nodes 938 employing stale addresses and routes for this prefixes will be 939 unable to communicate with the new "owners" of the prefix. 941 * Given that currently recommended default value for the "Valid 942 Lifetime" of PIOs is 2592000 seconds (30 days), it would take 943 too long for hosts to remove the configured addresses and 944 routes for the stale prefix. 946 o The earlier the above rule is incorporated into the [RFC6724] 947 rules, the more it could lead to suboptimal address selection. 948 For example, if incorporated as Rule 3.5 (before Rule #4, but 949 after Rule 3), an implementation may end up choosing a source 950 address from a "fresher" prefix rather than one with a longest- 951 matching prefix, thus leading to suboptimal routing. On the other 952 hand, the later the rule is incorporated into the [RFC6724] rules, 953 the more irrelevant the rule becomes (since existing rules might 954 prefer the stale addresses). 956 o In scenarios where multiple prefixes are being advertised (whether 957 by a single router via multiple RAs, multiple routers on the same 958 LAN segment, or different routers on different LAN segments (when 959 a host has multiple interfaces)), the new SAS rule is guaranteed 960 to result in non-deterministic behaviour, with hosts frequently 961 changing the selected address. This is certainly not desirable 962 from a troubleshooting perspective. 964 As a result, updating IPv6 source address selection does not relieve 965 nodes from improving their SLAAC implementations as specified in 966 Section 5.1, if at all desirable. On the other hand, employing 967 appropriate timers as specified in Section 5.1.1 would result in Rule 968 3 of [RFC6724] employing fresh addresses, without leading to 969 undeterministic behaviour. 971 Authors' Addresses 973 Fernando Gont 974 SI6 Networks / UTN-FRH 975 Segurola y Habana 4310, 7mo Piso 976 Villa Devoto, Ciudad Autonoma de Buenos Aires 977 Argentina 979 Phone: +54 11 4650 8472 980 Email: fgont@si6networks.com 981 URI: https://www.si6networks.com 983 Jan Zorz 985 Email: jan@go6.si