idnits 2.17.1 draft-sarikaya-6man-sadr-overview-05.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 20, 2015) is 3351 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC6106' is defined on line 634, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-03 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) ** Downref: Normative reference to an Experimental RFC: RFC 6296 ** Downref: Normative reference to an Informational RFC: RFC 7157 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-02 == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-01 == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-10 == Outdated reference: A later version (-02) exists of draft-ietf-mif-mpvd-dhcp-support-00 == Outdated reference: A later version (-03) exists of draft-ietf-mif-mpvd-ndp-support-00 == Outdated reference: A later version (-01) exists of draft-naderi-ipv6-probing-00 == Outdated reference: A later version (-01) exists of draft-sarikaya-dhc-6man-dhcpv6-sadr-00 Summary: 5 errors (**), 0 flaws (~~), 17 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: Standards Track February 20, 2015 5 Expires: August 24, 2015 7 Source Address Dependent Routing and Source Address Selection for IPv6 8 Hosts 9 draft-sarikaya-6man-sadr-overview-05 11 Abstract 13 This document presents the source address dependent routing from the 14 host perspective. Multihomed hosts and hosts with multiple 15 interfaces are considered. Different architectures are introduced 16 and with their help, why source address selection and next hop 17 resolution in view of source address dependent routing is needed is 18 explained. The document concludes with an informative guidelines on 19 the different solution approaches. 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 August 24, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. SADR Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Analysis of Source Address Dependent Routing . . . . . . . . 7 59 4.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 7 60 4.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 9 61 5. Guidelines on Standardization Work . . . . . . . . . . . . . 9 62 5.1. Source Address Selection Rule 5.5 . . . . . . . . . . . . 10 63 5.2. Router Advertisement Option . . . . . . . . . . . . . . . 10 64 5.3. Router Advertisement Option Set . . . . . . . . . . . . . 11 65 5.4. Other Solutions . . . . . . . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 9.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 BCP 38 recommends ingress traffic routing to prohibit Denial of 77 Service (DoS) attacks, i.e. datagrams which have source addresses 78 that do not match with the network where the host is attached are 79 discarded [RFC2827]. Avoiding packets to be dropped because of 80 ingress filtering is difficult especially in multihomed networks 81 where the host receives more than one prefix from the connected 82 Internet Service Providers (ISP) and may have more than one source 83 addresses. Based on BCP 38, BCP 84 introduced recommendations on the 84 routing system for multihomed networks [RFC3704]. 86 Recommendations on the routing system for ingress filtering such as 87 in BCP 84 inevitably involve source address checks. This leads us to 88 the source address dependent routing. Source address dependent 89 routing is an issue especially when the host is connected to a 90 multihomed network and is communicating with another host in another 91 multihomed network. In such a case, the communication can be broken 92 in both directions if ISPs apply ingress filtering and the datagrams 93 contain wrong source addresses 94 [I-D.huitema-multi6-ingress-filtering]. 96 Hosts with simultaneously active interfaces receive multiple prefixes 97 and have multiple source addresses. Datagrams originating from such 98 hosts carry greats risks to be dropped due to ingress filtering. 99 Source address selection algorithm needs to be careful to try to 100 avoid ingress filtering on the next-hop router [RFC6724]. 102 Many use cases have been reported for source/destination routing in 103 [I-D.baker-rtgwg-src-dst-routing-use-cases]. These use cases clearly 104 indicate that the multihomed host or Customer Premises Equipment 105 (CPE) router needs to be configured with correct source prefixes/ 106 addresses so that it can route packets upstream correctly to avoid 107 ingress filtering applied by an upstream ISP to drop the packets. 109 In multihomed networks there is a need to do source address based 110 routing if some providers are performing the ingress filtering 111 defined in BCP38 [RFC2827]. This requires the routers to consider 112 the source addresses as well as the destination addresses in 113 determining the next hop to send the packet to. 115 Based on the use cases defined in 116 [I-D.baker-rtgwg-src-dst-routing-use-cases], the routers may be 117 informed about the source addresses to use in routing using 118 extensions to the routing protocols like IS-IS defined in 119 [ISO.10589.1992] [I-D.baker-ipv6-isis-dst-src-routing] and OSPF 120 defined in [RFC5340] [I-D.baker-ipv6-ospf-dst-src-routing]. In this 121 document we describe the use cases for source address dependent 122 routing from the host perspective. 124 There are two cases. A host may have a single interface with 125 multiple addresses (from different prefixes or /64s). Each address 126 or prefix is connected to or coming from different exit routers, and 127 this case can be called multi-prefix multihoming (MPMH). A host may 128 have simultaneously connected multiple interfaces where each 129 interface is connected to a different exit router and this case can 130 be called multi-prefix multiple interface (MPMI). 132 It should be noted that Network Address and Port Translation (NAPT) 133 [RFC3022] in IPv4 and IPv6-to-IPv6 Network Prefix Translation (NPTv6) 134 [RFC6296] in IPv6 implement the functions of source address selection 135 and next-hop resolution and as such they address multihoming (and 136 hosts with multiple interfaces) requirements arising from source 137 address dependent routing [RFC7157]. In this case, the gateway 138 router or CPE router does the source address and next hop selection 139 for all the hosts connected to the router. However, for end-to-end 140 connectivity, NAPT and NPTv6 should be avoided and because of this, 141 NAPT and NPTv6 are left out of scope in this document. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. SADR Scenarios 151 Source address dependent routing can be facilitated at the host with 152 proper next hop and source address selection. For this, each router 153 connected to different interfaces of the host uses Router 154 Advertisements to distribute default route, next hop as well as 155 source address/prefix information to the host. 157 The use case shown in Figure 1 is multi-prefix multi interface use 158 case where rtr1 and rtr2 represent customer premises equipment/ 159 routers (CPE) and there are exit routers in both network 1 and 160 network 2. The issue in this case is ingress filtering. If the 161 packets from the host communicating with a remote destination are 162 routed to the wrong exit router, i.e. carry wrong source address, 163 they will get dropped. 165 +------+ +------+ ___________ 166 | | | | / \ 167 | |-----| rtr1 |=====/ network \ 168 | | | | \ 1 / 169 | | +------+ \___________/ 170 | | 171 | host | 172 | | 173 | | +------+ ___________ 174 | | | | / \ 175 | |=====| rtr2 |=====/ network \ 176 | | | | \ 2 / 177 +------+ +------+ \___________/ 179 Figure 1: multiple Interfaced Host with Two CPE Routers 181 Our next use case is shown in Figure 2. This use case is a multi- 182 prefix multihoming use case. rtr is CPE router which is connected to 183 two ISPs each advertising their own prefixes. In this case, the host 184 may have a single interface but it receives multiple prefixes from 185 the connected ISPs. Assuming that ISPs apply ingress filtering 186 policy the packets for any external communication from the host 187 should follow source address dependent routing in order to avoid 188 getting dropped. 190 +------+ | 191 | | | 192 | | |=====|(ISP1)|===== 193 | | +------+ | 194 | | | | | 195 | |=====| rtr |=====| 196 | host | | | | 197 | | +------+ | 198 | | | 199 | | | 200 | | |=====|(ISP2)|===== 201 | | | 202 +------+ | 204 Figure 2: Multihomed Host with Multiple CPE Routers 206 A variation of this use case is specialized egress routing. Upstream 207 networks offer different services with specific requirements, e.g. 208 video service. The hosts using this service need to use the 209 service's source and destination addresses. No other service will 210 accept this source address, i.e. those packets will be dropped 211 [I-D.baker-rtgwg-src-dst-routing-use-cases]. 213 ___________ +------+ 214 / \ +------+ | | 215 / network \ | | | | 216 \ 1 /--| rtr1 |----| | 217 \___________/ | | | | +------+ ___________ 218 +------+ | host | | | / \ 219 | |=====| rtr3 |=====/ network \ 220 ___________ | | | | \ 3 / 221 / \ +------+ | | +------+ \___________/ 222 / network \ | | | | 223 \ 2 /--| rtr2 |----| | 224 \___________/ | | | | 225 +------+ | | 226 +------+ 228 Figure 3: multiple Interfaced Host with Three CPE Routers 230 Next use case is shown in Figure 3. It is a variation of multi- 231 prefix multi interface use case above. rtr1, rtr2 and rtr3 are CPE 232 Routers. The networks apply ingress routing. Source address 233 dependent routing should be used to avoid any external communications 234 be dropped. 236 In the homenet scenario given in Figure 4, representing a simple home 237 network, there is a host connected to two CPEs which are connected to 238 ISP1 and ISP2, respectively. Each ISP provides a different prefix. 239 Also each router provides a different prefix to the host. The issue 240 in this scenario is also ingress filtering used by each ISP. 242 +------+ 243 | | +------+ 244 | | | | 245 | |==+==| rtr1 |=====|(ISP1)|===== 246 | | | | | 247 | | | +------+ 248 | host | | 249 | | | 250 | | | +------+ 251 | | | | | 252 | | +==| rtr2 |=====|(ISP2)|===== 253 | | | | 254 +------+ +------+ 256 Figure 4: Simple Home Network with Two CPE Routers 258 The host has to select the source address from the prefixes of ISP1 259 or ISP2 when communicating with other hosts in ISP1 or ISP2. The 260 next issue is to select the correct next hop router, rtr1 or rtr2 261 that can reach the right ISP, ISP1 or ISP2. 263 +------+ | +------+ 264 | | | | | 265 | | |-----| rtrF |=====ISP3 266 | | | | | 267 | | | +------+ 268 | | | 269 | host | | 270 | | | 271 | | +------+ | +------+ 272 | | | | | | |===== ISP2 273 | |=====| rtr |=====|=====| rtrE | 274 | | | | | | |===== ISP1 275 +------+ +------+ + +------+ 277 Figure 5: Shim6 Host with Two Routers 279 The last use case in Figure 5 is also a variation of multi-prefix 280 multihoming use case above. In this case rtrE is connected to two 281 ISPs. All ISPs are assumed to apply ingress routing. The host 282 receives prefixes from each ISP and starts communicating with 283 external hosts, e.g. H1, H2, etc. H1 and H2 may be accessible both 284 from ISP1 and ISP3. 286 The host receives multiple provider-allocated IPv6 address prefixes, 287 e.g. P1, P2 and P3 for ISP1, ISP2 and ISP3 and supports shim6 288 protocol [RFC5533]. rtr is a CPE router and the default router for 289 the host. rtr receives OSPF routes and has a default route for rtrE 290 and rtrF. 292 4. Analysis of Source Address Dependent Routing 294 In this section we present an analysis of the scenarios of Section 3 295 and then discuss the relevance of SADR to the provisioning domains. 297 4.1. Scenarios Analysis 299 As in [RFC7157] we assume that the routers in Section 3 use Router 300 Advertisements to distribute default route, next hop and source 301 address prefixes supported in each next hop to the hosts or the 302 gateway/CPE router relayes this information to the hosts. 304 Referring to the scenario in Figure 1, source address dependent 305 routing can present a solution to the problem of the host wishes to 306 reach a destination in network 2 and the host may choose rtr1 as the 307 default router. The solution should start with the correct 308 configuration of the host. The host should be configured with the 309 next hop addresses and the prefixes supported in these next hops. 310 This way the host having received many prefixes will have the correct 311 knowledge in selecting the right source address and next hop when 312 sending packets to remote destinations. 314 Note that similar considerations apply to the scenario in Figure 3. 316 In the configuration of the scenario in Figure 2 also it is useful to 317 configure the host with the next hop addresses and the prefixes and 318 source address prefixes they support. This will enable the host to 319 select the right prefix when sending packets to the right next hop 320 and avoid any ingress filtering. 322 Source address dependent routing in the use case of specialized 323 egress routing may work as follows. The specialized service router 324 advertizes one or more specific prefixes with appropriate source 325 prefixes, e.g. to the CPE Router, rtr in Figure 2. The CPE router in 326 turn advertizes the specific service's prefixes and source prefixes 327 to the host. This will allow proper configuration at the host so 328 that the host can use the service by sending the packets with the 329 correct source and destination addresses. 331 Let us analyze the use case in Figure 4. If a source address 332 dependent routing protocol is used, the two routers (rtr1 and rtr2) 333 are both able to route traffic correctly, no matter which next-hop 334 router and source address the host selects. In case the host chooses 335 the wrong next hop router, e.g. for ISP2 rtr1 is selected, rtr1 will 336 forward the traffic to rtr2 to be sent to ISP2 and no ingress 337 filtering will happen. 339 Note that home networks are expected to comply with requirements for 340 source address dependent routing and the routers will be configured 341 accordingly, no matter which routing protocol, e.g. OSPF is used 342 [I-D.ietf-homenet-hncp]. 344 This would work but with issues. The host traffic to ISP2 will have 345 to go over two links instead of one, i.e. the link bandwidth will be 346 halved. Another possibility is rtr1 can send an ICMPv6 Redirect 347 message to the host to direct the traffic to rtr2. Host would 348 redirect ISP2 traffic to rtr2. 350 The problem with redirects is that ICMPv6 Redirect message can only 351 convey two addresses, i.e. in this case the router address, or rtr2 352 address and the destination address, or the destination host in ISP2. 353 That means the source address will not be communicated. As a result, 354 the host would send packets to the same destination using both source 355 addresses which causes rtr2 to send a redirect message to rtr1, 356 resulting in ping-pong redirects sent by rtr1 and rtr2. 358 The best solution to these issues is to configure the host with both 359 the next hop and the source address prefixes that the next hop 360 supports. In homenets, each interface of the host can be configured 361 by its next hop, so that all that is needed is to add the information 362 on source address prefixes. This results in the hosts to select the 363 right router no matter what. 365 Finally, the use case in Figure 5 shows that even though all the 366 routers may have source address dependent routing support, the 367 packets still may get dropped. 369 The host in Figure 5 starts external communication with H1 and sends 370 the first packet with source address P3::iid. Since rtr has a 371 default route to rtrE it will use this default route in sending the 372 host's packet out towards rtrE. rtrE will route this packet to ISP1 373 and the packet will be dropped due to the ingress filtering. 375 A solution to this issue could be that rtrE having multiple routes to 376 H1 could use the path through rtrF and could direct the packet to the 377 other route, i.e. rtrF which would reach H1 in ISP3 without being 378 subject to ingress routing 379 [I-D.baker-6man-multiprefix-default-route]. 381 4.2. Provisioning Domains and SADR 383 Consistent set of network configuration information is called 384 provisioning domain (PvD). In case of multi-prefix multihoming 385 (MPMH), more than one provisioning domain is present on a single 386 link. In case of multi-prefix multiple interface (MPMI) 387 environments, elements of the same domain may be present on multiple 388 links. PvD aware nodes support association of configuration 389 information into PvDs and use these PvDs to serve requests for 390 network connections, e.g. chosing the right source address for the 391 packets. PvDs can be constructed from one of more DHCP or Router 392 Advertisement (RA) options carrying such information as PvD identity 393 and PvD container [I-D.ietf-mif-mpvd-ndp-support], 394 [I-D.ietf-mif-mpvd-dhcp-support]. PvDs constructed based on such 395 information are called explicit PvDs [I-D.ietf-mif-mpvd-arch]. 397 Apart from PvD identity, PvD content may be encapsulated in separate 398 RA or DHCP options called PvD Container Option. Examples of such 399 content are defined in [I-D.sarikaya-6man-next-hop-ra] and 400 [I-D.sarikaya-dhc-6man-dhcpv6-sadr]. They constitute the content or 401 parts of the content of an explicit PvD. 403 Explicit PvDs may be received from different interfaces. Single PvD 404 may be accessible over one interface or simulatenously accessible 405 over multiple interfaces. Explicit PvDs may be scoped to a 406 configuration related to a particular interface, however in general 407 this may not apply. What matters is PvD ID provided that PvD ID is 408 authenticated by the node even in cases where the node has a single 409 connected interface. The authentication of the PvD ID should meet 410 the level required by the node policy. Single PvD information may be 411 received over multiple interfaces as long as PvD ID is the same. 412 This applies to the router advertisements (RAs) in which case a 413 multi-homed host (that is, with multiple interfaces) should trust a 414 message from a router on one interface to install a route to a 415 different router on another interface. 417 5. Guidelines on Standardization Work 419 We presented many topologies in which a host with multiple interfaces 420 or a multihomed host is connected to various networks or ISPs which 421 in turn may apply ingress routing. Our scenario analysis showed that 422 in order to avoid packets getting dropped due to ingress routing, 423 source address dependent routing is needed. Also, source address 424 dependent routing should be supported by routers throughout a site 425 that has multiple exits. 427 In this section, we provide informative guidelines on different 428 existing and future solutions vis a vis the scenarios presented in 429 Section 3. We start with source address selection rule 5.5 and the 430 scenarios it solves and continue with solutions that state exactly 431 what information hosts need in terms of new router advertisement 432 options for correct source address selection in those scenarios. 434 5.1. Source Address Selection Rule 5.5 436 One possible solution is the default source address selection Rule 437 5.5 in [RFC6724] which recommends to select source addresses 438 advertized by the next hop. Considering the above scenarios, we can 439 state that this rule can solve the problem in Figure 1, Figure 2 and 440 Figure 3. 442 In using Rule 5.5 the following guidelines should be kept in mind. 443 Source address selection rules can be distributed by DHCP server 444 using DHCP Option OPTION_ADDRSEL_TABLE defined in [RFC7078]. 446 In case of DHCP based host configuration, DHCP server can configure 447 only the interface of the host to which it is directly connected. In 448 order for Rule 5.5 to apply on other interfaces the option should be 449 sent on those interfaces as well using [RFC7078]. 451 The default source address selection Rule 5.5 solves that problem 452 when an application sends a packet with an unspecified source 453 address. In the presence of two default routes, one route will be 454 chosen, and Rule 5.5 will make sure the right source address is used. 456 When the application selects a source address, i.e. the source 457 address is chosen before next-hop selection, even though the source 458 address is a way for the application to select the exit point, in 459 this case that purpose will not be served. In the presence of 460 multiple default routes, one will be picked, ignoring the source 461 address which was selected by the application because it is known 462 that IPv6 implementations are not required to remember which next- 463 hops advertised which prefixes. Therefore, the next-hop router may 464 not be the correct one, and the packets may be filtered. 466 This implies that the hosts should register which next-hop router 467 announced each prefix. 469 5.2. Router Advertisement Option 471 There is a need to configure the host not only with the next hops and 472 their prefixes but also with the source prefixes they support. Such 473 a configuration may avoid the host getting ingress/egress policy 474 error messages such as ICMP source address failure message. 476 If host configuration is done using router advertisement messages 477 then there is a need to define new router advertisement options for 478 source address dependent routing. These options include Route Prefix 479 with Source Address/Prefix Option. Other options such as Next Hop 480 Address with Route Prefix option and Next Hop Address with Source 481 Address and Route Prefix option will be considered in Section 5.3. 483 As we observed in Section 4.1, the scenario in Figure 4 can be solved 484 by defining a new router advertisement option, i.e. Route Prefix 485 with Source Address/Prefix Option as defined in Section 13 in 486 [I-D.sarikaya-6man-next-hop-ra]. 488 If host configuration is done using DHCP then there is a need to 489 define new DHCP options for Route Prefix with Source Address/Prefix. 490 As mentioned above, DHCP server configuration is interface specific. 491 New DHCP options for source address dependent routing such as route 492 prefix and source prefix need to be configured for each interface 493 separately. 495 The scenario in Figure 4 can be solved by defining a new DHCP option, 496 i.e. Route Prefix with Source Address/Prefix Option, if DHCP 497 configuration is a must. 499 5.3. Router Advertisement Option Set 501 The source address selection rule 5.5 may possibly be a solution for 502 selecting the right source addresses for each next hop but there are 503 cases where the next hop routers on each interface of the host are 504 not known by the host initially. A typical use case is the Virtual 505 Private Network (VPN) access. The host in VPN access is configured 506 by the VPN router which should also give the information on the next 507 hop routers and host needs to solicit the router advertisment using 508 RS/RA exchange. 510 The solution then calls for configuring hosts with Next Hop Addresses 511 and the Route Prefix, Source Address/Prefixes that they support. A 512 set of new router advertisement options as in 513 [I-D.sarikaya-6man-next-hop-ra] needs to be defined. 515 The guideline for this solution is that routers in the whole site 516 should be configured to provide the correct configuration information 517 to the hosts. This may result is fate sharing in which one router, 518 e.g. VPN router failure may effect the whole system. In order to 519 avoid such failures, the availability and reliability of routing 520 paths need to be provided using Virtual Router Redundancy Protocol 521 (VRRP) which is widely deployed in industry. 523 Additional guideline for this solution is that regular router 524 operation calls for unsolicited router advertisements which are 525 commonly available in shared links. Also this type of operation does 526 not require inter router communication and thus avoids the fate 527 sharing, i.e. each router can autonomously operate independent of 528 other routers. 530 If host configuration is done using DHCP then there is a need to 531 define new DHCP options for Next Hop Address, Route Prefix with 532 Source Address/Prefix. Since DHCP server configuration is interface 533 specific, new DHCP options for source address dependent routing such 534 as next hop address, route prefix and source prefix need to be 535 configured for each interface separately. 537 The scenarios in Figure 1, Figure 2, Figure 3 and Figure 4 as well as 538 the ones involving the next hop addresses can be solved by defining 539 new DHCP options as in [I-D.sarikaya-dhc-6man-dhcpv6-sadr]. 541 5.4. Other Solutions 543 So far we have singled out the scenario in Figure 5. All the above 544 solutions do not work in this case. This brings us the issue of IP 545 path probing [I-D.naderi-ipv6-probing]. 547 For a given destination, the host selects a source address and a next 548 hop and sends its packet. When the selected path fails, in case of 549 IP probing, the host can probe all available paths until finding one 550 that works. 552 The guideline in probing is Source Address Dependent Routing (SADR) 553 should be used, i.e. it is a necessary tool. Basically, SADR saves 554 time in eliminating wrong paths, i.e. sending the packets to the 555 wrong exit router. If SADR is not taken into account correctly the 556 host will end up wasting resources trying to explore paths that are 557 certain to fail. 559 6. Security Considerations 561 This document describes some use cases and thus brings no new 562 security risks to the Internet. 564 7. IANA Considerations 566 None. 568 8. Acknowledgements 570 In writing this document, we benefited from the ideas expressed by 571 the electronic mail discussion participants on 6man Working Group: 572 Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray 573 Hunter, Lorenzo Colitti and others. Pierre Pfister proposed the 574 scenario in Figure 4 as well as some text for Rule 5.5. 576 9. References 578 9.1. Normative References 580 [I-D.ietf-homenet-hncp] 581 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 582 Control Protocol", draft-ietf-homenet-hncp-03 (work in 583 progress), January 2015. 585 [ISO.10589.1992] 586 International Organization for Standardization, 587 "Intermediate system to intermediate system intra-domain- 588 routing routine information exchange protocol for use in 589 conjunction with the protocol for providing the 590 connectionless-mode Network Service (ISO 8473), ISO 591 Standard 10589", ISO ISO.10589.1992, 1992. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 597 June 1999. 599 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 600 Defeating Denial of Service Attacks which employ IP Source 601 Address Spoofing", BCP 38, RFC 2827, May 2000. 603 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 604 Address Translator (Traditional NAT)", RFC 3022, January 605 2001. 607 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 608 Networks", BCP 84, RFC 3704, March 2004. 610 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 611 Neighbor Discovery (SEND)", RFC 3971, March 2005. 613 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 614 More-Specific Routes", RFC 4191, November 2005. 616 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 617 "Internet Group Management Protocol (IGMP) / Multicast 618 Listener Discovery (MLD)-Based Multicast Forwarding 619 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 621 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 622 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 623 September 2007. 625 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 626 Address Autoconfiguration", RFC 4862, September 2007. 628 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 629 for IPv6", RFC 5340, July 2008. 631 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 632 Shim Protocol for IPv6", RFC 5533, June 2009. 634 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 635 "IPv6 Router Advertisement Options for DNS Configuration", 636 RFC 6106, November 2010. 638 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 639 Translation", RFC 6296, June 2011. 641 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 642 "Default Address Selection for Internet Protocol Version 6 643 (IPv6)", RFC 6724, September 2012. 645 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 646 Address Selection Policy Using DHCPv6", RFC 7078, January 647 2014. 649 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 650 Wing, "IPv6 Multihoming without Network Address 651 Translation", RFC 7157, March 2014. 653 9.2. Informative References 655 [I-D.baker-6man-multiprefix-default-route] 656 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 657 draft-baker-6man-multiprefix-default-route-00 (work in 658 progress), November 2007. 660 [I-D.baker-ipv6-isis-dst-src-routing] 661 Baker, F. and D. Lamparter, "IPv6 Source/Destination 662 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 663 routing-02 (work in progress), October 2014. 665 [I-D.baker-ipv6-ospf-dst-src-routing] 666 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 667 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 668 progress), August 2013. 670 [I-D.baker-rtgwg-src-dst-routing-use-cases] 671 Baker, F., "Requirements and Use Cases for Source/ 672 Destination Routing", draft-baker-rtgwg-src-dst-routing- 673 use-cases-01 (work in progress), October 2014. 675 [I-D.huitema-multi6-ingress-filtering] 676 Huitema, C., "Ingress filtering compatibility for IPv6 677 multihomed sites", draft-huitema-multi6-ingress- 678 filtering-00 (work in progress), October 2004. 680 [I-D.ietf-mif-mpvd-arch] 681 Anipko, D., "Multiple Provisioning Domain Architecture", 682 draft-ietf-mif-mpvd-arch-10 (work in progress), February 683 2015. 685 [I-D.ietf-mif-mpvd-dhcp-support] 686 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 687 multiple provisioning domains in DHCPv6", draft-ietf-mif- 688 mpvd-dhcp-support-00 (work in progress), August 2014. 690 [I-D.ietf-mif-mpvd-ndp-support] 691 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 692 for multiple provisioning domains in IPv6 Neighbor 693 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-00 694 (work in progress), August 2014. 696 [I-D.naderi-ipv6-probing] 697 Naderi, H. and B. Carpenter, "Experience with IPv6 path 698 probing", draft-naderi-ipv6-probing-00 (work in progress), 699 October 2014. 701 [I-D.sarikaya-6man-next-hop-ra] 702 Sarikaya, B., "IPv6 RA Options for Next Hop Routes", 703 draft-sarikaya-6man-next-hop-ra-04 (work in progress), 704 December 2014. 706 [I-D.sarikaya-dhc-6man-dhcpv6-sadr] 707 Sarikaya, B., "DHCPv6 Route Options for Source Address 708 Dependent Routing", draft-sarikaya-dhc-6man-dhcpv6-sadr-00 709 (work in progress), December 2014. 711 Author's Address 713 Behcet Sarikaya 714 Huawei USA 715 5340 Legacy Dr. Building 175 716 Plano, TX 75024 718 Email: sarikaya@ieee.org