idnits 2.17.1 draft-ietf-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 577 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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 41 instances of lines with control characters in the document. ** The abstract seems to contain references ([TUNNELS], [TEREDO], [6TO4SECU], [Bradner,1996], [UNMANREQ], [6TO4ANYCAST], [6TO4], [ISATAP]), 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: 'Bradner' is mentioned on line 631, but not defined -- Looks like a reference, but probably isn't: '1996' on line 631 == Unused Reference: 'IPV6' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'NEIGHBOR' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'STATELESS' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'PREFIXDHCPV6' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'SIIT' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'NAT-PT' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'DNS-ALG-ISSUES' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'HALLIN-DNS-ALG' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'TRT' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'DSTM' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'DHCPV6' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'DNSDHCPV6' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'DNSANYCAST' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'LLMNR' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'NODEINFO' is defined on line 727, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: 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 2462 (ref. 'STATELESS') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3068 (ref. '6TO4ANYCAST') (Obsoleted by RFC 7526) -- Possible downref: Non-RFC (?) normative reference: ref. 'TEREDO' ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. 'TUNNELS') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISATAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'PREFIXDHCPV6' ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (ref. 'NAT-PT') (Obsoleted by RFC 4966) -- Duplicate reference: RFC2766, mentioned in 'DNS-ALG-ISSUES', was also mentioned in 'NAT-PT'. ** Obsolete normative reference: RFC 2766 (ref. 'DNS-ALG-ISSUES') (Obsoleted by RFC 4966) -- Possible downref: Non-RFC (?) normative reference: ref. 'HALLIN-DNS-ALG' ** Downref: Normative reference to an Informational RFC: RFC 3142 (ref. 'TRT') -- Possible downref: Non-RFC (?) normative reference: ref. 'DSTM' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSDHCPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSANYCAST' -- Possible downref: Non-RFC (?) normative reference: ref. 'LLMNR' -- Possible downref: Non-RFC (?) normative reference: ref. 'NODEINFO' -- Possible downref: Non-RFC (?) normative reference: ref. '6TO4SECU' Summary: 16 errors (**), 0 flaws (~~), 19 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. Huitema 2 Microsoft 3 June 3, 2003 R. Austein 4 Expires December 3, 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 corresponds 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) a gateway which does not provide IPv6 at all; 55 Huitema et al. [Page 1] 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 This document analyses the issues involved in the transition from 61 IPv4 to IPv6. One of the most important issues is that of naming and 62 addressing. 64 During the transition phase from IPv4 to IPv6 there will be IPv4 65 only, dual stack or IPv6 only nodes. In this document, we make the 66 hypothesis that the IPv6 only nodes do not need to communicate with 67 IPv4 only nodes; devices that want to communicate with both IPv4 and 68 IPv6 nodes are expected to implement both IPv4 and IPv6, i.e. be 69 dual stack. 71 The issues involved are described in the next chapters. This 72 analysis outlines two types of requirements: 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. 77 2 Meeting case A requirements 79 In case A, isolated hosts located behind a NAT need to acquire some 80 form of connectivity. In this section, we first evaluate how 81 mechanisms already defined or being worked on in the IETF meet this 82 requirement. We then consider the "remaining holes" and recommend 83 specific developments. 85 2.1 Evaluation of connectivity mechanisms 87 In case A, IPv6 capable hosts seek IPv6 connectivity in order to 88 participate to applications in the global IPv6 Internet. The 89 connectivity requirement can be met in two ways: Teredo, or UDP 90 tunnels. (We will not discuss here the case where there is no NAT; 91 this will be considered as a subset of case C.) 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 was described in a draft that has now expired, and is also mentioned 113 as a possible alternative to the bubble mechanism in the TEREDO 114 specification. 116 2.1.3 Comparison of TEREDO and tunnel solution 118 The TEREDO and tunnel solutions differ in terms of complexity and 119 operation. 121 A first difference is the cost of operating the server. TEREDO is 122 designed to minimize the cost of operating the server, which only 123 processes small bubbles and never relays traffic; on the other hand, 124 a tunnel server will relay all the packets going to and from the 125 Teredo host. This implies a very different amount of 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 however two situations in which a tunnel service makes 188 sense: when the cost of bandwidth is not a concern, and when the 189 unmanaged network is located behind a symmetric NAT. In these two 190 cases, using 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 only expected to serve local hosts, located behind the 204 NAT. Developers and administrators should make sure that the global 205 IPv6 connectivity is restricted to only those applications that are 206 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. In this mechanism, the gateway 246 uses a DHCP request to obtain an adequate prefix from a DHCP server 247 managed by the Internet Service Provider. The DHCP request is 248 expected to carry proper identification of the gateway, which 249 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 possibly both, is quite 265 urgent. 267 3.2 Communication between IPv4-only and IPv6-capable nodes 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, it is hard to develop a translation service that does not 275 have unwanted side effects on the efficiency or the security of 276 communications. As a consequence, the authors recommend that, if a 277 device has a requirement to communicate with IPv4 only hosts, this 278 device implements an IPv4 stack. The only devices that should only 279 have IPv6 connectivity are those that are intended to only 280 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; sending 308 the DNS requests to a well known IPv6 address; or sending the DNS 309 requests to the IPv6 address of the gateway itself. 311 3.3.2 Publishing IPv6 addresses to the Internet 313 IPv6 capable hosts may be willing to provide services accessible 314 from the global Internet. They will thus need to document their 315 address in a server that is publicly available. IPv4 hosts in 316 unmanaged networks have a similar problem today, which they solve 317 using one of three possible solutions: 319 * Manual configuration of a stable address in a DNS server; 320 * Dynamic configuration using the standard dynamic DNS protocol; 321 * Dynamic configuration using an ad hoc protocol. 323 Huitema et al. [Page 6] 324 Manual configuration of stable addresses is not satisfactory in an 325 unmanaged IPv6 network: the prefix allocated to the gateway may or 326 may not be stable, and in any case copying long binary addresses 327 through a manual procedure is error prone. 329 Dynamic configuration using the same type of ad hoc protocols that 330 are common today is indeed possible, but the IETF should encourage 331 the use of standard solutions based on DDNS. 333 3.3.3 Resolving the IPv6 addresses of local hosts 335 There are two possible ways of resolving the IPv6 addresses of local 336 hosts: one may either publish the IPv6 addresses in a DNS server for 337 the local domain, or one may use a peer-to-peer address resolution 338 protocol such as LLMNR. 340 When a DNS server is used, this server could in theory be located 341 anywhere on the Internet. There is however a very strong argument 342 for using a local server, which will remain reachable even if the 343 network connectivity is down. 345 The use of a local server requires that IPv6 capable hosts discover 346 this server, as explained in 3.3.1, and then that they use a 347 protocol such as DDNS to publish their IPv6 addresses to this 348 server. In practice, the DNS address discovered in 3.3.1 will often 349 be the address of the gateway itself, and the local server will thus 350 be the gateway. Implementing a dynamic DNS server on the gateway may 351 be problematic, as many of these gateways are very small devices 352 with limited memory and limited processing power. 354 An alternative to using a local server is LLMNR, which uses a 355 multicast mechanism to resolve DNS requests. LLMNR does not require 356 any service from the gateway, and also does not require that hosts 357 use DDNS. LLMNR relies on multicast for its operation. There are 358 scaling issues with using multicast, as the procedure may become 359 very chatty in large networks; but this is not a practical problem 360 in most unmanaged networks. A more important problem is that some 361 networks only have limited support for multicast transmission: for 362 example, multicast transmission on 802.11 network is error prone. 363 However, unmanaged networks also use multicast for neighbor 364 discovery; the requirements of ND and LLMNR are similar; if a link 365 technology supports use of ND, it will also enable use of LLMNR. 367 3.3.4 Recommendations for name resolution 369 The IETF should quickly provide a recommended procedure for 370 provisioning the DNS resolver in IPv6 only hosts, either by 371 standardizing the proper DHCPv6 subset, or by recommending an 372 alternate convention. 374 The most plausible candidate for local name resolution appears to be 376 Huitema et al. [Page 7] 377 LLMNR; the IETF should quickly proceed to the standardization fo 378 that protocol. 380 3.4 Security considerations in case B 382 The case B solutions provide global IPv6 connectivity to the local 383 hosts. Removing the limit to connectivity imposed by NAT is both a 384 feature and a risk. Implementations should carefully limit global 385 IPv6 connectivity to only those applications that are specifically 386 designed to operate on the global Internet. Local applications, for 387 example, could be restricted to only use link-local addresses, or 388 addresses whose most significant bits match the prefix of the local 389 subnet. 391 4 Meeting case C requirements 393 Case C is very similar to case B, the difference being that the ISP 394 is not dual stack. The gateway must thus use some form of tunneling 395 mechanism to obtain IPv6 connectivity, and an address prefix. 397 A simplified form of case B occurs is a single host with a global 398 IPv4 address, i.e. with a direct connection to the IPv4 Internet. 399 This host will be able to use the same tunneling mechanisms as a 400 gateway. 402 4.1 Tunneling mechanisms 404 4.1.1 6to4 406 The [6TO4] technology allows routers to derive a global scope IPv6 407 prefix from a global IPv4 address. This technology is a very good 408 fit for the second phase of the transition, as it can be programmed 409 in the "upgraded gateway", and can provide value to the gateway 410 users without requiring explicit support from the ISP. This 411 technology has however a clear limitation: it requires that the 412 gateway obtains at least one global IPv4 address from the local ISP. 414 Another potential limitation of the technology is the reliance on 415 publicly accessible "6to4 relay routers" that accept packets from 416 6to4 routers and relay them to the "regular" IPv6 Internet. These 417 relays all listen to the same IPv4 anycast address [6TO4ANYCAST], 418 which enables gateways to start operating as 6to4 routers without 419 requiring any explicit configuration. As the deployment of IPv6 420 progresses, a growing fraction of the traffic originating from 6to4 421 routers will have to be carried through these relays, potentially 422 leading to severe congestion of the relays. 424 There are three possible ways to alleviate this congestion. First, 425 one can hope that many actors will deploy 6to4 relay routers, in 426 order to facilitate the deployment of IPv6; congestion would be 427 alleviated by the provision of a large number of gateways. Second, 428 one could develop some "route optimization" process, so that the 430 Huitema et al. [Page 8] 431 traffic would flow through a "shortcut path" rather than through the 432 6to4 relays; the relays would then avoid congestion by carrying only 433 a small fraction of the traffic. Third, if neither the first nor the 434 second solution materializes, some gateways may enter into 435 contractual agreements with relay service providers; in this case, 436 the 6to4 technology would become merely a variant of the configured 437 tunnel technologies. 439 4.1.2 Tunnel broker 441 Configured tunnels require a contractual agreement with an IPv6 442 provider, which comes in addition to the existing agreement with the 443 IPv4 provider; different technologies have different domains of 444 application. 446 Many tunnel technologies use a global IPv4 address to identify the 447 "client end" of the tunnel, thus inheriting the same "global IPv4 448 address" requirement as 6TO4. A variant of the [TEREDO] technology 449 could be used to establish tunnels over UDP when the client is 450 behind a NAT; this variant is however not standardized. 452 Practical deployment of tunnel technologies requires the 453 introduction of accounting/billing functions; the existing tunnel 454 broker specification, [TUNNELS], does not describe how these 455 functions should be implemented. (However, the use of public relays 456 in the 6to4 technology may raise a similar issue.) 458 Configured tunnels are in practice an intermediate solution between 459 the "automatic configuration" provided by 6to4, and the "ISP 460 support" that characterizes case B. 462 4.1.3 ISATAP 464 The ISATAP protocol [ISATAP] enables the construction of IPv6 465 addresses by combining a subnet prefix with an identifier derived 466 from an IPv4 address. Hosts in an ISATAP subnet exchange IPv6 467 packets by an automatic tunneling mechanism: the IPv6 packets are 468 tunneled over IPv4 towards the IPv4 address specified in the 469 identifier part of the address. Hosts in the ISATAP tunnel 470 communicate with the IPv6 Internet by sending packets to the ISATAP 471 subnet routers. In practical deployments, ISATAP hosts are 472 configured with the IPv4 address or the DNS name of an ISATAP 473 router. 475 In theory, ISATAP could be used to provide hosts in an unmanaged 476 network with IPv6 connectivity; the gateway might function as an 477 ISATAP router. However, in a single subnet deployment, this solution 478 is markedly inferior to native IPv6: it incurs more overhead, and is 479 not easier to deploy. 481 One may also consider using the ISATAP technology to provide IPv6 482 connectivity to the gateway itself. However, ISATAP only derives a 484 Huitema et al. [Page 9] 485 single IPv6 address from an IPv4 address. ISATAP can thus only be 486 used in the degenerate case when the unmanaged network consists of a 487 single host. This will only be interesting if this single host does 488 not obtain a global IPv4 address from the ISP; if it did, it could 489 use 6TO4, which is easier to configure. An ISP that provides hosts 490 with non-global IPv4 address could set up an ISATAP router, so that 491 each of these hosts could obtain an IPv6 address. 493 4.1.4 Recommendations 495 The practical conclusion of the previous analysis is that "upgraded 496 gateways" will probably support the 6TO4 technology, and will have 497 an optional configuration option for "configured tunnels". The 498 ISATAP technology appears to have very limited applicability in this 499 scenario. 501 The tunnel broker technology should be augmented, to include support 502 for accounting and billing functions. 504 Due to concerns with potential overload of public 6to4 relays, the 505 6to4 implementations should include a configuration option that let 506 user take advantage of specific relays. 508 4.2 Naming requirements in case C 510 Naming requirements are similar to case B. 512 4.3 Security considerations in case C 514 The security issues in case C combines the issues already mentioned 515 in case B, plus the specific issues related to the use of tunneling 516 technologies. The main concern with tunneling technologies is the 517 possibility for attackers to spoof the source address of IPv6 518 packets sent inside a tunnel, and use this spoofing as the basis for 519 various attacks. Attacks on 6TO4 tunnels are documented in 520 [6TO4SECU]. Configured tunnels that do not use per packet 521 authentication can also be subject to spoofing attacks, if the 522 attacker is able to spoof the source IPv4 address of either a tunnel 523 server or a tunnel client. 525 5 Meeting the case D requirements 527 In case D, the ISP only provides IPv6 services. 529 5.1.1 IPv6 addressing requirements 531 We expect IPv6 addressing in case D to proceed similarly to case B, 532 i.e. use either RA proxy or explicit configuration to provision an 533 IPv6 prefix on the gateway. 535 5.1.2 IPv4 connectivity requirements 536 Local IPv4 capable hosts may want to still access IPv4 only 537 services. The proper way to do this for dual stack nodes in the 538 unmanaged network is to develop a form of "IPv4 over IPv6" 539 tunneling. This tunneling protocol need to be standardized. Part of 540 the standardization will have to cover configuration issues, i.e. 541 how to provision the IPv4 capable hosts with the address of the 542 local IPv4 tunnel servers. 544 5.2 Naming requirements 546 Naming requirements are similar to case B, with one difference: the 547 gateway cannot expect to use DHCPv4 to obtain the address of the DNS 548 resolver recommended by the ISP. This problem is similar to the 549 provision of DNS parameters to an IPv6 only host in case B, and the 550 same mechanisms can be used. 552 5.3 Security requirements 554 Security requirements in case D are analogous to those of case B. 555 The use of a tunneling mechanism to provide IPv4 connectivity may 556 introduce its own security issues, but the analysis of these issues 557 can only be performed after this tunneling mechanism is fully 558 designed. 560 6 Provisional recommendations 562 This draft is still a draft, but we can already list a set of 563 recommendations for the V6OPS working group: 565 1- To meet case A requirements, we need to develop and standardize 566 the Teredo or similar technology. 568 2- To meet case B prefix delegation requirements, we need a 569 standardized IPv6 prefix delegation mechanism 571 3- To meet case B "informal prefix sharing" requirements, we would 572 need a standardized way to perform "RA proxy", possibly as part of a 573 "multi-link subnet" specification 575 4- To meet case B naming requirements, we need to standardize a way 576 to provision a DNS resolver address in IPv6 only hosts, and we need 577 to proceed with the standardization of LLMNR. 579 5- To meet case C connectivity requirement, we need to continue 580 standardization of the 6to4 mechanism. 582 6- To meet case D IPv4 connectivity requirement, we need to 583 standardize an IPv4 over IPv6 tunneling mechanism, as well as the 584 associated configuration services. 586 7 Security consideration 587 The present document does not define any specific technology, and 588 thus is not believed to introduce any new security issue. The 589 security requirement of each specific transition case are described 590 as part of the analysis of that case. 592 8 IANA Considerations 594 This memo does not include any request to IANA. 596 9 Copyright 598 The following copyright notice is copied from RFC 2026 [Bradner, 599 1996], Section 10.4, and describes the applicable copyright for this 600 document. 602 Copyright (C) The Internet Society July 12, 2001. All Rights 603 Reserved. 605 This document and translations of it may be copied and furnished to 606 others, and derivative works that comment on or otherwise explain it 607 or assist in its implementation may be prepared, copied, published 608 and distributed, in whole or in part, without restriction of any 609 kind, provided that the above copyright notice and this paragraph 610 are included on all such copies and derivative works. However, this 611 document itself may not be modified in any way, such as by removing 612 the copyright notice or references to the Internet Society or other 613 Internet organizations, except as needed for the purpose of 614 developing Internet standards in which case the procedures for 615 copyrights defined in the Internet Standards process must be 616 followed, or as required to translate it into languages other than 617 English. 619 The limited permissions granted above are perpetual and will not be 620 revoked by the Internet Society or its successors or assignees. 622 This document and the information contained herein is provided on an 623 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 624 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 625 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 626 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 627 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 629 10 Intellectual Property 631 The following notice is copied from RFC 2026 [Bradner, 1996], 632 Section 10.4, and describes the position of the IETF concerning 633 intellectual property claims made against this document. 635 The IETF takes no position regarding the validity or scope of any 636 intellectual property or other rights that might be claimed to 637 pertain to the implementation or use other technology described in 638 this document or the extent to which any license under such rights 639 might or might not be available; neither does it represent that it 640 has made any effort to identify any such rights. Information on the 641 IETF's procedures with respect to rights in standards-track and 642 standards-related documentation can be found in BCP-11. Copies of 643 claims of rights made available for publication and any assurances 644 of licenses to be made available, or the result of an attempt made 645 to obtain a general license or permission for the use of such 646 proprietary rights by implementers or users of this specification 647 can be obtained from the IETF Secretariat. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights which may cover technology that may be required to practice 652 this standard. Please address the information to the IETF Executive 653 Director. 655 11 Acknowledgements 657 This fractional and preliminary memo has benefited from comments of 658 Margaret Wasserman and Tony Hain. 660 12 References 662 Normative references 664 [UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der 665 Pol. "Unmanaged Networks IPv6 Transition Scenarios", Work in 666 progress. 668 [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 669 (IPv6) Specification", RFC 2460, December 1998. 671 [NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 672 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 674 [STATELESS] Narten, T., and S. Thomson, "IPv6 Stateless Address 675 Autoconfiguration", RFC 2462, December 1998. 677 [6TO4] Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 678 IPv4 Clouds", RFC 3056, February 2001. 680 [6TO4ANYCAST] C. Huitema, "An Anycast Prefix for 6to4 Relay 681 Routers", RFC 3068, June 2001. 683 [TEREDO] C. Huitema. "Teredo: Tunneling IPv6 over UDP through NATs." 684 Work in progress. 686 [TUNNELS] Durand, A., Fasano, P., and I. Guardini. IPv6 Tunnel 687 Broker. RFC 3053, January 2001 689 [ISATAP] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 690 "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in 691 progress. 693 [PREFIXDHCPV6] Troan, O., and R. Droms. "IPv6 Prefix Options for 694 DHCPv6." Work in progress. 696 [SIIT] E. Nordmark, Stateless IP/ICMP Translation Algorithm (SIIT). 697 RFC 2765, February 2000. 699 [NAT-PT] Tsirtsis, G., and P. Srisuresh, Network Address 700 Translation - Protocol Translation (NAT-PT). RFC 2766, February 701 2000. 703 [DNS-ALG-ISSUES] Issues with NAT-PT DNS ALG in RFC2766. Work in 704 progress. 706 [HALLIN-DNS-ALG] NAT-PT DNS ALG solutions. Work in progress. 708 [TRT] Hagino, J., and K. Yamamoto. An IPv6-to-IPv4 Transport Relay 709 Translator, RFC 3142, June 2001. 711 [DSTM] Dual Stack Transition Mechanism (DSTM). Work in progress. 713 [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 714 M. Carney. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)." 715 Work in progress. 717 [DNSDHCPV6] R. Droms. "DNS Configuration options for DHCPv6." Work 718 in progress. 720 [DNSANYCAST] Durand, A., Hagino, J., and D. Thaler. "Well known 721 site local unicast addresses to communicate with recursive DNS 722 servers." Work in progress. 724 [LLMNR] Esibov, L., Aboba, B., and D. Thaler. "Linklocal Multicast 725 Name Resolution (LLMNR)Multicast DNS." Work in progress. 727 [NODEINFO] M. Crawford. "IPv6 Node Information Queries." Work in 728 progress. 730 [6TO4SECU] Savola, P., "Security Considerations for 6to4", Work in 731 progress. 733 Informative references 735 [NAT-PT] Tsirtsis, G., and P. Srisuresh. "Network Address 736 Translation - Protocol Translation (NAT-PT)." RFC 2766, February 737 2000. 739 [DNS-ALG-ISSUES] A. Durand. "Issues with NAT-PT DNS ALG in RFC2766." 740 Work in progress. 742 13 Authors' Addresses 744 Christian Huitema 745 Microsoft Corporation 746 One Microsoft Way 747 Redmond, WA 98052-6399 748 Email: huitema@microsoft.com 750 Rob Austein 751 Email: sra@hactrn.net 753 Suresh Satapati 754 Cisco Systems, Inc. 755 San Jose, CA 95134 756 USA 757 EMail: satapati@cisco.com 759 Ronald van der Pol 760 NLnet Labs 761 Kruislaan 419 762 1098 VA Amsterdam 763 NL 764 Email: Ronald.vanderPol@nlnetlabs.nl 766 Table of Contents: 768 1 Introduction .................................................... 1 769 2 Meeting case A requirements ..................................... 2 770 2.1 Evaluation of connectivity mechanisms ......................... 2 771 2.1.1 TEREDO ...................................................... 2 772 2.1.2 Simple UDP tunnel ........................................... 2 773 2.1.3 Comparison of TEREDO and tunnel solution .................... 3 774 2.1.4 Recommendation .............................................. 4 775 2.2 Security considerations in case A ............................. 4 776 3 Meeting case B requirements ..................................... 4 777 3.1 Prefix delegation ............................................. 5 778 3.1.1 RA proxy .................................................... 5 779 3.1.2 Explicit prefix delegation .................................. 5 780 3.1.3 Recommendation .............................................. 5 781 3.2 Communication between IPv4-only and IPv6-capable nodes ........ 5 782 3.3 Resolution of names to IPv6 addresses ......................... 6 783 3.3.1 Provisioning the address of a DNS resolver .................. 6 784 3.3.2 Publishing IPv6 addresses to the Internet ................... 6 785 3.3.3 Resolving the IPv6 addresses of local hosts ................. 7 786 3.3.4 Recommendations for name resolution ......................... 7 787 3.4 Security considerations in case B ............................. 8 788 4 Meeting case C requirements ..................................... 8 789 4.1 Tunneling mechanisms .......................................... 8 790 4.1.1 6to4 ........................................................ 8 791 4.1.2 Tunnel broker ............................................... 9 792 4.1.3 ISATAP ...................................................... 9 793 4.1.4 Recommendations ............................................. 10 794 4.2 Naming requirements in case C ................................. 10 795 4.3 Security considerations in case C ............................. 10 796 5 Meeting the case D requirements ................................. 10 797 5.1.1 IPv6 addressing requirements ................................ 10 798 5.1.2 IPv4 connectivity requirements ............................. 10 799 5.2 Naming requirements ........................................... 11 800 5.3 Security requirements ......................................... 11 801 6 Provisional recommendations ..................................... 11 802 7 Security consideration .......................................... 11 803 8 IANA Considerations ............................................. 12 804 9 Copyright ....................................................... 12 805 10 Intellectual Property .......................................... 12 806 11 Acknowledgements ............................................... 13 807 12 References ..................................................... 13 808 13 Authors' Addresses ............................................. 15