idnits 2.17.1 draft-ietf-v6ops-conditional-ras-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 18, 2018) is 2228 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC4116' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC4218' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC4219' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-dst-src-routing' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC5533' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC5534' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'RFC7788' is defined on line 754, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == 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: 3 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: September 19, 2018 RIPE NCC 6 March 18, 2018 8 Using Conditional Router Advertisements for Enterprise Multihoming 9 draft-ietf-v6ops-conditional-ras-02 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 September 19, 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 . . . . . . . . . . . 3 69 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 3 70 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4 71 3. Conditional Router Advertisements . . . . . . . . . . . . . . 4 72 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4 73 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 4 74 3.1.2. Source Address Selection and Conditional RAs . . . . 5 75 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . 10 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 . . . . . . . . . . . . . . . . . . 13 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 91 7.2. Informative References . . . . . . . . . . . . . . . . . 16 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 95 1. Introduction 97 Multihoming is an obvious requirement for many enterprise networks to 98 ensure the desired level of network reliability. However, using more 99 than one ISP (and address space assigned by those ISPs) introduces 100 the problem of assigning IP addresses to hosts. In IPv4 there is no 101 choice but using [RFC1918] address space and NAT ([RFC3022]) at the 102 network edge. Using Provider Independent (PI) address space is not 103 always an option as it requires running BGP between the enterprise 104 network and the ISPs, not mentioning administrative overhead of 105 obtaining and managing PI address space. As IPv6 host can, by 106 design, have multiple addresses of the global scope, multihoming 107 using provider address looks even easier for IPv6: each ISP assigns 108 an IPv6 block (usually /48) and hosts in the enterprise network have 109 addresses assigned from each ISP block. However using IPv6 PA blocks 110 in multihoming scenario introduces some challenges, including but not 111 limited to: 113 o Selecting the correct uplink based on the packet source address; 115 o Signaling to hosts that some source addresses should or should not 116 be used (e.g. an uplink to the ISP went down or became available 117 again). 119 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses 120 these and other related challenges in details in relation to the 121 general multihoming scenario for enterprise networks. Unfortunately 122 the proposed solution heavily relies on the rule 5.5 of the default 123 address selection algorithm ([RFC6724]) which has not been widely 124 implemented at the moment this document was written. Therefore 125 network administrators in enterprise networks can't yet assume that 126 all devices in their network support the rule 5.5, especially in the 127 quite common BYOD ("Bring Your Own Device") scenario. However, while 128 it does not seem feasible to solve all the possible multihoming 129 scenarios without reliying on rule 5.5, it is possible to provide 130 IPv6 multihoming using provider-assigned (PA) address space for the 131 most common use cases. This document discusses how the general 132 solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can 133 be applied to those two specific cases. 135 2. Common Enterprise Multihoming Scenarios 137 2.1. Two ISP Uplinks, Primary and Backup 139 This scenario has the following key characteristics: 141 o The enterprise network is using uplinks to two (or more) ISPs for 142 Internet access; 144 o Each ISP assigns IPv6 PA address space for the network; 146 o Uplink(s) to one ISP is a primary (preferred) one. All other 147 uplinks are backup and are not expected to be used while the 148 primary one is operational; 150 o If the primary uplink is operational, all Internet traffic should 151 flow via that uplink; 153 o When the primary uplink fails the Internet traffic needs to flow 154 via the backup uplinks; 156 o Recovery of the primary uplink needs to trigger the traffic 157 switchover from the backup uplinks back to primary one. 159 2.2. Two ISP Uplinks, Used for Load Balancing 161 This scenario has the following key characteristics: 163 o The enterprise network is using uplinks to two (or more) ISPs for 164 Internet access; 166 o Each ISP assigns an IPv6 PA address space; 168 o All the uplinks may be used simultaneously, with the traffic flows 169 being randomly (not nessesary equally) distributed between them. 171 3. Conditional Router Advertisements 173 3.1. Solution Overview 175 3.1.1. Uplink Selection 177 As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of 178 the two main problems to be solved in the enterprise multihoming 179 scenario is the problem of the next-hop (uplink) selection based on 180 the packet source address. For example, if the enterprise network 181 has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 182 subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) 183 then packets sourced from subnet_A must be sent to ISP_A uplink while 184 packets sourced from subnet_B must be sent to ISP_B uplink. 186 While some work is being done in the Source Address Dependent Routing 187 (SADR) area, the simplest way to implement the desired functionality 188 currently is to apply a policy which selects a next-hop or an egress 189 interface based on the packet source address. Most of the SMB/ 190 Enterprise grade routers have such functionality available currently. 192 3.1.2. Source Address Selection and Conditional RAs 194 Another problem to be solved in the multihoming scenario is the 195 source address selection on hosts. In the normal situation (all 196 uplinks are up/operational) hosts have multiple global unique 197 addresses and can rely on the default address selection algorithm 198 ([RFC6724]) to pick up a source address, while the network is 199 responsible for choosing the correct uplink based on the source 200 address selected by a host as described in Section 3.1.2. However, 201 some network topology changes (i.e. changing uplink status) might 202 affect the global reachability for packets sourced from the 203 particular prefixes and therefore such changes have to be signaled 204 back to the hosts. For example: 206 o An uplink to an ISP_A went down. Hosts should not use addresses 207 from ISP_A prefix; 209 o A primary uplink to ISP_A which was not operational has come back 210 up. Hosts should start using the source addresses from ISP_A 211 prefix. 213 [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed 214 explanation on why SLAAC and router advertisements are the most 215 suitable mechanism for signaling network topology changes to hosts 216 and thereby influencing the source address selection. Sending a 217 router advertisement to change the preferred lifetime for a given 218 prefix provides the following functionality: 220 o deprecating addresses (by sending an RA with the 221 preferred_lifetime set to 0 in the corresponding POI) to indicate 222 to hosts that that addresses from that prefix should not be used; 224 o making a previously unused (deprecated) prefix usable again (by 225 sending an RA containing a POI with non-zero preferred lifetime) 226 to indicate to hosts that addresses from that prefix can be used 227 again. 229 To provide the desired functionality, first-hop routers are required 230 to 232 o send RA triggered by defined event policies in response to uplink 233 status change event; and 235 o while sending periodic or solicted RAs, set the value in the given 236 RA field (e.g. PIO preferred lifetime) based on the uplink 237 status. 239 The exact definition of the 'uplink status' depends on the network 240 topology and may include conditions like: 242 o uplink interface status change; 244 o presence of a particular route in the routing table; 246 o presence of a particular route with a particular attribute (next- 247 hop, tag etc) in the routing table; 249 o protocol adjacency change. 251 etc. 253 In some scenarios, when two routers are providing first-hop 254 redundancy via VRRP, the master-backup status can be considered as a 255 condition for sending RAs and changing the preferred lifetime value. 256 See Section 3.2.2 for more details. 258 If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS 259 [RFC8106] it might be desirable for the conditional RAs to update the 260 Lifetime field of the RDNSS option as well. 262 The trigger is not only forcing the router to send an unsolicited RA 263 to propagate the topology changes to all hosts. Obviously the RA 264 fields values (like PIO Preferred Lifetime or DNS Server Lifetime) 265 changed by the particular trigger MUST stay the same until another 266 event happens causing the value to be updated. E.g. if the ISP_A 267 uplink failure causes the prefix to be deprecated all solicited and 268 unsolicited RAs sent by the router MUST have the Preferred Lifetime 269 for that POI set to 0 until the uplink comes back up. 271 It should be noted that the proposed solution is quite similar to the 272 existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the 273 documented behaviour of homenet devices. It is using the same 274 mechanism of deprecating a prefix when the corresponding uplink is 275 not operational, applying it to enterprise network scenario. 277 3.2. Example Scenarios 279 This section illustrates how the conditional RAs solution can be 280 applied to most common enterprise multihoming scenarios, described in 281 Section 2. 283 3.2.1. Single Router, Primary/Backup Uplinks 285 -------- 286 ,-------, ,' ', 287 +----+ 2001:db8:1::/48 ,' ', : : 288 | |------------------+ ISP_A +--+: : 289 2001:db8:1:1::/64 | | ', ,' : : 290 | | '-------' : : 291 H1------------------| R1 | : INTERNET : 292 | | ,-------, : : 293 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 294 | |------------------+ ISP_B +--+: : 295 +----+ ', ,' : : 296 '-------' ', ,' 297 -------- 299 Figure 1: Single Router, Primary/Backup Uplinks 301 Let's look at a simple network topology where a single router acts as 302 a border router to terminate two ISP uplinks and as a first-hop 303 router for hosts. Each ISP assigns a /48 to the network, and the 304 ISP_A uplink is a primary one, to be used for all Internet traffic, 305 while the ISP_B uplink is a backup, to be used only when the primary 306 uplink is not operational. 308 To ensure that packets with source addresses from ISP_A and ISP_B are 309 only routed to ISP_A and ISP_B uplinks respectively, the network 310 administrator needs to configure a policy on R1: 312 if { 313 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 314 packet_source_address is in 2001:db8:1::/48 315 } then { 316 default next-hop is ISP_A_uplink 317 } 318 if { 319 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 320 packet_source_address is in 2001:db8:2::/48 321 } 322 then { 323 default next-hop is ISP_B_uplink 324 } 326 Under normal circumstances it is desirable that all traffic be sent 327 via the ISP_A uplink, therefore hosts (the host H1 in the example 328 topology figure) should be using source addresses from 329 2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 330 using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 331 until the ISP_A uplink comes back up. To achieve this the router 332 advertisement configuration on the R1 device for the interface facing 333 H1 needs to have the following policy: 335 prefix 2001:db8:1:1::/64 { 336 if ISP_A_uplink is up 337 then preferred_lifetime = 604800 338 else preferred_lifetime = 0 339 } 341 prefix 2001:db8:2:1::/64 { 342 if ISP_A_Uplink is up 343 then preferred_lifetime = 0 344 else preferred_lifetime = 604800 345 } 347 A similar policy needs to be applied to the RDNSS Lifetime if ISP_A 348 and ISP_B DNS servers are used. 350 3.2.2. Two Routers, Primary/Backup Uplinks 352 Let's look at a more complex scenario where two border routers are 353 terminating two ISP uplinks (one each), acting as redundant first-hop 354 routers for hosts. The topology is shown on Fig.2 356 -------- 357 ,-------, ,' ', 358 +----+ 2001:db8:1::/48 ,' ', : : 359 2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 360 | | R1 | ', ,' : : 361 | +----+ '-------' : : 362 H1------------------| : INTERNET : 363 | +----+ ,-------, : : 364 |_| | 2001:db8:2::/48 ,' ', : : 365 2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : 366 +----+ ', ,' : : 367 '-------' ', ,' 368 -------- 370 Figure 2: Two Routers, Primary/Backup Uplinks 372 In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 373 address space) and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B 374 address space). Each router needs to have a forwarding policy 375 configured for packets received on its hosts-facing interface: 377 if { 378 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 379 packet_source_address is in 2001:db8:1::/48 380 } then { 381 default next-hop is ISP_A_uplink 382 } 383 if { 384 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 385 packet_source_address is in 2001:db8:2::/48 386 } then { 387 default next-hop is ISP_B_uplink 388 } 390 In this case there is more than one way to ensure that hosts are 391 selecting the correct source address based on the uplink status. If 392 VRRP is used to provide first-hop redundancy and the master router is 393 the one with the active uplink, then the simplest way is to use the 394 VRRP mastership as a condition for router advertisement. So, if 395 ISP_A is the primary uplink, the routers R1 and R2 need to be 396 configured in the following way: 398 R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A 399 uplink is down, then R1 becomes a backup. Router advertisements on 400 R1's interface facing H1 needs to have the following policy applied: 402 prefix 2001:db8:1:1::/64 { 403 if vrrp_master then preferred_lifetime = 604800 404 else preferred_lifetime = 0 405 } 407 R2 is VRRP backup by default. Router advertsement on R2 interface 408 facing H1 needs to have the following policy applied: 410 prefix 2001:db8:2:1::/64 { 411 if vrrp_master then preferred_lifetime = 604800 412 else preferred_lifetime = 0 413 } 415 If VRRP is not used or interface status tracking is not used for 416 mastership switchover, then each router needs to be able to detect 417 the uplink failure/recovery on the neighboring router, so that RAs 418 with updated preferred lifetime values are triggered. Depending on 419 the network setup various triggers like a route to the uplink 420 interface subnet or a default route received from the uplink can be 421 used. The obvious drawback of using the routing table to trigger the 422 conditional RAs is that some additional configuration is required. 423 For example, if a route to the prefix assigned to the ISP uplink is 424 used as a trigger, then the conditional RA policy would have the 425 following logic: 427 R1: 429 prefix 2001:db8:1:1::/64 { 430 if ISP_A_uplink is up then preferred_lifetime = 604800 431 else preferred_lifetime = 0 432 } 434 R2: 436 prefix 2001:db8:2:1::/64 { 437 if ISP_A_uplink_route is present then preferred_lifetime = 0 438 else preferred_lifetime = 604800 439 } 441 3.2.3. Single Router, Load Balancing Between Uplinks 443 Let's look at the example topology shown in Figure 1, but with both 444 uplinks used simultaneously. In this case R1 would send RAs 445 containing PIOs for both prefixes, 2001:db8:1:1::/64 and 446 2001:db8:2:1::/64, changing the preferred lifetime based on 447 particular uplink availability. If the interface status is used as 448 uplink availability indicator, then the policy logic would look like 449 the following: 451 prefix 2001:db8:1:1::/64 { 452 if ISP_A_uplink is up then preferred_lifetime = 604800 453 else preferred_lifetime = 0 454 } 455 prefix 2001:db8:2:1::/64 { 456 if ISP_B_uplink is up then preferred_lifetime = 604800 457 else preferred_lifetime = 0 458 } 460 R1 needs a forwarding policy to be applied to forward packets to the 461 correct uplink based on the source address as described in 462 Section 3.2.1. 464 3.2.4. Two Router, Load Balancing Between Uplinks 466 In this scenario the example topology is similar to the one shown in 467 Figure 2, but both uplinks can be used at the same time. It means 468 that both R1 and R2 need to have the corresponding forwarding policy 469 to forward packets based on their source addresses. 471 Each router would send RAs with POI for the corresponding prefix. 472 setting preferred_lifetime to a non-zero value when the ISP uplink is 473 up, and deprecating the prefix by setting the preferred lifetime to 0 474 in case of uplink failure. The uplink recovery would trigger another 475 RA with non-zero preferred lifetime to make the addresses from the 476 prefix preferred again. The example RA policy on R1 and R2 would 477 look like: 479 R1: 481 prefix 2001:db8:1:1::/64 { 482 if ISP_A_uplink is up then preferred_lifetime = 604800 483 else preferred_lifetime = 0 484 } 486 R2: 488 prefix 2001:db8:2:1::/64 { 489 if ISP_B_uplink is up then preferred_lifetime = 604800 490 else preferred_lifetime = 0 491 } 493 3.2.5. Topologies with Dedicated Border Routers 495 For simplicity reasons all topologies below show the ISP uplinks 496 terminated on the first-hop routers. Obviously, the proposed 497 approach can be used in more complex topologies when dedicated 498 devices are used for terminating ISP uplinks. In that case VRRP 499 mastership or inteface status can not be used as a trigger for 500 conditional RAs and route presence as described above should be used 501 instead. 503 Let's look at the example topology shown on the Figure 3: 505 2001:db8:1::/48 -------- 506 2001:db8:1:1::/64 ,-------, ,' ', 507 +----+ +---+ +----+ ,' ', : : 508 _| |--| |--| R3 |----+ ISP_A +---+: : 509 | | R1 | | | +----+ ', ,' : : 510 | +----+ | | '-------' : : 511 H1--------| |LAN| : INTERNET : 512 | +----+ | | ,-------, : : 513 |_| | | | +----+ ,' ', : : 514 | R2 |--| |--| R4 |----+ ISP_B +---+: : 515 +----+ +---+ +----+ ', ,' : : 516 2001:db8:2:1::/64 '-------' ', ,' 517 2001:db8:2::/48 -------- 519 Figure 3: Dedicated Border Routers 521 For example, if ISP_A is a primary uplink and ISP_B is a backup one 522 then the following policy might be used to achieve the desired 523 behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while 524 ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if 525 the uplink is non-operational): 527 R1 and R2 policy: 529 prefix 2001:db8:1:1::/64 { 530 if ISP_A_uplink_route is present then preferred_lifetime = 604800 531 else preferred_lifetime = 0 532 } 533 prefix 2001:db8:2:1::/64 { 534 if ISP_A_uplink_route is present then preferred_lifetime = 0 535 else preferred_lifetime = 604800 536 } 538 For load-balancing case the policy would look slightly different: 539 each prefix has non-zero preferred_lifetime only if the correspoding 540 ISP uplink route is present: 542 prefix 2001:db8:1:1::/64 { 543 if ISP_A_uplink_route is present then preferred_lifetime = 604800 544 else preferred_lifetime = 0 545 } 546 prefix 2001:db8:2:1::/64 { 547 if ISP_B_uplink_route is present then preferred_lifetime = 604800 548 else preferred_lifetime = 0 549 } 551 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 553 Prefix deprecation as a result of an uplink status change might lead 554 to a situation when all global prefixes are deprecated (all ISP 555 uplinks are not operational for some reason). Even when there is no 556 Internet connectivity it might be still desirable to have intra-site 557 IPv6 connectivity (especially when the network in question is an 558 IPv6-only one). However while an address is in a deprecated state, 559 its use is discouraged, but not strictly forbidden ([RFC4862]). In 560 such scenario all IPv6 source addresses in the candidate set 561 ([RFC6724]) are deprecated which means that they still can be used 562 (as there is no preferred addresses available) and the source address 563 selection algorith can pick up one of them, allowing the intra-site 564 communication. However some OSes might just fall back to IPv4 if the 565 network interface has no preferred IPv6 global addresses. Therefore 566 if intra-site connectivity is vital during simultanious outages of 567 multiple uplinks, administrators might consider using ULAs or 568 provisioning additional backup uplinks to protect the network from 569 double-failure cases. 571 3.2.7. Uplink Damping 573 If an actively used uplink (primary one or one used in load balaning 574 scenario) starts flapping, it might lead to undesirable situation of 575 flapping addresses on hosts (every time the uplink goes up hosts 576 receive an RA with non-zerop preferred PIO lifetime, and every time 577 the uplink goes down all address in the affected prefix become 578 deprecated). Undoubtedly it would negatively impact user experience, 579 not mentioning spikes of DAD traffic every time an uplink comes back 580 up. Therefore it's recommended that router vendors implement some 581 form of damping policy for conditional RAs and either postpone 582 sending an RA with non-zero lifetime for a POI when the uplink comes 583 up for a number of seconds or even introduce accumulated penalties/ 584 exponential backoff algorithm for such delays. (In the case of 585 multiple simultaneous uplink failure scenario, when all but one 586 uplinks are down and the last remaining is flapping it might result 587 in all addresses being deprecated for a while after the flapping 588 uplink recovers.) 590 3.3. Solution Limitations 592 It should be noted that the proposed approach is not a silver bullet 593 for all possible multihoming scenarios. The main goal is to solve 594 some common use cases so it would suit very well relatively simple 595 topologies with straightforward policies. The more complex the 596 network topology and the corresponding routing policies more 597 configuration would be required to implement the solution. Another 598 limitation is related to the load balancing between the uplinks. In 599 that scenario when both uplinks are active hosts would select the 600 source prefix using the Default Address Selection algorithm 601 ([RFC6724]) and therefore the load between two uplinks most likely 602 would not be evenly distributed. (However the proposed mechanism 603 does allow a creative way of controlling uplinks load in SDN networks 604 where controllers might selectively deprecate prefixes on some hosts 605 but not others to move egress traffic between uplinks). Also the 606 prefix selection does not take into account any other uplinks 607 properties (such as RTT etc) so egress traffic might not be sent to 608 the nearest uplink if the corresponding prefix is selected as a 609 source. In general if not all uplinks are equal and some uplinks are 610 expected to be preferred over others then the network adminitrator 611 should ensure that prefixes from non-preferred ISP(s) are kept 612 deprecated (so primary/backup setup is used). 614 4. IANA Considerations 616 This memo asks the IANA for no new parameters. 618 5. Security Considerations 620 This memo introduces no new security considerations. 622 5.1. Privacy Considerations 624 This memo introduces no new privacy considerations. 626 6. Acknowledgements 628 Thanks to the following people (in alphabetical order) for their 629 review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus 630 Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, Dave 631 Thaler. 633 7. References 635 7.1. Normative References 637 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 638 and E. Lear, "Address Allocation for Private Internets", 639 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 640 . 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 648 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 649 December 1998, . 651 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 652 Defeating Denial of Service Attacks which employ IP Source 653 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 654 May 2000, . 656 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 657 Address Translator (Traditional NAT)", RFC 3022, 658 DOI 10.17487/RFC3022, January 2001, 659 . 661 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 662 Multihoming Architectures", RFC 3582, 663 DOI 10.17487/RFC3582, August 2003, 664 . 666 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 667 Gill, "IPv4 Multihoming Practices and Limitations", 668 RFC 4116, DOI 10.17487/RFC4116, July 2005, 669 . 671 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 672 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 673 . 675 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 676 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 677 October 2005, . 679 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 680 Should Think About", RFC 4219, DOI 10.17487/RFC4219, 681 October 2005, . 683 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 684 Address Autoconfiguration", RFC 4862, 685 DOI 10.17487/RFC4862, September 2007, 686 . 688 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 689 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 690 . 692 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 693 and D. Wing, "IPv6 Multihoming without Network Address 694 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 695 . 697 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 698 Hosts in a Multi-Prefix Network", RFC 8028, 699 DOI 10.17487/RFC8028, November 2016, 700 . 702 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 703 "IPv6 Router Advertisement Options for DNS Configuration", 704 RFC 8106, DOI 10.17487/RFC8106, March 2017, 705 . 707 7.2. Informative References 709 [I-D.ietf-rtgwg-dst-src-routing] 710 Lamparter, D. and A. Smirnov, "Destination/Source 711 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 712 progress), October 2017. 714 [I-D.ietf-rtgwg-enterprise-pa-multihoming] 715 Baker, F., Bowers, C., and J. Linkova, "Enterprise 716 Multihoming using Provider-Assigned Addresses without 717 Network Prefix Translation: Requirements and Solution", 718 draft-ietf-rtgwg-enterprise-pa-multihoming-03 (work in 719 progress), February 2018. 721 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 722 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 723 2004, . 725 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 726 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 727 DOI 10.17487/RFC4861, September 2007, 728 . 730 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 731 Extensions for Stateless Address Autoconfiguration in 732 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 733 . 735 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 736 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 737 June 2009, . 739 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 740 Locator Pair Exploration Protocol for IPv6 Multihoming", 741 RFC 5534, DOI 10.17487/RFC5534, June 2009, 742 . 744 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 745 "Default Address Selection for Internet Protocol Version 6 746 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 747 . 749 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 750 Requirements for IPv6 Customer Edge Routers", RFC 7084, 751 DOI 10.17487/RFC7084, November 2013, 752 . 754 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 755 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 756 2016, . 758 Appendix A. Change Log 760 Initial Version: July 2017 762 Authors' Addresses 764 Jen Linkova 765 Google 766 Mountain View, California 94043 767 USA 769 Email: furry@google.com 771 Massimiliano Stucchi 772 RIPE NCC 773 Stationsplein, 11 774 Amsterdam 1012 AB 775 The Netherlands 777 Email: mstucchi@ripe.net