idnits 2.17.1 draft-ietf-rtgwg-enterprise-pa-multihoming-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 13, 2018) is 2176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1122' is defined on line 1946, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1951, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1961, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1966, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 1980, but no explicit reference was found in the text == Unused Reference: 'RFC4116' is defined on line 1985, but no explicit reference was found in the text == Unused Reference: 'RFC4218' is defined on line 1998, but no explicit reference was found in the text == Unused Reference: 'RFC4219' is defined on line 2002, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 2020, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 2039, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-src-routing' is defined on line 2046, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-rtgwg-src-dst-routing-use-cases' is defined on line 2051, but no explicit reference was found in the text == Unused Reference: 'I-D.boutier-babel-source-specific' is defined on line 2057, but no explicit reference was found in the text == Unused Reference: 'I-D.huitema-shim6-ingress-filtering' is defined on line 2062, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mif-mpvd-arch' is defined on line 2073, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mptcp-experience' is defined on line 2078, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-src-dst-bgp' is defined on line 2093, but no explicit reference was found in the text == Unused Reference: 'PATRICIA' is defined on line 2098, but no explicit reference was found in the text == Unused Reference: 'RFC6555' is defined on line 2141, but no explicit reference was found in the text == Unused Reference: 'RFC7788' is defined on line 2155, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-01 == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-06 -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 4 errors (**), 0 flaws (~~), 24 warnings (==), 4 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: October 15, 2018 Juniper Networks 6 J. Linkova 7 Google 8 April 13, 2018 10 Enterprise Multihoming using Provider-Assigned Addresses without Network 11 Prefix Translation: Requirements and Solution 12 draft-ietf-rtgwg-enterprise-pa-multihoming-04 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 documents 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 October 15, 2018. 54 Copyright Notice 56 Copyright (c) 2018 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. Enterprise Multihoming Requirements . . . . . . . . . . . . . 6 73 2.1. Simple ISP Connectivity with Connected SERs . . . . . . . 6 74 2.2. Simple ISP Connectivity Where SERs Are Not Directly 75 Connected . . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3. Enterprise Network Operator Expectations . . . . . . . . 8 77 2.4. More complex ISP connectivity . . . . . . . . . . . . . . 11 78 2.5. ISPs and Provider-Assigned Prefixes . . . . . . . . . . . 13 79 2.6. Simplified Topologies . . . . . . . . . . . . . . . . . . 14 80 3. Generating Source-Prefix-Scoped Forwarding Tables . . . . . 14 81 4. Mechanisms For Hosts To Choose Good Source Addresses In A 82 Multihomed Site . . . . . . . . . . . . . . . . . . . . . . . 21 83 4.1. Source Address Selection Algorithm on Hosts . . . . . . . 23 84 4.2. Selecting Source Address When Both Uplinks Are Working . 26 85 4.2.1. Distributing Address Selection Policy Table with 86 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . 26 87 4.2.2. Controlling Source Address Selection With Router 88 Advertisements . . . . . . . . . . . . . . . . . . . 26 89 4.2.3. Controlling Source Address Selection With ICMPv6 . . 28 90 4.2.4. Summary of Methods For Controlling Source Address 91 Selection To Implement Routing Policy . . . . . . . . 30 92 4.3. Selecting Source Address When One Uplink Has Failed . . . 31 93 4.3.1. Controlling Source Address Selection With DHCPv6 . . 32 94 4.3.2. Controlling Source Address Selection With Router 95 Advertisements . . . . . . . . . . . . . . . . . . . 33 96 4.3.3. Controlling Source Address Selection With ICMPv6 . . 34 97 4.3.4. Summary Of Methods For Controlling Source Address 98 Selection On The Failure Of An Uplink . . . . . . . . 34 99 4.4. Selecting Source Address Upon Failed Uplink Recovery . . 35 100 4.4.1. Controlling Source Address Selection With DHCPv6 . . 35 101 4.4.2. Controlling Source Address Selection With Router 102 Advertisements . . . . . . . . . . . . . . . . . . . 35 103 4.4.3. Controlling Source Address Selection With ICMP . . . 36 104 4.4.4. Summary Of Methods For Controlling Source Address 105 Selection Upon Failed Uplink Recovery . . . . . . . . 36 106 4.5. Selecting Source Address When All Uplinks Failed . . . . 37 107 4.5.1. Controlling Source Address Selection With DHCPv6 . . 37 108 4.5.2. Controlling Source Address Selection With Router 109 Advertisements . . . . . . . . . . . . . . . . . . . 37 110 4.5.3. Controlling Source Address Selection With ICMPv6 . . 38 111 4.5.4. Summary Of Methods For Controlling Source Address 112 Selection When All Uplinks Failed . . . . . . . . . . 38 113 4.6. Summary Of Methods For Controlling Source Address 114 Selection . . . . . . . . . . . . . . . . . . . . . . . . 38 115 4.7. Other Configuration Parameters . . . . . . . . . . . . . 40 116 4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 40 117 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 41 118 6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 42 119 6.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 42 120 6.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 42 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 122 8. Security Considerations . . . . . . . . . . . . . . . . . . . 43 123 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 43 124 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 125 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 126 10.1. Normative References . . . . . . . . . . . . . . . . . . 43 127 10.2. Informative References . . . . . . . . . . . . . . . . . 45 128 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 47 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 131 1. Introduction 133 Site multihoming, the connection of a subscriber network to multiple 134 upstream networks using redundant uplinks, is a common enterprise 135 architecture for improving the reliability of its Internet 136 connectivity. If the site uses provider-independent (PI) addresses, 137 all traffic originating from the enterprise can use source addresses 138 from the PI address space. Site multihoming with PI addresses is 139 commonly used with both IPv4 and IPv6, and does not present any new 140 technical challenges. 142 It may be desirable for an enterprise site to connect to multiple 143 ISPs using provider-assigned (PA) addresses, instead of PI addresses. 144 Multihoming with provider-assigned addresses is typically less 145 expensive for the enterprise relative to using provider-independent 146 addresses. PA multihoming is also a practice that should be 147 facilitated and encouraged because it does not add to the size of the 148 Internet routing table, whereas PI multihoming does. Note that PA is 149 also used to mean "provider-aggregatable". In this document we 150 assume that provider-assigned addresses are always provider- 151 aggregatable. 153 With PA multihoming, for each ISP connection, the site is assigned a 154 prefix from within an address block allocated to that ISP by its 155 National or Regional Internet Registry. In the simple case of two 156 ISPs (ISP-A and ISP-B), the site will have two different prefixes 157 assigned to it (prefix-A and prefix-B). This arrangement is 158 problematic. First, packets with the "wrong" source address may be 159 dropped by one of the ISPs. In order to limit denial of service 160 attacks using spoofed source addresses, BCP38 [RFC2827] recommends 161 that ISPs filter traffic from customer sites to only allow traffic 162 with a source address that has been assigned by that ISP. So a 163 packet sent from a multihomed site on the uplink to ISP-B with a 164 source address in prefix-A may be dropped by ISP-B. 166 However, even if ISP-B does not implement BCP38 or ISP-B adds 167 prefix-A to its list of allowed source addresses on the uplink from 168 the multihomed site, two-way communication may still fail. If the 169 packet with source address in prefix-A was sent to ISP-B because the 170 uplink to ISP-A failed, then if ISP-B does not drop the packet and 171 the packet reaches its destination somewhere on the Internet, the 172 return packet will be sent back with a destination address in prefix- 173 A. The return packet will be routed over the Internet to ISP-A, but 174 it will not be delivered to the multihomed site because its link with 175 ISP-A has failed. Two-way communication would require some 176 arrangement for ISP-B to advertise prefix-A when the uplink to ISP-A 177 fails. 179 Note that the same may be true with a provider that does not 180 implement BCP 38, if his upstream provider does, or has no 181 corresponding route. The issue is not that the immediate provider 182 implements ingress filtering; it is that someone upstream does, or 183 lacks a route. 185 With IPv4, this problem is commonly solved by using [RFC1918] private 186 address space within the multi-homed site and Network Address 187 Translation (NAT) or Network Address/Port Translation (NAPT) on the 188 uplinks to the ISPs. However, one of the goals of IPv6 is to 189 eliminate the need for and the use of NAT or NAPT. Therefore, 190 requiring the use of NAT or NAPT for an enterprise site to multihome 191 with provider-assigned addresses is not an attractive solution. 193 [RFC6296] describes a translation solution specifically tailored to 194 meet the requirements of multi-homing with provider-assigned IPv6 195 addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) 196 solution, within the site an enterprise can use Unique Local 197 Addresses [RFC4193] or the prefix assigned by one of the ISPs. As 198 traffic leaves the site on an uplink to an ISP, the source address 199 gets translated to an address within the prefix assigned by the ISP 200 on that uplink in a predictable and reversible manner. [RFC6296] is 201 currently classified as Experimental, and it has been implemented by 202 several vendors. See Section 6.2, for more discussion of NPTv6. 204 This document defines routing requirements for enterprise multihoming 205 using provider-assigned IPv6 addresses. We have made no attempt to 206 write these requirements in a manner that is agnostic to potential 207 solutions. Instead, this document focuses on the following general 208 class of solutions. 210 Each host at the enterprise has multiple addresses, at least one from 211 each ISP-assigned prefix. Each host, as discussed in Section 4.1 and 212 [RFC6724], is responsible for choosing the source address applied to 213 each packet it sends. A host SHOULD be able respond dynamically to 214 the failure of an uplink to a given ISP by no longer sending packets 215 with the source address corresponding to that ISP. Potential 216 mechanisms for the communication of changes in the network to the 217 host are Neighbor Discovery Router Advertisements, DHCPv6, and 218 ICMPv6. 220 The routers in the enterprise network are responsible for ensuring 221 that packets are delivered to the "correct" ISP uplink based on 222 source address. This requires that at least some routers in the site 223 network are able to take into account the source address of a packet 224 when deciding how to route it. That is, some routers must be capable 225 of some form of Source Address Dependent Routing (SADR), if only as 226 described in [RFC3704]. At a minimum, the routers connected to the 227 ISP uplinks (the site exit routers or SERs) must be capable of Source 228 Address Dependent Routing. Expanding the connected domain of routers 229 capable of SADR from the site exit routers deeper into the site 230 network will generally result in more efficient routing of traffic 231 with external destinations. 233 The document first looks in more detail at the enterprise networking 234 environments in which this solution is expected to operate. It then 235 discusses existing and proposed mechanisms for hosts to select the 236 source address applied to packets. Finally, it looks at the 237 requirements for routing that are needed to support these enterprise 238 network scenarios and the mechanisms by which hosts are expected to 239 select source addresses dynamically based on network state. 241 2. Enterprise Multihoming Requirements 243 2.1. Simple ISP Connectivity with Connected SERs 245 We start by looking at a scenario in which a site has connections to 246 two ISPs, as shown in Figure 1. The site is assigned the prefix 247 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP- 248 B. We consider three hosts in the site. H31 and H32 are on a LAN 249 that has been assigned subnets 2001:db8:0:a010::/64 and 250 2001:db8:0:b010::/64. H31 has been assigned the addresses 251 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned 252 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different 253 subnet that has been assigned 2001:db8:0:a020::/64 and 254 2001:db8:0:b020::/64. 256 2001:db8:0:1234::101 H101 257 | 258 | 259 2001:db8:0:a010::31 -------- 260 2001:db8:0:b010::31 ,-----. / \ 261 +--+ +--+ +----+ ,' `. : : 262 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 263 H31--+ +--+ +--+ | +----+ `. ,' : : 264 | | `-----' : Internet : 265 | | : : 266 | | : : 267 | | : : 268 | | ,-----. : : 269 H32--+ +--+ | +----+ ,' `. : : 270 +---|R2|----------+---|SERb|-+ ISP-B +--+-- : 271 +--+ | +----+ `. ,' : : 272 | `-----' : : 273 | : : 274 +--+ +--+ +--+ \ / 275 H41------|R3|--|R5|--|R6| -------- 276 +--+ +--+ +--+ 278 2001:db8:0:a020::41 279 2001:db8:0:b020::41 281 Figure 1: Simple ISP Connectivity With Connected SERs 283 We refer to a router that connects the site to an ISP as a site edge 284 router(SER). Several other routers provide connectivity among the 285 internal hosts (H31, H32, and H41), as well as connecting the 286 internal hosts to the Internet through SERa and SERb. In this 287 example SERa and SERb share a direct connection to each other. In 288 Section 2.2, we consider a scenario where this is not the case. 290 For the moment, we assume that the hosts are able to make good 291 choices about which source addresses through some mechanism that 292 doesn't involve the routers in the site network. Here, we focus on 293 primary task of the routed site network, which is to get packets 294 efficiently to their destinations, while sending a packet to the ISP 295 that assigned the prefix that matches the source address of the 296 packet. In Section 4, we examine what role the routed network may 297 play in helping hosts make good choices about source addresses for 298 packets. 300 With this solution, routers will need form of Source Address 301 Dependent Routing, which will be new functionality. It would be 302 useful if an enterprise site does not need to upgrade all routers to 303 support the new SADR functionality in order to support PA multi- 304 homing. We consider if this is possible and what are the tradeoffs 305 of not having all routers in the site support SADR functionality. 307 In the topology in Figure 1, it is possible to support PA multihoming 308 with only SERa and SERb being capable of SADR. The other routers can 309 continue to forward based only on destination address, and exchange 310 routes that only consider destination address. In this scenario, 311 SERa and SERb communicate source-scoped routing information across 312 their shared connection. When SERa receives a packet with a source 313 address matching prefix 2001:db8:0:b000::/52 , it forwards the packet 314 to SERb, which forwards it on the uplink to ISP-B. The analogous 315 behaviour holds for traffic that SERb receives with a source address 316 matching prefix 2001:db8:0:a000::/52. 318 In Figure 1, when only SERa and SERb are capable of source address 319 dependent routing, PA multi-homing will work. However, the paths 320 over which the packets are sent will generally not be the shortest 321 paths. The forwarding paths will generally be more efficient as more 322 routers are capable of SADR. For example, if R4, R2, and R6 are 323 upgraded to support SADR, then can exchange source-scoped routes with 324 SERa and SERb. They will then know to send traffic with a source 325 address matching prefix 2001:db8:0:b000::/52 directly to SERb, 326 without sending it to SERa first. 328 2.2. Simple ISP Connectivity Where SERs Are Not Directly Connected 330 In Figure 2, we modify the topology slightly by inserting R7, so that 331 SERa and SERb are no longer directly connected. With this topology, 332 it is not enough to just enable SADR routing on SERa and SERb to 333 support PA multi-homing. There are two solutions to ways to enable 334 PA multihoming in this topology. 336 2001:db8:0:1234::101 H101 337 | 338 | 339 2001:db8:0:a010::31 -------- 340 2001:db8:0:b010::31 ,-----. / \ 341 +--+ +--+ +----+ ,' `. : : 342 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 343 H31--+ +--+ +--+ | +----+ `. ,' : : 344 | | `-----' : Internet : 345 | +--+ : : 346 | |R7| : : 347 | +--+ : : 348 | | ,-----. : : 349 H32--+ +--+ | +----+ ,' `. : : 350 +---|R2|----------+---|SERb|-+ ISP-B +--+-- : 351 +--+ | +----+ `. ,' : : 352 | `-----' : : 353 | : : 354 +--+ +--+ +--+ \ / 355 H41------|R3|--|R5|--|R6| -------- 356 +--+ +--+ +--+ | 357 | 358 2001:db8:0:a020::41 2001:db8:0:5678::501 H501 359 2001:db8:0:b020::41 361 Figure 2: Simple ISP Connectivity Where SERs Are Not Directly 362 Connected 364 One option is to effectively modify the topology by creating a 365 logical tunnel between SERa and SERb, using GRE for example. 366 Although SERa and SERb are not directly connected physically in this 367 topology, they can be directly connected logically by a tunnel. 369 The other option is to enable SADR functionality on R7. In this way, 370 R7 will exchange source-scoped routes with SERa and SERb, making the 371 three routers act as a single SADR domain. This illustrates the 372 basic principle that the minimum requirement for the routed site 373 network to support PA multi-homing is having all of the site exit 374 routers be part of a connected SADR domain. Extending the connected 375 SADR domain beyond that point can produce more efficient forwarding 376 paths. 378 2.3. Enterprise Network Operator Expectations 380 Before considering a more complex scenario, let's look in more detail 381 at the reasonably simple multihoming scenario in Figure 2 to 382 understand what can reasonably be expected from this solution. As a 383 general guiding principle, we assume an enterprise network operator 384 will expect a multihomed network to behave as close as to a single- 385 homed network as possible. So a solution that meets those 386 expectations where possible is a good thing. 388 For traffic between internal hosts and traffic from outside the site 389 to internal hosts, an enterprise network operator would expect there 390 to be no visible change in the path taken by this traffic, since this 391 traffic does not need to be routed in a way that depends on source 392 address. It is also reasonable to expect that internal hosts should 393 be able to communicate with each other using either of their source 394 addresses without restriction. For example, H31 should be able to 395 communicate with H41 using a packet with S=2001:db8:0:a010::31, 396 D=2001:db8:0:b010::41, regardless of the state of uplink to ISP-B. 398 These goals can be accomplished by having all of the routers in the 399 network continue to originate normal unscoped destination routes for 400 their connected networks. If we can arrange so that these unscoped 401 destination routes get used for forwarding this traffic, then we will 402 have accomplished the goal of keeping forwarding of traffic destined 403 for internal hosts, unaffected by the multihoming solution. 405 For traffic destined for external hosts, it is reasonable to expect 406 that traffic with an source address from the prefix assigned by ISP-A 407 to follow the path to that the traffic would follow if there is no 408 connection to ISP-B. This can be accomplished by having SERa 409 originate a source-scoped route of the form (S=2001:db8:0:a000::/52, 410 D=::/0) . If all of the routers in the site support SADR, then the 411 path of traffic exiting via ISP-A can match that expectation. If 412 some routers don't support SADR, then it is reasonable to expect that 413 the path for traffic exiting via ISP-A may be different within the 414 site. This is a tradeoff that the enterprise network operator may 415 decide to make. 417 It is important to understand how this multihoming solution behaves 418 when an uplink to one of the ISPs fails. To simplify this 419 discussion, we assume that all routers in the site support SADR. We 420 first start by looking at how the network operates when the uplinks 421 to both ISP-A and ISP-B are functioning properly. SERa originates a 422 source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0), and 423 SERb is originates a source-scoped route of the form 424 (S=2001:db8:0:b000::/52, D=::/0). These routes are distributed 425 through the routers in the site, and they establish within the 426 routers two set of forwarding paths for traffic leaving the site. 427 One set of forwarding paths is for packets with source address in 428 2001:db8:0:a000::/52. The other set of forwarding paths is for 429 packets with source address in 2001:db8:0:b000::/52. The normal 430 destination routes which are not scoped to these two source prefixes 431 play no role in the forwarding. Whether a packet exits the site via 432 SERa or via SERb is completely determined by the source address 433 applied to the packet by the host. So for example, when host H31 434 sends a packet to host H101 with (S=2001:db8:0:a010::31, 435 D=2001:db8:0:1234::101), the packet will only be sent out the link 436 from SERa to ISP-A. 438 Now consider what happens when the uplink from SERa to ISP-A fails. 439 The only way for the packets from H31 to reach H101 is for H31 to 440 start using the source address for ISP-B. H31 needs to send the 441 following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101). 443 This behavior is very different from the behavior that occurs with 444 site multihoming using PI addresses or with PA addresses using NAT. 445 In these other multi-homing solutions, hosts do not need to react to 446 network failures several hops away in order to regain Internet 447 access. Instead, a host can be largely unaware of the failure of an 448 uplink to an ISP. When multihoming with PA addresses and NAT, 449 existing sessions generally need to be re-established after a failure 450 since the external host will receive packets from the internal host 451 with a new source address. However, new sessions can be established 452 without any action on the part of the hosts. 454 Another example where the behavior of this multihoming solution 455 differs significantly from that of multihoming with PI address or 456 with PA addresses using NAT is in the ability of the enterprise 457 network operator to route traffic over different ISPs based on 458 destination address. We still consider the fairly simple network of 459 Figure 2 and assume that uplinks to both ISPs are functioning. 460 Assume that the site is multihomed using PA addresses and NAT, and 461 that SERa and SERb each originate a normal destination route for 462 D=::/0, with the route origination dependent on the state of the 463 uplink to the respective ISP. 465 Now suppose it is observed that an important application running 466 between internal hosts and external host H101 experience much better 467 performance when the traffic passes through ISP-A (perhaps because 468 ISP-A provides lower latency to H101.) When multihoming this site 469 with PI addresses or with PA addresses and NAT, the enterprise 470 network operator can configure SERa to originate into the site 471 network a normal destination route for D=2001:db8:0:1234::/64 (the 472 destination prefix to reach H101) that depends on the state of the 473 uplink to ISP-A. When the link to ISP-A is functioning, the 474 destination route D=2001:db8:0:1234::/64 will be originated by SERa, 475 so traffic from all hosts will use ISP-A to reach H101 based on the 476 longest destination prefix match in the route lookup. 478 Implementing the same routing policy is more difficult with the PA 479 multihoming solution described in this document since it doesn't use 480 NAT. By design, the only way to control where a packet exits this 481 network is by setting the source address of the packet. Since the 482 network cannot modify the source address without NAT, the host must 483 set it. To implement this routing policy, each host needs to use the 484 source address from the prefix assigned by ISP-A to send traffic 485 destined for H101. Mechanisms have been proposed to allow hosts to 486 choose the source address for packets in a fine grained manner. We 487 will discuss these proposals in Section 4. However, interacting with 488 host operating systems in some manner to ensure a particular source 489 address is chosen for a particular destination prefix is not what an 490 enterprise network administrator would expect to have to do to 491 implement this routing policy. 493 2.4. More complex ISP connectivity 495 The previous sections considered two variations of a simple 496 multihoming scenario where the site is connected to two ISPs offering 497 only Internet connectivity. It is likely that many actual enterprise 498 multihoming scenarios will be similar to this simple example. 499 However, there are more complex multihoming scenarios that we would 500 like this solution to address as well. 502 It is fairly common for an ISP to offer a service in addition to 503 Internet access over the same uplink. Two variation of this are 504 reflected in Figure 3. In addition to Internet access, ISP-A offers 505 a service which requires the site to access host H51 at 506 2001:db8:0:5555::51. The site has a single physical and logical 507 connection with ISP-A, and ISP-A only allows access to H51 over that 508 connection. So when H32 needs to access the service at H51 it needs 509 to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) 510 and those packets need to be forward out the link from SERa to ISP-A. 512 2001:db8:0:1234::101 H101 513 | 514 | 515 2001:db8:0:a010::31 -------- 516 2001:db8:0:b010::31 ,-----. / \ 517 +--+ +--+ +----+ ,' `. : : 518 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 519 H31--+ +--+ +--+ | +----+ `. ,' : : 520 | | `-----' : Internet : 521 | | | : : 522 | | H51 : : 523 | | 2001:db8:0:5555::51 : : 524 | +--+ : : 525 | |R7| : : 526 | +--+ : : 527 | | : : 528 | | ,-----. : : 529 H32--+ +--+ | +-----+ ,' `. : : 530 +---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- : 531 +--+ | +-----+ `. ,' : : 532 +--+ `--|--' : : 533 2001:db8:0:a010::32 |R8| | \ / 534 +--+ ,--|--. -------- 535 | +-----+ ,' `. | 536 +-------|SERb2|-+ ISP-B | | 537 | +-----+ `. ,' H501 538 | `-----' 2001:db8:0:5678 539 | | ::501 540 +--+ +--+ H61 541 H41------|R3|--|R5| 2001:db8:0:6666::61 542 +--+ +--+ 544 2001:db8:0:a020::41 545 2001:db8:0:b020::41 547 Figure 3: Internet access and services offered by ISP-A and ISP-B 549 ISP-B illustrates a variation on this scenario. In addition to 550 Internet access, ISP-B also offers a service which requires the site 551 to access host H61. The site has two connections to two different 552 parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects 553 Internet traffic to use the uplink from SERb1, while it expects it 554 expects traffic destined for the service at H61 to use the uplink 555 from SERb2. For either uplink, ISP-B expects the ingress traffic to 556 have a source address matching the prefix it assigned to the site, 557 2001:db8:0:b000::/52. 559 As discussed before, we rely completely on the internal host to set 560 the source address of the packet properly. In the case of a packet 561 sent by H31 to access the service in ISP-B at H61, we expect the 562 packet to have the following addresses: (S=2001:db8:0:b010::31, 563 D=2001:db8:0:6666::61). The routed network has two potential ways of 564 distributing routes so that this packet exits the site on the uplink 565 at SERb2. 567 We could just rely on normal destination routes, without using 568 source-prefix scoped routes. If we have SERb2 originate a normal 569 unscoped destination route for D=2001:db8:0:6666::/64, the packets 570 from H31 to H61 will exit the site at SERb2 as desired. We should 571 not have to worry about SERa needing to originate the same route, 572 because ISP-B should choose a globally unique prefix for the service 573 at H61. 575 The alternative is to have SERb2 originate a source-prefix-scoped 576 destination route of the form (S=2001:db8:0:b000::/52, 577 D=2001:db8:0:6666::/64). From a forwarding point of view, the use of 578 the source-prefix-scoped destination route would result in traffic 579 with source addresses corresponding only to ISP-B being sent to 580 SERb2. Instead, the use of the unscoped destination route would 581 result in traffic with source addresses corresponding to ISP-A and 582 ISP-B being sent to SERb2, as long as the destination address matches 583 the destination prefix. It seems like either forwarding behavior 584 would be acceptable. 586 However, from the point of view of the enterprise network 587 administrator trying to configure, maintain, and trouble-shoot this 588 multihoming solution, it seems much clearer to have SERb2 originate 589 the source-prefix-scoped destination route correspond to the service 590 offered by ISP-B. In this way, all of the traffic leaving the site 591 is determined by the source-prefix-scoped routes, and all of the 592 traffic within the site or arriving from external hosts is determined 593 by the unscoped destination routes. Therefore, for this multihoming 594 solution we choose to originate source-prefix-scoped routes for all 595 traffic leaving the site. 597 2.5. ISPs and Provider-Assigned Prefixes 599 While we expect that most site multihoming involves connecting to 600 only two ISPs, this solution allows for connections to an arbitrary 601 number of ISPs to be supported. However, when evaluating scalable 602 implementations of the solution, it would be reasonable to assume 603 that the maximum number of ISPs that a site would connect to is five. 605 It is also useful to note that the prefixes assigned to the site by 606 different ISPs will not overlap. This must be the case , since the 607 provider-assigned addresses have to be globally unique. 609 2.6. Simplified Topologies 611 The topologies of many enterprise sites using this multihoming 612 solution may in practice be simpler than the examples that we have 613 used. The topology in Figure 1 could be further simplified by having 614 all hosts directly connected to the LAN connecting the two site exit 615 routers, SERa and SERb. The topology could also be simplified by 616 having the uplinks to ISP-A and ISP-B both connected to the same site 617 exit router. However, it is the aim of this draft to provide a 618 solution that applies to a broad a range of enterprise site network 619 topologies, so this draft focuses on providing a solution to the more 620 general case. The simplified cases will also be supported by this 621 solution, and there may even be optimizations that can be made for 622 simplified cases. This solution however needs to support more 623 complex topologies. 625 We are starting with the basic assumption that enterprise site 626 networks can be quite complex from a routing perspective. However, 627 even a complex site network can be multihomed to different ISPs with 628 PA addresses using IPv4 and NAT. It is not reasonable to expect an 629 enterprise network operator to change the routing topology of the 630 site in order to deploy IPv6. 632 3. Generating Source-Prefix-Scoped Forwarding Tables 634 So far we have described in general terms how the routers in this 635 solution that are capable of Source Address Dependent Routing will 636 forward traffic using both normal unscoped destination routes and 637 source-prefix-scoped destination routes. Here we give a precise 638 method for generating a source-prefix-scoped forwarding table on a 639 router that supports SADR. 641 1. Compute the next-hops for the source-prefix-scoped destination 642 prefixes using only routers in the connected SADR domain. These 643 are the initial source-prefix-scoped forwarding table entries. 645 2. Compute the next-hops for the unscoped destination prefixes using 646 all routers in the IGP. This is the unscoped forwarding table. 648 3. Augment each less specific source-prefix-scoped forwarding table 649 with all more specific source-prefix-scoped forwarding tables 650 entries based on the following rule. If the destination prefix 651 of the less specific source-prefix-scoped forwarding entry 652 exactly matches the destination prefix of an existing more 653 specific source-prefix-scoped forwarding entry (including 654 destination prefix length), then do not add the less specific 655 source-prefix-scoped forwarding entry. If the destination prefix 656 does NOT match an existing entry, then add the entry to the more 657 source-prefix-scoped forwarding table. As the unscoped 658 forwarding table is considered to be scoped to ::/0 this process 659 starts with propagating routes from the unscoped forwarding table 660 to source-prefix-scoped forwarding tables and then continues with 661 propagating routes to more-specific-source-prefix-scoped 662 forwarding tables should they exist. 664 The forward tables produced by this process are used in the following 665 way to forward packets. 667 1. Select the most specific (longerst prefix match) source-prefix- 668 scoped forwarding table that matches the source address of the 669 packet (again, the unscoped forwarding table is considered to be 670 scoped to ::/0). 672 2. Look up the destination address of the packet in the selected 673 forwarding table to determine the next-hop for the packet. 675 The following example illustrates how this process is used to create 676 a forwarding table for each provider-assigned source prefix. We 677 consider the multihomed site network in Figure 3. Initially we 678 assume that all of the routers in the site network support SADR. 679 Figure 4 shows the routes that are originated by the routers in the 680 site network. 682 Routes originated by SERa: 683 (S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64) 684 (S=2001:db8:0:a000::/52, D=::/0) 685 (D=2001:db8:0:5555::/64) 686 (D=::/0) 688 Routes originated by SERb1: 689 (S=2001:db8:0:b000::/52, D=::/0) 690 (D=::/0) 692 Routes originated by SERb2: 693 (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64) 694 (D=2001:db8:0:6666::/64) 696 Routes originated by R1: 697 (D=2001:db8:0:a010::/64) 698 (D=2001:db8:0:b010::/64) 700 Routes originated by R2: 701 (D=2001:db8:0:a010::/64) 702 (D=2001:db8:0:b010::/64) 704 Routes originated by R3: 705 (D=2001:db8:0:a020::/64) 706 (D=2001:db8:0:b020::/64) 708 Figure 4: Routes Originated by Routers in the Site Network 710 Each SER originates destination routes which are scoped to the source 711 prefix assigned by the ISP that the SER connects to. Note that the 712 SERs also originate the corresponding unscoped destination route. 713 This is not needed when all of the routers in the site support SADR. 714 However, it is required when some routers do not support SADR. This 715 will be discussed in more detail later. 717 We focus on how R8 constructs its source-prefix-scoped forwarding 718 tables from these route advertisements. R8 computes the next hops 719 for destination routes which are scoped to the source prefix 720 2001:db8:0:a000::/52. The results are shown in the first table in 721 Figure 5. (In this example, the next hops are computed assuming that 722 all links have the same metric.) Then, R8 computes the next hops for 723 destination routes which are scoped to the source prefix 724 2001:db8:0:b000::/52. The results are shown in the second table in 725 Figure 5 . Finally, R8 computes the next hops for the unscoped 726 destination prefixes. The results are shown in the third table in 727 Figure 5. 729 forwarding entries scoped to 730 source prefix = 2001:db8:0:a000::/52 731 ============================================ 732 D=2001:db8:0:5555/64 NH=R7 733 D=::/0 NH=R7 735 forwarding entries scoped to 736 source prefix = 2001:db8:0:b000::/52 737 ============================================ 738 D=2001:db8:0:6666/64 NH=SERb2 739 D=::/0 NH=SERb1 741 unscoped forwarding entries 742 ============================================ 743 D=2001:db8:0:a010::/64 NH=R2 744 D=2001:db8:0:b010::/64 NH=R2 745 D=2001:db8:0:a020::/64 NH=R5 746 D=2001:db8:0:b020::/64 NH=R5 747 D=2001:db8:0:5555::/64 NH=R7 748 D=2001:db8:0:6666::/64 NH=SERb2 749 D=::/0 NH=SERb1 751 Figure 5: Forwarding Entries Computed at R8 753 The final step is for R8 to augment the less specific source-prefix- 754 scoped forwarding entries with more specific source-prefix-scoped 755 forwarding entries. As unscoped forwarding table is considered being 756 scoped to ::/0 and both 2001:db8:0:a000::/52 and 2001:db8:0:b000::/52 757 are more specific prefixes of ::/0, the unscoped (scoped to ::/0) 758 forwarding table needs to be augmented with both more specific 759 source-prefix-scoped tables. If an less specific scoped forwarding 760 entry has the exact same destination prefix as an more specific 761 source-prefix-scoped forwarding entry (including destination prefix 762 length), then the more specific source-prefix-scoped forwarding entry 763 wins. 765 As as an example of how the source scoped forwarding entries are 766 augmented, we consider how the two entries in the first table in 767 Figure 5 (the table for source prefix = 2001:db8:0:a000::/52) are 768 augmented with entries from the third table in Figure 5 (the table of 769 unscoped or scoped for ::/0 forwarding entries). The first four 770 unscoped forwarding entries (D=2001:db8:0:a010::/64, 771 D=2001:db8:0:b010::/64, D=2001:db8:0:a020::/64, and 772 D=2001:db8:0:b020::/64) are not an exact match for any of the 773 existing entries in the forwarding table for source prefix 774 2001:db8:0:a000::/52. Therefore, these four entries are added to the 775 final forwarding table for source prefix 2001:db8:0:a000::/52. The 776 result of adding these entries is reflected in first four entries the 777 first table in Figure 6. 779 The next less specific scoped (scope is ::/0) forwarding table entry 780 is for D=2001:db8:0:5555::/64. This entry is an exact match for the 781 existing entry in the forwarding table for the more specific source 782 prefix 2001:db8:0:a000::/52. Therefore, we do not replace the 783 existing entry with the entry from the unscoped forwarding table. 784 This is reflected in the fifth entry in the first table in Figure 6. 785 (Note that since both scoped and unscoped entries have R7 as the next 786 hop, the result of applying this rule is not visible.) 788 The next less specific prefix scoped (scope is ::/0) forwarding table 789 entry is for D=2001:db8:0:6666::/64. This entry is not an exact 790 match for any existing entries in the forwarding table for source 791 prefix 2001:db8:0:a000::/52. Therefore, we add this entry. This is 792 reflected in the sixth entry in the first table in Figure 6. 794 The next less specific prefix scoped (scope is ::/0) forwarding table 795 entry is for D=::/0. This entry is an exact match for the existing 796 entry in the forwarding table for more specific source prefix 797 2001:db8:0:a000::/52. Therefore, we do not overwrite the existing 798 source-prefix-scoped entry, as can be seen in the last entry in the 799 first table in Figure 6. 801 if source address matches 2001:db8:0:a000::/52 802 then use this forwarding table 803 ============================================ 804 D=2001:db8:0:a010::/64 NH=R2 805 D=2001:db8:0:b010::/64 NH=R2 806 D=2001:db8:0:a020::/64 NH=R5 807 D=2001:db8:0:b020::/64 NH=R5 808 D=2001:db8:0:5555::/64 NH=R7 809 D=2001:db8:0:6666::/64 NH=SERb2 810 D=::/0 NH=R7 812 else if source address matches 2001:db8:0:b000::/52 813 then use this forwarding table 814 ============================================ 815 D=2001:db8:0:a010::/64 NH=R2 816 D=2001:db8:0:b010::/64 NH=R2 817 D=2001:db8:0:a020::/64 NH=R5 818 D=2001:db8:0:b020::/64 NH=R5 819 D=2001:db8:0:5555::/64 NH=R7 820 D=2001:db8:0:6666::/64 NH=SERb2 821 D=::/0 NH=SERb1 823 else if source address matches ::/0 use this forwarding table 824 ============================================ 825 D=2001:db8:0:a010::/64 NH=R2 826 D=2001:db8:0:b010::/64 NH=R2 827 D=2001:db8:0:a020::/64 NH=R5 828 D=2001:db8:0:b020::/64 NH=R5 829 D=2001:db8:0:5555::/64 NH=R7 830 D=2001:db8:0:6666::/64 NH=SERb2 831 D=::/0 NH=SERb1 833 Figure 6: Complete Forwarding Tables Computed at R8 835 The forwarding tables produced by this process at R8 have the desired 836 properties. A packet with a source address in 2001:db8:0:a000::/52 837 will be forwarded based on the first table in Figure 6. If the 838 packet is destined for the Internet at large or the service at 839 D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. 840 If the packet is destined for an internal host, then the first four 841 entries will send it to R2 or R5 as expected. Note that if this 842 packet has a destination address corresponding to the service offered 843 by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to 844 SERb2. It will be dropped by SERb2 or by ISP-B, since it the packet 845 has a source address that was not assigned by ISP-B. However, this 846 is expected behavior. In order to use the service offered by ISP-B, 847 the host needs to originate the packet with a source address assigned 848 by ISP-B. 850 In this example, a packet with a source address that doesn't match 851 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated 852 from an external host. Such a packet will use the unscoped 853 forwarding table (the last table in Figure 6). These packets will 854 flow exactly as they would in absence of multihoming. 856 We can also modify this example to illustrate how it supports 857 deployments where not all routers in the site support SADR. 858 Continuing with the topology shown in Figure 3, suppose that R3 and 859 R5 do not support SADR. Instead they are only capable of 860 understanding unscoped route advertisements. The SADR routers in the 861 network will still originate the routes shown in Figure 4. However, 862 R3 and R5 will only understand the unscoped routes as shown in 863 Figure 7. 865 Routes originated by SERa: 866 (D=2001:db8:0:5555::/64) 867 (D=::/0) 869 Routes originated by SERb1: 870 (D=::/0) 872 Routes originated by SERb2: 873 (D=2001:db8:0:6666::/64) 875 Routes originated by R1: 876 (D=2001:db8:0:a010::/64) 877 (D=2001:db8:0:b010::/64) 879 Routes originated by R2: 880 (D=2001:db8:0:a010::/64) 881 (D=2001:db8:0:b010::/64) 883 Routes originated by R3: 884 (D=2001:db8:0:a020::/64) 885 (D=2001:db8:0:b020::/64) 887 Figure 7: Routes Advertisements Understood by Routers that do no 888 Support SADR 890 With these unscoped route advertisements, R5 will produce the 891 forwarding table shown in Figure 8. 893 forwarding table 894 ============================================ 895 D=2001:db8:0:a010::/64 NH=R8 896 D=2001:db8:0:b010::/64 NH=R8 897 D=2001:db8:0:a020::/64 NH=R3 898 D=2001:db8:0:b020::/64 NH=R3 899 D=2001:db8:0:5555::/64 NH=R8 900 D=2001:db8:0:6666::/64 NH=SERb2 901 D=::/0 NH=R8 903 Figure 8: Forwarding Table For R5, Which Doesn't Understand Source- 904 Prefix-Scoped Routes 906 Any traffic that needs to exit the site will eventually hit a SADR- 907 capable router. Once that traffic enters the SADR-capable domain, 908 then it will not leave that domain until it exits the site. This 909 property is required in order to guarantee that there will not be 910 routing loops involving SADR-capable and non-SADR-capable routers. 912 Note that the mechanism described here for converting source-prefix- 913 scoped destination prefix routing advertisements into forwarding 914 state is somewhat different from that proposed in 915 [I-D.ietf-rtgwg-dst-src-routing]. The method described in this 916 document is intended to be easy to understand for network enterprise 917 operators while at the same time being functionally correct. Another 918 difference is that the method in this document assumes that source 919 prefix will not overlap. Other differences between the two 920 approaches still need to be understood and reconciled. 922 An interesting side-effect of deploying SADR is if all routers in a 923 given network support SADR and have a scoped forwarding table, then 924 the unscoped forwarding table can be eliminated which ensures that 925 packets with legitimate source addresses only can leave the network 926 (as there are no scoped forwarding tables for spoofed/bogon source 927 addresses). It would prevent accidental leaks of ULA/reserved/link- 928 local sources to the Internet as well as ensures that no spoofing is 929 possible from the SADR-enabled network. 931 4. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed 932 Site 934 Until this point, we have made the assumption that hosts are able to 935 choose the correct source address using some unspecified mechanism. 936 This has allowed us to just focus on what the routers in a multihomed 937 site network need to do in order to forward packets to the correct 938 ISP based on source address. Now we look at possible mechanisms for 939 hosts to choose the correct source address. We also look at what 940 role, if any, the routers may play in providing information that 941 helps hosts to choose source addresses. 943 Any host that needs to be able to send traffic using the uplinks to a 944 given ISP is expected to be configured with an address from the 945 prefix assigned by that ISP. The host will control which ISP is used 946 for its traffic by selecting one of the addresses configured on the 947 host as the source address for outgoing traffic. It is the 948 responsibility of the site network to ensure that a packet with the 949 source address from an ISP is now sent on an uplink to that ISP. 951 If all of the ISP uplinks are working, the choice of source address 952 by the host may be driven by the desire to load share across ISP 953 uplinks, or it may be driven by the desire to take advantage of 954 certain properties of a particular uplink or ISP. If any of the ISP 955 uplinks is not working, then the choice of source address by the host 956 can determine if packets get dropped. 958 How a host should make good decisions about source address selection 959 in a multihomed site is not a solved problem. We do not attempt to 960 solve this problem in this document. Instead we discuss the current 961 state of affairs with respect to standardized solutions and 962 implementation of those solutions. We also look at proposed 963 solutions for this problem. 965 An external host initiating communication with a host internal to a 966 PA multihomed site will need to know multiple addresses for that host 967 in order to communicate with it using different ISPs to the 968 multihomed site. These addresses are typically learned through DNS. 969 (For simplicity, we assume that the external host is single-homed.) 970 The external host chooses the ISP that will be used at the remote 971 multihomed site by setting the destination address on the packets it 972 transmits. For a sessions originated from an external host to an 973 internal host, the choice of source address used by the internal host 974 is simple. The internal host has no choice but to use the 975 destination address in the received packet as the source address of 976 the transmitted packet. 978 For a session originated by a host internal to the multi-homed site, 979 the decision of what source address to select is more complicated. 980 We consider three main methods for hosts to get information about the 981 network. The two proactive methods are Neighbor Discovery Router 982 Advertisements and DHCPv6. The one reactive method we consider is 983 ICMPv6. Note that we are explicitly excluding the possibility of 984 having hosts participate in or even listen directly to routing 985 protocol advertisements. 987 First we look at how a host is currently expected to select the 988 source and destination address with which it sends a packet. 990 4.1. Source Address Selection Algorithm on Hosts 992 [RFC6724] defines the algorithms that hosts are expected to use to 993 select source and destination addresses for packets. It defines an 994 algorithm for selecting a source address and a separate algorithm for 995 selecting a destination address. Both of these algorithms depend on 996 a policy table. [RFC6724] defines a default policy which produces 997 certain behavior. 999 The rules in the two algorithms in [RFC6724] depend on many different 1000 properties of addresses. While these are needed for understanding 1001 how a host should choose addresses in an arbitrary environment, most 1002 of the rules are not relevant for understanding how a host should 1003 choose among multiple source addresses in mulitihomed envinronment 1004 when sending a packet to a remote host. Returning to the example in 1005 Figure 3, we look at what the default algorithms in [RFC6724] say 1006 about the source address that internal host H31 should use to send 1007 traffic to external host H101, somewhere on the Internet. Let's look 1008 at what rules in [RFC6724] are actually used by H31 in this case. 1010 There is no choice to be made with respect to destination address. 1011 H31 needs to send a packet with D=2001:db8:0:1234::101 in order to 1012 reach H101. So H31 have to choose between using 1013 S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address 1014 for this packet. We go through the rules for source address 1015 selection in Section 5 of [RFC6724]. Rule 1 (Prefer same address) is 1016 not useful to break the tie between source addresses, because neither 1017 the candidate source addresses equals the destination address. Rule 1018 2 (Prefer appropriate scope) is also not used in this scenario, 1019 because both source addresses and the destination address have global 1020 scope. 1022 Rule 3 (Avoid deprecated addresses) applies to an address that has 1023 been autoconfigured by a host using stateless address 1024 autoconfiguration as defined in [RFC4862]. An address autoconfigured 1025 by a host has a preferred lifetime and a valid lifetime. The address 1026 is preferred until the preferred lifetime expires, after which it 1027 becomes deprecated. A deprecated address is not used if there is a 1028 preferred address of the appropriate scope available. When the valid 1029 lifetime expires, the address cannot be used at all. The preferred 1030 and valid lifetimes for an autoconfigured address are set based on 1031 the corresponding lifetimes in the Prefix Information Option in 1032 Neighbor Discovery Router Advertisements. So a possible tool to 1033 control source address selection in this scenario would be for a host 1034 to make an address deprecated by having routers on that link, R1 and 1035 R2 in Figure 3, send a Router Advertisement message contaning a 1036 Prefix Information Option for the source prefix to be discouraged (or 1037 prohibited) with the preferred lifetime set to zero. This is a 1038 rather blunt tool, because it discourages or prohibits the use of 1039 that source prefix for all destinations. However, it may be useful 1040 in some scenarios. For example, if all uplinks to a particular ISP 1041 fail, it is desirable to prevent hosts from using source addresses 1042 from that ISP address space. 1044 Rule 4 (Avoid home addresses) does not apply here because we are not 1045 considering Mobile IP. 1047 Rule 5 (Prefer outgoing interface) is not useful in this scenario, 1048 because both source addresses are assigned to the same interface. 1050 Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is 1051 not useful in the scenario when both R1 and R2 will advertise both 1052 source prefixes. However potentially this rule may allow a host to 1053 select the correct source prefix by selecting a next-hop. The most 1054 obvious way would be to make R1 to advertise itself as a default 1055 router and send PIO for 2001:db8:0:a010::/64, while R2 is advertising 1056 itself as a default router and sending PIO for 2001:db8:0:b010::/64. 1057 We'll discuss later how Rule 5.5 can be used to influence a source 1058 address selection in single-router topologies (e.g. when H41 is 1059 sending traffic using R3 as a default gateway). 1061 Rule 6 (Prefer matching label) refers to the Label value determined 1062 for each source and destination prefix as a result of applying the 1063 policy table to the prefix. With the default policy table defined in 1064 Section 2.1 of [RFC6724], Label(2001:db8:0:a010::31) = 5, 1065 Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) = 5. 1066 So with the default policy, Rule 6 does not break the tie. However, 1067 the algorithms in [RFC6724] are defined in such as way that non- 1068 default address selection policy tables can be used. [RFC7078] 1069 defines a way to distribute a non-default address selection policy 1070 table to hosts using DHCPv6. So even though the application of rule 1071 6 to this scenario using the default policy table is not useful, rule 1072 6 may still be a useful tool. 1074 Rule 7 (Prefer temporary addresses) has to do with the technique 1075 described in [RFC4941] to periodically randomize the interface 1076 portion of an IPv6 address that has been generated using stateless 1077 address autoconfiguration. In general, if H31 were using this 1078 technique, it would use it for both source addresses, for example 1079 creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 1080 2001:db8:0:b010:4838:f483:8384:3208, in addition to 1081 2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would 1082 prefer the two temporary addresses, but it would not break the tie 1083 between the two source prefixes from ISP-A and ISP-B. 1085 Rule 8 (Use longest matching prefix) dictates that between two 1086 candidate source addresses the one which has longest common prefix 1087 length with the destination address. For example, if H31 were 1088 selecting the source address for sending packets to H101, this rule 1089 would not be a tie breaker as for both candidate source addresses 1090 2001:db8:0:a101::31 and 2001:db8:0:b101::31 the common prefix length 1091 with the destination is 48. However if H31 were selecting the source 1092 address for sending packets H41 address 2001:db8:0:a020::41, then 1093 this rule would result in using 2001:db8:0:a101::31 as a source 1094 (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix 1095 2001:db8:0:a000::/58, while for `2001:db8:0:b101::31 and 1096 2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51). 1097 Therefore rule 8 might be useful for selecting the correct source 1098 address in some but not all scenarios (for example if ISP-B services 1099 belong to 2001:db8:0:b000::/59 then H31 would always use 1100 2001:db8:0:b010::31 to access those destinations). 1102 So we can see that of the 8 source selection address rules from 1103 [RFC6724], five actually apply to our basic site multihoming 1104 scenario. The rules that are relevant to this scenario are 1105 summarized below. 1107 o Rule 3: Avoid deprecated addresses. 1109 o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. 1111 o Rule 6: Prefer matching label. 1113 o Rule 8: Prefer longest matching prefix. 1115 The two methods that we discuss for controlling the source address 1116 selection through the four relevant rules above are SLAAC Router 1117 Advertisement messages and DHCPv6. 1119 We also consider a possible role for ICMPv6 for getting traffic- 1120 driven feedback from the network. With the source address selection 1121 algorithm discussed above, the goal is to choose the correct source 1122 address on the first try, before any traffic is sent. However, 1123 another strategy is to choose a source address, send the packet, get 1124 feedback from the network about whether or not the source address is 1125 correct, and try another source address if it is not. 1127 We consider four scenarios where a host needs to select the correct 1128 source address. The first is when both uplinks are working. The 1129 second is when one uplink has failed. The third one is a situation 1130 when one failed uplink has recovered. The last one is failure of 1131 both (all) uplinks. 1133 4.2. Selecting Source Address When Both Uplinks Are Working 1135 Again we return to the topology in Figure 3. Suppose that the site 1136 administrator wants to implement a policy by which all hosts need to 1137 use ISP-A to reach H01 at D=2001:db8:0:1234::101. So for example, 1138 H31 needs to select S=2001:db8:0:a010::31. 1140 4.2.1. Distributing Address Selection Policy Table with DHCPv6 1142 This policy can be implemented by using DHCPv6 to distribute an 1143 address selection policy table that assigns the same label to 1144 destination address that match 2001:db8:0:1234::/64 as it does to 1145 source addresses that match 2001:db8:0:a000::/52. The following two 1146 entries accomplish this. 1148 Prefix Precedence Label 1149 2001:db8:0:1234::/64 50 33 1150 2001:db8:0:a000::/52 50 33 1152 Figure 9: Policy table entries to implement a routing policy 1154 This requires that the hosts implement [RFC6724], the basic source 1155 and destination address framework, along with [RFC7078], the DHCPv6 1156 extension for distributing a non-default policy table. Note that it 1157 does NOT require that the hosts use DHCPv6 for address assignment. 1158 The hosts could still use stateless address autoconfiguration for 1159 address configuration, while using DHCPv6 only for policy table 1160 distribution (see [RFC3736]). However this method has a number of 1161 disadvantages: 1163 o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so 1164 this method might not work for all devices. 1166 o Network administrators are required to explicitly configure the 1167 desired network access policies on DHCPv6 servers. While it might 1168 be feasible in the scenarion of a single multihomed network, such 1169 approach might have some scalability issues, especially if the 1170 centralized DHCPv6 solution is deployed to serve a large number of 1171 multiomed sites. 1173 4.2.2. Controlling Source Address Selection With Router Advertisements 1175 Neighbor Discovery currently has two mechanisms to communicate prefix 1176 information to hosts. The base specification for Neighbor Discovery 1177 (see [RFC4861]) defines the Prefix Information Option (PIO) in the 1178 Router Advertisement (RA) message. When a host receives a PIO with 1179 the A-flag set, it can use the prefix in the PIO as source prefix 1180 from which it assigns itself an IP address using stateless address 1181 autoconfiguration (SLAAC) procedures described in [RFC4862]. In the 1182 example of Figure 3, if the site network is using SLAAC, we would 1183 expect both R1 and R2 to send RA messages with PIOs for both source 1184 prefixes 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64 with the 1185 A-flag set. H31 would then use the SLAAC procedure to configure 1186 itself with the 2001:db8:0:a010::31 and 2001:db8:0:b010::31. 1188 Whereas a host learns about source prefixes from PIO messages, hosts 1189 can learn about a destination prefix from a Router Advertisement 1190 containing Route Information Option (RIO), as specified in [RFC4191]. 1191 The destination prefixes in RIOs are intended to allow a host to 1192 choose the router that it uses as its first hop to reach a particular 1193 destination prefix. 1195 As currently standardized, neither PIO nor RIO options contained in 1196 Neighbor Discovery Router Advertisements can communicate the 1197 information needed to implement the desired routing policy. PIO's 1198 communicate source prefixes, and RIO communicate destination 1199 prefixes. However, there is currently no standardized way to 1200 directly associate a particular destination prefix with a particular 1201 source prefix. 1203 [I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route 1204 Information option for Neighbor Discovery Router Advertisements which 1205 would associate a source prefix and with a destination prefix. The 1206 details of [I-D.pfister-6man-sadr-ra] might need tweaking to address 1207 this use case. However, in order to be able to use Neighbor 1208 Discovery Router Advertisements to implement this routing policy, an 1209 extension that allows a R1 and R2 to explicitly communicate to H31 an 1210 association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 1211 would be needed. 1213 However, Rule 5.5 of the source address selection algorithm 1214 (discussed in Section 4.1 above), together with default router 1215 preference (specified in [RFC4191]) and RIO can be used to influence 1216 a source address selection on a host as described below. Let's look 1217 at source address selection on the host H41. It receives RAs from R3 1218 with PIOs for 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that 1219 point all traffic would use the same next-hop (R3 link-local address) 1220 so Rule 5.5 does not apply. Now let's assume that R3 supports SADR 1221 and has two scoped forwarding tables, one scoped to 1222 S=2001:db8:0:a000::/52 and another scoped to S=2001:db8:0:b000::/52. 1223 If R3 generates two different link-local addresses for its interface 1224 facing H41 (one for each scoped forwarding table, LLA_A and LLA_B) 1225 and starts sending two different RAs: one is sent from LLA_A and 1226 includes PIO for 2001:db8:0:a020::/64, another us sent from LLA_B and 1227 includes PIO for 2001:db8:0:b020::/64. Now it is possible to 1228 influence H41 source address selection for destinations which follow 1229 the default route by setting default router preference in RAs. If it 1230 is desired that H41 reaches H101 (or any destinations in the 1231 Internet) via ISP-A, then RAs sent from LLA_A should have default 1232 router preference set to 01 (high priority), while RAs sent from 1233 LLA_B should have preference set to 11 (low). Then LLA_A would be 1234 chosen as a next-hop for H101 and therefore (as per rule 5.5) 1235 2001:db8:0:a020::41 would be selected as the source address. If, at 1236 the same time, it is desired that H61 is accessible via ISP-B then R3 1237 should include a RIO for 2001:db8:0:6666::/64 to its RA sent from 1238 LLA_B. H41 would chose LLA_B as a next-hop for all traffic to H61 1239 and then as per Rule 5.5, 2001:db8:0:b020::41 would be selected as a 1240 source address. 1242 If in the above mentioned scenario it is desirable that all Internet 1243 traffic leaves the network via ISP-A and the link to ISP-B is used 1244 for accessing ISP-B services only (not as ISP-A link backup), then 1245 RAs sent by R3 from LLA_B should have Router Lifetime set to 0 and 1246 should include RIOs for ISP-B address space. It would instruct H41 1247 to use LLA_A for all Internet traffic but use LLA_B as a next-hop 1248 while sending traffic to ISP-B addresses. 1250 The description of the mechanism above assumes SADR support by the 1251 first-hop routers as well as SERs. However, a first-hop router can 1252 still provide a less flexible version of this mechanism even without 1253 implementing SADR. This could be done by providing configuration 1254 knobs on the first-hop router that allow it to generate different 1255 link-local addresses and to send individual RAs for each prefix. 1257 The mechanism described above relies on Rule 5.5 of the default 1258 source address selection algorithm defined in [RFC6724]. [RFC8028] 1259 recommends that a host SHOULD select default routers for each prefix 1260 in which it is assigned an address. It also recommends that hosts 1261 SHOULD implement Rule 5.5. of [RFC6724]. Hosts following the 1262 recommendations specified in [RFC8028] therefore should be able to 1263 benefit from the solution described in this document. No standards 1264 need to be updated in regards to host behavior. 1266 4.2.3. Controlling Source Address Selection With ICMPv6 1268 We now discuss how one might use ICMPv6 to implement the routing 1269 policy to send traffic destined for H101 out the uplink to ISP-A, 1270 even when uplinks to both ISPs are working. If H31 started sending 1271 traffic to H101 with S=2001:db8:0:b010::31 and 1272 D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the 1273 uplink to ISP-B. SERb1 could recognize that this is traffic is not 1274 following the desired routing policy and react by sending an ICMPv6 1275 message back to H31. 1277 In this example, we could arrange things so that SERb1 drops the 1278 packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and 1279 then sends to H31 an ICMPv6 Destination Unreachable message with Code 1280 5 (Source address failed ingress/egress policy). When H31 receives 1281 this packet, it would then be expected to try another source address 1282 to reach the destination. In this example, H31 would then send a 1283 packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which 1284 will reach SERa and be forwarded out the uplink to ISP-A. 1286 However, we would also want it to be the case that SERb1 does not 1287 enforce this routing policy when the uplink from SERa to ISP-A has 1288 failed. This could be accomplished by having SERa originate a 1289 source-prefix-scoped route for (S=2001:db8:0:a000::/52, 1290 D=2001:db8:0:1234::/64) and have SERb1 monitor the presence of that 1291 route. If that route is not present (because SERa has stopped 1292 originating it), then SERb1 will not enforce the routing policy, and 1293 it will forward packets with S=2001:db8:0:b010::31 and 1294 D=2001:db8:0:1234::101 out its uplink to ISP-B. 1296 We can also use this source-prefix-scoped route originated by SERa to 1297 communicate the desired routing policy to SERb1. We can define an 1298 EXCLUSIVE flag to be advertised together with the IGP route for 1299 (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow 1300 SERa to communicate to SERb that SERb should reject traffic for 1301 D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination 1302 Unreachable Code 5 message, as long as the route for 1303 (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. 1305 Finally, if we are willing to extend ICMPv6 to support this solution, 1306 then we could create a mechanism for SERb1 to tell the host what 1307 source address it should be using to successfully forward packets 1308 that meet the policy. In its current form, when SERb1 sends an 1309 ICMPv6 Destination Unreachable Code 5 message, it is basically 1310 saying, "This source address is wrong. Try another source address." 1311 In the absence of a clear indication which address to try next, the 1312 host will iterate over all addresses assigned to the interface (e.g. 1313 various privacy addresses) which would lead to significant delays and 1314 degraded user experience. It would be better is if the ICMPv6 1315 message could say, "This source address is wrong. Instead use a 1316 source address in S=2001:db8:0:a000::/52.". 1318 However using ICMPv6 for signalling source address information back 1319 to hosts introduces new challenges. Most routers currently have 1320 software or hardware limits on generating ICMP messages. An site 1321 administrator deploying a solution that relies on the SERs generating 1322 ICMP messages could try to improve the performance of SERs for 1323 generating ICMP messages. However, in a large network, it is still 1324 likely that ICMP message generation limits will be reached. As a 1325 result hosts would not receive ICMPv6 back which in turn leads to 1326 traffic blackholing and poor user experience. To improve the 1327 scalability of ICMPv6-based signalling hosts SHOULD cache the 1328 preferred source address (or prefix) for the given destination (which 1329 in turn might cause issues in case of the corresponding ISP uplinks 1330 failure - see Section 4.3). In addition, the same source prefix 1331 SHOULD be used for other destinations in the same /64 as the original 1332 destination address. The source prefix SHOULD have a specific 1333 lifetime. Expiration of the lifetime SHOULD trigger the source 1334 address selection algorithm again. 1336 Using ICMPv6 Code 5 message for influencing source address selection 1337 allows an attacker to exhaust the list of candidate source addresses 1338 on the host by sending spoofed ICMPv6 Code 5 for all prefixes known 1339 on the network (therefore preventing a victim from establishing a 1340 communication with the destination host). To protect from such 1341 attack hosts SHOULD verify that the original packet header included 1342 into ICMPv6 error message was actually sent by the host. 1344 As currently standardized in [RFC4443], the ICMPv6 Destination 1345 Unreachable Message with Code 5 would allow for the iterative 1346 approach to retransmitting packets using different source addresses. 1347 As currently defined, the ICMPv6 message does not provide a mechanism 1348 to communication information about which source prefix should be used 1349 for a retransmitted packet. The current document does not define 1350 such a mechanism. However, we note that this might be a useful 1351 extension to define in a different document. 1353 4.2.4. Summary of Methods For Controlling Source Address Selection To 1354 Implement Routing Policy 1356 So to summarize this section, we have looked at three methods for 1357 implementing a simple routing policy where all traffic for a given 1358 destination on the Internet needs to use a particular ISP, even when 1359 the uplinks to both ISPs are working. 1361 The default source address selection policy cannot distinguish 1362 between the source addresses needed to enforce this policy, so a non- 1363 default policy table using associating source and destination 1364 prefixes using Label values would need to be installed on each host. 1365 A mechanism exists for DHCPv6 to distribute a non-default policy 1366 table but such solution would heavily rely on DHCPv6 support by host 1367 operating system. Moreover there is no mechanism to translate 1368 desired routing/traffic engineering policies into policy tables on 1369 DHCPv6 servers. Therefore using DHCPv6 for controlling address 1370 selection policy table is not recommended and SHOULD NOT be used. 1372 At the same time Router Advertisements provide a reliable mechanism 1373 to influence source address selection process via PIO, RIO and 1374 default router preferences. As all those options have been 1375 standardized by IETF and are supported by various operating systems, 1376 no changes are required on hosts. First-hop routers in the 1377 enterprise network need to be able of sending different RAs for 1378 different SLAAC prefixes (either based on scoped forwarding tables or 1379 based on pre-configured policies). 1381 SERs can enforce the routing policy by sending ICMPv6 Destination 1382 Unreachable messages with Code 5 (Source address failed ingress/ 1383 egress policy) for traffic that is being sent with the wrong source 1384 address. The policy distribution can be automated by defining an 1385 EXCLUSIVE flag for the source-prefix-scoped route which can be set on 1386 the SER that originates the route. As ICMPv6 message generation can 1387 be rate-limited on routers, it SHOULD NOT be used as the only 1388 mechanism to influence source address selection on hosts. While 1389 hosts SHOULD select the correct source address for a given 1390 destination the network SHOULD signal any source address issues back 1391 to hosts using ICMPv6 error messages. 1393 4.3. Selecting Source Address When One Uplink Has Failed 1395 Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements, 1396 and ICMPv6 can help a host choose the right source address when an 1397 uplink to one of the ISPs has failed. Again we look at the scenario 1398 in Figure 3. This time we look at traffic from H31 destined for 1399 external host H501 at D=2001:db8:0:5678::501. We initially assume 1400 that the uplink from SERa to ISP-A is working and that the uplink 1401 from SERb1 to ISP-B is working. 1403 We assume there is no particular routing policy desired, so H31 is 1404 free to send packets with S=2001:db8:0:a010::31 or 1405 S=2001:db8:0:b010::31 and have them delivered to H501. For this 1406 example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that 1407 the packets exit via SERb to ISP-B. Now we see what happens when the 1408 link from SERb1 to ISP-B fails. How should H31 learn that it needs 1409 to start sending the packet to H501 with S=2001:db8:0:a010::31 in 1410 order to start using the uplink to ISP-A? We need to do this in a 1411 way that doesn't prevent H31 from still sending packets with 1412 S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61. 1414 4.3.1. Controlling Source Address Selection With DHCPv6 1416 For this example we assume that the site network in Figure 3 has a 1417 centralized DHCP server and all routers act as DHCP relay agents. We 1418 assume that both of the addresses assigned to H31 were assigned via 1419 DHCP. 1421 We could try to have the DHCP server monitor the state of the uplink 1422 from SERb1 to ISP-B in some manner and then tell H31 that it can no 1423 longer use S=2001:db8:0:b010::31 by settings its valid lifetime to 1424 zero. The DHCP server could initiate this process by sending a 1425 Reconfigure Message to H31 as described in Section 19 of [RFC3315]. 1426 Or the DHCP server can assign addresses with short lifetimes in order 1427 to force clients to renew them often. 1429 This approach would prevent H31 from using S=2001:db8:0:b010::31 to 1430 reach the a host on the Internet. However, it would also prevent H31 1431 from using S=2001:db8:0:b010::31 to reach H61 at 1432 D=2001:db8:0:6666::61, which is not desirable. 1434 Another potential approach is to have the DHCP server monitor the 1435 uplink from SERb1 to ISP-B and control the choice of source address 1436 on H31 by updating its address selection policy table via the 1437 mechanism in [RFC7078]. The DHCP server could initiate this process 1438 by sending a Reconfigure Message to H31. Note that [RFC3315] 1439 requires that Reconfigure Message use DHCP authentication. DHCP 1440 authentication could be avoided by using short address lifetimes to 1441 force clients to send Renew messages to the server often. If the 1442 host is not obtaining its IP addresses from the DHCP server, then it 1443 would need to use the Information Refresh Time option defined in 1444 [RFC4242]. 1446 If the following policy table can be installed on H31 after the 1447 failure of the uplink from SERb1, then the desired routing behavior 1448 should be achieved based on source and destination prefix being 1449 matched with label values. 1451 Prefix Precedence Label 1452 ::/0 50 44 1453 2001:db8:0:a000::/52 50 44 1454 2001:db8:0:6666::/64 50 55 1455 2001:db8:0:b000::/52 50 55 1457 Figure 10: Policy Table Needed On Failure Of Uplink From SERb1 1459 The described solution has a number of significant drawbacks, some of 1460 them already discussed in Section 4.2.1. 1462 o DHCPv6 support is not required for an IPv6 host and there are 1463 operating systems which do not support DHCPv6. Besides that, it 1464 does not appear that [RFC7078] has been widely implemented on host 1465 operating systems. 1467 o [RFC7078] does not clearly specify this kind of a dynamic use case 1468 where address selection policy needs to be updated quickly in 1469 response to the failure of a link. In a large network it would 1470 present scalability issues as many hosts need to be reconfigured 1471 in very short period of time. 1473 o Updating DHCPv6 server configuration each time an ISP uplink 1474 changes its state introduces some scalability issues, especially 1475 for mid/large distributed scale enterprise networks. In addition 1476 to that, the policy table needs to be manually configured by 1477 administrators which makes that solution prone to human error. 1479 o No mechanism exists for making DHCPv6 servers aware of network 1480 topology/routing changes in the network. In general DHCPv6 1481 servers monitoring network-related events sounds like a bad idea 1482 as completely new functionality beyond the scope of DHCPv6 role is 1483 required. 1485 4.3.2. Controlling Source Address Selection With Router Advertisements 1487 The same mechanism as discussed in Section 4.2.2 can be used to 1488 control the source address selection in the case of an uplink 1489 failure. If a particular prefix should not be used as a source for 1490 any destinations, then the router needs to send RA with Preferred 1491 Lifetime field for that prefix set to 0. 1493 Let's consider a scenario when all uplinks are operational and H41 1494 receives two different RAs from R3: one from LLA_A with PIO for 1495 2001:db8:0:a020::/64, default router preference set to 11 (low) and 1496 another one from LLA_B with PIO for 2001:db8:0:a020::/64, default 1497 router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. 1498 As a result H41 is using 2001:db8:0:b020::41 as a source address for 1499 all Internet traffic and those packets are sent by SERs to ISP-B. If 1500 SERb1 uplink to ISP-B failed, the desired behavior is that H41 stops 1501 using 2001:db8:0:b020::41 as a source address for all destinations 1502 but H61. To achieve that R3 should react to SERb1 uplink failure 1503 (which could be detected as the scoped route (S=2001:db8:0:b000::/52, 1504 D=::/0) disappearance) by withdrawing itself as a default router. R3 1505 sends a new RA from LLA_B with Router Lifetime value set to 0 (which 1506 means that it should not be used as default router). That RA still 1507 contains PIO for 2001:db8:0:b020::/64 (for SLAAC purposes) and RIO 1508 for 2001:db8:0:6666::/64 so H41 can reach H61 using LLA_B as a next- 1509 hop and 2001:db8:0:b020::41 as a source address. For all traffic 1510 following the default route, LLA_A will be used as a next-hop and 1511 2001:db8:0:a020::41 as a source address. 1513 If all uplinks to ISP-B have failed and therefore source addresses 1514 from ISP-B address space should not be used at all, the forwarding 1515 table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can 1516 be instructed to stop using source addresses from that block by 1517 sending RAs containing PIO with Preferred Lifetime set to 0. 1519 4.3.3. Controlling Source Address Selection With ICMPv6 1521 Now we look at how ICMPv6 messages can provide information back to 1522 H31. We assume again that at the time of the failure H31 is sending 1523 packets to H501 using (S=2001:db8:0:b010::31, 1524 D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, 1525 SERb1 would stop originating its source-prefix-scoped route for the 1526 default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its 1527 unscoped default destination route. With these routes no longer in 1528 the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) 1529 would end up at SERa based on the unscoped default destination route 1530 being originated by SERa. Since that traffic has the wrong source 1531 address to be forwarded to ISP-A, SERa would drop it and send a 1532 Destination Unreachable message with Code 5 (Source address failed 1533 ingress/egress policy) back to H31. H31 would then know to use 1534 another source address for that destination and would try with 1535 (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be 1536 forwarded to SERa based on the source-prefix-scoped default 1537 destination route still being originated by SERa, and SERa would 1538 forward it to ISP-A. As discussed above, if we are willing to extend 1539 ICMPv6, SERa can even tell H31 what source address it should use to 1540 reach that destination. The expected host behaviour has been 1541 discussed in Section 4.2.3. Potential issue with using ICMPv6 for 1542 signalling source address issues back to hosts is that uplink to an 1543 ISP-B failure immediately invalidates source addresses from 1544 2001:db8:0:b000::/52 for all hosts which triggers a large number of 1545 ICMPv6 being sent back to hosts - the same scalability/rate limiting 1546 issues discussed in Section 4.2.3 would apply. 1548 4.3.4. Summary Of Methods For Controlling Source Address Selection On 1549 The Failure Of An Uplink 1551 It appears that DHCPv6 is not particularly well suited to quickly 1552 changing the source address used by a host in the event of the 1553 failure of an uplink, which eliminates DHCPv6 from the list of 1554 potential solutions. On the other hand Router Advertisements 1555 provides a reliable mechanism to dynamically provide hosts with a 1556 list of valid prefixes to use as source addresses as well as prevent 1557 particular prefixes to be used. While no additional new features are 1558 required to be implemented on hosts, routers need to be able to send 1559 RAs based on the state of scoped forwarding tables entries and to 1560 react to network topology changes by sending RAs with particular 1561 parameters set. 1563 The use of ICMPv6 Destination Unreachable messages generated by the 1564 SER (or any SADR-capable) routers seem like they have the potential 1565 to provide a support mechanism together with RAs to signal source 1566 address selection errors back to hosts, however scalability issues 1567 may arise in large networks in case of sudden topology change. 1568 Therefore it is highly desirable that hosts are able to select the 1569 correct source address in case of uplinks failure with ICMPv6 being 1570 an additional mechanism to signal unexpected failures back to hosts. 1572 The current behavior of different host operating system when 1573 receiving ICMPv6 Destination Unreachable message with code 5 (Source 1574 address failed ingress/egress policy) is not clear to the authors. 1575 Information from implementers, users, and testing would be quite 1576 helpful in evaluating this approach. 1578 4.4. Selecting Source Address Upon Failed Uplink Recovery 1580 The next logical step is to look at the scenario when a failed uplink 1581 on SERb1 to ISP-B is coming back up, so hosts can start using source 1582 addresses belonging to 2001:db8:0:b000::/52 again. 1584 4.4.1. Controlling Source Address Selection With DHCPv6 1586 The mechanism to use DHCPv6 to instruct the hosts (H31 in our 1587 example) to start using prefixes from ISP-B space (e.g. 1588 S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is 1589 quite similar to one discussed in Section 4.3.1 and shares the same 1590 drawbacks. 1592 4.4.2. Controlling Source Address Selection With Router Advertisements 1594 Let's look at the scenario discussed in Section 4.3.2. If the 1595 uplink(s) failure caused the complete withdrawal of prefixes from 1596 2001:db8:0:b000::/52 address space by setting Preferred Lifetime 1597 value to 0, then the recovery of the link should just trigger new RA 1598 being sent with non-zero Preferred Lifetime. In another scenario 1599 discussed in Section 4.3.2, the SERb1 uplink to ISP-B failure leads 1600 to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from 1601 the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn, 1602 caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The 1603 recovery of the SERb1 uplink to ISP-B leads to 1604 (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- 1605 appearance and instructs R3 that it should advertise itself as a 1606 default router for ISP-B address space domain (send RAs from LLA_B 1607 with non-zero Router Lifetime). 1609 4.4.3. Controlling Source Address Selection With ICMP 1611 It looks like ICMPv6 provides a rather limited functionality to 1612 signal back to hosts that particular source addresses have become 1613 valid again. Unless the changes in the uplink state a particular 1614 (S,D) pair, hosts can keep using the same source address even after 1615 an ISP uplink has come back up. For example, after the uplink from 1616 SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as 1617 described in Section 4.3.3) and allegedly started using 1618 (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now 1619 when the SERb1 uplink comes back up, the packets with that (S,D) pair 1620 are still routed to SERa1 and sent to the Internet. Therefore H31 is 1621 not informed that it should stop using 2001:db8:0:a010::31 and start 1622 using 2001:db8:0:b010::31 again. Unless SERa has a policy configured 1623 to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and 1624 send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware 1625 of the network topology change and keep using S=2001:db8:0:a010::31 1626 for Internet destinations, including H51. 1628 One of the possible option may be using a scoped route with EXCLUSIVE 1629 flag as described in Section 4.2.3. SERa1 uplink recovery would 1630 cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to 1631 reappear in the routing table. In the absence of that route packets 1632 to H101 which were sent to ISP-B (as ISP-A uplink was down) with 1633 source addresses from 2001:db8:0:b000::/52. When the route re- 1634 appears SERb1 would reject those packets and sends ICMPv6 back as 1635 discussed in Section 4.2.3. Practically it might lead to scalability 1636 issues which have been already discussed in Section 4.2.3 and 1637 Section 4.4.3. 1639 4.4.4. Summary Of Methods For Controlling Source Address Selection Upon 1640 Failed Uplink Recovery 1642 Once again DHCPv6 does not look like reasonable choice to manipulate 1643 source address selection process on a host in the case of network 1644 topology changes. Using Router Advertisement provides the flexible 1645 mechanism to dynamically react to network topology changes (if 1646 routers are able to use routing changes as a trigger for sending out 1647 RAs with specific parameters). ICMPv6 could be considered as a 1648 supporting mechanism to signal incorrect source address back to hosts 1649 but should not be considered as the only mechanism to control the 1650 address selection in multihomed environments. 1652 4.5. Selecting Source Address When All Uplinks Failed 1654 One particular tricky case is a scenario when all uplinks have 1655 failed. In that case there is no valid source address to be used for 1656 any external destinations while it might be desirable to have intra- 1657 site connectivity. 1659 4.5.1. Controlling Source Address Selection With DHCPv6 1661 From DHCPv6 perspective uplinks failure should be treated as two 1662 independent failures and processed as described in Section 4.3.1. At 1663 this stage it is quite obvious that it would result in quite 1664 complicated policy table which needs to be explicitly configured by 1665 administrators and therefore seems to be impractical. 1667 4.5.2. Controlling Source Address Selection With Router Advertisements 1669 As discussed in Section 4.3.2 an uplink failure causes the scoped 1670 default entry to disappear from the scoped forwarding table and 1671 triggers RAs with zero Router Lifetime. Complete disappearance of 1672 all scoped entries for a given source prefix would cause the prefix 1673 being withdrawn from hosts by setting Preferred Lifetime value to 1674 zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts 1675 either lost their default routers and/or have no global IPv6 1676 addresses to use as a source. (Note that 'uplink failure' might mean 1677 'IPv6 connectivity failure with IPv4 still being reachable', in which 1678 case hosts might fall back to IPv4 if there is IPv4 connectivity to 1679 destinations). As a results intra-site connectivity is broken. One 1680 of the possible way to solve it is to use ULAs. 1682 All hosts have ULA addresses assigned in addition to GUAs and used 1683 for intra-site communication even if there is no GUA assigned to a 1684 host. To avoid accidental leaking of packets with ULA sources SADR- 1685 capable routers SHOULD have a scoped forwarding table for ULA source 1686 for internal routes but MUST NOT have an entry for D=::/0 in that 1687 table. In the absence of (S=ULA_Prefix; D=::/0) first-hop routers 1688 will send dedicated RAs from a unique link-local source LLA_ULA with 1689 PIO from ULA address space, RIO for the ULA prefix and Router 1690 Lifetime set to zero. The behaviour is consistent with the situation 1691 when SERb1 lost the uplink to ISP-B (so there is no Internet 1692 connectivity from 2001:db8:0:b000::/52 sources) but those sources can 1693 be used to reach some specific destinations. In the case of ULA 1694 there is no Internet connectivity from ULA sources but they can be 1695 used to reach another ULA destinations. Note that ULA usage could be 1696 particularly useful if all ISPs assign prefixes via DHCP-PD. In the 1697 absence of ULAs uplinks failure hosts would lost all their GUAs upon 1698 prefix lifetime expiration which again makes intra-site communication 1699 impossible. 1701 It should be noted that the Rule 5.5 (prefer a prefix advertised by 1702 the selected next-hop) takes precedence over the Rule 6 (prefer 1703 matching label, which ensures that GUA source addresses are preferred 1704 over ULAs for GUA destinations). Therefore if ULAs are used, the 1705 network adminstrator needs to ensure that while the site has an 1706 Internet connectivity, hosts do not select a roter which advertises 1707 ULA prefixes as their default router. 1709 4.5.3. Controlling Source Address Selection With ICMPv6 1711 In case of all uplinks failure all SERs will drop outgoing IPv6 1712 traffic and respond with ICMPv6 error message. In the large network 1713 when many hosts are trying to reach Internet destinations it means 1714 that SERs need to generate an ICMPv6 error to every packet they 1715 receive from hosts which presents the same scalability issues 1716 discussed in Section 4.3.3 1718 4.5.4. Summary Of Methods For Controlling Source Address Selection When 1719 All Uplinks Failed 1721 Again, combining SADR with Router Advertisements seems to be the most 1722 flexible and scalable way to control the source address selection on 1723 hosts. 1725 4.6. Summary Of Methods For Controlling Source Address Selection 1727 To summarize the scenarios and options discussed above: 1729 While DHCPv6 allows administrators to manipulate source address 1730 selection policy tables, this method has a number of significant 1731 disadvantages which eliminates DHCPv6 from a list of potential 1732 solutions: 1734 1. It required hosts to support DHCPv6 and its extension (RFC7078); 1736 2. DHCPv6 server needs to monitor network state and detect routing 1737 changes. 1739 3. The use of policy tables requires manual configuration and might 1740 be extremely complicated, especially in the case of distributed 1741 network when large number of remote sites are being served by 1742 centralized DHCPv6 servers. 1744 4. Network topology/routing policy changes could trigger 1745 simultaneous re-configuration of large number of hosts which 1746 present serious scalability issues. 1748 The use of Router Advertisements to influence the source address 1749 selection on hosts seem to be the most reliable, flexible and 1750 scalable solution. It has the following benefits: 1752 1. no new (non-standard) functionality needs to be implemented on 1753 hosts (except for [RFC4191] support); 1755 2. no changes in RA format; 1757 3. routers can react to routing table changes by sending RAs which 1758 would minimize the failover time in the case of network topology 1759 changes; 1761 4. information required for source address selection is broadcast to 1762 all affected hosts in case of topology change event which 1763 improves the scalability of the solution (comparing to DHCPv6 1764 reconfiguration or ICMPv6 error messages). 1766 To fully benefit from the RA-based solution, first-hop routers need 1767 to implement SADR and be able to send dedicated RAs per scoped 1768 forwarding table as discussed above, reacting to network changes with 1769 sending new RAs. It should be noted that the proposed solution would 1770 work even if first-hop routers are not SADR-capable but still able to 1771 send individual RAs for each ISP prefix and react to topology changes 1772 as discussed above (e.g. via configuration knobs). 1774 The RA-based solution relies heavily on hosts correctly implementing 1775 default address selection algorith as defined in [RFC6724]. While 1776 the basic (and most common) multihoming scenario (two or more 1777 Internet uplinks, no 'wall gardens') would work for any host 1778 supporting the minimal implementation of [RFC6724], more complex use 1779 cases (such as "wall garden" and other scenarios when some ISP 1780 resources can only be reached from that ISP address space) require 1781 that hosts support Rule 5.5 of the default address selection 1782 algorithm. There is some evidence that not all host OSes have that 1783 rule implemented currently. However it should be noted that 1784 [RFC8028] states that Rule 5.5 SHOULD be implemented. 1786 ICMPv6 Code 5 error message SHOULD be used to complement RA-based 1787 solution to signal incorrect source address selection back to hosts, 1788 but it SHOULD NOT be considered as the stand-alone solution. To 1789 prevent scenarios when hosts in multihomed envinronments incorrectly 1790 identify onlink/offlink destinations, hosts should treat ICMPv6 1791 Redirects as discussed in [RFC8028]. 1793 4.7. Other Configuration Parameters 1795 4.7.1. DNS Configuration 1797 In mutihomed envinronment each ISP might provide their own list of 1798 DNS servers. E.g. in the topology show on Figure 3, ISP-A might 1799 provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B 1800 might provide H61 2001:db8:0:6666::61 as a recursive DNS server. 1801 [RFC8106] defines IPv6 Router Advertisement options to allow IPv6 1802 routers to advertise a list of DNS recursive server addresses and a 1803 DNS Search List to IPv6 hosts. Using RDNSS together with 'scoped' 1804 RAs as described above would allow a first-hop router (R3 in the 1805 Figure 3) to send DNS server addresses and search lists provided by 1806 each ISP (or the corporate DNS servers addresses if the enterprise is 1807 running its own DNS servers). 1809 As discussed in Section 4.5.2, failure of all ISP uplinks would cause 1810 deprecaction of all addresses assigned to a host from the address 1811 space if all ISPs. If any intra-site IPv6 connectivity is still 1812 desirable (most likely to be the case for any mid/large scare 1813 network), then ULAs should be used as discussed in Section 4.5.2. In 1814 such a scenario, the enterprise network should run its own recursive 1815 DNS server(s) and provide its ULA addresses to hosts via RDNSS in RAs 1816 send for ULA-scoped forwarding table as described in Section 4.5.2. 1818 There are some scenarios when the final outcome of the name 1819 resolution might be different depending on: 1821 o which DNS server is used; 1823 o which source address the client uses to send a DNS query to the 1824 server (DNS split horizon). 1826 There is no way currently to instruct a host to use a particular DNS 1827 server out of the configured servers list for resolving a particular 1828 name. Therefore it does not seem feasible to solve the problem of 1829 DNS server selection on the host (it should be noted that this 1830 particular issue is protocol-agnostic and happens for IPv4 as well). 1831 In such a scenario it is recommended that the enterprise run its own 1832 local recursive DNS server. 1834 To influence host source address selection for packets sent to a 1835 particular DNS server the following requirements must be met: 1837 o the host supports RIO as defined in [RFC4191]; 1839 o the routers send RIO for routes to DNS server addresses. 1841 For example, if it is desirable that host H31 reaches the ISP-A DNS 1842 server H51 2001:db8:0:5555::51 using its source address 1843 2001:db8:0:a010::31, then both R1 and R2 should send the RIO 1844 containing the route to 2001:db8:0:5555::51 (or covering route) in 1845 their 'scoped' RAs, containing LLA_A as the default router address 1846 and the PO for SLAAC prefix 2001:db8:0:a010::/64. In that case the 1847 host H31 (if it supports the Rule 5.5) would select LLA_A as a next- 1848 hop and then chose 2001:db8:0:a010::31 as the source address for 1849 packets to the DNS server. 1851 It should be noted that [RFC6106] explicitly prohibits using DNS 1852 information if the RA router Lifetime expired: "An RDNSS address or a 1853 DNSSL domain name MUST be used only as long as both the RA router 1854 Lifetime (advertised by a Router Advertisement message) and the 1855 corresponding option Lifetime have not expired.". Therefore hosts 1856 might ignore RDNSS information provided in ULA-scoped RAs as those 1857 RAs would have router lifetime set to 0. However the updated version 1858 of RFC6106 ([RFC8106]) has that requirement removed. 1860 5. Deployment Considerations 1862 The solution described in this document requires certain mechanisms 1863 to be supported by the network infrastructure and hosts. It requires 1864 some routers in the enterprise site to support some form of Source 1865 Address Dependent Routing (SADR). It also requires hosts to be able 1866 to learn when the uplink to an ISP chages its state so the 1867 corresponding source addresses should (or should not) be used. 1868 Ongoing work to create mechanisms to accomplish this are discussed in 1869 this document, but they are still a work in progress. 1871 The solution discussed in this document relies on the default address 1872 selection algorithm ([RFC6724]) Rule 5.5. While [RFC6724] consideres 1873 this rule as optional, the recent [RFC8028] recommends that a host 1874 SHOULD select default routers for each prefix in which it is assigned 1875 an address. It also recommends that hosts SHOULD implement Rule 5.5. 1876 of [RFC6724]. Therefore while RFC8028-compliant hosts already have 1877 mechanism to learn about ISP uplinks state changes and selecting the 1878 source addresses accordingly, many hosts do not have such mechanism 1879 supported yet. 1881 It should be noted that multihomed enterprise network utilizing 1882 multipe ISP prefixes can be considered as a typical mutiple 1883 provisioning domain (mPVD) scenario, as desribed in [RFC7556]. This 1884 document defines a way for network to provide the PVD information to 1885 hosts indirectly, using the existing mechanisms. At the same time 1886 [I-D.ietf-intarea-provisioning-domains]takes one step further and 1887 describes a comprehensive mechanism for hosts to discover the whole 1888 set of configuration information associated with different PVD/ISPs. 1890 [I-D.ietf-intarea-provisioning-domains] complements this document in 1891 terms of making hosts being able to learn about ISP uplink states and 1892 selecting the corresponding source addresses. 1894 6. Other Solutions 1896 6.1. Shim6 1898 The Shim6 working group specified the Shim6 protocol [RFC5533] which 1899 allows a host at a multihomed site to communicate with an external 1900 host and exchange information about possible source and destination 1901 address pairs that they can use to communicate. It also specified 1902 the REAP protocol [RFC5534] to detect failures in the path between 1903 working address pairs and find new working address pairs. A 1904 fundamental requirement for Shim6 is that both internal and external 1905 hosts need to support Shim6. That is, both the host internal to the 1906 multihomed site and the host external to the multihomed site need to 1907 support Shim6 in order for there to be any benefit for the internal 1908 host to run Shim6. The Shim6 protocol specification was published in 1909 2009, but it has not been widely implemented. Therefore Shim6 is not 1910 considered as a viable solution for enterprise multihoming. 1912 6.2. IPv6-to-IPv6 Network Prefix Translation 1914 IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the 1915 focus of this document. NPTv6 suffers from the same fundamental 1916 issue as any other address translation approaches: it breaks end-to- 1917 end connectivity. Therefore NPTv6 is not considered as desirable 1918 solution and this document intentionally focuses on solving 1919 enterprise multihoming problem without any form of address 1920 translations. 1922 With increasing interest and ongoing work in bringing path awareness 1923 to transport and application layer protocols hosts migth be able to 1924 determine the properties of the various network paths and choose 1925 among paths available to them. As selecting the correct source 1926 address is one of the possible mechanisms path-aware hosts may 1927 utilize, address translation negatively affects hosts path-awareness 1928 which makes NTPv6 even more undesirable solution. 1930 7. IANA Considerations 1932 This memo asks the IANA for no new parameters. 1934 8. Security Considerations 1936 8.1. Privacy Considerations 1938 9. Acknowledgements 1940 The original outline was suggested by Ole Troan. 1942 10. References 1944 10.1. Normative References 1946 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1947 Communication Layers", STD 3, RFC 1122, 1948 DOI 10.17487/RFC1122, October 1989, 1949 . 1951 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1952 Application and Support", STD 3, RFC 1123, 1953 DOI 10.17487/RFC1123, October 1989, 1954 . 1956 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1957 and E. Lear, "Address Allocation for Private Internets", 1958 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1959 . 1961 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1962 Requirement Levels", BCP 14, RFC 2119, 1963 DOI 10.17487/RFC2119, March 1997, 1964 . 1966 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1967 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1968 December 1998, . 1970 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1971 Defeating Denial of Service Attacks which employ IP Source 1972 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1973 May 2000, . 1975 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1976 C., and M. Carney, "Dynamic Host Configuration Protocol 1977 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1978 2003, . 1980 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1981 Multihoming Architectures", RFC 3582, 1982 DOI 10.17487/RFC3582, August 2003, 1983 . 1985 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 1986 Gill, "IPv4 Multihoming Practices and Limitations", 1987 RFC 4116, DOI 10.17487/RFC4116, July 2005, 1988 . 1990 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1991 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1992 November 2005, . 1994 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1995 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1996 . 1998 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 1999 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 2000 October 2005, . 2002 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 2003 Should Think About", RFC 4219, DOI 10.17487/RFC4219, 2004 October 2005, . 2006 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 2007 Time Option for Dynamic Host Configuration Protocol for 2008 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 2009 2005, . 2011 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 2012 "IPv6 Router Advertisement Options for DNS Configuration", 2013 RFC 6106, DOI 10.17487/RFC6106, November 2010, 2014 . 2016 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2017 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 2018 . 2020 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 2021 and D. Wing, "IPv6 Multihoming without Network Address 2022 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 2023 . 2025 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 2026 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 2027 . 2029 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 2030 Hosts in a Multi-Prefix Network", RFC 8028, 2031 DOI 10.17487/RFC8028, November 2016, 2032 . 2034 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 2035 "IPv6 Router Advertisement Options for DNS Configuration", 2036 RFC 8106, DOI 10.17487/RFC8106, March 2017, 2037 . 2039 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2040 (IPv6) Specification", STD 86, RFC 8200, 2041 DOI 10.17487/RFC8200, July 2017, 2042 . 2044 10.2. Informative References 2046 [I-D.baker-ipv6-isis-dst-src-routing] 2047 Baker, F. and D. Lamparter, "IPv6 Source/Destination 2048 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 2049 routing-07 (work in progress), July 2017. 2051 [I-D.baker-rtgwg-src-dst-routing-use-cases] 2052 Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and 2053 Use Cases for Source/Destination Routing", draft-baker- 2054 rtgwg-src-dst-routing-use-cases-02 (work in progress), 2055 April 2016. 2057 [I-D.boutier-babel-source-specific] 2058 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 2059 Babel", draft-boutier-babel-source-specific-03 (work in 2060 progress), July 2017. 2062 [I-D.huitema-shim6-ingress-filtering] 2063 Huitema, C., "Ingress filtering compatibility for IPv6 2064 multihomed sites", draft-huitema-shim6-ingress- 2065 filtering-00 (work in progress), September 2005. 2067 [I-D.ietf-intarea-provisioning-domains] 2068 Pfister, P., Vyncke, E., Pauly, T., and D. Schinazi, 2069 "Discovering Provisioning Domain Names and Data", draft- 2070 ietf-intarea-provisioning-domains-01 (work in progress), 2071 February 2018. 2073 [I-D.ietf-mif-mpvd-arch] 2074 Anipko, D., "Multiple Provisioning Domain Architecture", 2075 draft-ietf-mif-mpvd-arch-11 (work in progress), March 2076 2015. 2078 [I-D.ietf-mptcp-experience] 2079 Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 2080 Operational Experience with Multipath TCP", draft-ietf- 2081 mptcp-experience-07 (work in progress), October 2016. 2083 [I-D.ietf-rtgwg-dst-src-routing] 2084 Lamparter, D. and A. Smirnov, "Destination/Source 2085 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 2086 progress), October 2017. 2088 [I-D.pfister-6man-sadr-ra] 2089 Pfister, P., "Source Address Dependent Route Information 2090 Option for Router Advertisements", draft-pfister-6man- 2091 sadr-ra-01 (work in progress), June 2015. 2093 [I-D.xu-src-dst-bgp] 2094 Xu, M., Yang, S., and J. Wu, "Source/Destination Routing 2095 Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress), 2096 March 2016. 2098 [PATRICIA] 2099 Morrison, D., "Practical Algorithm to Retrieve Information 2100 Coded in Alphanumeric", Journal of the ACM 15(4) 2101 pp514-534, October 1968. 2103 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 2104 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2105 2004, . 2107 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 2108 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 2109 April 2004, . 2111 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2112 Control Message Protocol (ICMPv6) for the Internet 2113 Protocol Version 6 (IPv6) Specification", STD 89, 2114 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2115 . 2117 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2118 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2119 DOI 10.17487/RFC4861, September 2007, 2120 . 2122 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2123 Address Autoconfiguration", RFC 4862, 2124 DOI 10.17487/RFC4862, September 2007, 2125 . 2127 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2128 Extensions for Stateless Address Autoconfiguration in 2129 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2130 . 2132 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 2133 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 2134 June 2009, . 2136 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 2137 Locator Pair Exploration Protocol for IPv6 Multihoming", 2138 RFC 5534, DOI 10.17487/RFC5534, June 2009, 2139 . 2141 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2142 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2143 2012, . 2145 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2146 "Default Address Selection for Internet Protocol Version 6 2147 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2148 . 2150 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2151 Address Selection Policy Using DHCPv6", RFC 7078, 2152 DOI 10.17487/RFC7078, January 2014, 2153 . 2155 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2156 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2157 2016, . 2159 Appendix A. Change Log 2161 Initial Version: July 2016 2163 Authors' Addresses 2165 Fred Baker 2166 Santa Barbara, California 93117 2167 USA 2169 Email: FredBaker.IETF@gmail.com 2170 Chris Bowers 2171 Juniper Networks 2172 Sunnyvale, California 94089 2173 USA 2175 Email: cbowers@juniper.net 2177 Jen Linkova 2178 Google 2179 Mountain View, California 94043 2180 USA 2182 Email: furry@google.com