idnits 2.17.00 (12 Aug 2021) /tmp/idnits55496/draft-vv-6man-nd-prefix-robustness-02.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: ---------------------------------------------------------------------------- (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 (March 4, 2022) is 71 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 1174, but not defined == Unused Reference: 'RFC8200' is defined on line 1334, but no explicit reference was found in the text == Unused Reference: 'Flash-Renumbering' is defined on line 1338, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: September 2022 Virgin Media 6 March 4, 2022 8 ND Prefix Robustness Improvements 9 draft-vv-6man-nd-prefix-robustness-02 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 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 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 ..................6 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..........................................10 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 of 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 after default router list change.27 95 7. Interoperability analysis.....................................27 96 8. Applicability analysis........................................28 97 9. Security Considerations.......................................28 98 10. IANA Considerations..........................................29 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 may lead to many days of outage for hosts. This is 134 not 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 Prefix Information Options (PIOs) in 159 Router Advertisements (RA) 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 3.1. 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 3.2. 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 3.2.1. Non-graceful reload due to unexpected events 216 A router could be reloaded abruptly for many reasons: hardware or 217 software bug, power outage, manual intervention. This last one is 218 very probable for home broadband subscribers that tend to fix every 219 problem with power recycle. 221 Usually, it does not create additional problems for [ND] and [SLAAC] 222 because the same PIO information would be advertised by the router 223 in RA messages after each reload. In such cases, a Home Gateway 224 would initialize its Ethernet and WiFI connections, clearing all 225 stale information on directly connected hosts. 227 It should not create problems for proper home network design where 228 all CPEs are routers - see [HomeNet Architecture]. The delegated 229 prefix would not be changed in the case of subtended CPE reload. 230 Prefix change in the case of upstream CPE reload should be properly 231 discontinued by subtended CPE. There is the need for a special 232 protocol for prefix distribution that is out of the scope of this 233 document - see [HNCP]. 235 For architecture #2 implemented in home environments, there is a 236 corner case when Home Gateway's abrupt reload would not be visible 237 to hosts connected to subtended "bridged" CPE. If it would coincide 238 with the situation when a different prefix would be delegated from 239 Carrier (at 37% probability according to [Residential practices]), 240 it would lead to the situation that hosts would receive a new prefix 241 without deprecation of the previous one. Hosts do not have any 242 standard mechanism to choose only the new prefix for communication. 243 That would lead to a connectivity problem. 245 How long a non-preferred prefix would be kept in a stale state on 246 the host is not important (default AdvValidLifetime is 30 days in 247 section 6.2.1 of [ND]), because according to [Default Address] 248 section 5 rule#3, it should have a lower priority to be chosen. 249 [SLAAC] section 5.5.4 is another good reference highlighting that 250 address should be avoided after it would reach the deprecated 251 status. 252 How long an address would stay in the preferred state is important. 253 [ND] instructs hosts to prefer certain prefix for 7 days - see 254 default AdvPreferredLifetime in section 6.2.1. 255 It is not realistic for the subscriber to wait for 7 days. 256 It practically means that the subscriber in this corner case would 257 have a few options to fix the problem: (1) reload all hosts, or (2) 258 reconnect the physical link of every host, or (3) reload subtended 259 bridge, or (4) manually delete the prefix on the hosts to clear 260 stale information. 262 3.2.2. Graceful reload without precautions 264 Specifically this scenario may happen when developers don't apply 265 precautions in case previous prefixes are not deprecated. It may 266 happen in both architectures. 268 The router could be reloaded by graceful procedure (reboot or 269 shutdown that would use "init 6" in Unix). It is still possible that 270 software would not send RA with prefix Preferred Lifetime zero to 271 inform hosts about prefix deprecation. This practice prevails 272 because IPv4's centralized address assignments by DHCP does not need 273 similar precautions. 275 Again, like in the previous section, it would not create a problem 276 in the majority of the cases for directly connected hosts 277 (architecture #1) because link layer would be reinitialized too. The 278 same corner case (architecture #2) would lead to the same result: a 279 connectivity problem that could be resolved only by 4 types of 280 manual intervention mentioned in the previous section. 282 3.2.3. Abrupt hardware replacement without the possibility for graceful 283 prefix deprecation 285 Such type of an outage is again may happen only for architecture #2. 286 It would lead to up to 30 minutes (including time for hardware 287 replacement) outage in all cases (to detect missing router) and up 288 to 1 week additional outage if a different prefix would be announced 289 after the hardware replacement. 291 The hardware could fail or be replaced with an abrupt power 292 disconnect. The latter is very probable for the home environment. 293 Graceful notification of hosts may not happen. 295 The new hardware may have a different link layer address and a 296 different link local address as a result. The router would look like 297 a new one on the link. Any communication with it could not be the 298 reason to deprecate announcements made early by the router perceived 299 as a different one. 301 [ND] section 6.2.1 has recommended the AdvDefaultLifetime as 302 3*MaxRtrAdvInterval. Hosts would send traffic to a non-existent 303 router for up to 30 minutes. 305 According to section 4.2 of [ND] "Router Lifetime" is related only 306 to router default status. PIO announced early may be preferred up to 307 7 days according to AdvPreferredLifetime in section 6.2.1 of [ND] 308 even after the router default status is deprecated. The probability 309 for such a situation is the same low as discussed in section 3.2.1. 310 because a different prefix should be announced after hardware reload 311 and a switch should be present between the host and the router. The 312 same corner case would lead to the same result: a connectivity 313 problem that could be resolved only by 4 types of manual 314 intervention mentioned in section 3.2.1. . 316 3.2.4. Non-graceful configuration change 318 This situation may happen due to abrupt prefix change on the router 319 (in both architectures) or VLAN change on the switch (it may happen 320 in architecture #2). 322 Router configuration could be changed manually, by automation tools, 323 or by protocols (for example, prefix distribution). 325 Additionally for architecture #2, L2 domain could be abruptly 326 changed by configuration (for example, VLAN change from "quarantine" 327 to "production" without any chance for the router to send a 328 message). 330 It could lead to the situation that prefix would change abruptly, 331 without any notification to hosts about the necessity to deprecate 332 the previous prefix. Hosts should be notified by prefix announcement 333 with Preferred Lifetime set to zero. 335 It should not happen for residential CPE because [CPE Requirements] 336 section 4.3 requirement L-13 clearly instructs: "If the delegated 337 prefix changes, i.e., the current prefix is replaced with a new 338 prefix without any overlapping period of time, then the IPv6 CE 339 router MUST immediately advertise the old prefix with a Preferred 340 Lifetime of zero". 342 But it is perfectly possible for other environments (except 343 residential CPEs) because other routers are not required to do the 344 same: [Node Requirements] does not clarify the exact router behavior 345 in the case of abrupt prefix change. [SLAAC] does not have any 346 recommendations either. 348 3.2.5. An uplink breaks connectivity without a relevant notification 349 to the connected hosts 351 It may happen in both architectures #1 and #2. 353 A router could lose uplink. The probability for such an event is 354 much bigger for a mobile uplink (modem). It would invalidate the 355 possibility to use a PA prefix advertised from this carrier even in 356 the case that another carrier uplink is available on this or 357 redundant router (connectivity to the Internet is not lost). Some 358 mechanism is needed to inform hosts not to use address space from 359 the disconnected carrier because another carrier would filter it out 360 by anti-spoofing security protection. 362 The multi-homing multi-prefix PA environment has been properly 363 explained in [MHMP]. The discussion of how traffic should be source- 364 routed by routers in [MHMP] environment is not relevant to our [ND] 365 discussion. Unfortunately, an improper address used as a source 366 would cause a traffic drop as soon as traffic gets to the different 367 carrier. 369 [Default Address] section 5 (source address selection) rule 5 (for 370 different interfaces on the host) and rule 5.5 (for the same 371 interface) partially prepare hosts for such situation: "Prefer 372 addresses in a prefix advertised by the next-hop. If SA or SA's 373 prefix is assigned by the selected next-hop that will be used to 374 send to D [...] then prefer SA". This algorithm has an assumption 375 that the source address should be chosen after the next hop. 377 Unfortunately, the rules mentioned above in [Default Address] 378 section 5 would work only if the default router would cease to be 379 default after it loses route to its carrier. It would work only in 380 simplified topology where all hosts connect by L2 to different CPEs, 381 each leading to its separate carrier prefix. It could be called a 382 "common-link environment for all hosts and routers". It is not 383 possible in practice because hosts on the most popular link layer 384 technology (WiFi) are rooted to only one CPE (with AP inside) - they 385 would not switch automatically to different CPE where the Internet 386 connectivity may be still available. 388 [CPE Requirements] have G-3/4/5 specifically for this simplified 389 multi-homing residential design. It recommends announcing Router 390 Lifetime as zero on LAN if CPE does not have "default router from 391 the uplink" - it would push the host to use another source address 392 by the mentioned above source address selection algorithm. 394 It is not explained in [CPE Requirements] what should happen with PA 395 delegated prefix after the respective uplink is disconnected. 396 Probably, this is because it was not needed to deprecate stale 397 prefix for the above mentioned mechanism (based on default router 398 withdrawal) to work. 400 The local residential network could be left without any default 401 router as a result of using the above mechanism - it is especially 402 probable in the single CPE environment. Hence, [CPE Requirements] 403 promotes [ULA] addresses for local connectivity. Default router 404 functionality is returned specifically for [ULA] addresses by 405 requirement L-3: use "Route Information Option" from [Route 406 Preferences]. It needs hosts' participation in routing through the 407 RIO option. 409 Unfortunately, this long chain of fixes explained above is strictly 410 optimized for the environment "common-link for all hosts and 411 routers". It is not the case for single WiFi inside any CPE or other 412 topologies. 414 Neither [ND] nor [SLAAC] instruct the router what to do when the PA 415 delegated prefix is withdrawn abruptly. 417 [Multi-Homing] section 3 has a good discussion about the proper 418 relationship between default routers and prefixes advertised by 419 respective routers in a stable situation. This would be discussed in 420 more details in section 5.1. . [Multi-Homing] does not discuss what 421 to do in the situation when the router is available, but some 422 uplinks (with delegated prefixes) are lost. 424 [MHMP] discusses the problem in deep detail with two tools proposed 425 to regulate [ND] behavior: [Policy by DHCP] to change [Default 426 Address] algorithm and [Route Preferences] to inform about 427 appropriate exit points. There are more details later in section 428 5.1. 430 4. Root cause analysis 432 Let's further analyze to be sure that all corner cases are found. 434 It is assumed in all discussions below that [RA-Guard] is 435 implemented, and all messages are from routers under legitimate 436 administrative control. Security issues are considered as resolved 437 by [RA-Guard], and possibly with extensions in [RA-Guard+]. 439 DHCP is almost as vulnerable as SLAAC for cases found below. DHCP's 440 typical lease time (hours) is shorter than SLAAC's prefix lifetime 441 (days), but is too long for users to accept self-repairing time. 442 Root cause analysis below applies to all possible environments: 443 DHCP, SLAAC, and mixed. 445 4.1. What to protect 447 [ND] Router Advertisements deliver configuration information to 448 hosts. Such information could become inaccurate in two different 449 periods of time: 451 a) "Recoverable". Time is needed for some process to finish and 452 update information (example: router reload or uplink re-connect). 454 b) "Non-recoverable". Time, dependent on some timer expiration 455 (example: complete loss of prefix or default router). 457 A careful look at the information distributed by RA would give us 458 the understanding that the most problematic is the information that 459 is already protected by deprecation timers: Prefix Information 460 Option and Default Router. Section 3 discusses that the handling of 461 this information is still susceptible to recoverable and non- 462 recoverable periods of inaccuracy. 464 For example, in the case of abrupt router reload described in 465 sections 3.2.1. -3.2.3. , the recoverable part is the time spent by 466 router and hosts to update their cache after the router reload. The 467 non-recoverable part is related to the setting of the 468 AdvPreferredLifetime timer which would probably force a user to 469 solve the issue with manual intervention. 471 The next problematic case is the abrupt change of source link-layer 472 address. This problem is not discovered yet in production because it 473 has a low probability. Indeed, a router with a different link-layer 474 address would be treated as a new router, the old router would just 475 disappear from the link. It would affect primarily default router 476 information because all other information should be immediately re- 477 advertised from the new link layer address. Section 6.2.8 of [ND] 478 already discusses how to properly deprecate the default router 479 status of the old link layer address, but no recommendation is given 480 in [ND] for prefix deprecation in this situation. A corner case is 481 possible that software would not treat the new virtual interface as 482 identical concerning the prefix information that should be 483 announced. Different prefixes may be announced. Some additional 484 precautions are needed. 486 Other information in RA (Hop Limit, MTU, DHCP flags, Reachable 487 timer, and Retransmit timer) are not so sensitive because (1) it is 488 typically static and (2) it does not affect connectivity for 489 respective parameters change in the wide range. 491 Flag "A" in PIO deserves special attention. It could be cleared 492 abruptly (signaling that hosts should not use this prefix for 493 [SLAAC] anymore). That should not create any problem, because the 494 prefix is still available from a respected PA provider - traffic 495 could be routed to the global Internet. Therefore, it is not vitally 496 important for the host to immediately deprecate the address from 497 this prefix. 498 A similar situation is with flag "M" in RA: DHCP address should be 499 deprecated. It should not create a connectivity problem because 500 prefixes could be routed to the global Internet. 502 4.2. Where to protect 504 [ND] is the protocol for first-hop connection between host and 505 router. It is designed for one link only. One link could have more 506 than one router. 508 It is assumed below that a more complex topology (many other 509 routers) is shielded from this link by some other protocol that 510 would deliver all necessary information to those routers. 511 [HomeNet Architecture] discusses many types of information that 512 should be distributed to every home router. Let's focus on delegated 513 prefixes for our discussion. 514 The number of uplinks on every router is not important, as long as 515 proper information about prefixes is up to date on the router. 517 Hence, all our topologies could be simplified into the following 518 scenarios: 520 I. L2 device (switch, WiFi AP) and L3 device (router) are in the 521 same device (sharing the fate for power, reboot) (refer to 522 architecture #1 in section 3.1. ). 524 II. Separate L2 device (probably a switch) and an arbitrary number of 525 L3 devices (routers) are connected to the same IPv6 link (refer 526 to architecture #2 in section 3.1. ). 528 4.3. When to protect: technology scenarios 530 Let's reorder scenarios discussed in section 3. in the way that it 531 would be better to map to the technology modifications and account 532 for some corner cases found in root cause analysis: 534 1. Proper prefix usage for Multi-Homing Multi-Prefix environment. 535 Hosts should be capable of choosing in a coordinated way 536 (1) a source address (from proper PA prefix) and (2) a next hop: 538 A.1. In a normal situation: all providers and prefixes are 539 available 541 A.2. In a faulty situation: one provider is not reachable, but some 542 hosts and links on the routed path to this provider may still be 543 reachable 545 A.3. In the case when an administrator abruptly replaces delegated 546 prefix 548 2. Proper prefix usage for the case of router outage that: 550 A.4. Planned for this interface 551 (reboot, shutdown, or ceasing to be a router) 553 A.5. Abrupt (power outage, software or hardware bug) 555 A.6. Abrupt (power outage, hardware fault) with hardware 556 replacement 558 3. Proper prefix usage for the case of link layer address of the 559 router. 561 These cases are discussed from section 5.1. to section 5.6. 563 There is no big difference for [ND] between ULA and GUA at the 564 considered link because both could be disjoined at any routed hop 565 upstream. It would need the same invalidation mechanisms on the 566 link. ULA could be invalidated too for the case that ULA spans many 567 sites in a big company. The residential network would probably have 568 a separate ULA for every household that would decrease the 569 probability of ULA prefixes invalidation. It is the responsibility 570 of another protocol (for example, [HNCP]) to decide when ULA should 571 be invalidated, if ever. 573 5. Solutions 575 Let's look at the solutions for scenarios listed in section 4.3. 577 5.1. Multi-homing multi-prefix (MHMP) environment 579 Let's consider here host capability to choose a proper PA prefix and 580 next hop router in a stable multi-homing multi-prefix (MHMP) 581 environment. 583 The complex MHMP situation is properly discussed in [MHMP] section 584 3.1 - it is critical to read it to understand the rest of this 585 section. Our discussion is restricted to [ND] protocol only (one 586 link) - it would cut the number of topologies discussed in section 587 4.2. MHMP may need additional complex routing interactions that are 588 out of the scope of this document. 590 It is possible to introduce one additional classification to clearly 591 separate what it is possible to implement now from what needs 592 additional standardization efforts: 594 1. Case "equal prefixes": Announced prefixes are fully equal by 595 scope and value, all resources interested for hosts could be 596 reachable through any announced PA prefix; additionally, traffic 597 distribution between carriers could be round-robin (no any 598 traffic engineering or policing). 600 2. Case "non-equal prefixes": Announced prefixes are not equal 601 because (1) some resources could be accessed only through a 602 particular prefix (for example walled garden of one carrier) or 603 (2) it is desirable to have some policy for traffic distribution 604 between PA prefixes (cost of traffic, delay, packet loss, jitter, 605 proportional load). 607 There are two reminders before the discussion of the above cases: 609 o [ND] section 6.3.6 recommends next hop choice between default 610 routers in a round-robin style. Traffic policy or even 611 reachability of particular resources through a particular default 612 router is not considered at the [ND] level. 614 o [Default Address] section 7 assumes that source and destination 615 address selection should happen after the next hop (or interface) 616 choice by [ND] or routing, source address is chosen after this. 618 Case "equal prefixes" does not create any requirement on what prefix 619 should be used for the source address. It is only needed that the 620 source address would be chosen to be compatible with the next hop 621 that should be in the direction of the respective carrier. 622 No problem is possible for the topology with only one router on the 623 link. The router itself may need source routing to choose next hop 624 properly but it is out of the scope of ND protocol and this 625 document. 626 Host on a multi-homing link would better be compliant to [Default 627 Address] section 5 (source address selection) rule 5 (for different 628 interfaces on the host) or rule 5.5 (for different next hops on the 629 same interface). It would help to properly choose a source address 630 compliant to the next hop chosen first. Moreover, if the source 631 address would be chosen wrongly then it is still possible to reroute 632 the packet later by source routing. 633 Hence, it is possible to satisfy the "equal prefixes" case on the 634 current level of standardization developed. 636 Case "non-equal prefixes" is more complicated. It would be too late 637 to try to solve this problem on a router, because the wrong source 638 address may be already chosen by the host - it would not be possible 639 to contact the appropriate resource in the "walled garden". Only NAT 640 could be left as an option, but that is not a valid choice for IPv6. 642 There are 2 methods to resolve the case of "non-equal prefixes": 644 1. The same policies could be formatted differently and fed to the 645 host by two mechanisms: 1) "Routing Information Options" of [Route 646 Preferences] and 2) [Policy by DHCP] to modify policies in 647 [Default Address] selection algorithm. Then current priority of 648 mechanisms could be preserved the same: initially [ND] or routing 649 would choose the next hop, then [Default Address] would choose a 650 source address (and destination if multiple answers from DNS are 651 available). It is the method that is assumed in [MHMP]. 652 2. Alternatively, policies could be supplied only by [Policy by DHCP] 653 to [Default Address] selection algorithm. [Default Address] 654 discusses potential capability in section 7 to reverse algorithm's 655 order: source address may be chosen first, only then to choose 656 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 for the default round-robin distribution between available 660 routers that specified in [ND]. [ND] extension is needed for this 661 method for the host to prioritize default routers that have 662 announced prefixes used for the source address of the considered 663 flow. 664 It is this method that is assumed in [Multi-Homing] section 3.2. 665 This document is different in that the same rules are formulated 666 not as the general advice, but as the particular extension to [ND] 667 - see section 6.1 of this document. 669 The second method has the advantage that there is no need to 670 download RIO policies by [Route Preferences]. It would simplify the 671 implementation of the MHMP environment. 672 Only the second method is universal and extendable because some 673 policies may not be translated as RIO of [Route Preferences]. 674 For example, dynamic policies (packet loss, delay, and jitter) could 675 be measured on hosts. Hence, the decision about source address and 676 next hop should be local. 678 5.2. A provider is not reachable in MHMP environment 680 Let's assume the fault situation when one provider is not reachable 681 in the [MHMP] environment. A prefix may be very dynamic for a few 682 reasons. It could be received from some protocols (DHCP-PD, HNCP). 683 The prefix could become invalid (at least for the global Internet 684 connectivity) as a result of the abrupt link loss in the upstream 685 direction to the carrier that distributed this prefix. 687 Additionally, consider the more complicated case when some hosts on 688 the upstream routed path to this provider may still be reachable 689 using a particular prefix but Internet connectivity is broken later. 691 Let's consider the last problem. Because Internet connectivity is 692 lost for this prefix, it should be announced to hosts by zero 693 Preferred Lifetime. [Route Preferences] gives the possibility to 694 inform hosts that particular a prefix (RIO) is still available on- 695 site but it would be an automation challenge to dynamically 696 calculate and announce prefix. Additionally, [Route Preferences] 697 should be supported by hosts. 698 In general, it is not a good idea to involve [ND] in routing. Hence, 699 it is better to support on-site connectivity by PI GUA or ULA that 700 may not be invalidated. There are many reasons to promote [ULA] for 701 internal site connectivity: (1) hosts may not have GUA address at 702 all without initial connection to the provider, (2) PA addresses 703 would be invalidated in 30 days of disconnect anyway, (3) it is not 704 a good idea to use addresses from PA pool that is disconnected from 705 global Internet - hosts may have a better option to get global 706 reachability. ULA has better security (open transport ports that are 707 not accessible from the Internet) which is an additional bonus. 708 It is effectively the request to join current [CPE Requirements] and 709 [HomeNet Architecture] requirements in sections 2.2, 2.4, 3.4.2 that 710 subscriber's network should have local ULA addresses. 712 Prefix deprecation should be done by RA with zero Lifetime for this 713 prefix. It will put the prefix on hosts to the deprecated status 714 that according to many standards ([ND], [SLAAC], and [Default 715 Address]) would prioritize other addresses. Global communication 716 would be disrupted for this prefix anyway. Local communication for 717 deprecated addresses would continue till normal resolution because 718 the default Valid Lifetime is 30 days. Moreover, if it would happen 719 that this delegated prefix was the only one in the local network (no 720 [ULA] for the same reason), then new sessions would be opened on 721 deprecated prefix because it is the only address available. 722 If connectivity would be re-established and the same prefix would be 723 delegated to the link - it would be announced again with proper 724 preferred lifetime. If a different prefix could be delegated by the 725 PA provider, then the old prefix would stay in deprecated status. 726 It is an advantage for the host that would know about global 727 reachability on this prefix (by deprecated status) because the host 728 may use other means for communication at that time. 730 Such dynamic treatment of prefixes may have the danger of [ND] 731 messages flood if the link on the path to PA provider would be 732 oscillating. 733 [HNCP] section 1.1 states: "it is desirable for ISPs to provide 734 large enough valid and preferred lifetimes to avoid unnecessary HNCP 735 state churn in homes". 736 It makes sense to introduce dampening for the rate of prefix 737 announcements. 739 Such conceptual change in the treatment of prefixes would not affect 740 current enterprise installations where prefixes are static. 742 It is important to mention again that it is the responsibility of 743 the respective protocol (that has delivered prefix to the considered 744 router) to inform the router that prefix is not routed anymore to 745 the respective carrier. It is easy to do it in the simplified 746 topology when the only router could correlate uplink status with the 747 DHCP-PD prefix delegated early. Some additional protocols like 748 [HNCP] are needed for a more complex topology. 750 There is nothing in [ND] or [SLAAC] that prevents us from treating 751 prefixes as something more dynamic than "renumbering" to reflect the 752 dynamic path status to the PA provider. Section 6.2. proposes 753 extensions to [CPE Requirements] and [SLAAC] that follow the logic 754 of this section. 756 5.3. Administrator abruptly replaces PA prefix 758 This is the case when the network administrator (maybe from another 759 domain) replaces prefix much faster than 2 hours or the remaining 760 preferred lifetime (as per section 5.5.3 of [SLAAC] on router 761 advertisement processing). The reason for abrupt replacement is 762 probably not related to networking. 763 Abrupt prefix change may be caused by improper configuration, for 764 example, VLAN change at the switch. 765 Standards recommend deprecating old prefixes but do not recommend 766 for developers and system designers to additionally check abrupt 767 configuration changes to mitigate human mistakes. IPv4 cannot 768 mitigate such type of mistake, IPv6 has an advantage here. 770 Section 6.3. proposes a recommendation for the additional check to 771 make sure that prefix would be deprecated. 773 This problem could be exacerbated by the low reliability of 774 multicast delivery in a wireless environment - the only packet sent 775 (for example before VLAN change) could be lost. A long-term solution 776 for this problem is proposed in section 6.6 that permits 777 synchronizing host states with a new flag in router announcements. 779 5.4. Planned router outage 781 A router could be planned to be put out of service for a link 782 (reboot, shutdown, or ceasing to be a router). 784 The primary Operating System for routers is LINUX. The following 785 discussion is based on LINUX as an example - other developers can 786 find an analogy for their operating system. 788 Some LINUX shutdown commands are not graceful in principle (like 789 Halt or Poweroff). It would need extraordinary efforts to send 790 messages discussed in this section before the system would be 791 stopped. It is better to restrict network administrators from such 792 tools on routers. 794 Other LINUX shutdown commands are safe (Reboot is safe for a long 795 time, Shutdown and "Init 6" have been safe). It would execute 796 shutdown scripts that would give the developer the chance to comply 797 with requirements in this section. 799 It is up to the developer how reboot and shutdown should be mapped 800 to particular OS commands in graphical user interface (GUI), command 801 line interface (CLI), or automation interface (Netconf/YANG), and 802 what particular actions should be taken. It SHOULD guarantee that 803 section 6.2.5 of [ND] with updates in section 6.4 of this document 804 properly inform hosts that the router is going out of service. 806 The same procedure SHOULD be automatically activated for cases when 807 an administrator tries manually (via CLI or GUI) or automatically 808 (via Netcong/YANG/Other) to change Link Layer Address on this router 809 interface or disable router functionality in [ND] for this link. 811 5.5. Prefix information lost because of abrupt router outage 813 PIO could be lost because of the abrupt reload - the router may not 814 have a chance to warn hosts, but the router could receive a 815 different prefix after reload. Reasons could be (1) power outage, 816 (2) software bug, or (3) hardware problem. 818 [HomeNet Architecture] section 3.4.3 (Delegated Prefixes) has 819 already recommended usage of non-volatile memory: 820 "Provisioning such persistent prefixes may imply the need for stable 821 storage on routing devices and also a method for a home user to 822 'reset' the stored prefix should a significant reconfiguration be 823 required (though ideally the home user should not be involved at 824 all)". 825 [SLAAC] section 5.7 has recommended storing acquired addresses on 826 hosts in non-volatile memory too. 827 This document joins these requests and propose adding similar 828 requirements to [CPE Requirements] and [SLAAC] - see section 6.5. 830 The best long-term solution is to inform the host by [ND] protocol 831 that RA has all information in one announcement. Any missing 832 information SHOULD be considered deprecated. It is possible to do it 833 with the new flag in RA - see section 6.6. 834 "Complete" flag would become useful only when implemented on both: 835 host and router. It is proposed to rely on storage improvements in 836 non-volatile memory till the "Complete" flag would be supported on 837 many hosts. 839 5.6. Prefix information lost after hardware replacement 841 Hardware fault or power outage may follow by hardware replacement. 843 Prefix storage in non-volatile memory and a "complete" flag would 844 not protect in such a situation. The new router would not have the 845 old prefix information and the "complete" flag would be sourced from 846 a different LLA. 848 Initially, it would be good to speed up the detection of hardware 849 replacement to delete the stale hardware from the default router 850 list of hosts. It is proposed to request all routers availability by 851 RS all-routers multicast address after new router detection on the 852 link- see section 6.8. It would permit to detect that old hardware 853 is not active in 13 seconds (see section 6.3.7 of [ND] for timers 854 MAX_RTR_SOLICITATIONS * RTR_SOLICITATION_INTERVAL + 855 MAX_RTR_SOLICITATION_DELAY). 13 seconds is considered a short enough 856 outage compare to hardware replacement and reload. 858 Then it is proposed to detect stale prefixes at the event of the 859 respective router deletion from the default router list. If the 860 particular prefix is not announced anymore by any active router on 861 the default router list then the prefix (and all associated 862 addresses) should be deprecated - see section 6.9. 864 5.7. Link layer address of the router should be changed 866 Sections 6.3 and 6.4 provide an additional check also in the case 867 of a link layer address change. Hence, additionally resolve LLA 868 change case. 870 5.8. Dependency between solutions and extensions 872 It could be useful to map, for quick reference, the dependency 873 between the solutions listed in this section and standard's 874 extensions as presented in section 6. 876 Solution discussed in Corresponding extension 878 5.1. -> 6.1. 880 5.2. -> 6.2. & 6.7. 882 5.3. -> 6.3. & 6.6. 884 5.4. -> 6.4. 886 5.5. -> 6.5. & 6.6. 888 5.6. -> 6.8. & 6.9. 890 5.7. -> 6.3. & 6.4. 892 6. Extensions of the existing standards 894 The solution requires a number of standard extensions. They are 895 split into separate sections for better understanding. It is better 896 to read references from section 5. before reading this section, see 897 section 5.8. for cross-reference. 899 6.1. Default router choice by host 901 * Section 6.3.6 (Default Router Selection) of [ND], add an initial 902 policy to default router selection: 904 0) For the cases when a particular implementation of ND does know 905 the source address at the time of default router selection 906 (it means that source address was chosen first), 907 then default routers that advertise the prefix for respective 908 source address SHOULD be preferred over routers that do not 909 advertise respective prefix. 911 6.2. Prefixes become dynamic 913 * This document joins the request to [CPE Requirements] that has 914 been proposed in section 11 (General Requirements for HNCP Nodes) of 915 [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 in the fixed and 931 mobile broadband environments, including cases of small business and 932 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 6.3. 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 6.4. 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 not be decreased from originally intended - current 1027 hosts sessions should have the possibility to be rerouted to the 1028 redundant router (if available). 1030 6.5. 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 for how to 1047 decide that convergence is finished is the responsibility of the 1048 respective protocol design. It could be a simple timer after uplink 1049 would go to "up" or successful exchange by some protocol (like DHCP- 1050 PD). 1051 If another protocol would not delegate prefix recorded in non- 1052 volatile memory after assumed convergence is achieved, then the old 1053 prefix MUST be announced on the link at least one time by multicast 1054 RA with the zero Preferred Lifetime. It SHOULD be included in RA for 1055 the remainder of the prefixes' respective valid lifetime but MAY be 1056 omitted after 2 hours of deprecation announcements. 1058 6.6. Find lost information by "Synchronization" 1060 * Section 4.2 (RA format) of [ND], introduce new flag: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Type | Code | Checksum | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Cur Hop Limit |M|O| Reserved|C| Router Lifetime | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Reachable Time | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Retrans Timer | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Options ... 1074 +-+-+-+-+-+-+-+-+-+-+-+- 1076 O 1-bit "Complete configuration" flag. When set, it 1077 indicates that all configuration information has been put 1078 inside this RA. The last reserved bit has been chosen to 1079 preserve the compatibility with [Route Preferences] that 1080 already propose to use the first reserved bit. 1082 * Section 6.2.3 (RA content) of [ND], introduce new flag: 1084 - In the C flag: set if it was possible to put all configuration 1085 information into this RA. 1087 * Section 6.2.3 (RA content) of [ND], add at the end: 1089 It is recommended that all configuration information SHOULD be 1090 included in one RA (if MTU permits) for multicast and unicast 1091 distribution. If successful, then the "Complete" flag SHOULD be set 1092 to signal the possibility of synchronization with hosts. 1094 * Section 6.3.4 (RA processing) of [ND], add at the beginning: 1096 After: "the receipt of a Router Advertisement MUST NOT invalidate 1097 all information received in a previous advertisement or from another 1098 source". 1100 Add: "Except for the case when RA received with "Complete" flag set, 1101 then any information from the same router (same Link Local Address) 1102 missing in this RA SHOULD be deprecated. Information protected by 1103 timers SHOULD be put into the deprecated state. Other information 1104 SHOULD be returned to the original state: in compliance to 1105 information from other routers or to default configuration if other 1106 routers do not announce respected information." 1108 * Section 6.3.4 (RA processing) of [ND], add to the list of PIO 1109 processing options: 1111 - If the prefix is missing in RA with the "Complete" flag set, then 1112 respective addresses should be put immediately into deprecated state 1113 up to the original valid lifetime. 1115 [ND] section 9 mentions: "In order to ensure that future extensions 1116 properly coexist with current implementations, all nodes MUST 1117 silently ignore any options they do not recognize in received ND 1118 packets and continue processing the packet." 1120 There is a possibility for the gradual introduction of the 1121 "Complete" flag: 1123 o If the host is upgraded to the new functionality first, then the 1124 router would send this bit zero (according to the basic [ND]) 1125 that would not activate new functionality on the host. 1127 o If the router is upgraded to the new functionality first, then 1128 the host would not pay attention to the flag for Reserved bits. 1130 6.7. Default router announcement rules 1132 * This document joins [HNCP] section 11 (General Requirements for 1133 HNCP Nodes) request to [CPE Requirements]: 1135 The generic requirements G-4 and G-5 are relaxed such that any known 1136 default router on any interface is sufficient for a router to 1137 announce itself as the default router; similarly, only the loss of 1138 all such default routers results in self-invalidation. 1140 6.8. Faster detection of the stale default router 1142 * Section 6.3.7 (sending Router Solicitations) of [ND]. 1144 The text: "When an interface becomes enabled, a host may be 1145 unwilling to wait for the next unsolicited Router Advertisement to 1146 locate default routers or learn prefixes. To obtain Router 1147 Advertisements quickly, a host SHOULD transmit up to 1148 MAX_RTR_SOLICITATIONS Router Solicitation messages, each separated 1149 by at least RTR_SOLICITATION_INTERVAL seconds. Router Solicitations 1150 may be sent after any of the following events:" 1152 Should be replaced by the text: " 1154 Interface enablement or new router arrival could be the signal of 1155 router replacement, a host may be unwilling to wait for the next 1156 unsolicited Router Advertisement to locate and invalidate default 1157 routers or learn prefixes. To obtain Router Advertisements quickly, 1158 a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router 1159 Solicitation messages, each separated by at least 1160 RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent 1161 after any of the following events: 1163 - the new router is discovered from RA 1165 - . . . 1166 " 1168 * Section 6.3.7 (sending Router Solicitations) of [ND]. 1170 After the text: "If a host sends MAX_RTR_SOLICITATIONS 1171 solicitations, and receives no Router Advertisements after having 1172 waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last 1173 solicitation, the host concludes that there are no routers on the 1174 link for the purpose of [ADDRCONF]." 1176 Add new text: "If a host sends MAX_RTR_SOLICITATIONS solicitations, 1177 and receives no Router Advertisements from the router already 1178 present on the default router list after having waited 1179 MAX_RTR_SOLICITATION_DELAY seconds, the host concludes that the 1180 router SHOULD be deprecated from the default router list." 1182 6.9. Clean orphaned prefixes after default router list change 1184 * Section 6.3.6 (Timing out Prefixes and Default Routers) of [ND] 1185 has: 1187 "Whenever the Lifetime of an entry in the Default Router List 1188 expires, that entry is discarded. When removing a router from the 1189 Default Router list, the node MUST update the Destination Cache in 1190 such a way that all entries using the router perform next-hop 1191 determination again rather than continue sending traffic to the 1192 (deleted) router." 1194 Add at the end: 1196 "All prefixes announced by deprecated default router SHOULD be 1197 checked on the announcement from other default routers. If any 1198 prefix is not anymore announced from any router - it SHOULD be 1199 deprecated." 1201 7. Interoperability analysis 1203 The primary motivation for the proposed changes originated from 1204 residential broadband requirements. [ND] extensions proposed in this 1205 document should not affect other environments (enterprise WAN, 1206 Campus). Moreover, some precautions proposed could block mistakes 1207 originated by humans in some corner cases in all environments. 1209 This document mostly intersects with Homenet working group documents 1210 [HomeNet Architecture], [HNCP], and [MHMP]. It was shown that it is 1211 possible to isolate [ND] in the context of Homenet to solve specific 1212 [ND] problems without any potential impact to the Homenet 1213 development and directions. 1215 [CPE Requirements] have the assumption of managing simplified 1216 topologies by manipulating routing information injection into [ND]. 1217 It has been shown in [MHMP] and in this document that it is better 1218 to signal reachability information to [ND] (reachability information 1219 to ND sounds strange) by the deprecation of delegated prefixes. This 1220 document joins [MHMP] request to change the approach. 1222 [Route Preferences] have been avoided as the mechanism for 1223 environments with PA address space because source address is 1224 selected first. Then next hop choice can be simplified - see section 1225 5.1 for more details. 1226 [Route Preferences] could still be applicable for PI (Provider- 1227 Independent) address environments because only next hops need to be 1228 chosen properly. 1230 8. Applicability analysis 1232 Two standard extensions require changes to hosts. Hence, it would 1233 take a long time to be implemented in live networks. But workaround 1234 exists for the solution to work before it would happen: 1236 o Absence of implementation for RA information synchronization by C 1237 flag on some hosts is not critical because router could use non- 1238 volatile memory for prefix storage. 1240 o Not being capable of excluding a router from the default router 1241 list (for the situation when it does not advertise respective 1242 prefix) is not critical, because it is needed only for the very 1243 advanced MHMP environment with traffic distribution by the policy 1244 between different PA providers. 1245 It is for the far future anyway. 1247 9. Security Considerations 1249 This document does not introduce new vulnerabilities. 1251 10. IANA Considerations 1253 This document has no any request to IANA. 1255 11. References 1257 11.1. Normative References 1259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1260 Requirement Levels", BCP 14, RFC 2119, DOI 1261 10.17487/RFC2119, March 1997, . 1264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1266 May 2017, . 1268 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1269 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1270 DOI 10.17487/RFC4861, September 2007, . 1273 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1274 Address Autoconfiguration", RFC 4862, DOI 1275 10.17487/RFC4862, September 2007, . 1278 [Route Preferences] R. Draves, D. Thaler, "Default Router 1279 Preferences and More-Specific Routes", RFC 4191, DOI 1280 10.17487/RFC4191, November 2005, . 1283 [Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection 1284 by Hosts in a Multi-Prefix Network", RFC 8028, DOI 1285 10.17487/RFC8028, November 2016, . 1288 [NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor 1289 Unreachability Detection Is Too Impatient", RFC 7048, DOI 1290 10.17487/RFC7048, July 2010, . 1293 [Default Address] D. Thaler, R. Draves, A. Matsumoto, T. Chown, 1294 "Default Address Selection for Internet Protocol Version 6 1295 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1296 . 1298 [Node Requirements] T. Chown, J. Loughney, T. Winters, "IPv6 Node 1299 Requirements", RFC 8504, DOI 10.17487/RFC8504, January 1300 2019, . 1302 [CPE Requirements] Singh, H., Beebee W., Donley, C., and B. Stark, 1303 "Basic Requirements for IPv6 Customer Edge Routers", RFC 1304 7084, DOI 10.17487/RFC7084, November 2013, 1305 . 1307 [HomeNet Architecture] T. Chown, J. Arkko, A. Brandt, O. Troan, J. 1308 Weil, "IPv6 Home Networking Architecture Principles", RFC 1309 7368, DOI 10.17487/RFC7368, October 2014, 1310 . 1312 [HNCP] M. Stenberg, S. Barth, P. Pfister, "Home Networking Control 1313 Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, 1314 . 1316 [Policy by DHCP] A. Matsumoto, T. Fujisaki, T. Chown, "Distributing 1317 Address Selection Policy Using DHCPv6", RFC 7078 DOI 1318 10.17487/RFC7078, January 2014, . 1321 [Residential practices] Palet, J., "IPv6 Deployment Survey 1322 Residential/Household Services) How IPv6 is being 1323 deployed?", UK NOF 39, January 2018, 1324 . 1327 [SLAAC Robustness] F. Gont, J. Zorz, R. Patterson, "Improving the 1328 Robustness of Stateless Address Autoconfiguration (SLAAC) 1329 to Flash Renumbering Events", draft-ietf-6man-slaac-renum- 1330 02 (work in progress), January 2021 1332 11.2. Informative References 1334 [RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6 1335 (IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200, 1336 July 2017, . 1338 [Flash-Renumbering] F. Gont, J. Zorz, R. Patterson, "Reaction of 1339 Stateless Address Autoconfiguration (SLAAC) to Flash- 1340 Renumbering Events", RFC 8978, March 2021. 1342 [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. 1343 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 1344 10.17487/RFC6105, February 2011, . 1347 [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router 1348 Advertisement Guard (RA-Guard)", RFC 7113, DOI 1349 10.17487/RFC7113, February 2014, . 1352 [MHMP] O. Troan, D. Miles, S. Matsushima, T. Okimoto, D. Wing, "IPv6 1353 Multihoming without Network Address Translation", RFC 1354 7157, DOI 10.17487/RFC7157, March 2014, . 1357 [ULA] R. Hinden, B. Haberman, "Unique Local IPv6 Unicast Addresses", 1358 RFC 4193, DOI 10.17487/RFC4193, October 2005, 1359 . 1361 12. Acknowledgments 1363 Thanks to 6man working group for problem discussion. 1365 Authors' Addresses 1367 Olorunloba Olopade 1368 Virgin Media 1369 270 & 280 Bartley Way, Bartley Wood Business Park, Hook, 1370 Hampshire RG27 9UP 1371 Email: Loba.Olopade@virginmedia.co.uk 1373 Eduard Vasilenko 1374 Huawei Technologies 1375 17/4 Krylatskaya st, Moscow, Russia 121614 1376 Email: vasilenko.eduard@huawei.com 1378 Paolo Volpato 1379 Huawei Technologies 1380 Via Lorenteggio 240, 20147 Milan, Italy 1381 Email: paolo.volpato@huawei.com