idnits 2.17.00 (12 Aug 2021) /tmp/idnits50126/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.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 (February 14, 2014) is 3011 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: August 18, 2014 Alcatel-Lucent 6 S. Matsushima 7 Softbank Telecom 8 T. Okimoto 9 NTT West 10 D. Wing 11 Cisco 12 February 14, 2014 14 IPv6 Multihoming without Network Address Translation 15 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 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 August 18, 2014. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 5 70 3.1. Classification of network scenarios for multihomed host . 5 71 3.2. Multihomed network environment . . . . . . . . . . . . . 7 72 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 10 75 4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10 76 5. Problem statement and analysis . . . . . . . . . . . . . . . 10 77 5.1. Source address selection . . . . . . . . . . . . . . . . 10 78 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . 11 79 5.3. DNS recursive name server selection . . . . . . . . . . . 12 80 6. Implementation approach . . . . . . . . . . . . . . . . . . . 12 81 6.1. Source address selection . . . . . . . . . . . . . . . . 12 82 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . 13 83 6.3. DNS recursive name server selection . . . . . . . . . . . 13 84 6.4. Other algorithms available in RFCs . . . . . . . . . . . 14 85 7. Considerations for MHMP deployment . . . . . . . . . . . . . 14 86 7.1. Non-MHMP host consideration . . . . . . . . . . . . . . . 15 87 7.2. Co-existence considerations . . . . . . . . . . . . . . . 15 88 7.3. Policy collision consideration . . . . . . . . . . . . . 16 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 94 11.2. Informative References . . . . . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 [RFC6724] may not deterministically select 464 the correct source address. [RFC7078] describes the use of the 465 policy table [RFC6724] to resolve this problem, using a DHCPv6 466 mechanism for host policy table management. 468 Again, by employing DHCPv6, the server could restrict address 469 assignment (of additional prefixes) only to hosts that support policy 470 table management. 472 Scenario 1: "Host" needs to support the solution for this problem. 474 Scenario 2: "Host" needs to support the solution for this problem. 476 Scenario 3: If "Host" support the next-hop selection solution, there 477 is no need to support the address selection functionality on the 478 host. 480 It is noted that the service providers (i.e., ISP and enterprise/VPN) 481 must also support [RFC7078]. 483 5.2. Next-hop selection 485 A multihomed IPv6 host or gateway may have multiple uplinks to 486 different service providers. Here each router would use Router 487 Advertisements [RFC4861] for distributing default route/next-hop 488 information to the host or gateway router. 490 In this case, the host or gateway router may select any valid default 491 router from the default routers list, resulting in traffic being sent 492 to the wrong router and discarded by the upstream service provider. 493 Using the above scenarios as an example, whenever the host wishes to 494 reach a destination in network 2 and there is no connectivity between 495 networks 1 and 2 (as is the case for a walled-garden or closed 496 service), the host or gateway router does not know whether to forward 497 traffic to rtr1 or rtr2 to reach a destination in network 2. The 498 host or gateway router may choose rtr1 as the default router, and 499 traffic fails to reach the destination server. The host or gateway 500 router requires route information for each upstream service provider, 501 but the use of a routing protocol between the gateway and the two 502 routers causes both configuration and scaling issues. For IPv4 503 hosts, the gateway router is often pre-configured with static route 504 information or uses of Classless Static Route Options [RFC3442] for 505 DHCPv4. Extensions to Router Advertisements through Default Router 506 Preference and More-Specific Routes [RFC4191] provides for link- 507 specific preferences but does not address per-host configuration in a 508 multi-access topology because of its reliance on Router 509 Advertisements. 511 Scenario 1: "Host" needs to support the solution for this problem. 513 Scenario 2: "GW rtr" needs to support the solution for this problem. 515 Scenario 3: "Host" needs to support the solution for this problem. 517 5.3. DNS recursive name server selection 519 A multihomed IPv6 host or gateway router may be provided multiple DNS 520 recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106]. 521 When the host or gateway router sends a DNS query, it would normally 522 choose one of the available DNS recursive name servers for the query. 524 In the IPv6 gateway router scenario, the Broadband Forum [TR124] 525 requires that the query be sent to all DNS recursive name servers, 526 and the gateway waits for the first reply. In IPv6, given our use of 527 specific destination-based policy for both routing and source address 528 selection, it is desirable to extend a policy-based concept to DNS 529 recursive name server selection. Doing so can minimize DNS recursive 530 name server load and avoid issues where DNS recursive name servers in 531 different networks have connectivity issues, or the DNS recursive 532 name server are not publicly accessible. In the worst case, a DNS 533 query for a name from a local namespace may not be resolved correctly 534 if sent towards a DNS server not aware of said local namespace, 535 resulting in a lack of connectivity. 537 It is not an issue of Domain Name System model itself, but an IPv6 538 multihomed host or gateway router should have the ability to select 539 appropriate DNS recursive name servers for each service based on the 540 domain space for the destination, and each service should provide 541 rules specific to that network. [RFC6731] proposes a solution for 542 distributing DNS server selection policy using a DHCPv6 option. 544 Scenario 1: "Host" needs to support the solution for this problem. 546 Scenario 2: "GW rtr" needs to support the solution for this problem. 548 Scenario 3: "Host" needs to support the solution for this problem. 550 It is noted that the service providers (i.e., ISP and enterprise/VPN) 551 must also support [RFC6731]. 553 6. Implementation approach 555 As mentioned in Section 5, in the multi-prefix environment, we have 556 three problems; source address selection, next-hop selection, and DNS 557 recursive name server selection. In this section, possible solutions 558 for each problem are introduced and evaluated against the 559 requirements in Section 4. 561 6.1. Source address selection 563 The problems of address selection in multi-prefix environments are 564 summarized in [RFC5220]. When solutions are examined against the 565 requirements in Section 4, the proactive approaches, such as the 566 policy table distribution mechanism and the routing hints mechanism, 567 are more appropriate in that they can propagate the network 568 administrator's policy directly. The policy distribution mechanism 569 has an advantage with regard to the host's protocol stack impact and 570 the static nature of the assumed target network environment. 572 6.2. Next-hop selection 574 As for the source address selection problem, both a policy-based 575 approach and a non policy-based approach are possible with regard to 576 the next-hop selection problem. Because of the same requirements, 577 the policy propagation-based solution mechanism, whatever the policy, 578 should be more appropriate. 580 Routing information is a typical example of policy related to next- 581 hop selection. If we assume source address-based routing at hosts or 582 intermediate routers, pairs of source prefixes and next-hops can be 583 another example of next-hop selection policy. 585 The routing information-based approach has a clear advantage in 586 implementation and is already commonly used. 588 The existing proposed or standardized routing information 589 distribution mechanisms are routing protocols, such as RIPng and 590 OSPFv3, the RA extension option defined in [RFC4191], and the [TR069] 591 standardized at BBF. 593 The RA-based mechanism doesn't handle distribution of per-host 594 routing information easily. Dynamic routing protocols are not 595 typically used between residential users and ISPs, because of their 596 scalability and security implications. The DHCPv6 mechanism does not 597 have these problems and has the advantage of its relaying 598 functionality. It is commonly used and is thus easy to deploy. 600 [TR069], mentioned above, is a possible solution mechanism for 601 routing information distribution to customer-premises equipment 602 (CPE). It assumes, however, IP reachability to the Auto 603 Configuration Server (ACS) is established. Therefore, if the CPE 604 requires routing information to reach the ACS, [TR069] cannot be used 605 to distribute this information. 607 6.3. DNS recursive name server selection 609 Note: Split-horizon DNS is discussed in this section. Split- 610 horizon DNS is known to cause problems with applications to allow 611 information leakage. The discussion of split-horizon DNS is not 612 condoning its use, but rather acknowledging that split-horizon DNS 613 is used and that its use is another justification for network 614 address translation. The goal of this document is to encourage 615 building solutions which do not need network address translation. 616 Two solutions appear possible: make split-horizon DNS work better 617 (which is discussed below) or meet network administrator's 618 requirements without split-horizon DNS (which is out of scope of 619 this document). 621 As in the above two problems, a policy-based approach and a non 622 policy-based approach are possible. In a non policy-based approach, 623 a host or a home gateway router is assumed to send DNS queries to 624 several DNS recursive name servers at once or to select one of the 625 available servers. 627 In the non policy-based approach, by making a query to a DNS 628 recursive name server in a different service provider to that which 629 hosts the service, a user could be directed to unexpected IP address 630 or receive an invalid response, and thus cannot connect to the 631 service provider's private and legitimate service. For example, some 632 DNS recursive name servers reply with different answers depending on 633 the source address of the DNS query, which is sometimes called split- 634 horizon. When the host mistakenly makes a query to a different 635 provider's DNS recursive name server to resolve a FQDN of another 636 provider's private service, and the DNS recursive name server adopts 637 the split-horizon configuration, the queried server returns an IP 638 address of the non-private side of the service. Another problem with 639 this approach is that it causes unnecessary DNS traffic to the DNS 640 recursive name servers that are visible to the users. 642 The alternative of a policy-based approach is documented in 643 [RFC6731], where several pairs of DNS recursive name server addresses 644 and DNS domain suffixes are defined as part of a policy and conveyed 645 to hosts in a new DHCP option. In an environment where there is a 646 home gateway router, that router can act as a DNS recursive name 647 server, interpret this option and distribute DNS queries to the 648 appropriate DNS servers according to the policy. 650 6.4. Other algorithms available in RFCs 652 The authors of this document are aware of a variety of other 653 algorithms and architectures, such as shim6 [RFC5533] and HIP 654 [RFC5206], that may be useful in this environment. At this writing, 655 there is not enough operational experience on which to base a 656 recommendation. Should such operational experience become available, 657 this document may be updated in the future. 659 7. Considerations for MHMP deployment 660 This section describes considerations to mitigate possible problem in 661 a network which implements MHMP described in Section 6. 663 7.1. Non-MHMP host consideration 665 In a typical IPv4 multihomed network deployment, IPv4 NAPT is 666 practically used and it can eventually avoid assigning multiple 667 addresses to the hosts and solve the next-hop selection problem. In 668 a similar fashion, NPTv6 can be used as a last resort for IPv6 669 multihomed network deployments where one needs to assign a single 670 IPv6 address to a non-MHMP host. 672 __________ 673 / \ 674 +---/ Internet \ 675 gateway router | \ / 676 +------+ +---------------------+ | \__________/ 677 | | | | | WAN1 +--+ 678 | host |-----|LAN| Router |--------| 679 | | | | |NAT|WAN2+--+ 680 +------+ +---------------------+ | __________ 681 | / \ 682 +---/ ASP \ 683 \ / 684 \__________/ 686 Figure 5: Legacy Host 688 The gateway router also has to support the two features, next-hop 689 selection and DNS server selection, shown in Section 6. 691 The implementation and issues of NPTv6 are out of the scope of this 692 document. They may be covered by another document under discussion 693 [RFC6296]. 695 7.2. Co-existence considerations 697 To allow the co-existence of non-MHMP hosts and MHMP hosts (i.e. 698 hosts supporting multi-prefix with the enhancements for the source 699 address selection), GW-rtr may need to treat those hosts separately. 701 An idea for how to achieve this, is that GW-rtr identifies the hosts, 702 and then assigns a single prefix to non-MHMP hosts and assigns 703 multiple prefixes to MHMP hosts. In this case, GW-rtr can perform 704 IPv6 NAT only for the traffic from non-MHMP hosts if its source 705 address is not appropriate. 707 Another idea is that GW-rtr assigns multiple prefixes to both hosts, 708 and performs IPv6 NAT for traffic from non-MHMP hosts if its source 709 address is not appropriate. 711 In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT 712 box. In this case, the non-MHMP host can access the service through 713 the NAT box. 715 The implementation of identifying non-MHMP hosts and NAT policy is 716 outside the scope of this document. 718 7.3. Policy collision consideration 720 When multiple policy distributors exist, a policy receiver may not 721 follow one or each of the received policy. In particular, when a 722 policy conflicts with another policy, a policy receiver cannot 723 implement each of the policy. To solve or mitigate this issue, it is 724 required that prioritization rule to align these policies along 725 preference on a trusted interface. Another solution is to preclude 726 the functionality of multiple policy acceptance at the receiver side. 727 In this case, a policy distributor should cooperate with other policy 728 distributors, and a single representative provider should distribute 729 a merged policy. 731 This document does not presume specific recommendations for resolving 732 policy collision. It is expected to the implementation to decide how 733 to resolve the conflicts. If they are not resolved consistently by 734 different implementations, that could affect interoperability and 735 security trust boundaries. Future work will be expected to address 736 the need for consistent policy resolution to avoid interoperability 737 and security trust boundary issues. 739 8. Security Considerations 741 In today's multi-homed IPv4 networks, it is difficult to resolve or 742 coordinate conflicts between the two upstream networks. This problem 743 persists with IPv6, no matter if the hosts use IPv6 provider- 744 dependent or provider-independent addresses. 746 This document requires that the solutions for MHMP should have policy 747 providing functions. New security threats can be introduced 748 depending on what kind and what form of the policy. The threats can 749 be categorized in two parts: the policy receiver side and the policy 750 distributor side. 752 A policy receiver may receive an evil policy from a policy 753 distributor. A policy distributor should expect some hosts in its 754 network do not follow the distributed policy. At the time of 755 writing, there are no known methods to resolve conflicts between the 756 host's own policy (policy receiver) and the policies of upstream 757 providers (policy provider). As this document is analyzing the 758 problem space, rather than proposing a solution, we note the 759 following problems: 761 Threats related to the policy distributor side: 763 Service provider should expect the existence of hosts that will 764 not obey the received policy. A possible solutions is to 765 ingress-filter those packets that do not match the distributed 766 policy and drop them. About the route selection, packet 767 forwarding or redirection can be another possible solution. 768 About the source address selection, IPv6 NAT can be another 769 possible solution. 771 Administrators of different networks might need to control 772 policies (and nodes' behaviors) independently of other 773 administrators. It means that the need to have access controls 774 for such cross-administrative policy access. Administrators 775 must control only nodes that are part of their own networks, or 776 some administrators must control only nodes that are part of 777 their own networks, while others are authorized to control 778 nodes across administrative boundaries. To be success to 779 cross-administrative policy-control, per-user authorization 780 might be required with existing AAA and network management 781 standards. 783 Threats related to the policy receiver side: 785 For policy receiver side, who should be trusted to accept 786 policies is a fundamental issue. How is the trust established, 787 and how can the network element be assured that it can 788 established that trust before the network is fully configured. 789 If a policy receiver trusts untrusted network, it will cause 790 that distributing unwanted and unauthorized policy that 791 described below. 793 A policy receiver are exposed to the threats of unauthorized 794 policy, which can lead to session hijack, falsification, DoS, 795 wiretapping and phishing. Unauthorized policy here means a 796 policy distributed from an entity that does not have rights to 797 do so. Usually, only a site administrator and a network 798 service provider have rights to distribute these policies just 799 as well as IP address assignment and DNS server address 800 notification. Regarding source address selection, unauthorized 801 policy can expose an IP address that will not usually be 802 exposed to an external server, which can be a privacy problem. 804 To solve or mitigate this problem of unauthorized policy, one 805 approach is limiting on use of these policy distribution 806 mechanisms, as described in the section 4.4 of [RFC6731]. For 807 example, a policy should be preferred or accepted when the 808 policy is verified its integrity and delivered across a secure, 809 trusted channel such as 3G connection in cellular services. 810 The proposed solutions are based on DHCP, so the limitation of 811 local site communication, which is often used in WiFi access 812 services, should be another solution or mitigation for this 813 problem. About DNS server selection issue, DNSSEC can be 814 another solution. About source address selection, the ingress 815 filter at the network service provider router can be a 816 solution. 818 Another threat is the leakage of the policy and privacy issues 819 resulting from that. Especially when each client is 820 distributed its own policy from the network service provider, 821 the policy can give a hint of which service the client 822 subscribes. Encryption of communication channel, separation of 823 communication channel per host can be solutions for this 824 problem. 826 The security threats related to IPv6 multihoming are described in 827 [RFC4218]. 829 9. IANA Considerations 831 This document has no IANA actions. 833 10. Contributors 835 The following people contributed to this document: Akiko Hattori, 836 Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, 837 Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, 838 Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has 839 greatly benefited from inputs by Randy Bush, Brian Carpenter, and 840 Teemu Savolainen. 842 11. References 844 11.1. Normative References 846 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 847 More-Specific Routes", RFC 4191, November 2005. 849 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 850 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 851 September 2007. 853 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 854 Translation", RFC 6296, June 2011. 856 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 857 "Default Address Selection for Internet Protocol Version 6 858 (IPv6)", RFC 6724, September 2012. 860 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 861 Recursive DNS Server Selection for Multi-Interfaced 862 Nodes", RFC 6731, December 2012. 864 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 865 Address Selection Policy Using DHCPv6", RFC 7078, January 866 2014. 868 11.2. Informative References 870 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 871 Address Translator (Traditional NAT)", RFC 3022, January 872 2001. 874 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 875 Static Route Option for Dynamic Host Configuration 876 Protocol (DHCP) version 4", RFC 3442, December 2002. 878 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 879 Multihoming Architectures", RFC 3582, August 2003. 881 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 882 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 883 December 2003. 885 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 886 Gill, "IPv4 Multihoming Practices and Limitations", RFC 887 4116, July 2005. 889 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 890 Multihoming Solutions", RFC 4218, October 2005. 892 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 893 4960, September 2007. 895 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 896 Host Mobility and Multihoming with the Host Identity 897 Protocol", RFC 5206, April 2008. 899 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 900 "Problem Statement for Default Address Selection in Multi- 901 Prefix Environments: Operational Issues of RFC 3484 902 Default Rules", RFC 5220, July 2008. 904 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 905 Shim Protocol for IPv6", RFC 5533, June 2009. 907 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 908 "IPv6 Router Advertisement Options for DNS Configuration", 909 RFC 6106, November 2010. 911 [TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol 912 v1.1, Version: Issue 1 Amendment 2", December 2007. 914 [TR124] The BroadBand Forum, "TR-124i2, Functional Requirements 915 for Broadband Residential Gateway Devices (work in 916 progress)", May 2010. 918 Authors' Addresses 920 Ole Troan (editor) 921 Cisco 922 Oslo 923 Norway 925 Email: ot@cisco.com 927 David Miles 928 Alcatel-Lucent 929 Melbourne 930 Australia 932 Email: david.miles@alcatel-lucent.com 934 Satoru Matsushima 935 Softbank Telecom 936 Tokyo 937 Japan 939 Email: satoru.matsushima@g.softbank.co.jp 940 Tadahisa Okimoto 941 NTT West 942 Osaka 943 Japan 945 Email: t.okimoto@west.ntt.co.jp 947 Dan Wing 948 Cisco 949 170 West Tasman Drive 950 San Jose 951 USA 953 Email: dwing@cisco.com