Internet Engineering Task Force A.Durand INTERNET-DRAFT SUN Microsystems,inc. June, 24, 2004 F. Parent Expires December 23, 2004 Hexago Requirements for assisted tunneling <draft-ietf-v6ops-assisted-tunneling-requirements-00.txt> 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 September 28, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines requirements for a tunnel set-up protocol that could be used by an ISP to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity without having to upgrade its access network. 1. Goal and Scope of the Document The v6ops working group has worked on requirements and scenarios for IPv6 deployment by soliciting input from network operators. This work has identified a need for an "assisted tunneling" mechanism. For example, an ISP starting its IPv6 offering to its customers without upgrading its access network to support IPv6 could use a "tunnel brokering solution" [ISP, section 5.1.] a la . What has been identified as missing from that RFC is a tunnel set-up protocol. In an ISP network, getting IPv6 connectivity to the customers involves upgrading the access network to support IPv6, which can take a long time and/or be costly. A tunneled infrastructure can be used as a low cost migration path [ISP, section 5.1]. With such an infrastructure, the ISP can connect its customers to its IPv6 network using its production IPv6 address space, thus facilitating migration towards native IPv6 deployment. The IPv6 deployment roadmap for connecting customers becomes: - assisted tunneling infrastructure to early adopters, - native IPv6 to customers where economically justified, - native IPv6 to all customers. Note that, as the addressing space used during the transition to native remains the same the customer routing, filtering, accounting [ISP, section 5.] stay the same, and there is no need to maintain any kind of relay. "Assisted tunneling" is used in this document to described a transition mechanism where the parameters to configure a bi- directional tunnel between an end-node (or leaf network) and a router in the core of an ISP are exchanged through a tunnel set-up protocol. Although this exchange can be automated, this remains different from transition mechanisms like 6to4 that is fully automatic. Teredo and ISATAP, on the other hand, practically require receiving information about the available prefix or address from the server/router, comparable to the most simple form of assisted tunneling. In particular, the 'registered' mode defined in section 4 enables explicit access control to the tunneled IPv6 connectivity, where the other transion mechanisms have to rely on other kinds of control (e.g., access control based on the IPv4 address). This document analyze the requirements for such a tunnel set-up protocol. The v6ops WG scenario and evaluation documents for deploying IPv6 within common network environments are used as input to this document. 2. Applicability Assisted tunneling is applicable in different IPv6 transition scenarios. The focus of this document is to define the requirements to apply this mechanism in the IPv4 ISP context making the following assumptions: - ISP is offering IPv6 connectivity to its customers initially using controlled tunneling infrastructure [ISP, 5.1 Steps in Transitioning Customer Connection Networks] - The customer configuration may be diverse, and not necessarily predictable by the ISP. The protocol must be able to adapt to the following cases, for example by choosing the most optimal tunnel encapsulation depending on the presence of a NAT. - a single node, - a leaf network, - using a globally routable IPv4 address, - behind a NAT (customer or ISP owned), - using dynamic IPv4 address (internally or externally to the NAT) There are actually two cases where the IPv4 address of the customer tunnel end point can be dynamic, and both must be supported: - The device used as tunnel end point is using a dynamic IPv4 address provided by the ISP. - The device used as tunnel end point is located behind a customer owned NAT box that is also acting as a local DHCP server. In that case, the device IPv4 address may change after a reboot. Althought the main focus of this document is the ISP scenario, assisted tunneling is applicable in all the other scenarios: unmanaged, enterprise and 3GPP. In unmanaged networks, assisted tunneling is applicable in the case A (a gateway which does not provide IPv6 at all) [UNMANAGED, section 3] and C (a dual-stack gateway connected to an IPv4-only ISP) [UNMANAGED, section 5]. In 3GPP networks, assisted tunneling can be used in the context of dual stack UE connecting to IPv6 nodes through a 3GPP network that only supports IPv4 PDP contexts [3GPP, 3.1]. 3. Requirements for Simplicity The tunnel set-up protocol must be simple to implement and easy to deploy. In particular, it should not depend on any complex, yet to be designed, protocols or infrastructure pieces. This protocol is a transition mechanism, thus does not need to be perfect. As a matter of fact, making it perfect would be counter productive, at it would first delay its definition, then make its deployment more cumbersome and, last but not least, diminish the incentives to deploy native IPv6. 4. Protocol Requirements Assisted tunneling can be provided in two different modes. "Non- registered" mode is a simple mode with no user registration, essentially deployed in a controlled and "authenticated" environment where the service is made available to all the IPv4 customers.. The "registered" mode is aimed at production deployment which requires the user to be authenticated. This mode can be used to offer the tunneling service to roaming users or restrict the service to specific (authenticated) users. The tunnel set-up protocol must support both modes, however ISP deploying it may choose to only support one mode of operation. Assisted tunneling in the non-registered mode is defined for simple "plug & play" scenarios. In this mode, the tunnel establishment is triggered through the execution of a simple program, without any pre- configuration or pre-registration required from the end-user. The tunnel established is "anonymous" in a sense as the end-user does not register explicitly to the server. An ISP using the protocol in this mode may be offering a free service and doesn't wish to require any form of registration. This free service can also be used to offer trial IPv6 service limited to the ISP customers by relying on IPv4 access control. The registered mode offers some extra features documented in latter sections. This mode is most valuable in a provider network where deployment of IPv6 is done in a more controlled manner or when the provider cannot rely on IPv4 related authentication (e.g. roaming customers). In such networks, ease of debugging, traceability, filtering and so on are important features. 4.1. Address and Prefix Delegation Assignment of an IPv6 address (/128) to the end-node must be supported in both modes. In non-registered mode, the IPv6 address is "transient" and may change, but the protocol SHOULD offer a mechanism to provide IPv6 address stability in this mode (e.g. cookie mechanism). The implementation of this mechanism MUST allow this feature to be turned off. In registered mode, the protocol MUST be able to support servers willing to offer stable IPv6 prefixes to the authenticated customers. The registered mode MUST support delegation of a single address or a whole prefix. The length of the IPv6 prefix delegated MUST be configurable on the server. The non-registered mode MAY support prefix delegation. See section 5.9 for DNS considerations. 4.2 Registration The registration of credentials is external to the protocol. A service provider SHOULD be able to use its existing authentication database. If necessary, an implementation may provide hooks to facilitate integration with the ISP management infrastructure (e.g. RADIUS for AAA, billing). The protocol MAY send information about registration procedure when a non-registered client requests registered mode (ex: URL to provider registration web page). 4.3. Authentication The authentication mechanism supported should be compatible with standardized methods that are generally deployed. In order to assure interoperability, at least one common authentication method MUST be supported. Other authentication MAY be supported and should be negotiated between the client and server (e.g., SASL ). 4.4. Service Discovery In order to offer "plug & play", the implementation SHOULD allow a mechanism to discover the address of the server that will provide the tunnel connectivity. This discovery should be automatic within an ISP network. 4.5. NAT Traversal Tunneling through IPv4 NAT MUST be supported. The protocol should detect if an IPv4 NAT is in the path during the set-up phase (section 5.3). If a NAT is present, an extra level of encapsulation is necessary to tunnel IPv6 across the NAT. If no NAT is detected, IPv6-over-IPv4 tunneling (IP protocol 41) is enough. 4.6. Firewall Traversal Even if no NAT is in the tunnel path, there may be a firewall which prohibits IP protocol 41. In such case, the tunnel encapsulation selection based on NAT detection (section 5.3) will select a tunnel that will not work. The implementation MUST allow a user to explicitly specify the desired tunnel encapsulation, regardless of the NAT detection process. 4.7. Accounting The assisted tunneling should include tools for managing and monitoring the provided service. Such information can be used to plan service capacity (traffic load) or billing information. Some useful accounting data are (not exhaustive list): - Tunnel counters (traffic in/out) - User utilization (tunnel uptime) - System logging (authentication failures, resource exhaustion, etc.) The interface used to provide such information can be through SNMP or an AAA protocol (e.g., RADIUS accounting). 4.8. Security Threat Analysis The non registered mode does not require explicit authentication of the user. Access control may be performed using e.g., IPv4 address. The mode essentially offer the IPv6 service to any of its IPv4 customers. Deployment of the service with this mode must be done carefully. In particular, security considerations must be taken into account. Non registered service should be limited to the provider network, where access of the service can be controlled based on the IPv4 address of the users (filtering). If specific filtering is not in place in the ISP core network, anyone on the Internet could start using its tunneling infrastructure to get free IPv6 connectivity, transforming effectively the ISP into a IPv6 transit provider. If IPv4 address spoofing is possible within the access network, a number of DoS attack can happen. For example, customer A can impersonate someone else's IPv4 address during the set-up phase and redirect a tunnel to that IP address. A then can, for example, start a high bandwidth multimedia flow across that tunnel and saturate its victim's up-link. But even with filtering in place, the non registered mode is vulnerable to denial of service attacks: a customer A behind a NAT can use a large number of (private) IPv4 addresses and request multiple tunnels.That would quickly saturate the ISP tunnel server infrastructure. In order to minimize such attacks, IPv4 return routability checks could help blocking many DoS attack. Also, the server implementation should offer a way to throttle and limit the number of tunnel established to the same (non-private) IPv4 address. In registered mode, the protocol must make sure that the tunnel is established to the legitimate and authenticated destination, again to avoid having someone establish a tunnel to a potential victim. IPv4 return routability checks could help block possible DoS attacks. 5. General Requirements 5.1 Scalability The tunnel set-up protocol must be scalable. Typically, this protocol should be deployable in broadband ISP. 5.2 Service discovery requirements The discovery part of the tunnel set-up protocol should be as automatic as possible. The discovery mechanism must be able to scale for large ISP who cover different geographical areas and/or have a large number of customers. Customers may very well try to use this tunnel set-up protocol even if their ISP is not offering the service. In this case, without any previous action taken by their ISP, the discovery part of the tunnel set-up protocol must be able to abort immediately and display the customers a message explaining that no service is available. 5.3 NAT Considerations The assisted tunnel established by the protocol to be designed must work with the existing infrastructure, in particular it must be compatible with the various customer premise equipments available today. This means that, in particular, the tunnels must be able to traverse one or many NAT boxes of different kinds. There is no requirement for any particular NAT traversal technology. However, as NAT traversal usually requires an extra layer of encapsulation, the tunnel set-up protocol SHOULD be able to detect automatically the presence of one or more NAT boxes in the path. The implementation MUST provide an option to to turn on extra encapsulation manually. In order to assure interoperability, at least one common tunnel encapsulation type MUST be supported. 5.4 Keep-alive When a tunnel has to cross a NAT box, the mapping established by the NAT must be preserved as long as the tunnel is in use. This is usually achieved by sending keep alive messages across the tunnel. Also, the same keep alive messages can enable the ISP tunnel end point to perform garbage collection of its resources when tunnels are not in use anymore. To enable those two functionalities, the tunnel set-up protocol must include the transmission of keep-alive messages. A client MAY choose not to send those messages (for example on ISDN type links), but should then expect that the tunnel may be disconnected at any time by the ISP and be prepared to restart the set-up phase. 5.5 Latency in Set-up Phases In certain type of networks, keeping tunnels active all the time is not possible (e.g., limited number of tunnels on server) or simply too expensive (e.g., wireless environments where periodic transmission is expensive). In those environments, the protocol must be able to set-up tunnels on demand of the IPv6 applications requiring external connectivity. The tunnel set-up protocol must then have a low enough latency to enable quasi-instant configuration. Latency is usually a function of the number of packet exchanges required, so minimizing this parameter is important. 5.6 Security The tunnel set-up protocol must not introduce any new vulnerability to the network. 5.7 Traceability In production environment, traceability is an important consideration. The tunnel set-up protocol must be instrumentable to enable the collection of usage data that can be used, for example, for capacity planning. 5.8 Phase Out This assisted tunneling mode is only a transition mechanism to enable ISP to jump start IPv6 service without requiring an immediate global upgrade of access networks and instead enabling a progressive roll out. Once IPv6 is available natively in the access network connecting a customer, there is no reason to keep using tunnels. So the implementation SHOULD have a provision to enable the ISP to signal the user to use native IPv6 instead. 5.9 Extensibility The protocol MUST be extensible to support tunnel encapsulation other than IPv6 over IPv4 and IPv6 over transport over IPv4. In particular, encapsulation of IPv4 over IPv6 or IPv6 over IPv6 could be defined. 5.10 DNS considerations It should be possible to have the server side of the protocol automatically register the assigned IPv6 address in the DNS system (AAAA and PTR records) using the ISP name space. Nothing specific is required in the protocol to support this. The details can be implementation specific. If stable prefix delegation is done, it is expected that the DNS delegation of the associated reverse DNS zone will be also stable and thus can be performed out of band, so there is no requirement to perform this delegation at the tunnel set-up time. 6. Compatibility with other Transition Mechanisms 6.1 TSP The tunnel set-up protocol is not required to be compatible with TSP [TSP] or any particular implementation of the tunnel broker model . Although, a great deal of experience can be drawn from the operation of tunnel brokers currently using the TSP protocol. 6.2 TEREDO There is a large number of Teredo clients already deployed, the tunnel set-up protocol should explore the avenue of providing a compatibility mode with Teredo, at least in the 'simple' mode described in section 4. However, it may turn out that supporting a compatibility mode with Teredo either requires to change the Teredo specifications and/or implement Teredo on the tunnel server side. In that case, it might be simpler to say that the compatibility mode should be manage on the client side instead of the server side, that is leave it up to the client to use either one of them. 6.3 ISATAP Similar considerations as Teredo, section 6.2, applies to Isatap. However, as Isatap can not work accross NAT, it is of much less interest in the framework of this document. 7. Security Considerations The establishment of a tunnel can be compared to Mobile IP technology, where traffic can be redirected to go from one place to another one. So similar threats exists. In particular, when a customer is asking for the set-up of a tunnel ending at IP address X, the ISP should check: - the customer is allowed to set-up this tunnel, i.e. he "owns" the IPv6 prefix. - the customer is allowed to terminate the tunnel where he said he would, i.e. he "owns" the IPv4 tunnel endpoint. The first check is simply an authentication issue. The second may be more complex, but can be omitted if strict ingress filtering is in place in the access network, i.e. the customer is effectively prevented from sending packet with an IPv4 source address he does not own. See section 4.4 for specific security consideration in the non- authenticated mode. 8. Acknowlegements 9. Author Addresses Alain Durand SUN Microsystems, Inc 17 Network circle UMPK17-202 Menlo Park, CA, 94025 USA Mail: Alain.Durand@sun.com Florent Parent Hexago 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Mail: Florent.Parent@hexago.com 10. Normative References  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  A. Durand, P. Fasano, I. Guardini, D. Lento., "IPv6 Tunnel Broker", January 2001. [ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6 into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-01 (work in progress), February 2004. [UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work in progress), February 2004. [3GPP] J. Wiljakka, "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March 2004. 11. Informative References  Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.  Myers, J., "Simple Authentication and Security Layer (SASL)", RFC2222, October 1997. [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-21 (work in progress), April 2004. [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-01 (work in progress), February 2004. [TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 (work in progress), February 2004. Appendix 1. Summary of the Protocol Requirements The non registered mode: - MUST be supported by the protocol to be designed - RECOMMENDED to be implemented on client and servers/brokers - implementation SHOULD turn it on be default - implementation MUST allow it to be turned off - MUST support single address assignment - SHOULD support stable IPv6 address - MAY support prefix delegation The registered mode: - MUST be supported by the protocol - RECOMMENDED to be implemented on clients and servers/brokers - implementation SHOULD turn it off by default - implementation MUST allow it to be turned on - MUST support single address assignment - MUST support stable IPv6 address - MUST support prefix delegation, SHOULD be able to turn off The registered part of the protocol SHOULD not be too different from the non registered one, so as to minimize code difference between the two modes 12. Full Copyright Statement 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 (2004). 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 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.