idnits 2.17.1 draft-chown-v6ops-unmanaged-connectivity-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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.) 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.) -- The document date (October 20, 2003) is 7484 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-00 == Outdated reference: A later version (-03) exists of draft-palet-v6ops-proto41-nat-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Expires: April 19, 2004 R. van der Pol 5 NLnet Labs 6 P. Savola 7 CSC/FUNET 8 October 20, 2003 10 Considerations for IPv6 Tunneling Solutions in Small End Sites 11 draft-chown-v6ops-unmanaged-connectivity-00 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 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 This Internet-Draft will expire on April 19, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 Tunneling IPv6 packets over the IPv4 Internet played a major role in 42 the early stages of IPv6 deployment. This was useful because in the 43 early days the routers in the internet did not support IPv6. 44 Nowadays, tunneling is used to get across legacy equipment and ISPs 45 that do not support IPv6. Many different tunneling mechanisms have 46 been invented. This document describes the drivers for IPv6 47 tunneling, the general architectures of existing mechanisms, and a 48 set of desirable properties against which subsequent analysis of the 49 mechanisms may be made. The document is aimed at small end sites 50 that may typically utilise tunneling methods in an early IPv6 51 deployment. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Motivations for Tunneling . . . . . . . . . . . . . . . . . 5 57 2.1 Using Tunneling To Circumvent Legacy ISPs . . . . . . . . . 5 58 2.2 Using Tunneling To Get Across Legacy NAT Boxes . . . . . . . 5 59 3. Tunneling Architectures . . . . . . . . . . . . . . . . . . 6 60 3.1 Configuration Aspects Of Tunneling Mechanisms . . . . . . . 6 61 3.2 Traffic Concentration . . . . . . . . . . . . . . . . . . . 6 62 3.3 (Un)managed and Dynamic/Fixed Tunneling . . . . . . . . . . 7 63 4. Desirable Properties of Tunneling Solutions . . . . . . . . 8 64 4.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3 Ease of Management . . . . . . . . . . . . . . . . . . . . . 8 67 4.4 Handling Dynamic IPv4 Addresses . . . . . . . . . . . . . . 8 68 4.5 Support for Hosts or Sites . . . . . . . . . . . . . . . . . 9 69 4.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.7 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.8 Can be Used Behind a NAT . . . . . . . . . . . . . . . . . . 9 72 4.9 Tunnel Service Ownership . . . . . . . . . . . . . . . . . . 9 73 4.10 Tunnel Service Discovery . . . . . . . . . . . . . . . . . . 10 74 4.11 Support for Special Services . . . . . . . . . . . . . . . . 10 75 4.12 Route Optimisation . . . . . . . . . . . . . . . . . . . . . 10 76 4.13 Reverse DNS Lookups Available . . . . . . . . . . . . . . . 10 77 4.14 Accountability . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 80 Informative References . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 82 Intellectual Property and Copyright Statements . . . . . . . 15 84 1. Introduction 86 Tunneling IPv6 packets over the IPv4 Internet played a major role in 87 the early stages of IPv6 deployment. The 6bone testbed made extensive 88 use of encapsulating IPv6 packets in IPv4 [1]. This was useful 89 because in the early days the routers in the Internet did not support 90 IPv6 and tunneling made it possible to build a virtual worldwide IPv6 91 network without changes to the IPv4 production routers and to 92 experiment with the IPv6 protocol. 94 Nowadays, tunneling is used to get across legacy equipment and ISPs 95 that do not support IPv6. This document describes the motivations for 96 IPv6 tunneling, the general architectures of existing mechanisms, and 97 a set of desirable properties against which subsequent analysis of 98 the mechanisms may be made. The document is aimed at small end 99 sites that may typically utilise tunneling methods in an early IPv6 100 deployment. 102 A number of tunneling solutions have been devised, and continue to be 103 devised. While ultimately when consumers really need IPv6 the ISPs 104 are very likely to then offer a native service, at present the 105 perceived demand at the ISPs is low, thus those sites wanting early 106 connectivity need tunneling methods. It can be argued that we should 107 not try to force IPv6 deployment by inventing complex protocols and 108 setups that are difficult to manage. Similarly the very presence of 109 automatic mechanisms, typically not provided by the ISP in question, 110 may reduce the ISPs' perceived customer demand even further. 112 We also note that some ISP practices will make the deployment of 113 tunneling solutions more difficult, e.g. the use of dynamic IPv4 114 address allocations to customers. This document recognises the need 115 to consider current operational practices, so that the 116 recommendations we may base upon the considerations in this document, 117 and the assumptions we make, may be more likely to be useful. 119 The goal of this document is to enable a trade-off analysis for 120 existing mechanisms that may include but not be limited to: 122 o Tunnel broker [2], with TSP [5] 124 o 6to4 [3] 126 o Teredo [4] 128 in addition to as yet undefined mechanisms or minor modifications or 129 extensions to current mechanisms. In this document, rather than 130 compare specific methods, we refer to the general methods, e.g. of a 131 "6to4-like" service. 133 We aim to keep the analysis logically different from this 134 considerations document. We do not want to be solution-centric, 135 rather problem-centric. Analysis should be done in a separate 136 document. 138 2. Motivations for Tunneling 140 Most tunneling mechanisms are intended for use in the early stages of 141 IPv6 deployment. Some try to bypass IPv4-only ISPs that do not offer 142 IPv6 services. Others try to bypass NAT boxes that do not support 143 IPv6, while also bypassing the ISPs which do not offer IPv6 services 144 (tackling both problems in one). Mechanisms only passing the NAT box 145 seem rather rare. None of the mechanisms are needed when the ISP 146 starts offering IPv6 services or when the NAT box is replaced by an 147 IPv6-aware box. 149 When considering the various tunneling mechanisms it is important to 150 know what problem they try to solve. Most do not seem to solve real 151 technical problems as such, and are instead a workaround for a lack 152 of native IPv6 deployment. The tradeoff between (possibly complex) 153 tunneling mechanisms and waiting for IPv6 deployment should be 154 carefully analysed. Similarly, the cost to an ISP of supporting 155 "early adopter" tunneling services as opposed to deploying a pilot 156 native service should be considered. However, the reality is that 157 tunneling solutions will be an important tool for the introduction of 158 IPv6 services for some time to come, hence this document focuses on 159 desirable properties for such solutions. 161 2.1 Using Tunneling To Circumvent Legacy ISPs 163 Tunneling can be used to get IPv6 connectivity across ISPs that do 164 not offer IPv6 yet. Ideally a customer's ISP would offer them a 165 native IPv6 service. However, in the absence of such a native IPv6 166 service a tunneled solution is the only real option for an early 167 adopter of IPv6. We thus need to consider the desirable properties 168 of such a tunneled solution. 170 2.2 Using Tunneling To Get Across Legacy NAT Boxes 172 Tunneling can also be used to get across legacy equipment (e.g. a 173 SOHO router) that does not support IPv6 yet. When ISPs start to offer 174 a native IPv6 service on a large scale, SOHO router manufacturers are 175 likely to introduce IPv6-enabled SOHO routers. In the meantime, 176 many customers will require some method to gain an IPv6 service in 177 the presence of a NAT. While trying to invent a complex protocol to 178 try to send IPv6 traffic at any cost is probably not the best 179 technical solution, it is one of necessity. 181 In such a situation ownership and access to the configuration of the 182 NAT device is an issue. Where ownership is held by the customer, 183 they have the technical knowledge, and have only one internal host or 184 network to establish a tunnel to, Protcol 41 forwarding [6] may 185 enable a tunnel to pass through such a NAT. 187 3. Tunneling Architectures 189 The examples of specific existing solutions listed in the 190 Introduction can be generalised, e.g.: 192 o A tunnel brokering service by which a host or network may obtain a 193 tunnel service by a one-time interaction which leads to the 194 establishment of a tunnel service to a tunnel concentrator, and 195 from there to the wider IPv6 internet. The tunnel concentrator may 196 reside either at a local or remote ISP. A NAT traversal may also 197 be included, using an additional encapsulation. Tunnel brokering 198 services may use a tunnel setup protocol for ease of management, 199 whereby tunnels are set up automatically and the mechanism has the 200 possibility of authentication. 202 o An automatic tunneling service by which a host or network may 203 obtain an automatic tunnel service to any other host or site 204 supporting the same service. While such traffic does not require 205 use of a concentrator, connectivity to the native IPv6 internet 206 requires use of such a relay. 208 o A NAT traversal service by which a host behind an IPv4 NAT may 209 gain tunneled connectivity to the external IPv6 internet by way of 210 a tunnel concentrator or server, while a part of communications 211 between the service's users is designed to go directly via 212 "short-cuts". 214 By these general descriptions we can refer to, for example, a "tunnel 215 broker-like" service. Each mechanism may have a different philosophy, 216 but each may also target a different problem (e.g. NAT traversal). 217 Each will have a different architecture. 219 3.1 Configuration Aspects Of Tunneling Mechanisms 221 Tunneling always involves encapsulating at one end of the tunnel and 222 decapsulating at the other end of the tunnel. When encapsulating, the 223 IPv4 address of the other side of the tunnel is needed. For some 224 mechanisms this information needs to be configured manually. For 225 other mechanisms the information is obtained via a special protocol 226 (e.g. TSP [5]), one time setup (e.g. manually configured tunnel 227 broker) or automatically (e.g. 6to4 [3]). Tunnels can be either 228 unidirectional or bi-directional. 230 3.2 Traffic Concentration 232 Some tunneling mechanisms send all traffic to the same tunnel 233 end-point. This end-point acts as a concentration point. Other 234 tunneling mechanisms use a tunnel end-point based on the destination 235 of the traffic. They send traffic over the same path as the IPv4 236 traffic. In this case there is no concentration point. 238 The use of concentrator points will have implications for the 239 scalability of the solution, and may also raise concerns over the 240 point of failure it represents (especially where denial of service 241 attacks may be directed at that point). However, a seemingly 242 de-centralized model (e.g. deployment using anycast) may in fact also 243 practically incur traffic concentration problems if only a small 244 amount of concentrators are being used. 246 3.3 (Un)managed and Dynamic/Fixed Tunneling 248 There is a subtle distinction between managed or unmanaged and manual 249 or automatic tunnel services. The distinction from the point of 250 view of the tunnel is that it may be fixed (to a pre-configured 251 remote IPv4 address) or dynamic (the tunnel is established on demand 252 to any given remote IPv4 address, whereby the remote IPv4 address is 253 based on the packet destination address and each destination has its 254 own remote IPv4 address). Either the fixed or dynamic tunnels may be 255 managed or unmanaged, although all dynamic mechanisms are unmanaged. 257 4. Desirable Properties of Tunneling Solutions 259 In this section we list the desirable properties that a tunnel 260 service may have, from the view of the customer, the ISP, or both the 261 customer and ISP. We do not categorise them as such at this point, 262 but may do so in a future revision of this document if it is deemed 263 useful to do so; such a future revision may also go into further 264 discussion of tradeoffs rather than purelybeing a list of desirable 265 properties. 267 Note that it is unlikely that a single tunnel solution will meet all 268 the desirable properties below. The properties are merely intended 269 to be a yardstick to analyse existing and future solutions against. 270 They are not meant to be an all-or-nothing set of requirements. 272 The list is in no particular order of importance. 274 4.1 Security 276 There are a number of IPv6 transition-specific issues. The tunnel 277 solution should address these, e.g. the tunnel decapsulators must be 278 able to verify that the packets being decapsulated come from a valid 279 tunnel-endpoint. This probably implies bidirectional tunneling and 280 some kind of authentication payload. 282 Consideration for detection or prevention of (distributed) 283 denial-of-service attacks should also be made. 285 4.2 Simplicity 287 A simpler solution should be favoured over a complex one. 289 4.3 Ease of Management 291 The tunnel service should be as easy to manage as possible. For the 292 ISP it should thus have minimal configuration load, and it should be 293 manageable within the management framework deployed by the ISP. 294 Faults should be easy to troubleshoot from the ISP or customer side. 296 4.4 Handling Dynamic IPv4 Addresses 298 The solution should be able to handle the customer-side IPv4 tunnel 299 end point address changing, as will be the case where the customer is 300 with an ISP that applies a dynamic address assignment policy. 301 Ideally the customer should not have to enter a new (one-time) setup 302 process each time their ISP-assigned IPv4 address changes. For 303 example, a "tunnel brokering"-like solution with good authentication 304 may be able to meet this requirement. 306 4.5 Support for Hosts or Sites 308 The tunnel service should support one host or a site network (/48). 309 If it supports a network, it may also be beneficial to support prefix 310 delegation (or at least getting a /48). 312 4.6 Scalability 314 All solutions should be scalable, to handle a significant number of 315 customer end-points. This consideration may be more acute where a 316 relay or concentrator is "open" and perhaps anonymous, rather than 317 restricted to the customers of the ISP, such that "open" or anonymous 318 mechanisms are harder to limit. 320 4.7 NAT Traversal 322 The mechanism should be able to traverse a NAT, for end customers who 323 have their IPv4 systems behind an IPv4 NAT device. It may be that 324 the solution co-exists on a NAT device or router, with the clients 325 behind the NAT using native IPv6 to such a router and IPv4 NAT in 326 parallel. 328 An important question is also which kinds of NAT boxes one should be 329 able to traverse. One should probably also consider whether it's an 330 "IPv4" NAT traversal mechanism or an "IPv6" mechanism. There are many 331 IPv4 NAT traversal mechanisms; thus one may ask whether these need 332 re-invention, especially when they are already complex. 334 4.8 Can be Used Behind a NAT 336 Some ISPs may only give their customers private addresses, to which 337 NAT will be applied somewhere in the ISP's network (e.g., GPRS 338 networks, some xDSL networks). This is a subscenario of NAT 339 traversal. In some cases the ISP might be willing to provide IPv6 340 service to these users; the mechanism may not need to be able to 341 traverse a NAT, but at least function behind one. 343 4.9 Tunnel Service Ownership 345 It is desirable that each ISP implement their own tunnel service. It 346 may also be advantageous to the customer that their IPv4 ISP offers 347 IPv6 tunnel services as well. We may not even be able to assume 348 that the customer gets their IPv6 service from a specific ISP, rather 349 than just from an anonymous service somewhere. However, the user 350 may not have control over which anonymous service they use, or that 351 it may be local to their network, e.g. where selection of the service 352 is automatic and based on a publicly advertised anycast address from 353 some remote ISP. In such a case the relay may be far away in terms 354 of RTT and be loaded with many other customers who (probably 355 automatically) select that service. 357 4.10 Tunnel Service Discovery 359 The customer should have some method for discovering the location 360 and/or configuration for the tunnel service as transparently as 361 possible. Such service discovery would be ideal, perhaps making use 362 of a feature like anycast. 364 If such a transparent system is not possible, the solution should 365 involve only a one-time setup (as would be the case for VPN creation, 366 or DSL dial-up parameters). 368 4.11 Support for Special Services 370 The tunnel mechanism (as opposed to the service) may need to support 371 special functions for the customer, e.g. IPv6 Multicast. Route 372 optimization or NBMA links may typically eliminate the possibility 373 without significant added complexity, while a plain bidirectional 374 tunnel will probably be fine. 376 4.12 Route Optimisation 378 The tunnel service should ideally offer no worse routing for the IPv6 379 tunnel than the best IPv4 path between two sites. If customers 380 perceive higher round trip time or latency for a tunneled IPv6 381 service, they will not wish to adopt the new protocol. It may be 382 desirable for the mechanism should create "short cuts" between two 383 parties which implement the same mechanism. 385 4.13 Reverse DNS Lookups Available 387 Some network services use reverse DNS lookups as a (weak) 388 authentication mechanism. The tunnel service should thus offer an 389 IPv6 address or prefix to the customer against which a reverse DNS 390 entry can be configured (ideally by the customer, failing that by the 391 ISP, but anonymous services may fail to meet this requirement). 393 4.14 Accountability 395 If the solution uses the prefix of the ISP who offers the service, 396 the return routing is simplifed, but also some level of 397 accountability exists. However, we need to consider whether we need a 398 solution which can be offered anonymously by ISPs which don"t want to 399 provide tunnel brokers with their own addresses. 401 5. Summary 403 This document consdiers the motivations for deployment of tunneled 404 IPv6 connectivity solutions for small end sites. It outlines 405 existing architectures and lists a condidate set of desirable 406 properties against which existing or emerging tunnel solutions may be 407 analysed. That analysis should be undertaken in a subsequent 408 document. 410 6. Security Considerations 412 This draft analyses tunneling mechanisms and requirements. It does 413 not raise any new security issues. 415 Informative References 417 [1] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 418 Specification", RFC 2473, December 1998. 420 [2] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 421 Broker", RFC 3053, January 2001. 423 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 424 Clouds", RFC 3056, February 2001. 426 [4] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 427 draft-huitema-v6ops-teredo-00 (work in progress), June 2003. 429 [5] Blanchet, M., "Tunnel Setup Protocol (TSP)A Control Protocol to 430 Setup IPv6 or IPv4 Tunnels", draft-vg-ngtrans-tsp-01 (work in 431 progress), July 2002. 433 [6] Palet, J., "Forwarding Protocol 41 in NAT Boxes", 434 draft-palet-v6ops-proto41-nat-01 (work in progress), July 2003. 436 Authors' Addresses 438 Tim Chown 439 University of Southampton 441 School of Electronics and Computer Science 442 Southampton, Hampshire SO17 1BJ 443 United Kingdom 445 EMail: tjc@ecs.soton.ac.uk 447 Ronald van der Pol 448 NLnet Labs 449 Kruislaan 419 450 Amsterdam, 1098 VA 451 Netherlands 453 EMail: Ronald.vanderPol@nlnetlabs.nl 454 Pekka Savola 455 CSC/FUNET 457 Espoo, 458 Finland 460 EMail: psavola@funet.fi 462 Intellectual Property Statement 464 The IETF takes no position regarding the validity or scope of any 465 intellectual property or other rights that might be claimed to 466 pertain to the implementation or use of the technology described in 467 this document or the extent to which any license under such rights 468 might or might not be available; neither does it represent that it 469 has made any effort to identify any such rights. Information on the 470 IETF's procedures with respect to rights in standards-track and 471 standards-related documentation can be found in BCP-11. Copies of 472 claims of rights made available for publication and any assurances of 473 licenses to be made available, or the result of an attempt made to 474 obtain a general license or permission for the use of such 475 proprietary rights by implementors or users of this specification can 476 be obtained from the IETF Secretariat. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights which may cover technology that may be required to practice 481 this standard. Please address the information to the IETF Executive 482 Director. 484 Full Copyright Statement 486 Copyright (C) The Internet Society (2003). All Rights Reserved. 488 This document and translations of it may be copied and furnished to 489 others, and derivative works that comment on or otherwise explain it 490 or assist in its implementation may be prepared, copied, published 491 and distributed, in whole or in part, without restriction of any 492 kind, provided that the above copyright notice and this paragraph are 493 included on all such copies and derivative works. However, this 494 document itself may not be modified in any way, such as by removing 495 the copyright notice or references to the Internet Society or other 496 Internet organizations, except as needed for the purpose of 497 developing Internet standards in which case the procedures for 498 copyrights defined in the Internet Standards process must be 499 followed, or as required to translate it into languages other than 500 English. 502 The limited permissions granted above are perpetual and will not be 503 revoked by the Internet Society or its successors or assignees. 505 This document and the information contained herein is provided on an 506 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 507 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 508 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 509 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 510 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 512 Acknowledgment 514 Funding for the RFC Editor function is currently provided by the 515 Internet Society.