idnits 2.17.1 draft-ietf-v6ops-conditional-ras-03.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 4 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-rtgwg-enterprise-pa-multihoming], [RFC8028]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 30, 2018) is 2219 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'RFC4116' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC4218' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC4219' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 740, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-dst-src-routing' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'RFC5533' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC5534' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'RFC7788' is defined on line 802, but no explicit reference was found in the text == 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-03 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 21 warnings (==), 2 comments (--). 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: October 1, 2018 RIPE NCC 6 March 30, 2018 8 Using Conditional Router Advertisements for Enterprise Multihoming 9 draft-ietf-v6ops-conditional-ras-03 11 Abstract 13 This document discusses 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. 20 [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to 21 this problem by introducing a new routing functionality (Source 22 Address Dependent Routing) to solve the uplink selection issue and 23 using Router Advertisements to influence the host source address 24 selection. While the above-mentioned document focuses on solving the 25 general problem and on covering various complex use cases, this 26 document describes how the solution proposed in 27 [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited 28 number of common use cases. In particular, the focus is on scenarios 29 where an enterprise network has two Internet uplinks used either in 30 primary/backup mode or simultaneously and hosts in that network might 31 not yet 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 October 1, 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 . . . . . . . . . 8 78 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 10 79 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 11 80 3.2.5. Topologies with Dedicated Border Routers . . . . . . 11 81 3.2.6. Intra-Site Communication during Simultaneous Uplinks 82 Outage . . . . . . . . . . . . . . . . . . . . . . . 13 83 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13 84 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 14 85 3.3.1. Connections Preservation . . . . . . . . . . . . . . 14 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 15 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 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. Using Provider Independent (PI) address space is not 104 always an option as it requires running BGP between the enterprise 105 network and the ISPs, not mentioning administrative overhead of 106 obtaining and managing PI address space. As IPv6 host can, by 107 design, have multiple addresses of the global scope, multihoming 108 using provider address looks even easier for IPv6: each ISP assigns 109 an IPv6 block (usually /48) and hosts in the enterprise network have 110 addresses assigned from each ISP block. However using IPv6 PA blocks 111 in multihoming scenario introduces some challenges, including but not 112 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 details in relation to the 122 general multihoming scenario for enterprise networks. Unfortunately 123 the proposed solution heavily relies on the rule 5.5 of the default 124 address selection algorithm ([RFC6724]) which has not been widely 125 implemented at the moment this document was written. Therefore 126 network administrators in enterprise networks can't yet assume that 127 all devices in their network support the rule 5.5, especially in the 128 quite common BYOD ("Bring Your Own Device") scenario. However, while 129 it does not seem feasible to solve all the possible multihoming 130 scenarios without reliying on rule 5.5, it is possible to provide 131 IPv6 multihoming using provider-assigned (PA) address space for the 132 most common use cases. This document discusses how the general 133 solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can 134 be applied to scenarios when: 136 o An enterprise network has two or more ISP uplinks; 138 o Those uplinks are used for Internet access in active/backup or 139 load sharing mode w/o any soficticated traffic engineering 140 requirements; 142 o Each ISP assigns the network a subnet from its own PA address 143 space 145 o Hosts in the enterprise network are not expected to support the 146 Rule 5.5 of the default address selection algorithm ([RFC6724]). 148 2. Common Enterprise Multihoming Scenarios 150 2.1. Two ISP Uplinks, Primary and Backup 152 This scenario has the following key characteristics: 154 o The enterprise network is using uplinks to two (or more) ISPs for 155 Internet access; 157 o Each ISP assigns IPv6 PA address space for the network; 159 o Uplink(s) to one ISP is a primary (preferred) one. All other 160 uplinks are backup and are not expected to be used while the 161 primary one is operational; 163 o If the primary uplink is operational, all Internet traffic should 164 flow via that uplink; 166 o When the primary uplink fails the Internet traffic needs to flow 167 via the backup uplinks; 169 o Recovery of the primary uplink needs to trigger the traffic 170 switchover from the backup uplinks back to primary one; 172 o Hosts in the enterprise network are not expected to support the 173 Rule 5.5 of the default address selection algorithm ([RFC6724]). 175 2.2. Two ISP Uplinks, Used for Load Balancing 177 This scenario has the following key characteristics: 179 o The enterprise network is using uplinks to two (or more) ISPs for 180 Internet access; 182 o Each ISP assigns an IPv6 PA address space; 184 o All the uplinks may be used simultaneously, with the traffic flows 185 being randomly (not nessesary equally) distributed between them; 187 o Hosts in the enterprise network are not expected to support the 188 Rule 5.5 of the default address selection algorithm ([RFC6724]). 190 3. Conditional Router Advertisements 192 3.1. Solution Overview 194 3.1.1. Uplink Selection 196 As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of 197 the two main problems to be solved in the enterprise multihoming 198 scenario is the problem of the next-hop (uplink) selection based on 199 the packet source address. For example, if the enterprise network 200 has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 201 subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) 202 then packets sourced from subnet_A must be sent to ISP_A uplink while 203 packets sourced from subnet_B must be sent to ISP_B uplink. 205 While some work is being done in the Source Address Dependent Routing 206 (SADR) area, the simplest way to implement the desired functionality 207 currently is to apply a policy which selects a next-hop or an egress 208 interface based on the packet source address. Most of the SMB/ 209 Enterprise grade routers have such functionality available currently. 211 3.1.2. Source Address Selection and Conditional RAs 213 Another problem to be solved in the multihoming scenario is the 214 source address selection on hosts. In the normal situation (all 215 uplinks are up/operational) hosts have multiple global unique 216 addresses and can rely on the default address selection algorithm 217 ([RFC6724]) to pick up a source address, while the network is 218 responsible for choosing the correct uplink based on the source 219 address selected by a host as described in Section 3.1.2. However, 220 some network topology changes (i.e. changing uplink status) might 221 affect the global reachability for packets sourced from the 222 particular prefixes and therefore such changes have to be signaled 223 back to the hosts. For example: 225 o An uplink to an ISP_A went down. Hosts should not use addresses 226 from ISP_A prefix; 228 o A primary uplink to ISP_A which was not operational has come back 229 up. Hosts should start using the source addresses from ISP_A 230 prefix. 232 [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed 233 explanation on why SLAAC and router advertisements are the most 234 suitable mechanism for signaling network topology changes to hosts 235 and thereby influencing the source address selection. Sending a 236 router advertisement to change the preferred lifetime for a given 237 prefix provides the following functionality: 239 o deprecating addresses (by sending an RA with the 240 preferred_lifetime set to 0 in the corresponding POI) to indicate 241 to hosts that that addresses from that prefix should not be used; 243 o making a previously unused (deprecated) prefix usable again (by 244 sending an RA containing a POI with non-zero preferred lifetime) 245 to indicate to hosts that addresses from that prefix can be used 246 again. 248 To provide the desired functionality, first-hop routers are required 249 to 251 o send RA triggered by defined event policies in response to uplink 252 status change event; and 254 o while sending periodic or solicted RAs, set the value in the given 255 RA field (e.g. PIO preferred lifetime) based on the uplink 256 status. 258 The exact definition of the 'uplink status' depends on the network 259 topology and may include conditions like: 261 o uplink interface status change; 263 o presence of a particular route in the routing table; 265 o presence of a particular route with a particular attribute (next- 266 hop, tag etc) in the routing table; 268 o protocol adjacency change. 270 etc. 272 In some scenarios, when two routers are providing first-hop 273 redundancy via VRRP, the master-backup status can be considered as a 274 condition for sending RAs and changing the preferred lifetime value. 275 See Section 3.2.2 for more details. 277 If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS 278 [RFC8106] it might be desirable for the conditional RAs to update the 279 Lifetime field of the RDNSS option as well. 281 The trigger is not only forcing the router to send an unsolicited RA 282 to propagate the topology changes to all hosts. Obviously the RA 283 fields values (like PIO Preferred Lifetime or DNS Server Lifetime) 284 changed by the particular trigger MUST stay the same until another 285 event happens causing the value to be updated. E.g. if the ISP_A 286 uplink failure causes the prefix to be deprecated all solicited and 287 unsolicited RAs sent by the router MUST have the Preferred Lifetime 288 for that POI set to 0 until the uplink comes back up. 290 It should be noted that the proposed solution is quite similar to the 291 existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the 292 documented behaviour of homenet devices. It is using the same 293 mechanism of deprecating a prefix when the corresponding uplink is 294 not operational, applying it to enterprise network scenario. 296 3.2. Example Scenarios 298 This section illustrates how the conditional RAs solution can be 299 applied to most common enterprise multihoming scenarios, described in 300 Section 2. 302 3.2.1. Single Router, Primary/Backup Uplinks 304 -------- 305 ,-------, ,' ', 306 +----+ 2001:db8:1::/48 ,' ', : : 307 | |------------------+ ISP_A +--+: : 308 2001:db8:1:1::/64 | | ', ,' : : 309 | | '-------' : : 310 H1------------------| R1 | : INTERNET : 311 | | ,-------, : : 312 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 313 | |------------------+ ISP_B +--+: : 314 +----+ ', ,' : : 315 '-------' ', ,' 316 -------- 318 Figure 1: Single Router, Primary/Backup Uplinks 320 Let's look at a simple network topology where a single router acts as 321 a border router to terminate two ISP uplinks and as a first-hop 322 router for hosts. Each ISP assigns a /48 to the network, and the 323 ISP_A uplink is a primary one, to be used for all Internet traffic, 324 while the ISP_B uplink is a backup, to be used only when the primary 325 uplink is not operational. 327 To ensure that packets with source addresses from ISP_A and ISP_B are 328 only routed to ISP_A and ISP_B uplinks respectively, the network 329 administrator needs to configure a policy on R1: 331 if { 332 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 333 packet_source_address is in 2001:db8:1::/48 334 } then { 335 default next-hop is ISP_A_uplink 336 } 337 if { 338 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 339 packet_source_address is in 2001:db8:2::/48 340 } 341 then { 342 default next-hop is ISP_B_uplink 343 } 345 Under normal circumstances it is desirable that all traffic be sent 346 via the ISP_A uplink, therefore hosts (the host H1 in the example 347 topology figure) should be using source addresses from 348 2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 349 using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 350 until the ISP_A uplink comes back up. To achieve this the router 351 advertisement configuration on the R1 device for the interface facing 352 H1 needs to have the following policy: 354 prefix 2001:db8:1:1::/64 { 355 if ISP_A_uplink is up 356 then preferred_lifetime = 604800 357 else preferred_lifetime = 0 358 } 360 prefix 2001:db8:2:1::/64 { 361 if ISP_A_Uplink is up 362 then preferred_lifetime = 0 363 else preferred_lifetime = 604800 364 } 366 A similar policy needs to be applied to the RDNSS Lifetime if ISP_A 367 and ISP_B DNS servers are used. 369 3.2.2. Two Routers, Primary/Backup Uplinks 371 Let's look at a more complex scenario where two border routers are 372 terminating two ISP uplinks (one each), acting as redundant first-hop 373 routers for hosts. The topology is shown on Fig.2 374 -------- 375 ,-------, ,' ', 376 +----+ 2001:db8:1::/48 ,' ', : : 377 2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 378 | | R1 | ', ,' : : 379 | +----+ '-------' : : 380 H1------------------| : INTERNET : 381 | +----+ ,-------, : : 382 |_| | 2001:db8:2::/48 ,' ', : : 383 2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : 384 +----+ ', ,' : : 385 '-------' ', ,' 386 -------- 388 Figure 2: Two Routers, Primary/Backup Uplinks 390 In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 391 address space) and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B 392 address space). Each router needs to have a forwarding policy 393 configured for packets received on its hosts-facing interface: 395 if { 396 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 397 packet_source_address is in 2001:db8:1::/48 398 } then { 399 default next-hop is ISP_A_uplink 400 } 401 if { 402 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 403 packet_source_address is in 2001:db8:2::/48 404 } then { 405 default next-hop is ISP_B_uplink 406 } 408 In this case there is more than one way to ensure that hosts are 409 selecting the correct source address based on the uplink status. If 410 VRRP is used to provide first-hop redundancy and the master router is 411 the one with the active uplink, then the simplest way is to use the 412 VRRP mastership as a condition for router advertisement. So, if 413 ISP_A is the primary uplink, the routers R1 and R2 need to be 414 configured in the following way: 416 R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A 417 uplink is down, then R1 becomes a backup. Router advertisements on 418 R1's interface facing H1 needs to have the following policy applied: 420 prefix 2001:db8:1:1::/64 { 421 if vrrp_master then preferred_lifetime = 604800 422 else preferred_lifetime = 0 423 } 425 R2 is VRRP backup by default. Router advertsement on R2 interface 426 facing H1 needs to have the following policy applied: 428 prefix 2001:db8:2:1::/64 { 429 if vrrp_master then preferred_lifetime = 604800 430 else preferred_lifetime = 0 431 } 433 If VRRP is not used or interface status tracking is not used for 434 mastership switchover, then each router needs to be able to detect 435 the uplink failure/recovery on the neighboring router, so that RAs 436 with updated preferred lifetime values are triggered. Depending on 437 the network setup various triggers like a route to the uplink 438 interface subnet or a default route received from the uplink can be 439 used. The obvious drawback of using the routing table to trigger the 440 conditional RAs is that some additional configuration is required. 441 For example, if a route to the prefix assigned to the ISP uplink is 442 used as a trigger, then the conditional RA policy would have the 443 following logic: 445 R1: 447 prefix 2001:db8:1:1::/64 { 448 if ISP_A_uplink is up then preferred_lifetime = 604800 449 else preferred_lifetime = 0 450 } 452 R2: 454 prefix 2001:db8:2:1::/64 { 455 if ISP_A_uplink_route is present then preferred_lifetime = 0 456 else preferred_lifetime = 604800 457 } 459 3.2.3. Single Router, Load Balancing Between Uplinks 461 Let's look at the example topology shown in Figure 1, but with both 462 uplinks used simultaneously. In this case R1 would send RAs 463 containing PIOs for both prefixes, 2001:db8:1:1::/64 and 464 2001:db8:2:1::/64, changing the preferred lifetime based on 465 particular uplink availability. If the interface status is used as 466 uplink availability indicator, then the policy logic would look like 467 the following: 469 prefix 2001:db8:1:1::/64 { 470 if ISP_A_uplink is up then preferred_lifetime = 604800 471 else preferred_lifetime = 0 472 } 473 prefix 2001:db8:2:1::/64 { 474 if ISP_B_uplink is up then preferred_lifetime = 604800 475 else preferred_lifetime = 0 476 } 478 R1 needs a forwarding policy to be applied to forward packets to the 479 correct uplink based on the source address as described in 480 Section 3.2.1. 482 3.2.4. Two Router, Load Balancing Between Uplinks 484 In this scenario the example topology is similar to the one shown in 485 Figure 2, but both uplinks can be used at the same time. It means 486 that both R1 and R2 need to have the corresponding forwarding policy 487 to forward packets based on their source addresses. 489 Each router would send RAs with POI for the corresponding prefix. 490 setting preferred_lifetime to a non-zero value when the ISP uplink is 491 up, and deprecating the prefix by setting the preferred lifetime to 0 492 in case of uplink failure. The uplink recovery would trigger another 493 RA with non-zero preferred lifetime to make the addresses from the 494 prefix preferred again. The example RA policy on R1 and R2 would 495 look like: 497 R1: 499 prefix 2001:db8:1:1::/64 { 500 if ISP_A_uplink is up then preferred_lifetime = 604800 501 else preferred_lifetime = 0 502 } 504 R2: 506 prefix 2001:db8:2:1::/64 { 507 if ISP_B_uplink is up then preferred_lifetime = 604800 508 else preferred_lifetime = 0 509 } 511 3.2.5. Topologies with Dedicated Border Routers 513 For simplicity reasons all topologies below show the ISP uplinks 514 terminated on the first-hop routers. Obviously, the proposed 515 approach can be used in more complex topologies when dedicated 516 devices are used for terminating ISP uplinks. In that case VRRP 517 mastership or inteface status can not be used as a trigger for 518 conditional RAs and route presence as described above should be used 519 instead. 521 Let's look at the example topology shown on the Figure 3: 523 2001:db8:1::/48 -------- 524 2001:db8:1:1::/64 ,-------, ,' ', 525 +----+ +---+ +----+ ,' ', : : 526 _| |--| |--| R3 |----+ ISP_A +---+: : 527 | | R1 | | | +----+ ', ,' : : 528 | +----+ | | '-------' : : 529 H1--------| |LAN| : INTERNET : 530 | +----+ | | ,-------, : : 531 |_| | | | +----+ ,' ', : : 532 | R2 |--| |--| R4 |----+ ISP_B +---+: : 533 +----+ +---+ +----+ ', ,' : : 534 2001:db8:2:1::/64 '-------' ', ,' 535 2001:db8:2::/48 -------- 537 Figure 3: Dedicated Border Routers 539 For example, if ISP_A is a primary uplink and ISP_B is a backup one 540 then the following policy might be used to achieve the desired 541 behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while 542 ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if 543 the uplink is non-operational): 545 R1 and R2 policy: 547 prefix 2001:db8:1:1::/64 { 548 if ISP_A_uplink_route is present then preferred_lifetime = 604800 549 else preferred_lifetime = 0 550 } 551 prefix 2001:db8:2:1::/64 { 552 if ISP_A_uplink_route is present then preferred_lifetime = 0 553 else preferred_lifetime = 604800 554 } 556 For load-balancing case the policy would look slightly different: 557 each prefix has non-zero preferred_lifetime only if the correspoding 558 ISP uplink route is present: 560 prefix 2001:db8:1:1::/64 { 561 if ISP_A_uplink_route is present then preferred_lifetime = 604800 562 else preferred_lifetime = 0 563 } 564 prefix 2001:db8:2:1::/64 { 565 if ISP_B_uplink_route is present then preferred_lifetime = 604800 566 else preferred_lifetime = 0 567 } 569 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 571 Prefix deprecation as a result of an uplink status change might lead 572 to a situation when all global prefixes are deprecated (all ISP 573 uplinks are not operational for some reason). Even when there is no 574 Internet connectivity it might be still desirable to have intra-site 575 IPv6 connectivity (especially when the network in question is an 576 IPv6-only one). However while an address is in a deprecated state, 577 its use is discouraged, but not strictly forbidden ([RFC4862]). In 578 such scenario all IPv6 source addresses in the candidate set 579 ([RFC6724]) are deprecated which means that they still can be used 580 (as there is no preferred addresses available) and the source address 581 selection algorith can pick up one of them, allowing the intra-site 582 communication. However some OSes might just fall back to IPv4 if the 583 network interface has no preferred IPv6 global addresses. Therefore 584 if intra-site connectivity is vital during simultanious outages of 585 multiple uplinks, administrators might consider using ULAs or 586 provisioning additional backup uplinks to protect the network from 587 double-failure cases. 589 3.2.7. Uplink Damping 591 If an actively used uplink (primary one or one used in load balaning 592 scenario) starts flapping, it might lead to undesirable situation of 593 flapping addresses on hosts (every time the uplink goes up hosts 594 receive an RA with non-zerop preferred PIO lifetime, and every time 595 the uplink goes down all address in the affected prefix become 596 deprecated). Undoubtedly it would negatively impact user experience, 597 not mentioning spikes of DAD traffic every time an uplink comes back 598 up. Therefore it's recommended that router vendors implement some 599 form of damping policy for conditional RAs and either postpone 600 sending an RA with non-zero lifetime for a POI when the uplink comes 601 up for a number of seconds or even introduce accumulated penalties/ 602 exponential backoff algorithm for such delays. (In the case of 603 multiple simultaneous uplink failure scenario, when all but one 604 uplinks are down and the last remaining is flapping it might result 605 in all addresses being deprecated for a while after the flapping 606 uplink recovers.) 608 3.3. Solution Limitations 610 It should be noted that the proposed approach is not a silver bullet 611 for all possible multihoming scenarios. The main goal is to solve 612 some common use cases so it would suit very well relatively simple 613 topologies with straightforward policies. The more complex the 614 network topology and the corresponding routing policies more 615 configuration would be required to implement the solution. 617 Another limitation is related to the load balancing between the 618 uplinks. In that scenario when both uplinks are active hosts would 619 select the source prefix using the Default Address Selection 620 algorithm ([RFC6724]) and therefore the load between two uplinks most 621 likely would not be evenly distributed. (However the proposed 622 mechanism does allow a creative way of controlling uplinks load in 623 SDN networks where controllers might selectively deprecate prefixes 624 on some hosts but not others to move egress traffic between uplinks). 625 Also the prefix selection does not take into account any other 626 uplinks properties (such as RTT etc) so egress traffic might not be 627 sent to the nearest uplink if the corresponding prefix is selected as 628 a source. In general if not all uplinks are equal and some uplinks 629 are expected to be preferred over others then the network 630 adminitrator should ensure that prefixes from non-preferred ISP(s) 631 are kept deprecated (so primary/backup setup is used). 633 3.3.1. Connections Preservation 635 The proposed solution is not designed to preserve connections state 636 after an uplink failure. If all uplinks to an ISP go down all 637 sessions to/from addresses from that ISP address space are 638 interrupted as there is no egress path for those packets and there is 639 not return path from Internet to the correspodning prefix. In this 640 regard it is similar to IPv4 multihoming using NAT, where an uplink 641 failure and failover to another uplink means that a public IPv4 642 address changes and all existing connections are interrupted. 644 An uplink recovery, however, does not nessesary leads to connections 645 interruption. In the load sharing/balancing scenario an uplink 646 recovery does not affect any existing connections at all. In the 647 active/backup topology when the primary uplink recovers from the 648 failure and the backup prefix is deprectaed, the existing sessions 649 (established to/from the backup ISP addresses) can be preserved if 650 the routers are configured as described in Section 3.2.1 and send 651 packets with the backup ISP source addresses to the backup uplink 652 even when the primary one is operational. As a result, the primary 653 uplink recovery makes the usage of the backup ISP addresses 654 discouraged but still possible. 656 It should be noted that in IPv4 multihoming with NAT, when the egress 657 interface is chosen without taking packet source address into account 658 (as internal hosts usually have addresses from [RFC1918] space), 659 sessions can not be preserved after an uplink recovery. 661 4. IANA Considerations 663 This memo asks the IANA for no new parameters. 665 5. Security Considerations 667 This memo introduces no new security considerations. 669 5.1. Privacy Considerations 671 This memo introduces no new privacy considerations. 673 6. Acknowledgements 675 Thanks to the following people (in alphabetical order) for their 676 review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus 677 Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave 678 Thaler. 680 7. References 682 7.1. Normative References 684 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 685 and E. Lear, "Address Allocation for Private Internets", 686 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 687 . 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, 691 DOI 10.17487/RFC2119, March 1997, 692 . 694 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 695 Defeating Denial of Service Attacks which employ IP Source 696 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 697 May 2000, . 699 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 700 Address Translator (Traditional NAT)", RFC 3022, 701 DOI 10.17487/RFC3022, January 2001, 702 . 704 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 705 Multihoming Architectures", RFC 3582, 706 DOI 10.17487/RFC3582, August 2003, 707 . 709 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 710 Gill, "IPv4 Multihoming Practices and Limitations", 711 RFC 4116, DOI 10.17487/RFC4116, July 2005, 712 . 714 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 715 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 716 . 718 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 719 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 720 October 2005, . 722 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 723 Should Think About", RFC 4219, DOI 10.17487/RFC4219, 724 October 2005, . 726 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 727 Address Autoconfiguration", RFC 4862, 728 DOI 10.17487/RFC4862, September 2007, 729 . 731 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 732 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 733 . 735 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 736 "Default Address Selection for Internet Protocol Version 6 737 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 738 . 740 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 741 and D. Wing, "IPv6 Multihoming without Network Address 742 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 743 . 745 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 746 Hosts in a Multi-Prefix Network", RFC 8028, 747 DOI 10.17487/RFC8028, November 2016, 748 . 750 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 751 "IPv6 Router Advertisement Options for DNS Configuration", 752 RFC 8106, DOI 10.17487/RFC8106, March 2017, 753 . 755 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 756 (IPv6) Specification", STD 86, RFC 8200, 757 DOI 10.17487/RFC8200, July 2017, 758 . 760 7.2. Informative References 762 [I-D.ietf-rtgwg-dst-src-routing] 763 Lamparter, D. and A. Smirnov, "Destination/Source 764 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 765 progress), October 2017. 767 [I-D.ietf-rtgwg-enterprise-pa-multihoming] 768 Baker, F., Bowers, C., and J. Linkova, "Enterprise 769 Multihoming using Provider-Assigned Addresses without 770 Network Prefix Translation: Requirements and Solution", 771 draft-ietf-rtgwg-enterprise-pa-multihoming-03 (work in 772 progress), February 2018. 774 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 775 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 776 2004, . 778 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 779 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 780 DOI 10.17487/RFC4861, September 2007, 781 . 783 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 784 Extensions for Stateless Address Autoconfiguration in 785 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 786 . 788 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 789 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 790 June 2009, . 792 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 793 Locator Pair Exploration Protocol for IPv6 Multihoming", 794 RFC 5534, DOI 10.17487/RFC5534, June 2009, 795 . 797 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 798 Requirements for IPv6 Customer Edge Routers", RFC 7084, 799 DOI 10.17487/RFC7084, November 2013, 800 . 802 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 803 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 804 2016, . 806 Appendix A. Change Log 808 Initial Version: July 2017 810 Authors' Addresses 812 Jen Linkova 813 Google 814 Mountain View, California 94043 815 USA 817 Email: furry@google.com 819 Massimiliano Stucchi 820 RIPE NCC 821 Stationsplein, 11 822 Amsterdam 1012 AB 823 The Netherlands 825 Email: mstucchi@ripe.net