idnits 2.17.1 draft-linkova-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 date (July 2, 2017) is 2462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC4116' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC4218' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'RFC4219' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-dst-src-routing' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC5533' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC5534' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC7788' is defined on line 648, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rtgwg-enterprise-pa-multihoming-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-04 -- 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: January 3, 2018 July 2, 2017 7 Using Conditional Router Advertisements for Enterprise Multihoming 8 draft-linkova-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 http://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 January 3, 2018. 49 Copyright Notice 51 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . 4 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 . . . . . . . . . 7 77 3.2.3. Single Router, Load Balancing Between Uplinks . . . . 9 78 3.2.4. Two Router, Load Balancing Between Uplinks . . . . . 10 79 3.2.5. Topologies with Dedicated Border Routers . . . . . . 10 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 12 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 7.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Multihoming is an obvious requirement for many enterprise networks to 93 ensure the desired level of network reliability. However, using more 94 than one ISP (and address space assigned by those ISPs) introduces 95 the problem of assigning IP addresses to hosts. In IPv4 there is no 96 choice but using [RFC1918] address space and NAT ([RFC3022]) at the 97 network edge. Using Provider Independent or PI address space is not 98 always an option as it requires running BGP between the enterprise 99 network and the ISPs). As IPv6 host can, by design, have multiple 100 addresses of the global scope, multihoming using provider address 101 looks even easier for IPv6: each ISP assigns an IPv6 block (usually 102 /48) and hosts in the enterprise network have addresses assigned from 103 each ISP block. However using IPv6 PA blocks in multihoming scenario 104 introduces some challenges, including but not limited to: 106 o Selecting the correct uplink based on the packet source address; 108 o Signaling to hosts that some source addresses should or should not 109 be used (e.g. an uplink to the ISP went down or became available 110 again). 112 The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses 113 these and other related challenges in details in relation to the 114 general multihoming scenario for enterprise networks. Unfortunately 115 the proposed solution heavily relies on the rule 5.5 of the default 116 address selection algorithm ([RFC6724]) which has not been widely 117 implemented at the moment this document was written. Therefore 118 network administrators in enterprise networks can't yet assume that 119 all devices in their network support the rule 5.5, especially in the 120 quite common BYOD ("Bring Your Own Device") scenario. However, while 121 it does not seem feasible to solve all the possible multihoming 122 scenarios without reliying on rule 5.5, it is possible to provide 123 IPv6 multihoming using provider-assigned (PA) address space for the 124 most common use cases. This document discusses how the general 125 solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can 126 be applied to those two specific cases. 128 2. Common Enterprise Multihoming Scenarios 130 2.1. Two ISP Uplinks, Primary and Backup 132 This scenario has the following key characteristics: 134 o The enterprise network is using uplinks to two (or more) ISPs for 135 Internet access; 137 o Each ISP assigns IPv6 PA address space for the network; 139 o Uplink(s) to one ISP is a primary (preferred) one. All other 140 uplinks are backup and are not expected to be used while the 141 primary one is operational; 143 o If the primary uplink is operational, all Internet traffic should 144 flow via that uplink; 146 o When the primary uplink fails the Internet traffic needs to flow 147 via the backup uplinks; 149 o Recovery of the primary uplink needs to trigger the traffic 150 switchover from the backup uplinks back to primary one. 152 2.2. Two ISP Uplinks, Used for Load Balancing 154 This scenario has the following key characteristics: 156 o The enterprise network is using uplinks to two (or more) ISPs for 157 Internet access; 159 o Each ISP assigns an IPv6 PA address space; 161 o All the uplinks may be used simultaneously, with the traffic being 162 randomly balanced between them. 164 3. Conditional Router Advertisements 166 3.1. Solution Overview 168 3.1.1. Uplink Selection 170 As discussed in [I-D.ietf-rtgwg-enterprise-pa-multihoming], one of 171 the two main problems to be solved in the enterprise multihoming 172 scenario is the problem of the next-hop (uplink) selection based on 173 the packet source address. For example, if the enterprise network 174 has two uplinks, to ISP_A and ISP_B, and hosts have addresses from 175 subnet_A and subnet_B (belonging to ISP_A and ISP_B respectively) 176 then packets sourced from subnet_A must be sent to ISP_A uplink while 177 packets sourced from subnet_B must be sent to ISP_B uplink. 179 While some work is being done in the Source Address Dependent Routing 180 (SADR) area, the simplest way to implement the desired functionality 181 currently is to apply a policy which selects a next-hop or an egress 182 interface based on the packet source address. Most of the SMB/ 183 Enterprise grade routers have such functionality available currently. 185 3.1.2. Source Address Selection and Conditional RAs 187 Another problem to be solved in the multihoming scenario is the 188 source address selection on hosts. In the normal situation (all 189 uplinks are up/operational) hosts have multiple global unique 190 addresses and can rely on the default address selection algorithm 191 ([RFC6724]) to pick up a source address, while the network is 192 responsible for choosing the correct uplink based on the source 193 address selected by a host as described in Section 3.1.2. However, 194 some network topology changes (i.e. changing uplink status) might 195 affect the global reachability for packets sourced from the 196 particular prefixes and therefore such changes have to be signaled 197 back to the hosts. For example: 199 o An uplink to an ISP_A went down. Hosts should not use addresses 200 from ISP_A prefix; 202 o A primary uplink to ISP_A which was not operational has come back 203 up. Hosts should start using the source addresses from ISP_A 204 prefix. 206 [I-D.ietf-rtgwg-enterprise-pa-multihoming] provides a detailed 207 explanation on why SLAAC and router advertisements are the most 208 suitable mechanism for signaling network topology changes to hosts 209 and thereby influencing the source address selection. Sending a 210 router advertisement to change the preferred lifetime for a given 211 prefix provides the following functionality: 213 o deprecating addresses (by sending an RA with the 214 preferred_lifetime set to 0 in the corresponding POI) to indicate 215 to hosts that that addresses from that prefix should not be used; 217 o making a previously unused (deprecated) prefix usable again (by 218 sending an RA containing a POI with non-zero preferred lifetime) 219 to indicate to hosts that addresses from that prefix can be used 220 again. 222 To provide the desired functionality, first-hop routers are required 223 to 225 o send RA triggered by defined event policies in response to uplink 226 status change event; and 228 o while sending periodic or solicted RAs, set the value in the given 229 RA field (e.g. PIO preferred lifetime) based on the uplink 230 status. 232 The exact definition of the 'uplink status' depends on the network 233 topology and may include conditions like: 235 o uplink interface status change; 237 o presence of a particular route in the routing table; 239 o presence of a particular route with a particular attribute (next- 240 hop, tag etc) in the routing table; 242 o protocol adjacency change. 244 etc. 246 In some scenarios, when two routers are providing first-hop 247 redundancy via VRRP, the master-backup status can be considered as a 248 condition for sending RAs and changing the preferred lifetime value. 249 See Section 3.2.2 for more details. 251 If hosts are provided with ISP DNS servers IPv6 addresses via RDNSS 252 [RFC8106] it might be desirable for the conditional RAs to update the 253 Lifetime field of the RDNSS option as well. 255 3.2. Example Scenarios 257 This section illustrates how the conditional RAs solution can be 258 applied to most common enterprise multihoming scenarios. 260 3.2.1. Single Router, Primary/Backup Uplinks 262 -------- 263 ,-------, ,' ', 264 +----+ 2001:db8:1::/48 ,' ', : : 265 | |------------------+ ISP_A +--+: : 266 2001:db8:1:1::/64 | | ', ,' : : 267 | | '-------' : : 268 H1------------------| R1 | : INTERNET : 269 | | ,-------, : : 270 2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : : 271 | |------------------+ ISP_B +--+: : 272 +----+ ', ,' : : 273 '-------' ', ,' 274 -------- 276 Figure 1: Single Router, Primary/Backup Uplinks 278 Let's look at a simple network topology where a single router acts as 279 a border router to terminate two ISP uplinks and as a first-hop 280 router for hosts. Each ISP assigns a /48 to the network, and the 281 ISP_A uplink is a primary one, to be used for all Internet traffic, 282 while the ISP_B uplink is a backup, to be used only when the primary 283 uplink is not operational. 285 To ensure that packets with source addresses from ISP_A and ISP_B are 286 only routed to ISP_A and ISP_B uplinks respectively, the network 287 administrator needs to configure a policy on R1: 289 if { 290 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 291 packet_source_address is in 2001:db8:1::/48 292 } then { 293 next-hop is ISP_A_uplink 294 } 295 if { 296 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 297 packet_source_address is in 2001:db8:2::/48 298 } 299 then { 300 next-hop is ISP_B_uplink 301 } 303 Under normal circumstances it is desirable that all traffic be sent 304 via the ISP_A uplink, therefore hosts (the host H1 in the example 305 topology figure) should be using source addresses from 306 2001:db8:1:1::/64. When/if ISP_A uplink fails, hosts should stop 307 using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 308 until the ISP_A uplink comes back up. To achieve the desired 309 behavior the router advertisement configuration on the R1 device for 310 the interface facing H1 needs to have the following policy: 312 prefix 2001:db8:1:1::/64 { 313 if ISP_A_uplink is up 314 then preferred_lifetime = 604800 315 else preferred_lifetime = 0 316 } 318 prefix 2001:db8:2:1::/64 { 319 if ISP_A_Uplink is up 320 then preferred_lifetime = 0 321 else preferred_lifetime = 604800 322 } 324 A similar policy needs to be applied to the RDNSS Lifetime if ISP_A 325 and ISP_B DNS servers are used. 327 3.2.2. Two Routers, Primary/Backup Uplinks 329 Let's look at a more complex scenario where two border routers are 330 terminating two ISP uplinks (one each), acting as redundant first-hop 331 routers for hosts. The topology is shown on Fig.2 332 -------- 333 ,-------, ,' ', 334 +----+ 2001:db8:1::/48 ,' ', : : 335 2001:db8:1:1::/64 _| |----------------+ ISP_A +--+: : 336 | | R1 | ', ,' : : 337 | +----+ '-------' : : 338 H1------------------| : INTERNET : 339 | +----+ ,-------, : : 340 |_| | 2001:db8:2::/48 ,' ', : : 341 2001:db8:2:1::/64 | R2 |----------------+ ISP_B +--+: : 342 +----+ ', ,' : : 343 '-------' ', ,' 344 -------- 346 Figure 2: Two Routers, Primary/Backup Uplinks 348 In this scenario R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A 349 address space) and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B 350 address space). Each router needs to have a forwarding policy 351 configured for packets received on its hosts-facing interface: 353 if { 354 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 355 packet_source_address is in 2001:db8:1::/48 356 } then { 357 next-hop is ISP_A_uplink 358 } 359 if { 360 packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48 361 packet_source_address is in 2001:db8:2::/48 362 } then { 363 next-hop is ISP_B_uplink 364 } 366 In this case there is more than one way to ensure that hosts are 367 selecting the correct source address based on the uplink status. If 368 VRRP is used to provide first-hop redundancy and the master router is 369 the one with the active uplink, then the simplest way is to use the 370 VRRP mastership as a condition for router advertisement. So, if 371 ISP_A is the primary uplink, the routers R1 and R2 need to be 372 configured in the following way: 374 R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A 375 uplink is down, then R1 becomes a backup. Router advertisements on 376 R1's interface facing H1 needs to have the following policy applied: 378 prefix 2001:db8:1:1::/64 { 379 if vrrp_master then preferred_lifetime = 604800 380 else preferred_lifetime = 0 381 } 383 R2 is VRRP backup by default. Router advertsement on R2 interface 384 facing H1 needs to have the following policy applied: 386 prefix 2001:db8:2:1::/64 { 387 if vrrp_master then preferred_lifetime = 604800 388 else preferred_lifetime = 0 389 } 391 If VRRP is not used or interface status tracking is not used for 392 mastership switchover, then each router needs to be able to detect 393 the uplink failure/recovery on the neighboring router, so that RAs 394 with updated preferred lifetime values are triggered. Depending on 395 the network setup various triggers like a route to the uplink 396 interface subnet or a default route received from the uplink can be 397 used. The obvious drawback of using the routing table to trigger the 398 conditional RAs is that some additional configuration is required. 399 For example, if a route to the prefix assigned to the ISP uplink is 400 used as a trgger, then the conditional RA policy would have the 401 following logic: 403 R1: 405 prefix 2001:db8:1:1::/64 { 406 if ISP_A_uplink is up then preferred_lifetime = 604800 407 else preferred_lifetime = 0 408 } 410 R2: 412 prefix 2001:db8:2:1::/64 { 413 if ISP_A_uplink_route is present then preferred_lifetime = 0 414 else preferred_lifetime = 604800 415 } 417 3.2.3. Single Router, Load Balancing Between Uplinks 419 Let's look at the example topology shown in Figure 1, but with both 420 uplinks used simultaneously. In this case R1 would send RAs 421 containing PIOs for both prefixes, 2001:db8:1:1::/64 and 422 2001:db8:2:1::/64, changing the preferred lifetime based on 423 particular uplink availability. If the interface status is used as 424 uplink availability indicator, then the policy logic would look like 425 the following: 427 prefix 2001:db8:1:1::/64 { 428 if ISP_A_uplink is up then preferred_lifetime = 604800 429 else preferred_lifetime = 0 430 } 431 prefix 2001:db8:2:1::/64 { 432 if ISP_B_uplink is up then preferred_lifetime = 604800 433 else preferred_lifetime = 0 434 } 436 R1 needs a forwarding policy to be applied to forward packets to the 437 correct uplink based on the source address as described in 438 Section 3.2.1. 440 3.2.4. Two Router, Load Balancing Between Uplinks 442 In this scenario the example topology is similar to the one shown in 443 Figure 2, but both uplinks can be used at the same time. It means 444 that both R1 and R2 need to have the corresponding forwarding policy 445 to forward packets based on their source addresses. 447 Each router would send RAs with POI for the corresponding prefix. 448 setting preferred_lifetime to a non-zero value when the ISP uplink is 449 up, and deprecating the prefix by setting the preferred lifetime to 0 450 in case of uplink failure. The uplink recovery would trigger another 451 RA with non-zero preferred lifetime to make the addresses from the 452 prefix preferred again. The example RA policy on R1 and R2 would 453 look like: 455 R1: 457 prefix 2001:db8:1:1::/64 { 458 if ISP_A_uplink is up then preferred_lifetime = 604800 459 else preferred_lifetime = 0 460 } 462 R2: 464 prefix 2001:db8:2:1::/64 { 465 if ISP_B_uplink is up then preferred_lifetime = 604800 466 else preferred_lifetime = 0 467 } 469 3.2.5. Topologies with Dedicated Border Routers 471 For simplicity reasons all topologies below show the ISP uplinks 472 terminated on the first-hop routers. Obviously, the proposed 473 approach can be used in more complex topologies when dedicated 474 devices are used for terminating ISP uplinks. In that case VRRP 475 mastership or inteface status can not be used as a trigger for 476 conditional RAs and route presence as described above should be used 477 instead. 479 Let's look at the example topology shown on the Figure 3: 481 2001:db8:1::/48 -------- 482 2001:db8:1:1::/64 ,-------, ,' ', 483 +----+ +---+ +----+ ,' ', : : 484 _| |--| |--| R3 |----+ ISP_A +---+: : 485 | | R1 | | | +----+ ', ,' : : 486 | +----+ | | '-------' : : 487 H1--------| |LAN| : INTERNET : 488 | +----+ | | ,-------, : : 489 |_| | | | +----+ ,' ', : : 490 | R2 |--| |--| R4 |----+ ISP_B +---+: : 491 +----+ +---+ +----+ ', ,' : : 492 2001:db8:2:1::/64 '-------' ', ,' 493 2001:db8:2::/48 -------- 495 Figure 3: Dedicated Border Routers 497 For example, if ISP_A is a primary uplink and ISP_B is a backup one 498 then the following policy might be used to achieve the desired 499 behaviour (H1 is using ISP_A address space, 2001:db8:1:1::/64 while 500 ISP_A uplink is up and only using ISP_B 2001:db8:2:1::/64 prefix if 501 the uplink is non-operational): 503 R1 and R2 policy: 505 prefix 2001:db8:1:1::/64 { 506 if ISP_A_uplink_route is present then preferred_lifetime = 604800 507 else preferred_lifetime = 0 508 } 509 prefix 2001:db8:2:1::/64 { 510 if ISP_A_uplink_route is present then preferred_lifetime = 0 511 else preferred_lifetime = 604800 512 } 514 For load-balancing case the policy would look slightly different: 515 each prefix has non-zero preferred_lifetime only if the correspnding 516 ISP uplink route is present: 518 prefix 2001:db8:1:1::/64 { 519 if ISP_A_uplink_route is present then preferred_lifetime = 604800 520 else preferred_lifetime = 0 521 } 522 prefix 2001:db8:2:1::/64 { 523 if ISP_B_uplink_route is present then preferred_lifetime = 0 524 else preferred_lifetime = 604800 525 } 527 4. IANA Considerations 529 This memo asks the IANA for no new parameters. 531 5. Security Considerations 533 5.1. Privacy Considerations 535 6. Acknowledgements 537 7. References 539 7.1. Normative References 541 [I-D.ietf-rtgwg-enterprise-pa-multihoming] 542 Baker, F., Bowers, C., and J. Linkova, "Enterprise 543 Multihoming using Provider-Assigned Addresses without 544 Network Prefix Translation: Requirements and Solution", 545 draft-ietf-rtgwg-enterprise-pa-multihoming-00 (work in 546 progress), March 2017. 548 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 549 and E. Lear, "Address Allocation for Private Internets", 550 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 551 . 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, 556 . 558 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 559 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 560 December 1998, . 562 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 563 Defeating Denial of Service Attacks which employ IP Source 564 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 565 May 2000, . 567 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 568 Address Translator (Traditional NAT)", RFC 3022, 569 DOI 10.17487/RFC3022, January 2001, 570 . 572 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 573 Multihoming Architectures", RFC 3582, 574 DOI 10.17487/RFC3582, August 2003, 575 . 577 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 578 Gill, "IPv4 Multihoming Practices and Limitations", 579 RFC 4116, DOI 10.17487/RFC4116, July 2005, 580 . 582 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 583 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 584 . 586 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 587 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 588 October 2005, . 590 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 591 Should Think About", RFC 4219, DOI 10.17487/RFC4219, 592 October 2005, . 594 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 595 Address Autoconfiguration", RFC 4862, 596 DOI 10.17487/RFC4862, September 2007, 597 . 599 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 600 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 601 . 603 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 604 and D. Wing, "IPv6 Multihoming without Network Address 605 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 606 . 608 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 609 "IPv6 Router Advertisement Options for DNS Configuration", 610 RFC 8106, DOI 10.17487/RFC8106, March 2017, 611 . 613 7.2. Informative References 615 [I-D.ietf-rtgwg-dst-src-routing] 616 Lamparter, D. and A. Smirnov, "Destination/Source 617 Routing", draft-ietf-rtgwg-dst-src-routing-04 (work in 618 progress), May 2017. 620 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 621 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 622 2004, . 624 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 625 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 626 DOI 10.17487/RFC4861, September 2007, 627 . 629 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 630 Extensions for Stateless Address Autoconfiguration in 631 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 632 . 634 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 635 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 636 June 2009, . 638 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 639 Locator Pair Exploration Protocol for IPv6 Multihoming", 640 RFC 5534, DOI 10.17487/RFC5534, June 2009, 641 . 643 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 644 "Default Address Selection for Internet Protocol Version 6 645 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 646 . 648 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 649 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 650 2016, . 652 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 653 Hosts in a Multi-Prefix Network", RFC 8028, 654 DOI 10.17487/RFC8028, November 2016, 655 . 657 Appendix A. Change Log 659 Initial Version: July 2017 661 Authors' Addresses 663 Jen Linkova 664 Google 665 Mountain View, California 94043 666 USA 668 Email: furry@google.com 670 Massimiliano Stucchi 672 Email: max@stucchi.ch