idnits 2.17.1 draft-ietf-v6ops-unmaneval-01.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 a Security Considerations 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 47 instances of lines with control characters in the document. ** The abstract seems to contain references ([NAT-PT], [TEREDO], [TUNNELS], [DNSOPV6], [IPV6], [DHCPV6], [NAT-T], [PREFIXDHCPV6], [DNSDHCPV6], [6To4ANYCAST], [Bradner,1996], [NEIGHBOR], [UNMANREQ], [6TO4ANYCAST], [LLMNR], [Teredo], [6TO4], [6to4], [STUN]), 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? 'IPV6' on line 769 looks like a reference -- Missing reference section? 'UNMANREQ' on line 765 looks like a reference -- Missing reference section? 'NAT-T' on line 88 looks like a reference -- Missing reference section? '6TO4' on line 775 looks like a reference -- Missing reference section? 'Teredo' on line 131 looks like a reference -- Missing reference section? '6to4' on line 131 looks like a reference -- Missing reference section? '6To4ANYCAST' on line 206 looks like a reference -- Missing reference section? 'STUN' on line 803 looks like a reference -- Missing reference section? 'LLMNR' on line 810 looks like a reference -- Missing reference section? 'DNSOPV6' on line 807 looks like a reference -- Missing reference section? 'DNSDHCPV6' on line 791 looks like a reference -- Missing reference section? 'NEIGHBOR' on line 772 looks like a reference -- Missing reference section? 'TUNNELS' on line 784 looks like a reference -- Missing reference section? 'TEREDO' on line 781 looks like a reference -- Missing reference section? 'PREFIXDHCPV6' on line 794 looks like a reference -- Missing reference section? 'Bradner' on line 731 looks like a reference -- Missing reference section? '1996' on line 731 looks like a reference -- Missing reference section? '6TO4ANYCAST' on line 778 looks like a reference -- Missing reference section? 'DHCPV6' on line 787 looks like a reference -- Missing reference section? 'NAT-PT' on line 799 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 February 4, 2004 R. Austein 4 Expires August 4, 2004 Bourgeois Dilettante 5 S. Satapati 6 Cisco Systems, Inc. 7 R. van der Pol 8 NLnet Labs 10 Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks 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 a companion paper we defined the "unmanaged networks", which 36 typically correspond to home networks or small office networks, and 37 the requirements for transition mechanisms in various scenarios of 38 transition to IPv6. We start from this analysis and evaluate here 39 the suitability of mechanisms that have already been specified, 40 proposed or deployed. 42 1 Introduction 44 This document analyses the issues involved in the transition from 45 IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the 46 "unmanaged networks", which typically correspond to home networks or 47 small office networks, and the requirements for transition 48 mechanisms in various scenarios of transition to IPv6. 50 The requirements for unmanaged networks are expressed by analyzing 51 four classes of application: local, client, peer to peer, and 52 servers, and considering four cases of deployment. These are: 54 Huitema et al. [Page 1] 55 A) a gateway which does not provide IPv6 at all; 56 B) a dual-stack gateway connected to a dual-stack ISP; 57 C) a dual-stack gateway connected to an IPv4-only ISP; and 58 D) a gateway connected to an IPv6-only ISP. 60 During the transition phase from IPv4 to IPv6 there will be IPv4- 61 only, dual-stack or IPv6-only nodes. In this document, we make the 62 hypothesis that the IPv6-only nodes do not need to communicate with 63 IPv4-only nodes; devices that want to communicate with both IPv4 and 64 IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be 65 dual-stack. 67 The issues involved are described in the next sections. This 68 analysis outlines two types of requirements: connectivity 69 requirements, i.e., how to ensure that nodes can exchange IP 70 packets, and naming requirements, i.e., how to ensure that nodes can 71 resolve each-other's names. The connectivity requirements often 72 require tunneling solutions. We devote the first section of this 73 memo to an evaluation of various tunneling solutions. 75 2 Evaluation of Tunneling Solutions 77 In the case A and case C scenarios described in [UNMANREQ], the 78 unmanaged network cannot obtain IPv6 service, at least natively, 79 from its ISP. In these cases, the IPv6 service will have to be 80 provided through some form of tunnel. There have been multiple 81 proposals on different ways to tunnel IPv6 through an IPv4 service. 82 We believe that these proposals can be categorized according to two 83 important properties: 85 * Is the deployment automatic, or does it require explicit 86 configuration or service provisioning? 88 * Does the proposal allow for the traversal of a NAT [NAT-T]? 90 These two questions divide the solution space into four broad 91 classes. Each of these classes has specific advantages and risks, 92 which we will now develop. 94 2.1 Comparing automatic and configured solutions 96 It is possible to broadly classify tunneling solutions as either 97 "automatic" or "configured". In an automatic solution, a host or a 98 router builds an IPv6 address or an IPv6 prefix by combining a pre- 99 defined prefix with some local attribute, such as local IPv4 address 100 [6TO4] or the combination of an address and a port number [Teredo]. 101 Another typical and very important characteristic of an automatic 102 solution is they aim to work with a minimal amount of support or 103 infrastructure for IPv6 in the local or remote ISPs. In a configured 104 solution, a host or a router identifies itself to a tunneling 105 service to set up a "configured tunnel" with an explicitly defined 107 Huitema et al. [Page 2] 108 "tunnel router". 110 Configured tunnels have many advantages over automatic tunnels. The 111 client is explicitly identified and can obtain a stable IPv6 112 address. The service provider is also well identified and can be 113 held responsible for the quality of the service. It is possible to 114 route multicast packets over the established tunnel. There is a 115 clear address delegation path, which enables easy support for 116 reverse DNS lookups. 118 Automatic tunnels generally cannot provide the same level of 119 service. The IPv6 address is only as stable as the underlying IPv4 120 address, the quality of service depends on relays operated by third 121 parties, there is typically no support for multicast, and there is 122 often no easy way to support reverse DNS lookups (although some 123 workarounds are probably possible). However, automatic tunnels have 124 other advantages. They are obviously easier to configure, since 125 there is no need of an explicit relation with a tunnel service. They 126 may also be in some case more efficient, as they allow for "path 127 optimization". 129 2.1.1 Path optimization in automatic tunnels 131 In automatic tunnels like [Teredo] and [6to4], the bulk of the 132 traffic between two nodes using the same technology is exchanged on 133 a direct path between the endpoints, using the IPv4 services to 134 which the endpoints already subscribe. By contrast, the configured 135 tunnel servers carry all the traffic exchanged by the tunnel client. 137 Path optimization is not a big issue if the tunnel server is close 138 to the client, on the natural path between the client and its peers. 139 However, if the tunnel server is operated by a third party, this 140 third party will have to bear the cost of provisioning the bandwidth 141 used by the client. The associated costs can be significant. 143 These costs are largely inexistent when the tunnels are configured 144 by the same ISP that provides the IPv4 service. The ISP can place 145 the tunnel end-points close to the client, i.e., mostly on the 146 direct path between the client and its peers. 148 2.1.2 Automatic tunnels and relays 150 The economics arguments related to path optimization favor either 151 configured tunnels provided by the local ISP or automatic tunneling 152 regardless of the co-operation of ISPs. However, automatic solutions 153 require that relays be configured throughout the Internet. If a host 154 that obtained connectivity through an automatic tunnel service wants 155 to communicate with a "native" host, it will need to use a relay 156 service, and someone will have to provide and pay for that service. 157 We cannot escape economic considerations for the deployment of these 158 relays. 160 Huitema et al. [Page 3] 161 It is desirable to locate these relays close to the "native host". 162 During the transition period, the native ISPS have an interest in 163 providing a relay service for use by their native subscribers. Their 164 subscribers will enjoy better connectivity, i.e., will be happier. 165 Providing the service does not result in much extra bandwidth 166 requirement: the packets are exchanged between the local subscribers 167 and the Internet; they are simply using a v6-v4 path instead of a 168 v6-v6 path. (The native ISP do not have an incentive to provide 169 relays for general use; they are expected to restrict access to 170 these relays to their customers.) 172 We should note however that different automatic tunneling techniques 173 have different deployment conditions. 175 2.1.3 The risk of several parallel IPv6 Internets 177 In an early deployment of the Teredo service by Microsoft, the 178 relays are provided by the native (or 6to4) hosts themselves. The 179 native or 6to4 hosts are de-facto multi-homed to native and Teredo, 180 although they never publish a Teredo address in the DNS or 181 otherwise. When a native host communicates with a Teredo host, the 182 first packets are exchanged through the native interface and relayed 183 by the Teredo server, while the subsequent packets are tunneled 184 "end-to-end" over IPv4 and UDP. This enables deployment of Teredo 185 without having to field an infrastructure of relays in the network. 187 This type of solution carries the implicit risk of developing two 188 parallel IPv6 Internets, one native and one using Teredo: in order 189 to communicate with a Teredo-only host, a native IPv6 host has to 190 implement a Teredo interface. The Teredo implementations try to 191 mitigate this risk by always preferring native paths when available, 192 but a true mitigation requires that native hosts do not have to 193 implement the transition technology. This requires cooperation from 194 the IPv6 ISP, who will have to support the relays. An IPv6 ISP that 195 really wants to isolate its customers from the Teredo technology can 196 do that by providing native connectivity and a Teredo relay. The 197 ISP's customers will not need to implement their own relay. 199 Communication between 6to4 networks and native networks uses a 200 different structure. There are two relays, one for each direction of 201 communication. The native host sends its packets through the nearest 202 6to4 router, i.e., the closest router advertising the 2002::/16 203 prefix through the IPv6 routing tables; the 6to4 network sends its 204 packet through a 6to4 relay that is either explicitly configured or 205 discovered through the 6to4 anycast address 192.88.99.1 206 [6To4ANYCAST]. The experience so far is that simple 6to4 routers are 207 easy to deploy, but 6to4 relays are scarce. If there are too few 208 relays, these relays will create a bottleneck. The communications 209 between 6to4 and native networks will be slower than the direct 210 communications between 6to4 hosts. This will create an incentive for 211 native hosts to somehow "multi-home" to 6to4, de facto creating two 212 parallel Internets, 6to4 and native. This risk will only be 214 Huitema et al. [Page 4] 215 mitigated if there is a sufficient deployment of 6to4 relays. 217 2.1.4 Lifespan of transition technologies 219 A related issue is the lifespan of the transition solutions. Since 220 automatic tunneling technologies enable an automatic deployment, 221 there is a risk that some hosts never migrate out of the transition. 222 The risk is arguably less for explicit tunnels: the ISPS who provide 223 the tunnels have an incentive to replace them with a native solution 224 as soon as possible. 226 Many implementations of automatic transition technologies 227 incorporate an "implicit sunset" mechanism: the hosts will not 228 configure a transition technology address if they have native 229 connectivity; the address selection mechanisms will prefer native 230 addresses when available. The transition technologies will stop 231 being used eventually, when native connectivity has been deployed 232 everywhere. However, the "implicit sunset" mechanism does not 233 provide any hard guarantee that transition will be complete at a 234 certain date. 236 Yet, the support of transition technologies has a cost for the 237 entire network: native IPv6 ISPS have to support relays in order to 238 provide good performance and avoid the "parallel Internet" syndrome. 239 These costs may be acceptable during an initial deployment phase, 240 but they can certainly not be supported for an indefinite period. 241 The "implicit sunset" mechanisms may not be sufficient to guarantee 242 a finite lifespan of the transition. 244 2.2 Cost and benefits of NAT traversal 246 During the transition, some hosts will be located behind IPv4 NATs. 247 In order to participate in the transition, these hosts will have to 248 use a tunneling mechanism designed to traverse NAT. 250 We may ask whether NAT traversal should be a generic property of any 251 transition technology, or whether it makes sense to develop two 252 types of technologies, some "NAT capable" and some not. An 253 important question is also which kinds of NAT boxes one should be 254 able to traverse. One should probably also consider whether it is 255 necessary to build an IPv6 specific NAT traversal mechanism, or 256 whether it is possible to combine an existing IPv4 NAT traversal 257 mechanism with some form of IPv6 in IPv4 tunneling. There are many 258 IPv4 NAT traversal mechanisms; thus one may ask whether these need 259 re-invention, especially when they are already complex. 261 A related question is whether the NAT traversal technology should 262 use automatic tunnels or configured tunnels. We saw in the previous 263 section that one can argue both sides of this issue. In fact, there 264 are already deployed automatic and configured solutions, so the 265 reality is that we will probably see both. 267 Huitema et al. [Page 5] 268 2.2.1 Cost of NAT traversal 270 NAT traversal technologies generally involve encapsulating IPv6 271 packets inside a transport protocol that is known to traverse NAT, 272 such as UDP or TCP. These transport technologies require 273 significantly more overhead than the simple tunneling over IPv4 used 274 in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on 275 UDP require the frequent transmission of "keep alive" packets to 276 maintain a "mapping" in the NAT; solutions based on TCP may not 277 require such mechanism, but they incur the risk of "head of queue 278 blocking", which may translate in poor performances. Given the 279 difference in performance, it makes sense to consider two types of 280 transition technologies, some capable of traversing NAT and some 281 aiming at the best performance. 283 2.2.2 Types of NAT 285 There are many kinds of NAT on the market. Different models 286 implement different strategies for address and port allocations, and 287 also different types of timers. It is desirable to find solutions 288 that cover "almost all" models of NAT. 290 A configured tunnel solution will generally make fewer hypotheses on 291 the behavior of the NAT than an automatic solution. The configured 292 solutions only need to establish a connection between an internal 293 node and a server; this communication pattern is supported by pretty 294 much all NAT configurations. The variability will come from the type 295 of transport protocols that the NAT support, especially when the NAT 296 also implements "firewall" functions. Some models will allow 297 establishment of a single "protocol 41" tunnel, while some may 298 prevent this type of transmission. Some models will allow UDP 299 transmission, while other may only allow TCP, or possibly HTTP. 301 The automatic solutions have to rely on a "lower common denominator" 302 that is likely to be accepted by most models of NAT. In practice, 303 this common denominator is UDP. UDP based NAT traversal is required 304 by many applications, e.g., networked games or voice over IP. The 305 experience shows that most recent "home routers" are designed to 306 support these applications. In some edge cases, the automatic 307 solutions will require explicit configuration of a port in the home 308 router, using the so-called "DMZ" functions. 310 2.2.3 Reuse of existing mechanisms 312 NAT traversal is not a problem for IPv6 alone. Many IPv4 313 applications have developed solutions, or kludges, to enable 314 communication across a NAT. 316 Virtual Private Networks are established by installing tunnels 317 between VPN clients and VPN servers. These tunnels are designed 318 today to carry IPv4, but in many cases could easily carry IPv6. For 319 example, the IETF standard, L2TP, includes a PPP layer that can 321 Huitema et al. [Page 6] 322 encapsulate IPv6 as well as IPv4. Several NAT models are explicitly 323 designed to pass VPN traffic, and several VPN solutions have special 324 provisions to traverse NAT. When we study the establishment of 325 configured tunnels through NAT, it makes a lot of sense to consider 326 existing VPN solutions. 328 [STUN] is a protocol designed to facilitate the establishment of UDP 329 associations through NAT, by letting nodes behind NAT discover their 330 "external" address. The same function is required for automatic 331 tunneling through NAT, and one could consider reusing the STUN 332 specification as part of an automatic tunneling solution. However, 333 the automatic solutions also require a mechanism of bubbles to 334 establish the initial path through a NAT. This mechanism is not 335 present in STUN. It is not clear that a combination of STUN and a 336 bubble mechanism would have a technical advantage over a solution 337 specifically designed for automatic tunneling through NAT. 339 2.3 Development of transition mechanisms 341 The previous sections make the case for the development of four 342 transition mechanism, covering the following 4 configuration: 344 - Configured tunnel over IPv4 in the absence of NAT; 345 - Automatic tunnel over IPv4 in the absence of NAT; 346 - Configured tunnel across a NAT; 347 - Automatic tunnel across a NAT. 349 Teredo is an example of already designed solution for automatic 350 tunnel across a NAT; 6to4 is an example of solution for automatic 351 tunnel over IPv4 in the absence of NAT. 353 All solutions should be designed to meet generic requirements such 354 as security, scalability, support for reverse name lookup, or simple 355 management. In particular, automatic tunneling solutions may need to 356 be augmented with a special purpose reverse DNS lookup mechanism, 357 while configured tunnel solutions would benefit from an automatic 358 service configuration mechanism. 360 3 Meeting case A requirements 362 In case A, isolated hosts need to acquire some form of connectivity. 363 In this section, we first evaluate how mechanisms already defined or 364 being worked on in the IETF meet this requirement. We then consider 365 the "remaining holes" and recommend specific developments. 367 3.1 Evaluation of connectivity mechanisms 369 In case A, IPv6 capable hosts seek IPv6 connectivity in order to 370 communicate with applications in the global IPv6 Internet. The 371 connectivity requirement can be met using either configured tunnels 372 or automatic tunnels. 374 Huitema et al. [Page 7] 375 If the host is located behind a NAT, the tunneling technology should 376 be designed to traverse NAT; tunneling technologies that do not 377 support NAT traversal can obviously be used if the host is not 378 located behind a NAT. 380 When the local ISP is willing to provide a configured tunnel 381 solution, we should make it easy for the host in case A to use it. 383 An automatic solution like Teredo appears to be a good fit for 384 providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 385 deployment. The service is designed for minimizing the cost of 386 deploying the server, which matches the requirement of minimizing 387 the cost of the "supporting infrastructure". 389 3.2 Security considerations in case A 391 A characteristic of case A is that an isolated host acquires global 392 IPv6 connectivity, using either Teredo or an alternative tunneling 393 mechanism. If no precaution is taken, there is a risk of exposing to 394 the global Internet some applications and services that only 395 expected to serve local hosts, e.g., those located behind the NAT 396 when a NAT is present. Developers and administrators should make 397 sure that the global IPv6 connectivity is restricted to only those 398 applications that are expressly designed for global Internet 399 connectivity. The users should be able to configure which 400 applications can get IPv6 connectivity to the Internet and which 401 should not. 403 4 Meeting case B requirements 405 In case B, we assume that the gateway and the ISP are both dual- 406 stack. The hosts on the local network may be IPv4-only, dual-stack, 407 or IPv6-only. The main requirements are: prefix delegation, and name 408 resolution. We also study the potential need for communication 409 between IPv4 and IPv6 hosts, and conclude that a dual-stack approach 410 is preferable. 412 4.1 Connectivity 414 The gateway must be able to acquire an IPv6 prefix, delegated by the 415 ISP. This can be done through explicit prefix delegation (e.g., 416 DHCPv6), or if the ISP is advertising a /64 prefix on the link, such 417 a link can be extended by the use of ND proxy or a bridge. 419 An ND proxy can also be used to extend a /64 prefix to multiple 420 physical links of different properties (e.g, an Ethernet and a PPP 421 link). 423 4.1.1 Extending a Subnet to Span Multiple Links 425 A /64 subnet can be extended to span multiple physical links using a 426 bridge or ND proxy. Bridges can be used when bridging multiple 428 Huitema et al. [Page 8] 429 similar media (mainly, Ethernet segments). On the other hand, ND 430 proxy must be used if a /64 prefix has to be shared across media 431 (e.g., an upstream PPP link and a downstream Ethernet), or if an 432 interface cannot be put into promiscuous mode (e.g., an upstream 433 wireless link). 435 Extending a single subnet to span from the ISP to the all of the 436 unmanaged network is not recommended, and prefix delegation should 437 be used when available. However, sometimes it is unavoidable. In 438 addition, sometimes it's necessary to extend a subnet in the 439 unmanaged network, at the "customer-side" of the gateway, and 440 changing the topology using routing might require too much 441 expertise. 443 The ND proxy method results in the sharing of the same prefix over 444 several links, a procedure generally known as "multi-link subnet". 445 This sharing has effects on neighbor discovery protocols, and 446 possibly also on other protocols such as LLMNR [LLMNR] that rely on 447 "link local multicast". These effects need to be carefully studied. 449 4.1.2 Explicit prefix delegation 451 Several networks have already started using an explicit prefix 452 delegation mechanism using DHCPv6. In this mechanism, the gateway 453 uses a DHCP request to obtain an adequate prefix from a DHCP server 454 managed by the Internet Service Provider. The DHCP request is 455 expected to carry proper identification of the gateway, which 456 enables the ISP to implement prefix delegation policies. It is 457 expected that the ISP assigns a /48 to the customer. The gateway 458 should automatically assign /64s out of this /48 to its internal 459 links. 461 The basic use of DHCP is insecure. This may be a problem if the link 462 between gateway and ISP is shared by multiple subscribers. DHCP 463 specification includes authentication options, but does not describe 464 the task of managing the keys, and how the information would be 465 shared between the customer and the ISP. To be useful in such 466 environment in practice, the practical details of managing the DHCP 467 authentication need to be analyzed. 469 4.1.3 Recommendation 471 The ND proxy and DHCP methods appear to have different domains of 472 application. ND proxy is a simple method that corresponds well to 473 "informal sharing" of a link, while explicit delegation provides 474 strong administrative control. Both methods require development: 475 specify the interaction with neighbor discovery for ND proxy; 476 provide security guidelines for explicit delegation. 478 4.2 Communication between IPv4-only and IPv6-capable nodes 480 During the transition phase from IPv4 to IPv6 there will be IPv4- 482 Huitema et al. [Page 9] 483 only, dual-stack and IPv6-only nodes. In theory, there may be a need 484 to provide some interconnection services so that IPv4-only and IPv6- 485 only hosts can communicate. However, it is hard to develop a 486 translation service that does not have unwanted side effects on the 487 efficiency or the security of communications. As a consequence, the 488 authors recommend that, if a device has a requirement to communicate 489 with IPv4-only hosts, this device implements an IPv4 stack. The only 490 devices that should only have IPv6 connectivity are those that are 491 intended to only communicate with IPv6 hosts. 493 4.3 Resolution of names to IPv6 addresses 495 There are three types of name resolution services that should be 496 provided in case B: local IPv6 capable hosts must be able to obtain 497 the IPv6 addresses of correspondent hosts on the Internet; they 498 should be able to publish their address if they want to be accessed 499 from the Internet; and they should be able to obtain the IPv6 500 address of other local IPv6 hosts. These three problems are 501 described in the next sections. Operational considerations and 502 issues with IPv6 DNS are analyzed in [DNSOPV6]. 504 4.3.1 Provisioning the address of a DNS resolver 506 In an unmanaged environment, IPv4 hosts usually obtain the address 507 of the local DNS resolver through DHCPv4; the DHCPv4 service is 508 generally provided by the gateway. The gateway will also use DHCPv4 509 to obtain the address of a suitable resolver from the local Internet 510 service provider. 512 The DHCPv4 solution will suffice in practice for the gateway and 513 also for the dual-stack hosts. There is evidence that even the 514 simple DNS resolvers present in small gateways can relay arbitrary 515 DNS requests and serve arbitrary DNS records, including AAAA 516 records. 518 Just using DHCPv4 will not be an adequate solution for IPv6-only 519 local hosts. The DHCP working group has defined how to use 520 (stateless) DHCPv6 to obtain the address of the DNS server 521 [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked 522 at in the DNSOP Working Group. 524 4.3.2 Publishing IPv6 addresses to the Internet 526 IPv6 capable hosts may be willing to provide services accessible 527 from the global Internet. They will thus need to document their 528 address in a server that is publicly available. IPv4 hosts in 529 unmanaged networks have a similar problem today, which they solve 530 using one of three possible solutions: 532 * Manual configuration of a stable address in a DNS server; 533 * Dynamic configuration using the standard dynamic DNS protocol; 534 * Dynamic configuration using an ad hoc protocol. 536 Manual configuration of stable addresses is not satisfactory in an 537 unmanaged IPv6 network: the prefix allocated to the gateway may or 538 may not be stable, and in any case copying long hexadecimal strings 539 through a manual procedure is error prone. 541 Dynamic configuration using the same type of ad hoc protocols that 542 are common today is indeed possible, but the IETF should encourage 543 the use of standard solutions based on Dynamic DNS (DDNS). 545 4.3.3 Resolving the IPv6 addresses of local hosts 547 There are two possible ways of resolving the IPv6 addresses of local 548 hosts: one may either publish the IPv6 addresses in a DNS server for 549 the local domain, or one may use a peer-to-peer address resolution 550 protocol such as LLMNR. 552 When a DNS server is used, this server could in theory be located 553 anywhere on the Internet. There is however a very strong argument 554 for using a local server, which will remain reachable even if the 555 network connectivity is down. 557 The use of a local server requires that IPv6 capable hosts discover 558 this server, as explained in 4.3.1, and then that they use a 559 protocol such as DDNS to publish their IPv6 addresses to this 560 server. In practice, the DNS address discovered in 4.3.1 will often 561 be the address of the gateway itself, and the local server will thus 562 be the gateway. 564 An alternative to using a local server is LLMNR, which uses a 565 multicast mechanism to resolve DNS requests. LLMNR does not require 566 any service from the gateway, and also does not require that hosts 567 use DDNS. An important problem is that some networks only have 568 limited support for multicast transmission: for example, multicast 569 transmission on 802.11 network is error prone. However, unmanaged 570 networks also use multicast for neighbor discovery [NEIGHBOR]; the 571 requirements of ND and LLMNR are similar; if a link technology 572 supports use of ND, it can also enable use of LLMNR. 574 4.3.4 Recommendations for name resolution 576 The IETF should quickly provide a recommended procedure for 577 provisioning the DNS resolver in IPv6-only hosts, either by 578 standardizing the proper DHCPv6 subset, or by recommending an 579 alternate convention. 581 The most plausible candidate for local name resolution appears to be 582 LLMNR; the IETF should quickly proceed to the standardization of 583 that protocol. 585 4.4 Security considerations in case B 586 The case B solutions provide global IPv6 connectivity to the local 587 hosts. Removing the limit to connectivity imposed by NAT is both a 588 feature and a risk. Implementations should carefully limit global 589 IPv6 connectivity to only those applications that are specifically 590 designed to operate on the global Internet. Local applications, for 591 example, could be restricted to only use link-local addresses, or 592 addresses whose most significant bits match the prefix of the local 593 subnet, e.g., a prefix advertised as "on link" in a local router 594 advertisement. There is a debate as to whether such restrictions 595 should be "per-site" or "per-link", but this is not a serious issue 596 when an unmanaged network is composed of a single link. 598 5 Meeting case C requirements 600 Case C is very similar to case B, the difference being that the ISP 601 is not dual-stack. The gateway must thus use some form of tunneling 602 mechanism to obtain IPv6 connectivity, and an address prefix. 604 A simplified form of case B occurs is a single host with a global 605 IPv4 address, i.e., with a direct connection to the IPv4 Internet. 606 This host will be able to use the same tunneling mechanisms as a 607 gateway. 609 5.1 Connectivity 611 Connectivity in case C requires some form of tunneling of IPv6 over 612 IPv4. The various tunneling solutions are discussed in section 2. 613 The requirements of case C can be solved by an automatic tunneling 614 mechanism such as 6to4 [6TO4]. An alternative may be the use of a 615 configured tunnels mechanism [TUNNELS], but as the local ISP does is 616 not IPv6-enabled this may not be feasible. The practical conclusion 617 of our analysis is that "upgraded gateways" will probably support 618 the 6to4 technology, and will have an optional configuration option 619 for "configured tunnels". 621 The tunnel broker technology should be augmented, to include support 622 for some form of automatic configuration. 624 Due to concerns with potential overload of public 6to4 relays, the 625 6to4 implementations should include a configuration option that let 626 user take advantage of specific relays. 628 6 Meeting the case D requirements 630 In case D, the ISP only provides IPv6 services. 632 6.1 IPv6 addressing requirements 634 We expect IPv6 addressing in case D to proceed similarly to case B, 635 i.e., use either ND proxy or explicit prefix delegation through 636 DHCPv6 to provision an IPv6 prefix on the gateway. 638 6.2 IPv4 connectivity requirements 640 Local IPv4 capable hosts may want to still access IPv4-only 641 services. The proper way to do this for dual-stack nodes in the 642 unmanaged network is to develop a form of "IPv4 over IPv6" 643 tunneling. This tunneling protocol need to be standardized. Part of 644 the standardization will have to cover configuration issues, i.e., 645 how to provision the IPv4 capable hosts with the address of the 646 local IPv4 tunnel servers. 648 6.3 Naming requirements 650 Naming requirements are similar to case B, with one difference: the 651 gateway cannot expect to use DHCPv4 to obtain the address of the 652 DNS resolver recommended by the ISP. 654 7 Provisional recommendations 656 After a careful analysis of the possible solutions, we can list a 657 set of recommendations for the V6OPS working group: 659 1- To meet case A and case C requirements, we need to develop, or 660 continue to develop, four types of tunneling technologies: automatic 661 tunnels without NAT traversal such as [6TO4], automatic tunnels with 662 NAT traversal such as [TEREDO], configured tunnels without NAT 663 traversal such as [TUNNELS] and configured tunnels with NAT 664 traversal. 666 2- To meet case B "informal prefix sharing" requirements, we would 667 need a standardized way to perform "ND proxy", possibly as part of a 668 "multi-link subnet" specification. (The explicit prefix delegation 669 can be accomplished through [PREFIXDHCPV6].) 671 3- To meet case B naming requirements we need to proceed with the 672 standardization of LLMNR. (The provisioning of DNS parameters can be 673 accomplished through [DNSDHCPV6].) 675 4- To meet case D IPv4 connectivity requirement, we need to 676 standardize an IPv4 over IPv6 tunneling mechanism, as well as the 677 associated configuration services. 679 8 Security considerations 681 This memo describes the general requirements for transition 682 mechanisms. Specific security issues should be studied and addressed 683 during the development of the specific mechanisms. 685 When hosts which have been behind a NAT are exposed to IPv6, the 686 security assumptions may change radically. This is mentioned in 687 sections 3.2 and 4.4. One way to cope with that is to have a 688 default firewall with NAT-like access configuration; one might also 689 restrict applications which can benefit from global IPv6 690 connectivity on the nodes. 692 9 IANA Considerations 694 This memo does not include any request to IANA. 696 10 Copyright 698 The following copyright notice is copied from RFC 2026 [Bradner, 699 1996], Section 10.4, and describes the applicable copyright for this 700 document. 702 Copyright (C) The Internet Society June 3, 2003. All Rights 703 Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it 707 or assist in its implementation may be prepared, copied, published 708 and distributed, in whole or in part, without restriction of any 709 kind, provided that the above copyright notice and this paragraph 710 are included on all such copies and derivative works. However, this 711 document itself may not be modified in any way, such as by removing 712 the copyright notice or references to the Internet Society or other 713 Internet organizations, except as needed for the purpose of 714 developing Internet standards in which case the procedures for 715 copyrights defined in the Internet Standards process must be 716 followed, or as required to translate it into languages other than 717 English. 719 The limited permissions granted above are perpetual and will not be 720 revoked by the Internet Society or its successors or assignees. 722 This document and the information contained herein is provided on an 723 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 724 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 725 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 726 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 727 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 729 11 Intellectual Property 731 The following notice is copied from RFC 2026 [Bradner, 1996], 732 Section 10.4, and describes the position of the IETF concerning 733 intellectual property claims made against this document. 735 The IETF takes no position regarding the validity or scope of any 736 intellectual property or other rights that might be claimed to 737 pertain to the implementation or use other technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; neither does it represent that it 740 has made any effort to identify any such rights. Information on the 741 IETF's procedures with respect to rights in standards-track and 742 standards-related documentation can be found in BCP-11. Copies of 743 claims of rights made available for publication and any assurances 744 of licenses to be made available, or the result of an attempt made 745 to obtain a general license or permission for the use of such 746 proprietary rights by implementers or users of this specification 747 can be obtained from the IETF Secretariat. 749 The IETF invites any interested party to bring to its attention any 750 copyrights, patents or patent applications, or other proprietary 751 rights which may cover technology that may be required to practice 752 this standard. Please address the information to the IETF Executive 753 Director. 755 12 Acknowledgements 757 This memo has benefited from comments of Margaret Wasserman, Pekka 758 Savola, Chirayu Patel and Tony Hain. Tim Chown provided a lot of the 759 analysis for the tunneling requirements work. 761 13 References 763 Normative references 765 [UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der 766 Pol. "Unmanaged Networks IPv6 Transition Scenarios", Work in 767 progress. 769 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 770 (IPv6) Specification", RFC 2460, December 1998. 772 [NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 773 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 775 [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 776 IPv4 Clouds", RFC 3056, February 2001. 778 [6TO4ANYCAST] C. Huitema. "An Anycast Prefix for 6to4 Relay 779 Routers", RFC 3068, June 2001. 781 [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs." 782 Work in progress. 784 [TUNNELS] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel 785 Broker. RFC 3053, January 2001 787 [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 788 M. Carney. "Dynamic Host Configuration Protocol for IPv6 789 (DHCPv6)."RFC 3315, July 2003. 791 [DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." RFC 792 3646, December 2003. 794 [PREFIXDHCPV6] Troan, O. and R. Droms. "IPv6 Prefix Options for 795 DHCPv6." RFC 3633, December 2003. 797 Informative references 799 [NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address 800 Translation - Protocol Translation (NAT-PT)." RFC 2766, February 801 2000. 803 [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN 804 - Simple Traversal of User Datagram Protocol (UDP) Through Network 805 Address Translators (NATs)", RFC 3489, March 2003. 807 [DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational 808 Considerations and Issues with IPv6 DNS." Work in progress. 810 [LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast 811 Name Resolution (LLMNR)." Work in progress. 813 14 Authors' Addresses 815 Christian Huitema 816 Microsoft Corporation 817 One Microsoft Way 818 Redmond, WA 98052-6399 819 Email: huitema@microsoft.com 821 Rob Austein 822 Email: sra@hactrn.net 824 Suresh Satapati 825 Cisco Systems, Inc. 826 San Jose, CA 95134 827 USA 828 EMail: satapati@cisco.com 830 Ronald van der Pol 831 NLnet Labs 832 Kruislaan 419 833 1098 VA Amsterdam 834 NL 835 Email: Ronald.vanderPol@nlnetlabs.nl 837 Table of Contents: 839 1 Introduction .................................................... 1 840 2 Evaluation of Tunneling Solutions ............................... 2 841 2.1 Comparing automatic and configured solutions .................. 2 842 2.1.1 Path optimization in automatic tunnels ...................... 3 843 2.1.2 Automatic tunnels and relays ................................ 3 844 2.1.3 The risk of several parallel IPv6 Internets ................. 4 845 2.1.4 Lifespan of transition technologies ......................... 5 846 2.2 Cost and benefits of NAT traversal ............................ 5 847 2.2.1 Cost of NAT traversal ....................................... 6 848 2.2.2 Types of NAT ................................................ 6 849 2.2.3 Reuse of existing mechanisms ................................ 6 850 2.3 Development of transition mechanisms .......................... 7 851 3 Meeting case A requirements ..................................... 7 852 3.1 Evaluation of connectivity mechanisms ......................... 7 853 3.2 Security considerations in case A ............................. 8 854 4 Meeting case B requirements ..................................... 8 855 4.1 Connectivity .................................................. 8 856 4.1.1 Extending a Subnet to Span Multiple Links ................... 8 857 4.1.2 Explicit prefix delegation .................................. 9 858 4.1.3 Recommendation .............................................. 9 859 4.2 Communication between IPv4-only and IPv6-capable nodes ........ 9 860 4.3 Resolution of names to IPv6 addresses ......................... 10 861 4.3.1 Provisioning the address of a DNS resolver .................. 10 862 4.3.2 Publishing IPv6 addresses to the Internet ................... 10 863 4.3.3 Resolving the IPv6 addresses of local hosts ................. 11 864 4.3.4 Recommendations for name resolution ......................... 11 865 4.4 Security considerations in case B ............................. 11 866 5 Meeting case C requirements ..................................... 12 867 5.1 Connectivity .................................................. 12 868 6 Meeting the case D requirements ................................. 12 869 6.1 IPv6 addressing requirements .................................. 12 870 6.2 IPv4 connectivity requirements ............................... 13 871 6.3 Naming requirements ........................................... 13 872 7 Provisional recommendations ..................................... 13 873 8 Security considerations ......................................... 13 874 9 IANA Considerations ............................................. 14 875 10 Copyright ...................................................... 14 876 11 Intellectual Property .......................................... 14 877 12 Acknowledgements ............................................... 15 878 13 References ..................................................... 15 879 14 Authors' Addresses ............................................. 16