idnits 2.17.1 draft-sarikaya-6man-sadr-overview-11.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 (July 21, 2016) is 2835 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5533' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-6man-multiprefix-default-route' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'I-D.naderi-ipv6-probing' is defined on line 637, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-6man-multi-homed-host-07 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-05 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: January 22, 2017 Orange 6 July 21, 2016 8 Source Address Dependent Routing and Source Address Selection for IPv6 9 Hosts: Problem Space Overview 10 draft-sarikaya-6man-sadr-overview-11 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 January 22, 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. Scenario 1: Multi-Prefix Multi-Interface . . . . . . . . 4 65 2.2. Scenario 2: Multi-Prefix Multihoming . . . . . . . . . . 5 66 2.3. Scenario 3: Service-specific Egress Routing . . . . . . . 6 67 2.4. Scenario 4: Home Network (Homenet) . . . . . . . . . . . 7 68 3. Analysis of Source Address Dependent Routing . . . . . . . . 7 69 3.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 7 70 3.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 9 71 4. Discussion on Alternate Solutions . . . . . . . . . . . . . . 10 72 4.1. Router Advertisement Option . . . . . . . . . . . . . . . 10 73 4.2. Router Advertisement Option Set . . . . . . . . . . . . . 11 74 4.3. Source Address Selection Rule 5.5 . . . . . . . . . . . . 11 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 8.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 1.1. Overall Context 87 BCP 38 recommends ingress traffic routing to prohibit Denial-of- 88 Service (DoS) attacks. As such, datagrams which have source 89 addresses that do not match with the network where the host is 90 attached are discarded [RFC2827]. Avoiding packets to be dropped 91 because of ingress filtering is difficult especially in multihomed 92 networks where the host receives more than one prefix from the 93 networks it is connected to, and consequently may have more than one 94 source addresses. Based on BCP 38, BCP 84 introduced recommendations 95 on the routing system for multihomed networks [RFC3704]. 97 Recommendations on the routing system for ingress filtering such as 98 in BCP 84 inevitably involve source address checks. This leads to 99 the source address dependent routing (SADR). Source address 100 dependent routing is an issue especially when the host is connected 101 to a multihomed network and is communicating with another host in 102 another multihomed network. In such a case, the communication can be 103 broken in both directions if Network Providers apply ingress 104 filtering and the datagrams contain wrong source addresses (see for 105 more details [I-D.huitema-multi6-ingress-filtering]). 107 Hosts with simultaneously active interfaces receive multiple prefixes 108 and have multiple source addresses. Datagrams originating from such 109 hosts are likely to be dropped due to ingress filtering policies. 110 Source address selection algorithm needs to be careful to try to 111 avoid ingress filtering on the next-hop router [RFC6724]. 113 Many use cases have been reported for source/destination routing, for 114 example [I-D.baker-rtgwg-src-dst-routing-use-cases]. These use cases 115 clearly indicate that the multihomed host or Customer Premises 116 Equipment (CPE) router needs to be configured with correct source 117 prefixes/addresses so that it can forward packets upstream correctly 118 to avoid ingress filtering applied by an upstream Network Provider to 119 drop the packets. 121 In multihomed networks there is a need to do source address based 122 routing if some providers are performing the ingress filtering 123 defined in BCP38 [RFC2827]. This requires the routers to consider 124 the source addresses as well as the destination addresses in 125 determining the next hop to send the packet to. 127 1.2. Scope 129 Based on the use cases defined in 130 [I-D.baker-rtgwg-src-dst-routing-use-cases], the routers may be 131 informed about the source addresses to use for forwarding using 132 extensions to the routing protocols like IS-IS [ISO.10589.1992] 133 [I-D.baker-ipv6-isis-dst-src-routing] or OSPF [RFC5340] 134 [I-D.baker-ipv6-ospf-dst-src-routing]. 136 In this document, we describe the scenarios for source address 137 dependent routing from the host perspective. Two flavors can be 138 considered: 140 1. A host may have a single interface with multiple addresses (from 141 different prefixes or /64s). Each prefix is delegated from 142 different exit routers, and this case can be called multi-prefix 143 multihoming (MPMH). 145 2. A host may have simultaneously connected multiple interfaces 146 where each interface is connected to a different exit router and 147 this case can be called multi-prefix multiple interface (MPMI). 149 Several limitations arise in such NAT- and NPTv6-based ([RFC6296]) 150 multihoming contexts (see for example [RFC4116]). NPTv6 is left out 151 of scope of this document. 153 This document was initially written to inform the community about the 154 SADR problem space. It was updated to record the various set of 155 alternate solutions to address that problem space. The 6man 156 consensus is documented in [I-D.ietf-6man-multi-homed-host]. 158 2. Source Address Dependent Routing (SADR) Scenarios 160 SADR can be facilitated at the host with proper next-hop and source 161 address selection. For this, each router connected to different 162 interfaces of the host uses Router Advertisements (RAs, [RFC4861]) to 163 distribute default route, next hop as well as source address/prefix 164 information to the host. As a reminder, while Prefix Information 165 Option (PIO) is defined in [RFC4861], Route Information Option (RIO) 166 is defined in [RFC4191]. 168 2.1. Scenario 1: Multi-Prefix Multi-Interface 170 The scenario shown in Figure 1 is multi-prefix multi interface where 171 "rtr1" and "rtr2" represent customer premises equipment/routers (CPE) 172 and there are exit routers in both "network 1" and "network 2". If 173 the packets from the host communicating with a remote destination are 174 routed to the wrong exit router, i.e., carry wrong source address, 175 they will get dropped due to ingress filtering. 177 +------+ +------+ ___________ 178 | | | | / \ 179 | |-----| rtr1 |=====/ network \ 180 | | | | \ 1 / 181 | | +------+ \___________/ 182 | | 183 | host | 184 | | 185 | | +------+ ___________ 186 | | | | / \ 187 | |=====| rtr2 |=====/ network \ 188 | | | | \ 2 / 189 +------+ +------+ \___________/ 191 Figure 1: Multiple Interfaced Host with Two CPE Routers 193 There is a variant of Figure 1 that is often referred to as a 194 corporate VPN, i.e., a secure tunnel from the host to a router 195 attached to a corporate network. In this case "rtr2" gives access 196 directly to the corporate network, and the link from the host to 197 "rtr2" is a secure tunnel (for example an IPsec tunnel). The 198 interface is therefore a virtual interface, with its own IP address/ 199 prefix assigned by the corporate network. 201 +------+ +------+ ___________ 202 | |-----| rtr1 | / \ 203 | ==========\\ |=====/ network \ 204 | |-----| || | \ 1 / 205 | | +--||--+ \___________/ 206 | | || 207 | host | || 208 | | || 209 | | +--||--+ ___________ 210 | | | | / corporate \ 211 | | | rtr2 |=====/ network \ 212 | | | | \ 2 / 213 +------+ +------+ \___________/ 215 Figure 2: VPN case 217 There are at least two sub-cases: 219 a. Dedicated forwarding entries are created in the host such that 220 only traffic directed to the corporate network is sent to "rtr2"; 221 everything else is sent to "rtr1". 223 b. All traffic is sent to "rtr2" and then routed to the Internet if 224 necessary. This case doesn't need host routes but leads to 225 unnecessary traffic and latency because of the path stretch via 226 rtr2. 228 2.2. Scenario 2: Multi-Prefix Multihoming 230 Another scenario is shown in Figure 3. This one is a multi-prefix 231 multihoming use case. "rtr" is CPE router which is connected to two 232 Network Providers, each advertising their own prefixes. In this 233 case, the host may have a single interface but it receives multiple 234 prefixes from the connected Network Provider. Assuming that 235 providers apply ingress filtering policy the packets for any external 236 communication from the host should follow source address dependent 237 routing in order to avoid getting dropped. 239 +------+ | 240 | | | (Network) 241 | | |=====|(Provider 1)|===== 242 | | +------+ | 243 | | | | | 244 | |=====| rtr |=====| 245 | host | | | | 246 | | +------+ | 247 | | | 248 | | | (Network) 249 | | |=====|(Provider 2)|===== 250 | | | 251 +------+ | 253 Figure 3: Multihomed Host with Multiple CPE Routers 255 2.3. Scenario 3: Service-specific Egress Routing 257 A variation of the scenario in Section 2.2 is: specialized egress 258 routing. Upstream networks offer different services with specific 259 requirements, e.g., VoIP or IPTV. The hosts using this service need 260 to use the service's source and destination addresses. No other 261 service will accept this source address, i.e., those packets will be 262 dropped [I-D.baker-rtgwg-src-dst-routing-use-cases]. 264 ___________ +------+ 265 / \ +------+ | | 266 / network \ | | | | 267 \ 1 /--| rtr1 |----| | 268 \___________/ | | | | +------+ ___________ 269 +------+ | host | | | / \ 270 | |=====| rtr3 |=====/ network \ 271 ___________ | | | | \ 3 / 272 / \ +------+ | | +------+ \___________/ 273 / network \ | | | | 274 \ 2 /--| rtr2 |----| | 275 \___________/ | | | | 276 +------+ | | 277 +------+ 279 Figure 4: Multiple Interfaced Host with Three CPE Routers 281 The scenario shown in Figure 4 s a variation of multi-prefix multi 282 interface scenario (Section 2.1). "rtr1", "rtr2" and "rtr3" are CPE 283 routers. The networks apply ingress routing. Source address 284 dependent routing should be used to avoid any external communications 285 be dropped. 287 2.4. Scenario 4: Home Network (Homenet) 289 In the homenet scenario depicted in Figure 5, representing a simple 290 home network, there is a host connected to two CPEs which are 291 connected to providers 1 and 2, respectively. Each network delegates 292 a different prefix. Also each router provides a different prefix to 293 the host. The issue in this scenario is also ingress filtering used 294 by each provider. 296 +------+ 297 | | +------+ 298 | | | | (Network) 299 | |==+==| rtr1 |====|(Provider 1)|===== 300 | | | | | 301 | | | +------+ 302 | host | | 303 | | | 304 | | | +------+ 305 | | | | | (Network) 306 | | +==| rtr2 |====|(Provider 2)|===== 307 | | | | 308 +------+ +------+ 310 Figure 5: Simple Home Network with Two CPE Routers 312 The host has to select the source address from the prefixes of 313 Providers 1 or 2 when communicating with other hosts in Provider 1 or 314 2. The next issue is to select the correct next hop router, rtr1 or 315 rtr2 that can reach the correct provider, "Network Provider 1" or 316 "Network Provider 2". 318 3. Analysis of Source Address Dependent Routing 320 In this section we present an analysis of the scenarios of Section 2 321 and then discuss the relevance of SADR to the provisioning domains. 323 3.1. Scenarios Analysis 325 As in [RFC7157] we assume that the routers in Section 2 use Router 326 Advertisements to distribute default route and source address 327 prefixes supported in each next hop to the hosts or the gateway/CPE 328 router relays this information to the hosts. 330 Referring to the scenario in Figure 1, source address dependent 331 routing can present a solution to the problem of the host wishes to 332 reach a destination in network 2 and the host may choose rtr1 as the 333 default router. The solution assumes the host is correctly 334 configured. The host should be configured with the prefixes 335 supported in these next hops. This way the host having received many 336 prefixes will have the correct knowledge in selecting the right 337 source address and next hop when sending packets to remote 338 destinations. 340 Note that similar considerations apply to the scenario in Figure 4. 342 In the configuration of the scenario (Figure 3) it is also useful to 343 configure the host with the prefixes and source address prefixes they 344 support. This will enable the host to select the right prefix when 345 sending packets to the right next hop and avoid any ingress 346 filtering. 348 Source address dependent routing in the use case of specialized 349 egress routing may work as follows. The specialized service router 350 advertizes one or more specific prefixes with appropriate source 351 prefixes, e.g., to the CPE Router, rtr in Figure 3. The CPE router 352 in turn advertizes the specific service's prefixes and source 353 prefixes to the host. This will allow proper configuration at the 354 host so that the host can use the service by sending the packets with 355 the correct source and destination addresses. 357 Let us analyze the scenario in Figure 5. If a source address 358 dependent routing protocol is used, the two routers (rtr1 and rtr2) 359 are both able to route traffic correctly, no matter which next-hop 360 router and source address the host selects. In case the host chooses 361 the wrong next hop router, e.g., for provider 2 rtr1 is selected, 362 rtr1 will forward the traffic to rtr2 to be sent to network provider 363 2 and no ingress filtering will happen. 365 Note that home networks are expected to comply with requirements for 366 source address dependent routing and the routers will be configured 367 accordingly, no matter which routing protocol, e.g., OSPF is used 368 [I-D.ietf-homenet-hncp]. 370 This would work but with issues. The host traffic to provider 2 will 371 have to go over two links instead of one, i.e., the link bandwidth 372 will be halved. Another possibility is rtr1 can send an ICMPv6 373 Redirect message to the host to direct the traffic to rtr2. Host 374 would redirect provider 2 traffic to rtr2. 376 The problem with redirects is that ICMPv6 Redirect message can only 377 convey two addresses, i.e., in this case the router address, or rtr2 378 address and the destination address, or the destination host in 379 provider 2. That means the source address will not be communicated. 380 As a result, the host would send packets to the same destination 381 using both source addresses which causes rtr2 to send a redirect 382 message to rtr1, resulting in ping-pong redirects sent by rtr1 and 383 rtr2. 385 A solution to these issues is to configure the host with the source 386 address prefixes that the next hop supports. In homenets, each 387 interface of the host can be configured by its next hop router, so 388 that all that is needed is to add the information on source address 389 prefixes. This results in the hosts to select the right router no 390 matter what. 392 3.2. Provisioning Domains and SADR 394 Consistent set of network configuration information is called 395 provisioning domain (PvD). In case of multi-prefix multihoming 396 (MPMH), more than one provisioning domain is present on a single 397 link. In case of multi-prefix multiple interface (MPMI) 398 environments, elements of the same domain may be present on multiple 399 links. PvD aware nodes support association of configuration 400 information into PvDs and use these PvDs to serve requests for 401 network connections, e.g., choosing the right source address for the 402 packets. PvDs can be constructed from one of more DHCP or Router 403 Advertisement (RA) options carrying such information as PvD identity 404 and PvD container [I-D.ietf-mif-mpvd-ndp-support], 405 [I-D.ietf-mif-mpvd-dhcp-support]. PvDs constructed based on such 406 information are called explicit PvDs [RFC7556]. 408 Apart from PvD identity, PvD content may be encapsulated in separate 409 RA or DHCP options called PvD Container Option. These options are 410 placed in the container options of an explicit PvD. 412 Explicit PvDs may be received from different interfaces. Single PvD 413 may be accessible over one interface or simultaneously accessible 414 over multiple interfaces. Explicit PvDs may be scoped to a 415 configuration related to a particular interface, however in general 416 this may not apply. What matters is PvD ID provided that PvD ID is 417 authenticated by the node even in cases where the node has a single 418 connected interface. The authentication of the PvD ID should meet 419 the level required by the node policy. Single PvD information may be 420 received over multiple interfaces as long as PvD ID is the same. 421 This applies to the router advertisements (RAs) in which case a 422 multi-homed host (that is, with multiple interfaces) should trust a 423 message from a router on one interface to install a route to a 424 different router on another interface. 426 4. Discussion on Alternate Solutions 428 We presented many topologies in which a host with multiple interfaces 429 or a multihomed host is connected to various networks or Network 430 Providers which in turn may apply ingress routing. The scenario 431 analysis in Section 3.1 shows that in order to avoid packets getting 432 dropped due to ingress routing, source address dependent routing is 433 needed. Also, source address dependent routing should be supported 434 by routers throughout a site that has multiple exits. 436 In this section, we provide some alternate solutions vis a vis the 437 scenarios presented in Section 2. We start with source address 438 selection rule 5.5 ([RFC6724]) and the scenarios it solves and 439 continue with solutions that state exactly what information hosts 440 need in terms of new router advertisement options for correct source 441 address selection in those scenarios. No recommendation is made in 442 this section. 444 4.1. Router Advertisement Option 446 There is a need to configure the host not only with the prefixes but 447 also with the source prefixes the next hop routers support. Such a 448 configuration may avoid the host getting ingress/egress policy error 449 messages such as ICMP source address failure message. 451 If host configuration is done using router advertisement messages 452 then there is a need to define new router advertisement options for 453 source address dependent routing. These options include Route Prefix 454 with Source Address/Prefix Option. Other options such as Next Hop 455 Address with Route Prefix option and Next Hop Address with Source 456 Address and Route Prefix option will be considered in Section 4.2. 458 As discussed in Section 3.1, the scenario in Figure 5 can be solved 459 by defining a new router advertisement option. 461 If host configuration is done using DHCP then there is a need to 462 define new DHCP options for Route Prefix with Source Address/Prefix. 463 As mentioned above, DHCP server configuration is interface specific. 464 New DHCP options for source address dependent routing such as route 465 prefix and source prefix need to be configured for each interface 466 separately. 468 The scenario in Figure 5 can be solved by defining a new DHCP option. 470 4.2. Router Advertisement Option Set 472 The source address selection rule 5.5 may possibly be a solution for 473 selecting the right source addresses for each next hop but there are 474 cases where the next hop routers on each interface of the host are 475 not known by the host initially. Such use cases are out of scope. 476 Guidelines for use cases that require router advertisement option set 477 involving third party next hop addresses are also out of scope. 479 4.3. Source Address Selection Rule 5.5 481 One possible solution is the default source address selection Rule 482 5.5 in [RFC6724] which recommends to select source addresses 483 advertized by the next hop. Considering the above scenarios, we can 484 state that this rule can solve the problem in Figure 1, Figure 3 and 485 Figure 4. 487 Source address selection rules can be distributed by DHCP server 488 using DHCP Option OPTION_ADDRSEL_TABLE defined in [RFC7078]. 490 In case of DHCP based host configuration, DHCP server can configure 491 only the interface of the host to which it is directly connected. In 492 order for Rule 5.5 to apply on other interfaces the option should be 493 sent on those interfaces as well using [RFC7078]. 495 The default source address selection Rule 5.5 solves that problem 496 when an application sends a packet with an unspecified source 497 address. In the presence of two default routes, one route will be 498 chosen, and Rule 5.5 will make sure the right source address is used. 500 When the application selects a source address, i.e., the source 501 address is chosen before next-hop selection, even though the source 502 address is a way for the application to select the exit point, in 503 this case that purpose will not be served. In the presence of 504 multiple default routes, one will be picked, ignoring the source 505 address which was selected by the application because it is known 506 that IPv6 implementations are not required to remember which next- 507 hops advertised which prefixes. Therefore, the next-hop router may 508 not be the correct one, and the packets may be filtered. 510 This implies that the hosts should register which next-hop router 511 announced each prefix. It is required that RAs be sent by the 512 routers and that they contain PIO on all links. It is also required 513 that the hosts remember the source addresses of the routers that sent 514 PIOs together with the prefixes advertised. This can be achieved by 515 updating redirect rules specified in [RFC4861]. 516 [I-D.ietf-6man-multi-homed-host] further elaborates this to specify 517 to which router a host should present its transmission. 519 Source address dependent routing solution is not complete without 520 support from the edge routers. All routers in edge networks need to 521 be required to support routing based on not only the destination 522 address but also the source address. All edge routers need to be 523 required to satify BCP 38 filters. 525 5. Security Considerations 527 This document describes some use cases and thus brings no additional 528 security risks. Solution documents should further elaborate on 529 specific security considerations. 531 6. IANA Considerations 533 None. 535 7. Acknowledgements 537 In writing this document, we benefited from the ideas expressed by 538 the electronic mail discussion participants on 6man Working Group: 539 Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray 540 Hunter, Lorenzo Colitti and others. 542 Pierre Pfister proposed the scenario in Figure 5 as well as some text 543 for Rule 5.5. 545 The text on corporate VPN in Section 3 was provided by Brian 546 Carpenter. 548 8. References 550 8.1. Normative References 552 [I-D.ietf-6man-multi-homed-host] 553 Baker, F. and B. Carpenter, "Routing packets from hosts in 554 a multi-prefix network", draft-ietf-6man-multi-homed- 555 host-07 (work in progress), June 2016. 557 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 558 Defeating Denial of Service Attacks which employ IP Source 559 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 560 May 2000, . 562 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 563 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 564 2004, . 566 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 567 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 568 DOI 10.17487/RFC4861, September 2007, 569 . 571 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 572 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 573 . 575 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 576 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 577 June 2009, . 579 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 580 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 581 . 583 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 584 "Default Address Selection for Internet Protocol Version 6 585 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 586 . 588 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 589 Address Selection Policy Using DHCPv6", RFC 7078, 590 DOI 10.17487/RFC7078, January 2014, 591 . 593 8.2. Informative References 595 [I-D.baker-6man-multiprefix-default-route] 596 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 597 draft-baker-6man-multiprefix-default-route-00 (work in 598 progress), November 2007. 600 [I-D.baker-ipv6-isis-dst-src-routing] 601 Baker, F. and D. Lamparter, "IPv6 Source/Destination 602 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 603 routing-05 (work in progress), April 2016. 605 [I-D.baker-ipv6-ospf-dst-src-routing] 606 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 607 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 608 progress), August 2013. 610 [I-D.baker-rtgwg-src-dst-routing-use-cases] 611 Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and 612 Use Cases for Source/Destination Routing", draft-baker- 613 rtgwg-src-dst-routing-use-cases-02 (work in progress), 614 April 2016. 616 [I-D.huitema-multi6-ingress-filtering] 617 Huitema, C., "Ingress filtering compatibility for IPv6 618 multihomed sites", draft-huitema-multi6-ingress- 619 filtering-00 (work in progress), October 2004. 621 [I-D.ietf-homenet-hncp] 622 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 623 Control Protocol", draft-ietf-homenet-hncp-10 (work in 624 progress), November 2015. 626 [I-D.ietf-mif-mpvd-dhcp-support] 627 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 628 multiple provisioning domains in DHCPv6", draft-ietf-mif- 629 mpvd-dhcp-support-02 (work in progress), October 2015. 631 [I-D.ietf-mif-mpvd-ndp-support] 632 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 633 for multiple provisioning domains in IPv6 Neighbor 634 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 635 (work in progress), February 2016. 637 [I-D.naderi-ipv6-probing] 638 Naderi, H. and B. Carpenter, "Experience with IPv6 path 639 probing", draft-naderi-ipv6-probing-01 (work in progress), 640 April 2015. 642 [ISO.10589.1992] 643 International Organization for Standardization, 644 "Intermediate system to intermediate system intra-domain- 645 routing routine information exchange protocol for use in 646 conjunction with the protocol for providing the 647 connectionless-mode Network Service (ISO 8473), ISO 648 Standard 10589", ISO ISO.10589.1992, 1992. 650 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 651 Gill, "IPv4 Multihoming Practices and Limitations", 652 RFC 4116, DOI 10.17487/RFC4116, July 2005, 653 . 655 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 656 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 657 November 2005, . 659 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 660 and D. Wing, "IPv6 Multihoming without Network Address 661 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 662 . 664 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 665 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 666 . 668 Authors' Addresses 670 Behcet Sarikaya 671 Huawei USA 672 5340 Legacy Dr. Building 175 673 Plano, TX 75024 675 Email: sarikaya@ieee.org 677 Mohamed Boucadair 678 Orange 679 Rennes 35000 680 France 682 Email: mohamed.boucadair@orange.com