idnits 2.17.1 draft-huitema-v6ops-unmaneval-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 45 instances of lines with control characters in the document. ** The abstract seems to contain references ([IPV6], [TUNNELS], [TEREDO], [DSTM], [NATPTISSUES], [PREFIXDHCPV6], [DNSDHCPV6], [NATPTBISSUES], [Bradner,1996], [NEIGHBOR], [UNMANREQ], [6TO4ANYCAST], [STATELESS], [LLMNR], [6TO4], [RFC3056], [DNSANYCAST]), 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? 'UNMANREQ' on line 603 looks like a reference -- Missing reference section? 'NATPTISSUES' on line 69 looks like a reference -- Missing reference section? 'TEREDO' on line 623 looks like a reference -- Missing reference section? 'PREFIXDHCPV6' on line 629 looks like a reference -- Missing reference section? 'NATPTBISSUES' on line 605 looks like a reference -- Missing reference section? 'DNSDHCPV6' on line 631 looks like a reference -- Missing reference section? 'DNSANYCAST' on line 633 looks like a reference -- Missing reference section? 'LLMNR' on line 636 looks like a reference -- Missing reference section? '6TO4' on line 617 looks like a reference -- Missing reference section? 'RFC3056' on line 405 looks like a reference -- Missing reference section? 'TUNNELS' on line 626 looks like a reference -- Missing reference section? 'DSTM' on line 638 looks like a reference -- Missing reference section? 'Bradner' on line 572 looks like a reference -- Missing reference section? '1996' on line 572 looks like a reference -- Missing reference section? 'IPV6' on line 608 looks like a reference -- Missing reference section? 'NEIGHBOR' on line 611 looks like a reference -- Missing reference section? 'STATELESS' on line 614 looks like a reference -- Missing reference section? '6TO4ANYCAST' on line 620 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 February 14, 2003 R. Austein 4 Expires August 14, 2003 Bourgeois Dilettante 5 S. Satapati 6 Cisco Systems, Inc. 7 Ronald van der Pol 8 NLnet Labs 10 Evaluation of 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" scope, 36 which typically correspond to home networks or small office 37 networks, and the requirements for IPv6 transition mechanism in that 38 scope. We start from this analysis and evaluate here the suitability 39 of mechanisms defined in the NGTRANS working group. 41 1 Introduction 43 In a companion paper [UNMANREQ] we defined the "unmanaged networks" 44 scope, which typically correspond to home networks or small office 45 networks, and the requirements for IPv6 transition mechanism in that 46 scope. We start from this analysis and evaluate here the suitability 47 of mechanisms defined in the NGTRANS working group. 49 The requirements for unmanaged networks are expressed by analyzing 50 four classes of application: local, client, peer to peer, and 51 servers, and considering four cases of deployment. These are: 53 A) Gateway does not provide IPv6 55 Huitema et al. [Page 1] 56 B) ISP and gateway are dual stack 57 C) Gateway is IPv6 capable, dual stack, ISP is not 58 D) ISP is IPv6 only 60 This document analyses the issues involved in the transition from 61 IPv4 to IPv6. 63 During the transition phase from IPv4 to IPv6 there will be IPv4 64 only, dual stack or IPv6 only nodes. In this document, we make the 65 hypothesis that the IPv6 only nodes do not need to communicate with 66 IPv4 only nodes; devices that want to communicate with both IPv4 and 67 IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be 68 dual stack. This issue is discussed in detail in a companion paper 69 [NATPTISSUES]. 71 The issues involved are described in the next sections. This 72 analysis outlines two types of requirement: connectivity 73 requirements, i.e. how to ensure that nodes can exchange IP packets, 74 and naming requirements, i.e. how to ensure that nodes can resolve 75 each-other's names. We also consider the specific security issues 76 that arise during the transition. 78 2 Meeting case A requirements 80 In case A, IPv6 capable hosts located behind a NAT need to acquire 81 IPv6 connectivity. In this section, we first evaluate how mechanisms 82 already defined or being worked on in the IETF meet this 83 requirement. We then consider the "remaining holes" and recommend 84 specific developments. 86 2.1 Evaluation of connectivity mechanisms 88 In case A, IPv6 capable hosts seek IPv6 connectivity in order to 89 participate with applications in the global IPv6 Internet. The 90 connectivity requirement can be met in two ways: Teredo [TEREDO], or 91 UDP tunnels. 93 2.1.1 TEREDO 95 TEREDO is a mechanism designed to provide IPv6 connectivity to hosts 96 behind NATs. Hosts use servers to find out a "mapped" IPv4 address 97 and UDP port; they build an IPv6 address that includes the IPv4 98 address of their preferred server, and their own mapped IPv4 address 99 and mapped port. A mechanism of bubbles, relayed by the servers, is 100 used for establishing contacts between Teredo nodes, or for 101 discovering the appropriate Teredo relay serving an IPv6 peer; the 102 actual IPv6 packets are carried in UDP packets exchanged directly 103 between the nodes, or exchanged through the relay serving an IPv6 104 peer. 106 2.1.2 Simple UDP tunnel 108 Huitema et al. [Page 2] 109 An alternative to TEREDO is to simply establish a tunnel to a 110 "tunnel broker" outside the unmanaged network; in order to traverse 111 the NAT, the IPv6 packets would be carried over UDP. This solution 112 is mentioned as a possible alternative to the bubble mechanism in 113 the TEREDO specification. 115 2.1.3 Comparison of TEREDO and tunnel solution 117 The TEREDO and tunnel solutions differ in terms of complexity and 118 operation. 120 A first difference is the cost of operating the server. TEREDO is 121 designed to minimize the amount of traffic flowing through the 122 server, which only processes small bubbles and never relays traffic; 123 on the other hand, a tunnel server will relay all the packets going 124 to and from the Teredo host. This implies a very different amount of 125 traffic. 127 To gauge the difference, we consider the case of a host engaging in 128 Voice over IP: it will maintain its address reachable all the time, 129 and it will send a large amount of traffic whenever it is engaged in 130 a conversation. According to classic figures collected by AT&T, the 131 average duration of a conversation is around 100 seconds, and a 132 business telephone is likely to be engaged in a conversation about 133 10% of the time, which implies starting a conversation on average 134 every 1000 seconds. The average load sent by a tunnel client to the 135 tunnel server will be 10% of the average data rate of the client; 136 assuming a 16kbps codec and 50 packets per second, the data rate of 137 the client sums up to about 51 kbps, hence an average load on the 138 tunnel server of 5 kbps. The load sent by the tunnel client to the 139 tunnel server will be about one exchange of bubble per minute, to 140 defend the address, plus one bubble exchange at the beginning of 141 each session with a new peer; adding all headers, the bubble size is 142 about 144 bytes, which results in about 20 bps of traffic on the 143 server. In short, the amount of traffic seen by the Teredo server is 144 250 times less that the traffic seen by a Teredo client. 146 The tunnel approach is more expensive to provide, because the tunnel 147 server will have to carry a much larger amount of traffic. It is 148 unclear that a tunnel service can be provided as an almost free 149 "supporting infrastructure", except perhaps if the service was 150 directly provided by the same ISP that already provides IPv4 151 connectivity to the unmanaged network. 153 The two approaches have much in common: both need to parameterize a 154 client with the name of a server and with sufficient credentials; 155 the encapsulation is similar; both use the same encapsulation 156 mechanism; and both will use router solicitations to obtain an 157 address prefix. The main difference is the handling of bubbles in 158 Teredo, which are used to defend the address and to initiate 159 sessions with peers. This is obviously more complex than sending the 160 packet without any processing, but the complexity is only marginally 162 Huitema et al. [Page 3] 163 higher than the discovery of link layer addresses using neighbor 164 discovery. In short, Teredo is more complex, but the complexity is 165 not overwhelming. 167 An advantage of the tunnel server approach over Teredo is that it 168 will work regardless of the type and number of NAT between the 169 client and the tunnel server. In contrast, Teredo will not work 170 across a "symmetric" NAT, and communication may be impossible 171 between two Teredo clients located behind the same NAT. 173 Another potential advantage of the tunnel server approach is that it 174 could provide clients with stable IPv6 addresses. This is only a 175 potential advantage, since the server may prefer to delegate 176 addresses on a session per session basis, or may want to operate in 177 a stateless manner. 179 2.1.4 Recommendation 181 Teredo appears to be a good fit for providing IPv6 connectivity to 182 hosts behind NAT, in case A of IPv6 deployment. The service is 183 designed for minimizing the cost of deploying the server, which 184 matches the requirement of minimizing the cost of the "supporting 185 infrastructure" for peer-to-peer applications. 187 There are two situations in which a tunnel service makes more sense: 188 when the cost of bandwidth is not a concern, and when the unmanaged 189 network is located behind a symmetric NAT. In these two cases, using 190 a tunnel service is preferred over using Teredo. 192 The most reasonable solution would be to develop a tunnel service 193 specification that is compatible with Teredo, so that a given host 194 could be configured to use either Teredo or the tunnel service, 195 depending on the server configured in the dual stack host. 197 2.2 Security considerations in case A 199 A characteristic of case A is that a host located behind a NAT 200 acquires global IPv6 connectivity, using either Teredo or an 201 alternative tunneling mechanism. If no precaution is taken, there is 202 a risk of exposing to the global Internet some applications and 203 services that are only expected to serve local hosts, located behind 204 the NAT. Developers and administrators should make sure that the 205 global IPv6 connectivity is restricted to only those applications 206 that are expressly designed for global Internet connectivity. 208 3 Meeting case B requirements 210 In case B, we assume that the gateway and the ISP are both dual 211 stack. The hosts on the local network may be IPv4 only, dual stack, 212 or IPv6 only. The main requirements are: prefix delegation, and name 213 resolution. We also study the potential need for communication 214 between IPv4 and IPv6 hosts, and conclude that a dual stack approach 216 Huitema et al. [Page 4] 217 is preferable. 219 3.1 Prefix delegation 221 The gateway must be able to acquire an IPv6 prefix, delegated by the 222 ISP. The possible mechanisms are RA proxy and explicit prefix 223 delegation. 225 3.1.1 RA proxy 227 The implicit delegation mechanism assumes that the gateway is 228 connected to the ISP by a point-to-point link. Examples of such 229 point to point links are various types of configured tunnels and 230 serial links, for example using PPP. The principle of RA proxy is 231 simple: the gateway issues a "router solicitation" message on the 232 serial link, receives a "router advertisement", learns a network 233 prefix from the advertisement, and advertises the same prefix on the 234 unmanaged network. 236 The RA proxy method results in the sharing of the same prefix over 237 several links, a procedure generally known as "multi-link subnet". 238 This sharing has effects on neighbor discovery protocols, and 239 possibly also on other protocols such as LLMNR that rely on "link 240 local multicast". These effects need to be carefully studied. 242 3.1.2 Explicit prefix delegation 244 Several networks have already started using an explicit prefix 245 delegation mechanism using DHCPv6 [PREFIXDHCPV6]. In this mechanism, 246 the gateway uses a DHCP request to obtain an adequate prefix from a 247 DHCP server managed by the Internet Service Provider. The DHCP 248 request is expected to carry proper identification of the gateway, 249 which enables the ISP to implement prefix delegation policies. 251 The basic use of DHCP is insecure. This may be a problem if the link 252 between gateway and ISP is shared by multiple subscribers. In that 253 case, some security procedure will have to be used, to ensure at a 254 minimum that DHCP requests and replies are properly authenticated. 256 3.1.3 Recommendation 258 The RA proxy and DHCP methods appear to have different domains of 259 application. RA proxy is a simple method that corresponds well to 260 "informal sharing" of a link, while explicit delegation provides 261 strong administrative control. Both methods require development: 262 specify the interaction with neighbor discovery for RA proxy; 263 provide security guidelines for explicit delegation. Proceeding with 264 standardization of at least one method, and preferably both, is 265 quite urgent. 267 3.2 Communication between IPv4-only and IPv6-only hosts 269 Huitema et al. [Page 5] 270 During the transition phase from IPv4 to IPv6 there will be IPv4- 271 only, dual stack and IPv6-only nodes. In theory, there may be a need 272 to provide some interconnection services so that IPv4-only and IPv6- 273 only hosts can communicate. However, as indicated in a companion 274 document [NATPTBISSUES], it is hard to develop a translation service 275 that does not have unwanted side effects on the efficiency or the 276 security of communications. As a consequence, the authors recommend 277 that, if a device has a requirement to communicate with IPv4 only 278 hosts, this device implements an IPv4 stack. The only devices that 279 should only have IPv6 connectivity are those that are intended to 280 only communicate with IPv6 hosts. 282 3.3 Resolution of names to IPv6 addresses 284 There are three types of name resolution services that should be 285 provided in case B: local IPv6 capable hosts must be able to obtain 286 the IPv6 addresses of correspondent hosts on the Internet; they 287 should be able to publish their address if they want to be accessed 288 from the Internet; and they should be able to obtain the IPv6 289 address of other local IPv6 hosts. These three problems are 290 described in the next sections. 292 3.3.1 Provisioning the address of a DNS resolver 294 In an unmanaged environment, IPv4 hosts usually obtain the address 295 of the local DNS resolver through DHCPv4; the DHCPv4 service is 296 generally provided by the gateway. The gateway will also use DHCPv4 297 to obtain the address of a suitable resolver from the local Internet 298 service provider. 300 The DHCPv4 solution will suffice in practice for the gateway and 301 also for the dual stack hosts. There is evidence that even the 302 simple DNS resolvers present in small gateways can relay arbitrary 303 DNS request and serve arbitrary DNS records, including AAAA records. 305 Just using DHCPv4 will not be an adequate solution for IPv6 only 306 local hosts. Three solutions have been envisaged for these hosts: 307 either using DHCPv6 to obtain the address of the DNS server 308 [DNSDHCPV6]; sending the DNS requests to a well known IPv6 address 309 [DNSANYCAST]; or sending the DNS requests to the IPv6 address of the 310 gateway itself. 312 3.3.2 Publishing IPv6 addresses to the Internet 314 IPv6 capable hosts may be willing to provide services accessible 315 from the global Internet. They will thus need to document their 316 address in a server that is publicly available. IPv4 hosts in 317 unmanaged networks have a similar problem today, which they solve 318 using one of three possible solutions: 320 * Manual configuration of a stable address in a DNS server; 321 * Dynamic configuration using the standard dynamic DNS protocol; 323 Huitema et al. [Page 6] 324 * Dynamic configuration using an ad hoc protocol. 326 Manual configuration of stable addresses is not satisfactory in an 327 unmanaged IPv6 network: the prefix allocated to the gateway may or 328 may not be stable, and in any case copying long binary addresses 329 through a manual procedure is error prone. 331 Dynamic configuration using the same type of ad hoc protocols that 332 are common today is indeed possible, but the IETF should encourage 333 the use of standard solutions based on DDNS. 335 3.3.3 Resolving local IPv6 addresses 337 There are two possible ways of resolving local IPv6 addresses: one 338 may either publish the IPv6 addresses in a local server, or one may 339 use a peer-to-peer address resolution protocol such as link local 340 multicast name resolution [LLMNR]. 342 The use of a local server requires that IPv6 capable hosts discover 343 this server, as explained in 3.3.1, and then that they use a 344 protocol such as DDNS to publish their IPv6 addresses to this 345 server. In practice, the DNS address discovered in 3.3.1 will often 346 be the address of the gateway itself, and the local server will thus 347 be the gateway. Implementing a dynamic DNS server on the gateway may 348 be problematic, as many of these gateways are very small devices 349 with limited memory and limited processing power. 351 An alternative to using a local server is LLMNR, which uses a 352 multicast mechanism to resolve DNS requests. LLMNR does not require 353 any service from the gateway, and also does not require that hosts 354 use DDNS. LLMNR relies on multicast for its operation. There are 355 scaling issues with using multicast, as the procedure may become 356 very chatty in large networks; but this is not a practical problem 357 in most unmanaged networks. A more important problem is that some 358 networks only have limited support for multicast transmission: for 359 example, multicast transmission on 802.11 network is error prone. 360 However, unmanaged networks also use multicast for neighbor 361 discovery; the requirements of ND and LLMNR are similar; if a link 362 technology supports use of ND, it will also enable use of LLMNR. 364 3.3.4 Recommendations for name resolution 366 The IETF should quickly provide a recommended procedure for 367 provisioning the DNS resolver in IPv6 only hosts, either by 368 standardizing the proper DHCPv6 subset, or by recommending an 369 alternate convention. 371 The most plausible candidate for local name resolution appears to be 372 LLMNR; the IETF should quickly proceed to the standardization of 373 that protocol. 375 3.4 Security considerations for case B 377 Huitema et al. [Page 7] 378 The case B solutions provide global IPv6 connectivity to the local 379 hosts. Removing the limit to connectivity imposed by NAT is both a 380 feature and a risk. Implementations should carefully limit global 381 IPv6 connectivity to only those applications that are specifically 382 designed to operate on the global Internet. 384 4 Meeting case C requirements 386 Case C is very similar to case B, the difference being that the ISP 387 is not dual stack. The gateway must thus use some form of tunneling 388 mechanism to obtain IPv6 connectivity, and an address prefix. 390 4.1 Tunneling mechanisms 392 4.1.1 6to4 394 The [6TO4] technology allows routers to derive a global scope IPv6 395 prefix from a global IPv4 address. This technology is a very good 396 fit for the second phase of the transition, as it can be programmed 397 in the "upgraded gateway", and can provide value to the gateway 398 users without requiring explicit support from the ISP. This 399 technology has however a clear limitation: it requires that the 400 gateway obtains at least one global IPv4 address from the local ISP. 402 Another potential limitation of the technology is the reliance on 403 publicly accessible "6to4 relay routers" that accept packets from 404 6to4 routers and relay them to the "regular" IPv6 Internet. These 405 relays all listen to the same IPv4 anycast address [RFC3056], which 406 enables gateways to start operating as 6to4 routers without 407 requiring any explicit configuration. As the deployment of IPv6 408 progresses, a growing fraction of the traffic originating from 6to4 409 routers will have to be carried through these relays, potentially 410 leading to severe congestion of the relays. 412 There are three possible ways to alleviate this congestion. First, 413 one can hope that many actors will deploy 6to4 relay routers, in 414 order to facilitate the deployment of IPv6; congestion would be 415 alleviated by the provision of a large number of gateways. Second, 416 one could develop some "route optimization" process, so that the 417 traffic would flow through a "shortcut path" rather than through the 418 6to4 relays; the relays would then avoid congestion by carrying only 419 a small fraction of the traffic. Third, if neither the first nor the 420 second solution materializes, some gateways may enter into 421 contractual agreements with relay service providers; in this case, 422 the 6to4 technology would become merely a variant of the configured 423 tunnel technologies. 425 4.1.2 Tunnel broker 427 Configured tunnels require a contractual agreement with an IPv6 428 provider, which comes in addition to the existing agreement with the 430 Huitema et al. [Page 8] 431 IPv4 provider; different technologies have different domains of 432 application: 434 - Many tunnel technologies use a global IPv4 address to identify the 435 "client end" of the tunnel, thus inheriting the same "global IPv4 436 address" requirement as 6TO4; 438 - A variant of the [TEREDO] technology could be used to establish 439 tunnels over UDP when the client is behind a NAT; this variant is 440 however not standardized. 442 - Practical deployment of tunnel technologies requires the 443 introduction of accounting/billing functions; the existing tunnel 444 broker specification, [TUNNELS], does not describe how these 445 functions should be implemented. (The use of public relays in the 446 6to4 technology may raise a similar issue.) 448 Configured tunnels are in practice an intermediate solution between 449 the "automatic configuration" provided by 6to4, and the "ISP 450 support" that characterizes case B. 452 4.1.3 Recommendations 454 The practical conclusion of the previous analysis is that "upgraded 455 gateways" will probably support the 6TO4 technology, and will have 456 an optional configuration option for "configured tunnels". 458 The tunnel broker technology should be augmented, to include support 459 for accounting and billing functions. 461 Due to concerns with potential overload of public 6to4 relays, the 462 6to4 implementations should include a configuration option that let 463 user take advantage of specific relays. 465 4.2 Security considerations 467 Providing local hosts with global IPv6 connectivity raises the same 468 issues in case C as in case B. Discussions in the V6OPS working 469 group have also raised a potential security concern with the 6to4 470 solution: an attacker can send a packet with a spoofed IPv6 address 471 to a host on the unmanaged network; the host will reply to the 472 source address; the reply traffic will be hard to trace back to the 473 original attacker. 475 This attack is only an additional vulnerability if IPv4 source 476 addresses cannot be spoofed; there is thus a debate between those 477 who believe that we will eventually make IPv4 addresses hard to 478 spoof, and those who believe that this goal will never be achieved. 479 Actually thwarting the attack would require a slight addition to the 480 6to4 specification: 6to4 routers that forward a encapsulated packet 481 to a native IPv6 network should implement a form of "traceback" 482 mechanism. 484 Huitema et al. [Page 9] 485 5 Meeting the case D requirements 487 In case D, the ISP only provides IPv6 services. 489 5.1.1 IPv6 addressing requirements 491 We expect IPv6 addressing in case D to proceed similarly to case B, 492 i.e. use either RA proxy or explicit configuration to provision an 493 IPv6 prefix on the gateway. 495 5.1.2 IPv4 connectivity requirements 497 Local IPv4 capable hosts may want to still access IPv4 only 498 services. The proper way to do this for dual stack nodes in the 499 unmanaged network is to develop a form of "IPv4 over IPv6" 500 tunneling. This tunneling protocol need to be standardized, possibly 501 as an extension of the "dual stack transition mechanism" proposal 502 [DSTM]. Part of the standardization will have to cover configuration 503 issues, i.e. how to provision the IPv4 capable hosts with the 504 address of the local IPv4 tunnel servers. 506 5.1.3 Naming requirements 508 Naming requirements are similar to case B, with one difference: the 509 gateway cannot expect to use DHCPv4 to obtain the address of the 510 DNS resolver recommended by the ISP. 512 6 Provisional recommendations 514 This draft is still a draft, but we can already list a set of 515 recommendations for the V6OPS working group: 517 - To meet case A requirements, we need to develop and standardize 518 the Teredo or similar technology. 520 - To meet case B prefix delegation requirements, we need a 521 standardized IPv6 prefix delegation mechanism 523 - To meet case B naming requirements, we need to standardize a way 524 to provision a DNS resolver address in IPv6 only hosts, and we 525 need to proceed with the standardization fo LLMNR. 527 - To meet case C connectivity requirement, we need to continue 528 standardization of the 6to4 mechanism. 530 - To meet case D IPv4 connectivity requirement, we need to 531 standardize an IPv4 over IPv6 tunneling mechanism, as well as the 532 associated configuration services. 534 7 IANA Considerations 535 This memo does not include any request to IANA. 537 8 Copyright 539 The following copyright notice is copied from RFC 2026 [Bradner, 540 1996], Section 10.4, and describes the applicable copyright for this 541 document. 543 Copyright (C) The Internet Society July 12, 2001. All Rights 544 Reserved. 546 This document and translations of it may be copied and furnished to 547 others, and derivative works that comment on or otherwise explain it 548 or assist in its implementation may be prepared, copied, published 549 and distributed, in whole or in part, without restriction of any 550 kind, provided that the above copyright notice and this paragraph 551 are included on all such copies and derivative works. However, this 552 document itself may not be modified in any way, such as by removing 553 the copyright notice or references to the Internet Society or other 554 Internet organizations, except as needed for the purpose of 555 developing Internet standards in which case the procedures for 556 copyrights defined in the Internet Standards process must be 557 followed, or as required to translate it into languages other than 558 English. 560 The limited permissions granted above are perpetual and will not be 561 revoked by the Internet Society or its successors or assignees. 563 This document and the information contained herein is provided on an 564 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 565 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 566 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 567 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 568 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 9 Intellectual Property 572 The following notice is copied from RFC 2026 [Bradner, 1996], 573 Section 10.4, and describes the position of the IETF concerning 574 intellectual property claims made against this document. 576 The IETF takes no position regarding the validity or scope of any 577 intellectual property or other rights that might be claimed to 578 pertain to the implementation or use other technology described in 579 this document or the extent to which any license under such rights 580 might or might not be available; neither does it represent that it 581 has made any effort to identify any such rights. Information on the 582 IETF's procedures with respect to rights in standards-track and 583 standards-related documentation can be found in BCP-11. Copies of 584 claims of rights made available for publication and any assurances 585 of licenses to be made available, or the result of an attempt made 586 to obtain a general license or permission for the use of such 587 proprietary rights by implementers or users of this specification 588 can be obtained from the IETF Secretariat. 590 The IETF invites any interested party to bring to its attention any 591 copyrights, patents or patent applications, or other proprietary 592 rights which may cover technology that may be required to practice 593 this standard. Please address the information to the IETF Executive 594 Director. 596 10 Acknowledgements 598 This fractional and preliminary memo has benefited from comments of 599 Margaret Wasserman and Tony Hain. 601 11 References 603 [UNMANREQ] Unmanaged Networks Transition Scope. Work in progress. 605 [NATPTBISSUES] Issues when translating between IPv4 and IPv6. Work 606 in progress. 608 [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 609 Specification", RFC 2460, December 1998. 611 [NEIGHBOR] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery 612 for IP Version 6 (IPv6)", RFC 2461, December 1998. 614 [STATELESS] T. Narten, S. Thomson, "IPv6 Stateless Address 615 Autoconfiguration", RFC 2462, December 1998. 617 [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 618 Clouds", RFC 3056, February 2001. 620 [6TO4ANYCAST] C. Huitema, "An Anycast Prefix for 6to4 Relay 621 Routers", RFC 3068, June 2001. 623 [TEREDO] Teredo: Tunneling IPv6 over UDP through NATs. Work in 624 progress. 626 [TUNNELS] A. Durand, P. Fasano, I. Guardini. IPv6 Tunnel Broker. RFC 627 3053, January 2001 629 [PREFIXDHCPV6] IPv6 Prefix Options for DHCPv6. Work in progress. 631 [DNSDHCPV6] DNS Configuration options for DHCPv6. Work in progress. 633 [DNSANYCAST] Well known site local unicast addresses for DNS 634 resolver. Work in progress. 636 [LLMNR] Link Local Multicast Name Resolution. Work in progress. 638 [DSTM] Dual Stack Transition Mechanism (DSTM). Work in progress. 640 12 Authors' Addresses 642 Christian Huitema 643 Microsoft Corporation 644 One Microsoft Way 645 Redmond, WA 98052-6399 646 Email: huitema@microsoft.com 648 Rob Austein 649 Email: sra@hactrn.net 651 Suresh Satapati 652 Cisco Systems, Inc. 653 San Jose, CA 95134 654 USA 655 EMail: satapati@cisco.com 657 Ronald van der Pol 658 Email: Ronald.vanderPol@rvdp.org 660 Table of Contents: 662 1 Introduction .................................................... 1 663 2 Meeting case A requirements ..................................... 2 664 2.1 Evaluation of connectivity mechanisms ......................... 2 665 2.1.1 TEREDO ...................................................... 2 666 2.1.2 Simple UDP tunnel ........................................... 2 667 2.1.3 Comparison of TEREDO and tunnel solution .................... 3 668 2.1.4 Recommendation .............................................. 4 669 2.2 Security considerations in case A ............................. 4 670 3 Meeting case B requirements ..................................... 4 671 3.1 Prefix delegation ............................................. 5 672 3.1.1 RA proxy .................................................... 5 673 3.1.2 Explicit prefix delegation .................................. 5 674 3.1.3 Recommendation .............................................. 5 675 3.2 Communication between IPv4-only and IPv6-only hosts ........... 5 676 3.3 Resolution of names to IPv6 addresses ......................... 6 677 3.3.1 Provisioning the address of a DNS resolver .................. 6 678 3.3.2 Publishing IPv6 addresses to the Internet ................... 6 679 3.3.3 Resolving local IPv6 addresses .............................. 7 680 3.3.4 Recommendations for name resolution ......................... 7 681 3.4 Security considerations for case B ............................ 7 682 4 Meeting case C requirements ..................................... 8 683 4.1 Tunneling mechanisms .......................................... 8 684 4.1.1 6to4 ........................................................ 8 685 4.1.2 Tunnel broker ............................................... 8 686 4.1.3 Recommendations ............................................. 9 687 4.2 Security considerations ....................................... 9 688 5 Meeting the case D requirements ................................. 10 689 5.1.1 IPv6 addressing requirements ................................ 10 690 5.1.2 IPv4 connectivity requirements ............................. 10 691 5.1.3 Naming requirements ......................................... 10 692 6 Provisional recommendations ..................................... 10 693 7 IANA Considerations ............................................. 10 694 8 Copyright ....................................................... 11 695 9 Intellectual Property ........................................... 11 696 10 Acknowledgements ............................................... 12 697 11 References ..................................................... 12 698 12 Authors' Addresses ............................................. 13