IPv6 Operations T. Chown Internet-Draft University of Southampton Expires: April 19, 2004 R. van der Pol NLnet Labs P. Savola CSC/FUNET October 20, 2003 Considerations for IPv6 Tunneling Solutions in Small End Sites draft-chown-v6ops-unmanaged-connectivity-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Tunneling IPv6 packets over the IPv4 Internet played a major role in the early stages of IPv6 deployment. This was useful because in the early days the routers in the internet did not support IPv6. Nowadays, tunneling is used to get across legacy equipment and ISPs that do not support IPv6. Many different tunneling mechanisms have been invented. This document describes the drivers for IPv6 tunneling, the general architectures of existing mechanisms, and a set of desirable properties against which subsequent analysis of the mechanisms may be made. The document is aimed at small end sites Chown, et al. Expires April 19, 2004 [Page 1] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 that may typically utilise tunneling methods in an early IPv6 deployment. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivations for Tunneling . . . . . . . . . . . . . . . . . 5 2.1 Using Tunneling To Circumvent Legacy ISPs . . . . . . . . . 5 2.2 Using Tunneling To Get Across Legacy NAT Boxes . . . . . . . 5 3. Tunneling Architectures . . . . . . . . . . . . . . . . . . 6 3.1 Configuration Aspects Of Tunneling Mechanisms . . . . . . . 6 3.2 Traffic Concentration . . . . . . . . . . . . . . . . . . . 6 3.3 (Un)managed and Dynamic/Fixed Tunneling . . . . . . . . . . 7 4. Desirable Properties of Tunneling Solutions . . . . . . . . 8 4.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Ease of Management . . . . . . . . . . . . . . . . . . . . . 8 4.4 Handling Dynamic IPv4 Addresses . . . . . . . . . . . . . . 8 4.5 Support for Hosts or Sites . . . . . . . . . . . . . . . . . 9 4.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 9 4.7 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 9 4.8 Can be Used Behind a NAT . . . . . . . . . . . . . . . . . . 9 4.9 Tunnel Service Ownership . . . . . . . . . . . . . . . . . . 9 4.10 Tunnel Service Discovery . . . . . . . . . . . . . . . . . . 10 4.11 Support for Special Services . . . . . . . . . . . . . . . . 10 4.12 Route Optimisation . . . . . . . . . . . . . . . . . . . . . 10 4.13 Reverse DNS Lookups Available . . . . . . . . . . . . . . . 10 4.14 Accountability . . . . . . . . . . . . . . . . . . . . . . . 10 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Chown, et al. Expires April 19, 2004 [Page 2] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 1. Introduction Tunneling IPv6 packets over the IPv4 Internet played a major role in the early stages of IPv6 deployment. The 6bone testbed made extensive use of encapsulating IPv6 packets in IPv4 [1]. This was useful because in the early days the routers in the Internet did not support IPv6 and tunneling made it possible to build a virtual worldwide IPv6 network without changes to the IPv4 production routers and to experiment with the IPv6 protocol. Nowadays, tunneling is used to get across legacy equipment and ISPs that do not support IPv6. This document describes the motivations for IPv6 tunneling, the general architectures of existing mechanisms, and a set of desirable properties against which subsequent analysis of the mechanisms may be made. The document is aimed at small end sites that may typically utilise tunneling methods in an early IPv6 deployment. A number of tunneling solutions have been devised, and continue to be devised. While ultimately when consumers really need IPv6 the ISPs are very likely to then offer a native service, at present the perceived demand at the ISPs is low, thus those sites wanting early connectivity need tunneling methods. It can be argued that we should not try to force IPv6 deployment by inventing complex protocols and setups that are difficult to manage. Similarly the very presence of automatic mechanisms, typically not provided by the ISP in question, may reduce the ISPs' perceived customer demand even further. We also note that some ISP practices will make the deployment of tunneling solutions more difficult, e.g. the use of dynamic IPv4 address allocations to customers. This document recognises the need to consider current operational practices, so that the recommendations we may base upon the considerations in this document, and the assumptions we make, may be more likely to be useful. The goal of this document is to enable a trade-off analysis for existing mechanisms that may include but not be limited to: o Tunnel broker [2], with TSP [5] o 6to4 [3] o Teredo [4] in addition to as yet undefined mechanisms or minor modifications or extensions to current mechanisms. In this document, rather than compare specific methods, we refer to the general methods, e.g. of a "6to4-like" service. Chown, et al. Expires April 19, 2004 [Page 3] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 We aim to keep the analysis logically different from this considerations document. We do not want to be solution-centric, rather problem-centric. Analysis should be done in a separate document. Chown, et al. Expires April 19, 2004 [Page 4] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 2. Motivations for Tunneling Most tunneling mechanisms are intended for use in the early stages of IPv6 deployment. Some try to bypass IPv4-only ISPs that do not offer IPv6 services. Others try to bypass NAT boxes that do not support IPv6, while also bypassing the ISPs which do not offer IPv6 services (tackling both problems in one). Mechanisms only passing the NAT box seem rather rare. None of the mechanisms are needed when the ISP starts offering IPv6 services or when the NAT box is replaced by an IPv6-aware box. When considering the various tunneling mechanisms it is important to know what problem they try to solve. Most do not seem to solve real technical problems as such, and are instead a workaround for a lack of native IPv6 deployment. The tradeoff between (possibly complex) tunneling mechanisms and waiting for IPv6 deployment should be carefully analysed. Similarly, the cost to an ISP of supporting "early adopter" tunneling services as opposed to deploying a pilot native service should be considered. However, the reality is that tunneling solutions will be an important tool for the introduction of IPv6 services for some time to come, hence this document focuses on desirable properties for such solutions. 2.1 Using Tunneling To Circumvent Legacy ISPs Tunneling can be used to get IPv6 connectivity across ISPs that do not offer IPv6 yet. Ideally a customer's ISP would offer them a native IPv6 service. However, in the absence of such a native IPv6 service a tunneled solution is the only real option for an early adopter of IPv6. We thus need to consider the desirable properties of such a tunneled solution. 2.2 Using Tunneling To Get Across Legacy NAT Boxes Tunneling can also be used to get across legacy equipment (e.g. a SOHO router) that does not support IPv6 yet. When ISPs start to offer a native IPv6 service on a large scale, SOHO router manufacturers are likely to introduce IPv6-enabled SOHO routers. In the meantime, many customers will require some method to gain an IPv6 service in the presence of a NAT. While trying to invent a complex protocol to try to send IPv6 traffic at any cost is probably not the best technical solution, it is one of necessity. In such a situation ownership and access to the configuration of the NAT device is an issue. Where ownership is held by the customer, they have the technical knowledge, and have only one internal host or network to establish a tunnel to, Protcol 41 forwarding [6] may enable a tunnel to pass through such a NAT. Chown, et al. Expires April 19, 2004 [Page 5] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 3. Tunneling Architectures The examples of specific existing solutions listed in the Introduction can be generalised, e.g.: o A tunnel brokering service by which a host or network may obtain a tunnel service by a one-time interaction which leads to the establishment of a tunnel service to a tunnel concentrator, and from there to the wider IPv6 internet. The tunnel concentrator may reside either at a local or remote ISP. A NAT traversal may also be included, using an additional encapsulation. Tunnel brokering services may use a tunnel setup protocol for ease of management, whereby tunnels are set up automatically and the mechanism has the possibility of authentication. o An automatic tunneling service by which a host or network may obtain an automatic tunnel service to any other host or site supporting the same service. While such traffic does not require use of a concentrator, connectivity to the native IPv6 internet requires use of such a relay. o A NAT traversal service by which a host behind an IPv4 NAT may gain tunneled connectivity to the external IPv6 internet by way of a tunnel concentrator or server, while a part of communications between the service's users is designed to go directly via "short-cuts". By these general descriptions we can refer to, for example, a "tunnel broker-like" service. Each mechanism may have a different philosophy, but each may also target a different problem (e.g. NAT traversal). Each will have a different architecture. 3.1 Configuration Aspects Of Tunneling Mechanisms Tunneling always involves encapsulating at one end of the tunnel and decapsulating at the other end of the tunnel. When encapsulating, the IPv4 address of the other side of the tunnel is needed. For some mechanisms this information needs to be configured manually. For other mechanisms the information is obtained via a special protocol (e.g. TSP [5]), one time setup (e.g. manually configured tunnel broker) or automatically (e.g. 6to4 [3]). Tunnels can be either unidirectional or bi-directional. 3.2 Traffic Concentration Some tunneling mechanisms send all traffic to the same tunnel end-point. This end-point acts as a concentration point. Other tunneling mechanisms use a tunnel end-point based on the destination Chown, et al. Expires April 19, 2004 [Page 6] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 of the traffic. They send traffic over the same path as the IPv4 traffic. In this case there is no concentration point. The use of concentrator points will have implications for the scalability of the solution, and may also raise concerns over the point of failure it represents (especially where denial of service attacks may be directed at that point). However, a seemingly de-centralized model (e.g. deployment using anycast) may in fact also practically incur traffic concentration problems if only a small amount of concentrators are being used. 3.3 (Un)managed and Dynamic/Fixed Tunneling There is a subtle distinction between managed or unmanaged and manual or automatic tunnel services. The distinction from the point of view of the tunnel is that it may be fixed (to a pre-configured remote IPv4 address) or dynamic (the tunnel is established on demand to any given remote IPv4 address, whereby the remote IPv4 address is based on the packet destination address and each destination has its own remote IPv4 address). Either the fixed or dynamic tunnels may be managed or unmanaged, although all dynamic mechanisms are unmanaged. Chown, et al. Expires April 19, 2004 [Page 7] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 4. Desirable Properties of Tunneling Solutions In this section we list the desirable properties that a tunnel service may have, from the view of the customer, the ISP, or both the customer and ISP. We do not categorise them as such at this point, but may do so in a future revision of this document if it is deemed useful to do so; such a future revision may also go into further discussion of tradeoffs rather than purelybeing a list of desirable properties. Note that it is unlikely that a single tunnel solution will meet all the desirable properties below. The properties are merely intended to be a yardstick to analyse existing and future solutions against. They are not meant to be an all-or-nothing set of requirements. The list is in no particular order of importance. 4.1 Security There are a number of IPv6 transition-specific issues. The tunnel solution should address these, e.g. the tunnel decapsulators must be able to verify that the packets being decapsulated come from a valid tunnel-endpoint. This probably implies bidirectional tunneling and some kind of authentication payload. Consideration for detection or prevention of (distributed) denial-of-service attacks should also be made. 4.2 Simplicity A simpler solution should be favoured over a complex one. 4.3 Ease of Management The tunnel service should be as easy to manage as possible. For the ISP it should thus have minimal configuration load, and it should be manageable within the management framework deployed by the ISP. Faults should be easy to troubleshoot from the ISP or customer side. 4.4 Handling Dynamic IPv4 Addresses The solution should be able to handle the customer-side IPv4 tunnel end point address changing, as will be the case where the customer is with an ISP that applies a dynamic address assignment policy. Ideally the customer should not have to enter a new (one-time) setup process each time their ISP-assigned IPv4 address changes. For example, a "tunnel brokering"-like solution with good authentication may be able to meet this requirement. Chown, et al. Expires April 19, 2004 [Page 8] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 4.5 Support for Hosts or Sites The tunnel service should support one host or a site network (/48). If it supports a network, it may also be beneficial to support prefix delegation (or at least getting a /48). 4.6 Scalability All solutions should be scalable, to handle a significant number of customer end-points. This consideration may be more acute where a relay or concentrator is "open" and perhaps anonymous, rather than restricted to the customers of the ISP, such that "open" or anonymous mechanisms are harder to limit. 4.7 NAT Traversal The mechanism should be able to traverse a NAT, for end customers who have their IPv4 systems behind an IPv4 NAT device. It may be that the solution co-exists on a NAT device or router, with the clients behind the NAT using native IPv6 to such a router and IPv4 NAT in parallel. An important question is also which kinds of NAT boxes one should be able to traverse. One should probably also consider whether it's an "IPv4" NAT traversal mechanism or an "IPv6" mechanism. There are many IPv4 NAT traversal mechanisms; thus one may ask whether these need re-invention, especially when they are already complex. 4.8 Can be Used Behind a NAT Some ISPs may only give their customers private addresses, to which NAT will be applied somewhere in the ISP's network (e.g., GPRS networks, some xDSL networks). This is a subscenario of NAT traversal. In some cases the ISP might be willing to provide IPv6 service to these users; the mechanism may not need to be able to traverse a NAT, but at least function behind one. 4.9 Tunnel Service Ownership It is desirable that each ISP implement their own tunnel service. It may also be advantageous to the customer that their IPv4 ISP offers IPv6 tunnel services as well. We may not even be able to assume that the customer gets their IPv6 service from a specific ISP, rather than just from an anonymous service somewhere. However, the user may not have control over which anonymous service they use, or that it may be local to their network, e.g. where selection of the service is automatic and based on a publicly advertised anycast address from some remote ISP. In such a case the relay may be far away in terms Chown, et al. Expires April 19, 2004 [Page 9] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 of RTT and be loaded with many other customers who (probably automatically) select that service. 4.10 Tunnel Service Discovery The customer should have some method for discovering the location and/or configuration for the tunnel service as transparently as possible. Such service discovery would be ideal, perhaps making use of a feature like anycast. If such a transparent system is not possible, the solution should involve only a one-time setup (as would be the case for VPN creation, or DSL dial-up parameters). 4.11 Support for Special Services The tunnel mechanism (as opposed to the service) may need to support special functions for the customer, e.g. IPv6 Multicast. Route optimization or NBMA links may typically eliminate the possibility without significant added complexity, while a plain bidirectional tunnel will probably be fine. 4.12 Route Optimisation The tunnel service should ideally offer no worse routing for the IPv6 tunnel than the best IPv4 path between two sites. If customers perceive higher round trip time or latency for a tunneled IPv6 service, they will not wish to adopt the new protocol. It may be desirable for the mechanism should create "short cuts" between two parties which implement the same mechanism. 4.13 Reverse DNS Lookups Available Some network services use reverse DNS lookups as a (weak) authentication mechanism. The tunnel service should thus offer an IPv6 address or prefix to the customer against which a reverse DNS entry can be configured (ideally by the customer, failing that by the ISP, but anonymous services may fail to meet this requirement). 4.14 Accountability If the solution uses the prefix of the ISP who offers the service, the return routing is simplifed, but also some level of accountability exists. However, we need to consider whether we need a solution which can be offered anonymously by ISPs which don"t want to provide tunnel brokers with their own addresses. Chown, et al. Expires April 19, 2004 [Page 10] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 5. Summary This document consdiers the motivations for deployment of tunneled IPv6 connectivity solutions for small end sites. It outlines existing architectures and lists a condidate set of desirable properties against which existing or emerging tunnel solutions may be analysed. That analysis should be undertaken in a subsequent document. Chown, et al. Expires April 19, 2004 [Page 11] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 6. Security Considerations This draft analyses tunneling mechanisms and requirements. It does not raise any new security issues. Chown, et al. Expires April 19, 2004 [Page 12] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 Informative References [1] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [2] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [4] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-00 (work in progress), June 2003. [5] Blanchet, M., "Tunnel Setup Protocol (TSP)A Control Protocol to Setup IPv6 or IPv4 Tunnels", draft-vg-ngtrans-tsp-01 (work in progress), July 2002. [6] Palet, J., "Forwarding Protocol 41 in NAT Boxes", draft-palet-v6ops-proto41-nat-01 (work in progress), July 2003. Authors' Addresses Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Ronald van der Pol NLnet Labs Kruislaan 419 Amsterdam, 1098 VA Netherlands EMail: Ronald.vanderPol@nlnetlabs.nl Chown, et al. Expires April 19, 2004 [Page 13] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 Pekka Savola CSC/FUNET Espoo, Finland EMail: psavola@funet.fi Chown, et al. Expires April 19, 2004 [Page 14] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Chown, et al. Expires April 19, 2004 [Page 15] Internet-Draft IPv6 Tunneling in Small End Sites October 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chown, et al. Expires April 19, 2004 [Page 16]