idnits 2.17.1 draft-bowbakova-rtgwg-enterprise-pa-multihoming-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1122' is defined on line 1822, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1827, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1837, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1842, but no explicit reference was found in the text == Unused Reference: 'RFC3582' is defined on line 1856, but no explicit reference was found in the text == Unused Reference: 'RFC4116' is defined on line 1861, but no explicit reference was found in the text == Unused Reference: 'RFC4218' is defined on line 1874, but no explicit reference was found in the text == Unused Reference: 'RFC4219' is defined on line 1878, but no explicit reference was found in the text == Unused Reference: 'RFC7157' is defined on line 1896, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-src-routing' is defined on line 1903, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-rtgwg-src-dst-routing-use-cases' is defined on line 1908, but no explicit reference was found in the text == Unused Reference: 'I-D.boutier-babel-source-specific' is defined on line 1914, but no explicit reference was found in the text == Unused Reference: 'I-D.huitema-shim6-ingress-filtering' is defined on line 1919, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mif-mpvd-arch' is defined on line 1935, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mptcp-experience' is defined on line 1940, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-src-dst-bgp' is defined on line 1955, but no explicit reference was found in the text == Unused Reference: 'PATRICIA' is defined on line 1960, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 1973, but no explicit reference was found in the text == Unused Reference: 'RFC6555' is defined on line 2003, but no explicit reference was found in the text == Unused Reference: 'RFC7788' is defined on line 2017, 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) ** Downref: Normative reference to an Informational RFC: RFC 3582 ** Downref: Normative reference to an Informational RFC: RFC 4116 ** Downref: Normative reference to an Informational RFC: RFC 4218 ** Downref: Normative reference to an Informational RFC: RFC 4219 ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Downref: Normative reference to an Experimental RFC: RFC 6296 ** Downref: Normative reference to an Informational RFC: RFC 7157 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-06 == Outdated reference: A later version (-03) exists of draft-boutier-babel-source-specific-01 == Outdated reference: A later version (-16) exists of draft-ietf-6man-rdnss-rfc6106bis-14 == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-02 -- 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: 10 errors (**), 0 flaws (~~), 26 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 Cisco Systems 4 Intended status: Standards Track C. Bowers 5 Expires: May 4, 2017 Juniper Networks 6 J. Linkova 7 Google 8 October 31, 2016 10 Enterprise Multihoming using Provider-Assigned Addresses without Network 11 Prefix Translation: Requirements and Solution 12 draft-bowbakova-rtgwg-enterprise-pa-multihoming-01 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 http://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 May 4, 2017. 54 Copyright Notice 56 Copyright (c) 2016 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 (http://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 . . . 30 93 4.3.1. Controlling Source Address Selection With DHCPv6 . . 31 94 4.3.2. Controlling Source Address Selection With Router 95 Advertisements . . . . . . . . . . . . . . . . . . . 32 96 4.3.3. Controlling Source Address Selection With ICMPv6 . . 33 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 . . 34 100 4.4.1. Controlling Source Address Selection With DHCPv6 . . 34 101 4.4.2. Controlling Source Address Selection With Router 102 Advertisements . . . . . . . . . . . . . . . . . . . 35 103 4.4.3. Controlling Source Address Selection With ICMP . . . 35 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 . . . . 36 107 4.5.1. Controlling Source Address Selection With DHCPv6 . . 36 108 4.5.2. Controlling Source Address Selection With Router 109 Advertisements . . . . . . . . . . . . . . . . . . . 36 110 4.5.3. Controlling Source Address Selection With ICMPv6 . . 37 111 4.5.4. Summary Of Methods For Controlling Source Address 112 Selection When All Uplinks Failed . . . . . . . . . . 37 113 4.6. Summary Of Methods For Controlling Source Address 114 Selection . . . . . . . . . . . . . . . . . . . . . . . . 37 115 4.7. Other Configuration Parameters . . . . . . . . . . . . . 38 116 4.7.1. DNS Configuration . . . . . . . . . . . . . . . . . . 38 117 5. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 39 118 5.1. Shim6 . . . . . . . . . . . . . . . . . . . . . . . . . . 39 119 5.2. IPv6-to-IPv6 Network Prefix Translation . . . . . . . . . 40 120 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 121 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 122 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 40 123 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 124 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 125 9.1. Normative References . . . . . . . . . . . . . . . . . . 40 126 9.2. Informative References . . . . . . . . . . . . . . . . . 42 127 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 45 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 130 1. Introduction 132 Site multihoming, the connection of a subscriber network to multiple 133 upstream networks using redundant uplinks, is a common enterprise 134 architecture for improving the reliability of its Internet 135 connectivity. If the site uses provider-independent (PI) addresses, 136 all traffic originating from the enterprise can use source addresses 137 from the PI address space. Site multihoming with PI addresses is 138 commonly used with both IPv4 and IPv6, and does not present any new 139 technical challenges. 141 It may be desirable for an enterprise site to connect to multiple 142 ISPs using provider-assigned (PA) addresses, instead of PI addresses. 143 Multihoming with provider-assigned addresses is typically less 144 expensive for the enterprise relative to using provider-independent 145 addresses. PA multihoming is also a practice that should be 146 facilitated and encouraged because it does not add to the size of the 147 Internet routing table, whereas PI multihoming does. Note that PA is 148 also used to mean "provider-aggregatable". In this document we 149 assume that provider-assigned addresses are always provider- 150 aggregatable. 152 With PA multihoming, for each ISP connection, the site is assigned a 153 prefix from within an address block allocated to that ISP by its 154 National or Regional Internet Registry. In the simple case of two 155 ISPs (ISP-A and ISP-B), the site will have two different prefixes 156 assigned to it (prefix-A and prefix-B). This arrangement is 157 problematic. First, packets with the "wrong" source address may be 158 dropped by one of the ISPs. In order to limit denial of service 159 attacks using spoofed source addresses, BCP38 [RFC2827] recommends 160 that ISPs filter traffic from customer sites to only allow traffic 161 with a source address that has been assigned by that ISP. So a 162 packet sent from a multihomed site on the uplink to ISP-B with a 163 source address in prefix-A may be dropped by ISP-B. 165 However, even if ISP-B does not implement BCP38 or ISP-B adds 166 prefix-A to its list of allowed source addresses on the uplink from 167 the multihomed site, two-way communication may still fail. If the 168 packet with source address in prefix-A was sent to ISP-B because the 169 uplink to ISP-A failed, then if ISP-B does not drop the packet and 170 the packet reaches its destination somewhere on the Internet, the 171 return packet will be sent back with a destination address in prefix- 172 A. The return packet will be routed over the Internet to ISP-A, but 173 it will not be delivered to the multihomed site because its link with 174 ISP-A has failed. Two-way communication would require some 175 arrangement for ISP-B to advertise prefix-A when the uplink to ISP-A 176 fails. 178 Note that the same may be true with a provider that does not 179 implement BCP 38, if his upstream provider does, or has no 180 corresponding route. The issue is not that the immediate provider 181 implements ingress filtering; it is that someone upstream does, or 182 lacks a route. 184 With IPv4, this problem is commonly solved by using [RFC1918] private 185 address space within the multi-homed site and Network Address 186 Translation (NAT) or Network Address/Port Translation (NAPT) on the 187 uplinks to the ISPs. However, one of the goals of IPv6 is to 188 eliminate the need for and the use of NAT or NAPT. Therefore, 189 requiring the use of NAT or NAPT for an enterprise site to multihome 190 with provider-assigned addresses is not an attractive solution. 192 [RFC6296] describes a translation solution specifically tailored to 193 meet the requirements of multi-homing with provider-assigned IPv6 194 addresses. With the IPv6-to-IPv6 Network Prefix Translation (NPTv6) 195 solution, within the site an enterprise can use Unique Local 196 Addresses [RFC4193] or the prefix assigned by one of the ISPs. As 197 traffic leaves the site on an uplink to an ISP, the source address 198 gets translated to an address within the prefix assigned by the ISP 199 on that uplink in a predictable and reversible manner. [RFC6296] is 200 currently classified as Experimental, and it has been implemented by 201 several vendors. See Section 5.2, for more discussion of NPTv6. 203 This document defines routing requirements for enterprise multihoming 204 using provider-assigned IPv6 addresses. We have made no attempt to 205 write these requirements in a manner that is agnostic to potential 206 solutions. Instead, this document focuses on the following general 207 class of solutions. 209 Each host at the enterprise has multiple addresses, at least one from 210 each ISP-assigned prefix. Each host, as discussed in Section 4.1 and 211 [RFC6724], is responsible for choosing the source address applied to 212 each packet it sends. A host SHOULD be able respond dynamically to 213 the failure of an uplink to a given ISP by no longer sending packets 214 with the source address corresponding to that ISP. Potential 215 mechanisms for the communication of changes in the network to the 216 host are Neighbor Discovery Router Advertisements, DHCPv6, and 217 ICMPv6. 219 The routers in the enterprise network are responsible for ensuring 220 that packets are delivered to the "correct" ISP uplink based on 221 source address. This requires that at least some routers in the site 222 network are able to take into account the source address of a packet 223 when deciding how to route it. That is, some routers must be capable 224 of some form of Source Address Dependent Routing (SADR), if only as 225 described in [RFC3704]. At a minimum, the routers connected to the 226 ISP uplinks (the site exit routers or SERs) must be capable of Source 227 Address Dependent Routing. Expanding the connected domain of routers 228 capable of SADR from the site exit routers deeper into the site 229 network will generally result in more efficient routing of traffic 230 with external destinations. 232 The document first looks in more detail at the enterprise networking 233 environments in which this solution is expected to operate. It then 234 discusses existing and proposed mechanisms for hosts to select the 235 source address applied to packets. Finally, it looks at the 236 requirements for routing that are needed to support these enterprise 237 network scenarios and the mechanisms by which hosts are expected to 238 select source addresses dynamically based on network state. 240 2. Enterprise Multihoming Requirements 242 2.1. Simple ISP Connectivity with Connected SERs 244 We start by looking at a scenario in which a site has connections to 245 two ISPs, as shown in Figure 1. The site is assigned the prefix 246 2001:db8:0:a000::/52 by ISP-A and prefix 2001:db8:0:b000::/52 by ISP- 247 B. We consider three hosts in the site. H31 and H32 are on a LAN 248 that has been assigned subnets 2001:db8:0:a010::/64 and 249 2001:db8:0:b010::/64. H31 has been assigned the addresses 250 2001:db8:0:a010::31 and 2001:db8:0:b010::31. H32 has been assigned 251 2001:db8:0:a010::32 and 2001:db8:0:b010::32. H41 is on a different 252 subnet that has been assigned 2001:db8:0:a020::/64 and 253 2001:db8:0:b020::/64. 255 2001:db8:0:1234::101 H101 256 | 257 | 258 2001:db8:0:a010::31 -------- 259 2001:db8:0:b010::31 ,-----. / \ 260 +--+ +--+ +----+ ,' `. : : 261 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 262 H31--+ +--+ +--+ | +----+ `. ,' : : 263 | | `-----' : Internet : 264 | | : : 265 | | : : 266 | | : : 267 | | ,-----. : : 268 H32--+ +--+ | +----+ ,' `. : : 269 +---|R2|----------+---|SERb|-+ ISP-B +--+-- : 270 +--+ | +----+ `. ,' : : 271 | `-----' : : 272 | : : 273 +--+ +--+ +--+ \ / 274 H41------|R3|--|R5|--|R6| -------- 275 +--+ +--+ +--+ 277 2001:db8:0:a020::41 278 2001:db8:0:b020::41 280 Figure 1: Simple ISP Connectivity With Connected SERs 282 We refer to a router that connects the site to an ISP as a site edge 283 router(SER). Several other routers provide connectivity among the 284 internal hosts (H31, H32, and H41), as well as connecting the 285 internal hosts to the Internet through SERa and SERb. In this 286 example SERa and SERb share a direct connection to each other. In 287 Section 2.2, we consider a scenario where this is not the case. 289 For the moment, we assume that the hosts are able to make good 290 choices about which source addresses through some mechanism that 291 doesn't involve the routers in the site network. Here, we focus on 292 primary task of the routed site network, which is to get packets 293 efficiently to their destinations, while sending a packet to the ISP 294 that assigned the prefix that matches the source address of the 295 packet. In Section 4, we examine what role the routed network may 296 play in helping hosts make good choices about source addresses for 297 packets. 299 With this solution, routers will need form of Source Address 300 Dependent Routing, which will be new functionality. It would be 301 useful if an enterprise site does not need to upgrade all routers to 302 support the new SADR functionality in order to support PA multi- 303 homing. We consider if this is possible and what are the tradeoffs 304 of not having all routers in the site support SADR functionality. 306 In the topology in Figure 1, it is possible to support PA multihoming 307 with only SERa and SERb being capable of SADR. The other routers can 308 continue to forward based only on destination address, and exchange 309 routes that only consider destination address. In this scenario, 310 SERa and SERb communicate source-scoped routing information across 311 their shared connection. When SERa receives a packet with a source 312 address matching prefix 2001:db8:0:b000::/52 , it forwards the packet 313 to SERb, which forwards it on the uplink to ISP-B. The analogous 314 behaviour holds for traffic that SERb receives with a source address 315 matching prefix 2001:db8:0:a000::/52. 317 In Figure 1, when only SERa and SERb are capable of source address 318 dependent routing, PA multi-homing will work. However, the paths 319 over which the packets are sent will generally not be the shortest 320 paths. The forwarding paths will generally be more efficient as more 321 routers are capable of SADR. For example, if R4, R2, and R6 are 322 upgraded to support SADR, then can exchange source-scoped routes with 323 SERa and SERb. They will then know to send traffic with a source 324 address matching prefix 2001:db8:0:b000::/52 directly to SERb, 325 without sending it to SERa first. 327 2.2. Simple ISP Connectivity Where SERs Are Not Directly Connected 329 In Figure 2, we modify the topology slightly by inserting R7, so that 330 SERa and SERb are no longer directly connected. With this topology, 331 it is not enough to just enable SADR routing on SERa and SERb to 332 support PA multi-homing. There are two solutions to ways to enable 333 PA multihoming in this topology. 335 2001:db8:0:1234::101 H101 336 | 337 | 338 2001:db8:0:a010::31 -------- 339 2001:db8:0:b010::31 ,-----. / \ 340 +--+ +--+ +----+ ,' `. : : 341 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 342 H31--+ +--+ +--+ | +----+ `. ,' : : 343 | | `-----' : Internet : 344 | +--+ : : 345 | |R7| : : 346 | +--+ : : 347 | | ,-----. : : 348 H32--+ +--+ | +----+ ,' `. : : 349 +---|R2|----------+---|SERb|-+ ISP-B +--+-- : 350 +--+ | +----+ `. ,' : : 351 | `-----' : : 352 | : : 353 +--+ +--+ +--+ \ / 354 H41------|R3|--|R5|--|R6| -------- 355 +--+ +--+ +--+ | 356 | 357 2001:db8:0:a020::41 2001:db8:0:5678::501 H501 358 2001:db8:0:b020::41 360 Figure 2: Simple ISP Connectivity Where SERs Are Not Directly 361 Connected 363 One option is to effectively modify the topology by creating a 364 logical tunnel between SERa and SERb, using GRE for example. 365 Although SERa and SERb are not directly connected physically in this 366 topology, they can be directly connected logically by a tunnel. 368 The other option is to enable SADR functionality on R7. In this way, 369 R7 will exchange source-scoped routes with SERa and SERb, making the 370 three routers act as a single SADR domain. This illustrates the 371 basic principle that the minimum requirement for the routed site 372 network to support PA multi-homing is having all of the site exit 373 routers be part of a connected SADR domain. Extending the connected 374 SADR domain beyond that point can produce more efficient forwarding 375 paths. 377 2.3. Enterprise Network Operator Expectations 379 Before considering a more complex scenario, let's look in more detail 380 at the reasonably simple multihoming scenario in Figure 2 to 381 understand what can reasonably be expected from this solution. As a 382 general guiding principle, we assume an enterprise network operator 383 will expect a multihomed network to behave as close as to a single- 384 homed network as possible. So a solution that meets those 385 expectations where possible is a good thing. 387 For traffic between internal hosts and traffic from outside the site 388 to internal hosts, an enterprise network operator would expect there 389 to be no visible change in the path taken by this traffic, since this 390 traffic does not need to be routed in a way that depends on source 391 address. It is also reasonable to expect that internal hosts should 392 be able to communicate with each other using either of their source 393 addresses without restriction. For example, H31 should be able to 394 communicate with H41 using a packet with S=2001:db8:0:a010::31, 395 D=2001:db8:0:b010::41, regardless of the state of uplink to ISP-B. 397 These goals can be accomplished by having all of the routers in the 398 network continue to originate normal unscoped destination routes for 399 their connected networks. If we can arrange so that these unscoped 400 destination routes get used for forwarding this traffic, then we will 401 have accomplished the goal of keeping forwarding of traffic destined 402 for internal hosts, unaffected by the multihoming solution. 404 For traffic destined for external hosts, it is reasonable to expect 405 that traffic with an source address from the prefix assigned by ISP-A 406 to follow the path to that the traffic would follow if there is no 407 connection to ISP-B. This can be accomplished by having SERa 408 originate a source-scoped route of the form (S=2001:db8:0:a000::/52, 409 D=::/0) . If all of the routers in the site support SADR, then the 410 path of traffic exiting via ISP-A can match that expectation. If 411 some routers don't support SADR, then it is reasonable to expect that 412 the path for traffic exiting via ISP-A may be different within the 413 site. This is a tradeoff that the enterprise network operator may 414 decide to make. 416 It is important to understand how this multihoming solution behaves 417 when an uplink to one of the ISPs fails. To simplify this 418 discussion, we assume that all routers in the site support SADR. We 419 first start by looking at how the network operates when the uplinks 420 to both ISP-A and ISP-B are functioning properly. SERa originates a 421 source-scoped route of the form (S=2001:db8:0:a000::/52, D=::/0), and 422 SERb is originates a source-scoped route of the form 423 (S=2001:db8:0:b000::/52, D=::/0). These routes are distributed 424 through the routers in the site, and they establish within the 425 routers two set of forwarding paths for traffic leaving the site. 426 One set of forwarding paths is for packets with source address in 427 2001:db8:0:a000::/52. The other set of forwarding paths is for 428 packets with source address in 2001:db8:0:b000::/52. The normal 429 destination routes which are not scoped to these two source prefixes 430 play no role in the forwarding. Whether a packet exits the site via 431 SERa or via SERb is completely determined by the source address 432 applied to the packet by the host. So for example, when host H31 433 sends a packet to host H101 with (S=2001:db8:0:a010::31, 434 D=2001:db8:0:1234::101), the packet will only be sent out the link 435 from SERa to ISP-A. 437 Now consider what happens when the uplink from SERa to ISP-A fails. 438 The only way for the packets from H31 to reach H101 is for H31 to 439 start using the source address for ISP-B. H31 needs to send the 440 following packet: (S=2001:db8:0:b010::31, D=2001:db8:0:1234::101). 442 This behavior is very different from the behavior that occurs with 443 site multihoming using PI addresses or with PA addresses using NAT. 444 In these other multi-homing solutions, hosts do not need to react to 445 network failures several hops away in order to regain Internet 446 access. Instead, a host can be largely unaware of the failure of an 447 uplink to an ISP. When multihoming with PA addresses and NAT, 448 existing sessions generally need to be re-established after a failure 449 since the external host will receive packets from the internal host 450 with a new source address. However, new sessions can be established 451 without any action on the part of the hosts. 453 Another example where the behavior of this multihoming solution 454 differs significantly from that of multihoming with PI address or 455 with PA addresses using NAT is in the ability of the enterprise 456 network operator to route traffic over different ISPs based on 457 destination address. We still consider the fairly simple network of 458 Figure 2 and assume that uplinks to both ISPs are functioning. 459 Assume that the site is multihomed using PA addresses and NAT, and 460 that SERa and SERb each originate a normal destination route for 461 D=::/0, with the route origination dependent on the state of the 462 uplink to the respective ISP. 464 Now suppose it is observed that an important application running 465 between internal hosts and external host H101 experience much better 466 performance when the traffic passes through ISP-A (perhaps because 467 ISP-A provides lower latency to H101.) When multihoming this site 468 with PI addresses or with PA addresses and NAT, the enterprise 469 network operator can configure SERa to originate into the site 470 network a normal destination route for D=2001:db8:0:1234::/64 (the 471 destination prefix to reach H101) that depends on the state of the 472 uplink to ISP-A. When the link to ISP-A is functioning, the 473 destination route D=2001:db8:0:1234::/64 will be originated by SERa, 474 so traffic from all hosts will use ISP-A to reach H101 based on the 475 longest destination prefix match in the route lookup. 477 Implementing the same routing policy is more difficult with the PA 478 multihoming solution described in this document since it doesn't use 479 NAT. By design, the only way to control where a packet exits this 480 network is by setting the source address of the packet. Since the 481 network cannot modify the source address without NAT, the host must 482 set it. To implement this routing policy, each host needs to use the 483 source address from the prefix assigned by ISP-A to send traffic 484 destined for H101. Mechanisms have been proposed to allow hosts to 485 choose the source address for packets in a fine grained manner. We 486 will discuss these proposals in Section 4. However, interacting with 487 host operating systems in some manner to ensure a particular source 488 address is chosen for a particular destination prefix is not what an 489 enterprise network administrator would expect to have to do to 490 implement this routing policy. 492 2.4. More complex ISP connectivity 494 The previous sections considered two variations of a simple 495 multihoming scenario where the site is connected to two ISPs offering 496 only Internet connectivity. It is likely that many actual enterprise 497 multihoming scenarios will be similar to this simple example. 498 However, there are more complex multihoming scenarios that we would 499 like this solution to address as well. 501 It is fairly common for an ISP to offer a service in addition to 502 Internet access over the same uplink. Two variation of this are 503 reflected in Figure 3. In addition to Internet access, ISP-A offers 504 a service which requires the site to access host H51 at 505 2001:db8:0:5555::51. The site has a single physical and logical 506 connection with ISP-A, and ISP-A only allows access to H51 over that 507 connection. So when H32 needs to access the service at H51 it needs 508 to send packets with (S=2001:db8:0:a010::32, D=2001:db8:0:5555::51) 509 and those packets need to be forward out the link from SERa to ISP-A. 511 2001:db8:0:1234::101 H101 512 | 513 | 514 2001:db8:0:a010::31 -------- 515 2001:db8:0:b010::31 ,-----. / \ 516 +--+ +--+ +----+ ,' `. : : 517 +---|R1|---|R4|---+---|SERa|-+ ISP-A +--+-- : 518 H31--+ +--+ +--+ | +----+ `. ,' : : 519 | | `-----' : Internet : 520 | | | : : 521 | | H51 : : 522 | | 2001:db8:0:5555::51 : : 523 | +--+ : : 524 | |R7| : : 525 | +--+ : : 526 | | : : 527 | | ,-----. : : 528 H32--+ +--+ | +-----+ ,' `. : : 529 +---|R2|-----+----+--|SERb1|-+ ISP-B +--+-- : 530 +--+ | +-----+ `. ,' : : 531 +--+ `--|--' : : 532 2001:db8:0:a010::32 |R8| | \ / 533 +--+ ,--|--. -------- 534 | +-----+ ,' `. | 535 +-------|SERb2|-+ ISP-B | | 536 | +-----+ `. ,' H501 537 | `-----' 2001:db8:0:5678 538 | | ::501 539 +--+ +--+ H61 540 H41------|R3|--|R5| 2001:db8:0:6666::61 541 +--+ +--+ 543 2001:db8:0:a020::41 544 2001:db8:0:b020::41 546 Figure 3: Internet access and services offered by ISP-A and ISP-B 548 ISP-B illustrates a variation on this scenario. In addition to 549 Internet access, ISP-B also offers a service which requires the site 550 to access host H61. The site has two connections to two different 551 parts of ISP-B (shown as SERb1 and SERb2 in Figure 3). ISP-B expects 552 Internet traffic to use the uplink from SERb1, while it expects it 553 expects traffic destined for the service at H61 to use the uplink 554 from SERb2. For either uplink, ISP-B expects the ingress traffic to 555 have a source address matching the prefix it assigned to the site, 556 2001:db8:0:b000::/52. 558 As discussed before, we rely completely on the internal host to set 559 the source address of the packet properly. In the case of a packet 560 sent by H31 to access the service in ISP-B at H61, we expect the 561 packet to have the following addresses: (S=2001:db8:0:b010::31, 562 D=2001:db8:0:6666::61). The routed network has two potential ways of 563 distributing routes so that this packet exits the site on the uplink 564 at SERb2. 566 We could just rely on normal destination routes, without using 567 source-prefix scoped routes. If we have SERb2 originate a normal 568 unscoped destination route for D=2001:db8:0:6666::/64, the packets 569 from H31 to H61 will exit the site at SERb2 as desired. We should 570 not have to worry about SERa needing to originate the same route, 571 because ISP-B should choose a globally unique prefix for the service 572 at H61. 574 The alternative is to have SERb2 originate a source-prefix-scoped 575 destination route of the form (S=2001:db8:0:b000::/52, 576 D=2001:db8:0:6666::/64). From a forwarding point of view, the use of 577 the source-prefix-scoped destination route would result in traffic 578 with source addresses corresponding only to ISP-B being sent to 579 SERb2. Instead, the use of the unscoped destination route would 580 result in traffic with source addresses corresponding to ISP-A and 581 ISP-B being sent to SERb2, as long as the destination address matches 582 the destination prefix. It seems like either forwarding behavior 583 would be acceptable. 585 However, from the point of view of the enterprise network 586 administrator trying to configure, maintain, and trouble-shoot this 587 multihoming solution, it seems much clearer to have SERb2 originate 588 the source-prefix-scoped destination route correspond to the service 589 offered by ISP-B. In this way, all of the traffic leaving the site 590 is determined by the source-prefix-scoped routes, and all of the 591 traffic within the site or arriving from external hosts is determined 592 by the unscoped destination routes. Therefore, for this multihoming 593 solution we choose to originate source-prefix-scoped routes for all 594 traffic leaving the site. 596 2.5. ISPs and Provider-Assigned Prefixes 598 While we expect that most site multihoming involves connecting to 599 only two ISPs, this solution allows for connections to an arbitrary 600 number of ISPs to be supported. However, when evaluating scalable 601 implementations of the solution, it would be reasonable to assume 602 that the maximum number of ISPs that a site would connect to is five. 604 It is also useful to note that the prefixes assigned to the site by 605 different ISPs will not overlap. This must be the case , since the 606 provider-assigned addresses have to be globally unique. 608 2.6. Simplified Topologies 610 The topologies of many enterprise sites using this multihoming 611 solution may in practice be simpler than the examples that we have 612 used. The topology in Figure 1 could be further simplified by having 613 all hosts directly connected to the LAN connecting the two site exit 614 routers, SERa and SERb. The topology could also be simplified by 615 having the uplinks to ISP-A and ISP-B both connected to the same site 616 exit router. However, it is the aim of this draft to provide a 617 solution that applies to a broad a range of enterprise site network 618 topologies, so this draft focuses on providing a solution to the more 619 general case. The simplified cases will also be supported by this 620 solution, and there may even be optimizations that can be made for 621 simplified cases. This solution however needs to support more 622 complex topologies. 624 We are starting with the basic assumption that enterprise site 625 networks can be quite complex from a routing perspective. However, 626 even a complex site network can be multihomed to different ISPs with 627 PA addresses using IPv4 and NAT. It is not reasonable to expect an 628 enterprise network operator to change the routing topology of the 629 site in order to deploy IPv6. 631 3. Generating Source-Prefix-Scoped Forwarding Tables 633 So far we have described in general terms how the routers in this 634 solution that are capable of Source Address Dependent Routing will 635 forward traffic using both normal unscoped destination routes and 636 source-prefix-scoped destination routes. Here we give a precise 637 method for generating a source-prefix-scoped forwarding table on a 638 router that supports SADR. 640 1. Compute the next-hops for the source-prefix-scoped destination 641 prefixes using only routers in the connected SADR domain. These 642 are the initial source-prefix-scoped forwarding table entries. 644 2. Compute the next-hops for the unscoped destination prefixes using 645 all routers in the IGP. This is the unscoped forwarding table. 647 3. Augment each source-prefix-scoped forwarding table with unscoped 648 forwarding table entries based on the following rule. If the 649 destination prefix of the unscoped forwarding entry exactly 650 matches the destination prefix of an existing source-prefix- 651 scoped forwarding entry (including destination prefix length), 652 then do not add the unscoped forwarding entry. If the 653 destination prefix does NOT match an existing entry, then add the 654 entry to the source-prefix-scoped forwarding table. 656 The forward tables produced by this process are used in the following 657 way to forward packets. 659 1. If the source address of the packet matches one of the source 660 prefixes, then look up the destination address of the packet in 661 the corresponding source-prefix-scoped forwarding table to 662 determine the next-hop for the packet. 664 2. If the source address of the packet does NOT match one of the 665 source prefixes, then look up the destination address of the 666 packet in unscoped forwarding table to determine the next-hop for 667 the packet. 669 The following example illustrates how this process is used to create 670 a forwarding table for each provider-assigned source prefix. We 671 consider the multihomed site network in Figure 3. Initially we 672 assume that all of the routers in the site network support SADR. 673 Figure 4 shows the routes that are originated by the routers in the 674 site network. 676 Routes originated by SERa: 677 (S=2001:db8:0:a000::/52, D=2001:db8:0:5555/64) 678 (S=2001:db8:0:a000::/52, D=::/0) 679 (D=2001:db8:0:5555::/64) 680 (D=::/0) 682 Routes originated by SERb1: 683 (S=2001:db8:0:b000::/52, D=::/0) 684 (D=::/0) 686 Routes originated by SERb2: 687 (S=2001:db8:0:b000::/52, D=2001:db8:0:6666::/64) 688 (D=2001:db8:0:6666::/64) 690 Routes originated by R1: 691 (D=2001:db8:0:a010::/64) 692 (D=2001:db8:0:b010::/64) 694 Routes originated by R2: 695 (D=2001:db8:0:a010::/64) 696 (D=2001:db8:0:b010::/64) 698 Routes originated by R3: 699 (D=2001:db8:0:a020::/64) 700 (D=2001:db8:0:b020::/64) 702 Figure 4: Routes Originated by Routers in the Site Network 704 Each SER originates destination routes which are scoped to the source 705 prefix assigned by the ISP that the SER connects to. Note that the 706 SERs also originate the corresponding unscoped destination route. 707 This is not needed when all of the routers in the site support SADR. 708 However, it is required when some routers do not support SADR. This 709 will be discussed in more detail later. 711 We focus on how R8 constructs its source-prefix-scoped forwarding 712 tables from these route advertisements. R8 computes the next hops 713 for destination routes which are scoped to the source prefix 714 2001:db8:0:a000::/52. The results are shown in the first table in 715 Figure 5. (In this example, the next hops are computed assuming that 716 all links have the same metric.) Then, R8 computes the next hops for 717 destination routes which are scoped to the source prefix 718 2001:db8:0:b000::/52. The results are shown in the second table in 719 Figure 5 . Finally, R8 computes the next hops for the unscoped 720 destination prefixes. The results are shown in the third table in 721 Figure 5. 723 forwarding entries scoped to 724 source prefix = 2001:db8:0:a000::/52 725 ============================================ 726 D=2001:db8:0:5555/64 NH=R7 727 D=::/0 NH=R7 729 forwarding entries scoped to 730 source prefix = 2001:db8:0:b000::/52 731 ============================================ 732 D=2001:db8:0:6666/64 NH=SERb2 733 D=::/0 NH=SERb1 735 unscoped forwarding entries 736 ============================================ 737 D=2001:db8:0:a010::/64 NH=R2 738 D=2001:db8:0:b010::/64 NH=R2 739 D=2001:db8:0:a020::/64 NH=R5 740 D=2001:db8:0:b020::/64 NH=R5 741 D=2001:db8:0:5555::/64 NH=R7 742 D=2001:db8:0:6666::/64 NH=SERb2 743 D=::/0 NH=SERb1 745 Figure 5: Forwarding Entries Computed at R8 747 The final step is for R8 to augment the source-prefix-scoped 748 forwarding entries with unscoped forwarding entries. If an unscoped 749 forwarding entry has the exact same destination prefix as an source- 750 prefix-scoped forwarding entry (including destination prefix length), 751 then the source-prefix-scoped forwarding entry wins. 753 As as an example of how the source scoped forwarding entries are 754 augmented with unscoped forwarding entries, we consider how the two 755 entries in the first table in Figure 5 (the table for source prefix = 756 2001:db8:0:a000::/52) are augmented with entries from the third table 757 in Figure 5 (the table of unscoped forwarding entries). The first 758 four unscoped forwarding entries (D=2001:db8:0:a010::/64, 759 D=2001:db8:0:b010::/64, D=2001:db8:0:a020::/64, and 760 D=2001:db8:0:b020::/64) are not an exact match for any of the 761 existing entries in the forwarding table for source prefix 762 2001:db8:0:a000::/52. Therefore, these four entries are added to the 763 final forwarding table for source prefix 2001:db8:0:a000::/52. The 764 result of adding these entries is reflected in first four entries the 765 first table in Figure 6. 767 The next unscoped forwarding table entry is for 768 D=2001:db8:0:5555::/64. This entry is an exact match for the 769 existing entry in the forwarding table for source prefix 770 2001:db8:0:a000::/52. Therefore, we do not replace the existing 771 entry with the entry from the unscoped forwarding table. This is 772 reflected in the fifth entry in the first table in Figure 6. (Note 773 that since both scoped and unscoped entries have R7 as the next hop, 774 the result of applying this rule is not visible.) 776 The next unscoped forwarding table entry is for 777 D=2001:db8:0:6666::/64. This entry is not an exact match for any 778 existing entries in the forwarding table for source prefix 779 2001:db8:0:a000::/52. Therefore, we add this entry. This is 780 reflected in the sixth entry in the first table in Figure 6. 782 The next unscoped forwarding table entry is for D=::/0. This entry 783 is an exact match for the existing entry in the forwarding table for 784 source prefix 2001:db8:0:a000::/52. Therefore, we do not overwrite 785 the existing source-prefix-scoped entry, as can be seen in the last 786 entry in the first table in Figure 6. 788 if source address matches 2001:db8:0:a000::/52 789 then use this forwarding table 790 ============================================ 791 D=2001:db8:0:a010::/64 NH=R2 792 D=2001:db8:0:b010::/64 NH=R2 793 D=2001:db8:0:a020::/64 NH=R5 794 D=2001:db8:0:b020::/64 NH=R5 795 D=2001:db8:0:5555::/64 NH=R7 796 D=2001:db8:0:6666::/64 NH=SERb2 797 D=::/0 NH=R7 799 else if source address matches 2001:db8:0:b000::/52 800 then use this forwarding table 801 ============================================ 802 D=2001:db8:0:a010::/64 NH=R2 803 D=2001:db8:0:b010::/64 NH=R2 804 D=2001:db8:0:a020::/64 NH=R5 805 D=2001:db8:0:b020::/64 NH=R5 806 D=2001:db8:0:5555::/64 NH=R7 807 D=2001:db8:0:6666::/64 NH=SERb2 808 D=::/0 NH=SERb1 810 else use this forwarding table 811 ============================================ 812 D=2001:db8:0:a010::/64 NH=R2 813 D=2001:db8:0:b010::/64 NH=R2 814 D=2001:db8:0:a020::/64 NH=R5 815 D=2001:db8:0:b020::/64 NH=R5 816 D=2001:db8:0:5555::/64 NH=R7 817 D=2001:db8:0:6666::/64 NH=SERb2 818 D=::/0 NH=SERb1 820 Figure 6: Complete Forwarding Tables Computed at R8 822 The forwarding tables produced by this process at R8 have the desired 823 properties. A packet with a source address in 2001:db8:0:a000::/52 824 will be forwarded based on the first table in Figure 6. If the 825 packet is destined for the Internet at large or the service at 826 D=2001:db8:0:5555/64, it will be sent to R7 in the direction of SERa. 827 If the packet is destined for an internal host, then the first four 828 entries will send it to R2 or R5 as expected. Note that if this 829 packet has a destination address corresponding to the service offered 830 by ISP-B (D=2001:db8:0:5555::/64), then it will get forwarded to 831 SERb2. It will be dropped by SERb2 or by ISP-B, since it the packet 832 has a source address that was not assigned by ISP-B. However, this 833 is expected behavior. In order to use the service offered by ISP-B, 834 the host needs to originate the packet with a source address assigned 835 by ISP-B. 837 In this example, a packet with a source address that doesn't match 838 2001:db8:0:a000::/52 or 2001:db8:0:b000::/52 must have originated 839 from an external host. Such a packet will use the unscoped 840 forwarding table (the last table in Figure 6). These packets will 841 flow exactly as they would in absence of multihoming. 843 We can also modify this example to illustrate how it supports 844 deployments where not all routers in the site support SADR. 845 Continuing with the topology shown in Figure 3, suppose that R3 and 846 R5 do not support SADR. Instead they are only capable of 847 understanding unscoped route advertisements. The SADR routers in the 848 network will still originate the routes shown in Figure 4. However, 849 R3 and R5 will only understand the unscoped routes as shown in 850 Figure 7. 852 Routes originated by SERa: 853 (D=2001:db8:0:5555::/64) 854 (D=::/0) 856 Routes originated by SERb1: 857 (D=::/0) 859 Routes originated by SERb2: 860 (D=2001:db8:0:6666::/64) 862 Routes originated by R1: 863 (D=2001:db8:0:a010::/64) 864 (D=2001:db8:0:b010::/64) 866 Routes originated by R2: 867 (D=2001:db8:0:a010::/64) 868 (D=2001:db8:0:b010::/64) 870 Routes originated by R3: 871 (D=2001:db8:0:a020::/64) 872 (D=2001:db8:0:b020::/64) 874 Figure 7: Routes Advertisements Understood by Routers that do no 875 Support SADR 877 With these unscoped route advertisements, R5 will produce the 878 forwarding table shown in Figure 8. 880 forwarding table 881 ============================================ 882 D=2001:db8:0:a010::/64 NH=R8 883 D=2001:db8:0:b010::/64 NH=R8 884 D=2001:db8:0:a020::/64 NH=R3 885 D=2001:db8:0:b020::/64 NH=R3 886 D=2001:db8:0:5555::/64 NH=R8 887 D=2001:db8:0:6666::/64 NH=SERb2 888 D=::/0 NH=R8 890 Figure 8: Forwarding Table For R5, Which Doesn't Understand Source- 891 Prefix-Scoped Routes 893 Any traffic that needs to exit the site will eventually hit a SADR- 894 capable router. Once that traffic enters the SADR-capable domain, 895 then it will not leave that domain until it exits the site. This 896 property is required in order to guarantee that there will not be 897 routing loops involving SADR-capable and non-SADR-capable routers. 899 Note that the mechanism described here for converting source-prefix- 900 scoped destination prefix routing advertisements into forwarding 901 state is somewhat different from that proposed in 902 [I-D.ietf-rtgwg-dst-src-routing]. The method described in this 903 document is intended to be easy to understand for network enterprise 904 operators while at the same time being functionally correct. Another 905 difference is that the method in this document assumes that source 906 prefix will not overlap. Other differences between the two 907 approaches still need to be understood and reconciled. 909 An interesting side-effect of deploying SADR is if all routers in a 910 given network support SADR and have a scoped forwarding table, then 911 the unscoped forwarding table can be eliminated which ensures that 912 packets with legitimate source addresses only can leave the network 913 (as there are no scoped forwarding tables for spoofed/bogon source 914 addresses). It would prevent accidental leaks of ULA/reserved/link- 915 local sources to the Internet as well as ensures that no spoofing is 916 possible from the SADR-enabled network. 918 4. Mechanisms For Hosts To Choose Good Source Addresses In A Multihomed 919 Site 921 Until this point, we have made the assumption that hosts are able to 922 choose the correct source address using some unspecified mechanism. 923 This has allowed us to just focus on what the routers in a multihomed 924 site network need to do in order to forward packets to the correct 925 ISP based on source address. Now we look at possible mechanisms for 926 hosts to choose the correct source address. We also look at what 927 role, if any, the routers may play in providing information that 928 helps hosts to choose source addresses. 930 Any host that needs to be able to send traffic using the uplinks to a 931 given ISP is expected to be configured with an address from the 932 prefix assigned by that ISP. The host will control which ISP is used 933 for its traffic by selecting one of the addresses configured on the 934 host as the source address for outgoing traffic. It is the 935 responsibility of the site network to ensure that a packet with the 936 source address from an ISP is not sent on an uplink to that ISP. 938 If all of the ISP uplinks are working, the choice of source address 939 by the host may be driven by the desire to load share across ISP 940 uplinks, or it may be driven by the desire to take advantage of 941 certain properties of a particular uplink or ISP. If any of the ISP 942 uplinks is not working, then the choice of source address by the host 943 can determine if packets get dropped. 945 How a host should make good decisions about source address selection 946 in a multihomed site is not a solved problem. We do not attempt to 947 solve this problem in this document. Instead we discuss the current 948 state of affairs with respect to standardized solutions and 949 implementation of those solutions. We also look at proposed 950 solutions for this problem. 952 An external host initiating communication with a host internal to a 953 PA multihomed site will need to know multiple addresses for that host 954 in order to communicate with it using different ISPs to the 955 multihomed site. These addresses are typically learned through DNS. 956 (For simplicity, we assume that the external host is single-homed.) 957 The external host chooses the ISP that will be used at the remote 958 multihomed site by setting the destination address on the packets it 959 transmits. For a sessions originated from an external host to an 960 internal host, the choice of source address used by the internal host 961 is simple. The internal host has no choice but to use the 962 destination address in the received packet as the source address of 963 the transmitted packet. 965 For a session originated by a host internal to the multi-homed site, 966 the decision of what source address to select is more complicated. 967 We consider three main methods for hosts to get information about the 968 network. The two proactive methods are Neighbor Discovery Router 969 Advertisements and DHCPv6. The one reactive method we consider is 970 ICMPv6. Note that we are explicitly excluding the possibility of 971 having hosts participate in or even listen directly to routing 972 protocol advertisements. 974 First we look at how a host is currently expected to select the 975 source and destination address with which it sends a packet. 977 4.1. Source Address Selection Algorithm on Hosts 979 [RFC6724] defines the algorithms that hosts are expected to use to 980 select source and destination addresses for packets. It defines an 981 algorithm for selecting a source address and a separate algorithm for 982 selecting a destination address. Both of these algorithms depend on 983 a policy table. [RFC6724] defines a default policy which produces 984 certain behavior. 986 The rules in the two algorithms in [RFC6724] depend on many different 987 properties of addresses. While these are needed for understanding 988 how a host should choose addresses in an arbitrary environment, most 989 of the rules are not relevant for understanding how a host should 990 choose among multiple source addresses in mulitihomed envinronment 991 when sending a packet to a remote host. Returning to the example in 992 Figure 3, we look at what the default algorithms in [RFC6724] say 993 about the source address that internal host H31 should use to send 994 traffic to external host H101, somewhere on the Internet. Let's look 995 at what rules in [RFC6724] are actually used by H31 in this case. 997 There is no choice to be made with respect to destination address. 998 H31 needs to send a packet with D=2001:db8:0:1234::101 in order to 999 reach H101. So H31 have to choose between using 1000 S=2001:db8:0:a010::31 or S=2001:db8:0:b010::31 as the source address 1001 for this packet. We go through the rules for source address 1002 selection in Section 5 of [RFC6724]. Rule 1 (Prefer same address) is 1003 not useful to break the tie between source addresses, because neither 1004 the candidate source addresses equals the destination address. Rule 1005 2 (Prefer appropriate scope) is also not used in this scenario, 1006 because both source addresses and the destination address have global 1007 scope. 1009 Rule 3 (Avoid deprecated addresses) applies to an address that has 1010 been autoconfigured by a host using stateless address 1011 autoconfiguration as defined in [RFC4862]. An address autoconfigured 1012 by a host has a preferred lifetime and a valid lifetime. The address 1013 is preferred until the preferred lifetime expires, after which it 1014 becomes deprecated. A deprecated address can still be used, but it 1015 is better to use a preferred address. When the valid lifetime 1016 expires, the address cannot be used at all. The preferred and valid 1017 lifetimes for an autoconfigured address are set based on the 1018 corresponding lifetimes in the Prefix Information Option in Neighbor 1019 Discovery Router Advertisements. So a possible tool to control 1020 source address selection in this scenario would be to a host to make 1021 an address deprecated by having routers on that link, R1 and R2 in 1022 Figure 3, send Prefix Information Option messages with the preferred 1023 lifetime for the source prefix to be discouraged (or prohibited) set 1024 to zero. This is a rather blunt tool, because it discourages or 1025 prohibits the use of that source prefix for all destinations. 1026 However, it may be useful in some scenarios. 1028 Rule 4 (Avoid home addresses) does not apply here because we are not 1029 considering Mobile IP. 1031 Rule 5 (Prefer outgoing interface) is not useful in this scenario, 1032 because both source addresses are assigned to the same interface. 1034 Rule 5.5 (Prefer addresses in a prefix advertised by the next-hop) is 1035 not useful in the scenario when both R1 and R2 will advertise both 1036 source prefixes. However potentially this rule may allow a host to 1037 select the correct source prefix by selecting a next-hop. The most 1038 obvious way would be to make R1 to advertise itself as a default 1039 router and send PIO for 2001:db8:0:a010::/64, while R2 is advertising 1040 itself as a default router and sending PIO for 2001:db8:0:b010::/64. 1041 We'll discuss later how Rule 5.5 can be used to influence a source 1042 address selection in single-router topologies (e.g. when H41 is 1043 sending traffic using R3 as a default gateway). 1045 Rule 6 (Prefer matching label) refers to the Label value determined 1046 for each source and destination prefix as a result of applying the 1047 policy table to the prefix. With the default policy table defined in 1048 Section 2.1 of [RFC6724], Label(2001:db8:0:a010::31) = 5, 1049 Label(2001:db8:0:b010::31) = 5, and Label(2001:db8:0:1234::101) = 5. 1050 So with the default policy, Rule 6 does not break the tie. However, 1051 the algorithms in [RFC6724] are defined in such as way that non- 1052 default address selection policy tables can be used. [RFC7078] 1053 defines a way to distribute a non-default address selection policy 1054 table to hosts using DHCPv6. So even though the application of rule 1055 6 to this scenario using the default policy table is not useful, rule 1056 6 may still be a useful tool. 1058 Rule 7 (Prefer temporary addresses) has to do with the technique 1059 described in [RFC4941] to periodically randomize the interface 1060 portion of an IPv6 address that has been generated using stateless 1061 address autoconfiguration. In general, if H31 were using this 1062 technique, it would use it for both source addresses, for example 1063 creating temporary addresses 2001:db8:0:a010:2839:9938:ab58:830f and 1064 2001:db8:0:b010:4838:f483:8384:3208, in addition to 1065 2001:db8:0:a010::31 and 2001:db8:0:b010::31. So this rule would 1066 prefer the two temporary addresses, but it would not break the tie 1067 between the two source prefixes from ISP-A and ISP-B. 1069 Rule 8 (Use longest matching prefix) dictates that between two 1070 candidate source addresses the one which has longest common prefix 1071 length with the destination address. For example, if H31 were 1072 selecting the source address for sending packets to H101, this rule 1073 would not be a tie breaker as for both candidate source addresses 1074 2001:db8:0:a101::31 and 2001:db8:0:b101::31 the common prefix length 1075 with the destination is 48. However if H31 were selecting the source 1076 address for sending packets H41 address 2001:db8:0:a020::41, then 1077 this rule would result in using 2001:db8:0:a101::31 as a source 1078 (2001:db8:0:a101::31 and 2001:db8:0:a020::41 share the common prefix 1079 2001:db8:0:a000::/58, while for `2001:db8:0:b101::31 and 1080 2001:db8:0:a020::41 the common prefix is 2001:db8:0:a000::/51). 1081 Therefore rule 8 might be useful for selecting the correct source 1082 address in some but not all scenarios (for example if ISP-B services 1083 belong to 2001:db8:0:b000::/59 then H31 would always use 1084 2001:db8:0:b010::31 to access those destinations). 1086 So we can see that of the 8 source selection address rules from 1087 [RFC6724], five actually apply to our basic site multihoming 1088 scenario. The rules that are relevant to this scenario are 1089 summarized below. 1091 o Rule 3: Avoid deprecated addresses. 1093 o Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. 1095 o Rule 6: Prefer matching label. 1097 o Rule 8: Prefer longest matching prefix. 1099 The two methods that we discuss for controlling the source address 1100 selection through the four relevant rules above are SLAAC Router 1101 Advertisement messages and DHCPv6. 1103 We also consider a possible role for ICMPv6 for getting traffic- 1104 driven feedback from the network. With the source address selection 1105 algorithm discussed above, the goal is to choose the correct source 1106 address on the first try, before any traffic is sent. However, 1107 another strategy is to choose a source address, send the packet, get 1108 feedback from the network about whether or not the source address is 1109 correct, and try another source address if it is not. 1111 We consider four scenarios where a host needs to select the correct 1112 source address. The first is when both uplinks are working. The 1113 second is when one uplink has failed. The third one is a situation 1114 when one failed uplink has recovered. The last one is failure of 1115 both (all) uplinks. 1117 4.2. Selecting Source Address When Both Uplinks Are Working 1119 Again we return to the topology in Figure 3. Suppose that the site 1120 administrator wants to implement a policy by which all hosts need to 1121 use ISP-A to reach H01 at D=2001:db8:0:1234::101. So for example, 1122 H31 needs to select S=2001:db8:0:a010::31. 1124 4.2.1. Distributing Address Selection Policy Table with DHCPv6 1126 This policy can be implemented by using DHCPv6 to distribute an 1127 address selection policy table that assigns the same label to 1128 destination address that match 2001:db8:0:1234::/64 as it does to 1129 source addresses that match 2001:db8:0:a000::/52. The following two 1130 entries accomplish this. 1132 Prefix Precedence Label 1133 2001:db8:0:1234::/64 50 33 1134 2001:db8:0:a000::/52 50 33 1136 Figure 9: Policy table entries to implement a routing policy 1138 This requires that the hosts implement [RFC6724], the basic source 1139 and destination address framework, along with [RFC7078], the DHCPv6 1140 extension for distributing a non-default policy table. Note that it 1141 does NOT require that the hosts use DHCPv6 for address assignment. 1142 The hosts could still use stateless address autoconfiguration for 1143 address configuration, while using DHCPv6 only for policy table 1144 distribution (see [RFC3736]). However this method has a number of 1145 disadvantages: 1147 o DHCPv6 support is not a mandatory requirement for IPv6 hosts, so 1148 this method might not work for all devices. 1150 o Network administrators are required to explicitly configure the 1151 desired network access policies on DHCPv6 servers. 1153 4.2.2. Controlling Source Address Selection With Router Advertisements 1155 Neighbor Discovery currently has two mechanisms to communicate prefix 1156 information to hosts. The base specification for Neighbor Discovery 1157 (see [RFC4861]) defines the Prefix Information Option (PIO) in the 1158 Router Advertisement (RA) message. When a host receives a PIO with 1159 the A-flag set, it can use the prefix in the PIO as source prefix 1160 from which it assigns itself an IP address using stateless address 1161 autoconfiguration (SLAAC) procedures described in [RFC4862]. In the 1162 example of Figure 3, if the site network is using SLAAC, we would 1163 expect both R1 and R2 to send RA messages with PIOs for both source 1164 prefixes 2001:db8:0:a010::/64 and 2001:db8:0:b010::/64 with the 1165 A-flag set. H31 would then use the SLAAC procedure to configure 1166 itself with the 2001:db8:0:a010::31 and 2001:db8:0:b010::31. 1168 Whereas a host learns about source prefixes from PIO messages, hosts 1169 can learn about a destination prefix from a Router Advertisement 1170 containing Route Information Option (RIO), as specified in [RFC4191]. 1171 The destination prefixes in RIOs are intended to allow a host to 1172 choose the router that it uses as its first hop to reach a particular 1173 destination prefix. 1175 As currently standardized, neither PIO nor RIO options contained in 1176 Neighbor Discovery Router Advertisements can communicate the 1177 information needed to implement the desired routing policy. PIO's 1178 communicate source prefixes, and RIO communicate destination 1179 prefixes. However, there is currently no standardized way to 1180 directly associate a particular destination prefix with a particular 1181 source prefix. 1183 [I-D.pfister-6man-sadr-ra] proposes a Source Address Dependent Route 1184 Information option for Neighbor Discovery Router Advertisements which 1185 would associate a source prefix and with a destination prefix. The 1186 details of [I-D.pfister-6man-sadr-ra] might need tweaking to address 1187 this use case. However, in order to be able to use Neighbor 1188 Discovery Router Advertisements to implement this routing policy, an 1189 extension that allows a R1 and R2 to explicitly communicate to H31 an 1190 association between S=2001:db8:0:a000::/52 D=2001:db8:0:1234::/64 1191 would be needed. 1193 However the Rule 5.5 of the source address selection (discussed 1194 above) together with default router preference (specified in 1195 [RFC4191]) and RIO can be used to influence a source address 1196 selection on a host as described below. Let's look at source address 1197 selection on the host H41. It receives RAs from R3 with PIOs for 1198 2001:db8:0:a020::/64 and 2001:db8:0:b020::/64. At that point all 1199 traffic would use the same next-hop (R3 link-local address) so Rule 1200 5.5 does not apply. Now let's assume that R3 supports SADR and has 1201 two scoped forwarding tables, one scoped to S=2001:db8:0:a000::/52 1202 and another scoped to S=2001:db8:0:b000::/52. If R3 generates two 1203 different link-local addresses for its interface facing H41 (one for 1204 each scoped forwarding table, LLA_A and LLA_B) and starts sending two 1205 different RAs: one is sent from LLA_A and includes PIO for 1206 2001:db8:0:a020::/64, another us sent from LLA_B and includes PIO for 1207 2001:db8:0:b020::/64. Now it is possible to influence H41 source 1208 address selection for destinations which follow the default route by 1209 setting default router preference in RAs. If it is desired that H41 1210 reaches H101 (or any destinations in the Internet) via ISP-A, then 1211 RAs sent from LLA_A should have default router preference set to 01 1212 (high priority), while RAs sent from LLA_B should have preference set 1213 to 11 (low). Then LLA_A would be chosen as a next-hop for H101 and 1214 therefore (as per rule 5.5) 2001:db8:0:a020::41 would be selected as 1215 the source address. If, at the same time, it is desired that H61 is 1216 accessible via ISP-B then R3 should include a RIO for 1217 2001:db8:0:6666::/64 to its RA sent from LLA_B. H41 would chose 1218 LLA_B as a next-hop for all traffic to H61 and then as per Rule 5.5, 1219 2001:db8:0:b020::41 would be selected as a source address. 1221 If in the above mentioned scenario it is desirable that all Internet 1222 traffic leaves the network via ISP-A and the link to ISP-B is used 1223 for accessing ISP-B services only (not as ISP-A link backup), then 1224 RAs sent by R3 from LLA_B should have Router Lifetime set to 0 and 1225 should include RIOs for ISP-B address space. It would instruct H41 1226 to use LLA_A for all Internet traffic but use LLA_B as a next-hop 1227 while sending traffic to ISP-B addresses. 1229 The proposed solution relies on SADR support by first-hop routers as 1230 well as SERs. 1232 4.2.3. Controlling Source Address Selection With ICMPv6 1234 We now discuss how one might use ICMPv6 to implement the routing 1235 policy to send traffic destined for H101 out the uplink to ISP-A, 1236 even when uplinks to both ISPs are working. If H31 started sending 1237 traffic to H101 with S=2001:db8:0:b010::31 and 1238 D=2001:db8:0:1234::101, it would be routed through SER-b1 and out the 1239 uplink to ISP-B. SERb1 could recognize that this is traffic is not 1240 following the desired routing policy and react by sending an ICMPv6 1241 message back to H31. 1243 In this example, we could arrange things so that SERb1 drops the 1244 packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and 1245 then sends to H31 an ICMPv6 Destination Unreachable message with Code 1246 5 (Source address failed ingress/egress policy). When H31 receives 1247 this packet, it would then be expected to try another source address 1248 to reach the destination. In this example, H31 would then send a 1249 packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which 1250 will reach SERa and be forwarded out the uplink to ISP-A. 1252 However, we would also want it to be the case that SERb1 does not 1253 enforce this routing policy when the uplink from SERa to ISP-A has 1254 failed. This could be accomplished by having SERa originate a 1255 source-prefix-scoped route for (S=2001:db8:0:a000::/52, 1256 D=2001:db8:0:1234::/64) and have SERb1 monitor the presence of that 1257 route. If that route is not present (because SERa has stopped 1258 originating it), then SERb1 will not enforce the routing policy, and 1259 it will forward packets with S=2001:db8:0:b010::31 and 1260 D=2001:db8:0:1234::101 out its uplink to ISP-B. 1262 We can also use this source-prefix-scoped route originated by SERa to 1263 communicate the desired routing policy to SERb1. We can define an 1264 EXCLUSIVE flag to be advertised together with the IGP route for 1265 (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64). This would allow 1266 SERa to communicate to SERb that SERb should reject traffic for 1267 D=2001:db8:0:1234::/64 and respond with an ICMPv6 Destination 1268 Unreachable Code 5 message, as long as the route for 1269 (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) is present. 1271 Finally, if we are willing to extend ICMPv6 to support this solution, 1272 then we could create a mechanism for SERb1 to tell the host what 1273 source address it should be using to successfully forward packets 1274 that meet the policy. In its current form, when SERb1 sends an 1275 ICMPv6 Destination Unreachable Code 5 message, it is basically 1276 saying, "This source address is wrong. Try another source address." 1277 It would be better is if the ICMPv6 message could say, "This source 1278 address is wrong. Instead use a source address in 1279 S=2001:db8:0:a000::/52." 1281 However using ICMPv6 for signalling source address information back 1282 to hosts introduces new challenges. Most routers currently have 1283 software or hardware limits on generating ICMP messages. An site 1284 administrator deploying a solution that relies on the SERs generating 1285 ICMP messages could try to improve the performance of SERs for 1286 generating ICMP messages. However, in a large network, it is still 1287 likely that ICMP message generation limits will be reached. As a 1288 result hosts would not receive ICMPv6 back which in turns leads to 1289 traffic blackholing and poor user experience. To improve the 1290 scalability of ICMPv6-based signalling hosts SHOULD cache the 1291 preferred source address (or prefix) for the given destination. In 1292 addition, the same source prefix SHOULD be used for other 1293 destinations in the same /64 as the original destination address. 1294 The source prefix SHOULD have a specific lifetime. Expiration of the 1295 lifetime SHOULD trigger the source address selection algorithm again. 1297 Using ICMPv6 Code 5 message for influencing source address selection 1298 allows an attacker to exhaust the list of candidate source addresses 1299 on the host by sending spoofed ICMPv6 Code 5 for all prefixes known 1300 on the network (therefore preventing a victim from establishing a 1301 communication with the destination host). To protect from such 1302 attack hosts SHOULD verify that the original packet header included 1303 into ICMPv6 error message was actually sent by the host. 1305 4.2.4. Summary of Methods For Controlling Source Address Selection To 1306 Implement Routing Policy 1308 So to summarize this section, we have looked at three methods for 1309 implementing a simple routing policy where all traffic for a given 1310 destination on the Internet needs to use a particular ISP, even when 1311 the uplinks to both ISPs are working. 1313 The default source address selection policy cannot distinguish 1314 between the source addresses needed to enforce this policy, so a non- 1315 default policy table using associating source and destination 1316 prefixes using Label values would need to be installed on each host. 1317 A mechanism exists for DHCPv6 to distribute a non-default policy 1318 table but such solution would heavily rely on DHCPv6 support by host 1319 operating system. Moreover there is no mechanism to translate 1320 desired routing/traffic engineering policies into policy tables on 1321 DHCPv6 servers. Therefore using DHCPv6 for controlling address 1322 selection policy table is not recommended and SHOULD NOT be used. 1324 At the same time Router Advertisements provide a reliable mechanism 1325 to influence source address selection process via PIO, RIO and 1326 default router preferences. As all those options have been 1327 standardized by IETF and are supported by various operating systems, 1328 no changes are required on hosts. First-hop routers in the 1329 enterprise network need to be able of sending different RAs for 1330 different SLAAC prefixes (either based on scoped forwarding tables or 1331 based on pre-configured policies). 1333 SERs can enforce the routing policy by sending ICMPv6 Destination 1334 Unreachable messages with Code 5 (Source address failed ingress/ 1335 egress policy) for traffic that is being sent with the wrong source 1336 address. The policy distribution can be automated by defining an 1337 EXCLUSIVE flag for the source-prefix-scoped route which can be set on 1338 the SER that originates the route. As ICMPv6 message generation can 1339 be rate-limited on routers, it SHOULD NOT be used as the only 1340 mechanism to influence source address selection on hosts. While 1341 hosts SHOULD select the correct source address for a given 1342 destination the network SHOULD signal any source address issues back 1343 to hosts using ICMPv6 error messages. 1345 4.3. Selecting Source Address When One Uplink Has Failed 1347 Now we discuss if DHCPv6, Neighbor Discovery Router Advertisements, 1348 and ICMPv6 can help a host choose the right source address when an 1349 uplink to one of the ISPs has failed. Again we look at the scenario 1350 in Figure 3. This time we look at traffic from H31 destined for 1351 external host H501 at D=2001:db8:0:5678::501. We initially assume 1352 that the uplink from SERa to ISP-A is working and that the uplink 1353 from SERb1 to ISP-B is working. 1355 We assume there is no particular routing policy desired, so H31 is 1356 free to send packets with S=2001:db8:0:a010::31 or 1357 S=2001:db8:0:b010::31 and have them delivered to H501. For this 1358 example, we assume that H31 has chosen S=2001:db8:0:b010::31 so that 1359 the packets exit via SERb to ISP-B. Now we see what happens when the 1360 link from SERb1 to ISP-B fails. How should H31 learn that it needs 1361 to start sending the packet to H501 with S=2001:db8:0:a010::31 in 1362 order to start using the uplink to ISP-A? We need to do this in a 1363 way that doesn't prevent H31 from still sending packets with 1364 S=2001:db8:0:b010::31 in order to reach H61 at D=2001:db8:0:6666::61. 1366 4.3.1. Controlling Source Address Selection With DHCPv6 1368 For this example we assume that the site network in Figure 3 has a 1369 centralized DHCP server and all routers act as DHCP relay agents. We 1370 assume that both of the addresses assigned to H31 were assigned via 1371 DHCP. 1373 We could try to have the DHCP server monitor the state of the uplink 1374 from SERb1 to ISP-B in some manner and then tell H31 that it can no 1375 longer use S=2001:db8:0:b010::31 by settings its valid lifetime to 1376 zero. The DHCP server could initiate this process by sending a 1377 Reconfigure Message to H31 as described in Section 19 of [RFC3315]. 1378 Or the DHCP server can assign addresses with short lifetimes in order 1379 to force clients to renew them often. 1381 This approach would prevent H31 from using S=2001:db8:0:b010::31 to 1382 reach the a host on the Internet. However, it would also prevent H31 1383 from using S=2001:db8:0:b010::31 to reach H61 at 1384 D=2001:db8:0:6666::61, which is not desirable. 1386 Another potential approach is to have the DHCP server monitor the 1387 uplink from SERb1 to ISP-B and control the choice of source address 1388 on H31 by updating its address selection policy table via the 1389 mechanism in [RFC7078]. The DHCP server could initiate this process 1390 by sending a Reconfigure Message to H31. Note that [RFC3315] 1391 requires that Reconfigure Message use DHCP authentication. DHCP 1392 authentication could be avoided by using short address lifetimes to 1393 force clients to send Renew messages to the server often. If the 1394 host is not obtaining its IP addresses from the DHCP server, then it 1395 would need to use the Information Refresh Time option defined in 1396 [RFC4242]. 1398 If the following policy table can be installed on H31 after the 1399 failure of the uplink from SERb1, then the desired routing behavior 1400 should be achieved based on source and destination prefix being 1401 matched with label values. 1403 Prefix Precedence Label 1404 ::/0 50 44 1405 2001:db8:0:a000::/52 50 44 1406 2001:db8:0:6666::/64 50 55 1407 2001:db8:0:b000::/52 50 55 1409 Figure 10: Policy Table Needed On Failure Of Uplink From SERb1 1411 The described solution has a number of significant drawbacks, some of 1412 them already discussed in Section 4.2.1. 1414 o DHCPv6 support is not required for an IPv6 host and there are 1415 operating systems which do not support DHCPv6. Besides that, it 1416 does not appear that [RFC7078] has been widely implemented on host 1417 operating systems. 1419 o [RFC7078] does not clearly specify this kind of a dynamic use case 1420 where address selection policy needs to be updated quickly in 1421 response to the failure of a link. In a large network it would 1422 present scalability issues as many hosts need to be reconfigured 1423 in very short period of time. 1425 o No mechanism exists for making DHCPv6 servers aware of network 1426 topology/routing changes in the network. In general DHCPv6 1427 servers monitoring network-related events sounds like a bad idea 1428 as completely new functionality beyond the scope of DHCPv6 role is 1429 required. 1431 4.3.2. Controlling Source Address Selection With Router Advertisements 1433 The same mechanism as discussed in Section 4.2.2 can be used to 1434 control the source address selection in the case of an uplink 1435 failure. If a particular prefix should not be used as a source for 1436 any destinations, then the router needs to send RA with Preferred 1437 Lifetime field for that prefix set to 0. 1439 Let's consider a scenario when all uplinks are operational and H41 1440 receives two different RAs from R3: one from LLA_A with PIO for 1441 2001:db8:0:a020::/64, default router preference set to 11 (low) and 1442 another one from LLA_B with PIO for 2001:db8:0:a020::/64, default 1443 router preference set to 01 (high) and RIO for 2001:db8:0:6666::/64. 1444 As a result H41 is using 2001:db8:0:b020::41 as a source address for 1445 all Internet traffic and those packets are sent by SERs to ISP-B. If 1446 SERb1 uplink to ISP-B failed, the desired behavior is that H41 stops 1447 using 2001:db8:0:b020::41 as a source address for all destinations 1448 but H61. To achieve that R3 should react to SERb1 uplink failure 1449 (which could be detected as the scoped route (S=2001:db8:0:b000::/52, 1450 D=::/0) disappearance) by withdrawing itself as a default router. R3 1451 sends a new RA from LLA_B with Router Lifetime value set to 0 (which 1452 means that it should not be used as default router). That RA still 1453 contains PIO for 2001:db8:0:b020::/64 (for SLAAC purposes) and RIO 1454 for 2001:db8:0:6666::/64 so H41 can reach H61 using LLA_B as a next- 1455 hop and 2001:db8:0:b020::41 as a source address. For all traffic 1456 following the default route, LLA_A will be used as a next-hop and 1457 2001:db8:0:a020::41 as a source address. 1459 If all uplinks to ISP-B have failed and therefore source addresses 1460 from ISP-B address space should not be used at all, the forwarding 1461 table scoped S=2001:db8:0:b000::/52 contains no entries. Hosts can 1462 be instructed to stop using source addresses from that block by 1463 sending RAs containing PIO with Preferred Lifetime set to 0. 1465 4.3.3. Controlling Source Address Selection With ICMPv6 1467 Now we look at how ICMPv6 messages can provide information back to 1468 H31. We assume again that at the time of the failure H31 is sending 1469 packets to H501 using (S=2001:db8:0:b010::31, 1470 D=2001:db8:0:5678::501). When the uplink from SERb1 to ISP-B fails, 1471 SERb1 would stop originating its source-prefix-scoped route for the 1472 default destination (S=2001:db8:0:b000::/52, D=::/0) as well as its 1473 unscoped default destination route. With these routes no longer in 1474 the IGP, traffic with (S=2001:db8:0:b010::31, D=2001:db8:0:5678::501) 1475 would end up at SERa based on the unscoped default destination route 1476 being originated by SERa. Since that traffic has the wrong source 1477 address to be forwarded to ISP-A, SERa would drop it and send a 1478 Destination Unreachable message with Code 5 (Source address failed 1479 ingress/egress policy) back to H31. H31 would then know to use 1480 another source address for that destination and would try with 1481 (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501). This would be 1482 forwarded to SERa based on the source-prefix-scoped default 1483 destination route still being originated by SERa, and SERa would 1484 forward it to ISP-A. As discussed above, if we are willing to extend 1485 ICMPv6, SERa can even tell H31 what source address it should use to 1486 reach that destination. The expected host behaviour has been 1487 discussed in Section 4.2.3. Potential issue with using ICMPv6 for 1488 signalling source address issues back to hosts is that uplink to an 1489 ISP-B failure immediately invalidates source addresses from 1490 2001:db8:0:b000::/52 for all hosts which triggers a large number of 1491 ICMPv6 being sent back to hosts - the same scalability/rate limiting 1492 issues discussed in Section 4.2.3 would apply. 1494 4.3.4. Summary Of Methods For Controlling Source Address Selection On 1495 The Failure Of An Uplink 1497 It appears that DHCPv6 is not particularly well suited to quickly 1498 changing the source address used by a host in the event of the 1499 failure of an uplink, which eliminates DHCPv6 from the list of 1500 potential solutions. On the other hand Router Advertisements 1501 provides a reliable mechanism to dynamically provide hosts with a 1502 list of valid prefixes to use as source addresses as well as prevent 1503 particular prefixes to be used. While no additional new features are 1504 required to be implemented on hosts, routers need to be able to send 1505 RAs based on the state of scoped forwarding tables entries and to 1506 react to network topology changes by sending RAs with particular 1507 parameters set. 1509 The use of ICMPv6 Destination Unreachable messages generated by the 1510 SER (or any SADR-capable) routers seem like they have the potential 1511 to provide a support mechanism together with RAs to signal source 1512 address selection errors back to hosts, however scalability issues 1513 may arise in large networks in case of sudden topology change. 1514 Therefore it is highly desirable that hosts are able to select the 1515 correct source address in case of uplinks failure with ICMPv6 being 1516 an additional mechanism to signal unexpected failures back to hosts. 1518 The current behavior of different host operating system when 1519 receiving ICMPv6 Destination Unreachable message with code 5 (Source 1520 address failed ingress/egress policy) is not clear to the authors. 1521 Information from implementers, users, and testing would be quite 1522 helpful in evaluating this approach. 1524 4.4. Selecting Source Address Upon Failed Uplink Recovery 1526 The next logical step is to look at the scenario when a failed uplink 1527 on SERb1 to ISP-B is coming back up, so hosts can start using source 1528 addresses belonging to 2001:db8:0:b000::/52 again. 1530 4.4.1. Controlling Source Address Selection With DHCPv6 1532 The mechanism to use DHCPv6 to instruct the hosts (H31 in our 1533 example) to start using prefixes from ISP-B space (e.g. 1534 S=2001:db8:0:b010::31 for H31) to reach hosts on the Internet is 1535 quite similar to one discussed in Section 4.3.1 and shares the same 1536 drawbacks. 1538 4.4.2. Controlling Source Address Selection With Router Advertisements 1540 Let's look at the scenario discussed in Section 4.3.2. If the 1541 uplink(s) failure caused the complete withdrawal of prefixes from 1542 2001:db8:0:b000::/52 address space by setting Preferred Lifetime 1543 value to 0, then the recovery of the link should just trigger new RA 1544 being sent with non-zero Preferred Lifetime. In another scenario 1545 discussed in Section 4.3.2, the SERb1 uplink to ISP-B failure leads 1546 to disappearance of the (S=2001:db8:0:b000::/52, D=::/0) entry from 1547 the forwarding table scoped to S=2001:db8:0:b000::/52 and, in turn, 1548 caused R3 to send RAs from LLA_B with Router Lifetime set to 0. The 1549 recovery of the SERb1 uplink to ISP-B leads to 1550 (S=2001:db8:0:b000::/52, D=::/0) scoped forwarding entry re- 1551 appearance and instructs R3 that it should advertise itself as a 1552 default router for ISP-B address space domain (send RAs from LLA_B 1553 with non-zero Router Lifetime). 1555 4.4.3. Controlling Source Address Selection With ICMP 1557 It looks like ICMPv6 provides a rather limited functionality to 1558 signal back to hosts that particular source addresses have become 1559 valid again. Unless the changes in the uplink state a particular 1560 (S,D) pair, hosts can keep using the same source address even after 1561 an ISP uplink has come back up. For example, after the uplink from 1562 SERb1 to ISP-B had failed, H31 received ICMPv6 Code 5 message (as 1563 described in Section 4.3.3) and allegedly started using 1564 (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) to reach H501. Now 1565 when the SERb1 uplink comes back up, the packets with that (S,D) pair 1566 are still routed to SERa1 and sent to the Internet. Therefore H31 is 1567 not informed that it should stop using 2001:db8:0:a010::31 and start 1568 using 2001:db8:0:b010::31 again. Unless SERa has a policy configured 1569 to drop packets (S=2001:db8:0:a010::31, D=2001:db8:0:5678::501) and 1570 send ICMPv6 back if SERb1 uplink to ISP-B is up, H31 will be unaware 1571 of the network topology change and keep using S=2001:db8:0:a010::31 1572 for Internet destinations, including H51. 1574 One of the possible option may be using a scoped route with EXCLUSIVE 1575 flag as described in Section 4.2.3. SERa1 uplink recovery would 1576 cause (S=2001:db8:0:a000::/52, D=2001:db8:0:1234::/64) route to 1577 reappear in the routing table. In the absence of that route packets 1578 to H101 which were sent to ISP-B (as ISP-A uplink was down) with 1579 source addresses from 2001:db8:0:b000::/52. When the route re- 1580 appears SERb1 would reject those packets and sends ICMPv6 back as 1581 discussed in Section 4.2.3. Practically it might lead to scalability 1582 issues which have been already discussed in Section 4.2.3 and 1583 Section 4.4.3. 1585 4.4.4. Summary Of Methods For Controlling Source Address Selection Upon 1586 Failed Uplink Recovery 1588 Once again DHCPv6 does not look like reasonable choice to manipulate 1589 source address selection process on a host in the case of network 1590 topology changes. Using Router Advertisement provides the flexible 1591 mechanism to dynamically react to network topology changes (if 1592 routers are able to use routing changes as a trigger for sending out 1593 RAs with specific parameters). ICMPv6 could be considered as a 1594 supporting mechanism to signal incorrect source address back to hosts 1595 but should not be considered as the only mechanism to control the 1596 address selection in multihomed environments. 1598 4.5. Selecting Source Address When All Uplinks Failed 1600 One particular tricky case is a scenario when all uplinks have 1601 failed. In that case there is no valid source address to be used for 1602 any external destinations while it might be desirable to have intra- 1603 site connectivity. 1605 4.5.1. Controlling Source Address Selection With DHCPv6 1607 From DHCPv6 perspective uplinks failure should be treated as two 1608 independent failures and processed as described in Section 4.3.1. At 1609 this stage it is quite obvious that it would result in quite 1610 complicated policy table which needs to be explicitly configured by 1611 administrators and therefore seems to be impractical. 1613 4.5.2. Controlling Source Address Selection With Router Advertisements 1615 As discussed in Section 4.3.2 an uplink failure causes the scoped 1616 default entry to disappear from the scoped forwarding table and 1617 triggers RAs with zero Router Lifetime. Complete disappearance of 1618 all scoped entries for a given source prefix would cause the prefix 1619 being withdrawn from hosts by setting Preferred Lifetime value to 1620 zero in PIO. If all uplinks (SERa, SERb1 and SERb2) failed, hosts 1621 either lost their default routers and/or have no global IPv6 1622 addresses to use as a source. (Note that 'uplink failure' might mean 1623 'IPv6 connectivity failure with IPv4 still being reachable', in which 1624 case hosts might fall back to IPv4 if there is IPv4 connectivity to 1625 destinations). As a results intra-site connectivity is broken. One 1626 of the possible way to solve it is to use ULAs. 1628 All hosts have ULA addresses assigned in addition to GUAs and used 1629 for intra-site communication even if there is no GUA assigned to a 1630 host. To avoid accidental leaking of packets with ULA sources SADR- 1631 capable routers SHOULD have a scoped forwarding table for ULA source 1632 for internal routes but MUST NOT have an entry for D=::/0 in that 1633 table. In the absence of (S=ULA_Prefix; D=::/0) first-hop routers 1634 will send dedicated RAs from a unique link-local source LLA_ULA with 1635 PIO from ULA address space, RIO for the ULA prefix and Router 1636 Lifetime set to zero. The behaviour is consistent with the situation 1637 when SERb1 lost the uplink to ISP-B (so there is no Internet 1638 connectivity from 2001:db8:0:b000::/52 sources) but those sources can 1639 be used to reach some specific destinations. In the case of ULA 1640 there is no Internet connectivity from ULA sources but they can be 1641 used to reach another ULA destinations. Note that ULA usage could be 1642 particularly useful if all ISPs assign prefixes via DHCP-PD. In the 1643 absence of ULAs uplinks failure hosts would lost all their GUAs upon 1644 prefix lifetime expiration which again makes intra-site communication 1645 impossible. 1647 4.5.3. Controlling Source Address Selection With ICMPv6 1649 In case of all uplinks failure all SERs will drop outgoing IPv6 1650 traffic and respond with ICMPv6 error message. In the large network 1651 when many hosts are trying to reach Internet destinations it means 1652 that SERs need to generate an ICMPv6 error to every packet they 1653 receive from hosts which presents the same scalability issues 1654 discussed in Section 4.3.3 1656 4.5.4. Summary Of Methods For Controlling Source Address Selection When 1657 All Uplinks Failed 1659 Again, combining SADR with Router Advertisements seems to be the most 1660 flexible and scalable way to control the source address selection on 1661 hosts. 1663 4.6. Summary Of Methods For Controlling Source Address Selection 1665 To summarize the scenarios and options discussed above: 1667 While DHCPv6 allows administrators to manipulate source address 1668 selection policy tables, this method has a number of significant 1669 disadvantages which eliminates DHCPv6 from a list of potential 1670 solutions: 1672 1. It required hosts to support DHCPv6 and its extension (RFC7078); 1674 2. DHCPv6 server need to monitor network state and detect routing 1675 changes. 1677 3. Network topology/routing policy changes could trigger 1678 simultaneous re-configuration of large number of hosts which 1679 present serious scalability issues. 1681 The use of Router Advertisements to influence the source address 1682 selection on hosts seem to be the most reliable, flexible and 1683 scalable solution. It has the following benefits: 1685 1. no new (non-standard) functionality needs to be implemented on 1686 hosts (except for [RFC4191] support); 1688 2. no changes in RA format; 1690 3. Routers can react to routing table changes by sending RAs which 1691 would minimize the failover time in the case of network topology 1692 changes; 1694 4. information required for source address selection is broadcast to 1695 all affected hosts in case of topology change event which 1696 improves the scalability of the solution (comparing to DHCPv6 1697 reconfiguration or ICMPv6 error messages). 1699 To fully benefit from the RA-based solution, first-hop routers need 1700 to implement SADR and be able to send dedicated RAs per scoped 1701 forwarding table as discussed above, reacting to network changes with 1702 sending new RAs. It should be noted that the proposed solution would 1703 work even if first-hop routers are not SADR-capable but still able to 1704 send individual RAs for each ISP prefix and react to topology changes 1705 as discussed above 1707 The RA-based solution relies heavily on hosts correctly implementing 1708 default address selection algorith as defined in [RFC6724] and in 1709 particular, Rule 5.5. There are some evidences that not all host 1710 OSes have that rule implemented currenly (it should be noted that 1711 [I-D.ietf-6man-multi-homed-host] states that Rule 5.5 SHOULD be 1712 implemented. 1714 ICMPv6 Code 5 error message SHOULD be used to complement RA-based 1715 solution to signal incorrect source address selection back to hosts, 1716 but it SHOULD NOT be considered as the stand-alone solution. To 1717 prevent scenarios when hosts in multihomed envinronments incorrectly 1718 identify onlink/offlink destimations, hosts should treat ICMPv6 1719 Redirects as discussed in [I-D.ietf-6man-multi-homed-host]. 1721 4.7. Other Configuration Parameters 1723 4.7.1. DNS Configuration 1725 In mutihomed envinronment each ISP might provide their own list of 1726 DNS servers. E.g. in the topology show on Figure 3, ISP-A might 1727 provide recursive DNS server H51 2001:db8:0:5555::51, while ISP-B 1728 might provide H61 2001:db8:0:6666::61 as a recursive DNS server. If 1729 the multihomed enterprise network is not running their own recursive 1730 resolver then hosts need to be configured with DNS server IPv6 1731 addresses. [RFC6106] defines IPv6 Router Advertisement options to 1732 allow IPv6 routers to advertise a list of DNS recursive server 1733 addresses and a DNS Search List to IPv6 hosts. Using RDNSS together 1734 with 'scoped' RAs as described above would allow a first-hop router 1735 (R3 in the Figure 3) to send DNS server addresses and search lists 1736 provided by each ISPs. 1738 As discussed in Section 4.5.2, failure of all ISP uplinks would cause 1739 depreaction of all addresses assigned to a host from ISPs address 1740 space. Most likely intra-site IPv6 connectivity would be still 1741 desirable so Section 4.5.2 proposes a usage of ULAs to enable intra- 1742 site communication. In such scenario the enterprise network should 1743 run its own recursive DNS server(s) and provide its ULA addresses to 1744 hosts via RDNSS mechanism in RAs send for ULA-scoped forwarding table 1745 as described in Section 4.5.2. 1747 It should be noted that [RFC6106] explicitly prohibits using DNS 1748 information if the RA router Lifetime expired: "An RDNSS address or a 1749 DNSSL domain name MUST be used only as long as both the RA router 1750 Lifetime (advertised by a Router Advertisement message) and the 1751 corresponding option Lifetime have not expired.". Therefore hosts 1752 might ignore RDNSS information provided in ULA-scoped RAs as those 1753 RAs would have router lifetime set to 0. However the updated version 1754 of RFC6106 ([I-D.ietf-6man-rdnss-rfc6106bis]) has that requirement 1755 removed. 1757 5. Other Solutions 1759 5.1. Shim6 1761 The Shim6 working group specified the Shim6 protocol [RFC5533] which 1762 allows a host at a multihomed site to communicate with an external 1763 host and exchange information about possible source and destination 1764 address pairs that they can use to communicate. It also specified 1765 the REAP protocol [RFC5534] to detect failures in the path between 1766 working address pairs and find new working address pairs. A 1767 fundamental requirement for Shim6 is that both internal and external 1768 hosts need to support Shim6. That is, both the host internal to the 1769 multihomed site and the host external to the multihomed site need to 1770 support Shim6 in order for there to be any benefit for the internal 1771 host to run Shim6. The Shim6 protocol specification was published in 1772 2009, but it has not been implemented on widely used operating 1773 systems. 1775 We do not consider Shim6 to be a viable solution. It suffers from 1776 the fact that it requires widespread deployment of Shim6 on hosts all 1777 over the Internet before the host at a PA multihomed site sees 1778 significant benefit. However, there appears to be no motivation for 1779 the vast majority of hosts on the Internet (which are not at PA 1780 multihomed sites) to deploy Shim6. This may help explain why Shim6 1781 has not been widely implemented. 1783 5.2. IPv6-to-IPv6 Network Prefix Translation 1785 IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] is not the 1786 focus of this document. This document describes a solution where a 1787 host in a multihomed site determines which ISP a packet will be sent 1788 to based on the source address it applies to the packet. This 1789 solution has many moving parts. It requires some routers in the 1790 enterprise site to support some form of Source Address Dependent 1791 Routing (SADR). It requires a host to be able to learn when the 1792 uplink to an ISP fails so that it can stop using the source address 1793 corresponding to that ISP. Ongoing work to create mechanisms to 1794 accomplish this are discussed in this document, but they are still a 1795 work in progress. 1797 This document attempts to create a PA multihoming solution that is as 1798 easy as possible for an enterprise to deploy. However, the success 1799 of this solution will depend greatly on whether or not the mechanisms 1800 for hosts to select source addresses based on the state of ISP 1801 uplinks gets implemented across a wide range of operating systems as 1802 the default mode of operation. Until that occurs, NPTv6 should still 1803 be considered a viable option to enable PA multihoming for 1804 enterprises. 1806 6. IANA Considerations 1808 This memo asks the IANA for no new parameters. 1810 7. Security Considerations 1812 7.1. Privacy Considerations 1814 8. Acknowledgements 1816 The original outline was suggested by Ole Troan. 1818 9. References 1820 9.1. Normative References 1822 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1823 Communication Layers", STD 3, RFC 1122, 1824 DOI 10.17487/RFC1122, October 1989, 1825 . 1827 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1828 Application and Support", STD 3, RFC 1123, 1829 DOI 10.17487/RFC1123, October 1989, 1830 . 1832 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1833 and E. Lear, "Address Allocation for Private Internets", 1834 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1835 . 1837 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1838 Requirement Levels", BCP 14, RFC 2119, 1839 DOI 10.17487/RFC2119, March 1997, 1840 . 1842 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1843 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1844 December 1998, . 1846 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1847 Defeating Denial of Service Attacks which employ IP Source 1848 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1849 May 2000, . 1851 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1852 C., and M. Carney, "Dynamic Host Configuration Protocol 1853 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1854 2003, . 1856 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1857 Multihoming Architectures", RFC 3582, 1858 DOI 10.17487/RFC3582, August 2003, 1859 . 1861 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 1862 Gill, "IPv4 Multihoming Practices and Limitations", 1863 RFC 4116, DOI 10.17487/RFC4116, July 2005, 1864 . 1866 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1867 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1868 November 2005, . 1870 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1871 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1872 . 1874 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 1875 Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218, 1876 October 2005, . 1878 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 1879 Should Think About", RFC 4219, DOI 10.17487/RFC4219, 1880 October 2005, . 1882 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 1883 Time Option for Dynamic Host Configuration Protocol for 1884 IPv6 (DHCPv6)", RFC 4242, DOI 10.17487/RFC4242, November 1885 2005, . 1887 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1888 "IPv6 Router Advertisement Options for DNS Configuration", 1889 RFC 6106, DOI 10.17487/RFC6106, November 2010, 1890 . 1892 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1893 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1894 . 1896 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 1897 and D. Wing, "IPv6 Multihoming without Network Address 1898 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 1899 . 1901 9.2. Informative References 1903 [I-D.baker-ipv6-isis-dst-src-routing] 1904 Baker, F. and D. Lamparter, "IPv6 Source/Destination 1905 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 1906 routing-06 (work in progress), October 2016. 1908 [I-D.baker-rtgwg-src-dst-routing-use-cases] 1909 Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and 1910 Use Cases for Source/Destination Routing", draft-baker- 1911 rtgwg-src-dst-routing-use-cases-02 (work in progress), 1912 April 2016. 1914 [I-D.boutier-babel-source-specific] 1915 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 1916 Babel", draft-boutier-babel-source-specific-01 (work in 1917 progress), May 2015. 1919 [I-D.huitema-shim6-ingress-filtering] 1920 Huitema, C., "Ingress filtering compatibility for IPv6 1921 multihomed sites", draft-huitema-shim6-ingress- 1922 filtering-00 (work in progress), September 2005. 1924 [I-D.ietf-6man-multi-homed-host] 1925 Baker, F. and B. Carpenter, "First-hop router selection by 1926 hosts in a multi-prefix network", draft-ietf-6man-multi- 1927 homed-host-10 (work in progress), October 2016. 1929 [I-D.ietf-6man-rdnss-rfc6106bis] 1930 Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1931 "IPv6 Router Advertisement Options for DNS Configuration", 1932 draft-ietf-6man-rdnss-rfc6106bis-14 (work in progress), 1933 June 2016. 1935 [I-D.ietf-mif-mpvd-arch] 1936 Anipko, D., "Multiple Provisioning Domain Architecture", 1937 draft-ietf-mif-mpvd-arch-11 (work in progress), March 1938 2015. 1940 [I-D.ietf-mptcp-experience] 1941 Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 1942 Operational Experience with Multipath TCP", draft-ietf- 1943 mptcp-experience-07 (work in progress), October 2016. 1945 [I-D.ietf-rtgwg-dst-src-routing] 1946 Lamparter, D. and A. Smirnov, "Destination/Source 1947 Routing", draft-ietf-rtgwg-dst-src-routing-02 (work in 1948 progress), May 2016. 1950 [I-D.pfister-6man-sadr-ra] 1951 Pfister, P., "Source Address Dependent Route Information 1952 Option for Router Advertisements", draft-pfister-6man- 1953 sadr-ra-01 (work in progress), June 2015. 1955 [I-D.xu-src-dst-bgp] 1956 Xu, M., Yang, S., and J. Wu, "Source/Destination Routing 1957 Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress), 1958 March 2016. 1960 [PATRICIA] 1961 Morrison, D., "Practical Algorithm to Retrieve Information 1962 Coded in Alphanumeric", Journal of the ACM 15(4) 1963 pp514-534, October 1968. 1965 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1966 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 1967 2004, . 1969 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1970 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 1971 April 2004, . 1973 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1974 Control Message Protocol (ICMPv6) for the Internet 1975 Protocol Version 6 (IPv6) Specification", RFC 4443, 1976 DOI 10.17487/RFC4443, March 2006, 1977 . 1979 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1980 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1981 DOI 10.17487/RFC4861, September 2007, 1982 . 1984 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1985 Address Autoconfiguration", RFC 4862, 1986 DOI 10.17487/RFC4862, September 2007, 1987 . 1989 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1990 Extensions for Stateless Address Autoconfiguration in 1991 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1992 . 1994 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1995 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1996 June 2009, . 1998 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 1999 Locator Pair Exploration Protocol for IPv6 Multihoming", 2000 RFC 5534, DOI 10.17487/RFC5534, June 2009, 2001 . 2003 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 2004 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2005 2012, . 2007 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 2008 "Default Address Selection for Internet Protocol Version 6 2009 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 2010 . 2012 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 2013 Address Selection Policy Using DHCPv6", RFC 7078, 2014 DOI 10.17487/RFC7078, January 2014, 2015 . 2017 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 2018 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2019 2016, . 2021 Appendix A. Change Log 2023 Initial Version: July 2016 2025 Authors' Addresses 2027 Fred Baker 2028 Cisco Systems 2029 Santa Barbara, California 93117 2030 USA 2032 Email: fred@cisco.com 2034 Chris Bowers 2035 Juniper Networks 2036 Sunnyvale, California 94089 2037 USA 2039 Email: cbowers@juniper.net 2041 Jen Linkova 2042 Google 2043 Mountain View, California 94043 2044 USA 2046 Email: furry@google.com