idnits 2.17.1 draft-gont-6man-slaac-renum-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4861, 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) -- 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 (January 31, 2019) is 1911 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 272, but not defined ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 (if approved) J. Zorz 5 Intended status: Standards Track January 31, 2019 6 Expires: August 4, 2019 8 Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering 9 Events 10 draft-gont-6man-slaac-renum-00 12 Abstract 14 A very common IPv6 deployment scenario is that in which a CPE employs 15 DHCPv6 Prefix Delegation to obtain an IPv6 prefix, and at least one 16 prefix from within the leased prefix is advertised on a local network 17 via SLAAC. In scenarios where e.g. the CPE crashes and reboots, 18 nodes on the local network continue using outdated prefixes which 19 result in connectivity problems. This document analyzes this problem 20 scenario, and proposes workarounds. 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 August 4, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Possible workarounds . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Improvement to SLAAC . . . . . . . . . . . . . . . . . . 3 60 3.2. Improved CPE behavior . . . . . . . . . . . . . . . . . . 5 61 3.3. Stable prefixes . . . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 6.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Appendix A. Flowchart for Host Processing of RAs . . . . . . . . 8 68 Appendix B. Sample Timeline for Host Processing of RAs . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Probably the most common deployment scenario for IPv6 in home 74 networks is that in which a CPE router employs DHCPv6 Prefix 75 Delegation (DHCPv6-PD) [RFC8415] to request a prefix from the ISP, 76 and a prefix belonging to the leased prefix is advertised on the LAN- 77 side of the CPE via Stateless Address Autoconfiguration (SLAAC) 78 [RFC4862]. 80 In scenarios such as that in which the CPE router crashes and 81 reboots, the CPE may be leased (via DHCPv6-PD) a different prefix 82 than the one previously leased and will therefore advertise such new 83 prefix on the LAN side via SLAAC. Hosts will normally configure an 84 address for the new prefix, but will normally retain and actively 85 employ the previously-configured addresses, since their associated 86 Preferred Lifetime and Valid Lifetime allow them to do so. The 87 default values, as specified in [RFC4861] are: 89 o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) 91 o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) 93 Lacking any explicit signaling to "obsolete" the previously- 94 configured addresses (for the now invalid/outdated prefix), hosts may 95 continue employing the previously-configured addresses which will 96 tipically result in packets being blackholed -- whether because of 97 egress-filtering by the CPE or ISP, or because responses to such 98 packets will be discarded or routed elsewhere. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Possible workarounds 108 The following subsections discuss possible workarounds for the 109 aforementioned problem. 111 3.1. Improvement to SLAAC 113 This section specifies an improvement to SLAAC that improves 114 robustness and that can mitigate the aforementioned problem. 116 The goal of this modification is that, when a router that was 117 previously advertising a prefix for address configuration (PIO with 118 the "A" bit set) is found to advertise other prefixes but not the 119 previously-advertised prefixes, addresses configured for the "old" 120 prefixes are marked as "not preferred" (i.e., their "Preferred 121 Lifetime" is set to 0), thus allowing for a more timely-reaction to 122 the problem described in Section 1. 124 Local information maintained for each prefix advertised by each 125 router is augmented with one boolean flag named "deprecate" that 126 defaults to "false". Note: hosts are already expected to keep track 127 of which router has advertised which prefix in order to be able to 128 properly select the first-hop router in multiple-prefix networks 129 [RFC8028] [I-D.ietf-6man-rfc6434-bis]. 131 After normal processing of Router Advertisement messages, Router 132 Advertisements that contain at least one PIO MUST be processed as 133 follows: 135 o The "deprecate" flag for each prefix advertised in the current 136 Router Advertisement should be set to "false". 138 o For each prefix that had been previously advertised by this router 139 but that does not have a corresponding PIO with the "A" flag set 140 in the received RA, proceed as follows: 142 * IF the "deprecate" flag is "true", then: 144 + IF there is any address configured for this prefix with a 145 "Preferred Lifetime" larger than 0, set its "Preferred 146 Lifetime" to 0, and the "deprecate flag" of this prefix to 147 "false". 149 + ELSE (all addresses for this prefix have a "Preferred 150 Lifetime" of 0), set the "Valid Lifetime" of any addresses 151 configured for this prefix to 0, and the "deprecate" flag to 152 "false". This will cause removal of all addresses for this 153 prefix. Additionally, if the corresponding prefix had been 154 advertised as on-link ("L"=1) by this router, remove any 155 routes to this prefix associated with the network interface 156 card on which the RA packet was received. 158 * ELSE (the "deprecate" flag is "false"): 160 + Set the "deprecate" flag of the corresponding prefix to 161 "true". 163 Appendix B illustrates the packet exchange and operation of the 164 algorithm for a typical scenario. Appendix A provides a flowchart 165 for this algorithm. 167 NOTES: 169 o The aforementioned processing assumes that while network 170 configuration information might be split into multiple RAs, PIOs 171 will be spread among *at most* two RAs. This assumption avoids 172 the use of any timers for this specific purpose. 174 o If the only prefix that has so far been advertised on the local 175 network is the prefix that has become outdated, and there is no 176 new prefix being advertised, the traditional processing is 177 unaffected (the mechanism discussed in this document will *never* 178 be triggered because no packets with PIOs with the "A" flag will 179 be received). The logic here is that it's better to have some 180 address, than no address at all. 182 o The processing of RAs that do not contain any PIOs with the "A" 183 bit set remain unaffected. 185 o The specified modification takes the conservative approach of 186 first setting the "Preferred Lifetime" to 0 (such that addresses 187 become non-preferred), and subsequently setting the "Valid 188 Lifetime" to 0 (such as the addresses are completely removed). 189 Once the addresses for this prefix have been removed, routes to 190 this prefix associated with the network interface on which the RA 191 packets were received are also removed. 193 3.2. Improved CPE behavior 195 The scenario discussed in Section 1 could be improved on the CPE-side 196 as follows: 198 o A CPE MUST record, on stable storage, the list of prefixes being 199 advertised on each LAN segment. 201 o Upon renewed information about the list of prefixes to be 202 advertised on the LAN-side (whether as a result of DHCPv6-PD or 203 manual configuration), then: 205 * Any prefixes that were previously advertised via SLAAC, but 206 that are not currently intended for address configuration, MUST 207 be advertised with a PIO option with the "A" bit set to 1 and 208 the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 210 * Any prefixes that were previously advertised via SLAAC as "on- 211 link", but that are not currently not considered "on-link", 212 MUST be advertised with a PIO option with the "L" bit set to 1 213 and the "Valid Lifetime" and a "Preferred Lifetime" set to 0. 215 * If both of the previous conditions are met (a prefix was 216 previously advertised with both the "A" and "L" bits set, but 217 is currently *not* intended for address configuration and is 218 *not* considered on-link), the prefix MUST be advertised with a 219 PIO option with both the "A" and "L" bits set to 1 and the 220 "Valid Lifetime" and a "Preferred Lifetime" set to 0. That is. 221 the advertisements of the previous two steps can be coalesced 222 into a single one with both the "A" and "L" bits set. 224 The aforementioned advertisement SHOULD be performed for at least the 225 "Valid Lifetime" previously employed for such prefix. 227 This improves the situation for hosts that do not implement the 228 modification specified in Section 3.1 but would obviously make 229 robustness dependent on the CPE, as opposed to the host itself. 231 3.3. Stable prefixes 233 The problem discussed in this document would be avoided if DHCPv6-PD 234 would lease "stable" prefixes. 236 There are a number of possible issues associated with this option: 238 o Provisioning systems may be unable to deliver stable IPv6 239 prefixes. 241 o While there is a range of information that may be employed to 242 correlate network activity [RFC7721], the use of stable prefixes 243 clearly simplifies network activity correlation, and may 244 essentially render features such as "temporary addresses" 245 [RFC4941] irrelevant. 247 o Applicable legislation may require the ISP to deliver dynamic IPv6 248 prefixes *by default* (see e.g. [GERMAN-DP]). 250 4. Security Considerations 252 This document discusses a a problem that may arise in scenarios where 253 dynamic IPv6 prefixes are employed, and proposes workarounds that 254 enable such usage while avoiding interoperability problems. The 255 security and privacy implications of IPv6 addresses are discussed in 256 [RFC7721]. 258 An attacker that could impersonate a router could forge multiple RA 259 packets that contain PIOs of prefixes that are currently not 260 advertised on the local network, to trigger the mechanism specified 261 in this document to cause addresses currently configured for the 262 legitimate prefixes to be removed. However, an attacker that can 263 impersonate a router could more easily achieve the same goal by 264 advertising the legitimate prefixes with both the "Preferred 265 Lifetime" and "Valid Lifetime" set to 0. 267 Attacks based on forged RA packed can be mitigated with technologies 268 such as RA-Guard [RFC6105] [RFC7113]. 270 5. Acknowledgments 272 The authors would lie to thank (in alphabetical order) [TBD] for 273 providing valuable comments on earlier versions of this document. 275 Fernando would like to thank Alejandro D'Egidio , and Sander Steffan 276 for a discussion of these issues. 278 The problem discussed in this document, and the recommendation to 279 employ stable prefixes, have been previously documented in 280 [RIPE-690]. 282 6. References 284 6.1. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 292 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 293 DOI 10.17487/RFC4861, September 2007, 294 . 296 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 297 Address Autoconfiguration", RFC 4862, 298 DOI 10.17487/RFC4862, September 2007, 299 . 301 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 302 Extensions for Stateless Address Autoconfiguration in 303 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 304 . 306 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 307 Hosts in a Multi-Prefix Network", RFC 8028, 308 DOI 10.17487/RFC8028, November 2016, 309 . 311 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 312 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 313 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 314 RFC 8415, DOI 10.17487/RFC8415, November 2018, 315 . 317 6.2. Informative References 319 [GERMAN-DP] 320 BFDI, "Einfuhrung von IPv6 Hinweise fur Provider im 321 Privatkundengeschaft und Herstellere", Entschliessung der 322 84. Konferenz der Datenschutzbeauftragten des Bundes und 323 der Lander am 7./8. November 2012 in Frankfurt (Oder), 324 November 2012, 325 . 329 [I-D.ietf-6man-rfc6434-bis] 330 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 331 Requirements", draft-ietf-6man-rfc6434-bis-09 (work in 332 progress), July 2018. 334 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 335 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 336 DOI 10.17487/RFC6105, February 2011, 337 . 339 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 340 Advertisement Guard (RA-Guard)", RFC 7113, 341 DOI 10.17487/RFC7113, February 2014, 342 . 344 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 345 Considerations for IPv6 Address Generation Mechanisms", 346 RFC 7721, DOI 10.17487/RFC7721, March 2016, 347 . 349 [RIPE-690] 350 RIPE, Zorz, J., Zorz, S., Drazumeric, P., Townsley, M., 351 Alston, J., Doering, G., Palet, J., Linkova, J., Balbinot, 352 L., Meynell, K., and L. Howard, "Best Current Operational 353 Practice for Operators: IPv6 prefix assignment for end- 354 users - persistent vs non-persistent, and what size to 355 choose", RIPE 690, October 2017, 356 . 358 Appendix A. Flowchart for Host Processing of RAs 360 Conceptually, the mechanism operates as follows: 362 +-------------------+ 363 | Normal processing | 364 | of RA packet | 365 +---------+---------+ 366 | 367 v 368 +-------------------+ 369 | RA has PIO with | No 370 | A==1? |------> DONE 371 +-------------------+ 372 | 373 | Yes 374 v 375 +-------------------+ 376 | (For each PIO) | 377 | deprecate=TRUE | 378 +-------------------+ 379 | 380 v 381 +-------------------+ +-----------------+ 382 | (For each Pref. | | | 383 | assoc with this | Yes | | 384 | router) |----->| deprecate=FALSE | 385 | Is there corresp. | | | 386 | PIO in the RA? | | | 387 +-------------------+ +-----------------+ 388 | 389 | No 390 v 391 +-------------------+ +------------------+ +-----------------+ 392 | | | (For each addr. | | Valid Lftime=0 | 393 | | Yes | for this Prefix) | Yes | deprecate=FALSE | 394 | deprecate==TRUE? |----->| |----->| (REM. ADDR!) | 395 | | | Pref. Lftime==0? | | ! 396 +-------------------+ +------------------+ +-----------------+ 397 | | 398 | No | No 399 v v 400 +-------------------+ +------------------+ 401 | | | Pref. Lftime=0 | 402 | deprecate=TRUE | | deprecate=FALSE | 403 +-------------------+ +------------------+ 405 Appendix B. Sample Timeline for Host Processing of RAs 407 The following example illustrates a sample packet exchange that 408 illustrates the algorithm specified in Section 3.1: 410 Router Host 411 RA, PIO={2001:DB8:1::/64, L=1, A=1} 412 --------------------------------------> 413 [Host configures addrs 414 for this prefix] 416 RA, PIO={2001:DB8:1::/64, L=1, A=1} 417 --------------------------------------> 418 [Normal proc. of RA] 419 . 420 . 421 [Router reboots] 423 RA, PIO={2001:DB8:2::/64, L=1, A=1} 424 --------------------------------------> 425 deprecate=TRUE 426 . 427 . 428 RA, PIO={2001:DB8:2::/64, L=1, A=1} 429 --------------------------------------> 430 Pref. Lftime=0 431 deprecate=FALSE 432 . 433 . 434 RA, PIO={2001:DB8:2::/64, L=1, A=1} 435 --------------------------------------> 436 deprecate=TRUE 437 . 438 . 439 RA, PIO={2001:DB8:2::/64, L=1, A=1} 440 --------------------------------------> 441 Valid Lftime=0 442 deprecate=FALSE 443 (Addr. Removed!) 445 Authors' Addresses 447 Fernando Gont 448 SI6 Networks / UTN-FRH 449 Segurola y Habana 4310, 7mo Piso 450 Villa Devoto, Ciudad Autonoma de Buenos Aires 451 Argentina 453 Phone: +54 11 4650 8472 454 Email: fgont@si6networks.com 455 URI: https://www.si6networks.com 456 Jan Zorz 458 Email: jan@go6.si