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