idnits 2.17.1 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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 date (March 18, 2013) is 4056 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-6man-addr-select-considerations-04 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-08 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force O. Troan, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational D. Miles 5 Expires: September 19, 2013 Alcatel-Lucent 6 S. Matsushima 7 Softbank Telecom 8 T. Okimoto 9 NTT West 10 D. Wing 11 Cisco 12 March 18, 2013 14 IPv6 Multihoming without Network Address Translation 15 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 17 Abstract 19 Network Address and Port Translation (NAPT) works well for conserving 20 global addresses and addressing multihoming requirements, because an 21 IPv4 NAPT router implements three functions: source address 22 selection, next-hop resolution and optionally DNS resolution. For 23 IPv6 hosts one approach could be the use of NPTv6. However, NAT 24 should be avoided, if at all possible, to permit transparent end-to- 25 end connectivity. In this document, we analyze the use cases of 26 multihoming. We also describe functional requirements and possible 27 solutions for multihoming without the use of NAT in IPv6 for hosts 28 and small IPv6 networks that would otherwise be unable to meet 29 minimum IPv6 allocation criteria. We conclude that DHCPv6 based 30 solutions are suitable to solve the multihoming issues, described in 31 this document, while NPTv6 may be required as an intermediate 32 solution. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 19, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 6 70 3.1. Classification of network scenarios for multihomed host . 6 71 3.2. Multihomed network environment . . . . . . . . . . . . . . 9 72 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 10 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 11 75 4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 12 76 5. Problem statement and analysis . . . . . . . . . . . . . . . . 12 77 5.1. Source address selection . . . . . . . . . . . . . . . . . 12 78 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 13 79 5.3. DNS recursive name server selection . . . . . . . . . . . 13 80 6. Implementation approach . . . . . . . . . . . . . . . . . . . 14 81 6.1. Source address selection . . . . . . . . . . . . . . . . . 14 82 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 15 83 6.3. DNS recursive name server selection . . . . . . . . . . . 15 84 6.4. Other algorithms available in RFCs . . . . . . . . . . . . 16 85 7. Considerations for MHMP deployment . . . . . . . . . . . . . . 16 86 7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 17 87 7.2. Co-existence considerations . . . . . . . . . . . . . . . 17 88 7.3. Policy collision consideration . . . . . . . . . . . . . . 18 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 In this document, we analyze the use cases of multihoming, describe 100 functional requirements and the problems with IPv6 multihoming. 101 There are two ways to avoid the problems of IPv6 multihoming: 103 1. IPv6 network prefix translation (NPTv6, [RFC6296]), or; 105 2. refining IPv6 specifications to resolve the problems with IPv6 106 multihoming. 108 This document concerns itself with the latter, and explores the 109 solution space. We hope this will encourage the development of 110 solutions to the problem so that, in the long run, NPTv6 can be 111 avoided. 113 IPv6 provides enough globally unique addresses to permit every 114 conceivable host on the Internet to be uniquely addressed without the 115 requirement for Network Address Port Translation (NAPT [RFC3022]), 116 offering a renaissance in end-to-end transparent connectivity. 118 Unfortunately, this may not be possible in every case, due to the 119 possible necessity of NAT even in IPv6, because of multihoming. 120 Though there are mechanisms to implement multihoming, such as BGP 121 multihoming [RFC4116] at the network level, and SCTP based 122 multihoming [RFC4960] in the transport layer, there is no mechanism 123 in IPv6 that serves as a replacement for NAT based multihoming in 124 IPv4. In IPv4, for a host or a small network, NAT based multihoming 125 is easily deployable and an already deployed technique. 127 Whenever a host or small network (that does not meet minimum IPv6 128 allocation criteria) is connected to multiple upstream networks, an 129 IPv6 address is assigned by each respective service provider 130 resulting in hosts with multiple global scope IPv6 addresses with 131 different prefixes. As each service provider is allocated a 132 different address space from its Internet Registry, it, in turn 133 assigns a different address space to the end-user network or host. 134 For example, a remote access user's host or router may use a VPN to 135 simultaneously connect to a remote network and retain a default route 136 to the Internet for other purposes. 138 In IPv4 a common solution to the multihoming problem is to employ 139 NAPT on a border router and use private address space for individual 140 host addressing. The use of NAPT allows hosts to have exactly one IP 141 address visible on the public network and the combination of NAPT 142 with provider-specific outside addresses (one for each uplink) and 143 destination-based routing insulates a host from the impacts of 144 multiple upstream networks. The border router may also implement a 145 DNS cache or DNS policy to resolve address queries from hosts. 147 It is our goal to avoid the IPv6 equivalent of NAT. So, the goals 148 for IPv6 multihoming defined in [RFC3582] do not match the goals of 149 this document. Also regardless of what the NPTv6 specification is, 150 we are trying to avoid any form of network address translation 151 technique that may not be visible to either of the end hosts. To 152 reach this goal, several mechanisms are needed for end-user hosts to 153 have multiple address assignments and resolve issues such as which 154 address to use for sourcing traffic to which destination: 156 o If multiple routers exist on a single link the host must select 157 the appropriate next-hop for each connected network. Each router 158 is in turn connected to a different service provider network, 159 which provides independent address assignment. Routing protocols 160 that would normally be employed for router-to-router network 161 advertisement seem inappropriate for use by individual hosts. 163 o Source address selection becomes difficult whenever a host has 164 more than one address of the same address scope. Current address 165 selection criteria, may result in hosts using an arbitrary or 166 random address when sourcing upstream traffic. Unfortunately, for 167 the host, the appropriate source address is a function of the 168 upstream network for which the packet is bound for. If an 169 upstream service provider uses IP anti-spoofing or ingress 170 filtering, it is conceivable that the packets that have an 171 inappropriate source address for the upstream network would never 172 reach their destination. 174 o In a multihomed environment, different DNS scopes or partitions 175 may exist in each independent upstream network. A DNS query sent 176 to an arbitrary upstream DNS recursive name server may result in 177 incorrect or poisoned responses. 179 In short, while IPv6 facilitates hosts having more than one address 180 in the same address scope, the application of this causes significant 181 issues for a host; from routing, source address selection and DNS 182 resolution perspectives. A possible consequence of assigning a host 183 multiple identically-scoped addresses is severely impaired IP 184 connectivity. 186 If a host connects to a network behind an IPv4 NAPT, the host has one 187 private address in the local network. There is no confusion. The 188 NAT becomes the gateway of the host and forwards the packet to an 189 appropriate network when it is multihomed. It also operates a DNS 190 cache server or DNS proxy, which receives all DNS inquires, and gives 191 a correct answer to the host. 193 2. Terminology 195 NPTv6 IPv6-to-IPv6 Network Prefix Translation in 196 NPTv6 [RFC6296]. 198 NAPT Network Address Port Translation as described 199 in [RFC3022]. In other contexts, NAPT is often 200 pronounced "NAT" or written as "NAT". 202 Multihomed with multi-prefix (MHMP) A host implementation which 203 supports the mechanisms described in this 204 document. Namely source address selection 205 policy, next-hop selection and DNS selection 206 policy. 208 3. IPv6 multihomed network scenarios 210 In this section, we classify three scenarios of the multihoming 211 environment. 213 3.1. Classification of network scenarios for multihomed host 215 Scenario 1: 217 In this scenario, two or more routers are present on a single link 218 shared with the host(s). Each router is in turn connected to a 219 different service provider network, that provides independent address 220 assignment and DNS recursive name servers. A host in this 221 environment would be offered multiple prefixes and DNS recursive name 222 servers advertised from the two different routers. 224 +------+ ___________ 225 | | / \ 226 +---| rtr1 |=====/ network \ 227 | | | \ 1 / 228 +------+ | +------+ \___________/ 229 | | | 230 | hosts|-----+ 231 | | | 232 +------+ | +------+ ___________ 233 | | | / \ 234 +---| rtr2 |=====/ network \ 235 | | \ 2 / 236 +------+ \___________/ 238 Figure 1: single uplink, multiple next-hop, multiple prefix 239 (Scenario 1) 241 Figure 1 illustrates the host connecting to rtr1 and rtr2 via a 242 shared link. Networks 1 and 2 are reachable via rtr1 and rtr2 243 respectively. When the host sends packets to network 1, the next-hop 244 to network 1 is rtr1. Similarly, rtr2 is the next-hop to network 2. 246 - e.g., multiple broadband service providers (Internet, VoIP, IPTV, 247 etc.) 249 Scenario 2: 251 In this scenario, a single gateway router connects the host to two or 252 more upstream service provider networks. This gateway router would 253 receive prefix delegations and a different set of DNS recursive name 254 servers from each independent service provider network. The gateway 255 in turn advertises the provider prefixes to the host, and for DNS, 256 may either act as a lightweight DNS cache server or may advertise the 257 complete set of service provider DNS recursive name servers to the 258 hosts. 260 +------+ ___________ 261 +-----+ | | / \ 262 | |=======| rtr1 |=====/ network \ 263 | |port1 | | \ 1 / 264 +------+ | | +------+ \___________/ 265 | | | | 266 | hosts|-----| GW | 267 | | | rtr | 268 +------+ | | +------+ ___________ 269 | |port2 | | / \ 270 | |-------| rtr2 |=====/ network \ 271 +-----+ | | \ 2 / 272 +------+ \___________/ 274 Figure 2: single uplink, single next-hop, multiple prefix 275 (Scenario 2) 277 Figure 2 illustrates the host connected to GW rtr. GW rtr connects 278 to networks 1 and 2 via port1 and 2 respectively. As the figure 279 shows a logical topology of the scenario, the port1 could be a pseudo 280 interface for tunneling, which connects to the network 1 through the 281 network 2, and vice versa. When the host sends packets to either 282 network 1 or 2, the next-hop is GW rtr. When the packets are sent to 283 network 1 (network 2), GW rtr forwards the packets to port1 (port2). 285 - e.g, Internet + VPN/Application Service Provider (ASP) 287 Scenario 3: 289 In this scenario, a host has more than one active interface that 290 connects to different routers and service provider networks. Each 291 router provides the host with a different address prefix and set of 292 DNS recursive name servers, resulting in a host with a unique address 293 per link/interface. 295 +------+ +------+ ___________ 296 | | | | / \ 297 | |-----| rtr1 |=====/ network \ 298 | | | | \ 1 / 299 | | +------+ \___________/ 300 | | 301 | host | 302 | | 303 | | +------+ ___________ 304 | | | | / \ 305 | |=====| rtr2 |=====/ network \ 306 | | | | \ 2 / 307 +------+ +------+ \___________/ 309 Figure 3: Multiple uplink, multiple next-hop, multiple prefix 310 (Scenario 3) 312 Figure 3 illustrates the host connecting to rtr1 and rtr2 via a 313 direct connection or a virtual link. When the host sends packets 314 network 1, the next-hop to network 1 is rtr1. Similarly, rtr2 is the 315 next-hop to network 2. 317 - e.g., Mobile Wifi + 3G, ISP A + ISP B 319 3.2. Multihomed network environment 321 In an IPv6 multihomed network, a host is assigned two or more IPv6 322 addresses and DNS recursive name servers from independent service 323 provider networks. When this multihomed host attempts to connect 324 with other hosts, it may incorrectly resolve the next-hop router, use 325 an inappropriate source address, or use a DNS response from an 326 incorrect service provider that may result in impaired IP 327 connectivity. 329 Multihomed networks in IPv4 have been implemented through the use of 330 a gateway router with NAPT function (scenario 2 with NAPT) in many 331 cases. An analysis of the current IPv4 NAPT and DNS functions within 332 the gateway router should provide a baseline set of requirements for 333 IPv6 multihomed environments. A destination prefix/route is often 334 used on the gateway router to separate traffic between the networks. 336 +------+ ___________ 337 | | / \ 338 +---| rtr1 |=====/ network \ 339 | | | \ 1 / 340 +------+ +-----+ | +------+ \___________/ 341 | IPv4 | | | | 342 | hosts|-----| GW |---+ 343 | | | rtr | | 344 +------+ +-----+ | +------+ ___________ 345 (NAPT&DNS) | | | / \ 346 (private +---| rtr2 |=====/ network \ 347 address | | \ 2 / 348 space) +------+ \___________/ 350 Figure 4: IPv4 Multihomed environment with Gateway Router performing 351 NAPT 353 3.3. Problem Statement 355 A multihomed IPv6 host has one or more assigned IPv6 addresses and 356 DNS recursive name servers from each upstream service provider, 357 resulting in the host having multiple valid IPv6 addresses and DNS 358 recursive name servers. The host must be able to resolve the 359 appropriate next-hop, the correct source address and DNS recursive 360 name server to use based on the destination prefix. To prevent IP 361 spoofing, operators will often implement ingress filtering to discard 362 traffic with an inappropriate source address, making it essential for 363 the host to correctly resolve these three items before sourcing the 364 first packet. 366 IPv6 has mechanisms for the provision of multiple routers on a single 367 link and multiple address assignments to a single host. However, 368 when these mechanisms are applied to the three scenarios in 369 Section 3.1 a number of connectivity issues are identified: 371 Scenario 1: 373 The host has been assigned an address from each router and recognizes 374 both rtr1 and rtr2 as valid default routers (in the default routers 375 list). 377 o The source address selection policy on the host does not 378 deterministically resolve a source address. Ingress filtering or 379 filter policies will discard traffic with source addresses that 380 the operator did not assign. 382 o The host will select one of the two routers as the active default 383 router. No traffic is sent to the other router. 385 Scenario 2: 387 The host has been assigned two different addresses from the single 388 gateway router. The gateway router is the only default router on the 389 link. 391 o The source address selection policy on the host does not 392 deterministically resolve a source address. Ingress filtering or 393 filter policies will discard traffic with source addresses that 394 the operator did not assign. 396 o The gateway router does not have an autonomous mechanism for 397 determining which traffic should be sent to which network. If the 398 gateway router is implementing host functions (i.e., processing 399 Router Advertisement) then two valid default routers may be 400 recognized. 402 Scenario 3: 404 A host has two separate interfaces and on each interface a different 405 address is assigned. Each link has its own router. 407 o The host does not have enough information for determining which 408 traffic should be sent to which upstream routers. The host will 409 select one of the two routers as the active default router, and no 410 traffic is sent to the other router. The default address 411 selection rules select the address assigned to the outgoing 412 interface as the source address. So, if a host has an appropriate 413 routing table, an appropriate source address will be selected. 415 All scenarios: 417 o In network deployments utilizing local namespaces, the host may 418 choose to communicate with a "wrong" DNS recursive server unable 419 to serve a local namespace. 421 4. Requirements 423 This section describes requirements that any solution multi-address 424 and multi-uplink architectures need to meet. 426 4.1. End-to-End transparency 428 One of the major design goals for IPv6 is to restore the end-to-end 429 transparency of the Internet. If NAT is applied to IP communication 430 between hosts, NAT traversal mechanism are required, to establish bi- 431 directional IP communication. A NAT traversal mechanism does not 432 need to be implemented in an application, in an environment with end- 433 to-end transparency. Therefore, the IPv6 multihoming solution should 434 strive to avoid NPTv6 to achieve end-to-end transparency. 436 4.2. Scalability 438 The solution will have to be able to manage a large number of sites/ 439 nodes. In services for residential users, provider edge devices have 440 to manage thousands of sites. In such environments, sending packets 441 periodically to each site may affect edge system performance. 443 5. Problem statement and analysis 445 The problems described in Section 3 can be classified into these 446 three types: 448 o Wrong source address selection 450 o Wrong next-hop selection 452 o Wrong DNS server selection 454 This section reviews the problem statements presented above and the 455 proposed functional requirements to resolve the issues. 457 5.1. Source address selection 459 A multihomed IPv6 host will typically have different addresses 460 assigned from each service provider either on the same link 461 (scenarios 1 & 2) or different links (scenario 3). When the host 462 wishes to send a packet to any given destination, the current source 463 address selection rules [RFC3484] may not deterministically select 464 the correct source address. 465 [I-D.ietf-6man-addr-select-considerations] describes the use of the 466 policy table [RFC3484] to resolve this problem, but there is no 467 mechanism defined to disseminate the policy table information to a 468 host. A proposal is in [I-D.ietf-6man-addr-select-opt] to provide a 469 DHCPv6 mechanism for host policy table management. 471 Again, by employing DHCPv6, the server could restrict address 472 assignment (of additional prefixes) only to hosts that support policy 473 table management. 475 Scenario 1: "Host" needs to support the solution for this problem. 477 Scenario 2: "Host" needs to support the solution for this problem. 479 Scenario 3: If "Host" support the next-hop selection solution, there 480 is no need to support the address selection functionality on the 481 host. 483 It is noted that the service providers (i.e., ISP and enterprise/VPN) 484 must also support [I-D.ietf-6man-addr-select-opt]. 486 5.2. Next-hop selection 488 A multihomed IPv6 host or gateway may have multiple uplinks to 489 different service providers. Here each router would use Router 490 Advertisements [RFC4861] for distributing default route/next-hop 491 information to the host or gateway router. 493 In this case, the host or gateway router may select any valid default 494 router from the default routers list, resulting in traffic being sent 495 to the wrong router and discarded by the upstream service provider. 496 Using the above scenarios as an example, whenever the host wishes to 497 reach a destination in network 2 and there is no connectivity between 498 networks 1 and 2 (as is the case for a walled-garden or closed 499 service), the host or gateway router does not know whether to forward 500 traffic to rtr1 or rtr2 to reach a destination in network 2. The 501 host or gateway router may choose rtr1 as the default router, and 502 traffic fails to reach the destination server. The host or gateway 503 router requires route information for each upstream service provider, 504 but the use of a routing protocol between the gateway and the two 505 routers causes both configuration and scaling issues. For IPv4 506 hosts, the gateway router is often pre-configured with static route 507 information or uses of Classless Static Route Options [RFC3442] for 508 DHCPv4. Extensions to Router Advertisements through Default Router 509 Preference and More-Specific Routes [RFC4191] provides for link- 510 specific preferences but does not address per-host configuration in a 511 multi-access topology because of its reliance on Router 512 Advertisements. 514 Scenario 1: "Host" needs to support the solution for this problem. 516 Scenario 2: "GW rtr" needs to support the solution for this problem. 518 Scenario 3: "Host" needs to support the solution for this problem. 520 5.3. DNS recursive name server selection 522 A multihomed IPv6 host or gateway router may be provided multiple DNS 523 recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106]. 524 When the host or gateway router sends a DNS query, it would normally 525 choose one of the available DNS recursive name servers for the query. 527 In the IPv6 gateway router scenario, the Broadband Forum [TR124] 528 requires that the query be sent to all DNS recursive name servers, 529 and the gateway waits for the first reply. In IPv6, given our use of 530 specific destination-based policy for both routing and source address 531 selection, it is desirable to extend a policy-based concept to DNS 532 recursive name server selection. Doing so can minimize DNS recursive 533 name server load and avoid issues where DNS recursive name servers in 534 different networks have connectivity issues, or the DNS recursive 535 name server are not publicly accessible. In the worst case, a DNS 536 query for a name from a local namespace may not be resolved correctly 537 if sent towards a DNS server not aware of said local namespace, 538 resulting in a lack of connectivity. 540 It is not an issue of Domain Name System model itself, but an IPv6 541 multihomed host or gateway router should have the ability to select 542 appropriate DNS recursive name servers for each service based on the 543 domain space for the destination, and each service should provide 544 rules specific to that network. [RFC6731] proposes a solution for 545 distributing DNS server selection policy using a DHCPv6 option. 547 Scenario 1: "Host" needs to support the solution for this problem. 549 Scenario 2: "GW rtr" needs to support the solution for this problem. 551 Scenario 3: "Host" needs to support the solution for this problem. 553 It is noted that the service providers (i.e., ISP and enterprise/VPN) 554 must also support [RFC6731]. 556 6. Implementation approach 558 As mentioned in Section 5, in the multi-prefix environment, we have 559 three problems; source address selection, next-hop selection, and DNS 560 recursive name server selection. In this section, possible solutions 561 for each problem are introduced and evaluated against the 562 requirements in Section 4. 564 6.1. Source address selection 566 Possible solutions and their evaluation are summarized in 567 [I-D.ietf-6man-addr-select-considerations]. When those solutions are 568 examined against the requirements in Section 4, the proactive 569 approaches, such as the policy table distribution mechanism and the 570 routing hints mechanism, are more appropriate in that they can 571 propagate the network administrator's policy directly. The policy 572 distribution mechanism has an advantage with regard to the host's 573 protocol stack impact and the static nature of the assumed target 574 network environment. 576 6.2. Next-hop selection 578 As for the source address selection problem, both a policy-based 579 approach and a non policy-based approach are possible with regard to 580 the next-hop selection problem. Because of the same requirements, 581 the policy propagation-based solution mechanism, whatever the policy, 582 should be more appropriate. 584 Routing information is a typical example of policy related to next- 585 hop selection. If we assume source address-based routing at hosts or 586 intermediate routers, pairs of source prefixes and next-hops can be 587 another example of next-hop selection policy. 589 The routing information-based approach has a clear advantage in 590 implementation and is already commonly used. 592 The existing proposed or standardized routing information 593 distribution mechanisms are routing protocols, such as RIPng and 594 OSPFv3, the RA extension option defined in [RFC4191], and the [TR069] 595 standardized at BBF. 597 The RA-based mechanism doesn't handle distribution of per-host 598 routing information easily. Dynamic routing protocols are not 599 typically used between residential users and ISPs, because of their 600 scalability and security implications. The DHCPv6 mechanism does not 601 have these problems and has the advantage of its relaying 602 functionality. It is commonly used and is thus easy to deploy. 604 [TR069], mentioned above, is a possible solution mechanism for 605 routing information distribution to customer-premises equipment 606 (CPE). It assumes, however, IP reachability to the Auto 607 Configuration Server (ACS) is established. Therefore, if the CPE 608 requires routing information to reach the ACS, [TR069] cannot be used 609 to distribute this information. 611 6.3. DNS recursive name server selection 613 Note: Split-horizon DNS is discussed in this section. Split- 614 horizon DNS is known to cause problems with applications to allow 615 information leakage. The discussion of split-horizon DNS is not 616 condoning its use, but rather acknowledging that split-horizon DNS 617 is used and that its use is another justification for network 618 address translation. The goal of this document is to encourage 619 building solutions which do not need network address translation. 620 Two solutions appear possible: make split-horizon DNS work better 621 (which is discussed below) or meet network administrator's 622 requirements without split-horizon DNS (which is out of scope of 623 this document). 625 As in the above two problems, a policy-based approach and a non 626 policy-based approach are possible. In a non policy-based approach, 627 a host or a home gateway router is assumed to send DNS queries to 628 several DNS recursive name servers at once or to select one of the 629 available servers. 631 In the non policy-based approach, by making a query to a DNS 632 recursive name server in a different service provider to that which 633 hosts the service, a user could be directed to unexpected IP address 634 or receive an invalid response, and thus cannot connect to the 635 service provider's private and legitimate service. For example, some 636 DNS recursive name servers reply with different answers depending on 637 the source address of the DNS query, which is sometimes called split- 638 horizon. When the host mistakenly makes a query to a different 639 provider's DNS recursive name server to resolve a FQDN of another 640 provider's private service, and the DNS recursive name server adopts 641 the split-horizon configuration, the queried server returns an IP 642 address of the non-private side of the service. Another problem with 643 this approach is that it causes unnecessary DNS traffic to the DNS 644 recursive name servers that are visible to the users. 646 The alternative of a policy-based approach is documented in 647 [RFC6731], where several pairs of DNS recursive name server addresses 648 and DNS domain suffixes are defined as part of a policy and conveyed 649 to hosts in a new DHCP option. In an environment where there is a 650 home gateway router, that router can act as a DNS recursive name 651 server, interpret this option and distribute DNS queries to the 652 appropriate DNS servers according to the policy. 654 6.4. Other algorithms available in RFCs 656 The authors of this document are aware of a variety of other 657 algorithms and architectures, such as shim6 [RFC5533] and HIP 658 [RFC5206], that may be useful in this environment. At this writing, 659 there is not enough operational experience on which to base a 660 recommendation. Should such operational experience become available, 661 this document may be updated in the future. 663 7. Considerations for MHMP deployment 665 This section describes considerations to mitigate possible problem in 666 a network which implements MHMP described in Section 6. 668 7.1. Non-MHMP host consideration 670 In a typical IPv4 multihomed network deployment, IPv4 NAPT is 671 practically used and it can eventually avoid assigning multiple 672 addresses to the hosts and solve the next-hop selection problem. In 673 a similar fashion, NPTv6 can be used as a last resort for IPv6 674 multihomed network deployments where one needs to assign a single 675 IPv6 address to a non-MHMP host. 677 __________ 678 / \ 679 +---/ Internet \ 680 gateway router | \ / 681 +------+ +---------------------+ | \__________/ 682 | | | | | WAN1 +--+ 683 | host |-----|LAN| Router |--------| 684 | | | | |NAT|WAN2+--+ 685 +------+ +---------------------+ | __________ 686 | / \ 687 +---/ ASP \ 688 \ / 689 \__________/ 691 Figure 5: Legacy Host 693 The gateway router also has to support the two features, next-hop 694 selection and DNS server selection, shown in Section 6. 696 The implementation and issues of NPTv6 are out of the scope of this 697 document. They may be covered by another document under discussion 698 [RFC6296]. 700 7.2. Co-existence considerations 702 To allow the co-existence of non-MHMP hosts and MHMP hosts (i.e. 703 hosts supporting multi-prefix with the enhancements for the source 704 address selection), GW-rtr may need to treat those hosts separately. 706 An idea for how to achieve this, is that GW-rtr identifies the hosts, 707 and then assigns a single prefix to non-MHMP hosts and assigns 708 multiple prefixes to MHMP hosts. In this case, GW-rtr can perform 709 IPv6 NAT only for the traffic from non-MHMP hosts if its source 710 address is not appropriate. 712 Another idea is that GW-rtr assigns multiple prefixes to both hosts, 713 and performs IPv6 NAT for traffic from non-MHMP hosts if its source 714 address is not appropriate. 716 In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT 717 box. In this case, the non-MHMP host can access the service through 718 the NAT box. 720 The implementation of identifying non-MHMP hosts and NAT policy is 721 outside the scope of this document. 723 7.3. Policy collision consideration 725 When multiple policy distributors exist, a policy receiver may not 726 follow one or each of the received policy. In particular, when a 727 policy conflicts with another policy, a policy receiver cannot 728 implement each of the policy. To solve or mitigate this issue, it is 729 required that prioritization rule to align these policies along 730 preference on a trusted interface. Another solution is to preclude 731 the functionality of multiple policy acceptance at the receiver side. 732 In this case, a policy distributor should cooperate with other policy 733 distributors, and a single representative provider should distribute 734 a merged policy. 736 This document does not presume specific recommendations for resolving 737 policy collision. It is expected to the implementation to decide how 738 to resolve the conflicts. If they are not resolved consistently by 739 different implementations, that could affect interoperability and 740 security trust boundaries. Future work will be expected to address 741 the need for consistent policy resolution to avoid interoperability 742 and security trust boundary issues. 744 8. Security Considerations 746 In today's multi-homed IPv4 networks, it is difficult to resolve or 747 coordinate conflicts between the two upstream networks. This problem 748 persists with IPv6, no matter if the hosts use IPv6 provider- 749 dependent or provider-independent addresses. 751 This document requires that the solutions for MHMP should have policy 752 providing functions. New security threats can be introduced 753 depending on what kind and what form of the policy. The threats can 754 be categorized in two parts: the policy receiver side and the policy 755 distributor side. 757 A policy receiver may receive an evil policy from a policy 758 distributor. A policy distributor should expect some hosts in its 759 network do not follow the distributed policy. At the time of 760 writing, there are no known methods to resolve conflicts between the 761 host's own policy (policy receiver) and the policies of upstream 762 providers (policy provider). As this document is analyzing the 763 problem space, rather than proposing a solution, we note the 764 following problems: 766 Threats related to the policy distributor side: 768 Service provider should expect the existence of hosts that will 769 not obey the received policy. A possible solutions is to 770 ingress-filter those packets that do not match the distributed 771 policy and drop them. About the route selection, packet 772 forwarding or redirection can be another possible solution. 773 About the source address selection, IPv6 NAT can be another 774 possible solution. 776 Administrators of different networks might need to control 777 policies (and nodes' behaviors) independently of other 778 administrators. It means that the need to have access controls 779 for such cross-administrative policy access. Administrators 780 must control only nodes that are part of their own networks, or 781 some administrators must control only nodes that are part of 782 their own networks, while others are authorized to control 783 nodes across administrative boundaries. To be success to 784 cross-administrative policy-control, per-user authorization 785 might be required with existing AAA and network management 786 standards. 788 Threats related to the policy receiver side: 790 For policy receiver side, who should be trusted to accept 791 policies is a fundamental issue. How is the trust established, 792 and how can the network element be assured that it can 793 established that trust before the network is fully configured. 794 If a policy receiver trusts untrusted network, it will cause 795 that distributing unwanted and unauthorized policy that 796 described below. 798 A policy receiver are exposed to the threats of unauthorized 799 policy, which can lead to session hijack, falsification, DoS, 800 wiretapping and phishing. Unauthorized policy here means a 801 policy distributed from an entity that does not have rights to 802 do so. Usually, only a site administrator and a network 803 service provider have rights to distribute these policies just 804 as well as IP address assignment and DNS server address 805 notification. Regarding source address selection, unauthorized 806 policy can expose an IP address that will not usually be 807 exposed to an external server, which can be a privacy problem. 808 To solve or mitigate this problem of unauthorized policy, one 809 approach is limiting on use of these policy distribution 810 mechanisms, as described in the section 4.4 of [RFC6731]. For 811 example, a policy should be preferred or accepted when the 812 policy is verified its integrity and delivered across a secure, 813 trusted channel such as 3G connection in cellular services. 814 The proposed solutions are based on DHCP, so the limitation of 815 local site communication, which is often used in WiFi access 816 services, should be another solution or mitigation for this 817 problem. About DNS server selection issue, DNSSEC can be 818 another solution. About source address selection, the ingress 819 filter at the network service provider router can be a 820 solution. 822 Another threat is the leakage of the policy and privacy issues 823 resulting from that. Especially when each client is 824 distributed its own policy from the network service provider, 825 the policy can give a hint of which service the client 826 subscribes. Encryption of communication channel, separation of 827 communication channel per host can be solutions for this 828 problem. 830 The security threats related to IPv6 multihoming are described in 831 [RFC4218]. 833 9. IANA Considerations 835 This document has no IANA actions. 837 10. Contributors 839 The following people contributed to this document: Akiko Hattori, 840 Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, 841 Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, 842 Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has 843 greatly benefited from inputs by Randy Bush, Brian Carpenter, and 844 Teemu Savolainen. 846 11. References 848 11.1. Normative References 850 [I-D.ietf-6man-addr-select-considerations] 851 Chown, T. and A. Matsumoto, "Considerations for IPv6 852 Address Selection Policy Changes", 853 draft-ietf-6man-addr-select-considerations-04 (work in 854 progress), October 2011. 856 [I-D.ietf-6man-addr-select-opt] 857 Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 858 Address Selection Policy using DHCPv6", 859 draft-ietf-6man-addr-select-opt-08 (work in progress), 860 January 2013. 862 [RFC3484] Draves, R., "Default Address Selection for Internet 863 Protocol version 6 (IPv6)", RFC 3484, February 2003. 865 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 866 More-Specific Routes", RFC 4191, November 2005. 868 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 869 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 870 September 2007. 872 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 873 Translation", RFC 6296, June 2011. 875 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 876 Recursive DNS Server Selection for Multi-Interfaced 877 Nodes", RFC 6731, December 2012. 879 11.2. Informative References 881 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 882 Address Translator (Traditional NAT)", RFC 3022, 883 January 2001. 885 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 886 Static Route Option for Dynamic Host Configuration 887 Protocol (DHCP) version 4", RFC 3442, December 2002. 889 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 890 Multihoming Architectures", RFC 3582, August 2003. 892 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 893 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 894 December 2003. 896 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 897 Gill, "IPv4 Multihoming Practices and Limitations", 898 RFC 4116, July 2005. 900 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 901 Multihoming Solutions", RFC 4218, October 2005. 903 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 904 RFC 4960, September 2007. 906 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 907 Host Mobility and Multihoming with the Host Identity 908 Protocol", RFC 5206, April 2008. 910 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 911 Shim Protocol for IPv6", RFC 5533, June 2009. 913 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 914 "IPv6 Router Advertisement Options for DNS Configuration", 915 RFC 6106, November 2010. 917 [TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol 918 v1.1, Version: Issue 1 Amendment 2", December 2007. 920 [TR124] The BroadBand Forum, "TR-124i2, Functional Requirements 921 for Broadband Residential Gateway Devices (work in 922 progress)", May 2010. 924 Authors' Addresses 926 Ole Troan (editor) 927 Cisco 928 Oslo 929 Norway 931 Email: ot@cisco.com 933 David Miles 934 Alcatel-Lucent 935 Melbourne 936 Australia 938 Email: david.miles@alcatel-lucent.com 940 Satoru Matsushima 941 Softbank Telecom 942 Tokyo 943 Japan 945 Email: satoru.matsushima@g.softbank.co.jp 946 Tadahisa Okimoto 947 NTT West 948 Osaka 949 Japan 951 Email: t.okimoto@west.ntt.co.jp 953 Dan Wing 954 Cisco 955 170 West Tasman Drive 956 San Jose 957 USA 959 Email: dwing@cisco.com