idnits 2.17.1 draft-ietf-v6ops-multihoming-without-nat66-00.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 (December 6, 2010) is 4883 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-mrw-nat66-00 == Outdated reference: A later version (-06) exists of draft-savolainen-mif-dns-server-selection-05 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5006 (Obsoleted by RFC 6106) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: June 9, 2011 Alcatel-Lucent 6 S. Matsushima 7 SOFTBANK TELECOM Corp. 8 T. Okimoto 9 NTT West 10 D. Wing 11 Cisco 12 December 6, 2010 14 IPv6 Multihoming without Network Address Translation 15 draft-ietf-v6ops-multihoming-without-nat66-00 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 host-to- 25 host connectivity. In this document, we analyze the use cases of 26 multihoming. We also describe functional requirements for 27 multihoming without the use of NAT in IPv6 for hosts and small IPv6 28 networks that would otherwise be unable to meet minimum IPv6 29 allocation criteria . 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 9, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. IPv6 multihomed network scenarios . . . . . . . . . . . . . . 5 67 3.1. Classification of network scenarios for multihomed host . 5 68 3.2. Multihomed network environment . . . . . . . . . . . . . . 7 69 3.3. Multihomed Problem Statement . . . . . . . . . . . . . . . 8 70 4. Problem statement and analysis . . . . . . . . . . . . . . . . 9 71 4.1. Source address selection . . . . . . . . . . . . . . . . . 10 72 4.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 10 73 4.3. DNS server selection . . . . . . . . . . . . . . . . . . . 11 74 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.1. End-to-End transparency . . . . . . . . . . . . . . . . . 12 76 5.2. Policy enforcement . . . . . . . . . . . . . . . . . . . . 12 77 5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 78 6. Implementation approach . . . . . . . . . . . . . . . . . . . 13 79 6.1. Source address selection . . . . . . . . . . . . . . . . . 13 80 6.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 13 81 6.3. DNS resolver selection . . . . . . . . . . . . . . . . . . 14 82 7. Considerations for host without multi-prefix support . . . . . 14 83 7.1. IPv6 NAT . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 7.2. Co-exisitence consideration . . . . . . . . . . . . . . . 15 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 IPv6 provides enough globally unique addresses to permit every 96 conceivable host on the Internet to be uniquely addressed without the 97 requirement for Network Address Port Translation (NAPT [RFC3022]) 98 offering a renaissance in host-to-host transparent connectivity. 100 Unfortunately, this may not be possible due to the necessity of NAT 101 even in IPv6, because of multihoming. 103 Multihoming is a blanket term to describe a host or small network 104 that is connected to more than one upstream network. Whenever a host 105 or small network (which does not meet minimum IPv6 allocation 106 criteria) is connected to multiple upstream networks IPv6 addressing 107 is assigned by each respective service provider resulting in hosts 108 with more than one active IPv6 address. As each service provided is 109 allocated a different address space from its Internet Registry, it 110 in-turn assigns a different address space to the end-user network or 111 host. For example, a remote access user may use a VPN to 112 simultaneously connect to a remote network and retain a default route 113 to the Internet for other purposes. 115 In IPv4 a common solution to the multihoming problem is to employ 116 NAPT on a border router and use private address space for individual 117 host addressing. The use of NAPT allows hosts to have exactly one IP 118 address visible on the public network and the combination of NAPT 119 with provider-specific outside addresses (one for each uplink) and 120 destination-based routing insulates a host from the impacts of 121 multiple upstream networks. The border router may also implement a 122 DNS cache or DNS policy to resolve address queries from hosts. 124 It is our goal to avoid the IPv6 equivalent of NAT. To reach this 125 goal, mechanisms are needed for end-user hosts to have multiple 126 address assignments and resolve issues such as which address to use 127 for sourcing traffic to which destination: 129 o If multiple routers exist on a single link the host must 130 appropriately select next-hop for each connected network. Routing 131 protocols that would normally be employed for router-to-router 132 network advertisement seem inappropriate for use by individual 133 hosts. 135 o Source address selection also becomes difficult whenever a host 136 has more than one address within the same address scope. Current 137 address selection criteria may result in hosts using an arbitrary 138 or random address when sourcing upstream traffic. Unfortunately, 139 for the host, the appropriate source address is a function of the 140 upstream network for which the packet is bound for. If an 141 upstream service provider uses IP anti-spoofing or uRPF, it is 142 conceivable that the packets that have inappropriate source 143 address for the upstream network would never reach their 144 destination. 146 o In a multihomed environment, different DNS scopes or partitions 147 may exist in each independent upstream network. A DNS query sent 148 to an arbitrary upstream resolver may result in incorrect or 149 poisoned responses. 151 In short, while IPv6 facilitates hosts having more than one address 152 in the same address scope, the application of this causes significant 153 issues for a host from routing, source address selection and DNS 154 resolution perspectives. A possible consequence of assigning a host 155 multiple identical-scoped addresses is severely impaired IP 156 connectivity. 158 If a host connects to a network behind an IPv4 NAPT, the host has one 159 private address in the local network. There is no confusion. The 160 NAT becomes the gateway of the host and forwards the packet to an 161 appropriate network when it is multihomed. It also operates a DNS 162 cache server, which receives all DNS inquires, and gives a correct 163 answer to the host. 165 In this document, we identify the functions present in multihomed 166 IPv4 NAPT environments and propose requirements that address 167 multihomed IPv6 environments without using IPv6 NAT. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 NAT66 or IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to 176 [I-D.mrw-nat66]. 178 NAPT Network Address Port Translation as described 179 in [RFC3022]. In other contexts, NAPT is often 180 pronounced "NAT" or written as "NAT". 182 Multihomed with multi-prefix (MHMP) A host implementation which 183 supports the mechanisms described in this 184 document. Namely source address selection 185 policy, next-hop selection and DNS selection 186 policy. 188 3. IPv6 multihomed network scenarios 190 In this section, we classify three scenarios of the multihoming 191 environment. 193 3.1. Classification of network scenarios for multihomed host 195 Scenario 1: 197 In this scenario, two or more routers are present on a single link 198 shared with the host(s). Each router is in turn connected to a 199 different service provider network, which provides independent 200 address assignment and DNS resolvers. A host in this environment 201 would be offered multiple prefixes and DNS resolvers advertised from 202 the two different routers. 204 +------+ ___________ 205 | | / \ 206 +---| rtr1 |=====/ network \ 207 | | | \ 1 / 208 +------+ | +------+ \___________/ 209 | | | 210 | host |-----+ 211 | | | 212 +------+ | +------+ ___________ 213 | | | / \ 214 +---| rtr2 |=====/ network \ 215 | | \ 2 / 216 +------+ \___________/ 218 Figure 1: single uplink, multiple next-hop, multiple prefix 219 (Scenario 1) 221 Figure 1 illustrates the host connecting to rtr1 and rtr2 via a 222 shared link. Networks 1 and 2 are reachable via rtr1 and rtr2 223 respectively. When the host sends packets to network 1, the next-hop 224 to network 1 is rtr1. Similarly, rtr2 is the next-hop to network 2. 226 - e.g., broadband service (Internet, VoIP, IPTV, etc.) 228 Scenario 2: 230 In this scenario, a single gateway router connects the host to two or 231 more upstream service provider networks. This gateway router would 232 receive prefix delegations from each independent service provider 233 network and a different set of DNS resolvers. The gateway in turn 234 advertises the provider prefixes to the host, and for DNS, may either 235 act as a lightweight DNS resolver/cache or may advertise the complete 236 set of service provider DNS resolvers to the hosts. 238 +------+ ___________ 239 | | / \ 240 +---| rtr1 |=====/ network \ 241 | | | \ 1 / 242 +------+ +-----+ | +------+ \___________/ 243 | | | | | 244 | host |-----| GW |---+ 245 | | | rtr | | 246 +------+ +-----+ | +------+ ___________ 247 | | | / \ 248 +---| rtr2 |=====/ network \ 249 | | \ 2 / 250 +------+ \___________/ 252 Figure 2: single uplink, single next-hop, multiple prefix 253 (Scenario 2) 255 Figure 2 illustrates the host connected to GW rtr. GW rtr connects 256 to networks 1 and 2 via rtr1 and rtr2, respectively. When the host 257 sends packets to either network 1 or 2, the next-hop is GW rtr. When 258 the packets are sent to network 1 (network 2), GW rtr forwards the 259 packets to rtr1 (rtr2). 261 - e.g, Internet + VPN/ASP 263 Scenario 3: 265 In this scenario, a host has more than one active interfaces that 266 connects to different routers and service provider networks. Each 267 router provides the host with a different address prefix and set of 268 DNS resolvers, resulting in a host with a unique address per link/ 269 interface. 271 +------+ +------+ ___________ 272 | | | | / \ 273 | |-----| rtr1 |=====/ network \ 274 | | | | \ 1 / 275 | | +------+ \___________/ 276 | | 277 | host | 278 | | 279 | | +------+ ___________ 280 | | | | / \ 281 | |=====| rtr2 |=====/ network \ 282 | | | | \ 2 / 283 +------+ +------+ \___________/ 285 Figure 3: Multiple uplink, multiple next-hop, multiple prefix 286 (Scenario 3) 288 Figure 3 illustrates the host connecting to rtr1 and rtr2 via a 289 direct connection or a virtual link. When the host sends packets 290 network 1, the next-hop to network 1 is rtr1. Similarly, rtr2 is the 291 next-hop to network 2. 293 - e.g., Mobile Wifi + 3G, ISP A + ISP B 295 3.2. Multihomed network environment 297 In an IPv6 multihomed network, a host is assigned two or more IPv6 298 addresses and DNS resolvers from independent service provider 299 networks. When this multihomed host attempts to connect with other 300 hosts, it may incorrectly resolve the next-hop router, use an 301 inappropriate source address, or use a DNS response from an incorrect 302 service provider that may result in impaired IP connectivity. 304 Multihomed networks in IPv4 have been commonly implemented through 305 the use of a gateway router with NAPT function (scenario 2 with 306 NAPT). An analysis of the current IPv4 NAPT and DNS functions within 307 the gateway router should provide a baseline set of requirements for 308 IPv6 multihomed environments. A destination prefix/route is often 309 used on the gateway router to separate traffic between the networks. 311 +------+ ___________ 312 | | / \ 313 +---| rtr1 |=====/ network \ 314 | | | \ 1 / 315 +------+ +-----+ | +------+ \___________/ 316 | IPv4 | | | | 317 | host |-----| GW |---+ 318 | | | rtr | | 319 +------+ +-----+ | +------+ ___________ 320 (NAPT&DNS) | | | / \ 321 (private +---| rtr2 |=====/ network \ 322 address | | \ 2 / 323 space) +------+ \___________/ 325 Figure 4: IPv4 Multihomed environment with Gateway Router performing 326 NAPT 328 3.3. Multihomed Problem Statement 330 A multihomed IPv6 host has one or more assigned IPv6 addresses and 331 DNS resolvers from each upstream service provider, resulting in the 332 host having multiple valid IPv6 addresses and DNS resolvers. The 333 host must be able to resolve the appropriate next-hop, the correct 334 source address and DNS resolver to use based on the destination 335 prefix. To prevent IP spoofing, operators will often implement IP 336 filters and uRPF to discard traffic with an inappropriate source 337 address, making it essential for the host to correctly resolve these 338 three criteria before sourcing the first packet. 340 IPv6 has mechanisms for the provision of multiple routers on a single 341 link and multiple address assignments to a single host. However, 342 when these mechanisms are applied to the three scenarios in 343 Section 3.1 a number of connectivity issues are identified: 345 Scenario 1: 347 The host has been assigned an address from each router and recognizes 348 both rtr1 and rtr2 as valid default routers (in the default routers 349 list). 351 o The source address selection policy on the host does not 352 deterministically resolve a source address. Upstream uRPF or 353 filter policies will discard traffic with source addresses that 354 the operator did not assign. 356 o The host will select one of the two routers as the active default 357 router. No traffic is sent to the other router. 359 Scenario 2: 361 The host has been assigned two different addresses from the single 362 gateway router. The gateway router is the only default router on the 363 link. 365 o The source address selection policy on the host does not 366 deterministically resolve a source address. Upstream uRPF or 367 filter policies will discard traffic with source addresses that 368 the operator did not assign. 370 o The gateway router does not have a mechanism for determining which 371 traffic should be sent to which network. If the gateway router is 372 implementing host functions (ie, processing RA) then two valid 373 default routers may be recognized. 375 Scenario 3: 377 A host has two separate interfaces and on each interface a different 378 address is assigned. Each link has its own router. 380 o The host does not have enough information for determining which 381 traffic should be sent to which upstream routers. The host will 382 select one of the two routers as the active default router, and no 383 traffic is sent to the other router. 385 o The default address selection rules select the address assigned to 386 the outgoing interface as the source address. So, if a host has 387 an appropriate routing table, an appropriate source address will 388 be selected. 390 All scenarios: 392 o The host may use an incorrect DNS resolver for DNS queries. 394 4. Problem statement and analysis 396 The problems described in Section 3 can be classified into these 397 three types: 399 o Wrong source address selection 401 o Wrong next-hop selection 403 o Wrong DNS server selection 405 This section reviews the problem statements presented above and the 406 proposed functional requirements to resolve the issues without 407 employing IPv6 NAT. 409 4.1. Source address selection 411 A multihomed IPv6 host will typically have different addresses 412 assigned from each service provider either on the same link 413 (scenarios 1 & 2) or different links (scenario 3). When the host 414 wishes to send a packet to any given destination, the current source 415 address selection rules [RFC3484] may not deterministically resolve 416 the correct source address when the host addressing was via RA or 417 DHCPv6. [I-D.ietf-6man-addr-select-sol] describes the use of the 418 policy table [RFC3484] to resolve this problem, but there is no 419 mechanism defined to disseminate the policy table information to a 420 host. A proposal is in [I-D.fujisaki-dhc-addr-select-opt] to provide 421 a DHCPv6 mechanism for host policy table management. 423 Again, by employing DHCPv6, the server could restrict address 424 assignment (of additional prefixes) only to hosts that support policy 425 table management. 427 Scenario 1: "Host" needs to support the solution for this problem 429 Scenario 2: "Host" needs to support the solution for this problem 431 Scenario 3: If "Host" support the next-hop selection solution, there 432 is no need to support the address selection functionality on the 433 host. 435 4.2. Next-hop selection 437 A multihomed IPv6 host or gateway may have multiple uplinks to 438 different service providers. Here each router would use Router 439 Advertisements [RFC4861] for distributing default route/next-hop 440 information to the host or gateway router. 442 In this case, the host or gateway router may select any valid default 443 router from the default routers list, resulting in traffic being sent 444 to the wrong router and discarded by the upstream service provider. 445 Using the above scenarios as an example, whenever the host wishes to 446 reach a destination in network 2 and there is no connectivity between 447 networks 1 and 2 (as is the case for a walled-garden or closed 448 service), the host or gateway router does not know whether to forward 449 traffic to rtr1 or rtr2 to reach a destination in network 2. The 450 host or gateway router may choose rtr1 as the default router, and 451 traffic fails to reach the destination server. The host or gateway 452 router requires route information for each upstream service provider, 453 but the use of a routing protocol between a host and router causes 454 both configuration and scaling issues. For IPv4 hosts, the gateway 455 router is often pre-configured with static route information or uses 456 of Classless Static Route Options [RFC3442] for DHCPv4. Extensions 457 to Router Advertisements through Default Router Preference and More- 458 Specific Routes [RFC4191] provides for link-specific preferences but 459 does not address per-host configuration in a multi-access topology 460 because of its reliance on Router Advertisements. A DHCPv6 option, 461 such as that in [I-D.dec-dhcpv6-route-option], is preferred for host- 462 specific configuration. By employing a DHCPv6 solution, a DHCPv6 463 server could restrict address assignment (of additional prefixes) 464 only to hosts that support more advanced next-hop and address 465 selection requirements. 467 Scenario 1: "Host" needs to support the solution for this problem 469 Scenario 2: "GW rtr" needs to support the solution for this problem 471 Scenario 3: "Host" needs to support the solution for this problem 473 4.3. DNS server selection 475 A multihomed IPv6 host or gateway router may be provided multiple DNS 476 resolvers through DHCPv6 or the experimental [RFC5006]. When the 477 host or gateway router sends a DNS query, it would normally choose 478 one of the available DNS resolvers for the query. 480 In the IPv6 gateway router scenario, the Broadband Forum [TR124] 481 required that the query be sent to all DNS resolvers, and the gateway 482 waits for the first reply. In IPv6, given our use of specific 483 destination-based policy for both routing and source address 484 selection, it is desirable to extend a policy-based concept to DNS 485 resolver selection. Doing so can minimize DNS resolver load and 486 avoid issues where DNS resolvers in different networks have 487 connectivity issues, or the DNS resolvers are not publicly 488 accessible. In the worst case, a DNS query may be unanswered if sent 489 towards an incorrect resolver, resulting in a lack of connectivity. 491 An IPv6 multihomed host or gateway router should have the ability to 492 select appropriate DNS resolvers for each service based on the domain 493 space for the destination, and each service should provide rules 494 specific to that network. [I-D.savolainen-mif-dns-server-selection] 495 proposes a solution for DNS server selection policy enforcement 496 solution with a DHCPv6 option. 498 Scenario 1: "Host" needs to support the solution for this problem 500 Scenario 2: "GW rtr" needs to support the solution for this problem 501 Scenario 3: "Host" needs to support the solution for this problem 503 5. Requirements 505 This section describes requirements that any solution multi-address 506 and multi-uplink architectures need to meet. 508 5.1. End-to-End transparency 510 End-to-end transparency is a basic concept of the Internet. 511 [RFC4966] states, "One of the major design goals for IPv6 is to 512 restore the end-to-end transparency of the Internet. Therefore, 513 because IPv6 is expected to remove the need for NATs and similar 514 impediments to transparency, developers creating applications to work 515 with IPv6 may be tempted to assume that the complex mechanisms 516 employed by an application to work in a 'NATted' IPv4 environment are 517 not required." The IPv6 multihoming solution SHOULD guarantee end- 518 to-end transparency by avoiding IPv6 NAT. 520 5.2. Policy enforcement 522 The solution SHOULD have a function to enforce a policy on sites/ 523 nodes. In particular, in a managed environment such as enterprise 524 networks, an administrator has to control all nodes in his or her 525 network. 527 The enforcement mechanisms should have: 529 o a function to distribute policies to nodes dynamically to update 530 their behavior. When the network environment changes and the 531 nodes' behavior has to be changed, a network administrator can 532 modify the behavior of the nodes. 534 o a function to control every node centrally. A site administrator 535 or a service provider could determine or could have an effect on 536 the behavior at their users' hosts. 538 o a function to control node-specific behavior. Even when multiple 539 nodes are on the same subnet, the mechanism should be able to 540 provide a method for the network administrator to make nodes 541 behave differently. For example, each node may have a different 542 set of assigned prefixes. In such a case, the appropriate 543 behavior may be different. 545 5.3. Scalability 547 The solution will have to be able to manage a large number of sites/ 548 nodes. In services for residential users, provider edge devices have 549 to manage thousands of sites. In such environments, sending packets 550 periodically to each site may affect edge system performance. 552 6. Implementation approach 554 As mentioned in Section 4, in the multi-prefix environment, we have 555 three problems in source address selection, next-hop selection, and 556 DNS resolver selection. In this section, possible solution 557 mechanisms for each problem are introduced and evaluated against the 558 requirements in Section 5. 560 6.1. Source address selection 562 Possible solutions and their evaluation are summarized in 563 [I-D.ietf-6man-addr-select-sol]. When those solutions are examined 564 against the requirements in Section 5, the proactive approaches, such 565 as the policy table distribution mechanism and the routing system 566 assistance mechanism, are more appropriate in that they can propagate 567 the network administrator's policy directly. The policy distribution 568 mechanism has an advantage with regard to the host's protocol stack 569 impact and the staticness of the assumed target network environment. 571 6.2. Next-hop selection 573 As for the source address selection problem, both a policy-based 574 approach and a non policy-based approach are possible with regard to 575 the next-hop selection problem. Because of the same requirements, 576 the policy propagation-based solution mechanism, whatever the policy, 577 should be more appropriate. 579 Routing information is a typical example of policy related to next- 580 hop selection. If we assume source address-based routing at hosts or 581 intermediate routers, the pairs of source prefixes and next-hops can 582 be another example of next-hop selection policy. 584 The routing information-based approach has a clear advantage in 585 implementation and is already commonly used. 587 The existing proposed or standardized routing information 588 distribution mechanisms are routing protocols, such as RIPng and 589 OSPFv3, the router advertisement (RA) extension option defined in 590 [RFC4191], the DHCPv6 route information option proposed in 591 [I-D.dec-dhcpv6-route-option], and the [TR069] standardized at BBF. 593 The RA-based mechanism has difficulty in per-host routing information 594 distribution. The dynamic routing protocols such as RIPng are not 595 usually used between the residential users and ISP networks because 596 of their scalability implications. The DHCPv6 mechanism does not 597 have these difficulties and has the advantages 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 resolver selection 609 As in the above two problems, a policy-based approach and non policy- 610 based approach are possible. In a non policy-based approach, a host 611 or a home gateway router is assumed to send DNS queries to several 612 DNS servers at once or to select one of the available servers. 614 In the non policy-based approach, by making a query to a resolver in 615 a different service provider to that which hosts the service, a user 616 could be directed to unexpected IP address or receive an invalid 617 response, and thus cannot connect to the service provider's private 618 and legitimate service. For example, some DNS servers reply with 619 different answers depending on the source address of the DNS query, 620 which is sometimes called split-horizon. When the host mistakenly 621 makes a query to a different provider's DNS to resolve a FQDN of 622 another provider's private service, and the DNS resolver adopts the 623 split-horizon configuration, the queried server returns an IP address 624 of the non-private side of the service. Another problem with this 625 approach is that it causes unnecessary DNS traffic to the DNS 626 resolvers that are visible to the users. 628 The alternative of a policy-based approach is documented in 629 [I-D.savolainen-mif-dns-server-selection], where several pairs of DNS 630 resolver addresses and DNS domain suffixes are defined as part of a 631 policy and conveyed to hosts in a new DHCP option. In an environment 632 where there is a home gateway router, that router can act as a DNS 633 proxy, interpret this option and distribute DNS queries to the 634 appropriate DNS servers according to the policy. 636 7. Considerations for host without multi-prefix support 638 This section presents an alternative approach to mitigate the problem 639 in a multihomed network. This approach will help IPv6 hosts that are 640 not capable of the enhancements for the source address selection 641 policy, next-hop selection policy, and DNS selection policy described 642 in Section 6. 644 7.1. IPv6 NAT 646 In a typical IPv4 multihomed network deployment, IPv4 NAPT is 647 practically used and it can eventually avoid assigning multiple 648 addresses to the hosts and solve the next-hop selection problem. In 649 a similar fashion, IPv6 NAT can be used as a last resort for IPv6 650 multihomed network deployments where one needs to assign a single 651 IPv6 address to a host. 653 __________ 654 / \ 655 +---/ Internet \ 656 gateway router | \ / 657 +------+ +---------------------+ | \__________/ 658 | | | | | WAN1 +--+ 659 | host |-----|LAN| Router |--------| 660 | | | | |NAT|WAN2+--+ 661 +------+ +---------------------+ | __________ 662 | / \ 663 +---/ ASP \ 664 \ / 665 \__________/ 667 Figure 5: Legacy Host 669 The gateway router also has to support the two features, next-hop 670 selection and DNS server selection, shown in Section 6. 672 The implementation and issues of IPv6 NAT are out of the scope of 673 this document. They may be covered by another document under 674 discussion [I-D.mrw-nat66]. 676 7.2. Co-exisitence consideration 678 The above scenario relies on the assumption that only hosts without 679 multi-prefix support are connected to the GW rtr in scenario 2. To 680 allow the coexistence of non-MHMP hosts and MHMP hosts(i.e. hosts 681 supporting multi-prefix with the enhancements for the source address 682 selection), GW-rtr may need to treat those hosts separately. 684 An idea to achieve this is that GW-rtr identifies the hosts, and then 685 assigns single prefix to non-MHMP hosts and assigns multiple prefix 686 to MHMP hosts. In this case, GW-rtr can perform IPv6 NAT only for 687 the traffic from MHMP hosts if its source address is not appropriate. 689 Another idea is that GW-rtr assigns multiple prefix to the both 690 hosts, and it performs IPv6 NAT for the traffic from non-MHMP hosts 691 if its source address is not appropriate. 693 In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT 694 box. In this case, non-MHMP host can access the service through the 695 NAT box. 697 The implementation of identifying non-MHMP hosts and NAT policy is 698 outside the scope of this document. 700 8. Security Considerations 702 This document does not define any new mechanisms. Each solution 703 mechanisms should consider security risks independently. Security 704 risks that occur as a result of combining solution mechanisms should 705 be considered in another document. 707 9. IANA Considerations 709 This document has no IANA actions. 711 10. Contributors 713 The following people contributed to this document: Akiko Hattori, 714 Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, 715 Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, 716 Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki 718 11. References 720 11.1. Normative References 722 [I-D.dec-dhcpv6-route-option] 723 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 724 Route Option", draft-dec-dhcpv6-route-option-05 (work in 725 progress), September 2010. 727 [I-D.fujisaki-dhc-addr-select-opt] 728 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 729 Address Selection Policy using DHCPv6", 730 draft-fujisaki-dhc-addr-select-opt-09 (work in progress), 731 March 2010. 733 [I-D.ietf-6man-addr-select-sol] 734 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 735 approaches for address-selection problems", 736 draft-ietf-6man-addr-select-sol-03 (work in progress), 737 March 2010. 739 [I-D.mrw-nat66] 740 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address 741 Translation (NAT66)", draft-mrw-nat66-00 (work in 742 progress), October 2010. 744 [I-D.savolainen-mif-dns-server-selection] 745 Savolainen, T. and J. Kato, "Improved DNS Server Selection 746 for Multi-Homed Nodes", 747 draft-savolainen-mif-dns-server-selection-05 (work in 748 progress), November 2010. 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC3484] Draves, R., "Default Address Selection for Internet 754 Protocol version 6 (IPv6)", RFC 3484, February 2003. 756 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 757 More-Specific Routes", RFC 4191, November 2005. 759 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 760 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 761 September 2007. 763 11.2. Informative References 765 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 766 Address Translator (Traditional NAT)", RFC 3022, 767 January 2001. 769 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 770 Static Route Option for Dynamic Host Configuration 771 Protocol (DHCP) version 4", RFC 3442, December 2002. 773 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 774 Address Translator - Protocol Translator (NAT-PT) to 775 Historic Status", RFC 4966, July 2007. 777 [RFC5006] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 778 "IPv6 Router Advertisement Option for DNS Configuration", 779 RFC 5006, September 2007. 781 [TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol 782 v1.1, Version: Issue 1 Amendment 2", December 2007. 784 [TR124] The BroadBand Forum, "TR-124i2, Functional Requirements 785 for Broadband Residential Gateway Devices (work in 786 progress)", May 2010. 788 Authors' Addresses 790 Ole Troan (editor) 791 Cisco 792 Bergen 793 Norway 795 Email: ot@cisco.com 797 David Miles 798 Alcatel-Lucent 799 Melbourne 800 Australia 802 Email: david.miles@alcatel-lucent.com 804 Satoru Matsushima 805 SOFTBANK TELECOM Corp. 806 Tokyo 807 Japan 809 Email: satoru.matsushima@tm.softbank.co.jp 811 Tadahisa Okimoto 812 NTT West 813 Osaka 814 Japan 816 Email: t.okimoto@rdc.west.ntt.co.jp 817 Dan Wing 818 Cisco 819 170 West Tasman Drive 820 San Jose 821 USA 823 Email: dwing@cisco.com