idnits 2.17.1 draft-ietf-v6ops-conditional-ras-08.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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 21, 2018) is 2073 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-06 == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-enterprise-pa-multihoming-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations J. Linkova 3 Internet-Draft Google 4 Intended status: Informational M. Stucchi 5 Expires: February 22, 2019 RIPE NCC 6 August 21, 2018 8 Using Conditional Router Advertisements for Enterprise Multihoming 9 draft-ietf-v6ops-conditional-ras-08 11 Abstract 13 This document discusses the most common scenarios of connecting an 14 enterprise network to multiple ISPs using an address space assigned 15 by an ISP and how the approach proposed in the "ietf-rtgwg- 16 enterprise-pa-multihoming" draft could be applied in those scenarios. 17 The problem of enterprise multihoming without address translation of 18 any form has not been solved yet as it requires both the network to 19 select the correct egress ISP based on the packet source address and 20 hosts to select the correct source address based on the desired 21 egress ISP for that traffic. The "ietf-rtgwg-enterprise-pa- 22 multihoming" document proposes a solution to this problem by 23 introducing a new routing functionality (Source Address Dependent 24 Routing) to solve the uplink selection issue and using Router 25 Advertisements to influence the host source address selection. While 26 the above-mentioned document focuses on solving the general problem 27 and on covering various complex use cases, this document adopts the 28 approach proposed in the "ietf-rtgwg-enterprise-pa-multihoming" draft 29 to provide a solution for a limited number of common use cases. In 30 particular, the focus is on scenarios where an enterprise network has 31 two Internet uplinks used either in primary/backup mode or 32 simultaneously and hosts in that network might not yet properly 33 support multihoming as described in RFC8028. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 22, 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4 71 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4 72 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 5 73 3. Conditional Router Advertisements . . . . . . . . . . . . . . 5 74 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 75 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5 76 3.1.2. Source Address Selection and Conditional RAs . . . . 5 77 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8 78 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8 79 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9 80 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 12 81 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 12 82 3.2.5. Topologies with Dedicated Border Routers . . . . . . 13 83 3.2.6. Intra-Site Communication during Simultaneous Uplinks 84 Outage . . . . . . . . . . . . . . . . . . . . . . . 15 85 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15 86 3.2.8. Routing Packets when the Corresponding Uplink is 87 Unavailable . . . . . . . . . . . . . . . . . . . . . 16 88 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16 89 3.3.1. Connections Preservation . . . . . . . . . . . . . . 17 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18 93 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 96 7.2. Informative References . . . . . . . . . . . . . . . . . 20 98 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 Multihoming is an obvious requirement for many enterprise networks to 104 ensure the desired level of network reliability. However, using more 105 than one ISP (and address space assigned by those ISPs) introduces 106 the problem of assigning IP addresses to hosts. In IPv4 there is no 107 choice but using [RFC1918] address space and NAT ([RFC3022]) at the 108 network edge ([RFC4116]). Using Provider Independent (PI) address 109 space is not always an option, since it requires running BGP between 110 the enterprise network and the ISPs. Administrative overhead of 111 obtaining and managing PI address space can also be a concern. As 112 IPv6 hosts can, by design, have multiple addresses of the global 113 scope ([RFC4291]), multihoming using provider address looks even 114 easier for IPv6: each ISP assigns an IPv6 block (usually /48) and 115 hosts in the enterprise network have addresses assigned from each ISP 116 block. However using IPv6 PA blocks in multihoming scenario 117 introduces some challenges, including but not limited to: 119 o Selecting the correct uplink based on the packet source address; 121 o Signaling to hosts that some source addresses should or should not 122 be used (e.g. an uplink to the ISP went down or became available 123 again). 125 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses 126 these and other related challenges in detail in relation to the 127 general multihoming scenario for enterprise networks and proposes a 128 solution which relies heavily on the rule 5.5 of the default address 129 selection algorithm ([RFC6724]). The rule 5.5 makes hosts prefer 130 source addresses in a prefix advertised by the next-hop and therefore 131 is very useful in multihomed scenarios when different routers may 132 advertise different prefixes. While [RFC6724] defines the Rule 5.5 133 as optional, the recent [RFC8028] recommends that multihomed hosts 134 SHOULD support it. Unfortunately that rule has not been widely 135 implemented when this document was written. Therefore network 136 administrators in enterprise networks can't yet assume that all 137 devices in their network support the rule 5.5, especially in the 138 quite common BYOD ("Bring Your Own Device") scenario. However, while 139 it does not seem feasible to solve all the possible multihoming 140 scenarios without relying on rule 5.5, it is possible to provide IPv6 141 multihoming using provider-assigned (PA) address space for the most 142 common use cases. This document discusses how the general approach 143 described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be 144 applied to solve multihoming scenarios when: 146 o An enterprise network has two or more ISP uplinks; 148 o Those uplinks are used for Internet access in active/backup or 149 load sharing mode w/o any sophisticated traffic engineering 150 requirements; 152 o Each ISP assigns the network a subnet from its own PA address 153 space 155 o Hosts in the enterprise network are not expected to support the 156 Rule 5.5 of the default address selection algorithm ([RFC6724]). 158 1.1. Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in BCP 14 [RFC2119] 163 [RFC8174] when, and only when, they appear in all capitals, as shown 164 here. 166 2. Common Enterprise Multihoming Scenarios 168 2.1. Two ISP Uplinks, Primary and Backup 170 This scenario has the following key characteristics: 172 o The enterprise network is using uplinks to two (or more) ISPs for 173 Internet access; 175 o Each ISP assigns IPv6 PA address space for the network; 177 o Uplink(s) to one ISP is a primary (preferred) one. All other 178 uplinks are backup and are not expected to be used while the 179 primary one is operational; 181 o If the primary uplink is operational, all Internet traffic should 182 flow via that uplink; 184 o When the primary uplink fails the Internet traffic needs to flow 185 via the backup uplinks; 187 o Recovery of the primary uplink needs to trigger the traffic 188 switchover from the backup uplinks back to primary one; 190 o Hosts in the enterprise network are not expected to support the 191 Rule 5.5 of the default address selection algorithm ([RFC6724]). 193 2.2. Two ISP Uplinks, Used for Load Balancing 195 This scenario has the following key characteristics: 197 o The enterprise network is using uplinks to two (or more) ISPs for 198 Internet access; 200 o Each ISP assigns an IPv6 PA address space; 202 o All the uplinks may be used simultaneously, with the traffic flows 203 being randomly (not necessarily equally) distributed between them; 205 o Hosts in the enterprise network are not expected to support the 206 Rule 5.5 of the default address selection algorithm ([RFC6724]). 208 3. Conditional Router Advertisements 210 3.1. Solution Overview 212 3.1.1. Uplink Selection 214 As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of 215 the two main problems to be solved in the enterprise multihoming 216 scenario is the problem of the next-hop (uplink) selection based on 217 the packet source address. For example, if the enterprise network 218 has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 219 subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) 220 then packets sourced from subnet_A must be sent to ISP_A uplink while 221 packets sourced from subnet_B must be sent to ISP_B uplink. Sending 222 packets with source addresses belonging to one ISP address space to 223 another ISP might cause those packets to be filtered out if those 224 ISPs or their uplinks implement anti-spoofing ingress filtering 225 ([RFC2827], [RFC3704]). 227 While some work is being done in the Source Address Dependent Routing 228 (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest way 229 to implement the desired functionality currently is to apply a policy 230 which selects a next-hop or an egress interface based on the packet 231 source address. Most SMB/Enterprise grade routers have such 232 functionality available currently. 234 3.1.2. Source Address Selection and Conditional RAs 236 Another problem to be solved in the multihoming scenario is the 237 source address selection on hosts. In the normal situation (all 238 uplinks are up/operational) hosts have multiple global unique 239 addresses and can rely on the default address selection algorithm 240 ([RFC6724]) to pick up a source address, while the network is 241 responsible for choosing the correct uplink based on the source 242 address selected by a host as described in Section 3.1.1. However, 243 some network topology changes (i.e. changing uplink status) might 244 affect the global reachability for packets sourced from the 245 particular prefixes and therefore such changes have to be signaled 246 back to the hosts. For example: 248 o An uplink to an ISP_A went down. Hosts should not use addresses 249 from ISP_A prefix; 251 o A primary uplink to ISP_A which was not operational has come back 252 up. Hosts should start using the source addresses from ISP_A 253 prefix. 255 [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed 256 explanation on why SLAAC (Stateless Address Autoconfiguration, 257 [RFC4862]) and RAs (Router Advertisements, [RFC4861]) are the most 258 suitable mechanism for signaling network topology changes to hosts 259 and thereby influencing the source address selection. Sending a 260 router advertisement to change the preferred lifetime for a given 261 prefix provides the following functionality: 263 o deprecating addresses (by sending an RA with the 264 preferred_lifetime set to 0 in the corresponding PIO (Prefix 265 Information option, [RFC4861])) to indicate to hosts that that 266 addresses from that prefix should not be used; 268 o making a previously unused (deprecated) prefix usable again (by 269 sending an RA containing a PIO with non-zero preferred lifetime) 270 to indicate to hosts that addresses from that prefix can be used 271 again. 273 It should be notes that only preferred lifetime for the affected 274 prefix needs to be changed. As the goal is to influence the source 275 address selection algoorithm on hosts, not preventing them from 276 forming addresses from a specific prefix, the valid lifetime should 277 not be changed. Actually it would not even be possible for 278 unauthenticated RAs (which is the most common deployment scenario) as 279 Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime 280 for addresses to zero unless RAs are authenticated. 282 To provide the desired functionality, first-hop routers are required 283 to 285 o send RA triggered by defined event policies in response to uplink 286 status change event; and 288 o while sending periodic or solicted RAs, set the value in the given 289 RA field (e.g. PIO preferred lifetime) based on the uplink 290 status. 292 The exact definition of the 'uplink status' depends on the network 293 topology and may include conditions like: 295 o uplink interface status change; 297 o presence of a particular route in the routing table; 299 o presence of a particular route with a particular attribute (next- 300 hop, tag etc) in the routing table; 302 o protocol adjacency change. 304 etc. 306 In some scenarios, when two routers are providing first-hop 307 redundancy via VRRP (Virtual Router Redundancy Protocol, [RFC5798]), 308 the master-backup status can be considered as a condition for sending 309 RAs and changing the preferred lifetime value. See Section 3.2.2 for 310 more details. 312 If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS 313 (Router Advertisement Options for DNS Configuration, [RFC8106]) it 314 might be desirable for the conditional RAs to update the Lifetime 315 field of the RDNSS option as well. 317 The trigger is not only forcing the router to send an unsolicited RA 318 to propagate the topology changes to all hosts. Obviously the RA 319 fields values (like PIO Preferred Lifetime or DNS Server Lifetime) 320 changed by the particular trigger need to stay the same until another 321 event happens causing the value to be updated. E.g. if the ISP_A 322 uplink failure causes the prefix to be deprecated, all solicited and 323 unsolicited RAs sent by the router need to have the Preferred 324 Lifetime for that PIO set to 0 until the uplink comes back up. 326 It should be noted that the proposed solution is quite similar to the 327 existing requirement L-13 for IPv6 Customer Edge Routers ([RFC7084]) 328 and the documented behavior of homenet devices ([RFC7788]). It is 329 using the same mechanism of deprecating a prefix when the 330 corresponding uplink is not operational, applying it to enterprise 331 network scenario. 333 3.2. Example Scenarios 335 This section illustrates how the conditional RAs solution can be 336 applied to most common enterprise multihoming scenarios, described in 337 Section 2. 339 3.2.1. Single Router, Primary/Backup Uplinks 341 -------- 342 ,-------, ,' ', 343 +----+ 2001:db8:1::/48 ,' ', : : 344 | |------------------+ ISP_A +--+: : 345 2001:db8:1:1::/64 | | ', ,' : : 346 | | '-------' : : 347 H1------------------| R1 | : INTERNET : 348 | | ,-------, : : 349 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 350 | |------------------+ ISP_B +--+: : 351 +----+ ', ,' : : 352 '-------' ', ,' 353 -------- 355 Figure 1: Single Router, Primary/Backup Uplinks 357 Let's look at a simple network topology where a single router acts as 358 a border router to terminate two ISP uplinks and as a first-hop 359 router for hosts. Each ISP assigns a /48 to the network, and the 360 ISP_A uplink is a primary one, to be used for all Internet traffic, 361 while the ISP_B uplink is a backup, to be used only when the primary 362 uplink is not operational. 364 To ensure that packets with source addresses from ISP_A and ISP_B are 365 only routed to ISP_A and ISP_B uplinks respectively, the network 366 administrator needs to configure a policy on R1: 368 IF (packet_source_address is in 2001:db8:1::/48) 369 and 370 (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 371 THEN 372 default next-hop is ISP_A_uplink 374 IF (packet_source_address is in 2001:db8:2::/48) 375 and 376 (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 377 THEN 378 default next-hop is ISP_B_uplink 380 Under normal circumstances it is desirable that all traffic be sent 381 via the ISP_A uplink, therefore hosts (the host H1 in the example 382 topology figure) should be using source addresses from 383 2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 384 using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 385 until the ISP_A uplink comes back up. To achieve this the router 386 advertisement configuration on the R1 device for the interface facing 387 H1 needs to have the following policy: 389 prefix 2001:db8:1:1::/64 { 390 IF (ISP_A_uplink is up) 391 THEN 392 preferred_lifetime = 604800 393 ELSE 394 preferred_lifetime = 0 395 } 397 prefix 2001:db8:2:1::/64 { 398 IF (ISP_A_Uplink is up) 399 THEN 400 preferred_lifetime = 0 401 ELSE 402 preferred_lifetime = 604800 403 } 405 A similar policy needs to be applied to the RDNSS Lifetime if ISP_A 406 and ISP_B DNS servers are used. 408 3.2.2. Two Routers, Primary/Backup Uplinks 410 Let's look at a more complex scenario where two border routers are 411 terminating two ISP uplinks (one each), acting as redundant first-hop 412 routers for hosts. The topology is shown on Fig.2 413 -------- 414 ,-------, ,' ', 415 +----+ 2001:db8:1::/48 ,' ', : : 416 2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 417 | | R1 | ', ,' : : 418 | +----+ '-------' : : 419 H1------------------| : INTERNET : 420 | +----+ ,-------, : : 421 |_| | 2001:db8:2::/48 ,' ', : : 422 2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : 423 +----+ ', ,' : : 424 '-------' ', ,' 425 -------- 427 Figure 2: Two Routers, Primary/Backup Uplinks 429 In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 430 address space) and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B 431 address space). Each router needs to have a forwarding policy 432 configured for packets received on its hosts-facing interface: 434 IF (packet_source_address is in 2001:db8:1::/48) 435 and 436 (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 437 THEN 438 default next-hop is ISP_A_uplink 440 IF (packet_source_address is in 2001:db8:2::/48) 441 i and 442 (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 443 THEN 444 default next-hop is ISP_B_uplink 446 In this case there is more than one way to ensure that hosts are 447 selecting the correct source address based on the uplink status. If 448 VRRP is used to provide first-hop redundancy and the master router is 449 the one with the active uplink, then the simplest way is to use the 450 VRRP mastership as a condition for router advertisement. So, if 451 ISP_A is the primary uplink, the routers R1 and R2 need to be 452 configured in the following way: 454 R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A 455 uplink is down, then R1 becomes a backup (the VRRP interface status 456 tracking is expected to be used to automatically modify the VRRP 457 priorities and trigger the mastership switchover). Router 458 advertisements on R1's interface facing H1 needs to have the 459 following policy applied: 461 prefix 2001:db8:1:1::/64 { 462 IF (vrrp_master) 463 THEN 464 preferred_lifetime = 604800 465 ELSE 466 preferred_lifetime = 0 467 } 469 R2 is VRRP backup by default. Router advertsement on R2 interface 470 facing H1 needs to have the following policy applied: 472 prefix 2001:db8:2:1::/64 { 473 IF(vrrp_master) 474 THEN 475 preferred_lifetime = 604800 476 ELSE 477 preferred_lifetime = 0 478 } 480 If VRRP is not used or interface status tracking is not used for 481 mastership switchover, then each router needs to be able to detect 482 the uplink failure/recovery on the neighboring router, so that RAs 483 with updated preferred lifetime values are triggered. Depending on 484 the network setup various triggers like a route to the uplink 485 interface subnet or a default route received from the uplink can be 486 used. The obvious drawback of using the routing table to trigger the 487 conditional RAs is that some additional configuration is required. 488 For example, if a route to the prefix assigned to the ISP uplink is 489 used as a trigger, then the conditional RA policy would have the 490 following logic: 492 R1: 494 prefix 2001:db8:1:1::/64 { 495 IF (ISP_A_uplink is up) 496 THEN 497 preferred_lifetime = 604800 498 ELSE 499 preferred_lifetime = 0 500 } 502 R2: 504 prefix 2001:db8:2:1::/64 { 505 IF (ISP_A_uplink_route is present) 506 THEN 507 preferred_lifetime = 0 508 ELSE 509 preferred_lifetime = 604800 510 } 512 3.2.3. Single Router, Load Balancing Between Uplinks 514 Let's look at the example topology shown in Figure 1, but with both 515 uplinks used simultaneously. In this case R1 would send RAs 516 containing PIOs for both prefixes, 2001:db8:1:1::/64 and 517 2001:db8:2:1::/64, changing the preferred lifetime based on 518 particular uplink availability. If the interface status is used as 519 uplink availability indicator, then the policy logic would look like 520 the following: 522 prefix 2001:db8:1:1::/64 { 523 IF (ISP_A_uplink is up) 524 THEN 525 preferred_lifetime = 604800 526 ELSE 527 preferred_lifetime = 0 528 } 529 prefix 2001:db8:2:1::/64 { 530 IF (ISP_B_uplink is up) 531 THEN 532 preferred_lifetime = 604800 533 ELSE 534 preferred_lifetime = 0 535 } 537 R1 needs a forwarding policy to be applied to forward packets to the 538 correct uplink based on the source address similar to one described 539 in Section 3.2.1. 541 3.2.4. Two Router, Load Balancing Between Uplinks 543 In this scenario the example topology is similar to the one shown in 544 Figure 2, but both uplinks can be used at the same time. It means 545 that both R1 and R2 need to have the corresponding forwarding policy 546 to forward packets based on their source addresses. 548 Each router would send RAs with PIO for the corresponding prefix. 549 setting preferred_lifetime to a non-zero value when the ISP uplink is 550 up, and deprecating the prefix by setting the preferred lifetime to 0 551 in case of uplink failure. The uplink recovery would trigger another 552 RA with non-zero preferred lifetime to make the addresses from the 553 prefix preferred again. The example RA policy on R1 and R2 would 554 look like: 556 R1: 558 prefix 2001:db8:1:1::/64 { 559 IF (ISP_A_uplink is up) 560 THEN 561 preferred_lifetime = 604800 562 ELSE 563 preferred_lifetime = 0 564 } 566 R2: 568 prefix 2001:db8:2:1::/64 { 569 IF (ISP_B_uplink is up) 570 THEN 571 preferred_lifetime = 604800 572 ELSE 573 preferred_lifetime = 0 574 } 576 3.2.5. Topologies with Dedicated Border Routers 578 For simplicity, all topologies above show the ISP uplinks terminated 579 on the first-hop routers. Obviously, the proposed approach can be 580 used in more complex topologies when dedicated devices are used for 581 terminating ISP uplinks. In that case VRRP mastership or interface 582 status can not be used as a trigger for conditional RAs and route 583 presence as described above (Section 3.2.2) should be used instead. 585 Let's look at the example topology shown on the Figure 3: 587 2001:db8:1::/48 -------- 588 2001:db8:1:1::/64 ,-------, ,' ', 589 +----+ +---+ +----+ ,' ', : : 590 _| |--| |--| R3 |----+ ISP_A +---+: : 591 | | R1 | | | +----+ ', ,' : : 592 | +----+ | | '-------' : : 593 H1--------| |LAN| : INTERNET : 594 | +----+ | | ,-------, : : 595 |_| | | | +----+ ,' ', : : 596 | R2 |--| |--| R4 |----+ ISP_B +---+: : 597 +----+ +---+ +----+ ', ,' : : 598 2001:db8:2:1::/64 '-------' ', ,' 599 2001:db8:2::/48 -------- 601 Figure 3: Dedicated Border Routers 603 For example, if ISP_A is a primary uplink and ISP_B is a backup one 604 then the following policy might be used to achieve the desired 605 behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while 606 ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if 607 the uplink is non-operational): 609 R1 and R2 policy: 611 prefix 2001:db8:1:1::/64 { 612 IF (ISP_A_uplink_route is present) 613 THEN 614 preferred_lifetime = 604800 615 ELSE 616 preferred_lifetime = 0 617 } 619 prefix 2001:db8:2:1::/64 { 620 IF (ISP_A_uplink_route is present) 621 THEN 622 preferred_lifetime = 0 623 ELSE 624 preferred_lifetime = 604800 625 } 627 For the load-balancing case the policy would look slightly different: 628 each prefix has non-zero preferred_lifetime only if the correspoding 629 ISP uplink route is present: 631 prefix 2001:db8:1:1::/64 { 632 IF (ISP_A_uplink_route is present) 633 THEN 634 preferred_lifetime = 604800 635 ELSE 636 preferred_lifetime = 0 637 } 639 prefix 2001:db8:2:1::/64 { 640 IF (ISP_B_uplink_route is present) 641 THEN 642 preferred_lifetime = 604800 643 ELSE 644 preferred_lifetime = 0 645 } 647 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 649 Prefix deprecation as a result of an uplink status change might lead 650 to a situation when all global prefixes are deprecated (all ISP 651 uplinks are not operational for some reason). Even when there is no 652 Internet connectivity it might be still desirable to have intra-site 653 IPv6 connectivity (especially when the network in question is an 654 IPv6-only one). However while an address is in a deprecated state, 655 its use is discouraged, but not strictly forbidden ([RFC4862]). In 656 such a scenario all IPv6 source addresses in the candidate set 657 ([RFC6724]) are deprecated, which means that they still can be used 658 (as there are no preferred addresses available) and the source 659 address selection algorithm can pick up one of them, allowing the 660 intra-site communication. However some OSes might just fall back to 661 IPv4 if the network interface has no preferred IPv6 global addresses. 662 Therefore if intra-site connectivity is vital during simultanious 663 outages of multiple uplinks, administrators might consider using ULAs 664 (Unique Local Addresses, [RFC4193]) or provisioning additional backup 665 uplinks to protect the network from double-failure cases. 667 3.2.7. Uplink Damping 669 If an actively used uplink (primary one or one used in load balaning 670 scenario) starts flapping, it might lead to the undesirable situation 671 of flapping addresses on hosts (every time the uplink goes up hosts 672 receive an RA with non-zero preferred PIO lifetime, and every time 673 the uplink goes down all addresses in the affected prefix become 674 deprecated). This would, undoubtedly, negatively impact the user 675 experience, not to mention the impact of spikes of duplicate address 676 detection traffic every time an uplink comes back up. Therefore it's 677 recommended that router vendors implement some form of damping policy 678 for conditional RAs and either postpone sending an RA with non-zero 679 lifetime for a PIO when the uplink comes up for a number of seconds 680 or even introduce accumulated penalties/exponential backoff algorithm 681 for such delays. (In the case of a multiple simultaneous uplink 682 failure scenario, when all but one uplinks are down and the last 683 remaining is flapping it might result in all addresses being 684 deprecated for a while after the flapping uplink recovers.) 686 3.2.8. Routing Packets when the Corresponding Uplink is Unavailable 688 Deprecating IPv6 addresses by setting the preferred lifetime to 0 689 discourage but not strictly forbid its usage in new communications. 690 A deprecated address may still be used for existing connections 691 ([RFC4862]). Therefore when an ISP uplink goes down the 692 corresponding border router might still receive packets with source 693 addresses belonging to that ISP address space while there is no 694 available uplink to send those packets to. 696 The expected router behaviour would depend on the uplink selection 697 mechanism. For example if some form of SADR is used then such 698 packets will be dropped as there is no route to the destination. If 699 policy-based routing is used to set a next-hop then the behaviour 700 would be implementation-dependend and may vary from dropping the 701 packets to forwarding them based on the routing table entries. It 702 should be noted that there is no return path to the packet source (as 703 the ISP uplink is not operational) therefore even if the outgoing 704 packets are sent to another ISP the return traffic might not be 705 delivered. 707 3.3. Solution Limitations 709 It should be noted that the proposed approach is not a "silver 710 bullet" for all possible multihoming scenarios. It would work very 711 well for networks with relatively simple topologies and 712 straightforward routing policies. The more complex the network 713 topology and the corresponding routing policies, the more 714 configuration would be required to implement the solution. 716 Another limitation is related to the load balancing between the 717 uplinks. In the scenario in which both uplinks are active, hosts 718 would select the source prefix using the Default Address Selection 719 algorithm ([RFC6724]), and therefore the load between two uplinks 720 most likely would not be evenly distributed. (However, the proposed 721 mechanism does allow a creative way of controlling uplinks load in 722 software defined networks where controllers might selectively 723 deprecate prefixes on some hosts but not others to move egress 724 traffic between uplinks). Also the prefix selection does not take 725 into account any other uplinks properties (such as latency etc), so 726 egress traffic might not be sent to the nearest uplink if the 727 corresponding prefix is selected as a source. In general, if not all 728 uplinks are equal and some uplinks are expected to be preferred over 729 others, then the network administrator should ensure that prefixes 730 from non-preferred ISP(s) are kept deprecated (so primary/backup 731 setup is used). 733 3.3.1. Connections Preservation 735 The proposed solution is not designed to preserve connection state 736 after an uplink failure. If all uplinks to an ISP go down, all 737 sessions to/from addresses from that ISP address space are 738 interrupted as there is no egress path for those packets and there is 739 no return path from the Internet to the corresponding prefix. In 740 this regard it is similar to IPv4 multihoming using NAT, where an 741 uplink failure and failover to another uplink means that a public 742 IPv4 address changes and all existing connections are interrupted. 744 An uplink recovery, however, does not necessarily lead to connections 745 interruption. In the load sharing/balancing scenario an uplink 746 recovery does not affect any existing connections at all. In the 747 active/backup topology when the primary uplink recovers from the 748 failure and the backup prefix is deprecated, the existing sessions 749 (established to/from the backup ISP addresses) can be preserved if 750 the routers are configured as described in Section 3.2.1 and send 751 packets with the backup ISP source addresses to the backup uplink 752 even when the primary one is operational. As a result, the primary 753 uplink recovery makes the usage of the backup ISP addresses 754 discouraged but still possible. 756 It should be noted that in IPv4 multihoming with NAT, when the egress 757 interface is chosen without taking packet source address into account 758 (as internal hosts usually have addresses from [RFC1918] space), 759 sessions might not be preserved after an uplink recovery unless 760 packet forwarding is integrated with existing NAT sessions tracking. 762 4. IANA Considerations 764 This memo asks the IANA for no new parameters. 766 5. Security Considerations 768 This memo introduces no new security considerations. It relies on 769 Router Advertisements ([RFC4861]) and SLAAC ([RFC4862] mechanism and 770 inherits their security properties. If an attacker is able to send a 771 rogue RA they could deprecate IPv6 addresses on hosts or infuence 772 source address selection processes on hosts. 774 The potential attack vectors are including but not limited to: 776 o An attacker sends a rogue RA deprecating IPv6 addresses on hosts; 778 o An attacker sends a rogue RA making addresses preferred while the 779 corresponding ISP uplink is not operational; 781 o An attacker sends a rogue RA making addresses preferred for a 782 backup ISP, steering traffic to undesirable (e.g. more expensive) 783 uplink. 785 Therefore the network administrators SHOULD secure Router 786 Advertisements, e.g., by deploying RA guard [RFC6105]. 788 5.1. Privacy Considerations 790 This memo introduces no new privacy considerations. 792 6. Acknowledgements 794 Thanks to the following people (in alphabetical order) for their 795 review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus 796 Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave 797 Thaler. 799 7. References 801 7.1. Normative References 803 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 804 and E. Lear, "Address Allocation for Private Internets", 805 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 806 . 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, 810 DOI 10.17487/RFC2119, March 1997, 811 . 813 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 814 Defeating Denial of Service Attacks which employ IP Source 815 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 816 May 2000, . 818 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 819 Address Translator (Traditional NAT)", RFC 3022, 820 DOI 10.17487/RFC3022, January 2001, 821 . 823 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 824 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 825 2004, . 827 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 828 Gill, "IPv4 Multihoming Practices and Limitations", 829 RFC 4116, DOI 10.17487/RFC4116, July 2005, 830 . 832 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 833 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 834 . 836 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 837 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 838 2006, . 840 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 841 Address Autoconfiguration", RFC 4862, 842 DOI 10.17487/RFC4862, September 2007, 843 . 845 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 846 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 847 DOI 10.17487/RFC6105, February 2011, 848 . 850 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 851 "Default Address Selection for Internet Protocol Version 6 852 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 853 . 855 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 856 Hosts in a Multi-Prefix Network", RFC 8028, 857 DOI 10.17487/RFC8028, November 2016, 858 . 860 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 861 "IPv6 Router Advertisement Options for DNS Configuration", 862 RFC 8106, DOI 10.17487/RFC8106, March 2017, 863 . 865 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 866 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 867 May 2017, . 869 7.2. Informative References 871 [I-D.ietf-rtgwg-dst-src-routing] 872 Lamparter, D. and A. Smirnov, "Destination/Source 873 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 874 progress), October 2017. 876 [I-D.ietf-rtgwg-enterprise-pa-multihoming] 877 Baker, F., Bowers, C., and J. Linkova, "Enterprise 878 Multihoming using Provider-Assigned Addresses without 879 Network Prefix Translation: Requirements and Solution", 880 draft-ietf-rtgwg-enterprise-pa-multihoming-07 (work in 881 progress), June 2018. 883 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 884 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 885 DOI 10.17487/RFC4861, September 2007, 886 . 888 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 889 Version 3 for IPv4 and IPv6", RFC 5798, 890 DOI 10.17487/RFC5798, March 2010, 891 . 893 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 894 Requirements for IPv6 Customer Edge Routers", RFC 7084, 895 DOI 10.17487/RFC7084, November 2013, 896 . 898 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 899 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 900 2016, . 902 Appendix A. Change Log 904 Initial Version: July 2017 906 Authors' Addresses 908 Jen Linkova 909 Google 910 Mountain View, California 94043 911 USA 913 Email: furry@google.com 914 Massimiliano Stucchi 915 RIPE NCC 916 Stationsplein, 11 917 Amsterdam 1012 AB 918 The Netherlands 920 Email: mstucchi@ripe.net