idnits 2.17.1 draft-ietf-v6ops-unman-scenarios-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 578 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 43 instances of lines with control characters in the document. ** The abstract seems to contain references ([DNSOPV6], [RFC2766], [Bradner,1996], [EVAL], [6TO4], [RFC2608]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '6TO4' is mentioned on line 642, but not defined == Missing Reference: 'Bradner' is mentioned on line 816, but not defined -- Looks like a reference, but probably isn't: '1996' on line 816 == Unused Reference: 'RFC791' is defined on line 851, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC2462' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'RFC3022' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC2993' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC3041' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'DNSINADDR' is defined on line 904, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- Duplicate reference: RFC2993, mentioned in 'RFC2993', was also mentioned in 'RFC2608'. -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 10 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 October 16, 2003 R. Austein 4 Expires April 16, 2004 Bourgeois Dilettant 5 S. Satapati 6 Cisco Systems, Inc. 7 R. van der Pol 8 NLnet Labs 10 Unmanaged Networks IPv6 Transition Scenarios 12 Status of this memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 In order to evaluate the suitability of IPv6 transition mechanisms, 36 we need to define the scenarios in which these mechanisms have to be 37 used. One specific scope is the "unmanaged network", which typically 38 corresponds to a home or small office network. The scenarios are 39 specific to single subnet, and are defined in terms of IP 40 connectivity supported by the gateway and the ISP. We first examine 41 the generic requirements of four classes of applications: local, 42 client, peer to peer and server. Then, for each scenario, we infer 43 transition requirements by analyzing the needs for smooth migration 44 of applications from IPv4 to IPv6. 46 1 Introduction 48 In order to evaluate the suitability of transition mechanisms, we 49 need to define the environment or scope in which these mechanisms 50 have to be used. One specific scope is the "unmanaged networks", 51 which typically correspond to home networks or small office 52 networks. 54 This document studies the requirement posed by various transition 56 Huitema et al. [Page 1] 57 scenarios, and is organized in four main sections. Section 2 defines 58 the topology that we are considering. Section 3 presents the four 59 classes of applications that we consider for unmanaged networks: 60 local applications, client applications, peer-to-peer applications, 61 and server applications. Section 4 studies the requirements of these 62 four classes of applications. Section 5 analyses how these 63 requirements translate into four configurations which we expect to 64 encounter during IPv6 deployment: gateways which do not provide 65 IPv6, dual-stack gateways connected to dual-stack ISPs, dual-stack 66 gateways connected to IPv4-only ISPs, and IPv6-capable gateways 67 connected to IPv6-only ISPs. While these four configurations are 68 certainly not an exhaustive list of possible configurations, we 69 believe that they represent the common cases for unmanaged networks. 71 2 Topology 73 The typical unmanaged network is composed of a single subnet, 74 connected to the Internet through a single Internet Service Provider 75 (ISP) connection. Several hosts may be connected to the subnet: 77 +------+ 78 | Host +--+ 79 +------+ | 80 | 81 +------+ | 82 | Host +--+ +-------------- 83 +------+ | | 84 : +-----+ 85 : +---------+ | | 86 +--+ Gateway +------| ISP | Internet 87 : +---------+ | | 88 : +-----+ 89 +------+ | | 90 | Host +--+ +-------------- 91 +------+ | 92 | 93 +------+ | 94 | Host +--+ 95 +------+ 97 Between the subnet and the ISP access link is a gateway, which may 98 or may not perform NAT and firewall functions. A key point of this 99 configuration is that the gateway is typically not "managed". In 100 most cases, it is a simple "appliance", which incorporates some 101 static policies. However, there are many cases in which the gateway 102 is procured and configured by the ISP, and there are also some 103 common cases in which we find two gateways back to back, one managed 104 by the ISP and the other added by the owner of the unmanaged 105 network. 107 The access link between the unmanaged network and the ISP might be 108 either a static, permanent connection or a dynamic connection such 110 Huitema et al. [Page 2] 111 as a dial-up or ISDN line. 113 In a degenerate case, an unmanaged network might consist of a single 114 host, directly connected to an ISP. 116 There are some cases in which the "gateway" is replaced by a layer-2 117 bridge. In such deployments, the hosts have direct access to the ISP 118 service. In order to avoid lengthy developments, we will treat these 119 cases as if the gateway was not present, i.e. as if each host was 120 connected directly to the ISP. 122 Our definition of unmanaged networks explicitly exclude networks 123 composed of multiple subnets. We will readily admit that some home 124 networks and some small business networks contain multiple subnets, 125 but in the current state of the technology these multiple subnet 126 networks are not "unmanaged": some competent administrator has to 127 explicitly configure the routers. We will thus concentrate on single 128 subnet networks, where no such competent operator is expected. 130 3 Applications 132 Users may use or wish to use the unmanaged network services in four 133 types of applications: local, client, servers and peer-to-peers. 134 These applications may or may not run easily on today's networks 135 (some do, some don't). 137 3.1 Local applications 139 "Local applications" are only meant to involve the hosts that are 140 part of the unmanaged network. Typical examples would be file 141 sharing or printer sharing. 143 Local applications work effectively in IPv4 unmanaged networks, even 144 when the gateway performs NAT or firewall function. In fact, 145 firewall services at the gateway are often deemed desirable, as they 146 isolate the local applications from interference by Internet users. 148 3.2 Client applications 150 "Client applications" are those that involve a client on the 151 unmanaged network and a server at a remote location. Typical 152 examples would be accessing a web server from a client inside the 153 unmanaged network, or reading and sending e-mail with the help of a 154 server outside the unmanaged network. 156 Client applications tend to work correctly in IPv4 unmanaged 157 networks, even when the gateway performs NAT or firewall function: 158 these translation and firewall functions are designed precisely to 159 enable client applications. 161 3.3 Peer-to-peer applications 163 Huitema et al. [Page 3] 164 There are really two kinds of "peer-to-peer" applications: ones 165 which only involve hosts on the unmanaged network, and ones which 166 involve both one or more hosts on the unmanaged network and one or 167 more hosts outside the unmanaged network. We will only consider the 168 latter kind of peer-to-peer applications, since the former can be 169 considered a subset of the kind of local applications discussed 170 in section 3.1. 172 Peer-to-peer applications often don't work well in unmanaged IPv4 173 networks. Application developers often have to enlist the help of a 174 "relay server", in effect restructuring the peer-to-peer connection 175 into a pair of back-to-back client/server connections. 177 3.4 Server applications 179 "Server applications" involve running a server in the unmanaged 180 network for use by other parties outside the network. Typical 181 examples would be running a web server or an e-mail server on one of 182 the hosts inside the unmanaged network. 184 Deploying these servers in most unmanaged IPv4 networks requires 185 some special programming of the NAT or firewall, and is more complex 186 when the NAT only publishes a small number of global IP addresses 187 and relies on "port translation". In the common case in which the 188 NAT manages exactly one global IP address and relies on "port 189 translation", a given external port can only be used by one internal 190 server. 192 Deploying servers usually requires providing each server with a 193 stable DNS name, and associating a global IPv4 address with that 194 name, whether the address be that of the server itself or that of 195 the router acting as a firewall or NAT. Since updating DNS is a 196 management task, it falls somewhat outside the scope of an unmanaged 197 network. On the other hand, it is also possible to use out-of-band 198 techniques (such as cut-and-paste into an instant message system) to 199 pass around the address of the target server. 201 4 Application requirements of an IPv6 unmanaged network 203 As we transition to IPv6, we must meet the requirements of the 204 various applications, which we can summarize in the following way: 205 applications that used to work well with IPv4 should continue 206 working well during the transition; it should be possible to use 207 IPv6 to deploy new applications that are currently hard to deploy in 208 IPv4 networks; and the deployment of these IPv6 applications should 209 be simple and easy to manage, but the solutions should also be 210 robust and secure. 212 The application requirements for IPv6 Unmanaged Networks fall into 213 three general categories: connectivity, naming, and security. 214 Connectivity issues include the provision of IPv6 addresses and 215 their quality: do hosts need global addresses, should these 217 Huitema et al. [Page 4] 218 addresses be stable or, more precisely, what should the expected 219 lifetimes of these addresses be? Naming issues include the 220 management of names for the hosts: do hosts need DNS names, and is 221 inverse name resolution a requirement? Security issues include 222 possible restriction to connectivity, privacy concerns and, 223 generally speaking, the security of the applications. 225 4.1 Requirements of local applications 227 Local applications require local connectivity. They must continue to 228 work even if the unmanaged network is isolated from the Internet. 230 Local applications typically use ad hoc naming systems. Many of 231 these systems are proprietary; an example of a standard system is 232 the service location protocol (SLP) [RFC2608]. 234 The security of local applications will usually be enhanced if these 235 applications can be effectively isolated from the global Internet. 237 4.2 Requirements of client applications 239 Client applications require global connectivity. In an IPv6 network, 240 we would expect the client to use a global IPv6 address, which will 241 have to remain stable for the duration of the client-server session. 243 Client applications typically use the domain name system to locate 244 servers. In an IPv6 network, the client must be able to locate a DNS 245 resolver. 247 Many servers try to look up a DNS name associated to the IP address 248 of the client. In an IPv4 network, this IP address will often be 249 allocated by the Internet service provider to the gateway, and the 250 corresponding PTR record will be maintained by the ISP. In many 251 cases, these PTR records are perfunctory, derived in an algorithmic 252 fashion from the IPv4 address; the main information that they 253 contain is the domain name of the ISP. Whether or not an equivalent 254 function should be provided in an IPv6 network is unclear. 256 4.2.1 Privacy requirement of client applications 258 It is debatable whether the IPv6 networking service should be 259 engineered to enhance the privacy of the clients, and specifically 260 whether support for RFC 3041 should be required. RFC 3041 enables 261 hosts to pick IPv6 addresses in which the host identifier is 262 randomized; this was designed to make sure that the IPv6 addresses 263 and the host identifier cannot be used to track the Internet 264 connections of a device's owner. 266 Many observe that randomizing the host identifier portion of the 267 address is only a half measure. If the unmanaged network address 268 prefix remains constant, the randomization only hides which host in 269 the unmanaged network originates a given connection, e.g. the 271 Huitema et al. [Page 5] 272 children's computer versus their parents'. This would place the 273 privacy rating of such connections on a par with that of IPv4 274 connections originating from an unmanaged network in which a NAT 275 manages a static IPv4 address; in both cases, the IPv4 address or 276 the IPv6 prefix can be used to identify the unmanaged network, e.g. 277 the specific home from which the connection originated. 279 However, randomization of the host identifier does provide benefits. 280 First, if some of the hosts in the unmanaged network are mobile, the 281 randomization destroys any correlation between the addresses used at 282 various locations: the addresses alone could not be used to 283 determine whether a given connection originates from the same laptop 284 moving from work to home, or used on the road. Second, the 285 randomization removes any information that could be extracted from a 286 hardwired host identifier; for example, it will prevent outsiders 287 from correlating a serial number with a specific brand of expensive 288 electronic equipment, and to use this information for planning 289 marketing campaigns or possibly burglary attempts. 291 Randomization of the addresses is not sufficient to guarantee 292 privacy. Usage can be tracked by a variety of other means, from 293 application level "cookies" to complex techniques involving data 294 mining and traffic analysis. However, we should not make a bad 295 situation worse. Other attacks to privacy may be possible, but this 296 is not a reason to enable additional tracking through IPv6 297 addresses. 299 Randomization of the host identifier has some cost: the address 300 management in hosts is more complex for the hosts, reverse DNS 301 services are harder to provide, and the gateway may have to maintain 302 a larger cache of neighbor addresses; however, experience from 303 existing implementation shows that these costs are not overwhelming. 304 Given the limited benefits, it would be unreasonable to require that 305 all hosts use privacy addresses; however, given the limited costs, 306 it is reasonable to require that all unmanaged networks allow use of 307 privacy addresses by those hosts that choose to do so. 309 4.3 Requirements of peer-to-peer applications 311 Peer-to-peer applications require global connectivity. In an IPv6 312 network, we would expect the peers to use a global IPv6 address, 313 which will have to remain stable for the duration of the peer-to- 314 peer session. 316 There are multiple aspects to the security of peer-to-peer 317 applications, many of which relate to the security of the rendezvous 318 system. If we assume that the peers have been able to safely 319 exchange their IPv6 addresses, the main security requirement is the 320 capability to safely exchange data between the peers, without 321 interference by third parties. 323 Private conversations by one of the authors with developers of peer- 325 Huitema et al. [Page 6] 326 to-peer applications suggest that many would be willing to consider 327 an "IPv6-only" model if they can get two guarantees: 329 1) That there is no regression from IPv4, i.e. that all customers 330 who could participate in a peer-to-peer application using IPv4 can 331 also be reached by IPv6. 333 2) That IPv6 provides a solution for at least some of their hard 334 problems, e.g. enabling peers located behind an IPv4 NAT to 335 participate in a peer-to-peer application. 337 Requiring IPv6 connectivity for a popular peer-to-peer application 338 could create what economists refer to as a "network effect", which 339 in turn could significantly speed up the deployment of IPv6. 341 4.4 Requirements of server applications 343 Server applications require global connectivity, which in an IPv6 344 network implies global addresses. In an IPv4 network utilizing a 345 NAT, for each service provided by a server, the NAT has to be 346 configured to forward packets sent to that service to the server 347 that offers the service. 349 Server applications normally rely on the publication of the server's 350 address in the DNS. This, in turn, requires that the server be 351 provisioned with a "global DNS name". 353 The DNS entries for the server will have to be updated, preferably 354 in real time, if the server's address changes. In practice, updating 355 the DNS can be slow, which implies that server applications will 356 have a better chance of being deployed if the IPv6 addresses remain 357 stable for a long period. 359 The security of server applications depends mostly on the 360 correctness of the server, and also on the absence of collateral 361 effects: many incidents occur when the opening of a server on the 362 Internet inadvertently enables remote access to some other services 363 on the same host. 365 5 Stages of IPv6 deployment 367 We expect the deployment of IPv6 to proceed from an initial state in 368 which there is little or no deployment to a final stage in which we 369 might retire the IPv4 infrastructure. We expect this process to 370 stretch over many years; we also expect it to not be synchronized, 371 as different parties involved will deploy IPv6 at different paces. 373 In order to get some clarity, we distinguish three entities involved 374 in the transition of an unmanaged network: the ISP (possibly 375 including ISP consumer premise equipment (CPE)), the home gateway, 376 and the hosts (computers and appliances). Each can support IPv4- 377 only, both IPv4 and IPv6 or IPv6-only. That gives us 27 379 Huitema et al. [Page 7] 380 possibilities. We describe the most important cases. We will assume 381 that in all cases the hosts are a combination of IPv4-only, dual 382 stack and (perhaps) IPv6-only hosts. 384 The cases we will consider are: 386 A) a gateway which does not provide IPv6 at all; 387 B) a dual-stack gateway connected to a dual stack ISP; 388 C) a dual stack gateway connected to an IPV4-only ISP; and 389 D) a gateway connected to an IPv6-only ISP 391 In most of these cases we will assume that the gateway includes a 392 NAT: we realize that this is not always the case, but we submit that 393 it is common enough that we have to deal with it; furthermore, we 394 believe that the non-NAT variants of these cases map fairly closely 395 to this same set of cases. In fact, we can consider three non-NAT 396 variants: directly connected host; gateway acting as a bridge; and 397 gateway acting as a non-NAT IP router. 399 The cases of directly connected hosts are in effect variants of 400 cases B, C and D, in which the host can use all solutions available 401 to gateways: case B if the ISP is dual stack, case C if the ISP only 402 provides IPv4 connectivity, and case D if the ISP only provides IPv6 403 connectivity. 405 In the cases where the gateway is a bridge, the hosts are in effect 406 directly connected to the ISP, and for all practical matter behave 407 as directly connected hosts. 409 The case where the gateway is an IP router but not a NAT will be 410 treated as small variants in the analysis of case A, B, C and D. 412 5.1 Case A, host deployment of IPv6 applications 414 In this case the gateway doesn't provide IPv6; the ISP may or may 415 not provide IPv6, but this is not relevant, since the non-upgraded 416 gateway would prevent the hosts from using the ISP service. Some 417 hosts will try to get IPv6 connectivity, in order to run 418 applications that require IPv6, or work better with IPv6. The hosts 419 in this case will have to handle the IPv6 transition mechanisms on 420 their own. 422 There are two variations of this case, depending on the type of 423 service implemented by the gateway. In many cases, the gateway is a 424 direct obstacle to the deployment of IPv6, but a gateway which is 425 some form of bridge-mode CPE or which is a plain (neither 426 filtering nor NAT) router does not really fall into this category. 428 5.1.1 Application support in Case A 430 The focus of Case A is to enable communication between a host on the 431 unmanaged network and some IPv6-only hosts outside of the network. 433 Huitema et al. [Page 8] 434 The primary focus in the immediate future, i.e. for the early 435 adopters of IPv6, will be peer-to-peer applications. However, as 436 IPv6 deployment progresses, we will likely find a situation where 437 some networks have IPv6-only services deployed, at which point we 438 would like case A client applications to be able to access those 439 services. 441 Local applications are not a primary focus of Case A. At this stage, 442 we expect all clients in the unmanaged network to have either IPv4 443 only or dual stack support. Local applications can continue working 444 using IPv4. 446 Server applications are also not a primary focus of Case A. Server 447 applications require DNS support, which is difficult to engineer for 448 clients located behind a NAT, which is likely to be present in this 449 case. Besides, server applications at present cater mostly to IPv4 450 clients; putting up an IPv6-only server is not very attractive. 452 In contrast, peer-to-peer applications are probably both attractive 453 and easy to deploy: they are deployed in a coordinated fashion as 454 part of a peer-to-peer network, which means that hosts can all 455 receive some form of IPv6 upgrade; they often provide their own 456 naming infrastructure, in which case they are not dependent on DNS 457 services. 459 5.1.2 Addresses and connectivity in Case A 461 We saw in 5.1.1 that the likely motivation for deployment of IPv6 462 connectivity in hosts in case A is a desire to use peer-to-peer and 463 client IPv6 applications. These applications require that all 464 participating nodes get some form of IPv6 connectivity, i.e. at 465 least one globally reachable IPv6 address. 467 If the local gateway provides global IPv4 addresses to the local 468 hosts, then these hosts can individually exercise the mechanisms 469 described in case C, "IPv6 connectivity without provider support." 470 If the local gateway implements a NAT function, another type of 471 mechanism is needed. The mechanism to provide connectivity to peers 472 behind NAT should be easy to deploy, and light weight; it will have 473 to involve tunneling over a protocol that can easily traverse NAT, 474 either TCP or preferably UDP, as tunneling over TCP can result in 475 poor performances in case of time-outs and retransmission. If 476 servers are needed, these servers will in practice have to be 477 deployed as part of the "support infrastructure" for the peer-to- 478 peer network or for an IPv6-based service; economic reality implies 479 that the cost of running these servers should be as low as possible. 481 5.1.3 Naming services in Case A 483 At this phase of IPv6 deployment, hosts in the unmanaged domain have 484 access to DNS services over IPv4, through the existing gateway. DNS 485 resolvers are supposed to serve AAAA records, even if they only 487 Huitema et al. [Page 9] 488 implement IPv4; the local hosts should thus be able to obtain the 489 IPv6 addresses of IPv6-only servers. 491 Reverse lookup is difficult to provide for hosts on the unmanaged 492 network if the gateway is not upgraded. This is a potential issue 493 for client applications. Some servers require a reverse lookup as 494 part of accepting a client's connection, and may require that the 495 direct lookup of the corresponding name matches the IPv6 address of 496 the client. There is thus a requirement either to provide a reverse 497 lookup solution, or to make sure that IPv6 servers do not require 498 reverse lookup. 500 5.2 Case B, IPv6 connectivity with provider support 502 In this case the ISP and gateway are both dual stack. The gateway 503 can use native IPv6 connectivity to the ISP and can use an IPv6 504 prefix allocated by the ISP. 506 5.2.1 Application support in Case B 508 If the ISP and the gateway are dual-stack, client applications, 509 peer-to-peer applications and server applications can all be enabled 510 easily on the unmanaged network. 512 We expect the unmanaged network to include three kinds of hosts: 513 IPv4 only, IPv6-only, and dual stack. Obviously, dual stack hosts 514 can interact easily with either IPv4 only hosts or IPv6-only hosts, 515 but an IPv4 only host and an IPv6-only host cannot communicate 516 without a third party performing some kind of translation service. 517 Our analysis concludes that unmanaged networks should not have to 518 provide such translation services. 520 The argument for providing translation services is that their 521 availability would accelerate the deployment of IPv6-only devices, 522 and thus the transition to IPv6. This is however a dubious argument, 523 since it can also be argued that the availability of these 524 translation services will reduce the pressure to provide IPv6 at 525 all, and to just continue fielding IPv4-only devices. The remaining 526 pressure to provide IPv6 connectivity would just be the difference 527 in "quality of service" between a translated exchange and a native 528 interconnect. 530 The argument against translation service is the difficulty of 531 providing these services for all applications, compared to the 532 relative ease of installing dual stack solutions in an unmanaged 533 network. Translation services can be provided either by application 534 relays such as HTTP proxies, or by network level services such as 535 NAT-PT [RFC2766]. Application relays pose several operational 536 problems: first, one must develop relays for all applications; 537 second, one must develop a management infrastructure to provision 538 the host with the addresses of the relays; in addition, the 539 application may have to be modified if one wants to use the relay 540 selectively, e.g. only when direct connection is not available. 541 Network level translation poses similar problems: in practice, 542 network level actions must be complemented by "application layer 543 gateways" that will rewrite references to IP addresses in the 544 protocol, and while these relays are not necessary for every 545 application, they are necessary for enough applications to make any 546 sort of generalized translation quite problematic; hosts may need to 547 be parameterized to use the translation service; and designing the 548 right algorithm to decide when to translate DNS requests has proven 549 very difficult. 551 Not assuming translation services in the network appears to be both 552 more practical and more robust. If the market requirement for a new 553 device requires that it interact with both IPv4 and IPv6 hosts, we 554 may expect the manufacturers of these devices to program them with a 555 dual stack capability; in particular, we expect general purpose 556 systems such as personal computers to be effectively dual-stack. The 557 only devices that are expected to be capable of only supporting IPv6 558 are those who are designed for specific applications, which do not 559 require interoperation with IPv4-only systems. We also observe that 560 providing both IPv4 and IPv6 connectivity in an unmanaged network is 561 not particularly difficult: we have a fair amount of experience 562 using IPv4 in unmanaged networks in parallel with other protocols 563 such as, for example, IPX. 565 5.2.2 Addresses and connectivity in Case B 567 In Case B, the upgraded gateway will act as an IPv6 router; it will 568 continue providing the IPv4 connectivity, perhaps using NAT. Nodes 569 in the local network will typically obtain: 571 - IPv4 addresses (from or via the gateway), 572 - IPv6 link local addresses, and 573 - IPv6 global addresses. 575 In some networks, NAT will not be in use and the local hosts will 576 actually obtain global IPv4 addresses. We will not elaborate on 577 this, as the availability of global IPv4 addresses does not bring 578 any additional complexity to the transition mechanisms. 580 To enable this scenario, the gateway needs to use a mechanism to 581 obtain a global IPv6 address prefix from the ISP, and advertise this 582 address prefix to the hosts in the unmanaged network; several 583 solutions will be assessed in a companion memo [EVAL]. 585 5.2.3 Naming services in Case B 587 In case B, hosts in the unmanaged domain have access to DNS services 588 through the gateway. As the gateway and the ISP both support IPv4 589 and IPv6, these services may be accessible by the IPv4-only hosts 590 using IPv4, by the IPv6-only hosts using IPv6, and by the dual stack 591 hosts using either. Currently, IPv4 only hosts usually discover the 592 IPv4 address of the local DNS resolver using DHCP; there must be a 593 way for IPv6-only hosts to discover the IPv6 address of the DNS 594 resolver. 596 There must be a way to resolve the name of local hosts to their IPv4 597 or IPv6 addresses. Typing auto-configured IPv6 addresses in a 598 configuration file is impractical; this implies either some form of 599 dynamic registration of IPv6 addresses in the local service, or a 600 dynamic address discovery mechanism. Possible solutions will be 601 compared in the evaluation draft. 603 The requirement to support server applications in the unmanaged 604 network implies a requirement to publish the IPv6 addresses of local 605 servers in the DNS. There are multiple solutions, including domain 606 name delegation. If efficient reverse lookup functions are to be 607 provided, delegation of a fraction of the ip6.arpa tree is also 608 required. 610 The response to a DNS request should not depend on the protocol by 611 which the request is transported: dual-stack hosts may use either 612 IPv4 or IPv6 to contact the local resolver, the choice of IPv4 or 613 IPv6 may be random, and the value of the response should not depend 614 of a random event. 616 DNS transition issues in a dual IPv4/IPv6 network are discussed in 617 [DNSOPV6]. 619 5.3 Case C, IPv6 connectivity without provider support 621 In this case the gateway is dual stack, but the ISP is not. The 622 gateway has been upgraded and offers both IPv4 and IPv6 connectivity 623 to hosts. It cannot rely on the ISP for IPv6 connectivity, because 624 the ISP does not offer ISP connectivity yet. 626 5.3.1 Application support in Case C 628 Application support in case C should be identical to that of case B. 630 5.3.2 Addresses and connectivity in Case C 632 The upgraded gateway will behave as an IPv6 router; it will continue 633 providing the IPv4 connectivity, perhaps using NAT. Nodes in the 634 local network will obtain: 636 - IPv4 addresses (from or via the gateway), 637 - IPv6 link local addresses, 638 - IPv6 global addresses. 640 There are two ways to bring immediate IPv6 connectivity on top of an 641 IPv4 only infrastructure: automatic tunnels, e.g. provided by the 642 [6TO4] technology, or configured tunnels. Both technologies have 643 advantages and limitations, which will be studied in a companion 644 document. 646 There will be some cases where the local hosts actually obtain 647 global IPv4 addresses. We will not discuss this scenario, as it does 648 not make the use of transition technology harder, or more complex. 649 Case A has already examined how hosts could obtain IPv6 connectivity 650 individually. 652 5.3.3 Naming services in Case C 654 The local naming requirements in case C are identical to the local 655 naming requirements of case B, with two differences: delegation of 656 domain names, and management of reverse lookup queries. 658 A delegation of some domain name is required in order to publish the 659 IPv6 addresses of servers in the DNS. 661 A specific mechanism for handling reverse lookup queries will be 662 required if the gateway uses a dynamic mechanism such as 6to4 to 663 obtain a prefix independently of any IPv6 ISP. 665 5.4 Case D, ISP stops providing native IPv4 connectivity 667 In this case the ISP is IPv6-only, so the gateway loses IPv4 668 connectivity, and is faced with an IPv6-only service provider. The 669 gateway itself is dual stack, and the unmanaged network includes 670 IPv4 only, IPv6-only and dual stack hosts. Any interaction between 671 hosts in the unmanaged network and IPv4 hosts on the Internet will 672 require the provision of some inter-protocol services by the ISP. 674 5.4.1 Application support in Case D 676 At this phase of the transition, IPv6 hosts can participate in all 677 types of applications with other IPv6 hosts. IPv4 hosts in the 678 unmanaged network will be able to perform local applications with 679 IPv4 or dual stack local hosts. 681 As in case B, we will assume that IPv6-only hosts will not interact 682 with IPv4-only hosts, either local or remote. We must however assume 683 that IPv4-only hosts and dual stack hosts will desire to interact 684 with IPv4 services available on the Internet: the inability to do so 685 would place the IPv6-only provider at a great commercial 686 disadvantage compared to other Internet service providers. 688 There are three possible ways that an ISP can provide hosts in the 689 unmanaged network with access to IPv4 applications: by using a set 690 of application relays, by providing an address translation service, 691 or by providing IPv4-over-IPv6 tunnels. Our analysis concludes that 692 a tunnel service seems to be vastly preferable. 694 We already mentioned the drawbacks of the application gateway 695 approach when analyzing case B: it is necessary to provide relays 696 for all applications, to develop a way to provision the hosts with 697 the addresses of these relays, and to modify the applications so 698 that they will only use the relays when needed. We also observe that 699 in an IPv6-only ISP the application relays would only be accessible 700 over IPv6, and would thus not be accessible by the "legacy" IPv4- 701 only hosts. The application relay approach is thus not very 702 attractive. 704 Providing a network address and protocol translation service between 705 IPv6 and IPv4 would also have many drawbacks. As in case B, it will 706 have to be complemented by "application layer gateways" that will 707 rewrite references to IP addresses in the protocol; hosts may need 708 to be parameterized to use the translation service; and we would 709 have to solve DNS issues. The network level protocol translation 710 service doesn't appear to be very desirable. 712 The preferable alternative to application relays and network address 713 translation is the provision of an IPv4-over-IPv6 service. 715 5.4.2 Addresses and connectivity in Case D 717 The ISP assigns an IPv6 prefix to the unmanaged network, so hosts 718 have a global IPv6 address and use it for global IPv6 connectivity. 719 This will require delegation of an IPv6 address prefix, as 720 investigated in case C. 722 To enable IPv4 hosts and dual stack hosts to access remote IPv4 723 services, the ISP must provide the gateway with at least one IPv4 724 address, using some form of IPv4-over-IPv6 tunneling. Once such 725 addresses have been provided, the gateway effectively acquires dual- 726 stack connectivity; for hosts inside the unmanaged network, this 727 will be indistinguishable from the IPv4 connectivity obtained in 728 case B or C. 730 5.4.3 Naming services in Case D 732 The loss of IPv4 connectivity has a direct impact on the provision 733 of naming services. In many IPv4 unmanaged networks, hosts obtain 734 their DNS configuration parameters from the local gateway, typically 735 through the DHCP service. If the same mode of operation is desired 736 in case D, the gateway will have to be provisioned with the address 737 of a DNS resolver and with other DNS parameters, and this 738 provisioning will have to use IPv6 mechanisms. Another consequence 739 is that the DNS service in the gateway will only be able to use IPv6 740 connectivity to resolve queries; if local hosts perform DNS 741 resolution autonomously, they will have the same restriction. 743 On the surface, this seems to indicate that the local hosts will 744 only be able to resolve names if the domain servers are accessible 745 through an IPv6 address documented in an AAAA record. However, the 746 DNS services are just one case of "IPv4 servers accessed by IPv6 747 hosts": it should be possible to simply send queries through the 748 IPv4 connectivity services to reach the IPv4 only servers. 750 The gateway should be able to act as a recursive DNS name server for 751 the remaining IPv4 only hosts. 753 6 Security Considerations 755 Security considerations are discussed as part of the applications' 756 requirements. They include: 758 - the guarantee that local applications are only used locally, 759 - the protection of the privacy of clients 760 - the requirement that peer-to-peer connections are only used by 761 authorized peers 762 - the requirement that tunneling protocols used for IPv6 access over 763 IPv4 be designed for secure use 764 - the related requirement that servers in the infrastructure 765 supporting transition scenarios be designed not to be vulnerable to 766 abuse. 768 The security solutions currently used in IPv4 networks include a 769 combination of firewall functions in the gateway, authentication and 770 authorization functions in the applications, encryption and 771 authentication services provides by IP security, Transport Layer 772 Security and application specific services, and host-based security 773 products such as anti-virus software, and host firewalls. The 774 applicability of these tools in IPv6 unmanaged networks will be 775 studied in a companion document. 777 7 IANA Considerations 779 This memo does not include any request to IANA. 781 8 Copyright 783 The following copyright notice is copied from RFC 2026 [Bradner, 784 1996], Section 10.4, and describes the applicable copyright for this 785 document. 787 Copyright (C) The Internet Society July 12, 2001. All Rights 788 Reserved. 790 This document and translations of it may be copied and furnished to 791 others, and derivative works that comment on or otherwise explain it 792 or assist in its implementation may be prepared, copied, published 793 and distributed, in whole or in part, without restriction of any 794 kind, provided that the above copyright notice and this paragraph 795 are included on all such copies and derivative works. However, this 796 document itself may not be modified in any way, such as by removing 797 the copyright notice or references to the Internet Society or other 798 Internet organizations, except as needed for the purpose of 799 developing Internet standards in which case the procedures for 800 copyrights defined in the Internet Standards process must be 801 followed, or as required to translate it into languages other than 802 English. 804 The limited permissions granted above are perpetual and will not be 805 revoked by the Internet Society or its successors or assignees. 807 This document and the information contained herein is provided on an 808 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 809 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 810 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 811 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 812 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 814 9 Intellectual Property 816 The following notice is copied from RFC 2026 [Bradner, 1996], 817 Section 10.4, and describes the position of the IETF concerning 818 intellectual property claims made against this document. 820 The IETF takes no position regarding the validity or scope of any 821 intellectual property or other rights that might be claimed to 822 pertain to the implementation or use other technology described in 823 this document or the extent to which any license under such rights 824 might or might not be available; neither does it represent that it 825 has made any effort to identify any such rights. Information on the 826 IETF's procedures with respect to rights in standards-track and 827 standards-related documentation can be found in BCP-11. Copies of 828 claims of rights made available for publication and any assurances 829 of licenses to be made available, or the result of an attempt made 830 to obtain a general license or permission for the use of such 831 proprietary rights by implementers or users of this specification 832 can be obtained from the IETF Secretariat. 834 The IETF invites any interested party to bring to its attention any 835 copyrights, patents or patent applications, or other proprietary 836 rights which may cover technology that may be required to practice 837 this standard. Please address the information to the IETF Executive 838 Director. 840 10 Acknowledgements 842 This draft has benefited from the comments of the members of the 843 IETF V6OPS working group, and from extensive reviews by Chris 844 Fischer, Tony Hain, Kurt Erik Lindqvist, Erik Nordmark, Pekka 845 Savola, and Margaret Wasserman. 847 11 References 849 Normative References 851 [RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981. 853 [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6 854 (IPv6) Specification", RFC 2460, December 1998. 856 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 857 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 859 [RFC2462] Narten, T., and S. Thomson, "IPv6 Stateless Address 860 Autoconfiguration", RFC 2462, December 1998. 862 Informative references 864 [EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks, 865 work in progress. 867 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 868 J., and E. Lear, "Address Allocation for Private Internets", RFC 869 1918, February 1996. 871 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, 872 "Service Location Protocol, Version 2", RFC 2608, June 1999. 874 [RFC3056] Carpenter, B., and K. Moore, "Connection of IPv6 Domains 875 via IPv4 Clouds", RFC 3056, February 2001. 877 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 878 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 879 Session Initiation Protocol", RFC 3261, June 2002. 881 [RFC3022] Srisuresh, P., and K. Egevang. "Traditional IP Network 882 Address Translator (Traditional NAT)", RFC 3022, January 2001. 884 [RFC2993] T. Hain. "Architectural Implications of NAT", RFC 2993, 885 November 2000. 887 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day. 888 "Service Location Protocol, Version 2", RFC 2993, June 1999. 890 [RFC3041] Narten, T., and R. Draves. "Privacy Extensions for 891 Stateless Address Autoconfiguration in IPv6", RFC 3041, January 892 2001. 894 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 895 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 896 Session Initiation Protocol", RFC 3261, June 2002. 898 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 899 Translation - Protocol Translation (NAT-PT)", RFC 2766, February 900 2000. 902 [DNSOPV6] A. Durand. "IPv6 DNS transition issues", Work in progress. 904 [DNSINADDR] D. Senie. "Requiring DNS IN-ADDR Mapping", Work in 905 progress. 907 12 Authors' Addresses 909 Christian Huitema 910 Microsoft Corporation 911 One Microsoft Way 912 Redmond, WA 98052-6399 913 Email: huitema@microsoft.com 915 Rob Austein 916 Email: sra@hactrn.net 918 Suresh Satapati 919 Cisco Systems, Inc. 920 San Jose, CA 95134 921 USA 922 EMail: satapati@cisco.com 924 Ronald van der Pol 925 NLnet Labs 926 Kruislaan 419 927 1098 VA Amsterdam 928 NL 929 Email: Ronald.vanderPol@nlnetlabs.nl 931 Table of Contents: 933 1 Introduction .................................................... 1 934 2 Topology ........................................................ 2 935 3 Applications .................................................... 3 936 3.1 Local applications ............................................ 3 937 3.2 Client applications ........................................... 3 938 3.3 Peer-to-peer applications ..................................... 3 939 3.4 Server applications ........................................... 4 940 4 Application requirements of an IPv6 unmanaged network ........... 4 941 4.1 Requirements of local applications ............................ 5 942 4.2 Requirements of client applications ........................... 5 943 4.2.1 Privacy requirement of client applications .................. 5 944 4.3 Requirements of peer-to-peer applications ..................... 6 945 4.4 Requirements of server applications ........................... 7 946 5 Stages of IPv6 deployment ....................................... 7 947 5.1 Case A, host deployment of IPv6 applications .................. 8 948 5.1.1 Application support in Case A ............................... 8 949 5.1.2 Addresses and connectivity in Case A ........................ 9 950 5.1.3 Naming services in Case A ................................... 9 951 5.2 Case B, IPv6 connectivity with provider support ............... 10 952 5.2.1 Application support in Case B ............................... 10 953 5.2.2 Addresses and connectivity in Case B ........................ 11 954 5.2.3 Naming services in Case B ................................... 11 955 5.3 Case C, IPv6 connectivity without provider support ............ 12 956 5.3.1 Application support in Case C ............................... 12 957 5.3.2 Addresses and connectivity in Case C ........................ 12 958 5.3.3 Naming services in Case C ................................... 13 959 5.4 Case D, ISP stops providing native IPv4 connectivity .......... 13 960 5.4.1 Application support in Case D ............................... 13 961 5.4.2 Addresses and connectivity in Case D ........................ 14 962 5.4.3 Naming services in Case D ................................... 14 963 6 Security Considerations ......................................... 15 964 7 IANA Considerations ............................................. 15 965 8 Copyright ....................................................... 15 966 9 Intellectual Property ........................................... 16 967 10 Acknowledgements ............................................... 16 968 11 References ..................................................... 16 969 12 Authors' Addresses ............................................. 18