idnits 2.17.1 draft-sarikaya-6man-sadr-overview-10.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 5, 2016) is 2846 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5533' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-6man-multiprefix-default-route' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'I-D.naderi-ipv6-probing' is defined on line 634, 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 6, 2017 Orange 6 July 5, 2016 8 Source Address Dependent Routing and Source Address Selection for IPv6 9 Hosts: Problem Space Overview 10 draft-sarikaya-6man-sadr-overview-10 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 6, 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 does not make any solution recommendations. 155 2. Source Address Dependent Routing (SADR) Scenarios 157 SADR can be facilitated at the host with proper next-hop and source 158 address selection. For this, each router connected to different 159 interfaces of the host uses Router Advertisements (RAs, [RFC4861]) to 160 distribute default route, next hop as well as source address/prefix 161 information to the host. As a reminder, while Prefix Information 162 Option (PIO) is defined in [RFC4861], Route Information Option (RIO) 163 is defined in [RFC4191]. 165 2.1. Scenario 1: Multi-Prefix Multi-Interface 167 The scenario shown in Figure 1 is multi-prefix multi interface where 168 "rtr1" and "rtr2" represent customer premises equipment/routers (CPE) 169 and there are exit routers in both "network 1" and "network 2". If 170 the packets from the host communicating with a remote destination are 171 routed to the wrong exit router, i.e., carry wrong source address, 172 they will get dropped due to ingress filtering. 174 +------+ +------+ ___________ 175 | | | | / \ 176 | |-----| rtr1 |=====/ network \ 177 | | | | \ 1 / 178 | | +------+ \___________/ 179 | | 180 | host | 181 | | 182 | | +------+ ___________ 183 | | | | / \ 184 | |=====| rtr2 |=====/ network \ 185 | | | | \ 2 / 186 +------+ +------+ \___________/ 188 Figure 1: Multiple Interfaced Host with Two CPE Routers 190 There is a variant of Figure 1 that is often referred to as a 191 corporate VPN, i.e., a secure tunnel from the host to a router 192 attached to a corporate network. In this case "rtr2" gives access 193 directly to the corporate network, and the link from the host to 194 "rtr2" is a secure tunnel (for example an IPsec tunnel). The 195 interface is therefore a virtual interface, with its own IP address/ 196 prefix assigned by the corporate network. 198 +------+ +------+ ___________ 199 | |-----| rtr1 | / \ 200 | ==========\\ |=====/ network \ 201 | |-----| || | \ 1 / 202 | | +--||--+ \___________/ 203 | | || 204 | host | || 205 | | || 206 | | +--||--+ ___________ 207 | | | | / corporate \ 208 | | | rtr2 |=====/ network \ 209 | | | | \ 2 / 210 +------+ +------+ \___________/ 212 Figure 2: VPN case 214 There are at least two sub-cases: 216 a. Dedicated forwarding entries are created in the host such that 217 only traffic directed to the corporate network is sent to "rtr2"; 218 everything else is sent to "rtr1". 220 b. All traffic is sent to "rtr2" and then routed to the Internet if 221 necessary. This case doesn't need host routes but leads to 222 unnecessary traffic and latency because of the path stretch via 223 rtr2. 225 2.2. Scenario 2: Multi-Prefix Multihoming 227 Another scenario is shown in Figure 3. This one is a multi-prefix 228 multihoming use case. "rtr" is CPE router which is connected to two 229 Network Providers, each advertising their own prefixes. In this 230 case, the host may have a single interface but it receives multiple 231 prefixes from the connected Network Provider. Assuming that 232 providers apply ingress filtering policy the packets for any external 233 communication from the host should follow source address dependent 234 routing in order to avoid getting dropped. 236 +------+ | 237 | | | (Network) 238 | | |=====|(Provider 1)|===== 239 | | +------+ | 240 | | | | | 241 | |=====| rtr |=====| 242 | host | | | | 243 | | +------+ | 244 | | | 245 | | | (Network) 246 | | |=====|(Provider 2)|===== 247 | | | 248 +------+ | 250 Figure 3: Multihomed Host with Multiple CPE Routers 252 2.3. Scenario 3: Service-specific Egress Routing 254 A variation of the scenario in Section 2.2 is: specialized egress 255 routing. Upstream networks offer different services with specific 256 requirements, e.g., VoIP or IPTV. The hosts using this service need 257 to use the service's source and destination addresses. No other 258 service will accept this source address, i.e., those packets will be 259 dropped [I-D.baker-rtgwg-src-dst-routing-use-cases]. 261 ___________ +------+ 262 / \ +------+ | | 263 / network \ | | | | 264 \ 1 /--| rtr1 |----| | 265 \___________/ | | | | +------+ ___________ 266 +------+ | host | | | / \ 267 | |=====| rtr3 |=====/ network \ 268 ___________ | | | | \ 3 / 269 / \ +------+ | | +------+ \___________/ 270 / network \ | | | | 271 \ 2 /--| rtr2 |----| | 272 \___________/ | | | | 273 +------+ | | 274 +------+ 276 Figure 4: Multiple Interfaced Host with Three CPE Routers 278 The scenario shown in Figure 4 s a variation of multi-prefix multi 279 interface scenario (Section 2.1). "rtr1", "rtr2" and "rtr3" are CPE 280 routers. The networks apply ingress routing. Source address 281 dependent routing should be used to avoid any external communications 282 be dropped. 284 2.4. Scenario 4: Home Network (Homenet) 286 In the homenet scenario depicted in Figure 5, representing a simple 287 home network, there is a host connected to two CPEs which are 288 connected to providers 1 and 2, respectively. Each network delegates 289 a different prefix. Also each router provides a different prefix to 290 the host. The issue in this scenario is also ingress filtering used 291 by each provider. 293 +------+ 294 | | +------+ 295 | | | | (Network) 296 | |==+==| rtr1 |====|(Provider 1)|===== 297 | | | | | 298 | | | +------+ 299 | host | | 300 | | | 301 | | | +------+ 302 | | | | | (Network) 303 | | +==| rtr2 |====|(Provider 2)|===== 304 | | | | 305 +------+ +------+ 307 Figure 5: Simple Home Network with Two CPE Routers 309 The host has to select the source address from the prefixes of 310 Providers 1 or 2 when communicating with other hosts in Provider 1 or 311 2. The next issue is to select the correct next hop router, rtr1 or 312 rtr2 that can reach the correct provider, "Network Provider 1" or 313 "Network Provider 2". 315 3. Analysis of Source Address Dependent Routing 317 In this section we present an analysis of the scenarios of Section 2 318 and then discuss the relevance of SADR to the provisioning domains. 320 3.1. Scenarios Analysis 322 As in [RFC7157] we assume that the routers in Section 2 use Router 323 Advertisements to distribute default route and source address 324 prefixes supported in each next hop to the hosts or the gateway/CPE 325 router relays this information to the hosts. 327 Referring to the scenario in Figure 1, source address dependent 328 routing can present a solution to the problem of the host wishes to 329 reach a destination in network 2 and the host may choose rtr1 as the 330 default router. The solution assumes the host is correctly 331 configured. The host should be configured with the prefixes 332 supported in these next hops. This way the host having received many 333 prefixes will have the correct knowledge in selecting the right 334 source address and next hop when sending packets to remote 335 destinations. 337 Note that similar considerations apply to the scenario in Figure 4. 339 In the configuration of the scenario (Figure 3) it is also useful to 340 configure the host with the prefixes and source address prefixes they 341 support. This will enable the host to select the right prefix when 342 sending packets to the right next hop and avoid any ingress 343 filtering. 345 Source address dependent routing in the use case of specialized 346 egress routing may work as follows. The specialized service router 347 advertizes one or more specific prefixes with appropriate source 348 prefixes, e.g., to the CPE Router, rtr in Figure 3. The CPE router 349 in turn advertizes the specific service's prefixes and source 350 prefixes to the host. This will allow proper configuration at the 351 host so that the host can use the service by sending the packets with 352 the correct source and destination addresses. 354 Let us analyze the scenario in Figure 5. If a source address 355 dependent routing protocol is used, the two routers (rtr1 and rtr2) 356 are both able to route traffic correctly, no matter which next-hop 357 router and source address the host selects. In case the host chooses 358 the wrong next hop router, e.g., for provider 2 rtr1 is selected, 359 rtr1 will forward the traffic to rtr2 to be sent to network provider 360 2 and no ingress filtering will happen. 362 Note that home networks are expected to comply with requirements for 363 source address dependent routing and the routers will be configured 364 accordingly, no matter which routing protocol, e.g., OSPF is used 365 [I-D.ietf-homenet-hncp]. 367 This would work but with issues. The host traffic to provider 2 will 368 have to go over two links instead of one, i.e., the link bandwidth 369 will be halved. Another possibility is rtr1 can send an ICMPv6 370 Redirect message to the host to direct the traffic to rtr2. Host 371 would redirect provider 2 traffic to rtr2. 373 The problem with redirects is that ICMPv6 Redirect message can only 374 convey two addresses, i.e., in this case the router address, or rtr2 375 address and the destination address, or the destination host in 376 provider 2. That means the source address will not be communicated. 377 As a result, the host would send packets to the same destination 378 using both source addresses which causes rtr2 to send a redirect 379 message to rtr1, resulting in ping-pong redirects sent by rtr1 and 380 rtr2. 382 A solution to these issues is to configure the host with the source 383 address prefixes that the next hop supports. In homenets, each 384 interface of the host can be configured by its next hop router, so 385 that all that is needed is to add the information on source address 386 prefixes. This results in the hosts to select the right router no 387 matter what. 389 3.2. Provisioning Domains and SADR 391 Consistent set of network configuration information is called 392 provisioning domain (PvD). In case of multi-prefix multihoming 393 (MPMH), more than one provisioning domain is present on a single 394 link. In case of multi-prefix multiple interface (MPMI) 395 environments, elements of the same domain may be present on multiple 396 links. PvD aware nodes support association of configuration 397 information into PvDs and use these PvDs to serve requests for 398 network connections, e.g., choosing the right source address for the 399 packets. PvDs can be constructed from one of more DHCP or Router 400 Advertisement (RA) options carrying such information as PvD identity 401 and PvD container [I-D.ietf-mif-mpvd-ndp-support], 402 [I-D.ietf-mif-mpvd-dhcp-support]. PvDs constructed based on such 403 information are called explicit PvDs [RFC7556]. 405 Apart from PvD identity, PvD content may be encapsulated in separate 406 RA or DHCP options called PvD Container Option. These options are 407 placed in the container options of an explicit PvD. 409 Explicit PvDs may be received from different interfaces. Single PvD 410 may be accessible over one interface or simultaneously accessible 411 over multiple interfaces. Explicit PvDs may be scoped to a 412 configuration related to a particular interface, however in general 413 this may not apply. What matters is PvD ID provided that PvD ID is 414 authenticated by the node even in cases where the node has a single 415 connected interface. The authentication of the PvD ID should meet 416 the level required by the node policy. Single PvD information may be 417 received over multiple interfaces as long as PvD ID is the same. 418 This applies to the router advertisements (RAs) in which case a 419 multi-homed host (that is, with multiple interfaces) should trust a 420 message from a router on one interface to install a route to a 421 different router on another interface. 423 4. Discussion on Alternate Solutions 425 We presented many topologies in which a host with multiple interfaces 426 or a multihomed host is connected to various networks or Network 427 Providers which in turn may apply ingress routing. The scenario 428 analysis in Section 3.1 shows that in order to avoid packets getting 429 dropped due to ingress routing, source address dependent routing is 430 needed. Also, source address dependent routing should be supported 431 by routers throughout a site that has multiple exits. 433 In this section, we provide some alternate solutions vis a vis the 434 scenarios presented in Section 2. We start with source address 435 selection rule 5.5 ([RFC6724]) and the scenarios it solves and 436 continue with solutions that state exactly what information hosts 437 need in terms of new router advertisement options for correct source 438 address selection in those scenarios. No recommendation is made in 439 this section. 441 4.1. Router Advertisement Option 443 There is a need to configure the host not only with the prefixes but 444 also with the source prefixes the next hop routers support. Such a 445 configuration may avoid the host getting ingress/egress policy error 446 messages such as ICMP source address failure message. 448 If host configuration is done using router advertisement messages 449 then there is a need to define new router advertisement options for 450 source address dependent routing. These options include Route Prefix 451 with Source Address/Prefix Option. Other options such as Next Hop 452 Address with Route Prefix option and Next Hop Address with Source 453 Address and Route Prefix option will be considered in Section 4.2. 455 As discussed in Section 3.1, the scenario in Figure 5 can be solved 456 by defining a new router advertisement option. 458 If host configuration is done using DHCP then there is a need to 459 define new DHCP options for Route Prefix with Source Address/Prefix. 460 As mentioned above, DHCP server configuration is interface specific. 461 New DHCP options for source address dependent routing such as route 462 prefix and source prefix need to be configured for each interface 463 separately. 465 The scenario in Figure 5 can be solved by defining a new DHCP option. 467 4.2. Router Advertisement Option Set 469 The source address selection rule 5.5 may possibly be a solution for 470 selecting the right source addresses for each next hop but there are 471 cases where the next hop routers on each interface of the host are 472 not known by the host initially. Such use cases are out of scope. 473 Guidelines for use cases that require router advertisement option set 474 involving third party next hop addresses are also out of scope. 476 4.3. Source Address Selection Rule 5.5 478 One possible solution is the default source address selection Rule 479 5.5 in [RFC6724] which recommends to select source addresses 480 advertized by the next hop. Considering the above scenarios, we can 481 state that this rule can solve the problem in Figure 1, Figure 3 and 482 Figure 4. 484 Source address selection rules can be distributed by DHCP server 485 using DHCP Option OPTION_ADDRSEL_TABLE defined in [RFC7078]. 487 In case of DHCP based host configuration, DHCP server can configure 488 only the interface of the host to which it is directly connected. In 489 order for Rule 5.5 to apply on other interfaces the option should be 490 sent on those interfaces as well using [RFC7078]. 492 The default source address selection Rule 5.5 solves that problem 493 when an application sends a packet with an unspecified source 494 address. In the presence of two default routes, one route will be 495 chosen, and Rule 5.5 will make sure the right source address is used. 497 When the application selects a source address, i.e., the source 498 address is chosen before next-hop selection, even though the source 499 address is a way for the application to select the exit point, in 500 this case that purpose will not be served. In the presence of 501 multiple default routes, one will be picked, ignoring the source 502 address which was selected by the application because it is known 503 that IPv6 implementations are not required to remember which next- 504 hops advertised which prefixes. Therefore, the next-hop router may 505 not be the correct one, and the packets may be filtered. 507 This implies that the hosts should register which next-hop router 508 announced each prefix. It is required that RAs be sent by the 509 routers and that they contain PIO on all links. It is also required 510 that the hosts remember the source addresses of the routers that sent 511 PIOs together with the prefixes advertised. This can be achieved by 512 updating redirect rules specified in [RFC4861]. 513 [I-D.ietf-6man-multi-homed-host] further elaborates this to specify 514 to which router a host should present its transmission. 516 Source address dependent routing solution is not complete without 517 support from the edge routers. All routers in edge networks need to 518 be required to support routing based on not only the destination 519 address but also the source address. All edge routers need to be 520 required to satify BCP 38 filters. 522 5. Security Considerations 524 This document describes some use cases and thus brings no additional 525 security risks. Solution documents should further elaborate on 526 specific security considerations. 528 6. IANA Considerations 530 None. 532 7. Acknowledgements 534 In writing this document, we benefited from the ideas expressed by 535 the electronic mail discussion participants on 6man Working Group: 536 Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray 537 Hunter, Lorenzo Colitti and others. 539 Pierre Pfister proposed the scenario in Figure 5 as well as some text 540 for Rule 5.5. 542 The text on corporate VPN in Section 3 was provided by Brian 543 Carpenter. 545 8. References 547 8.1. Normative References 549 [I-D.ietf-6man-multi-homed-host] 550 Baker, F. and B. Carpenter, "Routing packets from hosts in 551 a multi-prefix network", draft-ietf-6man-multi-homed- 552 host-07 (work in progress), June 2016. 554 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 555 Defeating Denial of Service Attacks which employ IP Source 556 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 557 May 2000, . 559 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 560 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 561 2004, . 563 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 564 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 565 DOI 10.17487/RFC4861, September 2007, 566 . 568 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 569 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 570 . 572 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 573 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 574 June 2009, . 576 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 577 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 578 . 580 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 581 "Default Address Selection for Internet Protocol Version 6 582 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 583 . 585 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 586 Address Selection Policy Using DHCPv6", RFC 7078, 587 DOI 10.17487/RFC7078, January 2014, 588 . 590 8.2. Informative References 592 [I-D.baker-6man-multiprefix-default-route] 593 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 594 draft-baker-6man-multiprefix-default-route-00 (work in 595 progress), November 2007. 597 [I-D.baker-ipv6-isis-dst-src-routing] 598 Baker, F. and D. Lamparter, "IPv6 Source/Destination 599 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 600 routing-05 (work in progress), April 2016. 602 [I-D.baker-ipv6-ospf-dst-src-routing] 603 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 604 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 605 progress), August 2013. 607 [I-D.baker-rtgwg-src-dst-routing-use-cases] 608 Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and 609 Use Cases for Source/Destination Routing", draft-baker- 610 rtgwg-src-dst-routing-use-cases-02 (work in progress), 611 April 2016. 613 [I-D.huitema-multi6-ingress-filtering] 614 Huitema, C., "Ingress filtering compatibility for IPv6 615 multihomed sites", draft-huitema-multi6-ingress- 616 filtering-00 (work in progress), October 2004. 618 [I-D.ietf-homenet-hncp] 619 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 620 Control Protocol", draft-ietf-homenet-hncp-10 (work in 621 progress), November 2015. 623 [I-D.ietf-mif-mpvd-dhcp-support] 624 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 625 multiple provisioning domains in DHCPv6", draft-ietf-mif- 626 mpvd-dhcp-support-02 (work in progress), October 2015. 628 [I-D.ietf-mif-mpvd-ndp-support] 629 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 630 for multiple provisioning domains in IPv6 Neighbor 631 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 632 (work in progress), February 2016. 634 [I-D.naderi-ipv6-probing] 635 Naderi, H. and B. Carpenter, "Experience with IPv6 path 636 probing", draft-naderi-ipv6-probing-01 (work in progress), 637 April 2015. 639 [ISO.10589.1992] 640 International Organization for Standardization, 641 "Intermediate system to intermediate system intra-domain- 642 routing routine information exchange protocol for use in 643 conjunction with the protocol for providing the 644 connectionless-mode Network Service (ISO 8473), ISO 645 Standard 10589", ISO ISO.10589.1992, 1992. 647 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 648 Gill, "IPv4 Multihoming Practices and Limitations", 649 RFC 4116, DOI 10.17487/RFC4116, July 2005, 650 . 652 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 653 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 654 November 2005, . 656 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 657 and D. Wing, "IPv6 Multihoming without Network Address 658 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 659 . 661 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 662 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 663 . 665 Authors' Addresses 667 Behcet Sarikaya 668 Huawei USA 669 5340 Legacy Dr. Building 175 670 Plano, TX 75024 672 Email: sarikaya@ieee.org 674 Mohamed Boucadair 675 Orange 676 Rennes 35000 677 France 679 Email: mohamed.boucadair@orange.com