idnits 2.17.1 draft-ietf-v6ops-conditional-ras-05.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 56 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 129: '... SHOULD support it. Unfortunately t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2018) is 2136 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: 2 errors (**), 0 flaws (~~), 3 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: December 20, 2018 RIPE NCC 6 June 18, 2018 8 Using Conditional Router Advertisements for Enterprise Multihoming 9 draft-ietf-v6ops-conditional-ras-05 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. The problem of enterprise multihoming without address 16 translation of any form has not been solved yet as it requires both 17 the network to select the correct egress ISP based on the packet 18 source address and hosts to select the correct source address based 19 on the desired egress ISP for that traffic. The "ietf-rtgwg- 20 enterprise-pa-multihoming" document proposes a solution to this 21 problem by introducing a new routing functionality (Source Address 22 Dependent Routing) to solve the uplink selection issue and using 23 Router Advertisements to influence the host source address selection. 24 While the above-mentioned document focuses on solving the general 25 problem and on covering various complex use cases, this document 26 adopts the approach proposed in the "ietf-rtgwg-enterprise-pa- 27 multihoming" draft to provide a solution for a limited number of 28 common use cases. In particular, the focus is on scenarios where an 29 enterprise network has two Internet uplinks used either in primary/ 30 backup mode or simultaneously and hosts in that network might not yet 31 properly support multihoming as described in RFC8028. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 20, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4 69 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4 70 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4 71 3. Conditional Router Advertisements . . . . . . . . . . . . . . 5 72 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5 74 3.1.2. Source Address Selection and Conditional RAs . . . . 5 75 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 7 76 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 7 77 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9 78 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 11 79 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 12 80 3.2.5. Topologies with Dedicated Border Routers . . . . . . 12 81 3.2.6. Intra-Site Communication during Simultaneous Uplinks 82 Outage . . . . . . . . . . . . . . . . . . . . . . . 14 83 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 14 84 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 15 85 3.3.1. Connections Preservation . . . . . . . . . . . . . . 15 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 16 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 92 7.2. Informative References . . . . . . . . . . . . . . . . . 17 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 Multihoming is an obvious requirement for many enterprise networks to 99 ensure the desired level of network reliability. However, using more 100 than one ISP (and address space assigned by those ISPs) introduces 101 the problem of assigning IP addresses to hosts. In IPv4 there is no 102 choice but using [RFC1918] address space and NAT ([RFC3022]) at the 103 network edge ([RFC4116]). Using Provider Independent (PI) address 104 space is not always an option, since it requires running BGP between 105 the enterprise network and the ISPs. Administrative overhead of 106 obtaining and managing PI address space can also be a concern. As 107 IPv6 hosts can, by design, have multiple addresses of the global 108 scope ([RFC4291]), multihoming using provider address looks even 109 easier for IPv6: each ISP assigns an IPv6 block (usually /48) and 110 hosts in the enterprise network have addresses assigned from each ISP 111 block. However using IPv6 PA blocks in multihoming scenario 112 introduces some challenges, including but not limited to: 114 o Selecting the correct uplink based on the packet source address; 116 o Signaling to hosts that some source addresses should or should not 117 be used (e.g. an uplink to the ISP went down or became available 118 again). 120 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses 121 these and other related challenges in detail in relation to the 122 general multihoming scenario for enterprise networks and proposes 123 solution which relies heavily on the rule 5.5 of the default address 124 selection algorithm ([RFC6724]). The rule 5.5 makes hosts prefer 125 source addresses in a prefix advertised by the next-hop and therefore 126 is very useful in multihomed scenarios when different routers may 127 advertise different prefixes. While [RFC6724] defines the Rule 5.5 128 as optional, the recent [RFC8028] recommends that multihomed hosts 129 SHOULD support it. Unfortunately that rule has not been widely 130 implemented when this document was written. Therefore network 131 administrators in enterprise networks can't yet assume that all 132 devices in their network support the rule 5.5, especially in the 133 quite common BYOD ("Bring Your Own Device") scenario. However, while 134 it does not seem feasible to solve all the possible multihoming 135 scenarios without relying on rule 5.5, it is possible to provide IPv6 136 multihoming using provider-assigned (PA) address space for the most 137 common use cases. This document discusses how the general approach 138 described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be 139 applied to solve multihoming scenarios when: 141 o An enterprise network has two or more ISP uplinks; 142 o Those uplinks are used for Internet access in active/backup or 143 load sharing mode w/o any sophisticated traffic engineering 144 requirements; 146 o Each ISP assigns the network a subnet from its own PA address 147 space 149 o Hosts in the enterprise network are not expected to support the 150 Rule 5.5 of the default address selection algorithm ([RFC6724]). 152 2. Common Enterprise Multihoming Scenarios 154 2.1. Two ISP Uplinks, Primary and Backup 156 This scenario has the following key characteristics: 158 o The enterprise network is using uplinks to two (or more) ISPs for 159 Internet access; 161 o Each ISP assigns IPv6 PA address space for the network; 163 o Uplink(s) to one ISP is a primary (preferred) one. All other 164 uplinks are backup and are not expected to be used while the 165 primary one is operational; 167 o If the primary uplink is operational, all Internet traffic should 168 flow via that uplink; 170 o When the primary uplink fails the Internet traffic needs to flow 171 via the backup uplinks; 173 o Recovery of the primary uplink needs to trigger the traffic 174 switchover from the backup uplinks back to primary one; 176 o Hosts in the enterprise network are not expected to support the 177 Rule 5.5 of the default address selection algorithm ([RFC6724]). 179 2.2. Two ISP Uplinks, Used for Load Balancing 181 This scenario has the following key characteristics: 183 o The enterprise network is using uplinks to two (or more) ISPs for 184 Internet access; 186 o Each ISP assigns an IPv6 PA address space; 188 o All the uplinks may be used simultaneously, with the traffic flows 189 being randomly (not necessarily equally) distributed between them; 191 o Hosts in the enterprise network are not expected to support the 192 Rule 5.5 of the default address selection algorithm ([RFC6724]). 194 3. Conditional Router Advertisements 196 3.1. Solution Overview 198 3.1.1. Uplink Selection 200 As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of 201 the two main problems to be solved in the enterprise multihoming 202 scenario is the problem of the next-hop (uplink) selection based on 203 the packet source address. For example, if the enterprise network 204 has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 205 subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) 206 then packets sourced from subnet_A must be sent to ISP_A uplink while 207 packets sourced from subnet_B must be sent to ISP_B uplink. Sending 208 packets with source addresses belonging to one ISP address space to 209 another ISP might cause those packets to be filtered out if those 210 ISPs or their uplinks implement anti-spoofing ingress filtering 211 ([RFC2827] 213 While some work is being done in the Source Address Dependent Routing 214 (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]), the simplest 215 way to implement the desired functionality currently is to apply a 216 policy which selects a next-hop or an egress interface based on the 217 packet source address. Most SMB/Enterprise grade routers have such 218 functionality available currently. 220 3.1.2. Source Address Selection and Conditional RAs 222 Another problem to be solved in the multihoming scenario is the 223 source address selection on hosts. In the normal situation (all 224 uplinks are up/operational) hosts have multiple global unique 225 addresses and can rely on the default address selection algorithm 226 ([RFC6724]) to pick up a source address, while the network is 227 responsible for choosing the correct uplink based on the source 228 address selected by a host as described in Section 3.1.1. However, 229 some network topology changes (i.e. changing uplink status) might 230 affect the global reachability for packets sourced from the 231 particular prefixes and therefore such changes have to be signaled 232 back to the hosts. For example: 234 o An uplink to an ISP_A went down. Hosts should not use addresses 235 from ISP_A prefix; 237 o A primary uplink to ISP_A which was not operational has come back 238 up. Hosts should start using the source addresses from ISP_A 239 prefix. 241 [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed 242 explanation on why SLAAC (Stateless Address Autoconfiguration, 243 [RFC4862] and RAs (Router Advertisements, [RFC4861]) are the most 244 suitable mechanism for signaling network topology changes to hosts 245 and thereby influencing the source address selection. Sending a 246 router advertisement to change the preferred lifetime for a given 247 prefix provides the following functionality: 249 o deprecating addresses (by sending an RA with the 250 preferred_lifetime set to 0 in the corresponding PIO (Prefix 251 Information option, [RFC4861]) to indicate to hosts that that 252 addresses from that prefix should not be used; 254 o making a previously unused (deprecated) prefix usable again (by 255 sending an RA containing a PIO with non-zero preferred lifetime) 256 to indicate to hosts that addresses from that prefix can be used 257 again. 259 To provide the desired functionality, first-hop routers are required 260 to 262 o send RA triggered by defined event policies in response to uplink 263 status change event; and 265 o while sending periodic or solicted RAs, set the value in the given 266 RA field (e.g. PIO preferred lifetime) based on the uplink 267 status. 269 The exact definition of the 'uplink status' depends on the network 270 topology and may include conditions like: 272 o uplink interface status change; 274 o presence of a particular route in the routing table; 276 o presence of a particular route with a particular attribute (next- 277 hop, tag etc) in the routing table; 279 o protocol adjacency change. 281 etc. 283 In some scenarios, when two routers are providing first-hop 284 redundancy via VRRP (Virtual Router Redundancy Protocol, [RFC5798]), 285 the master-backup status can be considered as a condition for sending 286 RAs and changing the preferred lifetime value. See Section 3.2.2 for 287 more details. 289 If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS 290 (Router Advertisement Options for DNS Configuration, [RFC8106]) it 291 might be desirable for the conditional RAs to update the Lifetime 292 field of the RDNSS option as well. 294 The trigger is not only forcing the router to send an unsolicited RA 295 to propagate the topology changes to all hosts. Obviously the RA 296 fields values (like PIO Preferred Lifetime or DNS Server Lifetime) 297 changed by the particular trigger need to stay the same until another 298 event happens causing the value to be updated. E.g. if the ISP_A 299 uplink failure causes the prefix to be deprecated, all solicited and 300 unsolicited RAs sent by the router need to have the Preferred 301 Lifetime for that PIO set to 0 until the uplink comes back up. 303 It should be noted that the proposed solution is quite similar to the 304 existing requirement L-13 for IPv6 Customer Edge Routers ([RFC7084]) 305 and the documented behavior of homenet devices ([RFC7788]). It is 306 using the same mechanism of deprecating a prefix when the 307 corresponding uplink is not operational, applying it to enterprise 308 network scenario. 310 3.2. Example Scenarios 312 This section illustrates how the conditional RAs solution can be 313 applied to most common enterprise multihoming scenarios, described in 314 Section 2. 316 3.2.1. Single Router, Primary/Backup Uplinks 317 -------- 318 ,-------, ,' ', 319 +----+ 2001:db8:1::/48 ,' ', : : 320 | |------------------+ ISP_A +--+: : 321 2001:db8:1:1::/64 | | ', ,' : : 322 | | '-------' : : 323 H1------------------| R1 | : INTERNET : 324 | | ,-------, : : 325 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 326 | |------------------+ ISP_B +--+: : 327 +----+ ', ,' : : 328 '-------' ', ,' 329 -------- 331 Figure 1: Single Router, Primary/Backup Uplinks 333 Let's look at a simple network topology where a single router acts as 334 a border router to terminate two ISP uplinks and as a first-hop 335 router for hosts. Each ISP assigns a /48 to the network, and the 336 ISP_A uplink is a primary one, to be used for all Internet traffic, 337 while the ISP_B uplink is a backup, to be used only when the primary 338 uplink is not operational. 340 To ensure that packets with source addresses from ISP_A and ISP_B are 341 only routed to ISP_A and ISP_B uplinks respectively, the network 342 administrator needs to configure a policy on R1: 344 IF (packet_source_address is in 2001:db8:1::/48) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 345 THEN 346 default next-hop is ISP_A_uplink 348 IF (packet_source_address is in 2001:db8:2::/48) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 349 THEN 350 default next-hop is ISP_B_uplink 352 Under normal circumstances it is desirable that all traffic be sent 353 via the ISP_A uplink, therefore hosts (the host H1 in the example 354 topology figure) should be using source addresses from 355 2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 356 using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 357 until the ISP_A uplink comes back up. To achieve this the router 358 advertisement configuration on the R1 device for the interface facing 359 H1 needs to have the following policy: 361 prefix 2001:db8:1:1::/64 { 362 IF (ISP_A_uplink is up) 363 THEN 364 preferred_lifetime = 604800 365 ELSE 366 preferred_lifetime = 0 367 } 369 prefix 2001:db8:2:1::/64 { 370 IF (ISP_A_Uplink is up) 371 THEN 372 preferred_lifetime = 0 373 ELSE 374 preferred_lifetime = 604800 375 } 377 A similar policy needs to be applied to the RDNSS Lifetime if ISP_A 378 and ISP_B DNS servers are used. 380 3.2.2. Two Routers, Primary/Backup Uplinks 382 Let's look at a more complex scenario where two border routers are 383 terminating two ISP uplinks (one each), acting as redundant first-hop 384 routers for hosts. The topology is shown on Fig.2 386 -------- 387 ,-------, ,' ', 388 +----+ 2001:db8:1::/48 ,' ', : : 389 2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 390 | | R1 | ', ,' : : 391 | +----+ '-------' : : 392 H1------------------| : INTERNET : 393 | +----+ ,-------, : : 394 |_| | 2001:db8:2::/48 ,' ', : : 395 2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : 396 +----+ ', ,' : : 397 '-------' ', ,' 398 -------- 400 Figure 2: Two Routers, Primary/Backup Uplinks 402 In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 403 address space) and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B 404 address space). Each router needs to have a forwarding policy 405 configured for packets received on its hosts-facing interface: 407 IF (packet_source_address is in 2001:db8:1::/48) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 408 THEN 409 default next-hop is ISP_A_uplink 411 IF (packet_source_address is in 2001:db8:2::/48) and (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) 412 THEN 413 default next-hop is ISP_B_uplink 415 In this case there is more than one way to ensure that hosts are 416 selecting the correct source address based on the uplink status. If 417 VRRP is used to provide first-hop redundancy and the master router is 418 the one with the active uplink, then the simplest way is to use the 419 VRRP mastership as a condition for router advertisement. So, if 420 ISP_A is the primary uplink, the routers R1 and R2 need to be 421 configured in the following way: 423 R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A 424 uplink is down, then R1 becomes a backup. Router advertisements on 425 R1's interface facing H1 needs to have the following policy applied: 427 prefix 2001:db8:1:1::/64 { 428 IF (vrrp_master) 429 THEN 430 preferred_lifetime = 604800 431 ELSE 432 preferred_lifetime = 0 433 } 435 R2 is VRRP backup by default. Router advertsement on R2 interface 436 facing H1 needs to have the following policy applied: 438 prefix 2001:db8:2:1::/64 { 439 IF(vrrp_master) 440 THEN 441 preferred_lifetime = 604800 442 ELSE 443 preferred_lifetime = 0 444 } 446 If VRRP is not used or interface status tracking is not used for 447 mastership switchover, then each router needs to be able to detect 448 the uplink failure/recovery on the neighboring router, so that RAs 449 with updated preferred lifetime values are triggered. Depending on 450 the network setup various triggers like a route to the uplink 451 interface subnet or a default route received from the uplink can be 452 used. The obvious drawback of using the routing table to trigger the 453 conditional RAs is that some additional configuration is required. 455 For example, if a route to the prefix assigned to the ISP uplink is 456 used as a trigger, then the conditional RA policy would have the 457 following logic: 459 R1: 461 prefix 2001:db8:1:1::/64 { 462 IF (ISP_A_uplink is up) 463 THEN 464 preferred_lifetime = 604800 465 ELSE 466 preferred_lifetime = 0 467 } 469 R2: 471 prefix 2001:db8:2:1::/64 { 472 IF (ISP_A_uplink_route is present) 473 THEN 474 preferred_lifetime = 0 475 ELSE 476 preferred_lifetime = 604800 477 } 479 3.2.3. Single Router, Load Balancing Between Uplinks 481 Let's look at the example topology shown in Figure 1, but with both 482 uplinks used simultaneously. In this case R1 would send RAs 483 containing PIOs for both prefixes, 2001:db8:1:1::/64 and 484 2001:db8:2:1::/64, changing the preferred lifetime based on 485 particular uplink availability. If the interface status is used as 486 uplink availability indicator, then the policy logic would look like 487 the following: 489 prefix 2001:db8:1:1::/64 { 490 IF (ISP_A_uplink is up) 491 THEN 492 preferred_lifetime = 604800 493 ELSE 494 preferred_lifetime = 0 495 } 496 prefix 2001:db8:2:1::/64 { 497 IF (ISP_B_uplink is up) 498 THEN 499 preferred_lifetime = 604800 500 ELSE 501 preferred_lifetime = 0 502 } 503 R1 needs a forwarding policy to be applied to forward packets to the 504 correct uplink based on the source address similar to one described 505 in Section 3.2.1. 507 3.2.4. Two Router, Load Balancing Between Uplinks 509 In this scenario the example topology is similar to the one shown in 510 Figure 2, but both uplinks can be used at the same time. It means 511 that both R1 and R2 need to have the corresponding forwarding policy 512 to forward packets based on their source addresses. 514 Each router would send RAs with PIO for the corresponding prefix. 515 setting preferred_lifetime to a non-zero value when the ISP uplink is 516 up, and deprecating the prefix by setting the preferred lifetime to 0 517 in case of uplink failure. The uplink recovery would trigger another 518 RA with non-zero preferred lifetime to make the addresses from the 519 prefix preferred again. The example RA policy on R1 and R2 would 520 look like: 522 R1: 524 prefix 2001:db8:1:1::/64 { 525 IF (ISP_A_uplink is up) 526 THEN 527 preferred_lifetime = 604800 528 ELSE 529 preferred_lifetime = 0 530 } 532 R2: 534 prefix 2001:db8:2:1::/64 { 535 IF (ISP_B_uplink is up) 536 THEN 537 preferred_lifetime = 604800 538 ELSE 539 preferred_lifetime = 0 540 } 542 3.2.5. Topologies with Dedicated Border Routers 544 For simplicity, all topologies above show the ISP uplinks terminated 545 on the first-hop routers. Obviously, the proposed approach can be 546 used in more complex topologies when dedicated devices are used for 547 terminating ISP uplinks. In that case VRRP mastership or interface 548 status can not be used as a trigger for conditional RAs and route 549 presence as described above should be used instead. 551 Let's look at the example topology shown on the Figure 3: 553 2001:db8:1::/48 -------- 554 2001:db8:1:1::/64 ,-------, ,' ', 555 +----+ +---+ +----+ ,' ', : : 556 _| |--| |--| R3 |----+ ISP_A +---+: : 557 | | R1 | | | +----+ ', ,' : : 558 | +----+ | | '-------' : : 559 H1--------| |LAN| : INTERNET : 560 | +----+ | | ,-------, : : 561 |_| | | | +----+ ,' ', : : 562 | R2 |--| |--| R4 |----+ ISP_B +---+: : 563 +----+ +---+ +----+ ', ,' : : 564 2001:db8:2:1::/64 '-------' ', ,' 565 2001:db8:2::/48 -------- 567 Figure 3: Dedicated Border Routers 569 For example, if ISP_A is a primary uplink and ISP_B is a backup one 570 then the following policy might be used to achieve the desired 571 behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while 572 ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if 573 the uplink is non-operational): 575 R1 and R2 policy: 577 prefix 2001:db8:1:1::/64 { 578 IF (ISP_A_uplink_route is present) 579 THEN 580 preferred_lifetime = 604800 581 ELSE 582 preferred_lifetime = 0 583 } 585 prefix 2001:db8:2:1::/64 { 586 IF (ISP_A_uplink_route is present) 587 THEN 588 preferred_lifetime = 0 589 ELSE 590 preferred_lifetime = 604800 591 } 593 For the load-balancing case the policy would look slightly different: 594 each prefix has non-zero preferred_lifetime only if the correspoding 595 ISP uplink route is present: 597 prefix 2001:db8:1:1::/64 { 598 IF (ISP_A_uplink_route is present) 599 THEN 600 preferred_lifetime = 604800 601 ELSE 602 preferred_lifetime = 0 603 } 605 prefix 2001:db8:2:1::/64 { 606 IF (ISP_B_uplink_route is present) 607 THEN 608 preferred_lifetime = 604800 609 ELSE 610 preferred_lifetime = 0 611 } 613 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 615 Prefix deprecation as a result of an uplink status change might lead 616 to a situation when all global prefixes are deprecated (all ISP 617 uplinks are not operational for some reason). Even when there is no 618 Internet connectivity it might be still desirable to have intra-site 619 IPv6 connectivity (especially when the network in question is an 620 IPv6-only one). However while an address is in a deprecated state, 621 its use is discouraged, but not strictly forbidden ([RFC4862]). In 622 such a scenario all IPv6 source addresses in the candidate set 623 ([RFC6724]) are deprecated, which means that they still can be used 624 (as there is no preferred addresses available) and the source address 625 selection algorithm can pick up one of them, allowing the intra-site 626 communication. However some OSes might just fall back to IPv4 if the 627 network interface has no preferred IPv6 global addresses. Therefore 628 if intra-site connectivity is vital during simultanious outages of 629 multiple uplinks, administrators might consider using ULAs (Unique 630 Local Addresses, [RFC4193]) or provisioning additional backup uplinks 631 to protect the network from double-failure cases. 633 3.2.7. Uplink Damping 635 If an actively used uplink (primary one or one used in load balaning 636 scenario) starts flapping, it might lead to the undesirable situation 637 of flapping addresses on hosts (every time the uplink goes up hosts 638 receive an RA with non-zero preferred PIO lifetime, and every time 639 the uplink goes down all addresses in the affected prefix become 640 deprecated). This would, undoubtedly, negatively impact the user 641 experience, not to mention the impact of spikes of duplicate address 642 detection traffic every time an uplink comes back up. Therefore it's 643 recommended that router vendors implement some form of damping policy 644 for conditional RAs and either postpone sending an RA with non-zero 645 lifetime for a PIO when the uplink comes up for a number of seconds 646 or even introduce accumulated penalties/exponential backoff algorithm 647 for such delays. (In the case of a multiple simultaneous uplink 648 failure scenario, when all but one uplinks are down and the last 649 remaining is flapping it might result in all addresses being 650 deprecated for a while after the flapping uplink recovers.) 652 3.3. Solution Limitations 654 It should be noted that the proposed approach is not a silver bullet 655 for all possible multihoming scenarios. It would work very well for 656 networks with relatively simple topologies and straightforward 657 routing policies. The more complex the network topology and the 658 corresponding routing policies, the more configuration would be 659 required to implement the solution. 661 Another limitation is related to the load balancing between the 662 uplinks. In the scenario in which both uplinks are active, hosts 663 would select the source prefix using the Default Address Selection 664 algorithm ([RFC6724]), and therefore the load between two uplinks 665 most likely would not be evenly distributed. (However, the proposed 666 mechanism does allow a creative way of controlling uplinks load in 667 software defined networks where controllers might selectively 668 deprecate prefixes on some hosts but not others to move egress 669 traffic between uplinks). Also the prefix selection does not take 670 into account any other uplinks properties (such as latencyetc), so 671 egress traffic might not be sent to the nearest uplink if the 672 corresponding prefix is selected as a source. In general, if not all 673 uplinks are equal and some uplinks are expected to be preferred over 674 others, then the network administrator should ensure that prefixes 675 from non-preferred ISP(s) are kept deprecated (so primary/backup 676 setup is used). 678 3.3.1. Connections Preservation 680 The proposed solution is not designed to preserve connection state 681 after an uplink failure. If all uplinks to an ISP go down, all 682 sessions to/from addresses from that ISP address space are 683 interrupted as there is no egress path for those packets and there is 684 not return path from the Internet to the correspodning prefix. In 685 this regard it is similar to IPv4 multihoming using NAT, where an 686 uplink failure and failover to another uplink means that a public 687 IPv4 address changes and all existing connections are interrupted. 689 An uplink recovery, however, does not necessarily lead to connections 690 interruption. In the load sharing/balancing scenario an uplink 691 recovery does not affect any existing connections at all. In the 692 active/backup topology when the primary uplink recovers from the 693 failure and the backup prefix is deprecated, the existing sessions 694 (established to/from the backup ISP addresses) can be preserved if 695 the routers are configured as described in Section 3.2.1 and send 696 packets with the backup ISP source addresses to the backup uplink 697 even when the primary one is operational. As a result, the primary 698 uplink recovery makes the usage of the backup ISP addresses 699 discouraged but still possible. 701 It should be noted that in IPv4 multihoming with NAT, when the egress 702 interface is chosen without taking packet source address into account 703 (as internal hosts usually have addresses from [RFC1918] space), 704 sessions can not be preserved after an uplink recovery. 706 4. IANA Considerations 708 This memo asks the IANA for no new parameters. 710 5. Security Considerations 712 This memo introduces no new security considerations. 714 5.1. Privacy Considerations 716 This memo introduces no new privacy considerations. 718 6. Acknowledgements 720 Thanks to the following people (in alphabetical order) for their 721 review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus 722 Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave 723 Thaler. 725 7. References 727 7.1. Normative References 729 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 730 and E. Lear, "Address Allocation for Private Internets", 731 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 732 . 734 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 735 Defeating Denial of Service Attacks which employ IP Source 736 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 737 May 2000, . 739 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 740 Address Translator (Traditional NAT)", RFC 3022, 741 DOI 10.17487/RFC3022, January 2001, 742 . 744 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 745 Gill, "IPv4 Multihoming Practices and Limitations", 746 RFC 4116, DOI 10.17487/RFC4116, July 2005, 747 . 749 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 750 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 751 . 753 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 754 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 755 2006, . 757 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 758 Address Autoconfiguration", RFC 4862, 759 DOI 10.17487/RFC4862, September 2007, 760 . 762 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 763 "Default Address Selection for Internet Protocol Version 6 764 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 765 . 767 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 768 Hosts in a Multi-Prefix Network", RFC 8028, 769 DOI 10.17487/RFC8028, November 2016, 770 . 772 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 773 "IPv6 Router Advertisement Options for DNS Configuration", 774 RFC 8106, DOI 10.17487/RFC8106, March 2017, 775 . 777 7.2. Informative References 779 [I-D.ietf-rtgwg-dst-src-routing] 780 Lamparter, D. and A. Smirnov, "Destination/Source 781 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 782 progress), October 2017. 784 [I-D.ietf-rtgwg-enterprise-pa-multihoming] 785 Baker, F., Bowers, C., and J. Linkova, "Enterprise 786 Multihoming using Provider-Assigned Addresses without 787 Network Prefix Translation: Requirements and Solution", 788 draft-ietf-rtgwg-enterprise-pa-multihoming-07 (work in 789 progress), June 2018. 791 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 792 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 793 DOI 10.17487/RFC4861, September 2007, 794 . 796 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 797 Version 3 for IPv4 and IPv6", RFC 5798, 798 DOI 10.17487/RFC5798, March 2010, 799 . 801 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 802 Requirements for IPv6 Customer Edge Routers", RFC 7084, 803 DOI 10.17487/RFC7084, November 2013, 804 . 806 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 807 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 808 2016, . 810 Appendix A. Change Log 812 Initial Version: July 2017 814 Authors' Addresses 816 Jen Linkova 817 Google 818 Mountain View, California 94043 819 USA 821 Email: furry@google.com 823 Massimiliano Stucchi 824 RIPE NCC 825 Stationsplein, 11 826 Amsterdam 1012 AB 827 The Netherlands 829 Email: mstucchi@ripe.net