idnits 2.17.1 draft-ietf-v6ops-conditional-ras-01.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 (February 27, 2018) is 2251 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC4116' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC4218' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC4219' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-dst-src-routing' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC5533' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'RFC5534' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC7788' is defined on line 748, 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-02 -- 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: August 31, 2018 February 27, 2018 7 Using Conditional Router Advertisements for Enterprise Multihoming 8 draft-ietf-v6ops-conditional-ras-01 10 Abstract 12 This document discusses most common scenarios of connecting an 13 enterprise network to multiple ISPs using an address space assigned 14 by an ISP. The problem of enterprise multihoming without address 15 translation of any form has not been solved yet as it requires both 16 the network to select the correct egress ISP based on the packet 17 source address and hosts to select the correct source address based 18 on the desired egress ISP for that traffic. 19 [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to 20 this problem by introducing a new routing functionality (Source 21 Address Dependent Routing) to solve the uplink selection issue and 22 using Router Advertisements to influence the host source address 23 selection. While the above-mentioned document focuses on solving the 24 general problem and on covering various complex use cases, this 25 document describes how the solution proposed in 26 [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited 27 number of common use cases. In particular, the focus is on scenarios 28 where an enterprise network has two Internet uplinks used either in 29 primary/backup mode or simultaneously and hosts in that network might 30 not yet properly support multihoming as described in [RFC8028]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 31, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 3 68 2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 3 69 2.2. Two ISP Uplinks, Used for Load Balancing . . . . . . . . 4 70 3. Conditional Router Advertisements . . . . . . . . . . . . . . 4 71 3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 4 72 3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 4 73 3.1.2. Source Address Selection and Conditional RAs . . . . 5 74 3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 6 75 3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 6 76 3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 8 77 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 10 78 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 10 79 3.2.5. Topologies with Dedicated Border Routers . . . . . . 11 80 3.2.6. Intra-Site Communication during Simultaneous Uplinks 81 Outage . . . . . . . . . . . . . . . . . . . . . . . 13 82 3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 13 83 3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 13 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 14 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 7.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 Multihoming is an obvious requirement for many enterprise networks to 97 ensure the desired level of network reliability. However, using more 98 than one ISP (and address space assigned by those ISPs) introduces 99 the problem of assigning IP addresses to hosts. In IPv4 there is no 100 choice but using [RFC1918] address space and NAT ([RFC3022]) at the 101 network edge. Using Provider Independent (PI) address space is not 102 always an option as it requires running BGP between the enterprise 103 network and the ISPs, not mentioning administrative overhead of 104 obtaining and managing PI address space. As IPv6 host can, by 105 design, have multiple addresses of the global scope, multihoming 106 using provider address looks even easier for IPv6: each ISP assigns 107 an IPv6 block (usually /48) and hosts in the enterprise network have 108 addresses assigned from each ISP block. However using IPv6 PA blocks 109 in multihoming scenario introduces some challenges, including but not 110 limited to: 112 o Selecting the correct uplink based on the packet source address; 114 o Signaling to hosts that some source addresses should or should not 115 be used (e.g. an uplink to the ISP went down or became available 116 again). 118 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses 119 these and other related challenges in details in relation to the 120 general multihoming scenario for enterprise networks. Unfortunately 121 the proposed solution heavily relies on the rule 5.5 of the default 122 address selection algorithm ([RFC6724]) which has not been widely 123 implemented at the moment this document was written. Therefore 124 network administrators in enterprise networks can't yet assume that 125 all devices in their network support the rule 5.5, especially in the 126 quite common BYOD ("Bring Your Own Device") scenario. However, while 127 it does not seem feasible to solve all the possible multihoming 128 scenarios without reliying on rule 5.5, it is possible to provide 129 IPv6 multihoming using provider-assigned (PA) address space for the 130 most common use cases. This document discusses how the general 131 solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can 132 be applied to those two specific cases. 134 2. Common Enterprise Multihoming Scenarios 136 2.1. Two ISP Uplinks, Primary and Backup 138 This scenario has the following key characteristics: 140 o The enterprise network is using uplinks to two (or more) ISPs for 141 Internet access; 143 o Each ISP assigns IPv6 PA address space for the network; 145 o Uplink(s) to one ISP is a primary (preferred) one. All other 146 uplinks are backup and are not expected to be used while the 147 primary one is operational; 149 o If the primary uplink is operational, all Internet traffic should 150 flow via that uplink; 152 o When the primary uplink fails the Internet traffic needs to flow 153 via the backup uplinks; 155 o Recovery of the primary uplink needs to trigger the traffic 156 switchover from the backup uplinks back to primary one. 158 2.2. Two ISP Uplinks, Used for Load Balancing 160 This scenario has the following key characteristics: 162 o The enterprise network is using uplinks to two (or more) ISPs for 163 Internet access; 165 o Each ISP assigns an IPv6 PA address space; 167 o All the uplinks may be used simultaneously, with the traffic being 168 randomly balanced between them. 170 3. Conditional Router Advertisements 172 3.1. Solution Overview 174 3.1.1. Uplink Selection 176 As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of 177 the two main problems to be solved in the enterprise multihoming 178 scenario is the problem of the next-hop (uplink) selection based on 179 the packet source address. For example, if the enterprise network 180 has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 181 subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) 182 then packets sourced from subnet_A must be sent to ISP_A uplink while 183 packets sourced from subnet_B must be sent to ISP_B uplink. 185 While some work is being done in the Source Address Dependent Routing 186 (SADR) area, the simplest way to implement the desired functionality 187 currently is to apply a policy which selects a next-hop or an egress 188 interface based on the packet source address. Most of the SMB/ 189 Enterprise grade routers have such functionality available currently. 191 3.1.2. Source Address Selection and Conditional RAs 193 Another problem to be solved in the multihoming scenario is the 194 source address selection on hosts. In the normal situation (all 195 uplinks are up/operational) hosts have multiple global unique 196 addresses and can rely on the default address selection algorithm 197 ([RFC6724]) to pick up a source address, while the network is 198 responsible for choosing the correct uplink based on the source 199 address selected by a host as described in Section 3.1.2. However, 200 some network topology changes (i.e. changing uplink status) might 201 affect the global reachability for packets sourced from the 202 particular prefixes and therefore such changes have to be signaled 203 back to the hosts. For example: 205 o An uplink to an ISP_A went down. Hosts should not use addresses 206 from ISP_A prefix; 208 o A primary uplink to ISP_A which was not operational has come back 209 up. Hosts should start using the source addresses from ISP_A 210 prefix. 212 [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed 213 explanation on why SLAAC and router advertisements are the most 214 suitable mechanism for signaling network topology changes to hosts 215 and thereby influencing the source address selection. Sending a 216 router advertisement to change the preferred lifetime for a given 217 prefix provides the following functionality: 219 o deprecating addresses (by sending an RA with the 220 preferred_lifetime set to 0 in the corresponding POI) to indicate 221 to hosts that that addresses from that prefix should not be used; 223 o making a previously unused (deprecated) prefix usable again (by 224 sending an RA containing a POI with non-zero preferred lifetime) 225 to indicate to hosts that addresses from that prefix can be used 226 again. 228 To provide the desired functionality, first-hop routers are required 229 to 231 o send RA triggered by defined event policies in response to uplink 232 status change event; and 234 o while sending periodic or solicted RAs, set the value in the given 235 RA field (e.g. PIO preferred lifetime) based on the uplink 236 status. 238 The exact definition of the 'uplink status' depends on the network 239 topology and may include conditions like: 241 o uplink interface status change; 243 o presence of a particular route in the routing table; 245 o presence of a particular route with a particular attribute (next- 246 hop, tag etc) in the routing table; 248 o protocol adjacency change. 250 etc. 252 In some scenarios, when two routers are providing first-hop 253 redundancy via VRRP, the master-backup status can be considered as a 254 condition for sending RAs and changing the preferred lifetime value. 255 See Section 3.2.2 for more details. 257 If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS 258 [RFC8106] it might be desirable for the conditional RAs to update the 259 Lifetime field of the RDNSS option as well. 261 The trigger is not only forcing the router to send an unsolicited RA 262 to propagate the topology changes to all hosts. Obviously the RA 263 fields values (like PIO Preferred Lifetime or DNS Server Lifetime) 264 changed by the particular trigger MUST stay the same until another 265 event happens causing the value to be updated. E.g. if the ISP_A 266 uplink failure causes the prefix to be deprecated all solicited and 267 unsolicited RAs sent by the router MUST have the Preferred Lifetime 268 for that POI set to 0 until the uplink comes back up. 270 It should be noted that the proposed solution is quite similar to the 271 existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the 272 documented behaviour of homenet devices. It is using the same 273 mechanism of deprecating a prefix when the corresponding uplink is 274 not operational, applying it to enterprise network scenario. 276 3.2. Example Scenarios 278 This section illustrates how the conditional RAs solution can be 279 applied to most common enterprise multihoming scenarios. 281 3.2.1. Single Router, Primary/Backup Uplinks 282 -------- 283 ,-------, ,' ', 284 +----+ 2001:db8:1::/48 ,' ', : : 285 | |------------------+ ISP_A +--+: : 286 2001:db8:1:1::/64 | | ', ,' : : 287 | | '-------' : : 288 H1------------------| R1 | : INTERNET : 289 | | ,-------, : : 290 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 291 | |------------------+ ISP_B +--+: : 292 +----+ ', ,' : : 293 '-------' ', ,' 294 -------- 296 Figure 1: Single Router, Primary/Backup Uplinks 298 Let's look at a simple network topology where a single router acts as 299 a border router to terminate two ISP uplinks and as a first-hop 300 router for hosts. Each ISP assigns a /48 to the network, and the 301 ISP_A uplink is a primary one, to be used for all Internet traffic, 302 while the ISP_B uplink is a backup, to be used only when the primary 303 uplink is not operational. 305 To ensure that packets with source addresses from ISP_A and ISP_B are 306 only routed to ISP_A and ISP_B uplinks respectively, the network 307 administrator needs to configure a policy on R1: 309 if { 310 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 311 packet_source_address is in 2001:db8:1::/48 312 } then { 313 next-hop is ISP_A_uplink 314 } 315 if { 316 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 317 packet_source_address is in 2001:db8:2::/48 318 } 319 then { 320 next-hop is ISP_B_uplink 321 } 323 Under normal circumstances it is desirable that all traffic be sent 324 via the ISP_A uplink, therefore hosts (the host H1 in the example 325 topology figure) should be using source addresses from 326 2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 327 using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 328 until the ISP_A uplink comes back up. To achieve this the router 329 advertisement configuration on the R1 device for the interface facing 330 H1 needs to have the following policy: 332 prefix 2001:db8:1:1::/64 { 333 if ISP_A_uplink is up 334 then preferred_lifetime = 604800 335 else preferred_lifetime = 0 336 } 338 prefix 2001:db8:2:1::/64 { 339 if ISP_A_Uplink is up 340 then preferred_lifetime = 0 341 else preferred_lifetime = 604800 342 } 344 A similar policy needs to be applied to the RDNSS Lifetime if ISP_A 345 and ISP_B DNS servers are used. 347 3.2.2. Two Routers, Primary/Backup Uplinks 349 Let's look at a more complex scenario where two border routers are 350 terminating two ISP uplinks (one each), acting as redundant first-hop 351 routers for hosts. The topology is shown on Fig.2 353 -------- 354 ,-------, ,' ', 355 +----+ 2001:db8:1::/48 ,' ', : : 356 2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 357 | | R1 | ', ,' : : 358 | +----+ '-------' : : 359 H1------------------| : INTERNET : 360 | +----+ ,-------, : : 361 |_| | 2001:db8:2::/48 ,' ', : : 362 2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : 363 +----+ ', ,' : : 364 '-------' ', ,' 365 -------- 367 Figure 2: Two Routers, Primary/Backup Uplinks 369 In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 370 address space) and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B 371 address space). Each router needs to have a forwarding policy 372 configured for packets received on its hosts-facing interface: 374 if { 375 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 376 packet_source_address is in 2001:db8:1::/48 377 } then { 378 next-hop is ISP_A_uplink 379 } 380 if { 381 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 382 packet_source_address is in 2001:db8:2::/48 383 } then { 384 next-hop is ISP_B_uplink 385 } 387 In this case there is more than one way to ensure that hosts are 388 selecting the correct source address based on the uplink status. If 389 VRRP is used to provide first-hop redundancy and the master router is 390 the one with the active uplink, then the simplest way is to use the 391 VRRP mastership as a condition for router advertisement. So, if 392 ISP_A is the primary uplink, the routers R1 and R2 need to be 393 configured in the following way: 395 R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A 396 uplink is down, then R1 becomes a backup. Router advertisements on 397 R1's interface facing H1 needs to have the following policy applied: 399 prefix 2001:db8:1:1::/64 { 400 if vrrp_master then preferred_lifetime = 604800 401 else preferred_lifetime = 0 402 } 404 R2 is VRRP backup by default. Router advertsement on R2 interface 405 facing H1 needs to have the following policy applied: 407 prefix 2001:db8:2:1::/64 { 408 if vrrp_master then preferred_lifetime = 604800 409 else preferred_lifetime = 0 410 } 412 If VRRP is not used or interface status tracking is not used for 413 mastership switchover, then each router needs to be able to detect 414 the uplink failure/recovery on the neighboring router, so that RAs 415 with updated preferred lifetime values are triggered. Depending on 416 the network setup various triggers like a route to the uplink 417 interface subnet or a default route received from the uplink can be 418 used. The obvious drawback of using the routing table to trigger the 419 conditional RAs is that some additional configuration is required. 420 For example, if a route to the prefix assigned to the ISP uplink is 421 used as a trgger, then the conditional RA policy would have the 422 following logic: 424 R1: 426 prefix 2001:db8:1:1::/64 { 427 if ISP_A_uplink is up then preferred_lifetime = 604800 428 else preferred_lifetime = 0 429 } 431 R2: 433 prefix 2001:db8:2:1::/64 { 434 if ISP_A_uplink_route is present then preferred_lifetime = 0 435 else preferred_lifetime = 604800 436 } 438 3.2.3. Single Router, Load Balancing Between Uplinks 440 Let's look at the example topology shown in Figure 1, but with both 441 uplinks used simultaneously. In this case R1 would send RAs 442 containing PIOs for both prefixes, 2001:db8:1:1::/64 and 443 2001:db8:2:1::/64, changing the preferred lifetime based on 444 particular uplink availability. If the interface status is used as 445 uplink availability indicator, then the policy logic would look like 446 the following: 448 prefix 2001:db8:1:1::/64 { 449 if ISP_A_uplink is up then preferred_lifetime = 604800 450 else preferred_lifetime = 0 451 } 452 prefix 2001:db8:2:1::/64 { 453 if ISP_B_uplink is up then preferred_lifetime = 604800 454 else preferred_lifetime = 0 455 } 457 R1 needs a forwarding policy to be applied to forward packets to the 458 correct uplink based on the source address as described in 459 Section 3.2.1. 461 3.2.4. Two Router, Load Balancing Between Uplinks 463 In this scenario the example topology is similar to the one shown in 464 Figure 2, but both uplinks can be used at the same time. It means 465 that both R1 and R2 need to have the corresponding forwarding policy 466 to forward packets based on their source addresses. 468 Each router would send RAs with POI for the corresponding prefix. 469 setting preferred_lifetime to a non-zero value when the ISP uplink is 470 up, and deprecating the prefix by setting the preferred lifetime to 0 471 in case of uplink failure. The uplink recovery would trigger another 472 RA with non-zero preferred lifetime to make the addresses from the 473 prefix preferred again. The example RA policy on R1 and R2 would 474 look like: 476 R1: 478 prefix 2001:db8:1:1::/64 { 479 if ISP_A_uplink is up then preferred_lifetime = 604800 480 else preferred_lifetime = 0 481 } 483 R2: 485 prefix 2001:db8:2:1::/64 { 486 if ISP_B_uplink is up then preferred_lifetime = 604800 487 else preferred_lifetime = 0 488 } 490 3.2.5. Topologies with Dedicated Border Routers 492 For simplicity reasons all topologies below show the ISP uplinks 493 terminated on the first-hop routers. Obviously, the proposed 494 approach can be used in more complex topologies when dedicated 495 devices are used for terminating ISP uplinks. In that case VRRP 496 mastership or inteface status can not be used as a trigger for 497 conditional RAs and route presence as described above should be used 498 instead. 500 Let's look at the example topology shown on the Figure 3: 502 2001:db8:1::/48 -------- 503 2001:db8:1:1::/64 ,-------, ,' ', 504 +----+ +---+ +----+ ,' ', : : 505 _| |--| |--| R3 |----+ ISP_A +---+: : 506 | | R1 | | | +----+ ', ,' : : 507 | +----+ | | '-------' : : 508 H1--------| |LAN| : INTERNET : 509 | +----+ | | ,-------, : : 510 |_| | | | +----+ ,' ', : : 511 | R2 |--| |--| R4 |----+ ISP_B +---+: : 512 +----+ +---+ +----+ ', ,' : : 513 2001:db8:2:1::/64 '-------' ', ,' 514 2001:db8:2::/48 -------- 516 Figure 3: Dedicated Border Routers 518 For example, if ISP_A is a primary uplink and ISP_B is a backup one 519 then the following policy might be used to achieve the desired 520 behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while 521 ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if 522 the uplink is non-operational): 524 R1 and R2 policy: 526 prefix 2001:db8:1:1::/64 { 527 if ISP_A_uplink_route is present then preferred_lifetime = 604800 528 else preferred_lifetime = 0 529 } 530 prefix 2001:db8:2:1::/64 { 531 if ISP_A_uplink_route is present then preferred_lifetime = 0 532 else preferred_lifetime = 604800 533 } 535 For load-balancing case the policy would look slightly different: 536 each prefix has non-zero preferred_lifetime only if the correspoding 537 ISP uplink route is present: 539 prefix 2001:db8:1:1::/64 { 540 if ISP_A_uplink_route is present then preferred_lifetime = 604800 541 else preferred_lifetime = 0 542 } 543 prefix 2001:db8:2:1::/64 { 544 if ISP_B_uplink_route is present then preferred_lifetime = 0 545 else preferred_lifetime = 604800 546 } 548 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage 550 Prefix deprecation as a result of an uplink status change might lead 551 to a situation when all global prefixes are deprecated (all ISP 552 uplinks are not operational for some reason). Even when there is no 553 Internet connectivity it might be still desirable to have intra-site 554 IPv6 connectivity (especially when the network in question is an 555 IPv6-only one). However while an address is in a deprecated state, 556 its use is discouraged, but not strictly forbidden ([RFC4862]). In 557 such scenario all IPv6 source addresses in the candidate set 558 ([RFC6724]) are deprecated which means that they still can be used 559 (as there is no preferred addresses available) and the source address 560 selection algorith can pick up one of them, allowing the intra-site 561 communication. In the scenario when intra-site connectivity is vital 562 even in multiple failure scenario, administrators might consider 563 using ULAs or provisioning additional backup uplinks to protect the 564 network from double-failure cases. 566 3.2.7. Uplink Damping 568 If an actively used uplink (primary one or one used in load balaning 569 scenario) starts flapping, it might lead to undesirable situation of 570 flapping addresses on hosts (every time the uplink goes up hosts 571 receive an RA with non-zerop preferred PIO lifetime, and every time 572 the uplink goes down all address in the affected prefix become 573 deprecated). Undoubtedly it would negatively impact user experience, 574 not mentioning spikes of DAD traffic every time an uplink comes back 575 up. Therefore it's recommended that router vendors implement some 576 form of damping policy for conditional RAs and either postpone 577 sending an RA with non-zero lifetime for a POI when the uplink comes 578 up for a number of seconds or even introduce accumulated penalties/ 579 exponential backoff algorithm for such delays. (In the case of 580 multiple simultaneous uplink failure scenario, when all but one 581 uplinks are down and the last remaining is flapping it might result 582 in all addresses being deprecated for a while after the flapping 583 uplink recovers.) 585 3.3. Solution Limitations 587 It should be noted that the proposed approach is not a silver bullet 588 for all possible multihoming scenarios. The main goal is to solve 589 some common use cases so it would suit very well relatively simple 590 topologies with straightforward policies. The more complex the 591 network topology and the corresponding routing policies more 592 configuration would be required to implement the solution. Another 593 limitation is related to the load balancing between the uplinks. In 594 that scenario when both uplinks are active hosts would select the 595 source prefix using the Default Address Selection algorithm 596 ([RFC6724]) and therefore the load between two uplinks most likely 597 would not be evenly distributed. (However the proposed mechanism 598 does allow a creative way of controlling uplinks load in SDN networks 599 where controllers might selectively deprecate prefixes on some hosts 600 but not others to move egress traffic between uplinks). Also the 601 prefix selection does not take into account any other uplinks 602 properties (such as RTT etc) so egress traffic might not be sent to 603 the nearest uplink if the corresponding prefix is selected as a 604 source. In general if not all uplinks are equal and some uplinks are 605 expected to be preferred over others then the network adminitrator 606 should ensure that prefixes from non-preferred ISP(s) are kept 607 deprecated (so primary/backup setup is used). 609 4. IANA Considerations 611 This memo asks the IANA for no new parameters. 613 5. Security Considerations 615 This memo introduces no new security considerations. 617 5.1. Privacy Considerations 619 This memo introduces no new privacy considerations. 621 6. Acknowledgements 623 Thanks to the following people (in alphabetical order) for their 624 review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus 625 Keane, Erik Kline, David Lamparter, Erik Nordmark, Dave Thaler. 627 7. References 629 7.1. Normative References 631 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 632 and E. Lear, "Address Allocation for Private Internets", 633 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 634 . 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, 639 . 641 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 642 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 643 December 1998, . 645 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 646 Defeating Denial of Service Attacks which employ IP Source 647 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 648 May 2000, . 650 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 651 Address Translator (Traditional NAT)", RFC 3022, 652 DOI 10.17487/RFC3022, January 2001, 653 . 655 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 656 Multihoming Architectures", RFC 3582, 657 DOI 10.17487/RFC3582, August 2003, 658 . 660 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 661 Gill, "IPv4 Multihoming Practices and Limitations", 662 RFC 4116, DOI 10.17487/RFC4116, July 2005, 663 . 665 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 666 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 667 . 669 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 670 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 671 October 2005, . 673 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 674 Should Think About", RFC 4219, DOI 10.17487/RFC4219, 675 October 2005, . 677 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 678 Address Autoconfiguration", RFC 4862, 679 DOI 10.17487/RFC4862, September 2007, 680 . 682 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 683 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 684 . 686 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 687 and D. Wing, "IPv6 Multihoming without Network Address 688 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 689 . 691 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 692 Hosts in a Multi-Prefix Network", RFC 8028, 693 DOI 10.17487/RFC8028, November 2016, 694 . 696 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 697 "IPv6 Router Advertisement Options for DNS Configuration", 698 RFC 8106, DOI 10.17487/RFC8106, March 2017, 699 . 701 7.2. Informative References 703 [I-D.ietf-rtgwg-dst-src-routing] 704 Lamparter, D. and A. Smirnov, "Destination/Source 705 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 706 progress), October 2017. 708 [I-D.ietf-rtgwg-enterprise-pa-multihoming] 709 Baker, F., Bowers, C., and J. Linkova, "Enterprise 710 Multihoming using Provider-Assigned Addresses without 711 Network Prefix Translation: Requirements and Solution", 712 draft-ietf-rtgwg-enterprise-pa-multihoming-02 (work in 713 progress), October 2017. 715 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 716 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 717 2004, . 719 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 720 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 721 DOI 10.17487/RFC4861, September 2007, 722 . 724 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 725 Extensions for Stateless Address Autoconfiguration in 726 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 727 . 729 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 730 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 731 June 2009, . 733 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 734 Locator Pair Exploration Protocol for IPv6 Multihoming", 735 RFC 5534, DOI 10.17487/RFC5534, June 2009, 736 . 738 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 739 "Default Address Selection for Internet Protocol Version 6 740 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 741 . 743 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 744 Requirements for IPv6 Customer Edge Routers", RFC 7084, 745 DOI 10.17487/RFC7084, November 2013, 746 . 748 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 749 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 750 2016, . 752 Appendix A. Change Log 754 Initial Version: July 2017 756 Authors' Addresses 758 Jen Linkova 759 Google 760 Mountain View, California 94043 761 USA 763 Email: furry@google.com 765 Massimiliano Stucchi 767 Email: max@stucchi.ch