idnits 2.17.1 draft-ietf-v6ops-unmaneval-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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: 'NAT-T' is mentioned on line 135, but not defined == Missing Reference: 'Teredo' is mentioned on line 181, but not defined == Missing Reference: '6to4' is mentioned on line 181, but not defined == Missing Reference: '6To4ANYCAST' is mentioned on line 259, but not defined == Missing Reference: 'RFC3667' is mentioned on line 897, but not defined ** Obsolete undefined reference: RFC 3667 (Obsoleted by RFC 3978) == Unused Reference: '6TO4ANYCAST' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'DHCPV6' is defined on line 807, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3750 (ref. 'UNMANREQ') ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. 'NEIGHBOR') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3068 (ref. '6TO4ANYCAST') (Obsoleted by RFC 7526) ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. 'TUNNELS') ** Obsolete normative reference: RFC 3315 (ref. 'DHCPV6') (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (ref. 'PREFIXDHCPV6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) Summary: 15 errors (**), 0 flaws (~~), 10 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 June 1, 2004 R. Austein 4 Expires December 1, 2004 ISC 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 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance 17 with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 In a companion paper we defined the "unmanaged networks", which 38 typically correspond to home networks or small office networks, and 39 the requirements for transition mechanisms in various scenarios of 40 transition to IPv6. We start from this analysis and evaluate here 41 the suitability of mechanisms that have already been specified, 42 proposed or deployed. 44 Huitema et al. [Page 1] 45 Table of Contents: 47 1 Introduction .................................................... 3 48 2 Evaluation of Tunneling Solutions ............................... 3 49 2.1 Comparing automatic and configured solutions .................. 4 50 2.1.1 Path optimization in automatic tunnels ...................... 4 51 2.1.2 Automatic tunnels and relays ................................ 5 52 2.1.3 The risk of several parallel IPv6 Internets ................. 5 53 2.1.4 Lifespan of transition technologies ......................... 6 54 2.2 Cost and benefits of NAT traversal ............................ 6 55 2.2.1 Cost of NAT traversal ....................................... 7 56 2.2.2 Types of NAT ................................................ 7 57 2.2.3 Reuse of existing mechanisms ................................ 8 58 2.3 Development of transition mechanisms .......................... 8 59 3 Meeting case A requirements ..................................... 9 60 3.1 Evaluation of connectivity mechanisms ......................... 9 61 3.2 Security considerations in case A ............................. 9 62 4 Meeting case B requirements ..................................... 10 63 4.1 Connectivity .................................................. 10 64 4.1.1 Extending a Subnet to Span Multiple Links ................... 10 65 4.1.2 Explicit prefix delegation .................................. 10 66 4.1.3 Recommendation .............................................. 11 67 4.2 Communication between IPv4-only and IPv6-capable nodes ........ 11 68 4.3 Resolution of names to IPv6 addresses ......................... 11 69 4.3.1 Provisioning the address of a DNS resolver .................. 11 70 4.3.2 Publishing IPv6 addresses to the Internet ................... 12 71 4.3.3 Resolving the IPv6 addresses of local hosts ................. 12 72 4.3.4 Recommendations for name resolution ......................... 13 73 4.4 Security considerations in case B ............................. 13 74 5 Meeting case C requirements ..................................... 13 75 5.1 Connectivity .................................................. 13 76 6 Meeting the case D requirements ................................. 14 77 6.1 IPv6 addressing requirements .................................. 14 78 6.2 IPv4 connectivity requirements ............................... 14 79 6.3 Naming requirements ........................................... 14 80 7 Recommendations ................................................. 14 81 8 Security considerations ......................................... 15 82 9 IANA Considerations ............................................. 15 83 10 Acknowledgements ............................................... 16 84 11 References ..................................................... 16 85 12 Authors' Addresses ............................................. 17 86 13 Intellectual Property Statement ................................ 17 87 14 Copyright ...................................................... 18 89 Huitema et al. [Page 2] 90 1 Introduction 92 This document analyses the issues involved in the transition from 93 IPv4 to IPv6 [IPV6]. In a companion paper [UNMANREQ] we defined the 94 "unmanaged networks", which typically correspond to home networks or 95 small office networks, and the requirements for transition 96 mechanisms in various scenarios of transition to IPv6. 98 The requirements for unmanaged networks are expressed by analyzing 99 four classes of applications: local, client, peer to peer, and 100 servers, and considering four cases of deployment. These are: 102 A) a gateway which does not provide IPv6 at all; 103 B) a dual-stack gateway connected to a dual-stack ISP; 104 C) a dual-stack gateway connected to an IPv4-only ISP; and 105 D) a gateway connected to an IPv6-only ISP. 107 During the transition phase from IPv4 to IPv6 there will be IPv4- 108 only, dual-stack or IPv6-only nodes. In this document, we make the 109 hypothesis that the IPv6-only nodes do not need to communicate with 110 IPv4-only nodes; devices that want to communicate with both IPv4 and 111 IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be 112 dual-stack. 114 The issues involved are described in the next sections. This 115 analysis outlines two types of requirements: connectivity 116 requirements, i.e., how to ensure that nodes can exchange IP 117 packets, and naming requirements, i.e., how to ensure that nodes can 118 resolve each-other's names. The connectivity requirements often 119 require tunneling solutions. We devote the first section of this 120 memo to an evaluation of various tunneling solutions. 122 2 Evaluation of Tunneling Solutions 124 In the case A and case C scenarios described in [UNMANREQ], the 125 unmanaged network cannot obtain IPv6 service, at least natively, 126 from its ISP. In these cases, the IPv6 service will have to be 127 provided through some form of tunnel. There have been multiple 128 proposals on different ways to tunnel IPv6 through an IPv4 service. 129 We believe that these proposals can be categorized according to two 130 important properties: 132 * Is the deployment automatic, or does it require explicit 133 configuration or service provisioning? 135 * Does the proposal allow for the traversal of a NAT [NAT-T]? 137 These two questions divide the solution space into four broad 138 classes. Each of these classes has specific advantages and risks, 139 which we will now develop. 141 Huitema et al. [Page 3] 142 2.1 Comparing automatic and configured solutions 144 It is possible to broadly classify tunneling solutions as either 145 "automatic" or "configured". In an automatic solution, a host or a 146 router builds an IPv6 address or an IPv6 prefix by combining a pre- 147 defined prefix with some local attribute, such as local IPv4 address 148 [6TO4] or the combination of an address and a port number [Teredo]. 149 Another typical and very important characteristic of an automatic 150 solution is they aim to work with a minimal amount of support or 151 infrastructure for IPv6 in the local or remote ISPs. 153 In a configured solution, a host or a router identifies itself to a 154 tunneling service to set up a "configured tunnel" with an explicitly 155 defined "tunnel router". The amount of actual configuration may vary 156 from manually configured static tunnels to dynamic tunnel services 157 requiring only the configuration of a "tunnel broker", or even a 158 completely automatic discovery of the tunnel router. 160 Configured tunnels have many advantages over automatic tunnels. The 161 client is explicitly identified and can obtain a stable IPv6 162 address. The service provider is also well identified and can be 163 held responsible for the quality of the service. It is possible to 164 route multicast packets over the established tunnel. There is a 165 clear address delegation path, which enables easy support for 166 reverse DNS lookups. 168 Automatic tunnels generally cannot provide the same level of 169 service. The IPv6 address is only as stable as the underlying IPv4 170 address, the quality of service depends on relays operated by third 171 parties, there is typically no support for multicast, and there is 172 often no easy way to support reverse DNS lookups (although some 173 workarounds are probably possible). However, automatic tunnels have 174 other advantages. They are obviously easier to configure, since 175 there is no need of an explicit relation with a tunnel service. They 176 may also be in some case more efficient, as they allow for "path 177 optimization". 179 2.1.1 Path optimization in automatic tunnels 181 In automatic tunnels like [Teredo] and [6to4], the bulk of the 182 traffic between two nodes using the same technology is exchanged on 183 a direct path between the endpoints, using the IPv4 services to 184 which the endpoints already subscribe. By contrast, the configured 185 tunnel servers carry all the traffic exchanged by the tunnel client. 187 Path optimization is not a big issue if the tunnel server is close 188 to the client, on the natural path between the client and its peers. 189 However, if the tunnel server is operated by a third party, this 190 third party will have to bear the cost of provisioning the bandwidth 191 used by the client. The associated costs can be significant. 193 These costs are largely absent when the tunnels are configured by 195 Huitema et al. [Page 4] 196 the same ISP that provides the IPv4 service. The ISP can place the 197 tunnel end-points close to the client, i.e., mostly on the direct 198 path between the client and its peers. 200 2.1.2 Automatic tunnels and relays 202 The economics arguments related to path optimization favor either 203 configured tunnels provided by the local ISP or automatic tunneling 204 regardless of the co-operation of ISPs. However, automatic solutions 205 require that relays be configured throughout the Internet. If a host 206 that obtained connectivity through an automatic tunnel service wants 207 to communicate with a "native" host or with a host using a 208 configured tunnel, it will need to use a relay service, and someone 209 will have to provide and pay for that service. We cannot escape 210 economic considerations for the deployment of these relays. 212 It is desirable to locate these relays close to the "native host". 213 During the transition period, the native ISPS have an interest in 214 providing a relay service for use by their native subscribers. Their 215 subscribers will enjoy better connectivity, i.e., will be happier. 216 Providing the service does not result in much extra bandwidth 217 requirement: the packets are exchanged between the local subscribers 218 and the Internet; they are simply using a v6-v4 path instead of a 219 v6-v6 path. (The native ISPS do not have an incentive to provide 220 relays for general use; they are expected to restrict access to 221 these relays to their customers.) 223 We should note however that different automatic tunneling techniques 224 have different deployment conditions. 226 2.1.3 The risk of several parallel IPv6 Internets 228 In an early deployment of the Teredo service by Microsoft, the 229 relays are provided by the native (or 6to4) hosts themselves. The 230 native or 6to4 hosts are de-facto "multi-homed" to native and 231 Teredo, although they never publish a Teredo address in the DNS or 232 otherwise. When a native host communicates with a Teredo host, the 233 first packets are exchanged through the native interface and relayed 234 by the Teredo server, while the subsequent packets are tunneled 235 "end-to-end" over IPv4 and UDP. This enables deployment of Teredo 236 without having to field an infrastructure of relays in the network. 238 This type of solution carries the implicit risk of developing two 239 parallel IPv6 Internets, one native and one using Teredo: in order 240 to communicate with a Teredo-only host, a native IPv6 host has to 241 implement a Teredo interface. The Teredo implementations try to 242 mitigate this risk by always preferring native paths when available, 243 but a true mitigation requires that native hosts do not have to 244 implement the transition technology. This requires cooperation from 245 the IPv6 ISP, who will have to support the relays. An IPv6 ISP that 246 really wants to isolate its customers from the Teredo technology can 247 do that by providing native connectivity and a Teredo relay. The 249 Huitema et al. [Page 5] 250 ISP's customers will not need to implement their own relay. 252 Communication between 6to4 networks and native networks uses a 253 different structure. There are two relays, one for each direction of 254 communication. The native host sends its packets through the nearest 255 6to4 router, i.e., the closest router advertising the 2002::/16 256 prefix through the IPv6 routing tables; the 6to4 network sends its 257 packet through a 6to4 relay that is either explicitly configured or 258 discovered through the 6to4 anycast address 192.88.99.1 259 [6To4ANYCAST]. The experience so far is that simple 6to4 routers are 260 easy to deploy, but 6to4 relays are scarce. If there are too few 261 relays, these relays will create a bottleneck. The communications 262 between 6to4 and native networks will be slower than the direct 263 communications between 6to4 hosts. This will create an incentive for 264 native hosts to somehow "multi-home" to 6to4, de facto creating two 265 parallel Internets, 6to4 and native. This risk will only be 266 mitigated if there is a sufficient deployment of 6to4 relays. 268 The configured tunnels solutions do not carry this type of risk. 270 2.1.4 Lifespan of transition technologies 272 A related issue is the lifespan of the transition solutions. Since 273 automatic tunneling technologies enable an automatic deployment, 274 there is a risk that some hosts never migrate out of the transition. 275 The risk is arguably less for explicit tunnels: the ISPS who provide 276 the tunnels have an incentive to replace them with a native solution 277 as soon as possible. 279 Many implementations of automatic transition technologies 280 incorporate an "implicit sunset" mechanism: the hosts will not 281 configure a transition technology address if they have native 282 connectivity; the address selection mechanisms will prefer native 283 addresses when available. The transition technologies will stop 284 being used eventually, when native connectivity has been deployed 285 everywhere. However, the "implicit sunset" mechanism does not 286 provide any hard guarantee that transition will be complete at a 287 certain date. 289 Yet, the support of transition technologies has a cost for the 290 entire network: native IPv6 ISPS have to support relays in order to 291 provide good performance and avoid the "parallel Internet" syndrome. 292 These costs may be acceptable during an initial deployment phase, 293 but they can certainly not be supported for an indefinite period. 294 The "implicit sunset" mechanisms may not be sufficient to guarantee 295 a finite lifespan of the transition. 297 2.2 Cost and benefits of NAT traversal 299 During the transition, some hosts will be located behind IPv4 NATs. 300 In order to participate in the transition, these hosts will have to 301 use a tunneling mechanism designed to traverse NAT. 303 Huitema et al. [Page 6] 304 We may ask whether NAT traversal should be a generic property of any 305 transition technology, or whether it makes sense to develop two 306 types of technologies, some "NAT capable" and some not. An 307 important question is also which kinds of NAT boxes one should be 308 able to traverse. One should probably also consider whether it is 309 necessary to build an IPv6 specific NAT traversal mechanism, or 310 whether it is possible to combine an existing IPv4 NAT traversal 311 mechanism with some form of IPv6 in IPv4 tunneling. There are many 312 IPv4 NAT traversal mechanisms; thus one may ask whether these need 313 re-invention, especially when they are already complex. 315 A related question is whether the NAT traversal technology should 316 use automatic tunnels or configured tunnels. We saw in the previous 317 section that one can argue both sides of this issue. In fact, there 318 are already deployed automatic and configured solutions, so the 319 reality is that we will probably see both. 321 2.2.1 Cost of NAT traversal 323 NAT traversal technologies generally involve encapsulating IPv6 324 packets inside a transport protocol that is known to traverse NAT, 325 such as UDP or TCP. These transport technologies require 326 significantly more overhead than the simple tunneling over IPv4 used 327 in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on 328 UDP require the frequent transmission of "keep alive" packets to 329 maintain a "mapping" in the NAT; solutions based on TCP may not 330 require such mechanism, but they incur the risk of "head of queue 331 blocking", which may translate in poor performance. Given the 332 difference in performance, it makes sense to consider two types of 333 transition technologies, some capable of traversing NAT and some 334 aiming at the best performance. 336 2.2.2 Types of NAT 338 There are many kinds of NAT on the market. Different models 339 implement different strategies for address and port allocations, and 340 also different types of timers. It is desirable to find solutions 341 that cover "almost all" models of NAT. 343 A configured tunnel solution will generally make fewer hypotheses on 344 the behavior of the NAT than an automatic solution. The configured 345 solutions only need to establish a connection between an internal 346 node and a server; this communication pattern is supported by pretty 347 much all NAT configurations. The variability will come from the type 348 of transport protocols that the NAT support, especially when the NAT 349 also implements "firewall" functions. Some models will allow 350 establishment of a single "protocol 41" tunnel, while some may 351 prevent this type of transmission. Some models will allow UDP 352 transmission, while other may only allow TCP, or possibly HTTP. 354 The automatic solutions have to rely on a "lowest common 356 Huitema et al. [Page 7] 357 denominator" that is likely to be accepted by most models of NAT. In 358 practice, this common denominator is UDP. UDP based NAT traversal is 359 required by many applications, e.g., networked games or voice over 360 IP. The experience shows that most recent "home routers" are 361 designed to support these applications. In some edge cases, the 362 automatic solutions will require explicit configuration of a port in 363 the home router, using the so-called "DMZ" functions; however, these 364 functions are hard to use in an "unmanaged network" scenario. 366 2.2.3 Reuse of existing mechanisms 368 NAT traversal is not a problem for IPv6 alone. Many IPv4 369 applications have developed solutions, or kludges, to enable 370 communication across a NAT. 372 Virtual Private Networks are established by installing tunnels 373 between VPN clients and VPN servers. These tunnels are designed 374 today to carry IPv4, but in many cases could easily carry IPv6. For 375 example, the proposed IETF standard, L2TP, includes a PPP layer that 376 can encapsulate IPv6 as well as IPv4. Several NAT models are 377 explicitly designed to pass VPN traffic, and several VPN solutions 378 have special provisions to traverse NAT. When we study the 379 establishment of configured tunnels through NAT, it makes a lot of 380 sense to consider existing VPN solutions. 382 [STUN] is a protocol designed to facilitate the establishment of UDP 383 associations through NAT, by letting nodes behind NAT discover their 384 "external" address. The same function is required for automatic 385 tunneling through NAT, and one could consider reusing the STUN 386 specification as part of an automatic tunneling solution. However, 387 the automatic solutions also require a mechanism of bubbles to 388 establish the initial path through a NAT. This mechanism is not 389 present in STUN. It is not clear that a combination of STUN and a 390 bubble mechanism would have a technical advantage over a solution 391 specifically designed for automatic tunneling through NAT. 393 2.3 Development of transition mechanisms 395 The previous sections make the case for the development of four 396 transition mechanism, covering the following 4 configuration: 398 - Configured tunnel over IPv4 in the absence of NAT; 399 - Automatic tunnel over IPv4 in the absence of NAT; 400 - Configured tunnel across a NAT; 401 - Automatic tunnel across a NAT. 403 Teredo is an example of already designed solution for automatic 404 tunnel across a NAT; 6to4 is an example of solution for automatic 405 tunnel over IPv4 in the absence of NAT. 407 All solutions should be designed to meet generic requirements such 408 as security, scalability, support for reverse name lookup, or simple 410 Huitema et al. [Page 8] 411 management. In particular, automatic tunneling solutions may need to 412 be augmented with a special purpose reverse DNS lookup mechanism, 413 while configured tunnel solutions would benefit from an automatic 414 service configuration mechanism. 416 3 Meeting case A requirements 418 In case A, isolated hosts need to acquire some form of connectivity. 419 In this section, we first evaluate how mechanisms already defined or 420 being worked on in the IETF meet this requirement. We then consider 421 the "remaining holes" and recommend specific developments. 423 3.1 Evaluation of connectivity mechanisms 425 In case A, IPv6 capable hosts seek IPv6 connectivity in order to 426 communicate with applications in the global IPv6 Internet. The 427 connectivity requirement can be met using either configured tunnels 428 or automatic tunnels. 430 If the host is located behind a NAT, the tunneling technology should 431 be designed to traverse NAT; tunneling technologies that do not 432 support NAT traversal can obviously be used if the host is not 433 located behind a NAT. 435 When the local ISP is willing to provide a configured tunnel 436 solution, we should make it easy for the host in case A to use it. 437 The requirements for such a service will be presented in another 438 document. 440 An automatic solution like Teredo appears to be a good fit for 441 providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 442 deployment. The service is designed for minimizing the cost of 443 deploying the server, which matches the requirement of minimizing 444 the cost of the "supporting infrastructure". 446 3.2 Security considerations in case A 448 A characteristic of case A is that an isolated host acquires global 449 IPv6 connectivity, using either Teredo or an alternative tunneling 450 mechanism. If no precaution is taken, there is a risk of exposing to 451 the global Internet some applications and services that only 452 expected to serve local hosts, e.g., those located behind the NAT 453 when a NAT is present. Developers and administrators should make 454 sure that the global IPv6 connectivity is restricted to only those 455 applications that are expressly designed for global Internet 456 connectivity. The users should be able to configure which 457 applications can get IPv6 connectivity to the Internet and which 458 should not. 460 Any solution to the NAT traversal problem is likely to involve 461 relays. There are concerns that improperly designed protocols or 462 improperly managed relays could open new avenues for attacks against 464 Huitema et al. [Page 9] 465 Internet services. This issue should be addressed and mitigated in 466 the design of the NAT traversal protocols and in the deployment 467 guides for relays. 469 4 Meeting case B requirements 471 In case B, we assume that the gateway and the ISP are both dual- 472 stack. The hosts on the local network may be IPv4-only, dual-stack, 473 or IPv6-only. The main requirements are: prefix delegation, and name 474 resolution. We also study the potential need for communication 475 between IPv4 and IPv6 hosts, and conclude that a dual-stack approach 476 is preferable. 478 4.1 Connectivity 480 The gateway must be able to acquire an IPv6 prefix, delegated by the 481 ISP. This can be done through explicit prefix delegation (e.g., 482 DHCPv6), or if the ISP is advertising a /64 prefix on the link, such 483 a link can be extended by the use of ND proxy or a bridge. 485 An ND proxy can also be used to extend a /64 prefix to multiple 486 physical links of different properties (e.g, an Ethernet and a PPP 487 link). 489 4.1.1 Extending a Subnet to Span Multiple Links 491 A /64 subnet can be extended to span multiple physical links using a 492 bridge or ND proxy. Bridges can be used when bridging multiple 493 similar media (mainly, Ethernet segments). On the other hand, ND 494 proxy must be used if a /64 prefix has to be shared across media 495 (e.g., an upstream PPP link and a downstream Ethernet), or if an 496 interface cannot be put into promiscuous mode (e.g., an upstream 497 wireless link). 499 Extending a single subnet to span from the ISP to the all of the 500 unmanaged network is not recommended, and prefix delegation should 501 be used when available. However, sometimes it is unavoidable. In 502 addition, sometimes it's necessary to extend a subnet in the 503 unmanaged network, at the "customer-side" of the gateway, and 504 changing the topology using routing might require too much 505 expertise. 507 The ND proxy method results in the sharing of the same prefix over 508 several links, a procedure generally known as "multi-link subnet". 509 This sharing has effects on neighbor discovery protocols, and 510 possibly also on other protocols such as LLMNR [LLMNR] that rely on 511 "link local multicast". These effects need to be carefully studied. 513 4.1.2 Explicit prefix delegation 515 Several networks have already started using an explicit prefix 516 delegation mechanism using DHCPv6. In this mechanism, the gateway 517 uses a DHCP request to obtain an adequate prefix from a DHCP server 518 managed by the Internet Service Provider. The DHCP request is 519 expected to carry proper identification of the gateway, which 520 enables the ISP to implement prefix delegation policies. It is 521 expected that the ISP assigns a /48 to the customer. The gateway 522 should automatically assign /64s out of this /48 to its internal 523 links. 525 DHCP is insecure unless authentication is used. This may be a 526 particular problem if the link between gateway and ISP is shared by 527 multiple subscribers. DHCP specification includes authentication 528 options, but the operational procedures for managing the keys and 529 methods for sharing the required information between the customer 530 and the ISP are unclear. To be secure in such environment in 531 practice, the practical details of managing the DHCP authentication 532 need to be analyzed. 534 4.1.3 Recommendation 536 The ND proxy and DHCP methods appear to have complementary domains 537 of application. ND proxy is a simple method that corresponds well to 538 "informal sharing" of a link, while explicit delegation provides 539 strong administrative control. Both methods require development: 540 specify the interaction with neighbor discovery for ND proxy; 541 provide security guidelines for explicit delegation. 543 4.2 Communication between IPv4-only and IPv6-capable nodes 545 During the transition phase from IPv4 to IPv6 there will be IPv4- 546 only, dual-stack and IPv6-only nodes. In theory, there may be a need 547 to provide some interconnection services so that IPv4-only and IPv6- 548 only hosts can communicate. However, it is hard to develop a 549 translation service that does not have unwanted side effects on the 550 efficiency or the security of communications. As a consequence, the 551 authors recommend that, if a device has a requirement to communicate 552 with IPv4-only hosts, this device implements an IPv4 stack. The only 553 devices that should only have IPv6 connectivity are those that are 554 intended to only communicate with IPv6 hosts. 556 4.3 Resolution of names to IPv6 addresses 558 There are three types of name resolution services that should be 559 provided in case B: local IPv6 capable hosts must be able to obtain 560 the IPv6 addresses of correspondent hosts on the Internet; they 561 should be able to publish their address if they want to be accessed 562 from the Internet; and they should be able to obtain the IPv6 563 address of other local IPv6 hosts. These three problems are 564 described in the next sections. Operational considerations and 565 issues with IPv6 DNS are analyzed in [DNSOPV6]. 567 4.3.1 Provisioning the address of a DNS resolver 568 In an unmanaged environment, IPv4 hosts usually obtain the address 569 of the local DNS resolver through DHCPv4; the DHCPv4 service is 570 generally provided by the gateway. The gateway will also use DHCPv4 571 to obtain the address of a suitable resolver from the local Internet 572 service provider. 574 The DHCPv4 solution will suffice in practice for the gateway and 575 also for the dual-stack hosts. There is evidence that DNS servers 576 accessed over IPv4 can serve arbitrary DNS records, including AAAA 577 records. 579 Just using DHCPv4 will not be an adequate solution for IPv6-only 580 local hosts. The DHCP working group has defined how to use 581 (stateless) DHCPv6 to obtain the address of the DNS server 582 [DNSDHCPV6]. DHCPv6 and several other possibilities are being looked 583 at in the DNSOP Working Group. 585 4.3.2 Publishing IPv6 addresses to the Internet 587 IPv6 capable hosts may be willing to provide services accessible 588 from the global Internet. They will thus need to publish their 589 address in a server that is publicly available. IPv4 hosts in 590 unmanaged networks have a similar problem today, which they solve 591 using one of three possible solutions: 593 * Manual configuration of a stable address in a DNS server; 594 * Dynamic configuration using the standard dynamic DNS protocol; 595 * Dynamic configuration using an ad hoc protocol. 597 Manual configuration of stable addresses is not satisfactory in an 598 unmanaged IPv6 network: the prefix allocated to the gateway may or 599 may not be stable, and in any case copying long hexadecimal strings 600 through a manual procedure is error prone. 602 Dynamic configuration using the same type of ad hoc protocols that 603 are common today is indeed possible, but the IETF should encourage 604 the use of standard solutions based on Dynamic DNS (DDNS). 606 4.3.3 Resolving the IPv6 addresses of local hosts 608 There are two possible ways of resolving the IPv6 addresses of local 609 hosts: one may either publish the IPv6 addresses in a DNS server for 610 the local domain, or one may use a peer-to-peer address resolution 611 protocol such as LLMNR. 613 When a DNS server is used, this server could in theory be located 614 anywhere on the Internet. There is however a very strong argument 615 for using a local server, which will remain reachable even if the 616 network connectivity is down. 618 The use of a local server requires that IPv6 capable hosts discover 619 this server, as explained in 4.3.1, and then that they use a 620 protocol such as DDNS to publish their IPv6 addresses to this 621 server. In practice, the DNS address discovered in 4.3.1 will often 622 be the address of the gateway itself, and the local server will thus 623 be the gateway. 625 An alternative to using a local server is LLMNR, which uses a 626 multicast mechanism to resolve DNS requests. LLMNR does not require 627 any service from the gateway, and also does not require that hosts 628 use DDNS. An important problem is that some networks only have 629 limited support for multicast transmission: for example, multicast 630 transmission on 802.11 network is error prone. However, unmanaged 631 networks also use multicast for neighbor discovery [NEIGHBOR]; the 632 requirements of ND and LLMNR are similar; if a link technology 633 supports use of ND, it can also enable use of LLMNR. 635 4.3.4 Recommendations for name resolution 637 The IETF should quickly provide a recommended procedure for 638 provisioning the DNS resolver in IPv6-only hosts. 640 The most plausible candidate for local name resolution appears to be 641 LLMNR; the IETF should quickly proceed to the standardization of 642 that protocol. 644 4.4 Security considerations in case B 646 The case B solutions provide global IPv6 connectivity to the local 647 hosts. Removing the limit to connectivity imposed by NAT is both a 648 feature and a risk. Implementations should carefully limit global 649 IPv6 connectivity to only those applications that are specifically 650 designed to operate on the global Internet. Local applications, for 651 example, could be restricted to only use link-local addresses, or 652 addresses whose most significant bits match the prefix of the local 653 subnet, e.g., a prefix advertised as "on link" in a local router 654 advertisement. There is a debate as to whether such restrictions 655 should be "per-site" or "per-link", but this is not a serious issue 656 when an unmanaged network is composed of a single link. 658 5 Meeting case C requirements 660 Case C is very similar to case B, the difference being that the ISP 661 is not dual-stack. The gateway must thus use some form of tunneling 662 mechanism to obtain IPv6 connectivity, and an address prefix. 664 A simplified form of case B is a single host with a global IPv4 665 address, i.e., with a direct connection to the IPv4 Internet. This 666 host will be able to use the same tunneling mechanisms as a gateway. 668 5.1 Connectivity 670 Connectivity in case C requires some form of tunneling of IPv6 over 671 IPv4. The various tunneling solutions are discussed in section 2. 673 The requirements of case C can be solved by an automatic tunneling 674 mechanism such as 6to4 [6TO4]. An alternative may be the use of a 675 configured tunnels mechanism [TUNNELS], but as the local ISP is not 676 IPv6-enabled this may not be feasible. The practical conclusion of 677 our analysis is that "upgraded gateways" will probably support the 678 6to4 technology, and will have an optional configuration option for 679 "configured tunnels". 681 The tunnel broker technology should be augmented, to include support 682 for some form of automatic configuration. 684 Due to concerns with potential overload of public 6to4 relays, the 685 6to4 implementations should include a configuration option that let 686 user take advantage of specific relays. 688 6 Meeting the case D requirements 690 In case D, the ISP only provides IPv6 services. 692 6.1 IPv6 addressing requirements 694 We expect IPv6 addressing in case D to proceed similarly to case B, 695 i.e., use either ND proxy or explicit prefix delegation through 696 DHCPv6 to provision an IPv6 prefix on the gateway. 698 6.2 IPv4 connectivity requirements 700 Local IPv4 capable hosts may want to still access IPv4-only 701 services. The proper way to do this for dual-stack nodes in the 702 unmanaged network is to develop a form of "IPv4 over IPv6" 703 tunneling. There are no standardized solutions and has been very 704 little effort devoted by the IETF to this issue, although there is 705 ongoing work with [DSTM] and [TSP]. A solution needs to be 706 standardized. The standardization will have to cover configuration 707 issues, i.e., how to provision the IPv4 capable hosts with the 708 address of the local IPv4 tunnel servers. 710 6.3 Naming requirements 712 Naming requirements are similar to case B, with one difference: the 713 gateway cannot expect to use DHCPv4 to obtain the address of the DNS 714 resolver recommended by the ISP. 716 7 Recommendations 718 After a careful analysis of the possible solutions, we can list a 719 set of recommendations for the V6OPS working group: 721 1- To meet case A and case C requirements, we need to develop, or 722 continue to develop, four types of tunneling technologies: automatic 723 tunnels without NAT traversal such as [6TO4], automatic tunnels with 724 NAT traversal such as [TEREDO], configured tunnels without NAT 725 traversal such as [TUNNELS, TSP] and configured tunnels with NAT 726 traversal. 728 2- To facilitate the use of configured tunnels, we need a 729 standardized way for hosts or gateways to discover the tunnel server 730 or tunnel broker that may have been configured by the local ISP. 732 3- To meet case B "informal prefix sharing" requirements, we would 733 need a standardized way to perform "ND proxy", possibly as part of a 734 "multi-link subnet" specification. (The explicit prefix delegation 735 can be accomplished through [PREFIXDHCPV6].) 737 4- To meet case B naming requirements we need to proceed with the 738 standardization of LLMNR. (The provisioning of DNS parameters can be 739 accomplished through [DNSDHCPV6].) 741 5- To meet case D IPv4 connectivity requirement, we need to 742 standardize an IPv4 over IPv6 tunneling mechanism, as well as the 743 associated configuration services. 745 8 Security considerations 747 This memo describes the general requirements for transition 748 mechanisms. Specific security issues should be studied and addressed 749 during the development of the specific mechanisms. 751 When hosts which have been behind a NAT are exposed to IPv6, the 752 security assumptions may change radically. This is mentioned in 753 sections 3.2 and 4.4. One way to cope with that is to have a 754 default firewall with NAT-like access configuration; however, any 755 such firewall configuration should allow for easy authorization of 756 those applications that actually need global connectivity. One might 757 also restrict applications which can benefit from global IPv6 758 connectivity on the nodes. 760 Security policies should be consistent between IPv4 and IPv6. A 761 policy which prevents use of v6 while allowing v4 will discourage 762 migration to v6 without significantly improving security. 763 Developers and administrators should make sure that global Internet 764 connectivity through either IPv4 or IPv6 is restricted to only those 765 applications that are expressly designed for global Internet 766 connectivity. 768 Several transition technologies require relays. There are concerns 769 that improperly designed protocols or improperly managed relays 770 could open new avenues for attacks against Internet services. This 771 issue should be addressed and mitigated in the design of the 772 transition technologies and in the deployment guides for relays. 774 9 IANA Considerations 775 This memo does not include any request to IANA. 777 10 Acknowledgements 779 This memo has benefited from comments of Margaret Wasserman, Pekka 780 Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms, Bill 781 Sommerfeld and Fred Templin. Tim Chown provided a lot of the 782 analysis for the tunneling requirements work. 784 11 References 786 Normative references 788 [UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der 789 Pol. "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 790 2004. 792 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 793 (IPv6) Specification", RFC 2460, December 1998. 795 [NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 796 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 798 [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 799 IPv4 Clouds", RFC 3056, February 2001. 801 [6TO4ANYCAST] C. Huitema. "An Anycast Prefix for 6to4 Relay 802 Routers", RFC 3068, June 2001. 804 [TUNNELS] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel 805 Broker. RFC 3053, January 2001 807 [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 808 M. Carney. "Dynamic Host Configuration Protocol for IPv6 809 (DHCPv6)."RFC 3315, July 2003. 811 [DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." RFC 812 3646, December 2003. 814 [PREFIXDHCPV6] Troan, O. and R. Droms. "IPv6 Prefix Options for 815 DHCPv6." RFC 3633, December 2003. 817 Informative references 819 [STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy. "STUN 820 - Simple Traversal of User Datagram Protocol (UDP) Through Network 821 Address Translators (NATs)", RFC 3489, March 2003. 823 [DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational 824 Considerations and Issues with IPv6 DNS." Work in progress. 826 [LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast 827 Name Resolution (LLMNR)." Work in progress. 829 [TSP] M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup 830 Protocol(TSP)". work in progress. 832 [DSTM] J. Bound, "Dual Stack Transition Mechanism". Work in 833 progress. 835 [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs." 836 Work in progress. 838 12 Authors' Addresses 840 Christian Huitema 841 Microsoft Corporation 842 One Microsoft Way 843 Redmond, WA 98052-6399 845 Email: huitema@microsoft.com 847 Rob Austein 848 Internet Systems Consortium 849 950 Charter Street 850 Redwood City, CA 94063 851 USA 853 EMail: sra@isc.org 855 Suresh Satapati 856 Cisco Systems, Inc. 857 San Jose, CA 95134 858 USA 860 EMail: satapati@cisco.com 862 Ronald van der Pol 863 NLnet Labs 864 Kruislaan 419 865 1098 VA Amsterdam 866 NL 868 Email: Ronald.vanderPol@nlnetlabs.nl 870 13 Intellectual Property Statement 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be claimed 874 to pertain to the implementation or use of the technology described 875 in this document or the extent to which any license under such 876 rights might or might not be available; nor does it represent that 877 it has made any independent effort to identify any such rights. 879 Information on the procedures with respect to rights in RFC 880 documents can be found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use 885 of such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository 887 at http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at ietf- 893 ipr@ietf.org. 895 14 Copyright 897 The following copyright notice is copied from [RFC3667], Section 898 5.4. It describes the applicable copyright for this document. 900 Copyright (C) The Internet Society (2004). This document is subject 901 to the rights, licenses and restrictions contained in BCP 78, and 902 except as set forth therein, the authors retain all their rights. 904 This document and the information contained herein are provided on 905 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 906 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 907 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 908 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 909 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR