idnits 2.17.1 draft-ietf-rtgwg-enterprise-pa-multihoming-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2019) is 1805 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-04 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group F. Baker 3 Internet-Draft 4 Intended status: Informational C. Bowers 5 Expires: November 18, 2019 Juniper Networks 6 J. Linkova 7 Google 8 May 17, 2019 10 Enterprise Multihoming using Provider-Assigned IPv6 Addresses without 11 Network Prefix Translation: Requirements and Solution 12 draft-ietf-rtgwg-enterprise-pa-multihoming-08 14 Abstract 16 Connecting an enterprise site to multiple ISPs using provider- 17 assigned addresses is difficult without the use of some form of 18 Network Address Translation (NAT). Much has been written on this 19 topic over the last 10 to 15 years, but it still remains a problem 20 without a clearly defined or widely implemented solution. Any 21 multihoming solution without NAT requires hosts at the site to have 22 addresses from each ISP and to select the egress ISP by selecting a 23 source address for outgoing packets. It also requires routers at the 24 site to take into account those source addresses when forwarding 25 packets out towards the ISPs. 27 This document attempts to define a complete solution to this problem. 28 It covers the behavior of routers to forward traffic taking into 29 account source address, and it covers the behavior of host to select 30 appropriate source addresses. It also covers any possible role that 31 routers might play in providing information to hosts to help them 32 select appropriate source addresses. In the process of exploring 33 potential solutions, this document also makes explicit requirements 34 for how the solution would be expected to behave from the perspective 35 of an enterprise site network administrator. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on November 18, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 73 3. Enterprise Multihoming Requirements . . . . . . . . . . . . . 6 74 3.1. Simple ISP Connectivity with Connected SERs . . . . . . . 6 75 3.2. Simple ISP Connectivity Where SERs Are Not Directly 76 Connected . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3. Enterprise Network Operator Expectations . . . . . . . . 9 78 3.4. More complex ISP connectivity . . . . . . . . . . . . . . 12 79 3.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 14 80 3.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 15 81 4. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 15 82 5. Mechanisms For Hosts To Choose Good Source Addresses In A 83 Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 22 84 5.1. Source Address Selection Algorithm on Hosts . . . . . . . 24 85 5.2. Selecting Source Address When Both Uplinks Are Working . 27 86 5.2.1. Distributing Address Selection Policy Table with 87 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 27 88 5.2.2. Controlling Source Address Selection With Router 89 Advertisements . . . . . . . . . . . . . . . . . . . 27 90 5.2.3. Controlling Source Address Selection With ICMPv6 . . 29 91 5.2.4. Summary of Methods For Controlling Source Address 92 Selection To Implement Routing Policy . . . . . . . . 31 93 5.3. Selecting Source Address When One Uplink Has Failed . . . 32 94 5.3.1. Controlling Source Address Selection With DHCPv6 . . 32 95 5.3.2. Controlling Source Address Selection With Router 96 Advertisements . . . . . . . . . . . . . . . . . . . 34 98 5.3.3. Controlling Source Address Selection With ICMPv6 . . 35 99 5.3.4. Summary Of Methods For Controlling Source Address 100 Selection On The Failure Of An Uplink . . . . . . . . 35 101 5.4. Selecting Source Address Upon Failed Uplink Recovery . . 36 102 5.4.1. Controlling Source Address Selection With DHCPv6 . . 36 103 5.4.2. Controlling Source Address Selection With Router 104 Advertisements . . . . . . . . . . . . . . . . . . . 36 105 5.4.3. Controlling Source Address Selection With ICMP . . . 37 106 5.4.4. Summary Of Methods For Controlling Source Address 107 Selection Upon Failed Uplink Recovery . . . . . . . . 37 108 5.5. Selecting Source Address When All Uplinks Failed . . . . 37 109 5.5.1. Controlling Source Address Selection With DHCPv6 . . 38 110 5.5.2. Controlling Source Address Selection With Router 111 Advertisements . . . . . . . . . . . . . . . . . . . 38 112 5.5.3. Controlling Source Address Selection With ICMPv6 . . 39 113 5.5.4. Summary Of Methods For Controlling Source Address 114 Selection When All Uplinks Failed . . . . . . . . . . 39 115 5.6. Summary Of Methods For Controlling Source Address 116 Selection . . . . . . . . . . . . . . . . . . . . . . . . 39 117 5.7. Other Configuration Parameters . . . . . . . . . . . . . 40 118 5.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40 119 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 42 120 7. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 43 121 7.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 43 122 7.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 43 123 7.3. Multipath Transport . . . . . . . . . . . . . . . . . . . 43 124 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 125 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 126 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 127 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 128 11.1. Normative References . . . . . . . . . . . . . . . . . . 44 129 11.2. Informative References . . . . . . . . . . . . . . . . . 46 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 132 1. Introduction 134 Site multihoming, the connection of a subscriber network to multiple 135 upstream networks using redundant uplinks, is a common enterprise 136 architecture for improving the reliability of its Internet 137 connectivity. If the site uses provider-independent (PI) addresses, 138 all traffic originating from the enterprise can use source addresses 139 from the PI address space. Site multihoming with PI addresses is 140 commonly used with both IPv4 and IPv6, and does not present any new 141 technical challenges. 143 It may be desirable for an enterprise site to connect to multiple 144 ISPs using provider-assigned (PA) addresses, instead of PI addresses. 145 Multihoming with provider-assigned addresses is typically less 146 expensive for the enterprise relative to using provider-independent 147 addresses. PA multihoming is also a practice that should be 148 facilitated and encouraged because it does not add to the size of the 149 Internet routing table, whereas PI multihoming does. Note that PA is 150 also used to mean "provider-aggregatable". In this document we 151 assume that provider-assigned addresses are always provider- 152 aggregatable. 154 With PA multihoming, for each ISP connection, the site is assigned a 155 prefix from within an address block allocated to that ISP by its 156 National or Regional Internet Registry. In the simple case of two 157 ISPs (ISP-A and ISP-B), the site will have two different prefixes 158 assigned to it (prefix-A and prefix-B). This arrangement is 159 problematic. First, packets with the "wrong" source address may be 160 dropped by one of the ISPs. In order to limit denial of service 161 attacks using spoofed source addresses, BCP38 [RFC2827] recommends 162 that ISPs filter traffic from customer sites to only allow traffic 163 with a source address that has been assigned by that ISP. So a 164 packet sent from a multihomed site on the uplink to ISP-B with a 165 source address in prefix-A may be dropped by ISP-B. 167 However, even if ISP-B does not implement BCP38 or ISP-B adds 168 prefix-A to its list of allowed source addresses on the uplink from 169 the multihomed site, two-way communication may still fail. If the 170 packet with source address in prefix-A was sent to ISP-B because the 171 uplink to ISP-A failed, then if ISP-B does not drop the packet and 172 the packet reaches its destination somewhere on the Internet, the 173 return packet will be sent back with a destination address in prefix- 174 A. The return packet will be routed over the Internet to ISP-A, but 175 it will not be delivered to the multihomed site because its link with 176 ISP-A has failed. Two-way communication would require some 177 arrangement for ISP-B to advertise prefix-A when the uplink to ISP-A 178 fails. 180 Note that the same may be true with a provider that does not 181 implement BCP 38, if his upstream provider does, or has no 182 corresponding route. The issue is not that the immediate provider 183 implements ingress filtering; it is that someone upstream does, or 184 lacks a route. 186 With IPv4, this problem is commonly solved by using [RFC1918] private 187 address space within the multi-homed site and Network Address 188 Translation (NAT) or Network Address/Port Translation (NAPT) on the 189 uplinks to the ISPs. However, one of the goals of IPv6 is to 190 eliminate the need for and the use of NAT or NAPT. Therefore, 191 requiring the use of NAT or NAPT for an enterprise site to multihome 192 with provider-assigned addresses is not an attractive solution. 194 [RFC6296] describes a translation solution specifically tailored to 195 meet the requirements of multi-homing with provider-assigned IPv6 196 addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) 197 solution, within the site an enterprise can use Unique Local 198 Addresses [RFC4193] or the prefix assigned by one of the ISPs. As 199 traffic leaves the site on an uplink to an ISP, the source address 200 gets translated to an address within the prefix assigned by the ISP 201 on that uplink in a predictable and reversible manner. [RFC6296] is 202 currently classified as Experimental, and it has been implemented by 203 several vendors. See Section 7.2, for more discussion of NPTv6. 205 This document defines routing requirements for enterprise multihoming 206 using provider-assigned IPv6 addresses. We have made no attempt to 207 write these requirements in a manner that is agnostic to potential 208 solutions. Instead, this document focuses on the following general 209 class of solutions. 211 Each host at the enterprise has multiple addresses, at least one from 212 each ISP-assigned prefix. Each host, as discussed in Section 5.1 and 213 [RFC6724], is responsible for choosing the source address applied to 214 each packet it sends. A host SHOULD be able respond dynamically to 215 the failure of an uplink to a given ISP by no longer sending packets 216 with the source address corresponding to that ISP. Potential 217 mechanisms for the communication of changes in the network to the 218 host are Neighbor Discovery Router Advertisements, DHCPv6, and 219 ICMPv6. 221 The routers in the enterprise network are responsible for ensuring 222 that packets are delivered to the "correct" ISP uplink based on 223 source address. This requires that at least some routers in the site 224 network are able to take into account the source address of a packet 225 when deciding how to route it. That is, some routers must be capable 226 of some form of Source Address Dependent Routing (SADR), if only as 227 described in [RFC3704]. At a minimum, the routers connected to the 228 ISP uplinks (the site exit routers or SERs) must be capable of Source 229 Address Dependent Routing. Expanding the connected domain of routers 230 capable of SADR from the site exit routers deeper into the site 231 network will generally result in more efficient routing of traffic 232 with external destinations. 234 This document is organized as follows. Section 3 looks in more 235 detail at the enterprise networking environments in which this 236 solution is expected to operate. The discussion of Section 3 uses 237 the concepts of source-prefix-scoped routing advertisements and 238 forwarding tables without stopping to provide a precise description 239 of how source-prefix-scoped routing advertisements are used to 240 generate source-prefix-scoped forwarding tables. Instead, this 241 detailed description is provided in Section 4. Section 5 discusses 242 existing and proposed mechanisms for hosts to select the source 243 address applied to packets. It also discusses the requirements for 244 routing that are needed to support these enterprise network scenarios 245 and the mechanisms by which hosts are expected to select source 246 addresses dynamically based on network state. Section 6 discusses 247 deployment considerations, while Section 7 discussed other solutions. 249 2. Requirements Language 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 253 "OPTIONAL" in this document are to be interpreted as described in BCP 254 14 [RFC2119] [RFC8174] when, and only when, they appear in all 255 capitals, as shown here. 257 3. Enterprise Multihoming Requirements 259 3.1. Simple ISP Connectivity with Connected SERs 261 We start by looking at a scenario in which a site has connections to 262 two ISPs, as shown in Figure 1. The site is assigned the prefix 263 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP- 264 B. We consider three hosts in the site. H31 and H32 are on a LAN 265 that has been assigned subnets 2001:db8:0:a010::/64 and 266 2001:db8:0:b010::/64. H31 has been assigned the addresses 267 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned 268 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different 269 subnet that has been assigned 2001:db8:0:a020::/64 and 270 2001:db8:0:b020::/64. 272 2001:db8:0:1234::101 H101 273 | 274 | 275 2001:db8:0:a010::31 -------- 276 2001:db8:0:b010::31 ,-----. / \ 277 +--+ +--+ +----+ ,' `. : : 278 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 279 H31--+ +--+ +--+ | +----+ `. ,' : : 280 | | `-----' : Internet : 281 | | : : 282 | | : : 283 | | : : 284 | | ,-----. : : 285 H32--+ +--+ | +----+ ,' `. : : 286 +---|R2|----------+---|SERb|-+ ISP-B +--+-- : 287 +--+ | +----+ `. ,' : : 288 | `-----' : : 289 | : : 290 +--+ +--+ +--+ \ / 291 H41------|R3|--|R5|--|R6| -------- 292 +--+ +--+ +--+ 294 2001:db8:0:a020::41 295 2001:db8:0:b020::41 297 Figure 1: Simple ISP Connectivity With Connected SERs 299 We refer to a router that connects the site to an ISP as a site edge 300 router(SER). Several other routers provide connectivity among the 301 internal hosts (H31, H32, and H41), as well as connecting the 302 internal hosts to the Internet through SERa and SERb. In this 303 example SERa and SERb share a direct connection to each other. In 304 Section 3.2, we consider a scenario where this is not the case. 306 For the moment, we assume that the hosts are able to make good 307 choices about which source addresses through some mechanism that 308 doesn't involve the routers in the site network. Here, we focus on 309 primary task of the routed site network, which is to get packets 310 efficiently to their destinations, while sending a packet to the ISP 311 that assigned the prefix that matches the source address of the 312 packet. In Section 5, we examine what role the routed network may 313 play in helping hosts make good choices about source addresses for 314 packets. 316 With this solution, routers will need some form of Source Address 317 Dependent Routing, which will be new functionality. It would be 318 useful if an enterprise site does not need to upgrade all routers to 319 support the new SADR functionality in order to support PA multi- 320 homing. We consider if this is possible and what are the tradeoffs 321 of not having all routers in the site support SADR functionality. 323 In the topology in Figure 1, it is possible to support PA multihoming 324 with only SERa and SERb being capable of SADR. The other routers can 325 continue to forward based only on destination address, and exchange 326 routes that only consider destination address. In this scenario, 327 SERa and SERb communicate source-scoped routing information across 328 their shared connection. When SERa receives a packet with a source 329 address matching prefix 2001:db8:0:b000::/52 , it forwards the packet 330 to SERb, which forwards it on the uplink to ISP-B. The analogous 331 behaviour holds for traffic that SERb receives with a source address 332 matching prefix 2001:db8:0:a000::/52. 334 In Figure 1, when only SERa and SERb are capable of source address 335 dependent routing, PA multi-homing will work. However, the paths 336 over which the packets are sent will generally not be the shortest 337 paths. The forwarding paths will generally be more efficient as more 338 routers are capable of SADR. For example, if R4, R2, and R6 are 339 upgraded to support SADR, then can exchange source-scoped routes with 340 SERa and SERb. They will then know to send traffic with a source 341 address matching prefix 2001:db8:0:b000::/52 directly to SERb, 342 without sending it to SERa first. 344 3.2. Simple ISP Connectivity Where SERs Are Not Directly Connected 346 In Figure 2, we modify the topology slightly by inserting R7, so that 347 SERa and SERb are no longer directly connected. With this topology, 348 it is not enough to just enable SADR routing on SERa and SERb to 349 support PA multi-homing. There are two solutions to ways to enable 350 PA multihoming in this topology. 352 2001:db8:0:1234::101 H101 353 | 354 | 355 2001:db8:0:a010::31 -------- 356 2001:db8:0:b010::31 ,-----. / \ 357 +--+ +--+ +----+ ,' `. : : 358 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 359 H31--+ +--+ +--+ | +----+ `. ,' : : 360 | | `-----' : Internet : 361 | +--+ : : 362 | |R7| : : 363 | +--+ : : 364 | | ,-----. : : 365 H32--+ +--+ | +----+ ,' `. : : 366 +---|R2|----------+---|SERb|-+ ISP-B +--+-- : 367 +--+ | +----+ `. ,' : : 368 | `-----' : : 369 | : : 370 +--+ +--+ +--+ \ / 371 H41------|R3|--|R5|--|R6| -------- 372 +--+ +--+ +--+ | 373 | 374 2001:db8:0:a020::41 2001:db8:0:5678::501 H501 375 2001:db8:0:b020::41 377 Figure 2: Simple ISP Connectivity Where SERs Are Not Directly 378 Connected 380 One option is to effectively modify the topology by creating a 381 logical tunnel between SERa and SERb, using GRE for example. 382 Although SERa and SERb are not directly connected physically in this 383 topology, they can be directly connected logically by a tunnel. 385 The other option is to enable SADR functionality on R7. In this way, 386 R7 will exchange source-scoped routes with SERa and SERb, making the 387 three routers act as a single SADR domain. This illustrates the 388 basic principle that the minimum requirement for the routed site 389 network to support PA multi-homing is having all of the site exit 390 routers be part of a connected SADR domain. Extending the connected 391 SADR domain beyond that point can produce more efficient forwarding 392 paths. 394 3.3. Enterprise Network Operator Expectations 396 Before considering a more complex scenario, let's look in more detail 397 at the reasonably simple multihoming scenario in Figure 2 to 398 understand what can reasonably be expected from this solution. As a 399 general guiding principle, we assume an enterprise network operator 400 will expect a multihomed network to behave as close as to a single- 401 homed network as possible. So a solution that meets those 402 expectations where possible is a good thing. 404 For traffic between internal hosts and traffic from outside the site 405 to internal hosts, an enterprise network operator would expect there 406 be no visible change in the path taken by this traffic, since this 407 traffic does not need to be routed in a way that depends on source 408 address. It is also reasonable to expect that internal hosts should 409 be able to communicate with each other using either of their source 410 addresses without restriction. For example, H31 should be able to 411 communicate with H41 using a packet with S=2001:db8:0:a010::31, 412 D=2001:db8:0:b010::41, regardless of the state of uplink to ISP-B. 414 These goals can be accomplished by having all of the routers in the 415 network continue to originate normal unscoped destination routes for 416 their connected networks. If we can arrange so that these unscoped 417 destination routes get used for forwarding this traffic, then we will 418 have accomplished the goal of keeping forwarding of traffic destined 419 for internal hosts, unaffected by the multihoming solution. 421 For traffic destined for external hosts, it is reasonable to expect 422 that traffic with a source address from the prefix assigned by ISP-A 423 to follow the path to that the traffic would follow if there is no 424 connection to ISP-B. This can be accomplished by having SERa 425 originate a source-scoped route of the form (S=2001:db8:0:a000::/52, 426 D=::/0) . If all of the routers in the site support SADR, then the 427 path of traffic exiting via ISP-A can match that expectation. If 428 some routers don't support SADR, then it is reasonable to expect that 429 the path for traffic exiting via ISP-A may be different within the 430 site. This is a tradeoff that the enterprise network operator may 431 decide to make. 433 It is important to understand how this multihoming solution behaves 434 when an uplink to one of the ISPs fails. To simplify this 435 discussion, we assume that all routers in the site support SADR. We 436 first start by looking at how the network operates when the uplinks 437 to both ISP-A and ISP-B are functioning properly. SERa originates a 438 source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0), and 439 SERb is originates a source-scoped route of the form 440 (S=2001:db8:0:b000::/52, D=::/0). These routes are distributed 441 through the routers in the site, and they establish within the 442 routers two set of forwarding paths for traffic leaving the site. 443 One set of forwarding paths is for packets with source address in 444 2001:db8:0:a000::/52. The other set of forwarding paths is for 445 packets with source address in 2001:db8:0:b000::/52. The normal 446 destination routes which are not scoped to these two source prefixes 447 play no role in the forwarding. Whether a packet exits the site via 448 SERa or via SERb is completely determined by the source address 449 applied to the packet by the host. So for example, when host H31 450 sends a packet to host H101 with (S=2001:db8:0:a010::31, 451 D=2001:db8:0:1234::101), the packet will only be sent out the link 452 from SERa to ISP-A. 454 Now consider what happens when the uplink from SERa to ISP-A fails. 455 The only way for the packets from H31 to reach H101 is for H31 to 456 start using the source address for ISP-B. H31 needs to send the 457 following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101). 459 This behavior is very different from the behavior that occurs with 460 site multihoming using PI addresses or with PA addresses using NAT. 461 In these other multi-homing solutions, hosts do not need to react to 462 network failures several hops away in order to regain Internet 463 access. Instead, a host can be largely unaware of the failure of an 464 uplink to an ISP. When multihoming with PA addresses and NAT, 465 existing sessions generally need to be re-established after a failure 466 since the external host will receive packets from the internal host 467 with a new source address. However, new sessions can be established 468 without any action on the part of the hosts. Multihoming with PA 469 addresses and NAT has created the expectation of a fairly quick and 470 simple recovery from network failures. Alternatives should to be 471 evaluated in terms of the speed and complexity of the recovery 472 mechanism. 474 Another example where the behavior of this multihoming solution 475 differs significantly from that of multihoming with PI address or 476 with PA addresses using NAT is in the ability of the enterprise 477 network operator to route traffic over different ISPs based on 478 destination address. We still consider the fairly simple network of 479 Figure 2 and assume that uplinks to both ISPs are functioning. 480 Assume that the site is multihomed using PA addresses and NAT, and 481 that SERa and SERb each originate a normal destination route for 482 D=::/0, with the route origination dependent on the state of the 483 uplink to the respective ISP. 485 Now suppose it is observed that an important application running 486 between internal hosts and external host H101 experience much better 487 performance when the traffic passes through ISP-A (perhaps because 488 ISP-A provides lower latency to H101.) When multihoming this site 489 with PI addresses or with PA addresses and NAT, the enterprise 490 network operator can configure SERa to originate into the site 491 network a normal destination route for D=2001:db8:0:1234::/64 (the 492 destination prefix to reach H101) that depends on the state of the 493 uplink to ISP-A. When the link to ISP-A is functioning, the 494 destination route D=2001:db8:0:1234::/64 will be originated by SERa, 495 so traffic from all hosts will use ISP-A to reach H101 based on the 496 longest destination prefix match in the route lookup. 498 Implementing the same routing policy is more difficult with the PA 499 multihoming solution described in this document since it doesn't use 500 NAT. By design, the only way to control where a packet exits this 501 network is by setting the source address of the packet. Since the 502 network cannot modify the source address without NAT, the host must 503 set it. To implement this routing policy, each host needs to use the 504 source address from the prefix assigned by ISP-A to send traffic 505 destined for H101. Mechanisms have been proposed to allow hosts to 506 choose the source address for packets in a fine grained manner. We 507 will discuss these proposals in Section 5. However, interacting with 508 host operating systems in some manner to ensure a particular source 509 address is chosen for a particular destination prefix is not what an 510 enterprise network administrator would expect to have to do to 511 implement this routing policy. 513 3.4. More complex ISP connectivity 515 The previous sections considered two variations of a simple 516 multihoming scenario where the site is connected to two ISPs offering 517 only Internet connectivity. It is likely that many actual enterprise 518 multihoming scenarios will be similar to this simple example. 519 However, there are more complex multihoming scenarios that we would 520 like this solution to address as well. 522 It is fairly common for an ISP to offer a service in addition to 523 Internet access over the same uplink. Two variations of this are 524 reflected in Figure 3. In addition to Internet access, ISP-A offers 525 a service which requires the site to access host H51 at 526 2001:db8:0:5555::51. The site has a single physical and logical 527 connection with ISP-A, and ISP-A only allows access to H51 over that 528 connection. So when H32 needs to access the service at H51 it needs 529 to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) 530 and those packets need to be forward out the link from SERa to ISP-A. 532 2001:db8:0:1234::101 H101 533 | 534 | 535 2001:db8:0:a010::31 -------- 536 2001:db8:0:b010::31 ,-----. / \ 537 +--+ +--+ +----+ ,' `. : : 538 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 539 H31--+ +--+ +--+ | +----+ `. ,' : : 540 | | `-----' : Internet : 541 | | | : : 542 | | H51 : : 543 | | 2001:db8:0:5555::51 : : 544 | +--+ : : 545 | |R7| : : 546 | +--+ : : 547 | | : : 548 | | ,-----. : : 549 H32--+ +--+ | +-----+ ,' `. : : 550 +---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- : 551 +--+ | +-----+ `. ,' : : 552 +--+ `--|--' : : 553 2001:db8:0:a010::32 |R8| | \ / 554 +--+ ,--|--. -------- 555 | +-----+ ,' `. | 556 +-------|SERb2|-+ ISP-B | | 557 | +-----+ `. ,' H501 558 | `-----' 2001:db8:0:5678 559 | | ::501 560 +--+ +--+ H61 561 H41------|R3|--|R5| 2001:db8:0:6666::61 562 +--+ +--+ 564 2001:db8:0:a020::41 565 2001:db8:0:b020::41 567 Figure 3: Internet access and services offered by ISP-A and ISP-B 569 ISP-B illustrates a variation on this scenario. In addition to 570 Internet access, ISP-B also offers a service which requires the site 571 to access host H61. The site has two connections to two different 572 parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects 573 Internet traffic to use the uplink from SERb1, while it expects 574 traffic destined for the service at H61 to use the uplink from SERb2. 575 For either uplink, ISP-B expects the ingress traffic to have a source 576 address matching the prefix it assigned to the site, 577 2001:db8:0:b000::/52. 579 As discussed before, we rely completely on the internal host to set 580 the source address of the packet properly. In the case of a packet 581 sent by H31 to access the service in ISP-B at H61, we expect the 582 packet to have the following addresses: (S=2001:db8:0:b010::31, 583 D=2001:db8:0:6666::61). The routed network has two potential ways of 584 distributing routes so that this packet exits the site on the uplink 585 at SERb2. 587 We could just rely on normal destination routes, without using 588 source-prefix scoped routes. If we have SERb2 originate a normal 589 unscoped destination route for D=2001:db8:0:6666::/64, the packets 590 from H31 to H61 will exit the site at SERb2 as desired. We should 591 not have to worry about SERa needing to originate the same route, 592 because ISP-B should choose a globally unique prefix for the service 593 at H61. 595 The alternative is to have SERb2 originate a source-prefix-scoped 596 destination route of the form (S=2001:db8:0:b000::/52, 597 D=2001:db8:0:6666::/64). From a forwarding point of view, the use of 598 the source-prefix-scoped destination route would result in traffic 599 with source addresses corresponding only to ISP-B being sent to 600 SERb2. Instead, the use of the unscoped destination route would 601 result in traffic with source addresses corresponding to ISP-A and 602 ISP-B being sent to SERb2, as long as the destination address matches 603 the destination prefix. It seems like either forwarding behavior 604 would be acceptable. 606 However, from the point of view of the enterprise network 607 administrator trying to configure, maintain, and trouble-shoot this 608 multihoming solution, it seems much clearer to have SERb2 originate 609 the source-prefix-scoped destination route correspond to the service 610 offered by ISP-B. In this way, all of the traffic leaving the site 611 is determined by the source-prefix-scoped routes, and all of the 612 traffic within the site or arriving from external hosts is determined 613 by the unscoped destination routes. Therefore, for this multihoming 614 solution we choose to originate source-prefix-scoped routes for all 615 traffic leaving the site. 617 3.5. ISPs and Provider-Assigned Prefixes 619 While we expect that most site multihoming involves connecting to 620 only two ISPs, this solution allows for connections to an arbitrary 621 number of ISPs to be supported. However, when evaluating scalable 622 implementations of the solution, it would be reasonable to assume 623 that the maximum number of ISPs that a site would connect to is five. 625 It is also useful to note that the prefixes assigned to the site by 626 different ISPs will not overlap. This must be the case, since the 627 provider-assigned addresses have to be globally unique. 629 3.6. Simplified Topologies 631 The topologies of many enterprise sites using this multihoming 632 solution may in practice be simpler than the examples that we have 633 used. The topology in Figure 1 could be further simplified by having 634 all hosts directly connected to the LAN connecting the two site exit 635 routers, SERa and SERb. The topology could also be simplified by 636 having the uplinks to ISP-A and ISP-B both connected to the same site 637 exit router. However, it is the aim of this draft to provide a 638 solution that applies to a broad a range of enterprise site network 639 topologies, so this draft focuses on providing a solution to the more 640 general case. The simplified cases will also be supported by this 641 solution, and there may even be optimizations that can be made for 642 simplified cases. This solution however needs to support more 643 complex topologies. 645 We are starting with the basic assumption that enterprise site 646 networks can be quite complex from a routing perspective. However, 647 even a complex site network can be multihomed to different ISPs with 648 PA addresses using IPv4 and NAT. It is not reasonable to expect an 649 enterprise network operator to change the routing topology of the 650 site in order to deploy IPv6. 652 4. Generating Source-Prefix-Scoped Forwarding Tables 654 So far we have described in general terms how the routers in this 655 solution that are capable of Source Address Dependent Routing will 656 forward traffic using both normal unscoped destination routes and 657 source-prefix-scoped destination routes. Here we give a precise 658 method for generating a source-prefix-scoped forwarding table on a 659 router that supports SADR. 661 1. Compute the next-hops for the source-prefix-scoped destination 662 prefixes using only routers in the connected SADR domain. These 663 are the initial source-prefix-scoped forwarding table entries. 665 2. Compute the next-hops for the unscoped destination prefixes using 666 all routers in the IGP. This is the unscoped forwarding table. 668 3. Augment each less specific source-prefix-scoped forwarding table 669 with all more specific source-prefix-scoped forwarding tables 670 entries based on the following rule. If the destination prefix 671 of the less specific source-prefix-scoped forwarding entry 672 exactly matches the destination prefix of an existing more 673 specific source-prefix-scoped forwarding entry (including 674 destination prefix length), then do not add the less specific 675 source-prefix-scoped forwarding entry. If the destination prefix 676 does NOT match an existing entry, then add the entry to the more 677 source-prefix-scoped forwarding table. As the unscoped 678 forwarding table is considered to be scoped to ::/0 this process 679 starts with propagating routes from the unscoped forwarding table 680 to source-prefix-scoped forwarding tables and then continues with 681 propagating routes to more-specific-source-prefix-scoped 682 forwarding tables should they exist. 684 The forward tables produced by this process are used in the following 685 way to forward packets. 687 1. Select the most specific (longest prefix match) source-prefix- 688 scoped forwarding table entries that matches the source address 689 of the packet (again, the unscoped forwarding table is considered 690 to be scoped to ::/0). 692 2. Look up the destination address of the packet in the selected 693 forwarding table to determine the next-hop for the packet. 695 The following example illustrates how this process is used to create 696 a forwarding table for each provider-assigned source prefix. We 697 consider the multihomed site network in Figure 3. Initially we 698 assume that all of the routers in the site network support SADR. 699 Figure 4 shows the routes that are originated by the routers in the 700 site network. 702 Routes originated by SERa: 703 (S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64) 704 (S=2001:db8:0:a000::/52, D=::/0) 705 (D=2001:db8:0:5555::/64) 706 (D=::/0) 708 Routes originated by SERb1: 709 (S=2001:db8:0:b000::/52, D=::/0) 710 (D=::/0) 712 Routes originated by SERb2: 713 (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64) 714 (D=2001:db8:0:6666::/64) 716 Routes originated by R1: 717 (D=2001:db8:0:a010::/64) 718 (D=2001:db8:0:b010::/64) 720 Routes originated by R2: 721 (D=2001:db8:0:a010::/64) 722 (D=2001:db8:0:b010::/64) 724 Routes originated by R3: 725 (D=2001:db8:0:a020::/64) 726 (D=2001:db8:0:b020::/64) 728 Figure 4: Routes Originated by Routers in the Site Network 730 Each SER originates destination routes which are scoped to the source 731 prefix assigned by the ISP that the SER connects to. Note that the 732 SERs also originate the corresponding unscoped destination route. 733 This is not needed when all of the routers in the site support SADR. 734 However, it is required when some routers do not support SADR. This 735 will be discussed in more detail later. 737 We focus on how R8 constructs its source-prefix-scoped forwarding 738 tables from these route advertisements. R8 computes the next hops 739 for destination routes which are scoped to the source prefix 740 2001:db8:0:a000::/52. The results are shown in the first table in 741 Figure 5. (In this example, the next hops are computed assuming that 742 all links have the same metric.) Then, R8 computes the next hops for 743 destination routes which are scoped to the source prefix 744 2001:db8:0:b000::/52. The results are shown in the second table in 745 Figure 5 . Finally, R8 computes the next hops for the unscoped 746 destination prefixes. The results are shown in the third table in 747 Figure 5. 749 forwarding entries scoped to 750 source prefix = 2001:db8:0:a000::/52 751 ============================================ 752 D=2001:db8:0:5555/64 NH=R7 753 D=::/0 NH=R7 755 forwarding entries scoped to 756 source prefix = 2001:db8:0:b000::/52 757 ============================================ 758 D=2001:db8:0:6666/64 NH=SERb2 759 D=::/0 NH=SERb1 761 unscoped forwarding entries 762 ============================================ 763 D=2001:db8:0:a010::/64 NH=R2 764 D=2001:db8:0:b010::/64 NH=R2 765 D=2001:db8:0:a020::/64 NH=R5 766 D=2001:db8:0:b020::/64 NH=R5 767 D=2001:db8:0:5555::/64 NH=R7 768 D=2001:db8:0:6666::/64 NH=SERb2 769 D=::/0 NH=SERb1 771 Figure 5: Forwarding Entries Computed at R8 773 The final step is for R8 to augment the less specific source-prefix- 774 scoped forwarding entries with more specific source-prefix-scoped 775 forwarding entries. As unscoped forwarding table is considered being 776 scoped to ::/0 and both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 777 are more specific prefixes of ::/0, the unscoped (scoped to ::/0) 778 forwarding table needs to be augmented with both more specific 779 source-prefix-scoped tables. If a less specific scoped forwarding 780 entry has the exact same destination prefix as a more specific 781 source-prefix-scoped forwarding entry (including destination prefix 782 length), then the more specific source-prefix-scoped forwarding entry 783 wins. 785 As as an example of how the source scoped forwarding entries are 786 augmented, we consider how the two entries in the first table in 787 Figure 5 (the table for source prefix = 2001:db8:0:a000::/52) are 788 augmented with entries from the third table in Figure 5 (the table of 789 unscoped or scoped to ::/0 forwarding entries). The first four 790 unscoped forwarding entries (D=2001:db8:0:a010::/64, 791 D=2001:db8:0:b010::/64, D=2001:db8:0:a020::/64, and 792 D=2001:db8:0:b020::/64) are not an exact match for any of the 793 existing entries in the forwarding table for source prefix 794 2001:db8:0:a000::/52. Therefore, these four entries are added to the 795 final forwarding table for source prefix 2001:db8:0:a000::/52. The 796 result of adding these entries is reflected in the first four entries 797 the first table in Figure 6. 799 The next less specific scoped (scope is ::/0) forwarding table entry 800 is for D=2001:db8:0:5555::/64. This entry is an exact match for the 801 existing entry in the forwarding table for the more specific source 802 prefix 2001:db8:0:a000::/52. Therefore, we do not replace the 803 existing entry with the entry from the unscoped forwarding table. 804 This is reflected in the fifth entry in the first table in Figure 6. 805 (Note that since both scoped and unscoped entries have R7 as the next 806 hop, the result of applying this rule is not visible.) 808 The next less specific prefix scoped (scope is ::/0) forwarding table 809 entry is for D=2001:db8:0:6666::/64. This entry is not an exact 810 match for any existing entries in the forwarding table for source 811 prefix 2001:db8:0:a000::/52. Therefore, we add this entry. This is 812 reflected in the sixth entry in the first table in Figure 6. 814 The next less specific prefix scoped (scope is ::/0) forwarding table 815 entry is for D=::/0. This entry is an exact match for the existing 816 entry in the forwarding table for more specific source prefix 817 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing 818 source-prefix-scoped entry, as can be seen in the last entry in the 819 first table in Figure 6. 821 if source address matches 2001:db8:0:a000::/52 822 then use this forwarding table 823 ============================================ 824 D=2001:db8:0:a010::/64 NH=R2 825 D=2001:db8:0:b010::/64 NH=R2 826 D=2001:db8:0:a020::/64 NH=R5 827 D=2001:db8:0:b020::/64 NH=R5 828 D=2001:db8:0:5555::/64 NH=R7 829 D=2001:db8:0:6666::/64 NH=SERb2 830 D=::/0 NH=R7 832 else if source address matches 2001:db8:0:b000::/52 833 then use this forwarding table 834 ============================================ 835 D=2001:db8:0:a010::/64 NH=R2 836 D=2001:db8:0:b010::/64 NH=R2 837 D=2001:db8:0:a020::/64 NH=R5 838 D=2001:db8:0:b020::/64 NH=R5 839 D=2001:db8:0:5555::/64 NH=R7 840 D=2001:db8:0:6666::/64 NH=SERb2 841 D=::/0 NH=SERb1 843 else if source address matches ::/0 use this forwarding table 844 ============================================ 845 D=2001:db8:0:a010::/64 NH=R2 846 D=2001:db8:0:b010::/64 NH=R2 847 D=2001:db8:0:a020::/64 NH=R5 848 D=2001:db8:0:b020::/64 NH=R5 849 D=2001:db8:0:5555::/64 NH=R7 850 D=2001:db8:0:6666::/64 NH=SERb2 851 D=::/0 NH=SERb1 853 Figure 6: Complete Forwarding Tables Computed at R8 855 The forwarding tables produced by this process at R8 have the desired 856 properties. A packet with a source address in 2001:db8:0:a000::/52 857 will be forwarded based on the first table in Figure 6. If the 858 packet is destined for the Internet at large or the service at 859 D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. 860 If the packet is destined for an internal host, then the first four 861 entries will send it to R2 or R5 as expected. Note that if this 862 packet has a destination address corresponding to the service offered 863 by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to 864 SERb2. It will be dropped by SERb2 or by ISP-B, since the packet has 865 a source address that was not assigned by ISP-B. However, this is 866 expected behavior. In order to use the service offered by ISP-B, the 867 host needs to originate the packet with a source address assigned by 868 ISP-B. 870 In this example, a packet with a source address that doesn't match 871 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated 872 from an external host. Such a packet will use the unscoped 873 forwarding table (the last table in Figure 6). These packets will 874 flow exactly as they would in absence of multihoming. 876 We can also modify this example to illustrate how it supports 877 deployments where not all routers in the site support SADR. 878 Continuing with the topology shown in Figure 3, suppose that R3 and 879 R5 do not support SADR. Instead they are only capable of 880 understanding unscoped route advertisements. The SADR routers in the 881 network will still originate the routes shown in Figure 4. However, 882 R3 and R5 will only understand the unscoped routes as shown in 883 Figure 7. 885 Routes originated by SERa: 886 (D=2001:db8:0:5555::/64) 887 (D=::/0) 889 Routes originated by SERb1: 890 (D=::/0) 892 Routes originated by SERb2: 893 (D=2001:db8:0:6666::/64) 895 Routes originated by R1: 896 (D=2001:db8:0:a010::/64) 897 (D=2001:db8:0:b010::/64) 899 Routes originated by R2: 900 (D=2001:db8:0:a010::/64) 901 (D=2001:db8:0:b010::/64) 903 Routes originated by R3: 904 (D=2001:db8:0:a020::/64) 905 (D=2001:db8:0:b020::/64) 907 Figure 7: Routes Advertisements Understood by Routers that do no 908 Support SADR 910 With these unscoped route advertisements, R5 will produce the 911 forwarding table shown in Figure 8. 913 forwarding table 914 ============================================ 915 D=2001:db8:0:a010::/64 NH=R8 916 D=2001:db8:0:b010::/64 NH=R8 917 D=2001:db8:0:a020::/64 NH=R3 918 D=2001:db8:0:b020::/64 NH=R3 919 D=2001:db8:0:5555::/64 NH=R8 920 D=2001:db8:0:6666::/64 NH=SERb2 921 D=::/0 NH=R8 923 Figure 8: Forwarding Table For R5, Which Doesn't Understand Source- 924 Prefix-Scoped Routes 926 Any traffic that needs to exit the site will eventually hit a SADR- 927 capable router. Once that traffic enters the SADR-capable domain, 928 then it will not leave that domain until it exits the site. This 929 property is required in order to guarantee that there will not be 930 routing loops involving SADR-capable and non-SADR-capable routers. 932 Note that the mechanism described here for converting source-prefix- 933 scoped destination prefix routing advertisements into forwarding 934 state is somewhat different from that proposed in 935 [I-D.ietf-rtgwg-dst-src-routing]. The method described in the 936 current document is functionally equivalent, but it is intended to be 937 easier to understand for enterprise network operators. 939 An interesting side-effect of deploying SADR is if all routers in a 940 given network support SADR and have a scoped forwarding table, then 941 the unscoped forwarding table can be eliminated which ensures that 942 packets with legitimate source addresses only can leave the network 943 (as there are no scoped forwarding tables for spoofed/bogon source 944 addresses). It would prevent accidental leaks of ULA/reserved/link- 945 local sources to the Internet as well as ensures that no spoofing is 946 possible from the SADR-enabled network. 948 5. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed 949 Site 951 Until this point, we have made the assumption that hosts are able to 952 choose the correct source address using some unspecified mechanism. 953 This has allowed us to just focus on what the routers in a multihomed 954 site network need to do in order to forward packets to the correct 955 ISP based on source address. Now we look at possible mechanisms for 956 hosts to choose the correct source address. We also look at what 957 role, if any, the routers may play in providing information that 958 helps hosts to choose source addresses. 960 Any host that needs to be able to send traffic using the uplinks to a 961 given ISP is expected to be configured with an address from the 962 prefix assigned by that ISP. The host will control which ISP is used 963 for its traffic by selecting one of the addresses configured on the 964 host as the source address for outgoing traffic. It is the 965 responsibility of the site network to ensure that a packet with the 966 source address from an ISP is now sent on an uplink to that ISP. 968 If all of the ISP uplinks are working, the choice of source address 969 by the host may be driven by the desire to load share across ISP 970 uplinks, or it may be driven by the desire to take advantage of 971 certain properties of a particular uplink or ISP. If any of the ISP 972 uplinks is not working, then the choice of source address by the host 973 can determine if packets get dropped. 975 How a host should make good decisions about source address selection 976 in a multihomed site is not a solved problem. We do not attempt to 977 solve this problem in this document. Instead we discuss the current 978 state of affairs with respect to standardized solutions and 979 implementation of those solutions. We also look at proposed 980 solutions for this problem. 982 An external host initiating communication with a host internal to a 983 PA multihomed site will need to know multiple addresses for that host 984 in order to communicate with it using different ISPs to the 985 multihomed site. These addresses are typically learned through DNS. 986 (For simplicity, we assume that the external host is single-homed.) 987 The external host chooses the ISP that will be used at the remote 988 multihomed site by setting the destination address on the packets it 989 transmits. For a session originated from an external host to an 990 internal host, the choice of source address used by the internal host 991 is simple. The internal host has no choice but to use the 992 destination address in the received packet as the source address of 993 the transmitted packet. 995 For a session originated by a host internal to the multi-homed site, 996 the decision of what source address to select is more complicated. 997 We consider three main methods for hosts to get information about the 998 network. The two proactive methods are Neighbor Discovery Router 999 Advertisements and DHCPv6. The one reactive method we consider is 1000 ICMPv6. Note that we are explicitly excluding the possibility of 1001 having hosts participate in or even listen directly to routing 1002 protocol advertisements. 1004 First we look at how a host is currently expected to select the 1005 source and destination address with which it sends a packet. 1007 5.1. Source Address Selection Algorithm on Hosts 1009 [RFC6724] defines the algorithms that hosts are expected to use to 1010 select source and destination addresses for packets. It defines an 1011 algorithm for selecting a source address and a separate algorithm for 1012 selecting a destination address. Both of these algorithms depend on 1013 a policy table. [RFC6724] defines a default policy which produces 1014 certain behavior. 1016 The rules in the two algorithms in [RFC6724] depend on many different 1017 properties of addresses. While these are needed for understanding 1018 how a host should choose addresses in an arbitrary environment, most 1019 of the rules are not relevant for understanding how a host should 1020 choose among multiple source addresses in multihomed environment when 1021 sending a packet to a remote host. Returning to the example in 1022 Figure 3, we look at what the default algorithms in [RFC6724] say 1023 about the source address that internal host H31 should use to send 1024 traffic to external host H101, somewhere on the Internet. 1026 There is no choice to be made with respect to destination address. 1027 H31 needs to send a packet with D=2001:db8:0:1234::101 in order to 1028 reach H101. So H31 have to choose between using 1029 S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address 1030 for this packet. We go through the rules for source address 1031 selection in Section 5 of [RFC6724]. Rule 1 (Prefer same address) is 1032 not useful to break the tie between source addresses, because neither 1033 the candidate source addresses equals the destination address. Rule 1034 2 (Prefer appropriate scope) is also not used in this scenario, 1035 because both source addresses and the destination address have global 1036 scope. 1038 Rule 3 (Avoid deprecated addresses) applies to an address that has 1039 been autoconfigured by a host using stateless address 1040 autoconfiguration as defined in [RFC4862]. An address autoconfigured 1041 by a host has a preferred lifetime and a valid lifetime. The address 1042 is preferred until the preferred lifetime expires, after which it 1043 becomes deprecated. A deprecated address is not used if there is a 1044 preferred address of the appropriate scope available. When the valid 1045 lifetime expires, the address cannot be used at all. The preferred 1046 and valid lifetimes for an autoconfigured address are set based on 1047 the corresponding lifetimes in the Prefix Information Option in 1048 Neighbor Discovery Router Advertisements. So a possible tool to 1049 control source address selection in this scenario would be for a host 1050 to make an address deprecated by having routers on that link, R1 and 1051 R2 in Figure 3, send a Router Advertisement message containing a 1052 Prefix Information Option for the source prefix to be discouraged (or 1053 prohibited) with the preferred lifetime set to zero. This is a 1054 rather blunt tool, because it discourages or prohibits the use of 1055 that source prefix for all destinations. However, it may be useful 1056 in some scenarios. For example, if all uplinks to a particular ISP 1057 fail, it is desirable to prevent hosts from using source addresses 1058 from that ISP address space. 1060 Rule 4 (Avoid home addresses) does not apply here because we are not 1061 considering Mobile IP. 1063 Rule 5 (Prefer outgoing interface) is not useful in this scenario, 1064 because both source addresses are assigned to the same interface. 1066 Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is 1067 not useful in the scenario when both R1 and R2 will advertise both 1068 source prefixes. However potentially this rule may allow a host to 1069 select the correct source prefix by selecting a next-hop. The most 1070 obvious way would be to make R1 to advertise itself as a default 1071 router and send PIO for 2001:db8:0:a010::/64, while R2 is advertising 1072 itself as a default router and sending PIO for 2001:db8:0:b010::/64. 1073 We'll discuss later how Rule 5.5 can be used to influence a source 1074 address selection in single-router topologies (e.g. when H41 is 1075 sending traffic using R3 as a default gateway). 1077 Rule 6 (Prefer matching label) refers to the Label value determined 1078 for each source and destination prefix as a result of applying the 1079 policy table to the prefix. With the default policy table defined in 1080 Section 2.1 of [RFC6724], Label(2001:db8:0:a010::31) = 5, 1081 Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) = 5. 1082 So with the default policy, Rule 6 does not break the tie. However, 1083 the algorithms in [RFC6724] are defined in such as way that non- 1084 default address selection policy tables can be used. [RFC7078] 1085 defines a way to distribute a non-default address selection policy 1086 table to hosts using DHCPv6. So even though the application of rule 1087 6 to this scenario using the default policy table is not useful, rule 1088 6 may still be a useful tool. 1090 Rule 7 (Prefer temporary addresses) has to do with the technique 1091 described in [RFC4941] to periodically randomize the interface 1092 portion of an IPv6 address that has been generated using stateless 1093 address autoconfiguration. In general, if H31 were using this 1094 technique, it would use it for both source addresses, for example 1095 creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 1096 2001:db8:0:b010:4838:f483:8384:3208, in addition to 1097 2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would 1098 prefer the two temporary addresses, but it would not break the tie 1099 between the two source prefixes from ISP-A and ISP-B. 1101 Rule 8 (Use longest matching prefix) dictates that between two 1102 candidate source addresses the one which has longest common prefix 1103 length with the destination address. For example, if H31 were 1104 selecting the source address for sending packets to H101, this rule 1105 would not be a tie breaker as for both candidate source addresses 1106 2001:db8:0:a101::31 and 2001:db8:0:b101::31 the common prefix length 1107 with the destination is 48. However if H31 were selecting the source 1108 address for sending packets H41 address 2001:db8:0:a020::41, then 1109 this rule would result in using 2001:db8:0:a101::31 as a source 1110 (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix 1111 2001:db8:0:a000::/58, while for `2001:db8:0:b101::31 and 1112 2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51). 1113 Therefore rule 8 might be useful for selecting the correct source 1114 address in some but not all scenarios (for example if ISP-B services 1115 belong to 2001:db8:0:b000::/59 then H31 would always use 1116 2001:db8:0:b010::31 to access those destinations). 1118 So we can see that of the 8 source selection address rules from 1119 [RFC6724], four actually apply to our basic site multihoming 1120 scenario. The rules that are relevant to this scenario are 1121 summarized below. 1123 o Rule 3: Avoid deprecated addresses. 1125 o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. 1127 o Rule 6: Prefer matching label. 1129 o Rule 8: Prefer longest matching prefix. 1131 The two methods that we discuss for controlling the source address 1132 selection through the four relevant rules above are SLAAC Router 1133 Advertisement messages and DHCPv6. 1135 We also consider a possible role for ICMPv6 for getting traffic- 1136 driven feedback from the network. With the source address selection 1137 algorithm discussed above, the goal is to choose the correct source 1138 address on the first try, before any traffic is sent. However, 1139 another strategy is to choose a source address, send the packet, get 1140 feedback from the network about whether or not the source address is 1141 correct, and try another source address if it is not. 1143 We consider four scenarios where a host needs to select the correct 1144 source address. The first is when both uplinks are working. The 1145 second is when one uplink has failed. The third one is a situation 1146 when one failed uplink has recovered. The last one is failure of 1147 both (all) uplinks. 1149 5.2. Selecting Source Address When Both Uplinks Are Working 1151 Again we return to the topology in Figure 3. Suppose that the site 1152 administrator wants to implement a policy by which all hosts need to 1153 use ISP-A to reach H01 at D=2001:db8:0:1234::101. So for example, 1154 H31 needs to select S=2001:db8:0:a010::31. 1156 5.2.1. Distributing Address Selection Policy Table with DHCPv6 1158 This policy can be implemented by using DHCPv6 to distribute an 1159 address selection policy table that assigns the same label to 1160 destination address that match 2001:db8:0:1234::/64 as it does to 1161 source addresses that match 2001:db8:0:a000::/52. The following two 1162 entries accomplish this. 1164 Prefix Precedence Label 1165 2001:db8:0:1234::/64 50 33 1166 2001:db8:0:a000::/52 50 33 1168 Figure 9: Policy table entries to implement a routing policy 1170 This requires that the hosts implement [RFC6724], the basic source 1171 and destination address framework, along with [RFC7078], the DHCPv6 1172 extension for distributing a non-default policy table. Note that it 1173 does NOT require that the hosts use DHCPv6 for address assignment. 1174 The hosts could still use stateless address autoconfiguration for 1175 address configuration, while using DHCPv6 only for policy table 1176 distribution (see [RFC8415]). However this method has a number of 1177 disadvantages: 1179 o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so 1180 this method might not work for all devices. 1182 o Network administrators are required to explicitly configure the 1183 desired network access policies on DHCPv6 servers. While it might 1184 be feasible in the scenario of a single multihomed network, such 1185 approach might have some scalability issues, especially if the 1186 centralized DHCPv6 solution is deployed to serve a large number of 1187 multiomed sites. 1189 5.2.2. Controlling Source Address Selection With Router Advertisements 1191 Neighbor Discovery currently has two mechanisms to communicate prefix 1192 information to hosts. The base specification for Neighbor Discovery 1193 (see [RFC4861]) defines the Prefix Information Option (PIO) in the 1194 Router Advertisement (RA) message. When a host receives a PIO with 1195 the A-flag set, it can use the prefix in the PIO as source prefix 1196 from which it assigns itself an IP address using stateless address 1197 autoconfiguration (SLAAC) procedures described in [RFC4862]. In the 1198 example of Figure 3, if the site network is using SLAAC, we would 1199 expect both R1 and R2 to send RA messages with PIOs for both source 1200 prefixes 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64 with the 1201 A-flag set. H31 would then use the SLAAC procedure to configure 1202 itself with the 2001:db8:0:a010::31 and 2001:db8:0:b010::31. 1204 Whereas a host learns about source prefixes from PIO messages, hosts 1205 can learn about a destination prefix from a Router Advertisement 1206 containing Route Information Option (RIO), as specified in [RFC4191]. 1207 The destination prefixes in RIOs are intended to allow a host to 1208 choose the router that it uses as its first hop to reach a particular 1209 destination prefix. 1211 As currently standardized, neither PIO nor RIO options contained in 1212 Neighbor Discovery Router Advertisements can communicate the 1213 information needed to implement the desired routing policy. PIO's 1214 communicate source prefixes, and RIO communicate destination 1215 prefixes. However, there is currently no standardized way to 1216 directly associate a particular destination prefix with a particular 1217 source prefix. 1219 [I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route 1220 Information option for Neighbor Discovery Router Advertisements which 1221 would associate a source prefix and with a destination prefix. The 1222 details of [I-D.pfister-6man-sadr-ra] might need tweaking to address 1223 this use case. However, in order to be able to use Neighbor 1224 Discovery Router Advertisements to implement this routing policy, an 1225 extension that allows R1 and R2 to explicitly communicate to H31 an 1226 association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 1227 would be needed. 1229 However, Rule 5.5 of the source address selection algorithm 1230 (discussed in Section 5.1 above), together with default router 1231 preference (specified in [RFC4191]) and RIO can be used to influence 1232 a source address selection on a host as described below. Let's look 1233 at source address selection on the host H41. It receives RAs from R3 1234 with PIOs for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that 1235 point all traffic would use the same next-hop (R3 link-local address) 1236 so Rule 5.5 does not apply. Now let's assume that R3 supports SADR 1237 and has two scoped forwarding tables, one scoped to 1238 S=2001:db8:0:a000::/52 and another scoped to S=2001:db8:0:b000::/52. 1239 If R3 generates two different link-local addresses for its interface 1240 facing H41 (one for each scoped forwarding table, LLA_A and LLA_B) 1241 and starts sending two different RAs: one is sent from LLA_A and 1242 includes PIO for 2001:db8:0:a020::/64, another is sent from LLA_B and 1243 includes PIO for 2001:db8:0:b020::/64. Now it is possible to 1244 influence H41 source address selection for destinations which follow 1245 the default route by setting default router preference in RAs. If it 1246 is desired that H41 reaches H101 (or any destinations in the 1247 Internet) via ISP-A, then RAs sent from LLA_A should have default 1248 router preference set to 01 (high priority), while RAs sent from 1249 LLA_B should have preference set to 11 (low). Then LLA_A would be 1250 chosen as a next-hop for H101 and therefore (as per rule 5.5) 1251 2001:db8:0:a020::41 would be selected as the source address. If, at 1252 the same time, it is desired that H61 is accessible via ISP-B then R3 1253 should include a RIO for 2001:db8:0:6666::/64 to its RA sent from 1254 LLA_B. H41 would chose LLA_B as a next-hop for all traffic to H61 1255 and then as per Rule 5.5, 2001:db8:0:b020::41 would be selected as a 1256 source address. 1258 If in the above mentioned scenario it is desirable that all Internet 1259 traffic leaves the network via ISP-A and the link to ISP-B is used 1260 for accessing ISP-B services only (not as ISP-A link backup), then 1261 RAs sent by R3 from LLA_B should have Router Lifetime set to 0 and 1262 should include RIOs for ISP-B address space. It would instruct H41 1263 to use LLA_A for all Internet traffic but use LLA_B as a next-hop 1264 while sending traffic to ISP-B addresses. 1266 The description of the mechanism above assumes SADR support by the 1267 first-hop routers as well as SERs. However, a first-hop router can 1268 still provide a less flexible version of this mechanism even without 1269 implementing SADR. This could be done by providing configuration 1270 knobs on the first-hop router that allow it to generate different 1271 link-local addresses and to send individual RAs for each prefix. 1273 The mechanism described above relies on Rule 5.5 of the default 1274 source address selection algorithm defined in [RFC6724]. [RFC8028] 1275 recommends that a host SHOULD select default routers for each prefix 1276 in which it is assigned an address. It also recommends that hosts 1277 SHOULD implement Rule 5.5. of [RFC6724]. Hosts following the 1278 recommendations specified in [RFC8028] therefore should be able to 1279 benefit from the solution described in this document. No standards 1280 need to be updated in regards to host behavior. 1282 5.2.3. Controlling Source Address Selection With ICMPv6 1284 We now discuss how one might use ICMPv6 to implement the routing 1285 policy to send traffic destined for H101 out the uplink to ISP-A, 1286 even when uplinks to both ISPs are working. If H31 started sending 1287 traffic to H101 with S=2001:db8:0:b010::31 and 1288 D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the 1289 uplink to ISP-B. SERb1 could recognize that this is traffic is not 1290 following the desired routing policy and react by sending an ICMPv6 1291 message back to H31. 1293 In this example, we could arrange things so that SERb1 drops the 1294 packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and 1295 then sends to H31 an ICMPv6 Destination Unreachable message with Code 1296 5 (Source address failed ingress/egress policy). When H31 receives 1297 this packet, it would then be expected to try another source address 1298 to reach the destination. In this example, H31 would then send a 1299 packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which 1300 will reach SERa and be forwarded out the uplink to ISP-A. 1302 However, we would also want it to be the case that SERb1 does not 1303 enforce this routing policy when the uplink from SERa to ISP-A has 1304 failed. This could be accomplished by having SERa originate a 1305 source-prefix-scoped route for (S=2001:db8:0:a000::/52, 1306 D=2001:db8:0:1234::/64) and have SERb1 monitor the presence of that 1307 route. If that route is not present (because SERa has stopped 1308 originating it), then SERb1 will not enforce the routing policy, and 1309 it will forward packets with S=2001:db8:0:b010::31 and 1310 D=2001:db8:0:1234::101 out its uplink to ISP-B. 1312 We can also use this source-prefix-scoped route originated by SERa to 1313 communicate the desired routing policy to SERb1. We can define an 1314 EXCLUSIVE flag to be advertised together with the IGP route for 1315 (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow 1316 SERa to communicate to SERb that SERb should reject traffic for 1317 D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination 1318 Unreachable Code 5 message, as long as the route for 1319 (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. 1321 Finally, if we are willing to extend ICMPv6 to support this solution, 1322 then we could create a mechanism for SERb1 to tell the host what 1323 source address it should be using to successfully forward packets 1324 that meet the policy. In its current form, when SERb1 sends an 1325 ICMPv6 Destination Unreachable Code 5 message, it is basically 1326 saying, "This source address is wrong. Try another source address." 1327 In the absence of a clear indication which address to try next, the 1328 host will iterate over all addresses assigned to the interface (e.g. 1329 various privacy addresses) which would lead to significant delays and 1330 degraded user experience. It would be better is if the ICMPv6 1331 message could say, "This source address is wrong. Instead use a 1332 source address in S=2001:db8:0:a000::/52.". 1334 However using ICMPv6 for signalling source address information back 1335 to hosts introduces new challenges. Most routers currently have 1336 software or hardware limits on generating ICMP messages. An site 1337 administrator deploying a solution that relies on the SERs generating 1338 ICMP messages could try to improve the performance of SERs for 1339 generating ICMP messages. However, in a large network, it is still 1340 likely that ICMP message generation limits will be reached. As a 1341 result hosts would not receive ICMPv6 back which in turn leads to 1342 traffic blackholing and poor user experience. To improve the 1343 scalability of ICMPv6-based signalling hosts SHOULD cache the 1344 preferred source address (or prefix) for the given destination (which 1345 in turn might cause issues in case of the corresponding ISP uplinks 1346 failure - see Section 5.3). In addition, the same source prefix 1347 SHOULD be used for other destinations in the same /64 as the original 1348 destination address. The source prefix SHOULD have a specific 1349 lifetime. Expiration of the lifetime SHOULD trigger the source 1350 address selection algorithm again. 1352 Using ICMPv6 Destination Unreachable Messages with Code 5 to 1353 influence source address selection allows an attacker to exhaust the 1354 list of candidate source addresses on the host by sending spoofed 1355 ICMPv6 Code 5 for all prefixes known on the network (therefore 1356 preventing a victim from establishing a communication with the 1357 destination host). To protect from an attack of this kind, hosts 1358 SHOULD verify that the original packet header included into ICMPv6 1359 error message was actually sent by the host. 1361 As currently standardized in [RFC4443], the ICMPv6 Destination 1362 Unreachable Message with Code 5 would allow for the iterative 1363 approach to retransmitting packets using different source addresses. 1364 As currently defined, the ICMPv6 message does not provide a mechanism 1365 to communication information about which source prefix should be used 1366 for a retransmitted packet. The current document does not define 1367 such a mechanism. However, we note that this might be a useful 1368 extension to define in a different document. 1370 5.2.4. Summary of Methods For Controlling Source Address Selection To 1371 Implement Routing Policy 1373 So to summarize this section, we have looked at three methods for 1374 implementing a simple routing policy where all traffic for a given 1375 destination on the Internet needs to use a particular ISP, even when 1376 the uplinks to both ISPs are working. 1378 The default source address selection policy cannot distinguish 1379 between the source addresses needed to enforce this policy, so a non- 1380 default policy table using associating source and destination 1381 prefixes using Label values would need to be installed on each host. 1382 A mechanism exists for DHCPv6 to distribute a non-default policy 1383 table but such solution would heavily rely on DHCPv6 support by host 1384 operating system. Moreover there is no mechanism to translate 1385 desired routing/traffic engineering policies into policy tables on 1386 DHCPv6 servers. Therefore using DHCPv6 for controlling address 1387 selection policy table is not recommended and SHOULD NOT be used. 1389 At the same time Router Advertisements provide a reliable mechanism 1390 to influence source address selection process via PIO, RIO and 1391 default router preferences. As all those options have been 1392 standardized by IETF and are supported by various operating systems, 1393 no changes are required on hosts. First-hop routers in the 1394 enterprise network need to be able of sending different RAs for 1395 different SLAAC prefixes (either based on scoped forwarding tables or 1396 based on pre-configured policies). 1398 SERs can enforce the routing policy by sending ICMPv6 Destination 1399 Unreachable messages with Code 5 (Source address failed ingress/ 1400 egress policy) for traffic that is being sent with the wrong source 1401 address. The policy distribution can be automated by defining an 1402 EXCLUSIVE flag for the source-prefix-scoped route which can be set on 1403 the SER that originates the route. As ICMPv6 message generation can 1404 be rate-limited on routers, it SHOULD NOT be used as the only 1405 mechanism to influence source address selection on hosts. While 1406 hosts SHOULD select the correct source address for a given 1407 destination the network SHOULD signal any source address issues back 1408 to hosts using ICMPv6 error messages. 1410 5.3. Selecting Source Address When One Uplink Has Failed 1412 Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements, 1413 and ICMPv6 can help a host choose the right source address when an 1414 uplink to one of the ISPs has failed. Again we look at the scenario 1415 in Figure 3. This time we look at traffic from H31 destined for 1416 external host H501 at D=2001:db8:0:5678::501. We initially assume 1417 that the uplink from SERa to ISP-A is working and that the uplink 1418 from SERb1 to ISP-B is working. 1420 We assume there is no particular routing policy desired, so H31 is 1421 free to send packets with S=2001:db8:0:a010::31 or 1422 S=2001:db8:0:b010::31 and have them delivered to H501. For this 1423 example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that 1424 the packets exit via SERb to ISP-B. Now we see what happens when the 1425 link from SERb1 to ISP-B fails. How should H31 learn that it needs 1426 to start sending the packet to H501 with S=2001:db8:0:a010::31 in 1427 order to start using the uplink to ISP-A? We need to do this in a 1428 way that doesn't prevent H31 from still sending packets with 1429 S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61. 1431 5.3.1. Controlling Source Address Selection With DHCPv6 1433 For this example we assume that the site network in Figure 3 has a 1434 centralized DHCP server and all routers act as DHCP relay agents. We 1435 assume that both of the addresses assigned to H31 were assigned via 1436 DHCP. 1438 We could try to have the DHCP server monitor the state of the uplink 1439 from SERb1 to ISP-B in some manner and then tell H31 that it can no 1440 longer use S=2001:db8:0:b010::31 by settings its valid lifetime to 1441 zero. The DHCP server could initiate this process by sending a 1442 Reconfigure Message to H31 as described in Section 18.3 of [RFC8415]. 1443 Or the DHCP server can assign addresses with short lifetimes in order 1444 to force clients to renew them often. 1446 This approach would prevent H31 from using S=2001:db8:0:b010::31 to 1447 reach the a host on the Internet. However, it would also prevent H31 1448 from using S=2001:db8:0:b010::31 to reach H61 at 1449 D=2001:db8:0:6666::61, which is not desirable. 1451 Another potential approach is to have the DHCP server monitor the 1452 uplink from SERb1 to ISP-B and control the choice of source address 1453 on H31 by updating its address selection policy table via the 1454 mechanism in [RFC7078]. The DHCP server could initiate this process 1455 by sending a Reconfigure Message to H31. Note that [RFC8415] 1456 requires that Reconfigure Message use DHCP authentication. DHCP 1457 authentication could be avoided by using short address lifetimes to 1458 force clients to send Renew messages to the server often. If the 1459 host is not obtaining its IP addresses from the DHCP server, then it 1460 would need to use the Information Refresh Time option defined in 1461 [RFC8415]. 1463 If the following policy table can be installed on H31 after the 1464 failure of the uplink from SERb1, then the desired routing behavior 1465 should be achieved based on source and destination prefix being 1466 matched with label values. 1468 Prefix Precedence Label 1469 ::/0 50 44 1470 2001:db8:0:a000::/52 50 44 1471 2001:db8:0:6666::/64 50 55 1472 2001:db8:0:b000::/52 50 55 1474 Figure 10: Policy Table Needed On Failure Of Uplink From SERb1 1476 The described solution has a number of significant drawbacks, some of 1477 them already discussed in Section 5.2.1. 1479 o DHCPv6 support is not required for an IPv6 host and there are 1480 operating systems which do not support DHCPv6. Besides that, it 1481 does not appear that [RFC7078] has been widely implemented on host 1482 operating systems. 1484 o [RFC7078] does not clearly specify this kind of a dynamic use case 1485 where address selection policy needs to be updated quickly in 1486 response to the failure of a link. In a large network it would 1487 present scalability issues as many hosts need to be reconfigured 1488 in very short period of time. 1490 o Updating DHCPv6 server configuration each time an ISP uplink 1491 changes its state introduces some scalability issues, especially 1492 for mid/large distributed scale enterprise networks. In addition 1493 to that, the policy table needs to be manually configured by 1494 administrators which makes that solution prone to human error. 1496 o No mechanism exists for making DHCPv6 servers aware of network 1497 topology/routing changes in the network. In general DHCPv6 1498 servers monitoring network-related events sounds like a bad idea 1499 as completely new functionality beyond the scope of DHCPv6 role is 1500 required. 1502 5.3.2. Controlling Source Address Selection With Router Advertisements 1504 The same mechanism as discussed in Section 5.2.2 can be used to 1505 control the source address selection in the case of an uplink 1506 failure. If a particular prefix should not be used as a source for 1507 any destinations, then the router needs to send RA with Preferred 1508 Lifetime field for that prefix set to 0. 1510 Let's consider a scenario when all uplinks are operational and H41 1511 receives two different RAs from R3: one from LLA_A with PIO for 1512 2001:db8:0:a020::/64, default router preference set to 11 (low) and 1513 another one from LLA_B with PIO for 2001:db8:0:a020::/64, default 1514 router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. 1515 As a result H41 is using 2001:db8:0:b020::41 as a source address for 1516 all Internet traffic and those packets are sent by SERs to ISP-B. If 1517 SERb1 uplink to ISP-B failed, the desired behavior is that H41 stops 1518 using 2001:db8:0:b020::41 as a source address for all destinations 1519 but H61. To achieve that R3 should react to SERb1 uplink failure 1520 (which could be detected as the scoped route (S=2001:db8:0:b000::/52, 1521 D=::/0) disappearance) by withdrawing itself as a default router. R3 1522 sends a new RA from LLA_B with Router Lifetime value set to 0 (which 1523 means that it should not be used as default router). That RA still 1524 contains PIO for 2001:db8:0:b020::/64 (for SLAAC purposes) and RIO 1525 for 2001:db8:0:6666::/64 so H41 can reach H61 using LLA_B as a next- 1526 hop and 2001:db8:0:b020::41 as a source address. For all traffic 1527 following the default route, LLA_A will be used as a next-hop and 1528 2001:db8:0:a020::41 as a source address. 1530 If all uplinks to ISP-B have failed and therefore source addresses 1531 from ISP-B address space should not be used at all, the forwarding 1532 table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can 1533 be instructed to stop using source addresses from that block by 1534 sending RAs containing PIO with Preferred Lifetime set to 0. 1536 5.3.3. Controlling Source Address Selection With ICMPv6 1538 Now we look at how ICMPv6 messages can provide information back to 1539 H31. We assume again that at the time of the failure H31 is sending 1540 packets to H501 using (S=2001:db8:0:b010::31, 1541 D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, 1542 SERb1 would stop originating its source-prefix-scoped route for the 1543 default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its 1544 unscoped default destination route. With these routes no longer in 1545 the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) 1546 would end up at SERa based on the unscoped default destination route 1547 being originated by SERa. Since that traffic has the wrong source 1548 address to be forwarded to ISP-A, SERa would drop it and send a 1549 Destination Unreachable message with Code 5 (Source address failed 1550 ingress/egress policy) back to H31. H31 would then know to use 1551 another source address for that destination and would try with 1552 (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be 1553 forwarded to SERa based on the source-prefix-scoped default 1554 destination route still being originated by SERa, and SERa would 1555 forward it to ISP-A. As discussed above, if we are willing to extend 1556 ICMPv6, SERa can even tell H31 what source address it should use to 1557 reach that destination. The expected host behaviour has been 1558 discussed in Section 5.2.3. Potential issue with using ICMPv6 for 1559 signalling source address issues back to hosts is that uplink to an 1560 ISP-B failure immediately invalidates source addresses from 1561 2001:db8:0:b000::/52 for all hosts which triggers a large number of 1562 ICMPv6 being sent back to hosts - the same scalability/rate limiting 1563 issues discussed in Section 5.2.3 would apply. 1565 5.3.4. Summary Of Methods For Controlling Source Address Selection On 1566 The Failure Of An Uplink 1568 It appears that DHCPv6 is not particularly well suited to quickly 1569 changing the source address used by a host in the event of the 1570 failure of an uplink, which eliminates DHCPv6 from the list of 1571 potential solutions. On the other hand Router Advertisements 1572 provides a reliable mechanism to dynamically provide hosts with a 1573 list of valid prefixes to use as source addresses as well as prevent 1574 particular prefixes to be used. While no additional new features are 1575 required to be implemented on hosts, routers need to be able to send 1576 RAs based on the state of scoped forwarding tables entries and to 1577 react to network topology changes by sending RAs with particular 1578 parameters set. 1580 The use of ICMPv6 Destination Unreachable messages generated by the 1581 SER (or any SADR-capable) routers seem like they have the potential 1582 to provide a support mechanism together with RAs to signal source 1583 address selection errors back to hosts, however scalability issues 1584 may arise in large networks in case of sudden topology change. 1585 Therefore it is highly desirable that hosts are able to select the 1586 correct source address in case of uplinks failure with ICMPv6 being 1587 an additional mechanism to signal unexpected failures back to hosts. 1589 The current behavior of different host operating system when 1590 receiving ICMPv6 Destination Unreachable message with code 5 (Source 1591 address failed ingress/egress policy) is not clear to the authors. 1592 Information from implementers, users, and testing would be quite 1593 helpful in evaluating this approach. 1595 5.4. Selecting Source Address Upon Failed Uplink Recovery 1597 The next logical step is to look at the scenario when a failed uplink 1598 on SERb1 to ISP-B is coming back up, so hosts can start using source 1599 addresses belonging to 2001:db8:0:b000::/52 again. 1601 5.4.1. Controlling Source Address Selection With DHCPv6 1603 The mechanism to use DHCPv6 to instruct the hosts (H31 in our 1604 example) to start using prefixes from ISP-B space (e.g. 1605 S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is 1606 quite similar to one discussed in Section 5.3.1 and shares the same 1607 drawbacks. 1609 5.4.2. Controlling Source Address Selection With Router Advertisements 1611 Let's look at the scenario discussed in Section 5.3.2. If the 1612 uplink(s) failure caused the complete withdrawal of prefixes from 1613 2001:db8:0:b000::/52 address space by setting Preferred Lifetime 1614 value to 0, then the recovery of the link should just trigger new RA 1615 being sent with non-zero Preferred Lifetime. In another scenario 1616 discussed in Section 5.3.2, the SERb1 uplink to ISP-B failure leads 1617 to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from 1618 the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn, 1619 caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The 1620 recovery of the SERb1 uplink to ISP-B leads to 1621 (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- 1622 appearance and instructs R3 that it should advertise itself as a 1623 default router for ISP-B address space domain (send RAs from LLA_B 1624 with non-zero Router Lifetime). 1626 5.4.3. Controlling Source Address Selection With ICMP 1628 It looks like ICMPv6 provides a rather limited functionality to 1629 signal back to hosts that particular source addresses have become 1630 valid again. Unless the changes in the uplink state a particular 1631 (S,D) pair, hosts can keep using the same source address even after 1632 an ISP uplink has come back up. For example, after the uplink from 1633 SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as 1634 described in Section 5.3.3) and allegedly started using 1635 (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now 1636 when the SERb1 uplink comes back up, the packets with that (S,D) pair 1637 are still routed to SERa1 and sent to the Internet. Therefore H31 is 1638 not informed that it should stop using 2001:db8:0:a010::31 and start 1639 using 2001:db8:0:b010::31 again. Unless SERa has a policy configured 1640 to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and 1641 send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware 1642 of the network topology change and keep using S=2001:db8:0:a010::31 1643 for Internet destinations, including H51. 1645 One of the possible option may be using a scoped route with EXCLUSIVE 1646 flag as described in Section 5.2.3. SERa1 uplink recovery would 1647 cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to 1648 reappear in the routing table. In the absence of that route packets 1649 to H101 which were sent to ISP-B (as ISP-A uplink was down) with 1650 source addresses from 2001:db8:0:b000::/52. When the route re- 1651 appears SERb1 would reject those packets and sends ICMPv6 back as 1652 discussed in Section 5.2.3. Practically it might lead to scalability 1653 issues which have been already discussed in Section 5.2.3 and 1654 Section 5.4.3. 1656 5.4.4. Summary Of Methods For Controlling Source Address Selection Upon 1657 Failed Uplink Recovery 1659 Once again DHCPv6 does not look like reasonable choice to manipulate 1660 source address selection process on a host in the case of network 1661 topology changes. Using Router Advertisement provides the flexible 1662 mechanism to dynamically react to network topology changes (if 1663 routers are able to use routing changes as a trigger for sending out 1664 RAs with specific parameters). ICMPv6 could be considered as a 1665 supporting mechanism to signal incorrect source address back to hosts 1666 but should not be considered as the only mechanism to control the 1667 address selection in multihomed environments. 1669 5.5. Selecting Source Address When All Uplinks Failed 1671 One particular tricky case is a scenario when all uplinks have 1672 failed. In that case there is no valid source address to be used for 1673 any external destinations while it might be desirable to have intra- 1674 site connectivity. 1676 5.5.1. Controlling Source Address Selection With DHCPv6 1678 From DHCPv6 perspective uplinks failure should be treated as two 1679 independent failures and processed as described in Section 5.3.1. At 1680 this stage it is quite obvious that it would result in quite 1681 complicated policy table which needs to be explicitly configured by 1682 administrators and therefore seems to be impractical. 1684 5.5.2. Controlling Source Address Selection With Router Advertisements 1686 As discussed in Section 5.3.2 an uplink failure causes the scoped 1687 default entry to disappear from the scoped forwarding table and 1688 triggers RAs with zero Router Lifetime. Complete disappearance of 1689 all scoped entries for a given source prefix would cause the prefix 1690 being withdrawn from hosts by setting Preferred Lifetime value to 1691 zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts 1692 either lost their default routers and/or have no global IPv6 1693 addresses to use as a source. (Note that 'uplink failure' might mean 1694 'IPv6 connectivity failure with IPv4 still being reachable', in which 1695 case hosts might fall back to IPv4 if there is IPv4 connectivity to 1696 destinations). As a result, intra-site connectivity is broken. One 1697 of the possible way to solve it is to use ULAs. 1699 All hosts have ULA addresses assigned in addition to GUAs and used 1700 for intra-site communication even if there is no GUA assigned to a 1701 host. To avoid accidental leaking of packets with ULA sources SADR- 1702 capable routers SHOULD have a scoped forwarding table for ULA source 1703 for internal routes but MUST NOT have an entry for D=::/0 in that 1704 table. In the absence of (S=ULA_Prefix; D=::/0) first-hop routers 1705 will send dedicated RAs from a unique link-local source LLA_ULA with 1706 PIO from ULA address space, RIO for the ULA prefix and Router 1707 Lifetime set to zero. The behaviour is consistent with the situation 1708 when SERb1 lost the uplink to ISP-B (so there is no Internet 1709 connectivity from 2001:db8:0:b000::/52 sources) but those sources can 1710 be used to reach some specific destinations. In the case of ULA 1711 there is no Internet connectivity from ULA sources but they can be 1712 used to reach another ULA destinations. Note that ULA usage could be 1713 particularly useful if all ISPs assign prefixes via DHCP-PD. In the 1714 absence of ULAs uplinks failure hosts would lost all their GUAs upon 1715 prefix lifetime expiration which again makes intra-site communication 1716 impossible. 1718 It should be noted that the Rule 5.5 (prefer a prefix advertised by 1719 the selected next-hop) takes precedence over the Rule 6 (prefer 1720 matching label, which ensures that GUA source addresses are preferred 1721 over ULAs for GUA destinations). Therefore if ULAs are used, the 1722 network administrator needs to ensure that while the site has an 1723 Internet connectivity, hosts do not select a router which advertises 1724 ULA prefixes as their default router. 1726 5.5.3. Controlling Source Address Selection With ICMPv6 1728 In case of all uplinks failure all SERs will drop outgoing IPv6 1729 traffic and respond with ICMPv6 error message. In the large network 1730 when many hosts are trying to reach Internet destinations it means 1731 that SERs need to generate an ICMPv6 error to every packet they 1732 receive from hosts which presents the same scalability issues 1733 discussed in Section 5.3.3 1735 5.5.4. Summary Of Methods For Controlling Source Address Selection When 1736 All Uplinks Failed 1738 Again, combining SADR with Router Advertisements seems to be the most 1739 flexible and scalable way to control the source address selection on 1740 hosts. 1742 5.6. Summary Of Methods For Controlling Source Address Selection 1744 To summarize the scenarios and options discussed above: 1746 While DHCPv6 allows administrators to manipulate source address 1747 selection policy tables, this method has a number of significant 1748 disadvantages which eliminates DHCPv6 from a list of potential 1749 solutions: 1751 1. It required hosts to support DHCPv6 and its extension (RFC7078); 1753 2. DHCPv6 server needs to monitor network state and detect routing 1754 changes. 1756 3. The use of policy tables requires manual configuration and might 1757 be extremely complicated, especially in the case of distributed 1758 network when large number of remote sites are being served by 1759 centralized DHCPv6 servers. 1761 4. Network topology/routing policy changes could trigger 1762 simultaneous re-configuration of large number of hosts which 1763 present serious scalability issues. 1765 The use of Router Advertisements to influence the source address 1766 selection on hosts seem to be the most reliable, flexible and 1767 scalable solution. It has the following benefits: 1769 1. no new (non-standard) functionality needs to be implemented on 1770 hosts (except for [RFC4191] support); 1772 2. no changes in RA format; 1774 3. routers can react to routing table changes by sending RAs which 1775 would minimize the failover time in the case of network topology 1776 changes; 1778 4. information required for source address selection is broadcast to 1779 all affected hosts in case of topology change event which 1780 improves the scalability of the solution (comparing to DHCPv6 1781 reconfiguration or ICMPv6 error messages). 1783 To fully benefit from the RA-based solution, first-hop routers need 1784 to implement SADR and be able to send dedicated RAs per scoped 1785 forwarding table as discussed above, reacting to network changes with 1786 sending new RAs. It should be noted that the proposed solution would 1787 work even if first-hop routers are not SADR-capable but still able to 1788 send individual RAs for each ISP prefix and react to topology changes 1789 as discussed above (e.g. via configuration knobs). 1791 The RA-based solution relies heavily on hosts correctly implementing 1792 default address selection algorithm as defined in [RFC6724]. While 1793 the basic (and most common) multihoming scenario (two or more 1794 Internet uplinks, no 'wall gardens') would work for any host 1795 supporting the minimal implementation of [RFC6724], more complex use 1796 cases (such as "wall garden" and other scenarios when some ISP 1797 resources can only be reached from that ISP address space) require 1798 that hosts support Rule 5.5 of the default address selection 1799 algorithm. There is some evidence that not all host OSes have that 1800 rule implemented currently. However it should be noted that 1801 [RFC8028] states that Rule 5.5 SHOULD be implemented. 1803 ICMPv6 Code 5 error message SHOULD be used to complement RA-based 1804 solution to signal incorrect source address selection back to hosts, 1805 but it SHOULD NOT be considered as the stand-alone solution. To 1806 prevent scenarios when hosts in multihomed envinronments incorrectly 1807 identify onlink/offlink destinations, hosts should treat ICMPv6 1808 Redirects as discussed in [RFC8028]. 1810 5.7. Other Configuration Parameters 1812 5.7.1. DNS Configuration 1814 In mutihomed envinronment each ISP might provide their own list of 1815 DNS servers. For example, in the topology shown in Figure 3, ISP-A 1816 might provide recursive DNS server H51 2001:db8:0:5555::51, while 1817 ISP-B might provide H61 2001:db8:0:6666::61 as a recursive DNS 1818 server. [RFC8106] defines IPv6 Router Advertisement options to allow 1819 IPv6 routers to advertise a list of DNS recursive server addresses 1820 and a DNS Search List to IPv6 hosts. Using RDNSS together with 1821 'scoped' RAs as described above would allow a first-hop router (R3 in 1822 the Figure 3) to send DNS server addresses and search lists provided 1823 by each ISP (or the corporate DNS servers addresses if the enterprise 1824 is running its own DNS servers). 1826 As discussed in Section 5.5.2, failure of all ISP uplinks would cause 1827 deprecation of all addresses assigned to a host from the address 1828 space of all ISPs. If any intra-site IPv6 connectivity is still 1829 desirable (most likely to be the case for any mid/large scare 1830 network), then ULAs should be used as discussed in Section 5.5.2. In 1831 such a scenario, the enterprise network should run its own recursive 1832 DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs 1833 send for ULA-scoped forwarding table as described in Section 5.5.2. 1835 There are some scenarios when the final outcome of the name 1836 resolution might be different depending on: 1838 o which DNS server is used; 1840 o which source address the client uses to send a DNS query to the 1841 server (DNS split horizon). 1843 There is no way currently to instruct a host to use a particular DNS 1844 server out of the configured servers list for resolving a particular 1845 name. Therefore it does not seem feasible to solve the problem of 1846 DNS server selection on the host (it should be noted that this 1847 particular issue is protocol-agnostic and happens for IPv4 as well). 1848 In such a scenario it is recommended that the enterprise runs its own 1849 local recursive DNS server. 1851 To influence host source address selection for packets sent to a 1852 particular DNS server the following requirements must be met: 1854 o the host supports RIO as defined in [RFC4191]; 1856 o the routers send RIO for routes to DNS server addresses. 1858 For example, if it is desirable that host H31 reaches the ISP-A DNS 1859 server H51 2001:db8:0:5555::51 using its source address 1860 2001:db8:0:a010::31, then both R1 and R2 should send the RIO 1861 containing the route to 2001:db8:0:5555::51 (or covering route) in 1862 their 'scoped' RAs, containing LLA_A as the default router address 1863 and the PO for SLAAC prefix 2001:db8:0:a010::/64. In that case the 1864 host H31 (if it supports the Rule 5.5) would select LLA_A as a next- 1865 hop and then chose 2001:db8:0:a010::31 as the source address for 1866 packets to the DNS server. 1868 It should be noted that [RFC8106] explicitly prohibits using DNS 1869 information if the RA router Lifetime expired: "An RDNSS address or a 1870 DNSSL domain name MUST be used only as long as both the RA router 1871 Lifetime (advertised by a Router Advertisement message) and the 1872 corresponding option Lifetime have not expired.". Therefore hosts 1873 might ignore RDNSS information provided in ULA-scoped RAs as those 1874 RAs would have router lifetime set to 0. However the updated version 1875 of RFC6106 ([RFC8106]) has that requirement removed. 1877 6. Deployment Considerations 1879 The solution described in this document requires certain mechanisms 1880 to be supported by the network infrastructure and hosts. It requires 1881 some routers in the enterprise site to support some form of Source 1882 Address Dependent Routing (SADR). It also requires hosts to be able 1883 to learn when the uplink to an ISP changes its state so the 1884 corresponding source addresses should (or should not) be used. 1885 Ongoing work to create mechanisms to accomplish this are discussed in 1886 this document, but they are still a work in progress. 1888 The solution discussed in this document relies on the default address 1889 selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] considers 1890 this rule as optional, the recent [RFC8028] recommends that a host 1891 SHOULD select default routers for each prefix in which it is assigned 1892 an address. It also recommends that hosts SHOULD implement Rule 5.5. 1893 of [RFC6724]. Therefore while RFC8028-compliant hosts already have 1894 mechanism to learn about ISP uplinks state changes and selecting the 1895 source addresses accordingly, many hosts do not have such mechanism 1896 supported yet. 1898 It should be noted that multihomed enterprise network utilizing 1899 multiple ISP prefixes can be considered as a typical mutiple 1900 provisioning domain (mPVD) scenario, as described in [RFC7556]. This 1901 document defines a way for network to provide the PVD information to 1902 hosts indirectly, using the existing mechanisms. At the same time 1903 [I-D.ietf-intarea-provisioning-domains]takes one step further and 1904 describes a comprehensive mechanism for hosts to discover the whole 1905 set of configuration information associated with different PVD/ISPs. 1906 [I-D.ietf-intarea-provisioning-domains] complements this document in 1907 terms of making hosts being able to learn about ISP uplink states and 1908 selecting the corresponding source addresses. 1910 7. Other Solutions 1912 7.1. Shim6 1914 The Shim6 working group specified the Shim6 protocol [RFC5533] which 1915 allows a host at a multihomed site to communicate with an external 1916 host and exchange information about possible source and destination 1917 address pairs that they can use to communicate. It also specified 1918 the REAP protocol [RFC5534] to detect failures in the path between 1919 working address pairs and find new working address pairs. A 1920 fundamental requirement for Shim6 is that both internal and external 1921 hosts need to support Shim6. That is, both the host internal to the 1922 multihomed site and the host external to the multihomed site need to 1923 support Shim6 in order for there to be any benefit for the internal 1924 host to run Shim6. The Shim6 protocol specification was published in 1925 2009, but it has not been widely implemented. Therefore Shim6 is not 1926 considered as a viable solution for enterprise multihoming. 1928 7.2. IPv6-to-IPv6 Network Prefix Translation 1930 IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the 1931 focus of this document. NPTv6 suffers from the same fundamental 1932 issue as any other address translation approaches: it breaks end-to- 1933 end connectivity. Therefore NPTv6 is not considered as desirable 1934 solution and this document intentionally focuses on solving 1935 enterprise multihoming problem without any form of address 1936 translations. 1938 With increasing interest and ongoing work in bringing path awareness 1939 to transport and application layer protocols hosts might be able to 1940 determine the properties of the various network paths and choose 1941 among paths available to them. As selecting the correct source 1942 address is one of the possible mechanisms path-aware hosts may 1943 utilize, address translation negatively affects hosts path-awareness 1944 which makes NTPv6 even more undesirable solution. 1946 7.3. Multipath Transport 1948 Using multipath transport might solve the problems discussed in 1949 Section 5 since it would allow hosts to use multiple source addresses 1950 for a single connection and switch between source addresses when a 1951 particular address becomes unavailable or a new address gets assigned 1952 to the host interface. Therefore if all hosts in the enterprise 1953 network are only using multipath transport for all connections, the 1954 signalling solution described in Section 5 might not be needed (it 1955 should be noted that the Source Address Dependent Routing would still 1956 be required to deliver packets to the correct uplinks). At the time 1957 this document was written, multipath transport alone could not be 1958 considered a solution for the problem of selecting the source address 1959 in a multihomed environment. There are significant number of hosts 1960 which do not use multipath transport currently and it seems unlikely 1961 that the situation is going to change in any foreseeable future. The 1962 solution for enterprise multihoming needs to work for the least 1963 common denominator: hosts without multipath transport support. In 1964 addition, not all protocols are using multipath transport. While 1965 multipath transport would complement the solution described in 1966 Section 5, it could not be considered as a sole solution to the 1967 problem of source address selection in multihomed environments. 1969 8. IANA Considerations 1971 This memo asks the IANA for no new parameters. 1973 9. Security Considerations 1975 Section 5.2.3 discusses a mechanism for controlling source address 1976 selection on hosts using ICMPv6 messages. It describes how an 1977 attacker could exploit this mechansim by sending spoofed ICMPv6 1978 messages. It recommends that a given host verify the original packet 1979 header included into ICMPv6 error message was actually sent by the 1980 host itself. 1982 The security considerations of using stateless address 1983 autoconfiguration are discussed in [RFC4862]. 1985 10. Acknowledgements 1987 The original outline was suggested by Ole Troan. 1989 The authors would like to thank the following people (in alphabetical 1990 order) for their review and feedback: Olivier Bonaventure, Brian E 1991 Carpenter, Lorenzo Colitti, David Lamparter, Nicolai Leymann, Acee 1992 Lindem, Philip Matthewsu, Robert Raszuk, Dave Thaler, Martin 1993 Vigoureux. 1995 11. References 1997 11.1. Normative References 1999 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2000 and E. Lear, "Address Allocation for Private Internets", 2001 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2002 . 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2005 Requirement Levels", BCP 14, RFC 2119, 2006 DOI 10.17487/RFC2119, March 1997, 2007 . 2009 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2010 Defeating Denial of Service Attacks which employ IP Source 2011 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2012 May 2000, . 2014 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 2015 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 2016 November 2005, . 2018 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2019 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2020 . 2022 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2023 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 2024 . 2026 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 2027 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 2028 . 2030 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 2031 Hosts in a Multi-Prefix Network", RFC 8028, 2032 DOI 10.17487/RFC8028, November 2016, 2033 . 2035 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 2036 "IPv6 Router Advertisement Options for DNS Configuration", 2037 RFC 8106, DOI 10.17487/RFC8106, March 2017, 2038 . 2040 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2041 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2042 May 2017, . 2044 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2045 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2046 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2047 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2048 . 2050 11.2. Informative References 2052 [I-D.ietf-intarea-provisioning-domains] 2053 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 2054 Shao, "Discovering Provisioning Domain Names and Data", 2055 draft-ietf-intarea-provisioning-domains-04 (work in 2056 progress), March 2019. 2058 [I-D.ietf-rtgwg-dst-src-routing] 2059 Lamparter, D. and A. Smirnov, "Destination/Source 2060 Routing", draft-ietf-rtgwg-dst-src-routing-07 (work in 2061 progress), March 2019. 2063 [I-D.pfister-6man-sadr-ra] 2064 Pfister, P., "Source Address Dependent Route Information 2065 Option for Router Advertisements", draft-pfister-6man- 2066 sadr-ra-01 (work in progress), June 2015. 2068 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 2069 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2070 2004, . 2072 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2073 Control Message Protocol (ICMPv6) for the Internet 2074 Protocol Version 6 (IPv6) Specification", STD 89, 2075 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2076 . 2078 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2079 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2080 DOI 10.17487/RFC4861, September 2007, 2081 . 2083 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2084 Address Autoconfiguration", RFC 4862, 2085 DOI 10.17487/RFC4862, September 2007, 2086 . 2088 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2089 Extensions for Stateless Address Autoconfiguration in 2090 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2091 . 2093 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 2094 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 2095 June 2009, . 2097 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 2098 Locator Pair Exploration Protocol for IPv6 Multihoming", 2099 RFC 5534, DOI 10.17487/RFC5534, June 2009, 2100 . 2102 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2103 "Default Address Selection for Internet Protocol Version 6 2104 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2105 . 2107 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2108 Address Selection Policy Using DHCPv6", RFC 7078, 2109 DOI 10.17487/RFC7078, January 2014, 2110 . 2112 Authors' Addresses 2114 Fred Baker 2115 Santa Barbara, California 93117 2116 USA 2118 Email: FredBaker.IETF@gmail.com 2120 Chris Bowers 2121 Juniper Networks 2122 Sunnyvale, California 94089 2123 USA 2125 Email: cbowers@juniper.net 2127 Jen Linkova 2128 Google 2129 Mountain View, California 94043 2130 USA 2132 Email: furry@google.com