idnits 2.17.1 draft-vv-6man-nd-prefix-robustness-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4862, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2021) is 896 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: 'ADDRCONF' is mentioned on line 1173, but not defined == Unused Reference: 'Flash-Renumbering' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 1342, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 8978 (ref. 'Flash-Renumbering') ** Downref: Normative reference to an Informational RFC: RFC 7157 (ref. 'MHMP') Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Maintenance (6man) Working Group E. Vasilenko 2 Internet Draft P. Volpato 3 Updates: 4861, 4862 (if approved) Huawei Technologies 4 Intended status: Standards Track Olorunloba Olopade 5 Expires: April 2022 Virgin Media 6 October 14, 2021 8 ND Prefix Robustness Improvements 9 draft-vv-6man-nd-prefix-robustness-01 11 Abstract 13 IPv6 prefixes could become invalid abruptly as a result of outages, 14 network administrator actions, or particular product shortcomings. 16 That could lead to connectivity problems for the hosts attached to 17 the subtended network. 19 This document has two targets: on one hand, to analyze the cases 20 that may lead to network prefix invalidity; on the other to develop 21 a root cause analysis for those cases and propose a solution. 23 This may bring to extensions of the protocols used to convey prefix 24 information and other options. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology and pre-requisite..................................3 61 2. Introduction...................................................4 62 3. Problem Scenarios..............................................4 63 3.1. Reference architectures...................................5 64 3.2. Discussion on the scenarios...............................5 65 3.2.1. Non-graceful reload due to unexpected events .........5 66 3.2.2. Graceful reload without precautions ..................7 67 3.2.3. Abrupt hardware replacement without the possibility 68 for graceful prefix deprecation.......................7 69 3.2.4. Non-graceful configuration change ....................8 70 3.2.5. An uplink breaks connectivity without a relevant 71 notification to the connected hosts...................8 72 4. Root cause analysis...........................................10 73 4.1. What to protect..........................................11 74 4.2. Where to protect.........................................12 75 4.3. When to protect: technology scenarios....................12 76 5. Solutions.....................................................13 77 5.1. Multi-homing multi-prefix (MHMP) environment.............13 78 5.2. A provider is not reachable in MHMP environment..........16 79 5.3. Administrator abruptly replaces PA prefix................17 80 5.4. Planned router outage....................................18 81 5.5. Prefix information lost because of abrupt router outage..19 82 5.6. Prefix information lost after hardware replacement.......19 83 5.7. Link layer address of the router should be changed.......20 84 5.8. Dependency between solutions and extensions..............20 85 6. Extensions to the existing standards..........................20 86 6.1. Default router choice by host............................20 87 6.2. Prefixes become dynamic..................................21 88 6.3. Do not forget to deprecate prefixes on renumbering.......22 89 6.4. Do not forget to deprecate prefixes on shutdown..........23 90 6.5. Store prefixes in non-volatile memory....................23 91 6.6. Find lost information by "Synchronization"...............24 92 6.7. Default router announcement rules........................26 93 6.8. Faster detection of the stale default router.............26 94 6.9. Clean orphaned prefixes at the default router list.......27 95 7. Interoperability analysis.....................................27 96 8. Applicability analysis........................................28 97 9. Security Considerations.......................................28 98 10. IANA Considerations..........................................28 99 11. References...................................................29 100 11.1. Normative References....................................29 101 11.2. Informative References..................................30 102 12. Acknowledgments..............................................31 104 1. Terminology and pre-requisite 106 [ND] and [SLAAC] are pre-requisite to understand this document. 107 The terms are inherited from these standards. 109 Additional terms: 111 Home Gateway - a small consumer-grade router that provides network 112 access between hosts on the local area network (LAN) and the 113 Internet behind the wide area network (WAN) 115 PA - Provider-Aggregatable addresses leased to the client or 116 subscriber 118 MHMP - Multi-Homing Multi-Prefix. An environment with hosts 119 connected to different PA providers (multi-homing) through 120 different address spaces announced from different providers 121 (multi-prefix) 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. Introduction 131 It has been reported that some number of cases could lead to loss of 132 information (primarily prefixes) by [ND]. Current [ND] protocol's 133 default timers lead to many days of outage for hosts. This is not 134 acceptable. 136 This document analyses all potential cases when an outage could 137 happen and proposes solutions. Discussion is restricted to potential 138 [ND] extensions only. 140 MHMP environment has been considered. It has been discovered that 141 [ND] problems could be isolated from the overall complex [MHMP] 142 environment, and could be fixed separately. 144 The document is organized to introduce, in section 3, the scenarios 145 where the issue of prefix invalidity may happen and the cases of 146 invalidity. 148 Section 4 provides a root cause analysis for the cases of invalidity 149 and identifies the corner-cases which are subject of our discussion. 151 Section 5 proposes a solution for the cases identified. 153 Section 6 brings the discussion forward, proposing extensions to 154 [ND]. 156 3. Problem Scenarios 158 [ND] distributes prefixes as PIOs (Prefix Information Options) in RA 159 (Router Advertisements) messages from routers. 161 Once a router assigns a prefix to a host, this prefix is assumed to 162 be stable so that hosts can employ it to configure the IPv6 163 addresses associated with their interfaces [SLAAC] or to forward 164 packets to the network. 166 Prefix changes may happen and are governed by the rules of [ND], 167 [SLAAC]. 169 Yet, cases exist where prefix instability may happen. An example is 170 provided by the so-called "flash-renumbering" event: when flash- 171 renumbering happens a network prefix in use suddenly becomes invalid 172 because it is replaced by a new prefix. 174 The router causing or forced to cause the network renumbering may 175 not be able to cope with the effects of this sudden change (for 176 example, deprecating the previously assigned prefixes). Another 177 possibility is that the subtended hosts do not have the means of 178 overcoming the effects of renumbering. 180 This section describes problems that were found in live networks. 181 Most of the information in this section comes from [Flash- 182 Renumbering], [SLAAC Robustness]. Their contributions are greatly 183 acknowledged. 185 Reference architectures 187 Home broadband networks, SOHO (Small Office Home Office) networks 188 are the typical scenarios affected by renumbering. Some problems 189 discussed below applicable on the more general basis. 191 In typical case a router (e.g. Home Gateway, Customer Premise 192 Equipment (CPE), Customer Edge (CE), etc.) is deployed to provide 193 connectivity to a Service Provider network for the attached devices. 194 A second router may be deployed for redundancy, especially for 195 business scenarios. 197 Two reference architecture can be considered: 199 Architecture #1. Hosts are directly connected to the router. For 200 example, a Home Gateway embeds the functions of L2 device (Ethernet 201 switch, WiFi AP) and L3 device (router). 203 Architecture #2. Hosts connect to an intermediate L2 device (e.g. a 204 wired Ethernet switch or a Wi-Fi access point) that, in turn, 205 connects to the router (or routers, if uplink redundancy is 206 requested). 208 Discussion on the scenarios 210 The discussion provided here is introductory to both the root cause 211 analysis provided in section 4. and the solutions proposed in 212 section 5. 214 Non-graceful reload due to unexpected events 216 It may happen in architecture #2. 218 A router could be reloaded abruptly for many reasons: hardware or 219 software bug, power outage, manual intervention. This last one is 220 very probable for home broadband subscribers that tend to fix every 221 problem with power recycle. 223 It does not create additional problems for [ND] and [SLAAC] in the 224 majority of the cases, because the same information would be 225 advertised by the router in RA messages after each reload. 227 It does not create the problem in many other cases, including the 228 situation when Home Gateway would receive and advertise new PIO, 229 because hosts are typically directly connected to Home Gateway. 230 Ethernet or WiFi link would be initialized anyway - it would clear 231 all stale information on hosts. 233 It should not create problems for proper home network design where 234 all CPEs are routers - see [HomeNet Architecture]. The delegated 235 prefix would not be changed in the case of subtended CPE reload. 236 Prefix change in the case of upstream CPE reload should be properly 237 discontinued by subtended CPE. There is the need for a special 238 protocol for prefix distribution that is out of the scope of this 239 document - see [HNCP]. 241 For architecture #2 implemented in home environments, we have a 242 corner case when Home Gateway's abrupt reload would not be visible 243 to hosts connected to subtended "bridged" CPE. If it would coincide 244 with the situation when a different prefix would be delegated from 245 Carrier (at 37% probability according to [Residential practices]), 246 it would lead to the situation that hosts would receive a new prefix 247 without deprecation of the previous one. Hosts do not have any 248 standard mechanism to choose only the new prefix for communication. 249 That would lead to a connectivity problem. 251 How long a non-preferred prefix would be kept in a stale state on 252 the host is not important (default AdvValidLifetime is 30 days in 253 section 6.2.1 of [ND]), because according to [Default Address] 254 section 5 rule#3, it should have a lower priority to be chosen. 255 [SLAAC] section 5.5.4 is another good reference highlighting that 256 address should be avoided after it would reach the deprecated 257 status. 258 How long an address would stay in the preferred state is important. 259 [ND] instructs hosts to prefer certain prefix for 7 days - see 260 default AdvPreferredLifetime in section 6.2.1. 261 It is not realistic for the subscriber to wait for 7 days. 262 It practically means that the subscriber in this corner case would 263 have a few options to fix the problem: (1) reload all hosts, or (2) 264 reconnect the physical link of every host, or (3) reload subtended 265 bridge, or (4) manually delete the prefix on the hosts to clear 266 stale information. 268 Graceful reload without precautions 270 Specifically this scenario may happen when developers don't apply 271 precautions in case previous prefixes are not deprecated. It may 272 happen in both architectures. 274 The router could be reloaded by graceful procedure (reboot or 275 shutdown that would use "init 6" in Unix). It is still possible that 276 software would not send RA with prefix Preferred Lifetime zero to 277 inform hosts about prefix deprecation. This practice prevails 278 because IPv4's centralized address assignments by DHCP does not need 279 similar precautions. 281 Again, like in the previous section, it would not create a problem 282 in the majority of the cases for directly connected hosts 283 (architecture #1) because link layer would be reinitialized too. The 284 same corner case (architecture #2) would lead to the same result: 285 connectivity problem that could be resolved only by 4 types of 286 manual intervention mentioned in the previous section. 288 Abrupt hardware replacement without the possibility for graceful prefix 289 deprecation 291 Outage may happen up to 30 minutes (including time for hardware 292 replacement) in both architectures and 1 week in architecture #2. 294 The hardware could fail or be replaced with an abrupt power 295 disconnect. The latter is very probable for the home environment. 296 Graceful notification of hosts may not happen. 298 The new hardware may have a different link layer address and a 299 different link local address as a result. The router would look like 300 a new one on the link. Any communication with it could not be the 301 reason to deprecate announcements made early by the router perceived 302 as a different one. 304 [ND] section 6.2.1 has recommended the AdvDefaultLifetime as 305 3*MaxRtrAdvInterval. Hosts may send traffic to a non-existent router 306 for up to 30 minutes. This outage is probable for both 307 architectures. 309 According to section 4.2 of [ND] "Router Lifetime" is related only 310 to router default status. PIO announced early may be preferred up to 311 7 days according to AdvPreferredLifetime in section 6.2.1 of [ND] 312 even after the router default status is deprecated. The probability 313 for such a situation is the same low as discussed in case 1A because 314 a different prefix should be announced after hardware reload and a 315 switch should be present between the host and the router. The same 316 corner case (architecture #2) would lead to the same result: a 317 connectivity problem that could be resolved only by 4 types of 318 manual intervention mentioned in the previous section. 320 Non-graceful configuration change 322 This situation may happen due to abrupt prefix change on the router 323 (in both architectures) or VLAN change on the switch (it may happen 324 in architecture #2). 326 Router configuration could be changed manually, by automation tools, 327 or by protocols (for example, prefix distribution). 329 Additionally for architecture #2, L2 domain could be abruptly 330 changed by configuration (for example, VLAN change from "quarantine" 331 to "production" without any chance for the router to send a 332 message). 334 It could lead to the situation that prefix would change abruptly, 335 without any notification to hosts about the necessity to deprecate 336 the previous prefix. Hosts should be notified by prefix announcement 337 with Preferred Lifetime set to zero. 339 It should not happen for residential CPE because [CPE Requirements] 340 section 4.3 requirement L-13 clearly instructs: "If the delegated 341 prefix changes, i.e., the current prefix is replaced with a new 342 prefix without any overlapping period of time, then the IPv6 CE 343 router MUST immediately advertise the old prefix with a Preferred 344 Lifetime of zero". 346 But it is perfectly possible for other environments (except 347 residential CPEs) because other routers are not required to do the 348 same: [Node Requirements] does not clarify the exact router behavior 349 in the case of abrupt prefix change. [SLAAC] does not have any 350 recommendations either. 352 An uplink breaks connectivity without a relevant notification to the 353 connected hosts 355 It may arise in both architectures #1 and #2. 357 A router could lose uplink. The probability for such an event is 358 much bigger for a mobile uplink (modem). It would invalidate the 359 possibility to use a PA prefix advertised from this carrier even in 360 the case that another carrier uplink is available on this or 361 redundant router (connectivity to the Internet is not lost). Some 362 mechanism is needed to inform hosts not to use address space from 363 the disconnected carrier because another carrier would filter it out 364 by anti-spoofing security protection. 366 The multi-homing multi-prefix PA environment has been properly 367 explained in [MHMP]. The discussion of how traffic should be source- 368 routed by routers in [MHMP] environment is not relevant to our [ND] 369 discussion. Unfortunately, an improper address used as a source 370 would cause a traffic drop as soon as traffic gets to the different 371 carrier. 373 [Default Address] section 5 (source address selection) rule 5 (for 374 different interfaces on the host) and rule 5.5 (for the same 375 interface) partially prepare hosts for such situation: "Prefer 376 addresses in a prefix advertised by the next-hop. If SA or SA's 377 prefix is assigned by the selected next-hop that will be used to 378 send to D [...] then prefer SA". This algorithm has an assumption 379 that the source address should be chosen after the next hop. 381 Unfortunately, the rules mentioned above in [Default Address] 382 section 5 would work only if the default router would cease to be 383 default after it loses route to its carrier. It would work only in 384 simplified topology where all hosts connect by L2 to different CPEs, 385 each leading to its separate carrier prefix. It could be called a 386 "common-link environment for all hosts and routers". It is not 387 possible in practice because hosts on the most popular link layer 388 technology (WiFi) are rooted to only one CPE (with AP inside) - they 389 would not switch automatically to different CPE where the Internet 390 connectivity may be still available. 392 [CPE Requirements] have G-3/4/5 specifically for this simplified 393 multi-homing residential design. It recommends announcing Router 394 Lifetime as zero on LAN if CPE does not have "default router from 395 the uplink" - it would push the host to use another source address 396 by mentioned the above source address selection algorithm. 398 It is not explained in [CPE Requirements] what should happen with PA 399 delegated prefix after the respective uplink is disconnected. 400 Probably, this is because it was not needed to deprecate stale 401 prefix for the above mentioned-mechanism (based on default router 402 withdrawal) to work. 404 The local residential network could be left without any default 405 router as a result of using the above mechanism - it is especially 406 probable in the single CPE environment. Hence, [CPE Requirements] 407 promotes [ULA] addresses for local connectivity. Default router 408 functionality is returned specifically for [ULA] addresses by 409 requirement L-3: use "Route Information Option" from [Route 410 Preferences]. It needs hosts' participation in routing through the 411 RIO option. 413 Unfortunately, this long chain of fixes explained above is strictly 414 optimized for the environment "common-link for all hosts and 415 routers". It is not the case for single WiFi inside any CPE or other 416 topologies. 418 Neither [ND] nor [SLAAC] instruct the router what to do when the PA 419 delegated prefix is withdrawn abruptly. 421 [Multi-Homing] section 3 has a good discussion about the proper 422 relationship between default routers and prefixes advertised by 423 respective routers in a stable situation. We would reuse these ideas 424 in section 5.1. [Multi-Homing] does not discuss what to do in the 425 situation when the router is available, but some uplinks (with 426 delegated prefixes) are lost. 428 [MHMP] discusses the problem in deep detail with two tools proposed 429 to regulate [ND] behavior: [Policy by DHCP] to change [Default 430 Address] algorithm and [Route Preferences] to inform about 431 appropriate exit points. There are more details later in section 432 5.1. 434 4. Root cause analysis 436 Let's further analyze to be sure that all corner cases are found. 438 We would assume in all discussions below that [RA-Guard] is 439 implemented, and all messages are from routers under legitimate 440 administrative control. Security issues are considered as resolved 441 by [RA-Guard], and possibly with extensions in [RA-Guard+]. 443 DHCP is almost as vulnerable as SLAAC for cases found below. DHCP's 444 typical lease time (hours) is shorter than SLAAC's prefix lifetime 445 (days), but is too long for users to accept self-repairing time. 446 Root cause analysis below applies to all possible environments: 447 DHCP, SLAAC, and mixed. 449 What to protect 451 [ND] Router Advertisements deliver configuration information to 452 hosts. Such information could become inaccurate in two different 453 periods of time: 455 a) "Recoverable". Time is needed for some process to finish and 456 update information (example: router reload or uplink re-connect). 458 b) "Non-recoverable". Time, dependent on some timer expiration 459 (example: complete loss of prefix or default router). 461 A careful look at the information distributed by RA would give us 462 the understanding that the most problematic is the information that 463 is already protected by deprecation timers: Prefix Information 464 Option and Default Router. We see from the cases discussed in 465 section 3 that this information is still susceptible to recoverable 466 and non-recoverable periods of inaccuracy. 468 For example, in the case of abrupt router reload described in 469 sections 3.2.1. -3.2.3. , the recoverable part is the time spent by 470 router and hosts to update their cache after the router reload. The 471 non-recoverable part is related to the setting of the 472 AdvPreferredLifetime timer which would probably force a user to 473 solve the issue with manual intervention. 475 The next problematic case is the abrupt change of source link-layer 476 address. This problem is not discovered yet in production because it 477 has a low probability. Indeed, a router with a different link-layer 478 address would be treated as a new router, the old router would just 479 disappear from the link. It would affect primarily default router 480 information because all other information should be immediately re- 481 advertised from the new link layer address. Section 6.2.8 of [ND] 482 already discusses how to properly deprecate the default router 483 status of the old link layer address, but no recommendation is given 484 in [ND] for prefix deprecation in this situation. A corner case is 485 possible that software would not treat the new virtual interface as 486 identical concerning the prefix information that should be 487 announced. Different prefixes could be announced. Some additional 488 precautions are needed. 490 Other information in RA (Hop Limit, MTU, DHCP flags, Reachable 491 timer, and Retransmit timer) are not so sensitive because (1) it is 492 typically static and (2) it does not affect connectivity for 493 respective parameters change in the wide range. 495 Flag "A" in PIO deserves special attention. It could be cleared 496 abruptly (signaling that hosts should not use this prefix for 497 [SLAAC] anymore). That should not create any problem, because the 498 prefix is still available from a respected PA provider - traffic 499 could be routed to the global Internet. Therefore, it is not vitally 500 important for the host to immediately deprecate the address from 501 this prefix. 502 A similar situation is with flag "M" in RA: DHCP address should be 503 deprecated. It should not create a connectivity problem because 504 prefixes could be routed to the global Internet. 506 Where to protect 508 [ND] is the protocol for first-hop connection between host and 509 router. It is designed for one link only. One link could have more 510 than one router. 512 We would assume below that a more complex topology (many other 513 routers) is shielded from this link by some other protocol that 514 would deliver all necessary information to those routers. 515 [HomeNet Architecture] discusses many types of information that 516 should be distributed to every home router. We focus on only 517 delegated prefixes for our discussion. 518 The number of uplinks on every router is not important, as long as 519 proper information about prefixes is up to date on the router. 521 Hence, all our topologies could be simplified into the following 522 scenarios: 524 I. L2 device (switch, WiFi AP) and L3 device (router) are in the 525 same device (sharing the fate for power, reboot) (refer to 526 architecture #1 in section 3.1. ). 528 II. Separate L2 device (probably a switch) and an arbitrary number of 529 L3 devices (routers) are connected to the same IPv6 link (refer 530 to architecture #2 in section 3.1. ). 532 When to protect: technology scenarios 534 Let's reorder scenarios discussed in section 3. in the way that it 535 would be better to map to the technology modifications and account 536 for some corner cases found in root cause analysis: 538 1. Proper prefix usage for Multi-Homing Multi-Prefix environment. 539 Hosts should be capable of choosing in a coordinated way 540 (1) a source address (from proper PA prefix) and (2) a next hop: 542 a. In a normal situation: all providers and prefixes are available 544 b. In a faulty situation: one provider is not reachable, but some 545 hosts and links on the routed path to this provider may still be 546 reachable 548 c. In the case when an administrator abruptly replaces delegated 549 prefix 551 2. Proper prefix usage for the case of router outage that: 553 d. Planned for this interface 554 (reboot, shutdown, or ceasing to be a router) 556 e. Abrupt (power outage, software or hardware bug) 558 f. Abrupt (power outage, hardware fault) with hardware replacement 560 3. Proper prefix usage for the case of link layer address of the 561 router. 563 These cases are discussed from section 5.1. to section 5.6. 565 There is no big difference for [ND] between ULA and GUA at the 566 considered link because both could be disjoined at any routed hop 567 upstream. It would need the same invalidation mechanisms on the 568 link. ULA could be invalidated too for the case that ULA spans many 569 sites in a big company. The residential network would probably have 570 a separate ULA for every household that would decrease the 571 probability of ULA prefixes invalidation. It is the responsibility 572 of another protocol (example: [HNCP]) to decide when ULA should be 573 invalidated, if ever. 575 5. Solutions 577 Let's look at the solutions for scenarios listed in section 4.3. 579 Multi-homing multi-prefix (MHMP) environment 581 We would consider here host capability to choose a proper PA prefix 582 and next hop router in a multi-homing multi-prefix (MHMP) 583 environment. 585 Our discussion is restricted to [ND] protocol only (one link) - it 586 would cut the number of topologies discussed in section 4.2. 588 The complex MHMP situation is properly discussed in [MHMP] section 589 3.1 - it is critical to read it to understand the rest of this 590 section. It is possible to introduce one additional classification 591 to clearly separate what it is possible to implement now from what 592 needs additional standardization efforts: 594 1. Case "equal prefixes": Announced prefixes are fully equal by 595 scope and value, all interested (by host) resources could be 596 reachable through all announced PA prefixes; 597 traffic distribution between carriers could be round-robin. 599 2. Case "non-equal prefixes": Announced prefixes are not equal - (1) 600 some resources (for example walled garden of one carrier) could 601 be accessed only through a particular prefix or (2) it is 602 desirable to have some policy for traffic distribution between PA 603 prefixes (cost of traffic, delay, packet loss, jitter, 604 proportional load). 606 There are two reminders before we discuss the above cases: 608 o [ND] section 6.3.6 recommends next hop choice between default 609 routers in a round-robin style. 611 o [Default Address] section 7 defines that source and destination 612 address selection should happen after the next hop (or interface) 613 would be selected by [ND] or routing. [Note: the assumption is 614 that a host has the information to determine the next hop, for 615 example because it has been delegated by an upstream router. The 616 host considered here selects the source and destination addresses 617 knowing the outgoing interface or the next-hop]. 619 Case "equal prefixes" does not create any requirement on what prefix 620 should be used for the source address. It is only needed that the 621 source address would be chosen to be compatible with the next hop 622 that should be in the direction to the respective carrier. 623 It would happen automatically for topology with only one router on 624 this link (then it would be the problem of the router how to do 625 source routing to the proper carrier on upstream) - it does not 626 create any additional requirements for host functionality. 627 Host on a multi-homing link would need compliance to [Default 628 Address] section 5 (source address selection) rule 5 (for different 629 interfaces on the host) or rule 5.5 (for different next hops on the 630 same interface) to choose source address compliant to the next hop. 631 Hence, it is possible to satisfy this basic case on the current 632 level of standardization developed. 634 Case "non-equal prefixes" is more complicated. It would be too late 635 if we would try to solve this problem on a router, because the wrong 636 source address may be already chosen by the host - it would not be 637 possible to contact the appropriate resource in the "walled garden". 638 Only NAT could be left as an option, but that is not a valid choice 639 for IPv6. 641 We could consider 2 methods to resolve the case of "non-equal 642 prefixes": 644 1. The same policies could be formatted differently and fed to the 645 host by two mechanisms: "Routing Information Options" of [Route 646 Preferences] and [Policy by DHCP] to modify policies in [Default 647 Address] selection algorithm. Then current priority of mechanisms 648 could be preserved the same: initially [ND] or routing would 649 choose the next hop, then [Default Address] would choose a source 650 address (and destination if multiple answers from DNS are 651 available). It is the method that is assumed in [MHMP]. 652 2. We could supply policies by [Policy by DHCP] only to [Default 653 Address] selection algorithm. [Default Address] discusses such 654 potential application in section 7. We could assume the reversion 655 of the algorithm's order: source address could be chosen first, 656 then next hop (default router). 657 Source address selected from proper carrier is potentially the 658 complete information needed for the host to choose the next hop, 659 but not in the [ND] default round-robin way among all available 660 routers. We need [ND] extension for this method that the host 661 would consider only default routers that have announced prefixes 662 for the chosen source IP address. 663 It is this method that is assumed in [Multi-Homing] section 3.2. 664 The difference from this document is that the same rules were 665 formulated not as the general advice, but as the particular 666 correction to [ND] - see section 6.1 for proposed [ND] extension. 668 The advantage of the second method is that we would not need to 669 download policies as RIO by [Route Preferences] - this mechanism is 670 not needed for the MHMP environment. 671 Only the second method is universal and extendable because not all 672 policies could be translated as RIO of [Route Preferences]. 673 Dynamic policies (packet loss, delay, and jitter) could be measured 674 only on hosts in the direction of many carriers. The decision about 675 source address and next hop should have an option to be fully local. 677 A provider is not reachable in MHMP environment 679 Let's assume the following fault situation: one provider is not 680 reachable in [MHMP] environment. Additionally, consider the more 681 complicated case when some hosts on the upstream routed path to this 682 provider may still be reachable after the path to the carrier is 683 broken. 685 A prefix could be dynamic - it could be received from some other 686 protocols (DHCP-PD, HNCP). The prefix could become invalid (at least 687 for the global Internet connectivity) as a result of the link lost 688 in the upstream direction to the carrier that distributed this 689 prefix. 691 It is difficult to signal by [ND] that particular on-site subnets 692 are still available for hosts with this prefix. [Route Preferences] 693 does give the possibility to selectively inform hosts of what is 694 still available with this source address, but [Route Preferences] is 695 not trying to automate such prefix calculations. It is not the best 696 idea to involve [ND] in routing. A possibility is to invalidate the 697 prefix as a whole if the prefix is invalid for its primary purpose 698 (Internet connectivity). 699 The solution for connectivity to some upstream links that is still 700 potentially available with this prefix is [ULA]. We have many 701 reasons to promote [ULA] for internal site connectivity: (1) hosts 702 would not have any address at all without initial connection to the 703 provider, (2) PA addresses would be invalidated in 30 days of 704 disconnect anyway, (3) it is not a good idea to give new addresses 705 from PA pool that is disconnected now from global Internet - hosts 706 may have a better option to get global reachability. ULA has better 707 security (open transport ports is not accessible from the Internet) 708 that is an additional bonus. 709 We effectively join current [CPE Requirements] and [HomeNet 710 Architecture] requirements in sections 2.2, 2.4, 3.4.2 that 711 subscriber's network should have local ULA addresses. 713 Prefix deprecation should be done by RA with zero Lifetime for this 714 prefix. It will put the prefix on hosts to the deprecated status 715 that according to many standards ([ND], [SLAAC], and [Default 716 Address]) would prioritize other addresses. Global communication 717 would be disrupted for this prefix anyway. Local communication for 718 deprecated addresses would continue till normal resolution because 719 the default Valid Lifetime is 30 days. Moreover, if it would happen 720 that this delegated prefix was the only one in the local network (no 721 [ULA] for some reasons), then new sessions would be opened on 722 deprecated prefix because it is the only address available. 724 If connectivity would be re-established and the same prefix would be 725 delegated to the link - it would be announced again with proper 726 preferred lifetime. If a different prefix could be delegated by the 727 PA provider, then the old prefix would stay in deprecated status. 728 It is an advantage for the host that would know about global 729 reachability on this prefix (by deprecated status) because the host 730 may use other means for communication at that time. 732 Such dynamic treatment of prefixes could have the danger of 733 oscillating links on the path to PA provider that would create the 734 flood of [ND] messages. 735 [HNCP] section 1.1 states: "it is desirable for ISPs to provide 736 large enough valid and preferred lifetimes to avoid unnecessary HNCP 737 state churn in homes". 738 It makes sense to introduce dampening for the rate of prefix 739 announcements. 741 Such conceptual change in the treatment of prefixes would not affect 742 current enterprise installations where prefixes are static. 744 It is important to mention again that it is the responsibility of 745 the respective protocol (that has delivered prefix to the considered 746 router) to inform the same router that prefix is not routed anymore 747 to the respective carrier. It is easy to do it in the simplified 748 topology when the only router could correlate uplink status with 749 DHCP-PD prefix delegated early. Some additional protocols like 750 [HNCP] are needed for more complex topology. 752 There is nothing in [ND] or [SLAAC] that prevents us from treating 753 prefixes as something more dynamic than "renumbering" to reflect the 754 dynamic path status to the PA provider. We propose extensions to 755 [CPE Requirements] and [SLAAC] that follow the logic of this section 756 - see section 6.2. 758 Administrator abruptly replaces PA prefix 760 This is the case when the network administrator (maybe from another 761 domain) replaces prefix, for example much faster than 2 hours or 762 remaining preferred lifetime (as per section 5.5.3 of [SLAAC] on 763 router advertisement processing). The reason is probably not related 764 to networking. 765 Abrupt prefix change may be caused by improper configuration, for 766 example VLAN change at the bridge. 767 Standards do have recommendations to deprecate old prefix but do not 768 have recommendations for developers and system designers to do 769 additional checks that would mitigate human mistakes. IPv4 cannot 770 mitigate such type of mistake, IPv6 could have an advantage here. 772 We propose adding a recommendation for the additional check to 773 [SLAAC] to make sure that prefix would be deprecated - see section 774 6.3. 776 This problem could be exacerbated by the low reliability of 777 multicast delivery in a wireless environment - the only packet sent 778 (for example before VLAN change) could be lost. We propose a long- 779 term solution for this problem in section 6.6 that permits 780 synchronizing host states with a new flag in router announcements. 782 Planned router outage 784 A router could be planned to be put out of service for a link 785 (reboot, shutdown, or ceasing to be a router). 787 The primary Operation System for routers is LINUX. We would discuss 788 an example based on LINUX - other developers can find an analogy for 789 their operating system. 791 Some LINUX shutdown commands are not graceful in principle (like 792 Halt or Poweroff). It would need extraordinary efforts to send 793 messages discussed in this section before the system would be 794 stopped. It is better to restrict network administrators from such 795 tools on routers. 797 Other LINUX shutdown commands are safe (Reboot is safe for a long 798 time, Shutdown and "Init 6" have been safe). It would execute 799 shutdown scripts that would give the developer the chance to comply 800 with requirements in this section. 802 It is up to the developer how reboot and shutdown should be mapped 803 to particular OS commands in graphical user interface (GUI), command 804 line interface (CLI), or automation interface (Netconf/YANG), and 805 what particular actions should be taken. It SHOULD guarantee that 806 section 6.2.5 of [ND] with updates in section 6.4 of this document 807 properly inform hosts that the router is going out of service. 809 The same procedure SHOULD be automatically activated for cases when 810 an administrator tries manually (via CLI or GUI) or automatically 811 (via Netcong/YANG) to change Link Layer Address on this router 812 interface or disable router functionality in [ND] for this link. 814 Prefix information lost because of abrupt router outage 816 PIO could be lost because of the abrupt reload - the router may not 817 have a chance to warn hosts, but the router could receive a 818 different prefix after reload. Reasons could be (1) power outage, 819 (2) software bug, or (3) hardware bug. 821 [HomeNet Architecture] section 3.4.3 (Delegated Prefixes) has 822 already recommended using of non-volatile memory: 823 "Provisioning such persistent prefixes may imply the need for stable 824 storage on routing devices and also a method for a home user to 825 'reset' the stored prefix should a significant reconfiguration be 826 required (though ideally the home user should not be involved at 827 all)". 828 [SLAAC] section 5.7 has recommended storing acquired addresses on 829 hosts in non-volatile memory too. 830 We join these requests and propose adding similar requirements to 831 [CPE Requirements] and [SLAAC] - see section 6.5. 833 The best long-term solution is to inform the host by [ND] protocol 834 that RA has all information in one announcement. Any missing 835 information SHOULD be considered deprecated. It is possible to do it 836 with the new flag in RA - see section 6.6. 837 "Complete" flag would become useful only when implemented on both: 838 host and router. It is proposed to rely on storage improvements in 839 non-volatile memory till the "Complete" flag would be supported on 840 many nodes. 842 Prefix information lost after hardware replacement 844 Hardware fault or power outage may follow by hardware replacement. 846 Prefix storage in non-volatile memory and a "complete" flag would 847 not protect in such a situation. The new router would not have the 848 old prefix information and the "complete" flag would be sourced from 849 different LLA. 851 Initially, we need to speed up the detection of hardware replacement 852 to delete the stale hardware from the default router list of hosts. 853 It is proposed to request by RS all-routers multicast address after 854 new router detection on the link- see section 6.8. It would permit 855 to detect that old hardware is not active in 13 seconds (see section 856 6.3.7 of [ND] for timers MAX_RTR_SOLICITATIONS * 857 RTR_SOLICITATION_INTERVAL + MAX_RTR_SOLICITATION_DELAY). 13 seconds 858 is considered a short enough outage compare to hardware replacement 859 and reload. 861 Then it is proposed to detect stale prefixes at the time of router 862 deletion from the default router list. If the particular prefix is 863 not announced anymore by any active router on the default router 864 list then the prefix (and all associated addresses) should be 865 deprecated - see section 6.9. 867 Link layer address of the router should be changed 869 Sections 6.3 and 6.4 provide an additional check also in the case 870 of a link layer address change. 872 Dependency between solutions and extensions 874 It could be useful to map, for quick reference, the dependency 875 between the solutions listed in this section and standard's 876 extensions as presented in section 6. 878 Solution discussed in Corresponding extension 880 5.1. -> 6.1. 882 5.2. -> 6.2. & 6.7. 884 5.3. -> 6.3. & 6.6. 886 5.4. -> 6.4. 888 5.5. -> 6.5. & 6.6. 890 5.6. -> 6.8. & 6.9. 892 5.7. -> 6.3. & 6.4. 894 6. Extensions to the existing standards 896 The solution requires a number of standard extensions. They are 897 split into separate sections for better understanding. It is better 898 to read references from section 5. before reading this section. 900 Default router choice by host 902 * Section 6.3.6 (Default Router Selection) of [ND], add an initial 903 policy to default router selection: 905 0) For the cases when a particular implementation of ND does know 906 the source address at the time of default router selection 907 (it means that source address was chosen first), 908 then default routers that advertise the prefix for respective 909 source address SHOULD be preferred over routers that do not 910 advertise respective prefix. 912 Prefixes become dynamic 914 * We join request to [CPE Requirements] that has been proposed in 915 section 11 (General Requirements for HNCP Nodes) of [HNCP]: 917 The requirement L-13 to deprecate prefixes is applied to all 918 delegated prefixes in the network from which assignments have been 919 made on the respective interface. Furthermore, the Prefix 920 Information Options indicating deprecation MUST be included in 921 Router Advertisements for the remainder of the prefixes' respective 922 valid lifetime, but MAY be omitted after at least 2 hours have 923 passed. 925 * Add section 4.2 into [SLAAC]: 927 4.2 Dynamic Link Renumbering 929 Prefix delegation (primarily by DHCP-PD) is adopted by the industry 930 as the primary mechanism of PA address delegation mechanism in the 931 fixed and mobile broadband environments, including cases of small 932 business and branches of the big enterprises. 933 The delegated prefix is tied to dynamic link that has a considerable 934 probability to be disconnected, especially in a mobile environment. 935 The delegated prefix is losing the value if the remote site is 936 disconnected from prefix provider - this fact should be propagated 937 to all nodes on the disconnected site, including hosts. Information 938 Options indicating deprecation (multicast RA with zero preferred 939 lifetime) MUST be sent at least one time. It SHOULD be included in 940 Router Advertisements for the remainder of the prefixes' respective 941 valid lifetime but MAY be omitted after 2 hours of deprecation 942 announcements. 944 There is a high probability that connectivity to the provider would 945 be restored very soon then the prefix could be announced again to 946 all nodes on the site. 948 There is the probability that in a small period of time the same 949 problem would disconnect the site again (especially for mobile 950 uplink). Such oscillation between available and not available 951 provider could happen frequently that would flood the remote site 952 with [ND] updates. 953 Dampening mechanism MAY be implemented to suppress oscillation: 954 if the time between a particular prefix announcement and previous 955 deprecation was less than DampeningCheck then delay the next prefix 956 announcement for DampeningDelay and check the need for the prefix 957 announcement after DampeningDelay seconds. 958 It is recommended for protocol designers to implement a dampening 959 mechanism for protocols (like [HNCP]) that would be used to 960 distribute prefix delegation inside the site to relieve the majority 961 of site routers and the protocol itself from the processing of 962 oscillating messages. 964 * Section 5.1 (Node Configuration Variables) of [SLAAC], add timers: 966 DampeningCheck - the time between prefix announcement and previous 967 deprecation is checked against this value to decide about 968 dampening need. The timer should use 16bit unsigned integer 969 measured in seconds. The default value is 10 seconds. 971 DampeningDelay - the delay (penalty) for the next attempt to 972 announce the same prefix again. The timer should use 16bit 973 unsigned integer measured in seconds. The default value is 974 10 seconds. 976 These timers should be configurable like all other timers in [SLAAC] 977 section 5.1. 979 Do not forget to deprecate prefixes on renumbering 981 * Section 4.1 (Site renumbering) of [SLAAC], add at the end: 983 A network administrator SHOULD avoid the situations when renumbering 984 is done abruptly (with the time of transition that is less than the 985 preferred time for the respective prefix). Situations could happen 986 when it is not possible to archive the above-mentioned goal: (1) the 987 prefix could be withdrawn by the administrator of another domain, 988 (2) there could be the urgent need to change the prefix for reasons 989 not related to networking, (3) prefix could be invalidated after 990 some network event (example: loss of uplink that was used to receive 991 this prefix), (4) L2 connection (VLAN or VPN) could be changed 992 abruptly by mistake or due to not a proper design. 993 Prefix deprecation MUST be signaled at least one time by multicast 994 RA with Preferred Lifetime set to zero for respective PIO. It SHOULD 995 be included in RA for the remainder of the prefixes' respective 996 valid lifetime but MAY be omitted after 2 hours of deprecation 997 announcements. 999 It is recommended for developers to check and enforce this rule in 1000 router's software: if an administrator, automated system, or other 1001 protocol would try to delete a particular prefix from the link and 1002 if that prefix has the preferred lifetime bigger than zero, then the 1003 software MUST automatically generate deprecation announcements 1004 according to the rules explained above. 1006 System designer SHOULD make sure that in the case of abrupt change 1007 of logical connectivity at L2 (VLAN, VPN) new default router SHOULD 1008 deprecate stale prefixes inherited from the previous default router. 1010 Do not forget to deprecate prefixes on shutdown 1012 * Section 6.2.5 of [ND] starts from the definition of ceasing cases 1013 for the router on [ND] link. One additional reason SHOULD be added 1014 to the end of the list: 1016 - Link layer address of the interface should be changed. 1018 * Section 6.2.5 (Ceasing To Be an Advertising Interface) and 1019 Section 6.2.8 (Link Local Address Change) of [ND] already discusses 1020 requirements of proper ceasing to be [ND] router advertising 1021 interface. It has requirements to announce zero for a default router 1022 lifetime. It is proposed to add at the end of both sections: 1024 A router MUST also announce in above-mentioned announcements all 1025 previously advertised prefixes with zero Preferred LifeTime. Valid 1026 LifeTime should be not decreased from originally intended - current 1027 hosts sessions should have the possibility to be rerouted to the 1028 redundant router (if available). 1030 Store prefixes in non-volatile memory 1032 Add the same text: 1033 * [CPE Requirements], new requirement G-6 at the end of section 4.1, 1034 and 1035 * [SLAAC], at the end of section 5.7: 1037 The IPv6 router SHOULD keep in non-volatile memory all prefixes 1038 advertised on all links, including prefixes received by dynamic 1039 protocols with the reference to the respective protocol (DHCP-PD, 1040 HNCP, others). 1041 A router could experience a non-graceful reload. 1042 If another protocol would delegate any prefixes for router links 1043 then the router SHOULD immediately start announcing them in the 1044 normal way. 1045 Additionally, the router should wait until the end of convergence 1046 for the respective prefix-delegation protocol. The way to decide 1047 that convergence is finished is the responsibility of other 1048 protocols. It could be a simple timer after uplink would go to "up" 1049 or successful exchange by some protocol (like DHCP-PD). 1050 If another protocol would not delegate prefix recorded in non- 1051 volatile memory after assumed convergence is achieved, then the old 1052 prefix MUST be announced on the link at least one time by multicast 1053 RA with the zero Preferred Lifetime. It SHOULD be included in RA for 1054 the remainder of the prefixes' respective valid lifetime but MAY be 1055 omitted after 2 hours of deprecation announcements. 1057 Find lost information by "Synchronization" 1059 * Section 4.2 (RA format) of [ND], introduce new flag: 1061 0 1 2 3 1062 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type | Code | Checksum | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Cur Hop Limit |M|O| Reserved|C| Router Lifetime | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Reachable Time | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Retrans Timer | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Options ... 1073 +-+-+-+-+-+-+-+-+-+-+-+- 1075 O 1-bit "Complete configuration" flag. When set, it 1076 indicates that all configuration information has been put 1077 inside this RA. The last reserved bit has been chosen to 1078 preserve the compatibility with [Route Preferences] that 1079 already propose to use the first reserved bit. 1081 * Section 6.2.3 (RA content) of [ND], introduce new flag: 1083 - In the C flag: set if it was possible to put all configuration 1084 information into this RA. 1086 * Section 6.2.3 (RA content) of [ND], add at the end: 1088 It is recommended that all configuration information SHOULD be 1089 included in one RA (if MTU permits) for multicast and unicast 1090 distribution. If successful, then the "Complete" flag SHOULD be set 1091 to signal the possibility of synchronization with hosts. 1093 * Section 6.3.4 (RA processing) of [ND], add at the beginning: 1095 After: "the receipt of a Router Advertisement MUST NOT invalidate 1096 all information received in a previous advertisement or from another 1097 source". 1099 Add: "Except for the case when RA received with "Complete" flag set, 1100 then any information from the same router (same Link Local Address) 1101 missing in this RA SHOULD be deprecated. Information protected by 1102 timers SHOULD be put into the deprecated state. Other information 1103 SHOULD be returned to the original state: in compliance to 1104 information from other routers or to default configuration if other 1105 routers do not announce respective information." 1107 * Section 6.3.4 (RA processing) of [ND], add to the list of PIO 1108 processing options: 1110 - If the prefix is missing in RA with the "Complete" flag set, then 1111 respective addresses should be put immediately into deprecated state 1112 up to the original valid lifetime. 1114 [ND] section 9 does mention: "In order to ensure that future 1115 extensions properly coexist with current implementations, all nodes 1116 MUST silently ignore any options they do not recognize in received 1117 ND packets and continue processing the packet." 1118 There is a possibility for the gradual introduction of the 1119 "Complete" flag: 1121 o If the host is upgraded to the new functionality first, then the 1122 router would send this bit zero (according to the basic [ND]) 1123 that would not activate new functionality on the host. 1125 o If the router is upgraded to the new functionality first, then 1126 the host would not pay any attention to the flag for Reserved 1127 bits. 1129 Default router announcement rules 1131 * We join [HNCP] section 11 (General Requirements for HNCP Nodes) 1132 request to [CPE Requirements]: 1134 The generic requirements G-4 and G-5 are relaxed such that any known 1135 default router on any interface is sufficient for a router to 1136 announce itself as the default router; similarly, only the loss of 1137 all such default routers results in self-invalidation. 1139 Faster detection of the stale default router 1141 * Section 6.3.7 (sending Router Solicitations) of [ND]. 1143 The text: "When an interface becomes enabled, a host may be 1144 unwilling to wait for the next unsolicited Router Advertisement to 1145 locate default routers or learn prefixes. To obtain Router 1146 Advertisements quickly, a host SHOULD transmit up to 1147 MAX_RTR_SOLICITATIONS Router Solicitation messages, each separated 1148 by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations 1149 may be sent after any of the following events:" 1151 Should be replaced by the text: " 1153 When an interface becomes enabled or new router arrival could be the 1154 signal of another router replacement, a host may be unwilling to 1155 wait for the next unsolicited Router Advertisement to locate default 1156 routers or learn prefixes. To obtain Router Advertisements quickly, 1157 a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router 1158 Solicitation messages, each separated by at least 1159 RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent 1160 after any of the following events: 1162 - the new router is discovered from RA 1163 " 1164 The following other reasons for RS are preserved from the original 1165 text of [ND] Section 6.3.7. 1167 * Section 6.3.7 (sending Router Solicitations) of [ND]. 1169 After the text: "If a host sends MAX_RTR_SOLICITATIONS 1170 solicitations, and receives no Router Advertisements after having 1171 waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last 1172 solicitation, the host concludes that there are no routers on the 1173 link for the purpose of [ADDRCONF]." 1175 Add new text: "If a host sends MAX_RTR_SOLICITATIONS solicitations, 1176 and receives no Router Advertisements from the router already 1177 present on the default router list after having waited 1178 MAX_RTR_SOLICITATION_DELAY seconds, the host concludes that the 1179 router SHOULD be deprecated from the default router list." 1181 Clean orphaned prefixes at the default router list 1183 * Section 6.3.6 (Timing out Prefixes and Default Routers) of [ND] 1184 has: 1186 "Whenever the Lifetime of an entry in the Default Router List 1187 expires, that entry is discarded. When removing a router from the 1188 Default Router list, the node MUST update the Destination Cache in 1189 such a way that all entries using the router perform next-hop 1190 determination again rather than continue sending traffic to the 1191 (deleted) router." 1193 Add at the end: 1195 "All prefixes announced by deprecated default router SHOULD be 1196 checked on the announcement from other default routers. If any 1197 prefix is not anymore announced from any router - it SHOULD be 1198 deprecated." 1200 7. Interoperability analysis 1202 The primary motivation for the proposed changes originated from 1203 residential broadband requirements. [ND] extensions proposed in this 1204 document should not affect other environments (enterprise WAN, 1205 Campus). Moreover, some precautions proposed could block mistakes 1206 originated by humans in some corner cases in all environments. 1208 This document mostly intersects with Homenet working group documents 1209 [HomeNet Architecture], [HNCP], and [MHMP]. It was shown that it is 1210 possible to isolate [ND] in the context of Homenet to solve specific 1211 [ND] problems without any potential impact to the Homenet 1212 development and directions. 1214 [CPE Requirements] have the assumption of managing simplified 1215 topologies by manipulating routing information injection into [ND]. 1216 It has been shown in [MHMP] and in this document that it is better 1217 to signal reachability information to [ND] (reachability information 1218 to ND sounds strange) by the deprecation of delegated prefixes. We 1219 join [MHMP] request to change the approach. 1221 [Route Preferences] have been avoided as the mechanism for 1222 environments with PA address space. This is because source address 1223 is selected first. Then next hop can be chosen simply - see section 1224 5.1 for more details. 1225 [Route Preferences] could still be applicable for PI (Provider- 1226 Independent) address environments because only next hops need to be 1227 chosen properly. 1229 8. Applicability analysis 1231 Two standard extensions require changes to hosts. Hence, it would 1232 take a long time to be implemented in live networks. But workaround 1233 exists for the solution to work before then: 1235 o Absence of implementation for RA information synchronization by C 1236 flag on some hosts is not critical because we could use non- 1237 volatile memory for prefix storage. 1239 o Not being capable of excluding a router from the default router 1240 list (for the situation when it does not advertise respective 1241 prefix) is not critical, because it is needed only for the very 1242 advanced MHMP environment with traffic distribution by the policy 1243 between different PA providers. 1244 It is for the far future anyway. 1246 9. Security Considerations 1248 This document does not introduce new vulnerabilities. 1250 10. IANA Considerations 1252 This document has no any request to IANA. 1254 11. References 1256 Normative References 1258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1259 Requirement Levels", BCP 14, RFC 2119, DOI 1260 10.17487/RFC2119, March 1997, . 1263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1265 May 2017, . 1267 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1268 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1269 DOI 10.17487/RFC4861, September 2007, . 1272 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1273 Address Autoconfiguration", RFC 4862, DOI 1274 10.17487/RFC4862, September 2007, . 1277 [Flash-Renumbering] F. Gont, J. Zorz, R. Patterson, "Reaction of 1278 Stateless Address Autoconfiguration (SLAAC) to Flash- 1279 Renumbering Events", RFC 8978, March 2021. 1281 [Route Preferences] R. Draves, D. Thaler, "Default Router 1282 Preferences and More-Specific Routes", RFC 4191, DOI 1283 10.17487/RFC4191, November 2005, . 1286 [Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection 1287 by Hosts in a Multi-Prefix Network", RFC 8028, DOI 1288 10.17487/RFC8028, November 2016, . 1291 [NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor 1292 Unreachability Detection Is Too Impatient", RFC 7048, DOI 1293 10.17487/RFC7048, July 2010, . 1296 [Default Address] D. Thaler, R. Draves, A. Matsumoto, T. Chown, 1297 "Default Address Selection for Internet Protocol Version 6 1298 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1299 . 1301 [Node Requirements] T. Chown, J. Loughney, T. Winters, "IPv6 Node 1302 Requirements", RFC 8504, DOI 10.17487/RFC8504, January 1303 2019, . 1305 [CPE Requirements] Singh, H., Beebee W., Donley, C., and B. Stark, 1306 "Basic Requirements for IPv6 Customer Edge Routers", RFC 1307 7084, DOI 10.17487/RFC7084, November 2013, 1308 . 1310 [HomeNet Architecture] T. Chown, J. Arkko, A. Brandt, O. Troan, J. 1311 Weil, "IPv6 Home Networking Architecture Principles", RFC 1312 7368, DOI 10.17487/RFC7368, October 2014, 1313 . 1315 [HNCP] M. Stenberg, S. Barth, P. Pfister, "Home Networking Control 1316 Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, 1317 . 1319 [MHMP] O. Troan, D. Miles, S. Matsushima, T. Okimoto, D. Wing, "IPv6 1320 Multihoming without Network Address Translation", RFC 1321 7157, DOI 10.17487/RFC7157, March 2014, . 1324 [Policy by DHCP] A. Matsumoto, T. Fujisaki, T. Chown, "Distributing 1325 Address Selection Policy Using DHCPv6", RFC 7078 DOI 1326 10.17487/RFC7078, January 2014, . 1329 [Residential practices] Palet, J., "IPv6 Deployment Survey 1330 Residential/Household Services) How IPv6 is being 1331 deployed?", UK NOF 39, January 2018, 1332 . 1335 [SLAAC Robustness] F. Gont, J. Zorz, R. Patterson, "Improving the 1336 Robustness of Stateless Address Autoconfiguration (SLAAC) 1337 to Flash Renumbering Events", draft-ietf-6man-slaac-renum- 1338 02 (work in progress), January 2021 1340 Informative References 1342 [RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6 1343 (IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200, 1344 July 2017, . 1346 [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. 1347 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 1348 10.17487/RFC6105, February 2011, . 1351 [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router 1352 Advertisement Guard (RA-Guard)", RFC 7113, DOI 1353 10.17487/RFC7113, February 2014, . 1356 [ULA] R. Hinden, B. Haberman, "Unique Local IPv6 Unicast Addresses", 1357 RFC 4193, DOI 10.17487/RFC4193, October 2005, 1358 . 1360 12. Acknowledgments 1362 Thanks to 6man working group for problem discussion. 1364 Authors' Addresses 1366 Eduard Vasilenko 1367 Huawei Technologies 1368 17/4 Krylatskaya st, Moscow, Russia 121614 1369 Email: vasilenko.eduard@huawei.com 1371 Paolo Volpato 1372 Huawei Technologies 1373 Via Lorenteggio 240, 20147 Milan, Italy 1374 Email: paolo.volpato@huawei.com 1376 Olorunloba Olopade 1377 Virgin Media 1378 270 & 280 Bartley Way, Bartley Wood Business Park, Hook, 1379 Hampshire RG27 9UP, UK 1380 Email: Loba.Olopade@virginmedia.co.uk