idnits 2.17.1 draft-v6ops-multihoming-without-ipv6nat-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 (March 29, 2011) is 4776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-00 == Outdated reference: A later version (-05) exists of draft-ietf-mif-dhcpv6-route-option-01 == Outdated reference: A later version (-12) exists of draft-ietf-mif-dns-server-selection-01 == Outdated reference: A later version (-16) exists of draft-mrw-nat66-12 ** 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: September 30, 2011 Alcatel-Lucent 6 S. Matsushima 7 SOFTBANK TELECOM Corp. 8 T. Okimoto 9 NTT West 10 D. Wing 11 Cisco 12 March 29, 2011 14 IPv6 Multihoming without Network Address Translation 15 draft-v6ops-multihoming-without-ipv6nat-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 September 30, 2011. 48 Copyright Notice 49 Copyright (c) 2011 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. Problem Statement . . . . . . . . . . . . . . . . . . . . 8 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. End-to-End transparency . . . . . . . . . . . . . . . . . 9 72 4.2. Policy providing . . . . . . . . . . . . . . . . . . . . . 10 73 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Problem statement and analysis . . . . . . . . . . . . . . . . 10 75 5.1. Source address selection . . . . . . . . . . . . . . . . . 11 76 5.2. Next-hop selection . . . . . . . . . . . . . . . . . . . . 11 77 5.3. DNS server selection . . . . . . . . . . . . . . . . . . . 12 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. Though there are some 102 mechanisms to implement multihoming, such as BGP multihoming 103 [RFC4116] and SCTP based multihoming [RFC4960], there is no mechanism 104 in IPv6 that serves as a replacement for NAT based multihoming in 105 IPv4. In IPv4, for a host or a small network, NAT based multihoming 106 is easily deployable and already deployed technique. The same 107 situation that depends on NAT technique may be brought to the IPv6 108 world. 110 Whenever a host or small network (which does not meet minimum IPv6 111 allocation criteria) is connected to multiple upstream networks IPv6 112 address is assigned by each respective service provider resulting in 113 hosts with more than one active IPv6 addresses. As each service 114 provided is allocated a different address space from its Internet 115 Registry, it in-turn assigns a different address space to the end- 116 user network or host. For example, a remote access user's host or 117 router may use a VPN to simultaneously connect to a remote network 118 and retain a default route to the Internet for other purposes. 120 In IPv4 a common solution to the multihoming problem is to employ 121 NAPT on a border router and use private address space for individual 122 host addressing. The use of NAPT allows hosts to have exactly one IP 123 address visible on the public network and the combination of NAPT 124 with provider-specific outside addresses (one for each uplink) and 125 destination-based routing insulates a host from the impacts of 126 multiple upstream networks. The border router may also implement a 127 DNS cache or DNS policy to resolve address queries from hosts. 129 It is our goal to avoid the IPv6 equivalent of NAT. So, the goals 130 for IPv6 multihoming definced in [RFC3582] do not exactly match the 131 goals of us. Also regardless of what the IPv6 NAT's specification 132 is, we are trying to avoid any form of network address translation 133 technique that may not be visible for either of the end hosts. To 134 reach this goal, mechanisms are needed for end-user hosts to have 135 multiple address assignments and resolve issues such as which address 136 to use for sourcing traffic to which destination: 138 o If multiple routers exist on a single link the host must 139 appropriately select next-hop for each connected network. Each 140 router is in turn connected to a different service provider 141 network, which provides independent address assignment and DNS 142 resolvers. Routing protocols that would normally be employed for 143 router-to-router network advertisement seem inappropriate for use 144 by individual hosts. 146 o Source address selection also becomes difficult whenever a host 147 has more than one address within the same address scope. Current 148 address selection criteria may result in hosts using an arbitrary 149 or random address when sourcing upstream traffic. Unfortunately, 150 for the host, the appropriate source address is a function of the 151 upstream network for which the packet is bound for. If an 152 upstream service provider uses IP anti-spoofing or uRPF, it is 153 conceivable that the packets that have inappropriate source 154 address for the upstream network would never reach their 155 destination. 157 o In a multihomed environment, different DNS scopes or partitions 158 may exist in each independent upstream network. A DNS query sent 159 to an arbitrary upstream resolver may result in incorrect or 160 poisoned responses 162 In short, while IPv6 facilitates hosts having more than one address 163 in the same address scope, the application of this causes significant 164 issues for a host from routing, source address selection and DNS 165 resolution perspectives. A possible consequence of assigning a host 166 multiple identical-scoped addresses is severely impaired IP 167 connectivity. 169 If a host connects to a network behind an IPv4 NAPT, the host has one 170 private address in the local network. There is no confusion. The 171 NAT becomes the gateway of the host and forwards the packet to an 172 appropriate network when it is multihomed. It also operates a DNS 173 cache server, which receives all DNS inquires, and gives a correct 174 answer to the host. 176 In this document, we identify the functions present in multihomed 177 IPv4 NAPT environments and propose requirements that address 178 multihomed IPv6 environments without using IPv6 NAT. 180 2. Terminology 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 IPv6 NAT The terms "NAT66" and "IPv6 NAT" refer to 187 [I-D.mrw-nat66]. 189 NAPT Network Address Port Translation as described 190 in [RFC3022]. In other contexts, NAPT is often 191 pronounced "NAT" or written as "NAT". 193 Multihomed with multi-prefix (MHMP) A host implementation which 194 supports the mechanisms described in this 195 document. Namely source address selection 196 policy, next-hop selection and DNS selection 197 policy. 199 3. IPv6 multihomed network scenarios 201 In this section, we classify three scenarios of the multihoming 202 environment. 204 3.1. Classification of network scenarios for multihomed host 206 Scenario 1: 208 In this scenario, two or more routers are present on a single link 209 shared with the host(s). Each router is in turn connected to a 210 different service provider network, which provides independent 211 address assignment and DNS resolvers. A host in this environment 212 would be offered multiple prefixes and DNS resolvers advertised from 213 the two different routers. 215 +------+ ___________ 216 | | / \ 217 +---| rtr1 |=====/ network \ 218 | | | \ 1 / 219 +------+ | +------+ \___________/ 220 | | | 221 | host |-----+ 222 | | | 223 +------+ | +------+ ___________ 224 | | | / \ 225 +---| rtr2 |=====/ network \ 226 | | \ 2 / 227 +------+ \___________/ 229 Figure 1: single uplink, multiple next-hop, multiple prefix 230 (Scenario 1) 232 Figure 1 illustrates the host connecting to rtr1 and rtr2 via a 233 shared link. Networks 1 and 2 are reachable via rtr1 and rtr2 234 respectively. When the host sends packets to network 1, the next-hop 235 to network 1 is rtr1. Similarly, rtr2 is the next-hop to network 2. 237 - e.g., broadband service (Internet, VoIP, IPTV, etc.) 239 Scenario 2: 241 In this scenario, a single gateway router connects the host to two or 242 more upstream service provider networks. This gateway router would 243 receive prefix delegations from each independent service provider 244 network and a different set of DNS resolvers. The gateway in turn 245 advertises the provider prefixes to the host, and for DNS, may either 246 act as a lightweight DNS resolver/cache or may advertise the complete 247 set of service provider DNS resolvers to the hosts. 249 +------+ ___________ 250 | | / \ 251 +---| rtr1 |=====/ network \ 252 | | | \ 1 / 253 +------+ +-----+ | +------+ \___________/ 254 | | | | | 255 | host |-----| GW |---+ 256 | | | rtr | | 257 +------+ +-----+ | +------+ ___________ 258 | | | / \ 259 +---| rtr2 |=====/ network \ 260 | | \ 2 / 261 +------+ \___________/ 263 Figure 2: single uplink, single next-hop, multiple prefix 264 (Scenario 2) 266 Figure 2 illustrates the host connected to GW rtr. GW rtr connects 267 to networks 1 and 2 via rtr1 and rtr2, respectively. When the host 268 sends packets to either network 1 or 2, the next-hop is GW rtr. When 269 the packets are sent to network 1 (network 2), GW rtr forwards the 270 packets to rtr1 (rtr2). 272 - e.g, Internet + VPN/ASP 274 Scenario 3: 276 In this scenario, a host has more than one active interface that 277 connects to different routers and service provider networks. Each 278 router provides the host with a different address prefix and set of 279 DNS resolvers, resulting in a host with a unique address per link/ 280 interface. 282 +------+ +------+ ___________ 283 | | | | / \ 284 | |-----| rtr1 |=====/ network \ 285 | | | | \ 1 / 286 | | +------+ \___________/ 287 | | 288 | host | 289 | | 290 | | +------+ ___________ 291 | | | | / \ 292 | |=====| rtr2 |=====/ network \ 293 | | | | \ 2 / 294 +------+ +------+ \___________/ 296 Figure 3: Multiple uplink, multiple next-hop, multiple prefix 297 (Scenario 3) 299 Figure 3 illustrates the host connecting to rtr1 and rtr2 via a 300 direct connection or a virtual link. When the host sends packets 301 network 1, the next-hop to network 1 is rtr1. Similarly, rtr2 is the 302 next-hop to network 2. 304 - e.g., Mobile Wifi + 3G, ISP A + ISP B 306 3.2. Multihomed network environment 308 In an IPv6 multihomed network, a host is assigned two or more IPv6 309 addresses and DNS resolvers from independent service provider 310 networks. When this multihomed host attempts to connect with other 311 hosts, it may incorrectly resolve the next-hop router, use an 312 inappropriate source address, or use a DNS response from an incorrect 313 service provider that may result in impaired IP connectivity. 315 Multihomed networks in IPv4 have been commonly implemented through 316 the use of a gateway router with NAPT function (scenario 2 with 317 NAPT). An analysis of the current IPv4 NAPT and DNS functions within 318 the gateway router should provide a baseline set of requirements for 319 IPv6 multihomed environments. A destination prefix/route is often 320 used on the gateway router to separate traffic between the networks. 322 +------+ ___________ 323 | | / \ 324 +---| rtr1 |=====/ network \ 325 | | | \ 1 / 326 +------+ +-----+ | +------+ \___________/ 327 | IPv4 | | | | 328 | host |-----| GW |---+ 329 | | | rtr | | 330 +------+ +-----+ | +------+ ___________ 331 (NAPT&DNS) | | | / \ 332 (private +---| rtr2 |=====/ network \ 333 address | | \ 2 / 334 space) +------+ \___________/ 336 Figure 4: IPv4 Multihomed environment with Gateway Router performing 337 NAPT 339 3.3. Problem Statement 341 A multihomed IPv6 host has one or more assigned IPv6 addresses and 342 DNS resolvers from each upstream service provider, resulting in the 343 host having multiple valid IPv6 addresses and DNS resolvers. The 344 host must be able to resolve the appropriate next-hop, the correct 345 source address and DNS resolver to use based on the destination 346 prefix. To prevent IP spoofing, operators will often implement IP 347 filters and uRPF to discard traffic with an inappropriate source 348 address, making it essential for the host to correctly resolve these 349 three criteria before sourcing the first packet. 351 IPv6 has mechanisms for the provision of multiple routers on a single 352 link and multiple address assignments to a single host. However, 353 when these mechanisms are applied to the three scenarios in 354 Section 3.1 a number of connectivity issues are identified: 356 Scenario 1: 358 The host has been assigned an address from each router and recognizes 359 both rtr1 and rtr2 as valid default routers (in the default routers 360 list). 362 o The source address selection policy on the host does not 363 deterministically resolve a source address. Upstream uRPF or 364 filter policies will discard traffic with source addresses that 365 the operator did not assign. 367 o The host will select one of the two routers as the active default 368 router. No traffic is sent to the other router. 370 Scenario 2: 372 The host has been assigned two different addresses from the single 373 gateway router. The gateway router is the only default router on the 374 link. 376 o The source address selection policy on the host does not 377 deterministically resolve a source address. Upstream uRPF or 378 filter policies will discard traffic with source addresses that 379 the operator did not assign. 381 o The gateway router does not have a mechanism for determining which 382 traffic should be sent to which network. If the gateway router is 383 implementing host functions (ie, processing RA) then two valid 384 default routers may be recognized. 386 Scenario 3: 388 A host has two separate interfaces and on each interface a different 389 address is assigned. Each link has its own router. 391 o The host does not have enough information for determining which 392 traffic should be sent to which upstream routers. The host will 393 select one of the two routers as the active default router, and no 394 traffic is sent to the other router. 396 o The default address selection rules select the address assigned to 397 the outgoing interface as the source address. So, if a host has 398 an appropriate routing table, an appropriate source address will 399 be selected. 401 All scenarios: 403 o The host may use an incorrect DNS resolver for DNS queries. 405 4. Requirements 407 This section describes requirements that any solution multi-address 408 and multi-uplink architectures need to meet. 410 4.1. End-to-End transparency 412 End-to-end transparency is a basic concept of the Internet. 413 [RFC4966] states, "One of the major design goals for IPv6 is to 414 restore the end-to-end transparency of the Internet. Therefore, 415 because IPv6 is expected to remove the need for NATs and similar 416 impediments to transparency, developers creating applications to work 417 with IPv6 may be tempted to assume that the complex mechanisms 418 employed by an application to work in a 'NATted' IPv4 environment are 419 not required." The IPv6 multihoming solution SHOULD guarantee end- 420 to-end transparency by avoiding IPv6 NAT. 422 4.2. Policy providing 424 The solution SHOULD have a function to provide a policy on sites/ 425 nodes. In particular, in a managed environment such as enterprise 426 networks, an administrator has to control all nodes in his or her 427 network. 429 The providing mechanisms should have: 431 o a function to distribute policies to nodes dynamically to update 432 their behavior. When the network environment changes and the 433 nodes' behavior has to be changed, a network administrator can 434 modify the behavior of the nodes. 436 o a function to control every node centrally. A site administrator 437 or a service provider could determine or could have an effect on 438 the behavior at their users' hosts. 440 o a function to control node-specific behavior. Even when multiple 441 nodes are on the same subnet, the mechanism should be able to 442 provide a method for the network administrator to make nodes 443 behave differently. For example, each node may have a different 444 set of assigned prefixes. In such a case, the appropriate 445 behavior may be different. 447 4.3. Scalability 449 The solution will have to be able to manage a large number of sites/ 450 nodes. In services for residential users, provider edge devices have 451 to manage thousands of sites. In such environments, sending packets 452 periodically to each site may affect edge system performance. 454 5. Problem statement and analysis 456 The problems described in Section 3 can be classified into these 457 three types: 459 o Wrong source address selection 461 o Wrong next-hop selection 462 o Wrong DNS server selection 464 This section reviews the problem statements presented above and the 465 proposed functional requirements to resolve the issues. 467 5.1. Source address selection 469 A multihomed IPv6 host will typically have different addresses 470 assigned from each service provider either on the same link 471 (scenarios 1 & 2) or different links (scenario 3). When the host 472 wishes to send a packet to any given destination, the current source 473 address selection rules [RFC3484] may not deterministically resolve 474 the correct source address when the host addressing was via RA or 475 DHCPv6. [I-D.ietf-6man-addr-select-sol] describes the use of the 476 policy table [RFC3484] to resolve this problem, but there is no 477 mechanism defined to disseminate the policy table information to a 478 host. A proposal is in [I-D.ietf-6man-addr-select-opt] to provide a 479 DHCPv6 mechanism for host policy table management. 481 Again, by employing DHCPv6, the server could restrict address 482 assignment (of additional prefixes) only to hosts that support policy 483 table management. 485 Scenario 1: "Host" needs to support the solution for this problem 487 Scenario 2: "Host" needs to support the solution for this problem 489 Scenario 3: If "Host" support the next-hop selection solution, there 490 is no need to support the address selection functionality on the 491 host. 493 5.2. Next-hop selection 495 A multihomed IPv6 host or gateway may have multiple uplinks to 496 different service providers. Here each router would use Router 497 Advertisements [RFC4861] for distributing default route/next-hop 498 information to the host or gateway router. 500 In this case, the host or gateway router may select any valid default 501 router from the default routers list, resulting in traffic being sent 502 to the wrong router and discarded by the upstream service provider. 503 Using the above scenarios as an example, whenever the host wishes to 504 reach a destination in network 2 and there is no connectivity between 505 networks 1 and 2 (as is the case for a walled-garden or closed 506 service), the host or gateway router does not know whether to forward 507 traffic to rtr1 or rtr2 to reach a destination in network 2. The 508 host or gateway router may choose rtr1 as the default router, and 509 traffic fails to reach the destination server. The host or gateway 510 router requires route information for each upstream service provider, 511 but the use of a routing protocol between a host and router causes 512 both configuration and scaling issues. For IPv4 hosts, the gateway 513 router is often pre-configured with static route information or uses 514 of Classless Static Route Options [RFC3442] for DHCPv4. Extensions 515 to Router Advertisements through Default Router Preference and More- 516 Specific Routes [RFC4191] provides for link-specific preferences but 517 does not address per-host configuration in a multi-access topology 518 because of its reliance on Router Advertisements. A DHCPv6 option, 519 such as that in [I-D.ietf-mif-dhcpv6-route-option], is preferred for 520 host-specific configuration. By employing a DHCPv6 solution, a 521 DHCPv6 server could restrict address assignment (of additional 522 prefixes) only to hosts that support more advanced next-hop and 523 address selection requirements. 525 Scenario 1: "Host" needs to support the solution for this problem 527 Scenario 2: "GW rtr" needs to support the solution for this problem 529 Scenario 3: "Host" needs to support the solution for this problem 531 5.3. DNS server selection 533 A multihomed IPv6 host or gateway router may be provided multiple DNS 534 resolvers through DHCPv6 or RA [RFC6106]. When the host or gateway 535 router sends a DNS query, it would normally choose one of the 536 available DNS resolvers for the query. 538 In the IPv6 gateway router scenario, the Broadband Forum [TR124] 539 required that the query be sent to all DNS resolvers, and the gateway 540 waits for the first reply. In IPv6, given our use of specific 541 destination-based policy for both routing and source address 542 selection, it is desirable to extend a policy-based concept to DNS 543 resolver selection. Doing so can minimize DNS resolver load and 544 avoid issues where DNS resolvers in different networks have 545 connectivity issues, or the DNS resolvers are not publicly 546 accessible. In the worst case, a DNS query may be unanswered if sent 547 towards an incorrect resolver, resulting in a lack of connectivity. 549 An IPv6 multihomed host or gateway router should have the ability to 550 select appropriate DNS resolvers for each service based on the domain 551 space for the destination, and each service should provide rules 552 specific to that network. [I-D.ietf-mif-dns-server-selection] 553 proposes a solution for DNS server selection policy providing 554 solution with a DHCPv6 option. 556 Scenario 1: "Host" needs to support the solution for this problem 557 Scenario 2: "GW rtr" needs to support the solution for this problem 559 Scenario 3: "Host" needs to support the solution for this problem 561 6. Implementation approach 563 As mentioned in Section 5, in the multi-prefix environment, we have 564 three problems in source address selection, next-hop selection, and 565 DNS resolver selection. In this section, possible solution 566 mechanisms for each problem are introduced and evaluated against the 567 requirements in Section 4. 569 6.1. Source address selection 571 Possible solutions and their evaluation are summarized in 572 [I-D.ietf-6man-addr-select-sol]. When those solutions are examined 573 against the requirements in Section 4, the proactive approaches, such 574 as the policy table distribution mechanism and the routing system 575 assistance mechanism, are more appropriate in that they can propagate 576 the network administrator's policy directly. The policy distribution 577 mechanism has an advantage with regard to the host's protocol stack 578 impact and the staticness of the assumed target network environment. 580 6.2. Next-hop selection 582 As for the source address selection problem, both a policy-based 583 approach and a non policy-based approach are possible with regard to 584 the next-hop selection problem. Because of the same requirements, 585 the policy propagation-based solution mechanism, whatever the policy, 586 should be more appropriate. 588 Routing information is a typical example of policy related to next- 589 hop selection. If we assume source address-based routing at hosts or 590 intermediate routers, the pairs of source prefixes and next-hops can 591 be another example of next-hop selection policy. 593 The routing information-based approach has a clear advantage in 594 implementation and is already commonly used. 596 The existing proposed or standardized routing information 597 distribution mechanisms are routing protocols, such as RIPng and 598 OSPFv3, the router advertisement (RA) extension option defined in 599 [RFC4191], the DHCPv6 route information option proposed in 600 [I-D.ietf-mif-dhcpv6-route-option], and the [TR069] standardized at 601 BBF. 603 The RA-based mechanism has difficulty in per-host routing information 604 distribution. The dynamic routing protocols such as RIPng are not 605 usually used between the residential users and ISP networks because 606 of their scalability implications. The DHCPv6 mechanism does not 607 have these difficulties and has the advantages of its relaying 608 functionality. It is commonly used and is thus easy to deploy. 610 [TR069], mentioned above, is a possible solution mechanism for 611 routing information distribution to customer-premises equipment 612 (CPE). It assumes, however, IP reachability to the Auto 613 Configuration Server (ACS) is established. Therefore, if the CPE 614 requires routing information to reach the ACS, [TR069] cannot be used 615 to distribute this information. 617 6.3. DNS resolver selection 619 As in the above two problems, a policy-based approach and non policy- 620 based approach are possible. In a non policy-based approach, a host 621 or a home gateway router is assumed to send DNS queries to several 622 DNS servers at once or to select one of the available servers. 624 In the non policy-based approach, by making a query to a resolver in 625 a different service provider to that which hosts the service, a user 626 could be directed to unexpected IP address or receive an invalid 627 response, and thus cannot connect to the service provider's private 628 and legitimate service. For example, some DNS servers reply with 629 different answers depending on the source address of the DNS query, 630 which is sometimes called split-horizon. When the host mistakenly 631 makes a query to a different provider's DNS to resolve a FQDN of 632 another provider's private service, and the DNS resolver adopts the 633 split-horizon configuration, the queried server returns an IP address 634 of the non-private side of the service. Another problem with this 635 approach is that it causes unnecessary DNS traffic to the DNS 636 resolvers that are visible to the users. 638 The alternative of a policy-based approach is documented in 639 [I-D.ietf-mif-dns-server-selection],where several pairs of DNS 640 resolver addresses and DNS domain suffixes are defined as part of a 641 policy and conveyed to hosts in a new DHCP option. In an environment 642 where there is a home gateway router, that router can act as a DNS 643 proxy, interpret this option and distribute DNS queries to the 644 appropriate DNS servers according to the policy. 646 7. Considerations for host without multi-prefix support 648 This section presents an alternative approach to mitigate the problem 649 in a multihomed network. This approach will help IPv6 hosts that are 650 not capable of the enhancements for the source address selection 651 policy, next-hop selection policy, and DNS selection policy described 652 in Section 6. 654 7.1. IPv6 NAT 656 In a typical IPv4 multihomed network deployment, IPv4 NAPT is 657 practically used and it can eventually avoid assigning multiple 658 addresses to the hosts and solve the next-hop selection problem. In 659 a similar fashion, IPv6 NAT can be used as a last resort for IPv6 660 multihomed network deployments where one needs to assign a single 661 IPv6 address to a host. 663 __________ 664 / \ 665 +---/ Internet \ 666 gateway router | \ / 667 +------+ +---------------------+ | \__________/ 668 | | | | | WAN1 +--+ 669 | host |-----|LAN| Router |--------| 670 | | | | |NAT|WAN2+--+ 671 +------+ +---------------------+ | __________ 672 | / \ 673 +---/ ASP \ 674 \ / 675 \__________/ 677 Figure 5: Legacy Host 679 The gateway router also has to support the two features, next-hop 680 selection and DNS server selection, shown in Section 6. 682 The implementation and issues of IPv6 NAT are out of the scope of 683 this document. They may be covered by another document under 684 discussion [I-D.mrw-nat66]. 686 7.2. Co-exisitence consideration 688 To allow the coexistence of non-MHMP hosts and MHMP hosts (i.e. hosts 689 supporting multi-prefix with the enhancements for the source address 690 selection), GW-rtr may need to treat those hosts separately. 692 An idea to achieve this is that GW-rtr identifies the hosts, and then 693 assigns single prefix to non-MHMP hosts and assigns multiple prefix 694 to MHMP hosts. In this case, GW-rtr can perform IPv6 NAT only for 695 the traffic from MHMP hosts if its source address is not appropriate. 697 Another idea is that GW-rtr assigns multiple prefix to the both 698 hosts, and it performs IPv6 NAT for the traffic from non-MHMP hosts 699 if its source address is not appropriate. 701 In scenario 1 and 3, the non-MHMP hosts can be placed behind the NAT 702 box. In this case, non-MHMP host can access the service through the 703 NAT box. 705 The implementation of identifying non-MHMP hosts and NAT policy is 706 outside the scope of this document. 708 8. Security Considerations 710 This document requires that the solutions for MHMP should have a 711 policy providing function. So, new security risks can be introduced 712 depending on what kind and what form of the policy. The threats can 713 be categorized in two parts: the policy receiver side and the policy 714 distributer side. A policy receiver may receive an evil policy from 715 a policy distributor. A policy distributor should expect some hosts 716 in his network do not follow the distributed policy. The security 717 threats related to IPv6 multihoming are described in [RFC4218]. 719 9. IANA Considerations 721 This document has no IANA actions. 723 10. Contributors 725 The following people contributed to this document: Akiko Hattori, 726 Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, 727 Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, 728 Wojciech Dec, Yasuo Kashimura, Yuji Yamazaki. This document has 729 greatly benefited from inputs by Randy Bush, Brian Carpenter, and 730 Teemu Savolainen. 732 11. References 734 11.1. Normative References 736 [I-D.ietf-6man-addr-select-opt] 737 Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing 738 Address Selection Policy using DHCPv6", 739 draft-ietf-6man-addr-select-opt-00 (work in progress), 740 December 2010. 742 [I-D.ietf-6man-addr-select-sol] 743 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 744 approaches for address-selection problems", 745 draft-ietf-6man-addr-select-sol-03 (work in progress), 746 March 2010. 748 [I-D.ietf-mif-dhcpv6-route-option] 749 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 750 Route Option", draft-ietf-mif-dhcpv6-route-option-01 (work 751 in progress), March 2011. 753 [I-D.ietf-mif-dns-server-selection] 754 Savolainen, T. and J. Kato, "Improved DNS Server Selection 755 for Multi-Homed Nodes", 756 draft-ietf-mif-dns-server-selection-01 (work in progress), 757 March 2011. 759 [I-D.mrw-nat66] 760 Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 761 Translation", draft-mrw-nat66-12 (work in progress), 762 March 2011. 764 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 765 Requirement Levels", BCP 14, RFC 2119, March 1997. 767 [RFC3484] Draves, R., "Default Address Selection for Internet 768 Protocol version 6 (IPv6)", RFC 3484, February 2003. 770 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 771 More-Specific Routes", RFC 4191, November 2005. 773 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 774 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 775 September 2007. 777 11.2. Informative References 779 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 780 Address Translator (Traditional NAT)", RFC 3022, 781 January 2001. 783 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 784 Static Route Option for Dynamic Host Configuration 785 Protocol (DHCP) version 4", RFC 3442, December 2002. 787 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 788 Multihoming Architectures", RFC 3582, August 2003. 790 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 791 Gill, "IPv4 Multihoming Practices and Limitations", 792 RFC 4116, July 2005. 794 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 795 Multihoming Solutions", RFC 4218, October 2005. 797 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 798 RFC 4960, September 2007. 800 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 801 Address Translator - Protocol Translator (NAT-PT) to 802 Historic Status", RFC 4966, July 2007. 804 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 805 "IPv6 Router Advertisement Options for DNS Configuration", 806 RFC 6106, November 2010. 808 [TR069] The BroadBand Forum, "TR-069, CPE WAN Management Protocol 809 v1.1, Version: Issue 1 Amendment 2", December 2007. 811 [TR124] The BroadBand Forum, "TR-124i2, Functional Requirements 812 for Broadband Residential Gateway Devices (work in 813 progress)", May 2010. 815 Authors' Addresses 817 Ole Troan (editor) 818 Cisco 819 Bergen 820 Norway 822 Email: ot@cisco.com 824 David Miles 825 Alcatel-Lucent 826 Melbourne 827 Australia 829 Email: david.miles@alcatel-lucent.com 830 Satoru Matsushima 831 SOFTBANK TELECOM Corp. 832 Tokyo 833 Japan 835 Email: satoru.matsushima@tm.softbank.co.jp 837 Tadahisa Okimoto 838 NTT West 839 Osaka 840 Japan 842 Email: t.okimoto@rdc.west.ntt.co.jp 844 Dan Wing 845 Cisco 846 170 West Tasman Drive 847 San Jose 848 USA 850 Email: dwing@cisco.com