idnits 2.17.1 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01.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 (August 31, 2011) is 4622 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-03 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-01 == Outdated reference: A later version (-05) exists of draft-ietf-mif-dhcpv6-route-option-02 == Outdated reference: A later version (-12) exists of draft-ietf-mif-dns-server-selection-03 ** 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 6106 (Obsoleted by RFC 8106) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 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: March 3, 2012 Alcatel-Lucent 6 S. Matsushima 7 Softbank Telecom 8 T. Okimoto 9 NTT West 10 D. Wing 11 Cisco 12 August 31, 2011 14 IPv6 Multihoming without Network Address Translation 15 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-01 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 IPv6 NAT. 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. Nevertheless, we mention that the 30 possible needs for IPv6 NAT in the transition phase to the fully 31 deployment of the proposed solutions. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 3, 2012. 50 Copyright Notice 52 Copyright (c) 2011 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 . . . . . . . . . . . . . . 8 72 3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 10 75 4.2. Policy distribution . . . . . . . . . . . . . . . . . . . 11 76 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11 77 5. Problem statement and analysis . . . . . . . . . . . . . . . . 11 78 5.1. Source address selection . . . . . . . . . . . . . . . . . 12 79 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 12 80 5.3. DNS recursive name server selection . . . . . . . . . . . 13 81 6. Implementation approach . . . . . . . . . . . . . . . . . . . 14 82 6.1. Source address selection . . . . . . . . . . . . . . . . . 14 83 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 14 84 6.3. DNS recursive name server selection . . . . . . . . . . . 15 85 7. Considerations for host without multi-prefix support . . . . . 16 86 7.1. IPv6 NAT . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 7.2. Co-existence consideration . . . . . . . . . . . . . . . . 17 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 IPv6 provides enough globally unique addresses to permit every 99 conceivable host on the Internet to be uniquely addressed without the 100 requirement for Network Address Port Translation (NAPT [RFC3022]), 101 offering a renaissance in end-to-end transparent connectivity. 103 Unfortunately, this may not be possible due to the necessity of NAT 104 even in IPv6, because of multihoming. Though there are some 105 mechanisms to implement multihoming, such as BGP multihoming 106 [RFC4116] in network level, and SCTP based multihoming [RFC4960] in 107 application transport level, there is no mechanism in IPv6 that 108 serves as a replacement for NAT based multihoming in IPv4. In IPv4, 109 for a host or a small network, NAT based multihoming is easily 110 deployable and an already deployed technique. Some of the same 111 reasons for IPv4 NATs may be applicable to IPv6. 113 Whenever a host or small network (which does not meet minimum IPv6 114 allocation criteria) is connected to multiple upstream networks, an 115 IPv6 address is assigned by each respective service provider 116 resulting in hosts with multiple global scope IPv6 addresses with 117 different prefixes. As each service provider is allocated a 118 different address space from its Internet Registry, it in-turn 119 assigns a different address space to the end-user network or host. 120 For example, a remote access user's host or router may use a VPN to 121 simultaneously connect to a remote network and retain a default route 122 to the Internet for other purposes. 124 In IPv4 a common solution to the multihoming problem is to employ 125 NAPT on a border router and use private address space for individual 126 host addressing. The use of NAPT allows hosts to have exactly one IP 127 address visible on the public network and the combination of NAPT 128 with provider-specific outside addresses (one for each uplink) and 129 destination-based routing insulates a host from the impacts of 130 multiple upstream networks. The border router may also implement a 131 DNS cache or DNS policy to resolve address queries from hosts. 133 It is our goal to avoid the IPv6 equivalent of NAT. So, the goals 134 for IPv6 multihoming defined in [RFC3582] do not match the goals of 135 this document. Also regardless of what the IPv6 NAT's specification 136 is, we are trying to avoid any form of network address translation 137 technique that may not be visible for either of the end hosts. To 138 reach this goal, mechanisms are needed for end-user hosts to have 139 multiple address assignments and resolve issues such as which address 140 to use for sourcing traffic to which destination: 142 o If multiple routers exist on a single link the host must select 143 the appropriate next-hop for each connected network. Each router 144 is in turn connected to a different service provider network, 145 which provides independent address assignment. Routing protocols 146 that would normally be employed for router-to-router network 147 advertisement seem inappropriate for use by individual hosts. 149 o Source address selection also becomes difficult whenever a host 150 has more than one address within the same address scope. Current 151 address selection criteria may result in hosts using an arbitrary 152 or random address when sourcing upstream traffic. Unfortunately, 153 for the host, the appropriate source address is a function of the 154 upstream network for which the packet is bound for. If an 155 upstream service provider uses IP anti-spoofing or ingress 156 filtering, it is conceivable that the packets that have an 157 inappropriate source address for the upstream network would never 158 reach their destination. 160 o In a multihomed environment, different DNS scopes or partitions 161 may exist in each independent upstream network. A DNS query sent 162 to an arbitrary upstream DNS recursive name servier may result in 163 incorrect or poisoned responses. 165 In short, while IPv6 facilitates hosts having more than one address 166 in the same address scope, the application of this causes significant 167 issues for a host from routing, source address selection and DNS 168 resolution perspectives. A possible consequence of assigning a host 169 multiple identically-scoped addresses is severely impaired IP 170 connectivity. 172 If a host connects to a network behind an IPv4 NAPT, the host has one 173 private address in the local network. There is no confusion. The 174 NAT becomes the gateway of the host and forwards the packet to an 175 appropriate network when it is multihomed. It also operates a DNS 176 cache server, which receives all DNS inquires, and gives a correct 177 answer to the host. 179 In this document, we analyze the use cases of multihoming. We also 180 describe functional requirements and possible solutions for 181 multihoming without the use of NAT in IPv6 for hosts and small IPv6 182 networks that would otherwise be unable to meet minimum IPv6 183 allocation criteria. Nevertheless, we mention that the possible 184 needs for IPv6 NAT in the transition phase to the fully deployment of 185 the proposed solutions. 187 2. Terminology 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to NPTv6 194 [RFC6296]. 196 NAPT Network Address Port Translation as described 197 in [RFC3022]. In other contexts, NAPT is often 198 pronounced "NAT" or written as "NAT". 200 Multihomed with multi-prefix (MHMP) A host implementation which 201 supports the mechanisms described in this 202 document. Namely source address selection 203 policy, next-hop selection and DNS selection 204 policy. 206 3. IPv6 multihomed network scenarios 208 In this section, we classify three scenarios of the multihoming 209 environment. 211 3.1. Classification of network scenarios for multihomed host 213 Scenario 1: 215 In this scenario, two or more routers are present on a single link 216 shared with the host(s). Each router is in turn connected to a 217 different service provider network, which provides independent 218 address assignment and DNS recursive name servers. A host in this 219 environment would be offered multiple prefixes and DNS recursive name 220 servers advertised from the two different routers. 222 +------+ ___________ 223 | | / \ 224 +---| rtr1 |=====/ network \ 225 | | | \ 1 / 226 +------+ | +------+ \___________/ 227 | | | 228 | hosts|-----+ 229 | | | 230 +------+ | +------+ ___________ 231 | | | / \ 232 +---| rtr2 |=====/ network \ 233 | | \ 2 / 234 +------+ \___________/ 236 Figure 1: single uplink, multiple next-hop, multiple prefix 237 (Scenario 1) 239 Figure 1 illustrates the host connecting to rtr1 and rtr2 via a 240 shared link. Networks 1 and 2 are reachable via rtr1 and rtr2 241 respectively. When the host sends packets to network 1, the next-hop 242 to network 1 is rtr1. Similarly, rtr2 is the next-hop to network 2. 244 - e.g., broadband service (Internet, VoIP, IPTV, etc.) 246 Scenario 2: 248 In this scenario, a single gateway router connects the host to two or 249 more upstream service provider networks. This gateway router would 250 receive prefix delegations and a different set of DNS recursive name 251 servers from each independent service provider network. The gateway 252 in turn advertises the provider prefixes to the host, and for DNS, 253 may either act as a lightweight DNS cache server or may advertise the 254 complete set of service provider DNS recursive name servers to the 255 hosts. 257 +------+ ___________ 258 +-----+ | | / \ 259 | |=======| rtr1 |=====/ network \ 260 | |port1 | | \ 1 / 261 +------+ | | +------+ \___________/ 262 | | | | 263 | hosts|-----| GW | 264 | | | rtr | 265 +------+ | | +------+ ___________ 266 | |port2 | | / \ 267 | |=======| rtr2 |=====/ network \ 268 +-----+ | | \ 2 / 269 +------+ \___________/ 271 Figure 2: single uplink, single next-hop, multiple prefix 272 (Scenario 2) 274 Figure 2 illustrates the host connected to GW rtr. GW rtr connects 275 to networks 1 and 2 via port1 and 2 respectively. When the host 276 sends packets to either network 1 or 2, the next-hop is GW rtr. When 277 the packets are sent to network 1 (network 2), GW rtr forwards the 278 packets to port1 (port2). 280 - e.g, Internet + VPN/Application Service Provider (ASP) 282 Scenario 3: 284 In this scenario, a host has more than one active interface that 285 connects to different routers and service provider networks. Each 286 router provides the host with a different address prefix and set of 287 DNS recursive name servers, resulting in a host with a unique address 288 per link/interface. 290 +------+ +------+ ___________ 291 | | | | / \ 292 | |-----| rtr1 |=====/ network \ 293 | | | | \ 1 / 294 | | +------+ \___________/ 295 | | 296 | host | 297 | | 298 | | +------+ ___________ 299 | | | | / \ 300 | |=====| rtr2 |=====/ network \ 301 | | | | \ 2 / 302 +------+ +------+ \___________/ 304 Figure 3: Multiple uplink, multiple next-hop, multiple prefix 305 (Scenario 3) 307 Figure 3 illustrates the host connecting to rtr1 and rtr2 via a 308 direct connection or a virtual link. When the host sends packets 309 network 1, the next-hop to network 1 is rtr1. Similarly, rtr2 is the 310 next-hop to network 2. 312 - e.g., Mobile Wifi + 3G, ISP A + ISP B 314 3.2. Multihomed network environment 316 In an IPv6 multihomed network, a host is assigned two or more IPv6 317 addresses and DNS recursive name servers from independent service 318 provider networks. When this multihomed host attempts to connect 319 with other hosts, it may incorrectly resolve the next-hop router, use 320 an inappropriate source address, or use a DNS response from an 321 incorrect service provider that may result in impaired IP 322 connectivity. 324 Multihomed networks in IPv4 have been commonly implemented through 325 the use of a gateway router with NAPT function (scenario 2 with 326 NAPT). An analysis of the current IPv4 NAPT and DNS functions within 327 the gateway router should provide a baseline set of requirements for 328 IPv6 multihomed environments. A destination prefix/route is often 329 used on the gateway router to separate traffic between the networks. 331 +------+ ___________ 332 | | / \ 333 +---| rtr1 |=====/ network \ 334 | | | \ 1 / 335 +------+ +-----+ | +------+ \___________/ 336 | IPv4 | | | | 337 | host |-----| GW |---+ 338 | | | rtr | | 339 +------+ +-----+ | +------+ ___________ 340 (NAPT&DNS) | | | / \ 341 (private +---| rtr2 |=====/ network \ 342 address | | \ 2 / 343 space) +------+ \___________/ 345 Figure 4: IPv4 Multihomed environment with Gateway Router performing 346 NAPT 348 3.3. Problem Statement 350 A multihomed IPv6 host has one or more assigned IPv6 addresses and 351 DNS recursive name servers from each upstream service provider, 352 resulting in the host having multiple valid IPv6 addresses and DNS 353 recursive name servers. The host must be able to resolve the 354 appropriate next-hop, the correct source address and DNS recursive 355 name server to use based on the destination prefix. To prevent IP 356 spoofing, operators will often implement ingress filtering to discard 357 traffic with an inappropriate source address, making it essential for 358 the host to correctly resolve these three items before sourcing the 359 first packet. 361 IPv6 has mechanisms for the provision of multiple routers on a single 362 link and multiple address assignments to a single host. However, 363 when these mechanisms are applied to the three scenarios in 364 Section 3.1 a number of connectivity issues are identified: 366 Scenario 1: 368 The host has been assigned an address from each router and recognizes 369 both rtr1 and rtr2 as valid default routers (in the default routers 370 list). 372 o The source address selection policy on the host does not 373 deterministically resolve a source address. Ingress filtering or 374 filter policies will discard traffic with source addresses that 375 the operator did not assign. 377 o The host will select one of the two routers as the active default 378 router. No traffic is sent to the other router. 380 Scenario 2: 382 The host has been assigned two different addresses from the single 383 gateway router. The gateway router is the only default router on the 384 link. 386 o The source address selection policy on the host does not 387 deterministically resolve a source address. Ingress filtering or 388 filter policies will discard traffic with source addresses that 389 the operator did not assign. 391 o The gateway router does not have an autonomous mechanism for 392 determining which traffic should be sent to which network. If the 393 gateway router is implementing host functions (i.e., processing 394 Router Advertisement) then two valid default routers may be 395 recognized. 397 Scenario 3: 399 A host has two separate interfaces and on each interface a different 400 address is assigned. Each link has its own router. 402 o The host does not have enough information for determining which 403 traffic should be sent to which upstream routers. The host will 404 select one of the two routers as the active default router, and no 405 traffic is sent to the other router. The default address 406 selection rules select the address assigned to the outgoing 407 interface as the source address. So, if a host has an appropriate 408 routing table, an appropriate source address will be selected. 410 All scenarios: 412 o In network deployments utilizing local namespaces, the host may 413 choose to communicate with a "wrong" DNS recursive server unable 414 to serve a local namespace. 416 4. Requirements 418 This section describes requirements that any solution multi-address 419 and multi-uplink architectures need to meet. 421 4.1. End-to-End transparency 423 One of the major design goals for IPv6 is to restore the end-to-end 424 transparency of the Internet. If NAT mechanism is applied to IP 425 communication between hosts, it is required to apply complex NAT 426 traversal mechanism to establish bi-directional IP communication. 428 Essentially, extra NAT traversal meachanism does not need to be 429 implemented on application, on an environment with end-to-end 430 transparency. Therefore, The IPv6 multihoming solution SHOULD 431 guarantee end-to-end transparency by avoiding IPv6 NAT. 433 4.2. Policy distribution 435 The solution SHOULD have a function to provide a policy on sites/ 436 nodes. In particular, a network service provider has to control his 437 or her user nodes such as CPE devices. All nodes are not necessarily 438 controlled evenly with policy providing. It is required to identify 439 a nodes and provide indepenent policy by each node. 441 The providing mechanisms should have: 443 o a function to distribute policies to nodes dynamically to update 444 their behavior. When the network environment changes and the 445 nodes' behavior has to be changed, a network administrator can 446 modify the behavior of the nodes. 448 o a function to control every node centrally. A site administrator 449 or a service provider could determine or could have an effect on 450 the behavior at their users' hosts. 452 o a function to control node-specific behavior. Even when multiple 453 nodes are on the same subnet, the mechanism should be able to 454 provide a method for the network administrator to make nodes 455 behave differently. For example, each node may have a different 456 set of assigned prefixes. In such a case, the appropriate 457 behavior may be different. 459 4.3. Scalability 461 The solution will have to be able to manage a large number of sites/ 462 nodes. In services for residential users, provider edge devices have 463 to manage thousands of sites. In such environments, sending packets 464 periodically to each site may affect edge system performance. 466 5. Problem statement and analysis 468 The problems described in Section 3 can be classified into these 469 three types: 471 o Wrong source address selection 473 o Wrong next-hop selection 474 o Wrong DNS server selection 476 This section reviews the problem statements presented above and the 477 proposed functional requirements to resolve the issues. 479 5.1. Source address selection 481 A multihomed IPv6 host will typically have different addresses 482 assigned from each service provider either on the same link 483 (scenarios 1 & 2) or different links (scenario 3). When the host 484 wishes to send a packet to any given destination, the current source 485 address selection rules [RFC3484] may not deterministically resolve 486 the correct source address when the host addressing was via Router 487 Advertisement (RA) or DHCPv6. 488 [I-D.ietf-6man-addr-select-considerations] describes the use of the 489 policy table [RFC3484] to resolve this problem, but there is no 490 mechanism defined to disseminate the policy table information to a 491 host. A proposal is in [I-D.ietf-6man-addr-select-opt] to provide a 492 DHCPv6 mechanism for host policy table management. 494 Again, by employing DHCPv6, the server could restrict address 495 assignment (of additional prefixes) only to hosts that support policy 496 table management. 498 Scenario 1: "Host" needs to support the solution for this problem. 500 Scenario 2: "Host" needs to support the solution for this problem. 502 Scenario 3: If "Host" support the next-hop selection solution, there 503 is no need to support the address selection functionality on the 504 host. 506 It is noted that the service providers (i.e., ISP and enterprise/VPN) 507 must also support [I-D.ietf-6man-addr-select-opt]. 509 5.2. Next-hop selection 511 A multihomed IPv6 host or gateway may have multiple uplinks to 512 different service providers. Here each router would use Router 513 Advertisements [RFC4861] for distributing default route/next-hop 514 information to the host or gateway router. 516 In this case, the host or gateway router may select any valid default 517 router from the default routers list, resulting in traffic being sent 518 to the wrong router and discarded by the upstream service provider. 519 Using the above scenarios as an example, whenever the host wishes to 520 reach a destination in network 2 and there is no connectivity between 521 networks 1 and 2 (as is the case for a walled-garden or closed 522 service), the host or gateway router does not know whether to forward 523 traffic to rtr1 or rtr2 to reach a destination in network 2. The 524 host or gateway router may choose rtr1 as the default router, and 525 traffic fails to reach the destination server. The host or gateway 526 router requires route information for each upstream service provider, 527 but the use of a routing protocol between the gateway and the two 528 routers causes both configuration and scaling issues. For IPv4 529 hosts, the gateway router is often pre-configured with static route 530 information or uses of Classless Static Route Options [RFC3442] for 531 DHCPv4. Extensions to Router Advertisements through Default Router 532 Preference and More-Specific Routes [RFC4191] provides for link- 533 specific preferences but does not address per-host configuration in a 534 multi-access topology because of its reliance on Router 535 Advertisements. A DHCPv6 option, such as that in 536 [I-D.ietf-mif-dhcpv6-route-option], is preferred for host-specific 537 configuration. By employing a DHCPv6 solution, a DHCPv6 server could 538 restrict address assignment (of additional prefixes) only to hosts 539 that support more advanced next-hop and address selection 540 requirements. 542 Scenario 1: "Host" needs to support the solution for this problem. 544 Scenario 2: "GW rtr" needs to support the solution for this problem. 546 Scenario 3: "Host" needs to support the solution for this problem. 548 It is noted that the service providers (i.e., ISP and enterprise/VPN) 549 must also support [I-D.ietf-mif-dhcpv6-route-option]. 551 5.3. DNS recursive name server selection 553 A multihomed IPv6 host or gateway router may be provided multiple DNS 554 recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106]. 555 When the host or gateway router sends a DNS query, it would normally 556 choose one of the available DNS recursive name servers for the query. 558 In the IPv6 gateway router scenario, the Broadband Forum [TR124] 559 required that the query be sent to all DNS recursive name servers, 560 and the gateway waits for the first reply. In IPv6, given our use of 561 specific destination-based policy for both routing and source address 562 selection, it is desirable to extend a policy-based concept to DNS 563 recursive name server selection. Doing so can minimize DNS recursive 564 name server load and avoid issues where DNS recursive name servers in 565 different networks have connectivity issues, or the DNS recursive 566 name server are not publicly accessible. In the worst case, a DNS 567 query for a name from a local namespace may not be resolved correctly 568 if sent towards a DNS server not aware of said local namespace, 569 resulting in a lack of connectivity. 571 It is not issue of Domain Name System model itself, but an IPv6 572 multihomed host or gateway router should have the ability to select 573 appropriate DNS recursive name servers for each service based on the 574 domain space for the destination, and each service should provide 575 rules specific to that network. [I-D.ietf-mif-dns-server-selection] 576 proposes a solution for distributing DNS server selection policy 577 using a DHCPv6 option. 579 Scenario 1: "Host" needs to support the solution for this problem. 581 Scenario 2: "GW rtr" needs to support the solution for this problem. 583 Scenario 3: "Host" needs to support the solution for this problem. 585 It is noted that the service providers (i.e., ISP and enterprise/VPN) 586 must also support [I-D.ietf-mif-dns-server-selection]. 588 6. Implementation approach 590 As mentioned in Section 5, in the multi-prefix environment, we have 591 three problems in source address selection, next-hop selection, and 592 DNS recursive name server selection. In this section, possible 593 solution mechanisms for each problem are introduced and evaluated 594 against the requirements in Section 4. 596 6.1. Source address selection 598 Possible solutions and their evaluation are summarized in 599 [I-D.ietf-6man-addr-select-considerations]. When those solutions are 600 examined against the requirements in Section 4, the proactive 601 approaches, such as the policy table distribution mechanism and the 602 routing hints mechanism, are more appropriate in that they can 603 propagate the network administrator's policy directly. The policy 604 distribution mechanism has an advantage with regard to the host's 605 protocol stack impact and the static nature of the assumed target 606 network environment. 608 6.2. Next-hop selection 610 As for the source address selection problem, both a policy-based 611 approach and a non policy-based approach are possible with regard to 612 the next-hop selection problem. Because of the same requirements, 613 the policy propagation-based solution mechanism, whatever the policy, 614 should be more appropriate. 616 Routing information is a typical example of policy related to next- 617 hop selection. If we assume source address-based routing at hosts or 618 intermediate routers, the pairs of source prefixes and next-hops can 619 be another example of next-hop selection policy. 621 The routing information-based approach has a clear advantage in 622 implementation and is already commonly used. 624 The existing proposed or standardized routing information 625 distribution mechanisms are routing protocols, such as RIPng and 626 OSPFv3, the RA extension option defined in [RFC4191], the DHCPv6 627 route information option proposed in 628 [I-D.ietf-mif-dhcpv6-route-option], and the [TR069] standardized at 629 BBF. 631 The RA-based mechanism has difficulty in per-host routing information 632 distribution. The dynamic routing protocols such as RIPng are not 633 usually used between the residential users and ISP networks because 634 of their scalability implications. The DHCPv6 mechanism does not 635 have these difficulties and has the advantage of its relaying 636 functionality. It is commonly used and is thus easy to deploy. 638 [TR069], mentioned above, is a possible solution mechanism for 639 routing information distribution to customer-premises equipment 640 (CPE). It assumes, however, IP reachability to the Auto 641 Configuration Server (ACS) is established. Therefore, if the CPE 642 requires routing information to reach the ACS, [TR069] cannot be used 643 to distribute this information. 645 6.3. DNS recursive name server selection 647 As in the above two problems, a policy-based approach and non policy- 648 based approach are possible. In a non policy-based approach, a host 649 or a home gateway router is assumed to send DNS queries to several 650 DNS recursive name servers at once or to select one of the available 651 servers. 653 In the non policy-based approach, by making a query to a DNS 654 recursive name server in a different service provider to that which 655 hosts the service, a user could be directed to unexpected IP address 656 or receive an invalid response, and thus cannot connect to the 657 service provider's private and legitimate service. For example, some 658 DNS recursive name servers reply with different answers depending on 659 the source address of the DNS query, which is sometimes called split- 660 horizon. When the host mistakenly makes a query to a different 661 provider's DNS recursive name server to resolve a FQDN of another 662 provider's private service, and the DNS recursive name server adopts 663 the split-horizon configuration, the queried server returns an IP 664 address of the non-private side of the service. Another problem with 665 this approach is that it causes unnecessary DNS traffic to the DNS 666 recursive name servers that are visible to the users. 668 The alternative of a policy-based approach is documented in 669 [I-D.ietf-mif-dns-server-selection], where several pairs of DNS 670 recursive name server addresses and DNS domain suffixes are defined 671 as part of a policy and conveyed to hosts in a new DHCP option. In 672 an environment where there is a home gateway router, that router can 673 act as a DNS recursive name server, interpret this option and 674 distribute DNS queries to the appropriate DNS servers according to 675 the policy. 677 7. Considerations for host without multi-prefix support 679 This section presents an alternative approach to mitigate the problem 680 in a multihomed network. This approach will help IPv6 hosts that are 681 not capable of the enhancements for the source address selection 682 policy, next-hop selection policy, and DNS selection policy described 683 in Section 6. 685 7.1. IPv6 NAT 687 In a typical IPv4 multihomed network deployment, IPv4 NAPT is 688 practically used and it can eventually avoid assigning multiple 689 addresses to the hosts and solve the next-hop selection problem. In 690 a similar fashion, IPv6 NAT can be used as a last resort for IPv6 691 multihomed network deployments where one needs to assign a single 692 IPv6 address to a host. 694 __________ 695 / \ 696 +---/ Internet \ 697 gateway router | \ / 698 +------+ +---------------------+ | \__________/ 699 | | | | | WAN1 +--+ 700 | host |-----|LAN| Router |--------| 701 | | | | |NAT|WAN2+--+ 702 +------+ +---------------------+ | __________ 703 | / \ 704 +---/ ASP \ 705 \ / 706 \__________/ 708 Figure 5: Legacy Host 710 The gateway router also has to support the two features, next-hop 711 selection and DNS server selection, shown in Section 6. 713 The implementation and issues of IPv6 NAT are out of the scope of 714 this document. They may be covered by another document under 715 discussion [RFC6296]. 717 7.2. Co-existence consideration 719 To allow the co-existence of non-MHMP hosts and MHMP hosts (i.e. 720 hosts supporting multi-prefix with the enhancements for the source 721 address selection), GW-rtr may need to treat those hosts separately. 723 An idea to achieve this is that GW-rtr identifies the hosts, and then 724 assigns a single prefix to non-MHMP hosts and assigns multiple 725 prefixes to MHMP hosts. In this case, GW-rtr can perform IPv6 NAT 726 only for the traffic from non-MHMP hosts if its source address is not 727 appropriate. 729 Another idea is that GW-rtr assigns multiple prefixes to the both 730 hosts, and it performs IPv6 NAT for the traffic from non-MHMP hosts 731 if its source address is not appropriate. 733 In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT 734 box. In this case, the non-MHMP host can access the service through 735 the NAT box. 737 The implementation of identifying non-MHMP hosts and NAT policy is 738 outside the scope of this document. 740 8. Security Considerations 742 This document requires that the solutions for MHMP should have policy 743 providing functions. New security threats can be introduced 744 depending on what kind and what form of the policy. The threats can 745 be categorized in two parts: the policy receiver side and the policy 746 distributor side. 748 A policy receiver may receive an evil policy from a policy 749 distributor. A policy distributor should expect some hosts in its 750 network do not follow the distributed policy. The security threats 751 related to IPv6 multihoming are described in [RFC4218]. Those 752 threats that are specific to MHMP solutions are enumerated below. 754 Threats related to the policy distributor side: 756 Policy collision can happen. When multiple policy distributor 757 exists, a policy receiver may not follow one or each of the 758 received policy. Especially when a policy conflicts with 759 another policy, a policy receiver cannot implement each of the 760 policy. To solve or mitigate this issue, policy prioritization 761 rule should be defined, such as preference for the policy 762 received on a trusted interface. Another solution is to 763 preclude the functionality of multiple policy acceptance at the 764 receiver side. In this case, a policy distributor should 765 cooperate with other policy distributors, and a single 766 representative provider should distribute a merged policy. 768 Apart from the policy collision, a network service provider 769 should expect the existence of hosts that will not obey the 770 received policy. A possible solutions is to ingress-filter 771 those packets that do not match the distributed policy and drop 772 them. About the route selection, packet forwarding or 773 redirection can be another possible solution. About the source 774 address selection, IPv6 NAT can be another possible solution. 776 Threats related to the policy receiver side: 778 A policy receiver are exposed to the threats of unauthorized 779 policy, which can lead to session hijack, DoS, wiretapping and 780 phishing. Unauthorized policy here means a policy distributed 781 from an entity that does not have rights to do so. Usually, 782 only a site administrator and a network service provider have 783 rights to distribute these policies just as well as IP address 784 assignment and DNS server address notification. Regarding 785 source address selection, unauthorized policy can expose an IP 786 address that will not usually be exposed to an external server, 787 which can be a privacy problem. To solve or mitigate this 788 problem of unauthorized policy, one approach is limiting on use 789 of these policy distribution mechanisms, as described in the 790 section 4.4 of [I-D.ietf-mif-dns-server-selection]. For 791 example, a policy should be preferred or accepted when the 792 policy is delivered across a secure, trusted channel such as 3G 793 connection in cellular services. The proposed solutions are 794 baed on DHCP, so the limitation of local site communication, 795 which is often used in WiFi access services, should be another 796 solution or mitigation for this problem. About DNS server 797 selection issue, DNSSEC can be another solution. About source 798 address selection, the ingress filter at the network service 799 provider router can be a solution. 801 Another threat is the leakage of the policy and privacy issues 802 resulting from that. Especially when each client is 803 distributed its own policy from the network service provider, 804 the policy can give a hint of which service the client 805 subscribes. Encryption of communication channel, separation of 806 communication channel per host can be solutions for this 807 problem. 809 9. IANA Considerations 811 This document has no IANA actions. 813 10. Contributors 815 The following people contributed to this document: Akiko Hattori, 816 Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, 817 Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, 818 Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has 819 greatly benefited from inputs by Randy Bush, Brian Carpenter, and 820 Teemu Savolainen. 822 11. References 824 11.1. Normative References 826 [I-D.ietf-6man-addr-select-considerations] 827 Chown, T., "Considerations for IPv6 Address Selection 828 Policy Changes", 829 draft-ietf-6man-addr-select-considerations-03 (work in 830 progress), March 2011. 832 [I-D.ietf-6man-addr-select-opt] 833 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 834 "Distributing Address Selection Policy using DHCPv6", 835 draft-ietf-6man-addr-select-opt-01 (work in progress), 836 June 2011. 838 [I-D.ietf-mif-dhcpv6-route-option] 839 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 840 Route Options", draft-ietf-mif-dhcpv6-route-option-02 841 (work in progress), July 2011. 843 [I-D.ietf-mif-dns-server-selection] 844 Savolainen, T., Kato, J., and T. Lemon, "Improved DNS 845 Server Selection for Multi-Homed Nodes", 846 draft-ietf-mif-dns-server-selection-03 (work in progress), 847 June 2011. 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels", BCP 14, RFC 2119, March 1997. 852 [RFC3484] Draves, R., "Default Address Selection for Internet 853 Protocol version 6 (IPv6)", RFC 3484, February 2003. 855 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 856 More-Specific Routes", RFC 4191, November 2005. 858 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 859 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 860 September 2007. 862 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 863 Translation", RFC 6296, June 2011. 865 11.2. Informative References 867 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 868 Address Translator (Traditional NAT)", RFC 3022, 869 January 2001. 871 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 872 Static Route Option for Dynamic Host Configuration 873 Protocol (DHCP) version 4", RFC 3442, December 2002. 875 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 876 Multihoming Architectures", RFC 3582, August 2003. 878 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 879 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 880 December 2003. 882 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 883 Gill, "IPv4 Multihoming Practices and Limitations", 884 RFC 4116, July 2005. 886 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 887 Multihoming Solutions", RFC 4218, October 2005. 889 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 890 RFC 4960, September 2007. 892 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 893 "IPv6 Router Advertisement Options for DNS Configuration", 894 RFC 6106, November 2010. 896 [TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol 897 v1.1, Version: Issue 1 Amendment 2", December 2007. 899 [TR124] The BroadBand Forum, "TR-124i2, Functional Requirements 900 for Broadband Residential Gateway Devices (work in 901 progress)", May 2010. 903 Authors' Addresses 905 Ole Troan (editor) 906 Cisco 907 Bergen 908 Norway 910 Email: ot@cisco.com 912 David Miles 913 Alcatel-Lucent 914 Melbourne 915 Australia 917 Email: david.miles@alcatel-lucent.com 919 Satoru Matsushima 920 Softbank Telecom 921 Tokyo 922 Japan 924 Email: satoru.matsushima@tm.softbank.co.jp 926 Tadahisa Okimoto 927 NTT West 928 Osaka 929 Japan 931 Email: t.okimoto@rdc.west.ntt.co.jp 933 Dan Wing 934 Cisco 935 170 West Tasman Drive 936 San Jose 937 USA 939 Email: dwing@cisco.com