idnits 2.17.1 draft-sarikaya-6man-sadr-overview-12.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2016) is 2766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5533' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-6man-multiprefix-default-route' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'I-D.naderi-ipv6-probing' is defined on line 655, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-6man-multi-homed-host-09 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-05 Summary: 1 error (**), 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: April 1, 2017 Orange 6 September 28, 2016 8 Source Address Dependent Routing and Source Address Selection for IPv6 9 Hosts: Problem Space Overview 10 draft-sarikaya-6man-sadr-overview-12 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 The document is scoped on identifying a set of scenarios for source 22 address dependent routing from the host perspective and analyze a set 23 of solutions to mitigate encountered issues. The document does not 24 make any solution recommendations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 1, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 2 62 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Source Address Dependent Routing (SADR) Scenarios . . . . . . 4 64 2.1. Multi-Prefix Multihoming . . . . . . . . . . . . . . . . 4 65 2.2. Multi-Prefix Multi-Interface . . . . . . . . . . . . . . 5 66 2.3. Home Network (Homenet) . . . . . . . . . . . . . . . . . 6 67 2.4. Service-specific Egress Routing . . . . . . . . . . . . . 7 68 3. Analysis of Source Address Dependent Routing . . . . . . . . 8 69 3.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 8 70 3.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 10 71 4. Discussion on Alternate Solutions . . . . . . . . . . . . . . 11 72 4.1. Router Advertisement Option . . . . . . . . . . . . . . . 11 73 4.2. Router Advertisement Option Set . . . . . . . . . . . . . 12 74 4.3. Source Address Selection Rule 5.5 . . . . . . . . . . . . 12 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 7.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 1.1. Overall Context 86 BCP 38 recommends ingress traffic routing to prohibit Denial-of- 87 Service (DoS) attacks. As such, datagrams which have source 88 addresses that do not match with the network where the host is 89 attached are discarded [RFC2827]. Avoiding packets to be dropped 90 because of ingress filtering is difficult especially in multihomed 91 networks where the host receives more than one prefix from the 92 networks it is connected to, and consequently may have more than one 93 source addresses. Based on BCP 38, BCP 84 introduced recommendations 94 on the routing system for multihomed networks [RFC3704]. 96 Recommendations on the routing system for ingress filtering such as 97 in BCP 84 inevitably involve source address checks. This leads to 98 the source address dependent routing (SADR). Source address 99 dependent routing is an issue especially when the host is connected 100 to a multihomed network and is communicating with another host in 101 another multihomed network. In such a case, the communication can be 102 broken in both directions if Network Providers apply ingress 103 filtering and the datagrams contain wrong source addresses (see for 104 more details [I-D.huitema-multi6-ingress-filtering]). 106 Hosts with simultaneously active interfaces receive multiple prefixes 107 and have multiple source addresses. Datagrams originating from such 108 hosts are likely to be dropped due to ingress filtering policies. 109 Source address selection algorithm needs to be careful to try to 110 avoid ingress filtering on the next-hop router [RFC6724]. 112 Many use cases have been reported for source/destination routing, for 113 example [I-D.baker-rtgwg-src-dst-routing-use-cases]. These use cases 114 clearly indicate that the multihomed host or Customer Premises 115 Equipment (CPE) router needs to be configured with correct source 116 prefixes/addresses so that it can forward packets upstream correctly 117 to avoid ingress filtering applied by an upstream Network Provider to 118 drop the packets. 120 In multihomed networks there is a need to enforce source address 121 based routing if some providers are performing the ingress filtering. 122 This requires the routers to consider the source addresses as well as 123 the destination addresses in determining the next hop to send the 124 packet to. 126 1.2. Scope 128 Based on the use cases defined in 129 [I-D.baker-rtgwg-src-dst-routing-use-cases], the routers may be 130 informed about the source addresses to use for forwarding using 131 extensions to the routing protocols like IS-IS [ISO.10589.1992] 132 [I-D.baker-ipv6-isis-dst-src-routing] or OSPF [RFC5340] 133 [I-D.baker-ipv6-ospf-dst-src-routing]. 135 In this document, we describe the scenarios for source address 136 dependent routing from the host perspective. Two flavors can be 137 considered: 139 1. A host may have a single interface with multiple addresses (from 140 different prefixes or /64s). Each prefix is delegated from 141 different exit routers, and this case can be called multi-prefix 142 multihoming (MPMH). In such case, source address selection is 143 performed by the host while source-depending routing is to be 144 enforced by an upstream router. 146 2. A host may have simultaneously connected multiple interfaces 147 where each interface is connected to a different exit router and 148 this case can be called multi-prefix multiple interface (MPMI). 149 For this case, the host requires to support both source address 150 selection and source-depending routing to avoid the need to 151 rewrite the IPv6 prefix by an upstream router. 153 Several limitations arise in such NAT- and NPTv6-based ([RFC6296]) 154 multihoming contexts (see for example [RFC4116]). NPTv6 is left out 155 of scope of this document. 157 This document was initially written to inform the community about the 158 SADR problem space. It was updated to record the various set of 159 alternate solutions to address that problem space. The 6man 160 consensus is documented in [I-D.ietf-6man-multi-homed-host]. 162 2. Source Address Dependent Routing (SADR) Scenarios 164 This section describes a set of scenarios to illustrate the SADR 165 problem. Scenarios are listed following a complexity order. 167 2.1. Multi-Prefix Multihoming 169 The scenario shown in Figure 1 is a multi-prefix multihoming use 170 case. "rtr" is a CPE router which is connected to two Network 171 Providers, each advertising their own prefixes. In this case, the 172 host may have a single interface but it receives multiple prefixes 173 from the upstream Network Providers. Assuming that providers apply 174 ingress filtering policy the packets for any external communication 175 from the host should follow source address dependent routing in order 176 to avoid getting dropped. 178 In this scenario, the host does not need to perform source-depending 179 routing; it does only need to perform source address selection. 181 +------+ | 182 | | | (Network) 183 | | |=====|(Provider 1)|===== 184 | | +------+ | 185 | | | | | 186 | |=====| rtr |=====| 187 | host | | | | 188 | | +------+ | 189 | | | 190 | | | (Network) 191 | | |=====|(Provider 2)|===== 192 | | | 193 +------+ | 195 Figure 1: Multihomed Host with Multiple CPE Routers 197 2.2. Multi-Prefix Multi-Interface 199 The scenario shown in Figure 2 is multi-prefix multi interface, where 200 "rtr1" and "rtr2" represent CPE routers and there are exit routers in 201 both "network 1" and "network 2". If the packets from the host 202 communicating with a remote destination are routed to the wrong exit 203 router, i.e., carry wrong source address, they will get dropped due 204 to ingress filtering. 206 In order to avoid complications to send packets and avoid a need to 207 rewrite the source IPv6 prefix, the host requires to perform both 208 source address selection and source-depending routing so that 209 appropriate next-hop is selected taking into account the source 210 address. 212 +------+ +------+ ___________ 213 | | | | / \ 214 | |-----| rtr1 |=====/ network \ 215 | | | | \ 1 / 216 | | +------+ \___________/ 217 | | 218 | host | 219 | | 220 | | +------+ ___________ 221 | | | | / \ 222 | |=====| rtr2 |=====/ network \ 223 | | | | \ 2 / 224 +------+ +------+ \___________/ 226 Figure 2: Multiple Interfaced Host with Two CPE Routers 228 There is a variant of Figure 2 that is often referred to as a 229 corporate VPN, i.e., a secure tunnel from the host to a router 230 attached to a corporate network. In this case "rtr2" gives access 231 directly to the corporate network, and the link from the host to 232 "rtr2" is a secure tunnel (for example an IPsec tunnel). The 233 interface is therefore a virtual interface, with its own IP address/ 234 prefix assigned by the corporate network. 236 +------+ +------+ ___________ 237 | |-----| rtr1 | / \ 238 | ==========\\ |=====/ network \ 239 | |-----| || | \ 1 / 240 | | +--||--+ \___________/ 241 | | || 242 | host | || 243 | | || 244 | | +--||--+ ___________ 245 | | | | / corporate \ 246 | | | rtr2 |=====/ network \ 247 | | | | \ 2 / 248 +------+ +------+ \___________/ 250 Figure 3: VPN case 252 There are at least two sub-cases: 254 a. Dedicated forwarding entries are created in the host such that 255 only traffic directed to the corporate network is sent to "rtr2"; 256 everything else is sent to "rtr1". 258 b. All traffic is sent to "rtr2" and then routed to the Internet if 259 necessary. This case doesn't need host routes but leads to 260 unnecessary traffic and latency because of the path stretch via 261 rtr2. 263 2.3. Home Network (Homenet) 265 In the homenet scenario depicted in Figure 4, representing a simple 266 home network, there is a host connected to a local network that is 267 serviced with two CPEs which are connected to providers 1 and 2, 268 respectively. Each network delegates a different prefix. Also each 269 router provides a different prefix to the host. The issue in this 270 scenario is also ingress filtering used by each provider. This 271 scenario can be considered as a variation of the scenario described 272 in Section 2.2. 274 +------+ 275 | | +------+ 276 | | | | (Network) 277 | |==+==| rtr1 |====|(Provider 1)|===== 278 | | | | | 279 | | | +------+ 280 | host | | 281 | | | 282 | | | +------+ 283 | | | | | (Network) 284 | | +==| rtr2 |====|(Provider 2)|===== 285 | | | | 286 +------+ +------+ 288 Figure 4: Simple Home Network with Two CPE Routers 290 The host has to select the source address from the prefixes of 291 Providers 1 or 2 when communicating with other hosts in Provider 1 or 292 2. The next issue is to select the correct next hop router, rtr1 or 293 rtr2 that can reach the correct provider, "Network Provider 1" or 294 "Network Provider 2". 296 2.4. Service-specific Egress Routing 298 A variation of the scenario in Section 2.1 is: specialized egress 299 routing. Upstream networks offer different services with specific 300 requirements, e.g., VoIP or IPTV. The hosts using this service need 301 to use the service's source and destination addresses. No other 302 service will accept this source address, i.e., those packets will be 303 dropped [I-D.baker-rtgwg-src-dst-routing-use-cases]. 305 Both source address selection and source-dependent routing are 306 required to be performed by the host. 308 ___________ +------+ 309 / \ +------+ | | 310 / network \ | | | | 311 \ 1 /--| rtr1 |----| | 312 \___________/ | | | | +------+ ___________ 313 +------+ | host | | | / \ 314 | |=====| rtr3 |=====/ network \ 315 ___________ | | | | \ 3 / 316 / \ +------+ | | +------+ \___________/ 317 / network \ | | | | 318 \ 2 /--| rtr2 |----| | 319 \___________/ | | | | 320 +------+ | | 321 +------+ 323 Figure 5: Multiple Interfaced Host with Three CPE Routers 325 The scenario shown in Figure 5 s a variation of multi-prefix multi 326 interface scenario (Section 2.2). "rtr1", "rtr2" and "rtr3" are CPE 327 routers. The networks apply ingress routing. Source address 328 dependent routing should be used to avoid any external communications 329 be dropped. 331 3. Analysis of Source Address Dependent Routing 333 SADR can be facilitated at the host with proper source address and 334 next-hop selection. For this, each router connected to different 335 interfaces of the host uses Router Advertisements (RAs, [RFC4861]) to 336 distribute a default route, next hop as well as source address/prefix 337 information to the host. As a reminder, while Prefix Information 338 Option (PIO) is defined in [RFC4861], Route Information Option (RIO) 339 is defined in [RFC4191]. 341 Section 3.1 presents an analysis of the scenarios of Section 2 and 342 then Section 3.2discusses the relevance of SADR to the provisioning 343 domains. 345 3.1. Scenarios Analysis 347 As in [RFC7157] we assume that the routers in Section 2 use Router 348 Advertisements (RAs) 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 Section 2.1, source address selection is undertaken by 353 the host while source-dependent routing must be followed by "rtr" to 354 avoid packets drop. No particular modification is required for next- 355 hop selection at the host. 357 Referring to the scenario in Figure 2, source address dependent 358 routing can present a solution to the problem of the host wishes to 359 reach a destination in network 2 and the host may choose rtr1 as the 360 default router. The solution assumes the host is correctly 361 configured. The host should be configured with the prefixes 362 supported in these next hops. This way the host having received many 363 prefixes will have the correct knowledge in selecting the right 364 source address and next hop when sending packets to remote 365 destinations. 367 Note that similar considerations apply to the scenario in Figure 5. 369 In the configuration of the scenario (Figure 1) it is also useful to 370 configure the host with the prefixes and source address prefixes they 371 support. This will enable the host to select the right prefix when 372 sending packets to the right next hop and avoid any ingress filtering 373 issues. 375 Let us analyze the scenario in Section 2.3. If a source address 376 dependent routing protocol is used, the two routers (rtr1 and rtr2) 377 are both able to route traffic correctly, no matter which next-hop 378 router and source address the host selects. In case the host chooses 379 the wrong next hop router, e.g., for provider 2 rtr1 is selected, 380 rtr1 will forward the traffic to rtr2 to be sent to network provider 381 2 and no ingress filtering will happen. 383 Note that home networks are expected to comply with requirements for 384 source address dependent routing and the routers will be configured 385 accordingly, no matter which routing protocol is used [RFC7788]. 387 This would work but with issues. The host traffic to provider 2 will 388 have to go over two links instead of one, i.e., the link bandwidth 389 will be halved. Another possibility is rtr1 can send an ICMPv6 390 Redirect message to the host to direct the traffic to rtr2. Host 391 would redirect provider 2 traffic to rtr2. 393 The problem with redirects is that ICMPv6 Redirect message can only 394 convey two addresses, i.e., in this case the router address, or rtr2 395 address and the destination address, or the destination host in 396 provider 2. That means the source address will not be communicated. 397 As a result, the host would send packets to the same destination 398 using both source addresses which causes rtr2 to send a redirect 399 message to rtr1, resulting in ping-pong redirects sent by rtr1 and 400 rtr2. 402 A solution to these issues is to configure the host with the source 403 address prefixes that the next hop supports. In a homenet context, 404 each interface of the host can be configured by its next hop router, 405 so that all that is needed is to add the information on source 406 address prefixes. This results in the hosts to select the right 407 router no matter what. 409 Source address dependent routing in the use case of specialized 410 egress routing (Section 2.4) may work as follows. The specialized 411 service router advertises one or more specific prefixes with 412 appropriate source prefixes, e.g., to the CPE router, rtr in 413 Figure 1. The CPE router in turn advertises the specific service's 414 prefixes and source prefixes to the host. This will allow proper 415 configuration at the host so that the host can use the service by 416 sending the packets with the correct source and destination 417 addresses. 419 3.2. Provisioning Domains and SADR 421 Consistent set of network configuration information is called 422 provisioning domain (PvD). In case of multi-prefix multihoming 423 (MPMH), more than one provisioning domain is present on a single 424 link. In case of multi-prefix multiple interface (MPMI) 425 environments, elements of the same domain may be present on multiple 426 links. PvD aware nodes support association of configuration 427 information into PvDs and use these PvDs to serve requests for 428 network connections, e.g., choosing the right source address for the 429 packets. PvDs can be constructed from one of more DHCP or Router 430 Advertisement (RA) options carrying such information as PvD identity 431 and PvD container [I-D.ietf-mif-mpvd-ndp-support], 432 [I-D.ietf-mif-mpvd-dhcp-support]. PvDs constructed based on such 433 information are called explicit PvDs [RFC7556]. 435 Apart from PvD identity, PvD content may be encapsulated in separate 436 RA or DHCP options called PvD Container Option. These options are 437 placed in the container options of an explicit PvD. 439 Explicit PvDs may be received from different interfaces. Single PvD 440 may be accessible over one interface or simultaneously accessible 441 over multiple interfaces. Explicit PvDs may be scoped to a 442 configuration related to a particular interface, however in general 443 this may not apply. What matters is PvD ID provided that PvD ID is 444 authenticated by the node even in cases where the node has a single 445 connected interface. The authentication of the PvD ID should meet 446 the level required by the node policy. Single PvD information may be 447 received over multiple interfaces as long as PvD ID is the same. 448 This applies to the router advertisements (RAs) in which case a 449 multi-homed host (that is, with multiple interfaces) should trust a 450 message from a router on one interface to install a route to a 451 different router on another interface. 453 4. Discussion on Alternate Solutions 455 We presented many topologies in which a host with multiple interfaces 456 or a multihomed host is connected to various networks or Network 457 Providers which in turn may apply ingress routing. The scenario 458 analysis in Section 3.1 shows that in order to avoid packets getting 459 dropped due to ingress routing, source address dependent routing is 460 needed. Also, source address dependent routing should be supported 461 by routers throughout a site that has multiple egress points. 463 In this section, we provide some alternate solutions vis a vis the 464 scenarios presented in Section 2. We start with source address 465 selection rule 5.5 ([RFC6724]) and the scenarios it solves and 466 continue with solutions that state exactly what information hosts 467 need in terms of new router advertisement options for correct source 468 address selection in those scenarios. No recommendation is made in 469 this section. 471 4.1. Router Advertisement Option 473 There is a need to configure the host not only with the prefixes but 474 also with the source prefixes the next hop routers support. Such a 475 configuration may avoid the host getting ingress/egress policy error 476 messages such as ICMP source address failure message. 478 If host configuration is done using router advertisement messages 479 then there is a need to define new router advertisement options for 480 source address dependent routing. These options include Route Prefix 481 with Source Address/Prefix Option. Other options such as Next Hop 482 Address with Route Prefix option and Next Hop Address with Source 483 Address and Route Prefix option will be considered in Section 4.2. 485 As discussed in Section 3.1, the scenario in Figure 4 can be solved 486 by defining a new router advertisement option. 488 If host configuration is done using DHCP then there is a need to 489 define new DHCP options for Route Prefix with Source Address/Prefix. 490 As mentioned above, DHCP server configuration is interface specific. 491 New DHCP options for source address dependent routing such as route 492 prefix and source prefix need to be configured for each interface 493 separately. 495 The scenario in Figure 4 can be solved by defining a new DHCP option. 497 4.2. Router Advertisement Option Set 499 The source address selection rule 5.5 may possibly be a solution for 500 selecting the right source addresses for each next hop but there are 501 cases where the next hop routers on each interface of the host are 502 not known by the host initially. Such use cases are out of scope. 503 Guidelines for use cases that require router advertisement option set 504 involving third party next hop addresses are also out of scope. 506 4.3. Source Address Selection Rule 5.5 508 One possible solution is the default source address selection Rule 509 5.5 in [RFC6724] which recommends to select source addresses 510 advertised by the next hop. Considering the above scenarios, we can 511 state that this rule can solve the problem in Figure 2, Figure 1 and 512 Figure 5. 514 Source address selection rules can be distributed by DHCP server 515 using DHCP Option OPTION_ADDRSEL_TABLE defined in [RFC7078]. 517 In case of DHCP based host configuration, DHCP server can configure 518 only the interface of the host to which it is directly connected. In 519 order for Rule 5.5 to apply on other interfaces the option should be 520 sent on those interfaces as well using [RFC7078]. 522 The default source address selection Rule 5.5 solves that problem 523 when an application sends a packet with an unspecified source 524 address. In the presence of two default routes, one route will be 525 chosen, and Rule 5.5 will make sure the right source address is used. 527 When the application selects a source address, i.e., the source 528 address is chosen before next-hop selection, even though the source 529 address is a way for the application to select the exit point, in 530 this case that purpose will not be served. In the presence of 531 multiple default routes, one will be picked, ignoring the source 532 address which was selected by the application because it is known 533 that IPv6 implementations are not required to remember which next- 534 hops advertised which prefixes. Therefore, the next-hop router may 535 not be the correct one, and the packets may be filtered. 537 This implies that the hosts should register which next-hop router 538 announced each prefix. It is required that RAs be sent by the 539 routers and that they contain PIO on all links. It is also required 540 that the hosts remember the source addresses of the routers that sent 541 PIOs together with the prefixes advertised. This can be achieved by 542 updating redirect rules specified in [RFC4861]. 543 [I-D.ietf-6man-multi-homed-host] further elaborates this to specify 544 to which router a host should present its transmission. 546 Source address dependent routing solution is not complete without 547 support from the edge routers. All routers in edge networks need to 548 be required to support routing based on not only the destination 549 address but also the source address. All edge routers need to be 550 required to satisfy BCP 38 filters. 552 5. Security Considerations 554 This document describes some use cases and thus brings no additional 555 security risks. Solution documents should further elaborate on 556 specific security considerations. 558 6. Acknowledgements 560 In writing this document, we benefited from the ideas expressed by 561 the electronic mail discussion participants on 6man Working Group: 562 Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray 563 Hunter, Lorenzo Colitti and others. 565 Pierre Pfister proposed the scenario in Figure 4 as well as some text 566 for Rule 5.5. 568 The text on corporate VPN in Section 3 was provided by Brian 569 Carpenter. 571 7. References 573 7.1. Normative References 575 [I-D.ietf-6man-multi-homed-host] 576 Marcon, J. and B. Carpenter, "First-hop router selection 577 by hosts in a multi-prefix network", draft-ietf-6man- 578 multi-homed-host-09 (work in progress), August 2016. 580 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 581 Defeating Denial of Service Attacks which employ IP Source 582 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 583 May 2000, . 585 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 586 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 587 2004, . 589 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 590 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 591 DOI 10.17487/RFC4861, September 2007, 592 . 594 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 595 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 596 . 598 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 599 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 600 June 2009, . 602 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 603 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 604 . 606 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 607 "Default Address Selection for Internet Protocol Version 6 608 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 609 . 611 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 612 Address Selection Policy Using DHCPv6", RFC 7078, 613 DOI 10.17487/RFC7078, January 2014, 614 . 616 7.2. Informative References 618 [I-D.baker-6man-multiprefix-default-route] 619 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 620 draft-baker-6man-multiprefix-default-route-00 (work in 621 progress), November 2007. 623 [I-D.baker-ipv6-isis-dst-src-routing] 624 Baker, F. and D. Lamparter, "IPv6 Source/Destination 625 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 626 routing-05 (work in progress), April 2016. 628 [I-D.baker-ipv6-ospf-dst-src-routing] 629 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 630 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 631 progress), August 2013. 633 [I-D.baker-rtgwg-src-dst-routing-use-cases] 634 Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and 635 Use Cases for Source/Destination Routing", draft-baker- 636 rtgwg-src-dst-routing-use-cases-02 (work in progress), 637 April 2016. 639 [I-D.huitema-multi6-ingress-filtering] 640 Huitema, C., "Ingress filtering compatibility for IPv6 641 multihomed sites", draft-huitema-multi6-ingress- 642 filtering-00 (work in progress), October 2004. 644 [I-D.ietf-mif-mpvd-dhcp-support] 645 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 646 multiple provisioning domains in DHCPv6", draft-ietf-mif- 647 mpvd-dhcp-support-02 (work in progress), October 2015. 649 [I-D.ietf-mif-mpvd-ndp-support] 650 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 651 for multiple provisioning domains in IPv6 Neighbor 652 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 653 (work in progress), February 2016. 655 [I-D.naderi-ipv6-probing] 656 Naderi, H. and B. Carpenter, "Experience with IPv6 path 657 probing", draft-naderi-ipv6-probing-01 (work in progress), 658 April 2015. 660 [ISO.10589.1992] 661 International Organization for Standardization, 662 "Intermediate system to intermediate system intra-domain- 663 routing routine information exchange protocol for use in 664 conjunction with the protocol for providing the 665 connectionless-mode Network Service (ISO 8473), ISO 666 Standard 10589", ISO ISO.10589.1992, 1992. 668 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 669 Gill, "IPv4 Multihoming Practices and Limitations", 670 RFC 4116, DOI 10.17487/RFC4116, July 2005, 671 . 673 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 674 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 675 November 2005, . 677 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 678 and D. Wing, "IPv6 Multihoming without Network Address 679 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 680 . 682 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 683 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 684 . 686 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 687 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 688 2016, . 690 Authors' Addresses 692 Behcet Sarikaya 693 Huawei USA 694 5340 Legacy Dr. Building 175 695 Plano, TX 75024 697 Email: sarikaya@ieee.org 699 Mohamed Boucadair 700 Orange 701 Rennes 35000 702 France 704 Email: mohamed.boucadair@orange.com