idnits 2.17.1 draft-ietf-v6ops-unman-scenarios-00.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 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 46 instances of lines with control characters in the document. ** The abstract seems to contain references ([Bradner,1996], [EVAL], [6TO4]), 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 section? 'EVAL' on line 764 looks like a reference -- Missing reference section? '6TO4' on line 579 looks like a reference -- Missing reference section? 'Bradner' on line 733 looks like a reference -- Missing reference section? '1996' on line 733 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 January 10, 2003 R. Austein 4 Expires July 10, 2003 Bourgeois Dilettant 5 R. van der Pol 6 NLnet Labs 8 Unmanaged Networks IPv6 Transition Scenarios 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 In order to evaluate the suitability of transition mechanisms, we 34 need to define the scenarios in which these mechanisms have to be 35 used. One specific scope is the "unmanaged networks", which 36 typically correspond to home networks or small office networks. 38 1 Introduction 40 In order to evaluate the suitability of transition mechanisms, we 41 need to define the environment or scope in which these mechanisms 42 have to be used. One specific scope is the "unmanaged networks", 43 which typically correspond to home networks or small office 44 networks. 46 2 Topology 48 The typical unmanaged network is composed of a single subnet, 49 connected to the Internet through a single Internet Service Provider 50 (ISP)connection. Several hosts are connected to the subnet: 52 Huitema et al. [Page 1] 53 +------+ 54 | Host +--+ 55 +------+ | 56 | 57 +------+ | 58 | Host +--+ +-------------- 59 +------+ | | 60 : +-----+ 61 : +---------+ | | 62 +--+ Gateway +------| ISP | Internet 63 : +---------+ | | 64 : +-----+ 65 +------+ | | 66 | Host +--+ +-------------- 67 +------+ | 68 | 69 +------+ | 70 | Host +--+ 71 +------+ 73 Between the subnet and the ISP access link is a gateway, which may 74 or may not perform NAT and firewall function. A key point of this 75 configuration is that the gateway is typically not "managed". In 76 most cases, it is a simple "appliance", which incorporates some 77 static policies. There are however many cases in which the gateway 78 is procured and configured by the ISP, and there are also some 79 common cases in which we find two back to back gateways, one managed 80 by the ISP and the other added by the owner of the unmanaged 81 network. 83 The access link between the unmanaged network and the ISP can be 84 either static, i.e. a permanent connection, or dynamically 85 established, i.e. a dial-up or ISDN connection. 87 In a degenerate case, an unmanaged network can be constituted of a 88 single host, directly connected to an ISP. 90 3 Applications 92 Users may use or wish to use the unmanaged network services in four 93 types of applications: local, client, servers and peer-to-peers. 94 These applications may or may not run easily on today's network: 95 their status vary. 97 3.1 Local applications 99 Local applications are meant to only involve the hosts that are part 100 of the unmanaged network. Typical examples are the sharing of file 101 or printers. 103 Local applications work effectively in IPv4 unmanaged networks, even 105 Huitema et al. [Page 2] 106 when the gateway performs NAT or firewall function. In fact, 107 firewall services at the gateway are often deemed desirable, as they 108 isolate the local applications from interference by Internet users. 110 3.2 Client applications 112 Client applications are those that involve a client on the unmanaged 113 network and a server at a remote location. A typical example is 114 accessing a web server from a client inside the unmanaged network, 115 or reading and sending e-mail with the help of a server outside the 116 unmanaged network. 118 Local applications tend to work correctly in IPv4 unmanaged 119 networks, even when the gateway performs NAT or firewall function: 120 these translation and firewall functions are precisely designed to 121 enable client applications. 123 3.3 Peer-to-peer applications 125 There are two kinds of peer-to-peer applications, the "local peer- 126 to-peer" that only involve hosts on the unmanaged network, and the 127 "remote peer-to-peer" that involve both hosts on the unmanaged 128 network and hosts outside the network. We will only consider here 129 the "remote peer-to-peer" applications, as the local peer-to-peer 130 applications are a subset of the "local applications." 132 Peer-to-peer applications are a restricted subset of the server 133 applications, in which the services are only meant to be used by 134 well identified peers outside the unmanaged network. These 135 applications are often facilitated by a server outside the unmanaged 136 networks. Examples of a peer-to-peer application would be a video- 137 conference over IP, facilitated by a SIP server, or a distributed 138 game application, facilitated by a "game lobby". 140 Peer-to-peer applications often don't work well in unmanaged IPv4 141 networks. Application developers often have to enlist the help of a 142 "relay server", to effectively restructure the peer-to-peer 143 connection in two back-to-back client/server connections. 145 3.4 Server applications 147 Server applications involve running a server in the unmanaged 148 network, for use by other parties outside the network. Examples 149 would be running a web server or an e-mail server on one of the 150 hosts inside the unmanaged network. 152 Deploying these servers in most unmanaged IPv4 networks requires 153 some special programming of the NAT or firewall, and is more complex 154 when the NAT only publishes a small number of global IP addresses 155 and relies on "port translation". In the common case in which the 156 NAT manages exactly one global IP address and relies on "port 157 translation", a given external port can only be used by one internal 159 Huitema et al. [Page 3] 160 server. 162 Deploying servers usually requires providing the servers with a 163 stable DNS name, and associating the global IPv4 address of the 164 nat/firewall with that name. Since updating DNS is a management 165 task, it somewhat falls outside the scope of an unmanaged network. 166 On the other hand, it is also possible to use out-of-band 167 techniques, such as cut-and-paste into an instant message system, to 168 pass around the address of the target server. 170 4 Application requirements of an IPv6 unmanaged network 172 As we transition to IPv6, we must meet the requirements of the 173 various applications, which we can summarize in the following way: 174 the applications that used to work well with IPv4 should continue 175 working well during the transition; it should be possible to use 176 IPv6 to deploy new applications that are currently hard to deploy in 177 IPv4 networks; the deployment of these IPv6 applications should be 178 simple and easy to manage. 180 The application requirements are expressed in mostly three 181 dimensions: connectivity, naming, and security. Connectivity issues 182 include the provision of IPv6 addresses and their quality: do host 183 need a global scope address, should this address be stable, or more 184 precisely what should be the expected lifetime of the address. 185 Naming issues include the management of names for the hosts: do 186 hosts need a DNS-name, is inverse name resolution a requirement. 187 Security issues include possible restriction to connectivity, 188 privacy concerns, and generally speaking the security of the 189 applications. 191 4.1 Requirements of local applications 193 Local applications require local connectivity. They must continue 194 working even if the unmanaged network is isolated from the Internet. 196 Local applications typically use ad hoc naming systems. Many of 197 these systems are proprietary; an example of standard system is the 198 service location protocol (SLP). 200 The security of local applications is enhanced if these applications 201 can be effectively isolated from the global Internet. 203 4.2 Requirements of client applications 205 Client applications require global connectivity. In an IPv6 network, 206 we would expect the client to use a global IPv6 address, which will 207 have to remain stable for the duration of the client-server session. 209 Client applications typically use the domain name system to locate 210 servers. In an IPv6 network, the client must be able to locate a DNS 211 server. 213 Huitema et al. [Page 4] 214 Many servers try to look up a DNS name associated to the IP address 215 of the client. In an IPv4 network, this IP address will often be 216 allocated by the Internet service provider to the gateway, and the 217 corresponding PTR record will be maintained by the ISP. In most 218 cases, these PTR records are perfunctory, derived in an algorithmic 219 fashion from the IPv4 address; the main information that they 220 contain is the domain name of the ISP. Whether or not an equivalent 221 function should be provided in an IPv6 network is unclear. 223 4.2.1 Privacy requirement of client applications 225 We may debate whether the IPv6 networking service should be 226 engineered to enhance the privacy of the clients, and specifically 227 whether the support of RFC 3041 should be required. RFC 3041 enables 228 hosts to pick IPv6 addresses in which the host identifier is 229 randomized; this was designed to make sure that the IPv6 addresses 230 and the host identifier cannot be used to track the Internet 231 connections of a device's owner. 233 Many observe that randomizing the host identifier portion of the 234 address is only a half measure. If the unmanaged network address 235 prefix remains constant, the randomization only hides which host in 236 the unmanaged network originates a given connection, e.g. the 237 children's computer versus their parents'. This would place the 238 privacy rating of such connections on a par with that of IPv4 239 connections originating from an unmanaged network in which a NAT 240 manages a static IPv4 address; in both case, the IPv4 address or the 241 IPv6 prefix can be used to identify the unmanaged network, e.g. the 242 specific home from which the connection originated. 244 Randomization of the host identifier does however provide benefits. 245 First, if some of the hosts in the unmanaged network are mobile, the 246 randomization destroys any correlation between the addresses used at 247 various locations: the addresses alone could not be used to 248 determine whether a given connection originates from the same laptop 249 moving from work to home, or used on the road. Second, the 250 randomization removes any information that could be extracted from a 251 hardwired host identifier; for example, it will prevent outsiders to 252 correlate a serial number with a specific brand of expensive 253 electronic equipment, and to use this information for planning 254 marketing campaigns or possibly burglary attempts. 256 Randomization of the addresses is indeed not sufficient to guarantee 257 privacy. Usage can be tracked by a variety of other means, from 258 application level "cookies" to complex techniques involving data 259 mining and traffic analysis. However, just because privacy can be 260 breached by other means is not a sufficient reason to enable 261 additional tracking through IPv6 addresses. 263 Randomization of the host identifier has some cost: the address 264 management in hosts is more complex for the hosts and the gateway 266 Huitema et al. [Page 5] 267 may have to maintain a larger cache of neighbor addresses; however, 268 experience from existing implementation shows that these costs are 269 not overwhelming. Given the limited benefits, it would be 270 unreasonable to require that all hosts use privacy addresses; 271 however, given the limited costs, it is reasonable to require that 272 all unmanaged network allow use of privacy addresses by those hosts 273 who so choose. 275 4.3 Requirements of peer-to-peer applications 277 Peer-to-peer applications require global connectivity. In an IPv6 278 network, we would expect the peers to use a global IPv6 address, 279 which will have to remain stable for the duration of the peer-to- 280 peer between client and server. 282 Peer-to-peer applications often use ad hoc naming systems, sometimes 283 derived from an "instant messaging" service. Many of these systems 284 are proprietary; an example of standard system is the session 285 initiation protocol (SIP). In these systems, the peers register 286 their presence to a "rendezvous" server, using a name specific to 287 the service; the case of SIP, they would use a SIP URL, of the form 288 "sip:user@example.com". A peer to peer session typically starts by 289 an exchange of synchronization messages through the rendezvous 290 servers, during which the peers exchange the addresses that will be 291 used for the session. 293 There are multiple aspects to the security of peer-to-peer 294 applications, many of which relate to the security of the rendezvous 295 system. If we assume that the peers have been able to safely 296 exchange their IPv6 addresses, the main security requirement is the 297 capability to safely exchange data between the peers, without 298 interference by third parties. 300 Private conversations with developers of peer-to-peer applications 301 showed that many would be willing to consider an "IPv6-only" model 302 if they can get two guarantees: 304 1) That there is no regression from IPv4, i.e. that all customers 305 that could participate in a peer-to-peer application using IPv4 can 306 also be reached by IPv6. 308 2) That IPv6 provides a solution for at least some of their hard 309 problems, i.e. enabling peers located behind an IPv4 NAT to 310 participate in a peer-to-peer application. 312 Requiring IPv6 connectivity for a popular peer-to-peer application 313 could create what economists refer to as a "network effect", which 314 in turn could significantly speed up the deployment of IPv6. 316 4.4 Requirements of server applications 318 Server applications require global connectivity, which in an IPv6 320 Huitema et al. [Page 6] 321 network implies global addresses. 323 Server applications normally rely on the publication of the server's 324 address in the DNS. This, in turns, requires that the server be 325 provisioned with a "global DNS name". 327 The DNS entries for the server will have to be updated, preferably 328 in real time, if the server's address changes. In practice, updating 329 the DNS is slow, which implies that server applications will have a 330 better chance of being deployed if the IPv6 addresses remain stable 331 for a long period. 333 The security of server applications depends mostly on the 334 correctness of the server, and also on the absence of collateral 335 effects: many incidents occur when the opening of a server on the 336 Internet inadvertently enables remote access to some other services 337 on the same host. 339 5 Stages of IPv6 deployment 341 The deployment of IPv6 over time is expected to proceed from an 342 initial state in which there is little or no deployment, to a final 343 stage in which we might retire the IPv4 infrastructure. We expect 344 this process to stretch over several years; we also expect it to not 345 be synchronized, as different parties involved will deploy IPv6 at 346 different pace. In order to get some clarity, we distinguish three 347 entities involved in the transition of an unmanaged network: the ISP 348 (possibly including ISP CPE), the home gateway and the hosts 349 (computers and appliances). Each can support IPv4-only, both IPv4 350 and IPv6 or IPv6-only. That gives us 27 possibilities. We describe 351 the most important cases. We will consider that in all cases the 352 hosts are a combination of IPv4-only, dual stack and IPv6-only 353 hosts. 355 The cases we will consider are: 357 A) Gateway does not provide IPv6 358 B) ISP and gateway are dual stack 359 C) Gateway is IPv6 capable, dual stack, ISP is not 360 D) ISP is IPv6-only 362 The case where the ISP is IPv6 capable but the gateway is not is 363 similar to case A. 365 5.1 Case A, host deployment of IPv6 applications 367 In this case the gateway doesn't provide IPv6; the ISP may or may 368 not provide IPv6, but this is not relevant, since the non-upgraded 369 gateway would prevent the hosts from using the ISP service. Some 370 hosts will try to get IPv6 connectivity, in order to run 371 applications that require IPv6, or work better with IPv6. 373 Huitema et al. [Page 7] 374 5.1.1 Application support in Case A 376 The focus of Case A is to enable communication between a host on the 377 unmanaged network and some IPv6-only hosts outside of the network. 378 The primary focus in the immediate future, i.e. for the early 379 adopters of IPv6, will be peer-to-peer applications. However, as 380 IPv6 deployment progresses, we will likely find a situation where 381 some networks have IPv6-only services deployed, at which point we 382 would like case A client applications to be able to access those 383 services. 385 Local applications are not a primary focus of Case A. At this stage, 386 we expect all clients in the unmanaged network to have either IPv4 387 only or dual stack support. Local applications can continue working 388 using IPv4. 390 Server applications are also not a primary focus of Case A. Server 391 applications require DNS support, which is difficult to engineer for 392 clients located behind a NAT. Besides, server applications, at this 393 stage, cater mostly to IPv4 clients; putting up an IPv6-only server 394 is not very attractive. 396 In contrast, peer-to-peer applications are both attractive and easy 397 to deploy: they are deployed in a coordinated fashion as part of a 398 peer-to-peer network, which means that hosts can all receive some 399 form of IPv6 upgrade; they often provide their own naming 400 infrastructure, in which case they are not dependent on DNS 401 services. 403 5.1.2 Addresses and connectivity in Case A 405 We saw in 5.1.1 that a primary motivation for the deployment of IPv6 406 connectivity in hosts is participation to peer-to-peer applications, 407 and also to IPv6-only client applications. These applications 408 require that all participating nodes get some form of IPv6 409 connectivity, i.e. at least one globally reachable IPv6 address. The 410 mechanism to provide connectivity to peers behind NAT should be easy 411 to deploy, and light weight; it will have to involve tunneling over 412 UDP, as this is the practical way to traverse a NAT. If servers are 413 needed, these servers will in practice have to be deployed as part 414 of the "support infrastructure" for the peer-to-peer network or for 415 an IPv6 based service; economic reality implies that the cost of 416 running these servers should be as low as possible. 418 5.1.3 Naming services in Case A 420 At this phase of IPv6 deployment, hosts in the unmanaged domain have 421 access to DNS services over IPv4, through the existing gateway. DNS 422 resolvers are supposed to serve AAAA records, even if they only 423 implement IPv4; the local hosts should thus be able to obtain the 424 IPv6 addresses of IPv6-only servers. 426 Huitema et al. [Page 8] 427 Reverse lookup is hard to provide if the gateway is not upgraded. 428 This is a potential issue for client applications. Some servers 429 require a reverse lookup as part of accepting a client's connection, 430 and may require that the direct lookup of the corresponding name 431 matches the IPv6 address of the client. There is thus a requirement 432 to either provide a reverse lookup solution, or make sure that IPv6 433 servers do not require reverse lookup. 435 5.2 Case B, IPv6 connectivity with provider support 437 In this case the ISP and gateway are dual stack. The gateway can use 438 native IPv6 connectivity to the ISP and use an IPv6 prefix allocated 439 by the ISP. 441 5.2.1 Application support in Case B 443 If the ISP and the gateway are dual-stack, client applications, 444 peer-to-peer applications and server applications can all be enabled 445 easily on the unmanaged network. 447 We expect the unmanaged network to include three kinds of hosts: 448 IPv4 only, IPv6-only, and dual stack. Obviously, dual stack hosts 449 can interact easily with either IPv4 only hosts or IPv6-only hosts, 450 but an IPv4 only host and an IPv6-only host cannot communicate 451 without a third party performing some kind of translation service. 452 Our analysis concludes that unmanaged networks should not have to 453 provide such translation services. 455 The argument for providing translation services is that their 456 availability would accelerate the deployment of IPv6-only devices, 457 and thus the transition to IPv6. This is however a dubious argument, 458 since it can also be argued that the availability of these 459 translation services will reduce the pressure to provide IPv6 at 460 all, and to just continue fielding IPv6-only devices. The remaining 461 pressure to provide IPv6 connectivity would just be the difference 462 in "quality of service" between a translated exchange and a native 463 interconnect. 465 The argument against translation service is the difficulty of 466 providing these services for all applications, compared to the 467 relative ease of installing dual stack solutions in an unmanaged 468 network. Translation services can be provided either by application 469 relays such as HTTP proxies, or by network level services such as 470 NAT-PT. Application relays pose several operational problems: first, 471 one must develop relays for all applications; second, one must 472 develop a management infrastructure to provision the host with the 473 addresses of the relays; in addition, the application may have to be 474 modified if one wants to use the relay selectively, e.g. only when 475 direct connection is not available. Network level translation poses 476 similar problems: in practice, network level actions must be 477 complemented by "application layer gateways" that will rewrite 478 references to IP addresses in the protocol, and these relays tend to 480 Huitema et al. [Page 9] 481 be necessary for every application; hosts may need to be 482 parameterized to use the translation service; and designing the 483 right algorithm to decide when to translate DNS requests has proven 484 very difficult. 486 Not assuming translation services in the network appears both more 487 practical and more robust. If the market requirement for a new 488 device requires that it interacts with both IPv4 and IPv6 hosts, we 489 may expect the manufacturers of these devices to program them with a 490 dual stack capability; in particular, we expect general purpose 491 systems such as personal computers to be effectively dual-stack. The 492 only devices that are expected to be capable of only supporting IPv6 493 are those who are designed for specific applications, which do not 494 require interoperation with antique IPv4-only systems. We also 495 observe that providing both IPv4 and IPv6 connectivity in an 496 unmanaged network is not particularly difficult; indeed there is a 497 well established experience of using IPv4 in these networks in 498 parallel with other protocols such as for example IPX. 500 5.2.2 Addresses and connectivity in Case B 502 In Case B, the upgraded gateway will behave as an IPv6 router; it 503 will continue providing the IPv4 connectivity of a non-upgraded NAT. 504 Nodes in the local network will obtain: 506 - IPv4 natted addresses, 507 - IPv6 link local addresses, 508 - IPv6 global addresses. 510 The hosts could also obtain IPv6 site local addresses, if the 511 gateway advertises a site local prefix. This is as debatable: site 512 local addresses provide some isolation to site local application 513 from network connectivity events and network based attacks; however, 514 managing non unique addresses can be problematic if some local hosts 515 are multi-homed, as is common with VPN connections. 517 To enable this scenario, the gateway need to use a mechanism obtain 518 a global address prefix from the ISP, and advertise this address 519 prefix to the hosts in the unmanaged network; several solutions will 520 be assessed in a companion memo [EVAL]. 522 5.2.3 Naming services in Case B 524 At this phase of IPv6 deployment, hosts in the unmanaged domain have 525 access to DNS services through the gateway. As the gateway and the 526 ISP both support IPv4 and IPv6, these services may be accessible by 527 the IPv4 only hosts using IPv4, by the IPv6-only hosts using IPv6, 528 and by the dual stack hosts using either. Currently, IPv4 only hosts 529 discover the IPv4 address of the local DNS server using DHCP; there 530 must be a way for IPv6-only hosts to discover the IPv6 address of 531 the DNS server. 533 There must be a way to resolve the name of local hosts to their IPv4 534 or IPv6 addresses. Typing auto-configured IPv6 addresses in a 535 configuration file is impractical; this implies either some form of 536 dynamic registration of IPv6 addresses in the local service, or a 537 dynamic address discovery mechanism. Possible solutions will be 538 compared in the evaluation draft. 540 The requirement to support server applications in the unmanaged 541 network implies a requirement to publish the IPv6 addresses of local 542 servers in the DNS. There are multiple solutions, including 543 variations of domain name delegation. If we want to provide 544 efficient reverse lookup functions, delegation of a fraction of the 545 ip6.arpa tree is also required. 547 The response to a DNS request should not depend of the protocol with 548 which the request is transported: dual-stack hosts may indifferently 549 use IPv4 or IPv6 to contact the local resolver; the choice of IPv4 550 or IPv6 will be random; the value of the response should not depend 551 of a random event. 553 5.3 Case C, IPv6 connectivity without provider support 555 In this case the gateway is IPv6 capable, dual stack, the ISP is 556 not. The gateway has been upgraded and offers both IPv4 and IPv6 557 connectivity the hosts. It cannot rely on the ISP for IPv6 558 connectivity, because the ISP does not offer ISP connectivity yet. 560 5.3.1 Application support in Case C 562 Application support in case C should be identical to that of case B. 564 5.3.2 Addresses and connectivity in Case C 566 The upgraded gateway will behave as an IPv6 router; it will continue 567 providing the IPv4 connectivity of non-upgraded NAT. Nodes in the 568 local network will obtain: 570 - IPv4 natted addresses, 571 - IPv6 link local addresses, 572 - IPv6 global addresses. 574 The clients could also obtain IPv6 site local addresses, if the 575 gateway advertises a site local prefix; this raises the same issues 576 already discussed in case B. 578 There are two ways to bring immediate IPv6 connectivity on top of an 579 IPv4 only infrastructure: automatic tunnels provided by the [6TO4] 580 technology, or configured tunnels. Both technologies have advantages 581 and limitations, which will be studied in a companion document. 583 5.3.3 Naming services in Case C 584 The local naming requirements in case C are identical to the local 585 naming requirements of case B, with two differences: delegation of 586 domain names, and management of reverse lookup queries. 588 A delegation of some domain name is required in order to publish the 589 IPv6 addresses of servers in the DNS. As the ISP does not provide 590 support for IPv6 in case C, the delegation mechanism will have to be 591 provided independently of the IP connectivity mechanism. 593 A specific mechanism for handling reverse lookup queries will be 594 required if the gateway uses a dynamic mechanism such as 6to4 to 595 obtain a prefix independently of any IPv6 ISP. 597 5.4 Case D, ISP stops providing native IPv4 connectivity 599 In this case the ISP is IPv6-only, so the gateway looses IPv4 600 connectivity, and is faced with an IPv6-only service provider. The 601 gateway itself is dual stack, and the unmanaged network includes 602 IPv4 only, IPv6-only and dual stack hosts. Any interaction between 603 hosts in the unmanaged network and IPv4 hosts on the Internet will 604 require the provision of some inter-protocol services by the ISP. 606 5.4.1 Application support in Case D 608 At this phase of the transition, IPv6 hosts can perform all types of 609 applications with other IPv6 hosts. IPv4 hosts in the unmanaged 610 network will be able to perform local applications with IPv4 or dual 611 stack local hosts. 613 As in case B, we will assume that IPv6-only hosts will not interact 614 with IPv4-only hosts, either local or remote. We must however assume 615 that IPv4-only hosts and dual stack hosts will desire to interact 616 with IPv4 services available on the Internet: the inability to do so 617 would place the IPv6-only provider at a great commercial 618 disadvantage compared to other Internet service providers. 620 There are three possible ways that an ISP can provide hosts in the 621 unmanaged network with access to IPv4 application: by using a set of 622 application relays, by providing an address translation service, or 623 by providing IPv4-over-IPv6 tunnels. Our analysis concludes that a 624 tunnel service will be vastly preferable. 626 We already mentioned the drawbacks of the application gateway 627 approach when analyzing case B: it is necessary to provide relays 628 for all applications, to develop a way to provision the hosts with 629 the addresses of these relays, and to modify the applications so 630 that they will only use the relays when needed. We also observe that 631 in an IPv6-only ISP the application relays would only be accessible 632 over IPv6, and would thus not be accessible by the "legacy" IPv4- 633 only hosts. The application relay approach is thus not very 634 attractive. 636 Providing a network address and protocol translation service between 637 IPv6 and IPv4 would also have many drawbacks. As in case B, it will 638 have to be complemented by "application layer gateways" that will 639 rewrite references to IP addresses in the protocol; hosts may need 640 to be parameterized to use the translation service; and we would 641 have to solve DNS issues. In addition, in an IPv6-only ISP, an IPv6- 642 to-IPv4 translation service would not be accessible by legacy IPv4- 643 only hosts through the IPv6 only ISP service. The network level 644 protocol translation service appears to not be very desirable. 646 The proper alternative to application relays and network address 647 translation is the provision of an IPv4-over-IPv6 service. 649 5.4.2 Addresses and connectivity in Case D 651 The ISP assigns an IPv6 prefix to the unmanaged network, so hosts 652 have a global IPv6 address and use it for global IPv6 connectivity. 653 This will require delegation of an IPv6 address prefix, as 654 investigated in case C. 656 To enable IPv4 hosts and dual stack host to access remote IPv4 657 services, the ISP must provide the gateway with at least one IPv4 658 address, using some form of IPv4-over-IPv6 tunneling. Once such 659 addresses have been provided, the gateway effectively acquires dual- 660 stack connectivity; for hosts inside the unmanaged network, this 661 will be indistinguishable from the connectivity obtained in case B 662 or C. 664 5.4.3 Naming services in Case D 666 The loss of IPv4 connectivity has a direct impact on the provision 667 of naming services. An obvious consequence is the gateway will have 668 to be provisioned with the address of a DNS server and with other 669 DNS parameters, and that this provisioning will have to use IPv6 670 mechanisms. Another consequence is that the DNS service in the 671 gateway will only be able to use IPv6 connectivity to resolve 672 queries; if local hosts perform DNS resolution autonomously, they 673 will have the same restriction. 675 On the surface, this seems to indicate that the local hosts will 676 only be able to resolve names if the domain servers are accessible 677 through an IPv6 address documented in a AAAA record. However, the 678 DNS services are just one case of "IPv4 servers accessed by IPv6 679 hosts": it should be possible to simply send queries through the 680 address translation services to reach the IPv4 only servers. 682 The gateway should be able to act as a "DNS proxy" for the remaining 683 IPv4 only hosts. 685 6 Security Considerations 686 Security considerations are discussed as part of the applications' 687 requirements. They include: 689 - the guarantee that local applications are only used locally, 690 - the protection of the privacy of clients 691 - the requirement that peer-to-peer connections are only used by 692 authorized peers. 694 7 IANA Considerations 696 This memo does not include any request to IANA. 698 8 Copyright 700 The following copyright notice is copied from RFC 2026 [Bradner, 701 1996], Section 10.4, and describes the applicable copyright for this 702 document. 704 Copyright (C) The Internet Society July 12, 2001. All Rights 705 Reserved. 707 This document and translations of it may be copied and furnished to 708 others, and derivative works that comment on or otherwise explain it 709 or assist in its implementation may be prepared, copied, published 710 and distributed, in whole or in part, without restriction of any 711 kind, provided that the above copyright notice and this paragraph 712 are included on all such copies and derivative works. However, this 713 document itself may not be modified in any way, such as by removing 714 the copyright notice or references to the Internet Society or other 715 Internet organizations, except as needed for the purpose of 716 developing Internet standards in which case the procedures for 717 copyrights defined in the Internet Standards process must be 718 followed, or as required to translate it into languages other than 719 English. 721 The limited permissions granted above are perpetual and will not be 722 revoked by the Internet Society or its successors or assignees. 724 This document and the information contained herein is provided on an 725 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 726 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 727 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 728 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 729 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 731 9 Intellectual Property 733 The following notice is copied from RFC 2026 [Bradner, 1996], 734 Section 10.4, and describes the position of the IETF concerning 735 intellectual property claims made against this document. 737 The IETF takes no position regarding the validity or scope of any 738 intellectual property or other rights that might be claimed to 739 pertain to the implementation or use other technology described in 740 this document or the extent to which any license under such rights 741 might or might not be available; neither does it represent that it 742 has made any effort to identify any such rights. Information on the 743 IETF's procedures with respect to rights in standards-track and 744 standards-related documentation can be found in BCP-11. Copies of 745 claims of rights made available for publication and any assurances 746 of licenses to be made available, or the result of an attempt made 747 to obtain a general license or permission for the use of such 748 proprietary rights by implementers or users of this specification 749 can be obtained from the IETF Secretariat. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights which may cover technology that may be required to practice 754 this standard. Please address the information to the IETF Executive 755 Director. 757 10 Acknowledgements 759 This draft has benefited from extensive reviews by Tony Hain, Suresh 760 K Satapati, and Margaret Wasserman. 762 11 References 764 [EVAL] Evaluation of Transition Mechanisms for Unmanaged Networks, 765 work in progress. 767 12 Authors' Addresses 769 Christian Huitema 770 Microsoft Corporation 771 One Microsoft Way 772 Redmond, WA 98052-6399 773 Email: huitema@microsoft.com 775 Rob Austein 776 Email: sra@hactrn.net 778 Ronald van der Pol 779 Email: Ronald.vanderPol@surfnet.nl 781 Table of Contents: 783 1 Introduction .................................................... 1 784 2 Topology ........................................................ 1 785 3 Applications .................................................... 2 786 3.1 Local applications ............................................ 2 787 3.2 Client applications ........................................... 3 788 3.3 Peer-to-peer applications ..................................... 3 789 3.4 Server applications ........................................... 3 790 4 Application requirements of an IPv6 unmanaged network ........... 4 791 4.1 Requirements of local applications ............................ 4 792 4.2 Requirements of client applications ........................... 4 793 4.2.1 Privacy requirement of client applications .................. 5 794 4.3 Requirements of peer-to-peer applications ..................... 6 795 4.4 Requirements of server applications ........................... 6 796 5 Stages of IPv6 deployment ....................................... 7 797 5.1 Case A, host deployment of IPv6 applications .................. 7 798 5.1.1 Application support in Case A ............................... 8 799 5.1.2 Addresses and connectivity in Case A ........................ 8 800 5.1.3 Naming services in Case A ................................... 8 801 5.2 Case B, IPv6 connectivity with provider support ............... 9 802 5.2.1 Application support in Case B ............................... 9 803 5.2.2 Addresses and connectivity in Case B ........................ 10 804 5.2.3 Naming services in Case B ................................... 10 805 5.3 Case C, IPv6 connectivity without provider support ............ 11 806 5.3.1 Application support in Case C ............................... 11 807 5.3.2 Addresses and connectivity in Case C ........................ 11 808 5.3.3 Naming services in Case C ................................... 11 809 5.4 Case D, ISP stops providing native IPv4 connectivity .......... 12 810 5.4.1 Application support in Case D ............................... 12 811 5.4.2 Addresses and connectivity in Case D ........................ 13 812 5.4.3 Naming services in Case D ................................... 13 813 6 Security Considerations ......................................... 13 814 7 IANA Considerations ............................................. 14 815 8 Copyright ....................................................... 14 816 9 Intellectual Property ........................................... 14 817 10 Acknowledgements ............................................... 15 818 11 References ..................................................... 15 819 12 Authors' Addresses ............................................. 15