idnits 2.17.1 draft-sarikaya-6man-sadr-overview-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 9, 2015) is 3244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-02 == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-01 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-05 == Outdated reference: A later version (-02) exists of draft-ietf-mif-mpvd-dhcp-support-01 == Outdated reference: A later version (-03) exists of draft-ietf-mif-mpvd-ndp-support-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Informational M. Boucadair 5 Expires: December 11, 2015 France Telecom 6 June 9, 2015 8 Source Address Dependent Routing and Source Address Selection for IPv6 9 Hosts: Problem Space Overview 10 draft-sarikaya-6man-sadr-overview-07 12 Abstract 14 This document presents the source address dependent routing (SADR) 15 problem space from the host perspective. Both multihomed hosts and 16 hosts with multiple interfaces are considered. Several network 17 architectures are presented to illustrate why source address 18 selection and next hop resolution in view of source address dependent 19 routing is needed. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 11, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 2 57 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Source Address Dependent Routing (SADR) Scenarios . . . . . . 4 59 2.1. Scenario 1: Multi-Prefix Multi-Interface . . . . . . . . 4 60 2.2. Scenario 2: Multi-Prefix Multihoming . . . . . . . . . . 5 61 2.3. Scenario 3: Service-specific Egress Routing . . . . . . . 6 62 2.4. Scenario 4: Home Network (Homenet) . . . . . . . . . . . 7 63 2.5. Scenario 5: Shim6 Host with Two Router . . . . . . . . . 7 64 3. Analysis of Source Address Dependent Routing . . . . . . . . 8 65 3.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 8 66 3.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 10 67 4. Discussion on Candidate Solution Tracks . . . . . . . . . . . 11 68 4.1. Source Address Selection Rule 5.5 . . . . . . . . . . . . 11 69 4.2. Router Advertisement Option . . . . . . . . . . . . . . . 12 70 4.3. Router Advertisement Option Set . . . . . . . . . . . . . 12 71 4.4. Other Solutions . . . . . . . . . . . . . . . . . . . . . 12 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 1.1. Overall Context 84 BCP 38 recommends ingress traffic routing to prohibit Denial-of- 85 Service (DoS) attacks. As such, datagrams which have source 86 addresses that do not match with the network where the host is 87 attached are discarded [RFC2827]. Avoiding packets to be dropped 88 because of ingress filtering is difficult especially in multihomed 89 networks where the host receives more than one prefix from the 90 networks it is connected to, and consequently may have more than one 91 source addresses. Based on BCP 38, BCP 84 introduced recommendations 92 on the routing system for multihomed networks [RFC3704]. 94 Recommendations on the routing system for ingress filtering such as 95 in BCP 84 inevitably involve source address checks. This leads to 96 the source address dependent routing (SADR). Source address 97 dependent routing is an issue especially when the host is connected 98 to a multihomed network and is communicating with another host in 99 another multihomed network. In such a case, the communication can be 100 broken in both directions if Network Providers apply ingress 101 filtering and the datagrams contain wrong source addresses (see for 102 more details [I-D.huitema-multi6-ingress-filtering]). 104 Hosts with simultaneously active interfaces receive multiple prefixes 105 and have multiple source addresses. Datagrams originating from such 106 hosts are likely to be dropped due to ingress filtering policies. 107 Source address selection algorithm needs to be careful to try to 108 avoid ingress filtering on the next-hop router [RFC6724]. 110 Many use cases have been reported for source/destination routing, for 111 example [I-D.baker-rtgwg-src-dst-routing-use-cases]. These use cases 112 clearly indicate that the multihomed host or Customer Premises 113 Equipment (CPE) router needs to be configured with correct source 114 prefixes/addresses so that it can forward packets upstream correctly 115 to avoid ingress filtering applied by an upstream Network Provider to 116 drop the packets. 118 In multihomed networks there is a need to do source address based 119 routing if some providers are performing the ingress filtering 120 defined in BCP38 [RFC2827]. This requires the routers to consider 121 the source addresses as well as the destination addresses in 122 determining the next hop to send the packet to. 124 1.2. Scope 126 Based on the use cases defined in 127 [I-D.baker-rtgwg-src-dst-routing-use-cases], the routers may be 128 informed about the source addresses to use for forwarding using 129 extensions to the routing protocols like IS-IS [ISO.10589.1992] 130 [I-D.baker-ipv6-isis-dst-src-routing] or OSPF [RFC5340] 131 [I-D.baker-ipv6-ospf-dst-src-routing]. 133 In this document, we describe the scenarios for source address 134 dependent routing from the host perspective. Two flavors can be 135 considered: 137 1. A host may have a single interface with multiple addresses (from 138 different prefixes or /64s). Each prefix is delegated from 139 different exit routers, and this case can be called multi-prefix 140 multihoming (MPMH). 142 2. A host may have simultaneously connected multiple interfaces 143 where each interface is connected to a different exit router and 144 this case can be called multi-prefix multiple interface (MPMI). 146 Several limitations arise in such NAT- and NPTv6-based ([RFC6296]) 147 multihoming contexts (see for example [RFC4116]). NPTv6 is left out 148 of scope in this document. 150 2. Source Address Dependent Routing (SADR) Scenarios 152 SADR can be facilitated at the host with proper next-hop and source 153 address selection. For this, each router connected to different 154 interfaces of the host uses Router Advertisements (RAs, [RFC4861]) to 155 distribute default route, next hop as well as source address/prefix 156 information to the host. As a reminder, Route Information Option is 157 defined in [RFC4191]. 159 2.1. Scenario 1: Multi-Prefix Multi-Interface 161 The scenario shown in Figure 1 is multi-prefix multi interface where 162 "rtr1" and "rtr2" represent customer premises equipment/routers (CPE) 163 and there are exit routers in both "network 1" and "network 2". If 164 the packets from the host communicating with a remote destination are 165 routed to the wrong exit router, i.e., carry wrong source address, 166 they will get dropped due to ingress filtering. 168 +------+ +------+ ___________ 169 | | | | / \ 170 | |-----| rtr1 |=====/ network \ 171 | | | | \ 1 / 172 | | +------+ \___________/ 173 | | 174 | host | 175 | | 176 | | +------+ ___________ 177 | | | | / \ 178 | |=====| rtr2 |=====/ network \ 179 | | | | \ 2 / 180 +------+ +------+ \___________/ 182 Figure 1: Multiple Interfaced Host with Two CPE Routers 184 There is a variant of Figure 1 that is often referred to as a 185 corporate VPN, i.e., a secure tunnel from the host to a router 186 attached to a corporate network. In this case "rtr2" gives access 187 directly to the corporate network, and the link from the host to 188 "rtr2" is a secure tunnel (for example an IPsec tunnel). The 189 interface is therefore a virtual interface, with its own IP address/ 190 prefix assigned by the corporate network. 192 +------+ +------+ ___________ 193 | |-----| rtr1 | / \ 194 | ==========\\ |=====/ network \ 195 | |-----| || | \ 1 / 196 | | +--||--+ \___________/ 197 | | || 198 | host | || 199 | | || 200 | | +--||--+ ___________ 201 | | | | / corporate \ 202 | | | rtr2 |=====/ network \ 203 | | | | \ 2 / 204 +------+ +------+ \___________/ 206 Figure 2: VPN case 208 There are at least two sub-cases: 210 a. Dedicated forwarding entries are created in the host such that 211 only traffic directed to the corporate network is sent to "rtr2"; 212 everything else is sent to "rtr1". 214 b. All traffic is sent to "rtr2" and then routed to the Internet if 215 necessary. This case doesn't need host routes but leads to 216 unnecessary traffic and latency because of the path stretch via 217 rtr2. 219 2.2. Scenario 2: Multi-Prefix Multihoming 221 Another scenario is shown in Figure 3. This one is a multi-prefix 222 multihoming use case. "rtr" is CPE router which is connected to two 223 Network Providers, each advertising their own prefixes. In this 224 case, the host may have a single interface but it receives multiple 225 prefixes from the connected Network Provider. Assuming that 226 providers apply ingress filtering policy the packets for any external 227 communication from the host should follow source address dependent 228 routing in order to avoid getting dropped. 230 +------+ | 231 | | | (Network) 232 | | |=====|(Provider 1)|===== 233 | | +------+ | 234 | | | | | 235 | |=====| rtr |=====| 236 | host | | | | 237 | | +------+ | 238 | | | 239 | | | (Network) 240 | | |=====|(Provider 2)|===== 241 | | | 242 +------+ | 244 Figure 3: Multihomed Host with Multiple CPE Routers 246 2.3. Scenario 3: Service-specific Egress Routing 248 A variation of the scenario in Section 2.2 is: specialized egress 249 routing. Upstream networks offer different services with specific 250 requirements, e.g., VoIP or IPTV. The hosts using this service need 251 to use the service's source and destination addresses. No other 252 service will accept this source address, i.e., those packets will be 253 dropped [I-D.baker-rtgwg-src-dst-routing-use-cases]. 255 ___________ +------+ 256 / \ +------+ | | 257 / network \ | | | | 258 \ 1 /--| rtr1 |----| | 259 \___________/ | | | | +------+ ___________ 260 +------+ | host | | | / \ 261 | |=====| rtr3 |=====/ network \ 262 ___________ | | | | \ 3 / 263 / \ +------+ | | +------+ \___________/ 264 / network \ | | | | 265 \ 2 /--| rtr2 |----| | 266 \___________/ | | | | 267 +------+ | | 268 +------+ 270 Figure 4: Multiple Interfaced Host with Three CPE Routers 272 The scenario shown in Figure 4 s a variation of multi-prefix multi 273 interface scenario (Section 2.1). "rtr1", "rtr2" and "rtr3" are CPE 274 routers. The networks apply ingress routing. Source address 275 dependent routing should be used to avoid any external communications 276 be dropped. 278 2.4. Scenario 4: Home Network (Homenet) 280 In the homenet scenario depicted in Figure 5, representing a simple 281 home network, there is a host connected to two CPEs which are 282 connected to providers 1 and 2, respectively. Each network delegates 283 a different prefix. Also each router provides a different prefix to 284 the host. The issue in this scenario is also ingress filtering used 285 by each provider. 287 +------+ 288 | | +------+ 289 | | | | (Network) 290 | |==+==| rtr1 |====|(Provider 1)|===== 291 | | | | | 292 | | | +------+ 293 | host | | 294 | | | 295 | | | +------+ 296 | | | | | (Network) 297 | | +==| rtr2 |====|(Provider 2)|===== 298 | | | | 299 +------+ +------+ 301 Figure 5: Simple Home Network with Two CPE Routers 303 The host has to select the source address from the prefixes of 304 Providers 1 or 2 when communicating with other hosts in Provider 1 or 305 2. The next issue is to select the correct next hop router, rtr1 or 306 rtr2 that can reach the correct provider, "Network Provider 1" or 307 "Network Provider 2". 309 2.5. Scenario 5: Shim6 Host with Two Router 311 The last scenario shown in Figure 6 is also a variation of multi- 312 prefix multihoming scenario (Section 2.2). In this case rtrE is 313 connected to two providers. All network providers are assumed to 314 apply ingress routing. The host receives prefixes from each provider 315 and starts communicating with external hosts, e.g., H1, H2, etc. H1 316 and H2 may be accessible both from provider 1 and provider 3. 318 +------+ | +------+ 319 | | | | | (Network) 320 | | |-----| rtrF |=====(Provider 3) 321 | | | | | 322 | | | +------+ 323 | | | 324 | host | | 325 | | | 326 | | +------+ | +------+ (Network) 327 | | | | | | |=====(Provider 2) 328 | |=====| rtr |=====|=====| rtrE | (Network) 329 | | | | | | |=====(Provider 1) 330 +------+ +------+ + +------+ 332 Figure 6: Shim6 Host with Two Routers 334 The host receives multiple provider-allocated IPv6 address prefixes, 335 e.g., P1, P2 and P3 for providers 1, 2 and 3 and supports shim6 336 protocol [RFC5533]. rtr is a CPE router and the default router for 337 the host. rtr receives OSPF routes and has a default route for rtrE 338 and rtrF. 340 3. Analysis of Source Address Dependent Routing 342 In this section we present an analysis of the scenarios of Section 2 343 and then discuss the relevance of SADR to the provisioning domains. 345 3.1. Scenarios Analysis 347 As in [RFC7157] we assume that the routers in Section 2 use Router 348 Advertisements to distribute default route and source address 349 prefixes supported in each next hop to the hosts or the gateway/CPE 350 router relays this information to the hosts. 352 Referring to the scenario in Figure 1, source address dependent 353 routing can present a solution to the problem of the host wishes to 354 reach a destination in network 2 and the host may choose rtr1 as the 355 default router. The solution assumes the host is correctly 356 configured. The host should be configured with the prefixes 357 supported in these next hops. This way the host having received many 358 prefixes will have the correct knowledge in selecting the right 359 source address and next hop when sending packets to remote 360 destinations. 362 Note that similar considerations apply to the scenario in Figure 4. 364 In the configuration of the scenario (Figure 3) it is also useful to 365 configure the host with the prefixes and source address prefixes they 366 support. This will enable the host to select the right prefix when 367 sending packets to the right next hop and avoid any ingress 368 filtering. 370 Source address dependent routing in the use case of specialized 371 egress routing may work as follows. The specialized service router 372 advertizes one or more specific prefixes with appropriate source 373 prefixes, e.g., to the CPE Router, rtr in Figure 3. The CPE router 374 in turn advertizes the specific service's prefixes and source 375 prefixes to the host. This will allow proper configuration at the 376 host so that the host can use the service by sending the packets with 377 the correct source and destination addresses. 379 Let us analyze the scenario in Figure 5. If a source address 380 dependent routing protocol is used, the two routers (rtr1 and rtr2) 381 are both able to route traffic correctly, no matter which next-hop 382 router and source address the host selects. In case the host chooses 383 the wrong next hop router, e.g., for provider 2 rtr1 is selected, 384 rtr1 will forward the traffic to rtr2 to be sent to network provider 385 2 and no ingress filtering will happen. 387 Note that home networks are expected to comply with requirements for 388 source address dependent routing and the routers will be configured 389 accordingly, no matter which routing protocol, e.g., OSPF is used 390 [I-D.ietf-homenet-hncp]. 392 This would work but with issues. The host traffic to provider 2 will 393 have to go over two links instead of one, i.e., the link bandwidth 394 will be halved. Another possibility is rtr1 can send an ICMPv6 395 Redirect message to the host to direct the traffic to rtr2. Host 396 would redirect provider 2 traffic to rtr2. 398 The problem with redirects is that ICMPv6 Redirect message can only 399 convey two addresses, i.e., in this case the router address, or rtr2 400 address and the destination address, or the destination host in 401 provider 2. That means the source address will not be communicated. 402 As a result, the host would send packets to the same destination 403 using both source addresses which causes rtr2 to send a redirect 404 message to rtr1, resulting in ping-pong redirects sent by rtr1 and 405 rtr2. 407 The best solution to these issues is to configure the host with the 408 source address prefixes that the next hop supports. In homenets, 409 each interface of the host can be configured by its next hop router, 410 so that all that is needed is to add the information on source 411 address prefixes. This results in the hosts to select the right 412 router no matter what. 414 Finally, the scenario in Figure 6 shows that even though all the 415 routers may have source address dependent routing support, the 416 packets still may get dropped. 418 The host in Figure 6 starts external communication with H1 and sends 419 the first packet with source address P3::iid. Since rtr has a 420 default route to rtrE it will use this default route in sending the 421 host's packet out towards rtrE. rtrE will route this packet to 422 provider 1 and the packet will be dropped due to the ingress 423 filtering. 425 A solution to this issue could be that rtrE having multiple routes to 426 H1 could use the path through rtrF and could direct the packet to the 427 other route, i.e., rtrF which would reach H1 in Network Provider 3 428 without being subject to ingress routing 429 [I-D.baker-6man-multiprefix-default-route]. 431 3.2. Provisioning Domains and SADR 433 Consistent set of network configuration information is called 434 provisioning domain (PvD). In case of multi-prefix multihoming 435 (MPMH), more than one provisioning domain is present on a single 436 link. In case of multi-prefix multiple interface (MPMI) 437 environments, elements of the same domain may be present on multiple 438 links. PvD aware nodes support association of configuration 439 information into PvDs and use these PvDs to serve requests for 440 network connections, e.g., choosing the right source address for the 441 packets. PvDs can be constructed from one of more DHCP or Router 442 Advertisement (RA) options carrying such information as PvD identity 443 and PvD container [I-D.ietf-mif-mpvd-ndp-support], 444 [I-D.ietf-mif-mpvd-dhcp-support]. PvDs constructed based on such 445 information are called explicit PvDs [RFC7556]. 447 Apart from PvD identity, PvD content may be encapsulated in separate 448 RA or DHCP options called PvD Container Option. These options are 449 placed in the container options of an explicit PvD. 451 Explicit PvDs may be received from different interfaces. Single PvD 452 may be accessible over one interface or simultaneously accessible 453 over multiple interfaces. Explicit PvDs may be scoped to a 454 configuration related to a particular interface, however in general 455 this may not apply. What matters is PvD ID provided that PvD ID is 456 authenticated by the node even in cases where the node has a single 457 connected interface. The authentication of the PvD ID should meet 458 the level required by the node policy. Single PvD information may be 459 received over multiple interfaces as long as PvD ID is the same. 460 This applies to the router advertisements (RAs) in which case a 461 multi-homed host (that is, with multiple interfaces) should trust a 462 message from a router on one interface to install a route to a 463 different router on another interface. 465 4. Discussion on Candidate Solution Tracks 467 We presented many topologies in which a host with multiple interfaces 468 or a multihomed host is connected to various networks or Network 469 Providers which in turn may apply ingress routing. The scenario 470 analysis in Section 3.1 showed that in order to avoid packets getting 471 dropped due to ingress routing, source address dependent routing is 472 needed. Also, source address dependent routing should be supported 473 by routers throughout a site that has multiple exits. 475 In this section, we provide informative guidelines on different 476 existing and future solutions vis a vis the scenarios presented in 477 Section 2. We start with source address selection rule 5.5 478 ([RFC6724]) and the scenarios it solves and continue with solutions 479 that state exactly what information hosts need in terms of new router 480 advertisement options for correct source address selection in those 481 scenarios. 483 4.1. Source Address Selection Rule 5.5 485 One possible solution is the default source address selection Rule 486 5.5 in [RFC6724] which recommends to select source addresses 487 advertized by the next hop. Considering the above scenarios, we can 488 state that this rule can solve the problem in Figure 1, Figure 3 and 489 Figure 4. 491 In using Rule 5.5 the following guidelines should be kept in mind. 492 Source address selection rules can be distributed by DHCP server 493 using DHCP Option OPTION_ADDRSEL_TABLE defined in [RFC7078]. 495 In case of DHCP based host configuration, DHCP server can configure 496 only the interface of the host to which it is directly connected. In 497 order for Rule 5.5 to apply on other interfaces the option should be 498 sent on those interfaces as well using [RFC7078]. 500 The default source address selection Rule 5.5 solves that problem 501 when an application sends a packet with an unspecified source 502 address. In the presence of two default routes, one route will be 503 chosen, and Rule 5.5 will make sure the right source address is used. 505 When the application selects a source address, i.e., the source 506 address is chosen before next-hop selection, even though the source 507 address is a way for the application to select the exit point, in 508 this case that purpose will not be served. In the presence of 509 multiple default routes, one will be picked, ignoring the source 510 address which was selected by the application because it is known 511 that IPv6 implementations are not required to remember which next- 512 hops advertised which prefixes. Therefore, the next-hop router may 513 not be the correct one, and the packets may be filtered. 515 This implies that the hosts should register which next-hop router 516 announced each prefix. 518 4.2. Router Advertisement Option 520 There is a need to configure the host not only with the prefixes but 521 also with the source prefixes the next hop routers support. Such a 522 configuration may avoid the host getting ingress/egress policy error 523 messages such as ICMP source address failure message. 525 If host configuration is done using router advertisement messages 526 then there is a need to define new router advertisement options for 527 source address dependent routing. These options include Route Prefix 528 with Source Address/Prefix Option. Other options such as Next Hop 529 Address with Route Prefix option and Next Hop Address with Source 530 Address and Route Prefix option will be considered in Section 4.3. 532 As discussed in Section 3.1, the scenario in Figure 5 can be solved 533 by defining a new router advertisement option. 535 If host configuration is done using DHCP then there is a need to 536 define new DHCP options for Route Prefix with Source Address/Prefix. 537 As mentioned above, DHCP server configuration is interface specific. 538 New DHCP options for source address dependent routing such as route 539 prefix and source prefix need to be configured for each interface 540 separately. 542 The scenario in Figure 5 can be solved by defining a new DHCP option. 544 4.3. Router Advertisement Option Set 546 The source address selection rule 5.5 may possibly be a solution for 547 selecting the right source addresses for each next hop but there are 548 cases where the next hop routers on each interface of the host are 549 not known by the host initially. Such use cases are out of scope. 550 Guidelines for use cases that require router advertisement option set 551 involving third party next hop addresses are also out of scope. 553 4.4. Other Solutions 555 So far we have singled out the scenario in Figure 6. All the above 556 solutions do not work in this case. This brings us the issue of IP 557 path probing [I-D.naderi-ipv6-probing]. 559 For a given destination, the host selects a source address and a next 560 hop and sends its packet. When the selected path fails, in case of 561 IP probing, the host can probe all available paths until finding one 562 that works. 564 The guideline in probing is SADR should be used, i.e., it is a 565 necessary tool. Basically, SADR saves time in eliminating wrong 566 paths, i.e. sending the packets to the wrong exit router. If SADR is 567 not taken into account correctly the host will end up wasting 568 resources trying to explore paths that are certain to fail. 570 5. Security Considerations 572 This document describes some use cases and thus brings no additional 573 security risks. Solution documents should further elaborate on 574 specific security considerations. 576 6. IANA Considerations 578 None. 580 7. Acknowledgements 582 In writing this document, we benefited from the ideas expressed by 583 the electronic mail discussion participants on 6man Working Group: 584 Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray 585 Hunter, Lorenzo Colitti and others. 587 Pierre Pfister proposed the scenario in Figure 5 as well as some text 588 for Rule 5.5. 590 The text on corporate VPN in Section 3 was provided by Brian 591 Carpenter. 593 8. References 595 8.1. Normative References 597 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 598 Defeating Denial of Service Attacks which employ IP Source 599 Address Spoofing", BCP 38, RFC 2827, May 2000. 601 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 602 Networks", BCP 84, RFC 3704, March 2004. 604 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 605 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 606 September 2007. 608 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 609 for IPv6", RFC 5340, July 2008. 611 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 612 Shim Protocol for IPv6", RFC 5533, June 2009. 614 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 615 Translation", RFC 6296, June 2011. 617 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 618 "Default Address Selection for Internet Protocol Version 6 619 (IPv6)", RFC 6724, September 2012. 621 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 622 Address Selection Policy Using DHCPv6", RFC 7078, January 623 2014. 625 8.2. Informative References 627 [I-D.baker-6man-multiprefix-default-route] 628 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 629 draft-baker-6man-multiprefix-default-route-00 (work in 630 progress), November 2007. 632 [I-D.baker-ipv6-isis-dst-src-routing] 633 Baker, F. and D. Lamparter, "IPv6 Source/Destination 634 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 635 routing-02 (work in progress), October 2014. 637 [I-D.baker-ipv6-ospf-dst-src-routing] 638 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 639 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 640 progress), August 2013. 642 [I-D.baker-rtgwg-src-dst-routing-use-cases] 643 Baker, F., "Requirements and Use Cases for Source/ 644 Destination Routing", draft-baker-rtgwg-src-dst-routing- 645 use-cases-01 (work in progress), October 2014. 647 [I-D.huitema-multi6-ingress-filtering] 648 Huitema, C., "Ingress filtering compatibility for IPv6 649 multihomed sites", draft-huitema-multi6-ingress- 650 filtering-00 (work in progress), October 2004. 652 [I-D.ietf-homenet-hncp] 653 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 654 Control Protocol", draft-ietf-homenet-hncp-05 (work in 655 progress), June 2015. 657 [I-D.ietf-mif-mpvd-dhcp-support] 658 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 659 multiple provisioning domains in DHCPv6", draft-ietf-mif- 660 mpvd-dhcp-support-01 (work in progress), March 2015. 662 [I-D.ietf-mif-mpvd-ndp-support] 663 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 664 for multiple provisioning domains in IPv6 Neighbor 665 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-01 666 (work in progress), February 2015. 668 [I-D.naderi-ipv6-probing] 669 Naderi, H. and B. Carpenter, "Experience with IPv6 path 670 probing", draft-naderi-ipv6-probing-01 (work in progress), 671 April 2015. 673 [ISO.10589.1992] 674 International Organization for Standardization, 675 "Intermediate system to intermediate system intra-domain- 676 routing routine information exchange protocol for use in 677 conjunction with the protocol for providing the 678 connectionless-mode Network Service (ISO 8473), ISO 679 Standard 10589", ISO ISO.10589.1992, 1992. 681 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 682 Gill, "IPv4 Multihoming Practices and Limitations", RFC 683 4116, July 2005. 685 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 686 More-Specific Routes", RFC 4191, November 2005. 688 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 689 Wing, "IPv6 Multihoming without Network Address 690 Translation", RFC 7157, March 2014. 692 [RFC7556] Anipko, D., "Multiple Provisioning Domain Architecture", 693 RFC 7556, June 2015. 695 Authors' Addresses 697 Behcet Sarikaya 698 Huawei USA 699 5340 Legacy Dr. Building 175 700 Plano, TX 75024 702 Email: sarikaya@ieee.org 703 Mohamed Boucadair 704 France Telecom 705 Rennes 35000 706 France 708 Email: mohamed.boucadair@orange.com