idnits 2.17.1 draft-vv-6man-nd-prefix-robustness-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 (April 13, 2021) is 1108 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) == Unused Reference: 'RFC8200' is defined on line 1283, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7157 (ref. 'MHMP') Summary: 1 error (**), 0 flaws (~~), 2 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 April 13, 2021 5 Expires: October 2021 7 ND Prefix Robustness Improvements 8 draft-vv-6man-nd-prefix-robustness-00 10 Abstract 12 IPv6 prefixes could become invalid abruptly as a result of outages, 13 network administrator actions, or particular product shortcomings. 15 That could lead to connectivity problems for the hosts attached to 16 the subtended network. 18 This document has two targets: on the one hand, to analyze the cases 19 that may lead to network prefix invalidity; on the other to develop 20 a root cause analysis for those cases and propose a solution. 22 This may bring to extensions of the protocols used to convey prefix 23 information and other options. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology and pre-requisite..................................3 60 2. Introduction...................................................3 61 3. Problem Scenarios..............................................4 62 3.1. Reference architectures...................................5 63 3.2. Applicable cases..........................................5 64 3.2.1. Router reload........................................5 65 3.2.2. Non-graceful configuration change....................6 66 3.2.3. Home broadband/SOHO with uplink redundancy...........6 67 3.3. Discussion on the scenarios...............................6 68 3.3.1. Case 1.A - Non-graceful reload.......................6 69 3.3.2. Case 1.B: Graceful reload without precautions........8 70 3.3.3. Cases 2.A, 2.B: Non-graceful configuration change....8 71 3.3.4. Case 3.A: Site connectivity if uplink is lost........9 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: corner-case 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. Link layer address of the router should be changed.......19 83 5.7. Dependency between solutions and extensions..............20 84 6. Extensions to the existing standards..........................20 85 6.1. Default router choice by host............................20 86 6.2. Prefixes become dynamic..................................20 87 6.3. Do not forget to deprecate prefixes on renumbering.......22 88 6.4. Do not forget to deprecate prefixes on shutdown..........23 89 6.5. Store prefixes in non-volatile memory....................23 90 6.6. Find lost information by "Synchronization"...............24 91 6.7. Default router announcement rules........................26 92 6.8. Clean orphaned prefixes at the default router list.......26 93 7. Interoperability analysis.....................................26 94 8. Applicability analysis........................................27 95 9. Security Considerations.......................................27 96 10. IANA Considerations..........................................28 97 11. References...................................................28 98 11.1. Normative References....................................28 99 11.2. Informative References..................................29 100 12. Acknowledgments..............................................30 102 1. Terminology and pre-requisite 104 [ND] and [SLAAC] are pre-requisite to understand this document. 105 The terms are inherited from these standards. 107 Additional terms: 109 Home Gateway - a small consumer-grade router that provides network 110 access between hosts on the local area network (LAN) and the 111 Internet behind the wide area network (WAN) 113 PA - Provider-Aggregatable addresses leased to the client or 114 subscriber 116 MHMP - Multi-Homing Multi-Prefix. An environment with hosts 117 connected to different PA providers (multi-homing) through 118 different address spaces announced from different providers 119 (multi-prefix) 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 2. Introduction 129 It has been reported that some number of cases could lead to loss of 130 information (primarily prefixes) by [ND]. Current [ND] protocol's 131 default timers lead to many days of outage for hosts. This is not 132 acceptable. 134 This document analyses all potential cases when an outage could 135 happen and proposes solutions. Discussion is restricted to potential 136 [ND] extensions only. 138 MHMP environment has been considered. It has been discovered that 139 [ND] problems could be isolated from the overall complex [MHMP] 140 environment, and could be fixed separately. 142 The document is organized to introduce, in section 3, the scenarios 143 where the issue of prefix invalidity may happen and the cases of 144 invalidity. 146 Section 4 provides a root cause analysis for the cases of invalidity 147 and identifies the corner-cases which are subject of our discussion. 149 Section 5 proposes a solution for the cases identified. 151 Section 6 brings the discussion forward, proposing extensions to 152 [ND]. 154 3. Problem Scenarios 156 [ND] distributes prefixes as PIOs (Prefix Information Options) in RA 157 (Router Advertisements) messages from routers. 159 Once a router assigns a prefix to a host, this prefix is assumed to 160 be stable so that hosts can employ it to configure the IPv6 161 addresses associated with their interfaces [SLAAC] or to forward 162 packets to the network. 164 Prefix changes may happen and are governed by the rules of [ND], 165 [SLAAC]. 167 Yet, cases exist where prefix instability may happen. An example is 168 provided by the so-called "flash-renumbering" event: when flash- 169 renumbering happens a network prefix in use suddenly becomes invalid 170 because it is replaced by a new prefix. 172 The router causing or forced to cause the network renumbering may 173 not be able to cope with the effects of this sudden change (for 174 example, deprecating the previously assigned prefixes). Another 175 possibility is that the subtended hosts do not have the means of 176 overcoming the effects of renumbering. 178 This section describes problems that were found in live networks. 179 Most of the information in this section comes from [SLAAC 180 Renumbering]. Their contributions are greatly acknowledged. 182 3.1. Reference architectures 184 Home broadband networks, SOHO (Small Office Home Office) networks 185 are the typical scenarios affected by renumbering. 187 In both cases at least a router (e.g. Home Gateway, Customer Premise 188 Equipment (CPE), Customer Edge (CE), etc.) is deployed to provide 189 connectivity to a Service Provider network for the attached devices. 190 A second router may be deployed for redundancy, especially for 191 business scenarios. 193 Two reference architecture can be considered: 195 Architecture #1. Hosts are directly connected to the router. For 196 example, a Home Gateway embeds the functions of L2 device (Ethernet 197 switch, WiFi AP) and L3 device (router). 199 Architecture #2. Hosts connect to an intermediate L2 device (e.g. a 200 wired Ethernet switch or a Wi-Fi access point) that, in turn, 201 connects to the router (or routers, if uplink redundancy is 202 requested). 204 3.2. Applicable cases 206 The current version of this draft identifies three major areas 207 associated with IPv6 network prefix invalidity. 209 The cases listed in the next sections can be seen as a reference to 210 the corner-cases discussed in section 4.3. 212 Further cases may be included in further versions. 214 3.2.1. Router reload 216 Depending on the event that causes the router to reload, we may have 217 two sub-cases: 219 Sub-case 1.A: Non-graceful reload, due to brutal or unexpected 220 events (refer to section 3.3.1. for more details). 222 Sub-case 1.B: Graceful reload but previous prefixes are not 223 deprecated (refer to section 3.3.2. for more details). 225 Sub-case 1.A may happen in architecture #2, while sub-case 1.B may 226 happen in both architectures. 228 3.2.2. Non-graceful configuration change 230 A sudden configuration change imposed for example by manual 231 intervention, forces the router to delegate a new prefix. Two sub- 232 cases are found where old prefixes may not be deprecated: 234 Sub-case 2.A: Abrupt prefix change on the router. 236 Sub-case 2.B: VLAN change on the switch. 238 More details on both sub-cases can be found in section 3.3.3. 240 Sub-case 2.A may happen in architecture #1, while sub-case 2.B may 241 happen in architecture #2. 243 3.2.3. Home broadband/SOHO with uplink redundancy 245 A single sub-case is relevant in this group: 247 Sub-case 3.A: One of the uplinks breaks connectivity without a 248 relevant notification to the connected hosts. 250 More details can be found in section 3.3.4. 252 Sub-case 3.A may arise in both architectures #1 and #2. 254 3.3. Discussion on the scenarios 256 This section further expands the description of the scenarios 257 highlighted in the previous paragraph. 259 The discussion provided here is introductory to both the root cause 260 analysis provided in section 4. and the solutions proposed in 261 section 5. 263 3.3.1. Case 1.A - Non-graceful reload 265 A router could be reloaded abruptly for many reasons: hardware or 266 software bug, power outage, manual intervention. This last one is 267 very probable for home broadband subscribers that tend to fix every 268 problem with power recycle. 270 It does not create additional problems for [ND] and [SLAAC] in the 271 majority of the cases, because the same information would be 272 advertised by the router in RA messages after each reload. 274 It does not create the problem in many other cases, including the 275 situation when Home Gateway would receive and advertise new PIO, 276 because hosts are typically directly connected to Home Gateway. 277 Ethernet or WiFi link would be initialized anyway - it would clear 278 all stale information on hosts. 280 It should not create problems for proper home network design where 281 all CPEs are routers - see [HomeNet Architecture]. The delegated 282 prefix would not be changed in the case of subtended CPE reload. 283 Prefix change in the case of upstream CPE reload should be properly 284 discontinued by subtended CPE. There is the need for a special 285 protocol for prefix distribution that is out of the scope of this 286 document - see [HNCP]. 288 For architecture #2 implemented in home environments, we have a 289 corner case when Home Gateway's abrupt reload would not be visible 290 for hosts connected to subtended "bridged" CPE. If it would coincide 291 with the situation when a different prefix would be delegated from 292 Carrier (at 37% probability according to [Residential practices]), 293 it would lead to the situation that hosts would receive a new prefix 294 without deprecation of the previous one. Hosts do not have any 295 standard mechanism to choose only the new prefix for communication. 296 That would lead to a connectivity problem. 298 How long a non-preferred prefix would be kept in a stale state on 299 the host is not important (default AdvValidLifetime is 30 days in 300 section 6.2.1 of [ND]), because according to [Default Address] 301 section 5 rule#3, it should have a lower priority to be chosen. 302 [SLAAC] section 5.5.4 is another good reference highlighting that 303 address should be avoided after it would reach the deprecated 304 status. 305 How long an address would stay in the preferred state is important. 306 [ND] instructs hosts to prefer certain prefix for 7 days - see 307 default AdvPreferredLifetime in section 6.2.1. 308 It is not realistic for the subscriber to wait for 7 days. 309 It practically means that the subscriber in this corner case would 310 have a few options to fix the problem: (1) reload all hosts, or (2) 311 reconnect the physical link of every host, or (3) reload subtended 312 bridge, or (4) manually delete the prefix on the hosts to clear 313 stale information. 315 3.3.2. Case 1.B: Graceful reload without precautions 317 The router could be reloaded by graceful procedure (reboot or 318 shutdown that would use "init 6" in Unix). It is still possible that 319 software would not send RA with prefix Preferred Lifetime zero to 320 inform hosts about prefix deprecation. This practice prevails 321 because IPv4's centralized address assignments by DHCP does not need 322 similar precautions. 324 Again, like in the previous section, it would not create a problem 325 in the majority of the cases for directly connected hosts 326 (architecture #1) because link layer would be reinitialized too. The 327 same corner case (architecture #2) would lead to the same result: 328 connectivity problem that could be resolved only by 4 types of 329 manual intervention mentioned in the previous section. 331 3.3.3. Cases 2.A, 2.B: Non-graceful configuration change 333 Router configuration could be changed manually, by automation tools, 334 or by protocols (for example, prefix distribution). 336 Additionally for architecture #2, L2 domain could be abruptly 337 changed by configuration (for example, VLAN change from "quarantine" 338 to "production" without any chance for the router to send a 339 message). 341 It could lead to the situation that prefix would change abruptly, 342 without any notification to hosts about the necessity to deprecate 343 the previous prefix. Hosts should be notified by prefix announcement 344 with Preferred Lifetime set to zero. 346 It should not happen for residential CPE because [CPE Requirements] 347 section 4.3 requirement L-13 clearly instructs: "If the delegated 348 prefix changes, i.e., the current prefix is replaced with a new 349 prefix without any overlapping period of time, then the IPv6 CE 350 router MUST immediately advertise the old prefix with a Preferred 351 Lifetime of zero". 353 But it is perfectly possible for other environments (except 354 residential CPEs) because other routers are not required to do the 355 same: [Node Requirements] does not clarify the exact router behavior 356 in the case of abrupt prefix change. [SLAAC] does not have any 357 recommendations either. 359 3.3.4. Case 3.A: Site connectivity if uplink is lost 361 A router could lose uplink. The probability for such an event is 362 much bigger for a mobile uplink (modem). It would invalidate the 363 possibility to use a PA prefix advertised from this carrier even in 364 the case that another carrier uplink is available on this or 365 redundant router (connectivity to the Internet is not lost). Some 366 mechanism is needed to inform hosts not to use address space from 367 the disconnected carrier because another carrier would filter it out 368 by anti-spoofing security protection. 370 This is relevant to both architecture #1 and #2. 372 The multi-homing multi-prefix PA environment has been properly 373 explained in [MHMP]. The discussion of how traffic should be source- 374 routed by routers in [MHMP] environment is not relevant to our [ND] 375 discussion. Unfortunately, an improper address used as a source 376 would cause a traffic drop as soon as traffic gets to the different 377 carrier. 379 [Default Address] section 5 (source address selection) rule 5 (for 380 different interfaces on the host) and rule 5.5 (for the same 381 interface) partially prepare hosts for such situation: "Prefer 382 addresses in a prefix advertised by the next-hop. If SA or SA's 383 prefix is assigned by the selected next-hop that will be used to 384 send to D [...] then prefer SA". This algorithm has an assumption 385 that the source address should be chosen after the next hop. 387 Unfortunately, the rules mentioned above in [Default Address] 388 section 5 would work only if the default router would cease to be 389 default after it loses route to its carrier. It would work only in 390 simplified topology where all hosts connect by L2 to different CPEs, 391 each leading to its separate carrier prefix. It could be called a 392 "common-link environment for all hosts and routers". It is not 393 possible in practice because hosts on the most popular link layer 394 technology (WiFi) are rooted to only one CPE (with AP inside) - they 395 would not switch automatically to different CPE where the Internet 396 connectivity may be still available. 398 [CPE Requirements] have G-3/4/5 specifically for this simplified 399 multi-homing residential design. It recommends announcing Router 400 Lifetime as zero on LAN if CPE does not have "default router from 401 the uplink" - it would push the host to use another source address 402 by mentioned the above source address selection algorithm. 404 It is not explained in [CPE Requirements] what should happen with PA 405 delegated prefix after the respective uplink is disconnected. 406 Probably, this is because it was not needed to deprecate stale 407 prefix for the above mentioned-mechanism (based on default router 408 withdrawal) to work. 410 The local residential network could be left without any default 411 router as a result of using the above mechanism - it is especially 412 probable in the single CPE environment. Hence, [CPE Requirements] 413 promotes [ULA] addresses for local connectivity. Default router 414 functionality is returned specifically for [ULA] addresses by 415 requirement L-3: use "Route Information Option" from [Route 416 Preferences]. It needs hosts' participation in routing through the 417 RIO option. 419 Unfortunately, this long chain of fixes explained above is strictly 420 optimized for the environment "common-link for all hosts and 421 routers". It is not the case for single WiFi inside any CPE or other 422 topologies. 424 Neither [ND] nor [SLAAC] instructs the router what to do when the PA 425 delegated prefix is withdrawn abruptly. 427 [Multi-Homing] section 3 has a good discussion about the proper 428 relationship between default routers and prefixes advertised by 429 respective routers in a stable situation. We would reuse these ideas 430 in section 5.1. [Multi-Homing] does not discuss what to do in the 431 situation when the router is available, but some uplinks (with 432 delegated prefixes) are lost. 434 [MHMP] discusses the problem in deep detail with two tools proposed 435 to regulate [ND] behavior: [Policy by DHCP] to change [Default 436 Address] algorithm and [Route Preferences] to inform about 437 appropriate exit points. There are more details later in section 438 5.1. 440 4. Root cause analysis 442 Let's further analyze to be sure that all corner cases are found. 444 We would assume in all discussions below that [RA-Guard] is 445 implemented, and all messages are from routers under legitimate 446 administrative control. Security issues are considered as resolved 447 by [RA-Guard], and possibly with extensions in [RA-Guard+]. 449 DHCP is almost as vulnerable as SLAAC for cases found below. DHCP's 450 typical lease time (hours) is shorter than SLAAC's prefix lifetime 451 (days), but is too long for users to accept self-repairing time. 452 Root cause analysis below applies to all possible environments: 453 DHCP, SLAAC, and mixed. 455 4.1. What to protect 457 [ND] Router Advertisements deliver configuration information to 458 hosts. Such information could become inaccurate in two different 459 periods of time: 461 a) Recoverable. Time is needed for some process to finish and update 462 information (example: router reload or uplink re-connect). 464 b) Non-recoverable. Time, dependent on some timer expiration 465 (example: complete loss of prefix or default router). 467 A careful look at the information distributed by RA would give us 468 the understanding that the most problematic is the information that 469 is already protected by deprecation timers: Prefix Information 470 Option and Default Router. We see from the cases discussed in 471 section 3 that this information is still susceptible to recoverable 472 and non-recoverable periods of inaccuracy. 474 For example, in the case of abrupt router reload described in 475 section 3.3.1, the recoverable part is the time spent by router and 476 hosts to update their cache after the router reload. The non- 477 recoverable part is related to the setting of the 478 AdvPreferredLifetime timer which would force a user to solve the 479 issue with manual intervention. 481 The next problematic case is the abrupt change of source link-layer 482 address. This problem is not discovered yet in production because it 483 has a low probability. Indeed, a router with a different link-layer 484 address would be treated as a new router, the old router would just 485 disappear from the link. It would affect primarily default router 486 information because all other information should be immediately re- 487 advertised from the new link layer address. Section 6.2.8 of [ND] 488 already discusses how to properly deprecate the default router 489 status of the old link layer address, but no recommendation is given 490 in [ND] for prefix deprecation in this situation. A corner case is 491 possible that software would not treat the new virtual interface as 492 identical concerning to the prefix information that should be 493 announced. Different prefixes could be announced. Some additional 494 precautions are needed. 496 Other information in RA (Hop Limit, MTU, DHCP flags, Reachable 497 timer, and Retransmit timer) are not so sensitive because (1) it is 498 typically static and (2) it does not affect connectivity for 499 respective parameters change in the wide range. 501 Flag "A" in PIO deserves special attention. It could be cleared 502 abruptly (signaling that hosts should not use this prefix for 503 [SLAAC] anymore). That should not create any problem, because the 504 prefix is still available from a respected PA provider - traffic 505 could be routed to the global Internet. Therefore, it is not vitally 506 important for the host to immediately deprecate the address from 507 this prefix. 508 A similar situation is with flag "M" in RA: DHCP address should be 509 deprecated. It should not create a connectivity problem because 510 prefixes could be routed to the global Internet. 512 4.2. Where to protect 514 [ND] is the protocol for first-hop connection between host and 515 router. It is designed for one link only. One link could have more 516 than one router. 518 We would assume below that a more complex topology (many other 519 routers) is shielded from this link by some other protocol that 520 would deliver all necessary information to those routers. 521 [HomeNet Architecture] discusses many types of information that 522 should be distributed to every home router. We focus on only 523 delegated prefixes for our discussion. 524 The number of uplinks on every router is not important, as long as 525 proper information about prefixes is up to date on the router. 527 Hence, all our topologies could be simplified into the following 528 scenarios: 530 I. L2 device (switch, WiFi AP) and L3 device (router) are in the 531 same device (sharing the fate for power, reboot) (refer to 532 architecture #1 in section 3.1). 534 II. Separate L2 device (probably a switch) and an arbitrary number of 535 L3 devices (routers) are connected to the same IPv6 link (refer 536 to architecture #2 in section 3.1). 538 4.3. When to protect: corner-case scenarios 540 There are scenarios that are not fully resolved yet: 542 1. Proper prefix usage for Multi-Homing Multi-Prefix environment. 543 Hosts should be capable of choosing in a coordinated way 544 (1) a source address (from proper PA prefix) and (2) a next hop: 546 a. In a normal situation: all providers and prefixes are available 548 b. In a faulty situation: one provider is not reachable, but some 549 hosts and links on the routed path to this provider may still be 550 reachable 552 c. In the case when an administrator abruptly replaces delegated 553 prefix 555 2. Proper prefix usage for the case of router outage that: 557 d. Planned for this interface 558 (reboot, shutdown, or ceasing to be a router) 560 e. Abrupt (power outage, software or hardware bug) 562 3. Proper prefix usage for the case of link layer address of the 563 router. 565 These cases are discussed in section 5. (from 5.1 to 5.6). 567 There is no big difference for [ND] between ULA and GUA at the 568 considered link because both could be disjoined at any routed hop 569 upstream. It would need the same invalidation mechanisms on the 570 link. ULA could be invalidated too for the case that ULA spans many 571 sites in a big company. The residential network would probably have 572 a separate ULA for every household that would decrease the 573 probability of ULA prefixes invalidation. It is the responsibility 574 of another protocol (example: [HNCP]) to decide when ULA should be 575 invalidated, if ever. 577 5. Solutions 579 Let's look at the solutions for the corner-case scenarios listed in 580 section 4.3. 582 5.1. Multi-homing multi-prefix (MHMP) environment 584 We would consider here host capability to choose a proper PA prefix 585 and next hop router in a multi-homing multi-prefix (MHMP) 586 environment. 588 Our discussion is restricted to [ND] protocol only (one link) - it 589 would cut the number of topologies discussed in section 4.2. 591 The complex MHMP situation is properly discussed in [MHMP] section 592 3.1 - it is critical to read it to understand the rest of this 593 section. It is possible to introduce one additional classification 594 to clearly separate what it is possible to implement now from what 595 needs additional standardization efforts: 597 1. Case "equal prefixes": Announced prefixes are fully equal by 598 scope and value, all interested (by host) resources could be 599 reachable through all announced PA prefixes; 600 traffic distribution between carriers could be round-robin. 602 2. Case "non-equal prefixes": Announced prefixes are not equal - (1) 603 some resources (for example walled garden of one carrier) could 604 be accessed only through a particular prefix or (2) it is 605 desirable to have some policy for traffic distribution between PA 606 prefixes (cost of traffic, delay, packet loss, jitter, 607 proportional load). 609 There are two reminders before we discuss the above cases: 611 o [ND] section 6.3.6 recommends next hop choice between default 612 routers in a round-robin style. 614 o [Default Address] section 7 defines that source and destination 615 address selection should happen after the next hop (or interface) 616 would be selected by [ND] or routing. [Note: the assumption is 617 that a host has the information to determine the next hop, for 618 example because it has been delegated by an upstream router. The 619 host considered here selects the source and destination addresses 620 knowing the outgoing interface or the next-hop]. 622 Case "equal prefixes" does not create any requirement on what prefix 623 should be used for the source address. It is only needed that the 624 source address would be chosen to be compatible with the next hop 625 that should be in the direction to the respective carrier. 626 It would happen automatically for topology with only one router on 627 this link (then it would be the problem of the router how to do 628 source routing to the proper carrier on upstream) - it does not 629 create any additional requirements for host functionality. 630 Host on a multi-homing link would need compliance to [Default 631 Address] section 5 (source address selection) rule 5 (for different 632 interfaces on the host) or rule 5.5 (for different next hops on the 633 same interface) to choose source address compliant to the next hop. 635 Hence, it is possible to satisfy this basic case on the current 636 level of standardization developed. 638 Case "non-equal prefixes" is more complicated. It would be too late 639 if we would try to solve this problem on a router, because the wrong 640 source address may be already chosen by the host - it would not be 641 possible to contact the appropriate resource in the "walled garden". 642 Only NAT could be left as an option, but that is not a valid choice 643 for IPv6. 645 We could consider 2 methods to resolve the case of "non-equal 646 prefixes": 648 1. The same policies could be formatted differently and fed to the 649 host by two mechanisms: "Routing Information Options" of [Route 650 Preferences] and [Policy by DHCP] to modify policies in [Default 651 Address] selection algorithm. Then current priority of mechanisms 652 could be preserved the same: initially [ND] or routing would 653 choose the next hop, then [Default Address] would choose a source 654 address (and destination if multiple answers from DNS are 655 available). It is the method that is assumed in [MHMP]. 656 2. We could supply policies by [Policy by DHCP] only to [Default 657 Address] selection algorithm. [Default Address] discusses such 658 potential application in section 7. We could assume the reversion 659 of the algorithm's order: source address could be chosen first, 660 then next hop (default router). 661 Source address selected from proper carrier is potentially the 662 complete information needed for the host to choose the next hop, 663 but not in the [ND] default round-robin way among all available 664 routers. We need [ND] extension for this method that the host 665 would consider only default routers that have announced prefixes 666 for the chosen source IP address. 667 It is this method that is assumed in [Multi-Homing] section 3.2. 668 The difference from this document is that the same rules were 669 formulated not as the general advice, but as the particular 670 correction to [ND] - see section 6.1 for proposed [ND] extension. 672 The advantage of the second method is that we would not need to 673 download policies as RIO by [Route Preferences] - this mechanism is 674 not needed for the MHMP environment. 675 Only the second method is universal and extendable because not all 676 policies could be translated as RIO of [Route Preferences]. 677 Dynamic policies (packet loss, delay, and jitter) could be measured 678 only on hosts in the direction of many carriers. The decision about 679 source address and next hop should have an option to be fully local. 681 5.2. A provider is not reachable in MHMP environment 683 Let's assume the following fault situation: one provider is not 684 reachable in [MHMP] environment. Additionally, consider the more 685 complicated case when some hosts on the upstream routed path to this 686 provider may still be reachable after the path to the carrier is 687 broken. 689 A prefix could be dynamic - it could be received from some other 690 protocols (DHCP-PD, HNCP). The prefix could become invalid (at least 691 for the global Internet connectivity) as a result of the link lost 692 in the upstream direction to the carrier distributed this prefix. 694 It is difficult to signal by [ND] that particular on-site subnets 695 are still available for hosts with this prefix. [Route Preferences] 696 does give the possibility to selectively inform hosts of what is 697 still available with this source address, but [Route Preferences] is 698 not trying to automate such prefix calculations. It is not the best 699 idea to involve [ND] in routing. A possibility is to invalidate the 700 prefix as a whole if the prefix is invalid for its primary purpose 701 (Internet connectivity). 702 The solution for connectivity to some upstream links that is still 703 potentially available with this prefix is [ULA]. We have many 704 reasons to promote [ULA] for internal site connectivity: (1) hosts 705 would not have any address at all without initial connection to the 706 provider, (2) PA addresses would be invalidated in 30 days of 707 disconnect anyway, (3) it is not a good idea to give new addresses 708 from PA pool that is disconnected now from global Internet - hosts 709 may have a better option to get global reachability. ULA has better 710 security (open transport ports is not accessible from the Internet) 711 that is an additional bonus. 712 We effectively join current [CPE Requirements] and [HomeNet 713 Architecture] requirements in sections 2.2, 2.4, 3.4.2 that 714 subscriber's network should have local ULA addresses. 716 Prefix deprecation should be done by RA with zero Lifetime for this 717 prefix. It will put the prefix on hosts to the deprecated status 718 that according to many standards ([ND], [SLAAC], and [Default 719 Address]) would prioritize other addresses. Global communication 720 would be disrupted for this prefix anyway. Local communication for 721 deprecated addresses would continue till normal resolution because 722 the default Valid Lifetime is 30 days. Moreover, if it would happen 723 that this delegated prefix was the only one in the local network (no 724 [ULA] for some reasons), then new sessions would be opened on 725 deprecated prefix because it is the only address available. 726 If connectivity would be re-established and the same prefix would be 727 delegated to the link - it would be announced again with proper 728 preferred lifetime. If a different prefix could be delegated by the 729 PA provider, then the old prefix would stay in deprecated status. 730 It is an advantage for the host that would know about global 731 reachability on this prefix (by deprecated status) because the host 732 may use other means for communication at that time. 734 Such dynamic treatment of prefixes could have the danger of 735 oscillating links on the path to PA provider that would create the 736 flood of [ND] messages. 737 [HNCP] section 1.1 states: "it is desirable for ISPs to provide 738 large enough valid and preferred lifetimes to avoid unnecessary HNCP 739 state churn in homes". 740 It makes sense to introduce dampening for the rate of prefix 741 announcements. 743 Such conceptual change in the treatment of prefixes would not affect 744 current enterprise installations where prefixes are static. 746 It is important to mention again that it is the responsibility of 747 the respective protocol (that has delivered prefix to the considered 748 router) to inform the same router that prefix is not routed anymore 749 to the respective carrier. It is easy to do it in the simplified 750 topology when the only router could correlate uplink status with 751 DHCP-PD prefix delegated early. Some additional protocols like 752 [HNCP] are needed for more complex topology. 754 There is nothing in [ND] or [SLAAC] that prevents us from treating 755 prefixes as something more dynamic than "renumbering" to reflect the 756 dynamic path status to the PA provider. We propose extensions to 757 [CPE Requirements] and [SLAAC] that follow the logic of this section 758 - see section 6.2. 760 5.3. Administrator abruptly replaces PA prefix 762 This is the case when the network administrator (maybe from another 763 domain) replaces prefix, for example much faster than 2 hours or 764 remaining preferred lifetime (as per section 5.5.3 of [SLAAC] on 765 router advertisement processing). The reason is probably not related 766 to networking. 767 Abrupt prefix change may be caused by improper configuration, for 768 example VLAN change at the bridge. 769 Standards do have recommendations to deprecate old prefix but do not 770 have recommendations for developers and system designers to do 771 additional checks that would mitigate human mistakes. IPv4 cannot 772 mitigate such type of mistake, IPv6 could have an advantage here. 774 We propose adding a recommendation for the additional check to 775 [SLAAC] to make sure that prefix would be deprecated - see section 776 6.3. 778 This problem could be exacerbated by the low reliability of 779 multicast delivery in a wireless environment - the only packet sent 780 (for example before VLAN change) could be lost. We propose a long- 781 term solution for this problem in section 6.6 that permits 782 synchronizing host states with a new flag in router announcements. 784 5.4. Planned router outage 786 A router could be planned to be put out of service for a link 787 (reboot, shutdown, or ceasing to be a router). 789 The primary Operation System for routers is LINUX. We would discuss 790 an example based on LINUX - other developers can find an analogy for 791 his operating system. 793 Some LINUX shutdown commands are not graceful in principle (like 794 Halt or Poweroff). It would need extraordinary efforts to send 795 messages discussed in this section before the system would be 796 stopped. It is better to restrict network administrators from such 797 tools on routers. 799 Other LINUX shutdown commands are safe (Reboot is safe for a long 800 time, Shutdown and "Init 6" have been safe). It would execute 801 shutdown scripts that would give the developer the chance to comply 802 with requirements in this section. 804 It is up to the developer how reboot and shutdown should be mapped 805 to particular OS commands in graphical user interface (GUI), command 806 line interface (CLI), or automation interface (Netconf/YANG), and 807 what particular actions should be taken. It SHOULD guarantee that 808 section 6.2.5 of [ND] with updates in section 6.4 of this document 809 properly inform hosts that the router is going out of service. 811 The same procedure SHOULD be automatically activated for cases when 812 an administrator tries manually (via CLI or GUI) or automatically 813 (via Netcong/YANG) to change Link Layer Address on this router 814 interface or disable router functionality in [ND] for this link. 816 5.5. Prefix information lost because of abrupt router outage 818 PIO could be lost because of the abrupt reload - the router may not 819 have a chance to warn hosts, but the router could receive a 820 different prefix after reload. Reasons could be (1) power outage, 821 (2) software bug, or (3) hardware bug. 823 [HomeNet Architecture] section 3.4.3 (Delegated Prefixes) has 824 already recommended using of non-volatile memory: 825 "Provisioning such persistent prefixes may imply the need for stable 826 storage on routing devices and also a method for a home user to 827 'reset' the stored prefix should a significant reconfiguration be 828 required (though ideally the home user should not be involved at 829 all)". 830 [SLAAC] section 5.7 has recommended storing acquired addresses on 831 hosts in non-volatile memory too. 832 We join these requests and propose adding similar requirements to 833 [CPE Requirements] and [SLAAC] - see section 6.5. 835 The best long-term solution is to inform the host by [ND] protocol 836 that RA has all information in one announcement. Any missing 837 information SHOULD be considered deprecated. It is possible to do it 838 with the new flag in RA - see section 6.6. 839 "Complete" flag would become useful only when implemented on both: 840 host and router. It is proposed to rely on storage improvements in 841 non-volatile memory till the "Complete" flag would be supported on 842 many nodes. 844 Prefix storage in non-volatile memory and a "complete" flag may not 845 protect against all cases. It could be that the router was just 846 physically replaced for any reason (for example upgrade). The new 847 router would not have the old prefix information and the "complete" 848 flag would be sourced from different LLA. [ND] section 6.2.1 has 849 recommended to 30min as the default router lifetime 850 (AdvDefaultLifetime = 3*MaxRtrAdvInterval). Then router would be 851 deleted from the default list of hosts. It is proposed to deprecate 852 addresses at that time (default router list change) if the 853 particular prefix is not announced by any router active on the 854 default router list - see section 6.8. 856 5.6. Link layer address of the router should be changed 858 Sections 6.3 and 6.4 provide an additional check also in the case 859 of a link layer address change. 861 5.7. Dependency between solutions and extensions 863 It could be useful to map, for quick reference, the dependency 864 between the solutions listed in this section and standard's 865 extensions as presented in section 6. 867 Solution discussed in Corresponding extension 869 5.1 -> 6.1 871 5.2 -> 6.2 & 6.7 873 5.3 -> 6.3 & 6.6 875 5.4 -> 6.4 877 5.5 -> 6.5 & 6.6 & 6.8 879 5.6 -> 6.3 & 6.4 881 6. Extensions to the existing standards 883 The solution requires a number of standard extensions. They are 884 split into separate sections for better understanding. It is better 885 to read references from section 5. before reading this section. 887 6.1. Default router choice by host 889 * Section 6.3.6 (Default Router Selection) of [ND], add an initial 890 policy to default router selection: 892 0) For the cases when a particular implementation of ND does know 893 the source address at the time of default router selection 894 (it means that source address was chosen first), 895 then default routers that advertise the prefix for respective 896 source address SHOULD be preferred over routers that do not 897 advertise respective prefix. 899 6.2. Prefixes become dynamic 901 * We join request to [CPE Requirements] that has been proposed in 902 section 11 (General Requirements for HNCP Nodes) of [HNCP]: 904 The requirement L-13 to deprecate prefixes is applied to all 905 delegated prefixes in the network from which assignments have been 906 made on the respective interface. Furthermore, the Prefix 907 Information Options indicating deprecation MUST be included in 908 Router Advertisements for the remainder of the prefixes' respective 909 valid lifetime, but MAY be omitted after at least 2 hours have 910 passed. 912 * Add section 4.2 into [SLAAC]: 914 4.2 Dynamic Link Renumbering 916 Prefix delegation (primarily by DHCP-PD) is adopted by the industry 917 as the primary mechanism of PA address delegation mechanism in the 918 fixed and mobile broadband environments, including cases of small 919 business and branches of the big enterprises. 920 The delegated prefix is tied to dynamic link that has a considerable 921 probability to be disconnected, especially in a mobile environment. 922 The delegated prefix is losing the value if the remote site is 923 disconnected from prefix provider - this fact should be propagated 924 to all nodes on the disconnected site, including hosts. Information 925 Options indicating deprecation (multicast RA with zero preferred 926 lifetime) MUST be sent at least one time. It SHOULD be included in 927 Router Advertisements for the remainder of the prefixes' respective 928 valid lifetime but MAY be omitted after 2 hours of deprecation 929 announcements. 931 There is a high probability that connectivity to the provider would 932 be restored very soon then the prefix could be announced again to 933 all nodes on the site. 935 There is the probability that in a small period of time the same 936 problem would disconnect the site again (especially for mobile 937 uplink). Such oscillation between available and not available 938 provider could happen frequently that would flood the remote site 939 with [ND] updates. 940 Dampening mechanism MAY be implemented to suppress oscillation: 941 if the time between a particular prefix announcement and previous 942 deprecation was less than DampeningCheck then delay the next prefix 943 announcement for DampeningDelay and check the need for the prefix 944 announcement after DampeningDelay seconds. 945 It is recommended for protocol designers to implement a dampening 946 mechanism for protocols (like [HNCP]) that would be used to 947 distribute prefix delegation inside the site to relieve the majority 948 of site routers and the protocol itself from the processing of 949 oscillating messages. 951 * Section 5.1 (Node Configuration Variables) of [SLAAC], add timers: 953 DampeningCheck - the time between prefix announcement and previous 954 deprecation is checked against this value to decide about 955 dampening need. The timer should use 16bit unsigned integer 956 measured in seconds. The default value is 10 seconds. 958 DampeningDelay - the delay (penalty) for the next attempt to 959 announce the same prefix again. The timer should use 16bit 960 unsigned integer measured in seconds. The default value is 961 10 seconds. 963 These timers should be configurable like all other timers in [SLAAC] 964 section 5.1. 966 6.3. Do not forget to deprecate prefixes on renumbering 968 * Section 4.1 (Site renumbering) of [SLAAC], add at the end: 970 A network administrator SHOULD avoid the situations when renumbering 971 is done abruptly (with the time of transition that is less than the 972 preferred time for the respective prefix). Situations could happen 973 when it is not possible to archive the above-mentioned goal: (1) the 974 prefix could be withdrawn by the administrator of another domain, 975 (2) there could be the urgent need to change the prefix for reasons 976 not related to networking, (3) prefix could be invalidated after 977 some network event (example: loss of uplink that was used to receive 978 this prefix), (4) L2 connection (VLAN or VPN) could be changed 979 abruptly by mistake or not a proper design. 980 Prefix deprecation MUST be signaled at least one time by multicast 981 RA with Preferred Lifetime set to zero for respective PIO. It SHOULD 982 be included in RA for the remainder of the prefixes' respective 983 valid lifetime but MAY be omitted after 2 hours of deprecation 984 announcements. 986 It is recommended for developers to check and enforce this rule in 987 router's software: if an administrator, automated system, or other 988 protocol would try to delete a particular prefix from the link and 989 if that prefix has the preferred lifetime bigger than zero, then the 990 software MUST automatically generate deprecation announcements 991 according to the rules explained above. 993 System designer SHOULD make sure that in the case of abrupt change 994 of logical connectivity at L2 (VLAN, VPN) new default router SHOULD 995 deprecate stale prefixes inherited from the previous default router. 997 6.4. Do not forget to deprecate prefixes on shutdown 999 * Section 6.2.5 of [ND] starts from the definition of ceasing cases 1000 for the router on [ND] link. One additional reason SHOULD be added 1001 to the end of the list: 1003 - Link layer address of the interface should be changed. 1005 * Section 6.2.5 (Ceasing To Be an Advertising Interface) and 1006 Section 6.2.8 (Link Local Address Change) of [ND] already discusses 1007 requirements of proper ceasing to be [ND] router advertising 1008 interface. It has requirements to announce zero for a default router 1009 lifetime. It is proposed to add at the end of both sections: 1011 A router MUST also announce in above-mentioned announcements all 1012 previously advertised prefixes with zero Preferred LifeTime. Valid 1013 LifeTime should be not decreased from originally intended - current 1014 hosts sessions should have the possibility to be rerouted to the 1015 redundant router (if available). 1017 6.5. Store prefixes in non-volatile memory 1019 Add the same text: 1020 * [CPE Requirements], new requirement G-6 at the end of section 4.1, 1021 and 1022 * [SLAAC], at the end of section 5.7: 1024 The IPv6 router SHOULD keep in non-volatile memory all prefixes 1025 advertised on all links, including prefixes received by dynamic 1026 protocols with the reference to the respective protocol (DHCP-PD, 1027 HNCP, others). 1028 A router could experience a non-graceful reload. 1029 If another protocol would delegate any prefixes for router links 1030 then the router SHOULD immediately start announcing them in the 1031 normal way. 1032 Additionally, the router should wait until the end of convergence 1033 for the respective prefix-delegation protocol. The way to decide 1034 that convergence is finished is the responsibility of other 1035 protocols. It could be a simple timer after uplink would go to "up" 1036 or successful exchange by some protocol (like DHCP-PD). 1037 If another protocol would not delegate prefix recorded in non- 1038 volatile memory after assumed convergence is achieved, then the old 1039 prefix MUST be announced on the link at least one time by multicast 1040 RA with the zero Preferred Lifetime. It SHOULD be included in RA for 1041 the remainder of the prefixes' respective valid lifetime but MAY be 1042 omitted after 2 hours of deprecation announcements. 1044 6.6. Find lost information by "Synchronization" 1046 * Section 4.2 (RA format) of [ND], introduce new flag: 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Type | Code | Checksum | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Cur Hop Limit |M|O| Reserved|C| Router Lifetime | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Reachable Time | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Retrans Timer | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Options ... 1060 +-+-+-+-+-+-+-+-+-+-+-+- 1062 O 1-bit "Complete configuration" flag. When set, it 1063 indicates that all configuration information has been put 1064 inside this RA. The last reserved bit has been chosen to 1065 preserve the compatibility with [Route Preferences] that 1066 already propose to use the first reserved bit. 1068 * Section 6.2.3 (RA content) of [ND], introduce new flag: 1070 - In the C flag: set if it was possible to put all configuration 1071 information into this RA. 1073 * Section 6.2.3 (RA content) of [ND], add at the end: 1075 It is recommended that all configuration information SHOULD be 1076 included in one RA (if MTU permits) for multicast and unicast 1077 distribution. If successful, then the "Complete" flag SHOULD be set 1078 to signal the possibility of synchronization with hosts. 1080 * Section 6.3.4 (RA processing) of [ND], add at the beginning: 1082 After: "the receipt of a Router Advertisement MUST NOT invalidate 1083 all information received in a previous advertisement or from another 1084 source". 1086 Add: "Except for the case when RA received with "Complete" flag set, 1087 then any information from the same router (same Link Local Address) 1088 missing in this RA SHOULD be deprecated. Information protected by 1089 timers SHOULD be put into the deprecated state. Other information 1090 SHOULD be returned to the original state: in compliance to 1091 information from other routers or to default configuration if other 1092 routers do not announce respective information." 1094 * Section 6.3.4 (RA processing) of [ND], add to the list of PIO 1095 processing options: 1097 - If the prefix is missing in RA with the "Complete" flag set, then 1098 respective addresses should be put immediately into deprecated state 1099 up to the original valid lifetime. 1101 [ND] section 9 does mention: "In order to ensure that future 1102 extensions properly coexist with current implementations, all nodes 1103 MUST silently ignore any options they do not recognize in received 1104 ND packets and continue processing the packet." 1105 There is a possibility for the gradual introduction of the 1106 "Complete" flag: 1108 o If the host is upgraded to the new functionality first, then the 1109 router would send this bit zero (according to the basic [ND]) 1110 that would not activate new functionality on the host. 1112 o If the router is upgraded to the new functionality first, then 1113 the host would not pay any attention to the flag for Reserved 1114 bits. 1116 6.7. Default router announcement rules 1118 * We join [HNCP] section 11 (General Requirements for HNCP Nodes) 1119 request to [CPE Requirements]: 1121 The generic requirements G-4 and G-5 are relaxed such that any known 1122 default router on any interface is sufficient for a router to 1123 announce itself as the default router; similarly, only the loss of 1124 all such default routers results in self-invalidation. 1126 6.8. Clean orphaned prefixes at the default router list 1128 * Section 6.3.6 (Timing out Prefixes and Default Routers) of [ND] 1129 has: 1131 "Whenever the Lifetime of an entry in the Default Router List 1132 expires, that entry is discarded. When removing a router from the 1133 Default Router list, the node MUST update the Destination Cache in 1134 such a way that all entries using the router perform next-hop 1135 determination again rather than continue sending traffic to the 1136 (deleted) router." 1138 Add at the end: 1140 "All prefixes announced by deprecated default router SHOULD be 1141 checked on the announcement from other default routers. If any 1142 prefix is not anymore announced from any router - it SHOULD be 1143 deprecated." 1145 7. Interoperability analysis 1147 The primary motivation for the proposed changes originated from 1148 residential broadband requirements. [ND] extensions proposed in this 1149 document should not affect other environments (enterprise WAN, 1150 Campus). Moreover, some precautions proposed could block mistakes 1151 originated by humans in some corner cases in all environments. 1153 This document mostly intersects with Homenet working group documents 1154 [HomeNet Architecture], [HNCP], and [MHMP]. It was shown that it is 1155 possible to isolate [ND] in the context of Homenet to solve specific 1156 [ND] problems without any potential impact to the Homenet 1157 development and directions. 1159 [CPE Requirements] have the assumption of managing simplified 1160 topologies by manipulating routing information injection into [ND]. 1161 It has been shown in [MHMP] and in this document that it is better 1162 to signal reachability information to [ND] (reachability information 1163 to ND sounds strange) by the deprecation of delegated prefixes. We 1164 join [MHMP] request to change the approach. 1166 [Route Preferences] have been avoided as the mechanism for 1167 environments with PA address space. This is because source address 1168 is selected first. Then next hop can be chosen simply - see section 1169 5.1 for more details. 1170 [Route Preferences] could still be applicable for PI (Provider- 1171 Independent) address environments because only next hops need to be 1172 chosen properly. 1174 8. Applicability analysis 1176 Two standard extensions require changes to hosts. Hence, it would 1177 take a long time to be implemented in live networks. But workaround 1178 exists for the solution to work before then: 1180 o Absence of implementation for RA information synchronization by C 1181 flag on some hosts is not critical because we could use non- 1182 volatile memory for prefix storage. 1184 o Not being capable of excluding a router from the default router 1185 list (for the situation when it does not advertise respective 1186 prefix) is not critical, because it is needed only for the very 1187 advanced MHMP environment with traffic distribution by the policy 1188 between different PA providers. 1189 It is for the far future anyway. 1191 9. Security Considerations 1193 This document does not introduce new vulnerabilities. 1195 10. IANA Considerations 1197 This document has no any request to IANA. 1199 11. References 1201 11.1. Normative References 1203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1204 Requirement Levels", BCP 14, RFC 2119, DOI 1205 10.17487/RFC2119, March 1997, . 1208 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1209 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1210 May 2017, . 1212 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1213 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1214 DOI 10.17487/RFC4861, September 2007, . 1217 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1218 Address Autoconfiguration", RFC 4862, DOI 1219 10.17487/RFC4862, September 2007, . 1222 [SLAAC Renumbering] F. Gont, J. Zorz, R. Patterson, " Reaction of 1223 Stateless Address Autoconfiguration (SLAAC) to Flash- 1224 Renumbering Events", draft-gont-v6ops-slaac-renum-02 (work 1225 in progress), February 2020. 1227 [Route Preferences] R. Draves, D. Thaler, "Default Router 1228 Preferences and More-Specific Routes", RFC 4191, DOI 1229 10.17487/RFC4191, November 2005, . 1232 [Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection 1233 by Hosts in a Multi-Prefix Network", RFC 8028, DOI 1234 10.17487/RFC8028, November 2016, . 1237 [NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor 1238 Unreachability Detection Is Too Impatient", RFC 7048, DOI 1239 10.17487/RFC7048, July 2010, . 1242 [Default Address] D. Thaler, R. Draves, A. Matsumoto, T. Chown, 1243 "Default Address Selection for Internet Protocol Version 6 1244 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1245 . 1247 [Node Requirements] T. Chown, J. Loughney, T. Winters, "IPv6 Node 1248 Requirements", RFC 8504, DOI 10.17487/RFC8504, January 1249 2019, . 1251 [CPE Requirements] Singh, H., Beebee W., Donley, C., and B. Stark, 1252 "Basic Requirements for IPv6 Customer Edge Routers", RFC 1253 7084, DOI 10.17487/RFC7084, November 2013, 1254 . 1256 [HomeNet Architecture] T. Chown, J. Arkko, A. Brandt, O. Troan, J. 1257 Weil, "IPv6 Home Networking Architecture Principles", RFC 1258 7368, DOI 10.17487/RFC7368, October 2014, 1259 . 1261 [HNCP] M. Stenberg, S. Barth, P. Pfister, "Home Networking Control 1262 Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, 1263 . 1265 [MHMP] O. Troan, D. Miles, S. Matsushima, T. Okimoto, D. Wing, "IPv6 1266 Multihoming without Network Address Translation", RFC 1267 7157, DOI 10.17487/RFC7157, March 2014, . 1270 [Policy by DHCP] A. Matsumoto, T. Fujisaki, T. Chown, "Distributing 1271 Address Selection Policy Using DHCPv6", RFC 7078 DOI 1272 10.17487/RFC7078, January 2014, . 1275 [Residential practices] Palet, J., "IPv6 Deployment Survey 1276 Residential/Household Services) How IPv6 is being 1277 deployed?", UK NOF 39, January 2018, 1278 . 1281 11.2. Informative References 1283 [RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6 1284 (IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200, 1285 July 2017, . 1287 [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. 1288 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 1289 10.17487/RFC6105, February 2011, . 1292 [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router 1293 Advertisement Guard (RA-Guard)", RFC 7113, DOI 1294 10.17487/RFC7113, February 2014, . 1297 [ULA] R. Hinden, B. Haberman, "Unique Local IPv6 Unicast Addresses", 1298 RFC 4193, DOI 10.17487/RFC4193, October 2005, 1299 . 1301 12. Acknowledgments 1303 Thanks to 6man working group for problem discussion. 1305 Special Thanks to Fernando Gont for numerous discussions of [SLAAC 1306 Renumbering] in 6man alias and other drafts prepared for this 1307 problem. 1309 Authors' Addresses 1311 Eduard Vasilenko 1312 Huawei Technologies 1313 17/4 Krylatskaya st, Moscow, Russia 121614 1315 Email: vasilenko.eduard@huawei.com 1317 Paolo Volpato 1318 Huawei Technologies 1319 Via Lorenteggio 240, 20147 Milan, Italy 1321 Email: paolo.volpato@huawei.com