Internet Engineering Task Force R. Suryanarayanan Internet-Draft S. Madanapalli Expires: April 18, 2005 Samsung India Software Operations K. E. Nielsen Ericsson F. Parent Hexago J. Palet Consulintel October 18, 2004 Zero-Configuration Tunneling Requirements draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document describes the set of goals to be fulfilled by a Suryanarayanan, et al. Expires April 18, 2005 [Page 1] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Zero-Configuration Tunneling protocol. Zero-Configuration Tunneling here denotes an automatic tunneling mechanism that could be used by a Service Provider to offer IPv6 connectivity to its customers in early phases of IPv4 to IPv6 transition. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 IPv6 address allocation, Scope and Limitations . . . . . . 6 4.2 IPv6 tunnel link characteristics, Scope and Limitations . 6 5. Basic Assumptions and Prerequistes . . . . . . . . . . . . . 6 6. Requirements for Zero-Configuration Tunneling Mechanisms . . 7 6.1 Basic Requirements . . . . . . . . . . . . . . . . . . . . 7 6.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 8 6.1.2 Automated IPv6-in-IPv4 tunnel establishment . . . . . 8 6.1.3 IPv6 Address Assignment and Prefix Delegation . . . . 8 6.1.4 Use Native Connectivity When available . . . . . . . . 8 6.1.5 Tunnel Server End-Point Discovery . . . . . . . . . . 9 6.1.6 Tunnel End-Point Reachability Detection . . . . . . . 9 6.1.7 Private and public IPv4 addresses . . . . . . . . . . 9 6.1.8 Scalability and Load-Balancing . . . . . . . . . . . . 9 6.1.9 Easy to deploy and Easy to Phase Out . . . . . . . . . 9 6.1.10 Latency in Set-up Phases . . . . . . . . . . . . . . 10 6.1.11 Security . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Advanced Requirements . . . . . . . . . . . . . . . . . . 10 6.2.1 Tunnel Link Sustainability . . . . . . . . . . . . . . 10 6.2.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . 11 6.2.3 Firewall Traversal . . . . . . . . . . . . . . . . . . 11 6.2.4 Extensibility . . . . . . . . . . . . . . . . . . . . 11 6.2.5 IPv6 Address Stability . . . . . . . . . . . . . . . . 11 7. 3GPP Specific Requirements . . . . . . . . . . . . . . . . . 12 8. Unmanaged Networks Specific Requirements . . . . . . . . . . 12 8.1 Address Assignment and Prefix Delegation . . . . . . . . . 12 8.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 12 8.3 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 8.4 Tunnel Link Sustainability . . . . . . . . . . . . . . . . 13 8.5 Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 8.5.1 IPv4-in-IPv6 Tunneling . . . . . . . . . . . . . . . . 13 8.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 9. Enterprise Network Requirements . . . . . . . . . . . . . . 13 9.1 IPv6 Address Assignment and Prefix Delegation . . . . . . 14 9.2 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 14 9.3 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 14 Suryanarayanan, et al. Expires April 18, 2005 [Page 2] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 9.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . 15 9.4.1 IPv4-in-IPv6 Tunneling . . . . . . . . . . . . . . . . 15 10. ISP Network Specific Requirements . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . 15 11.1 Access Control . . . . . . . . . . . . . . . . . . . . . 15 11.2 General Threats . . . . . . . . . . . . . . . . . . . . 16 11.3 Threats to nodes implementing Zero-Configuration Tunneling . . . . . . . . . . . . . . . . . . . . . . . 17 11.3.1 Threats to end-hosts . . . . . . . . . . . . . . . . 17 11.3.2 Threats to Tunnel Servers . . . . . . . . . . . . . 18 11.4 Implications of Direct Tunneling . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1 Normative References . . . . . . . . . . . . . . . . . . . 20 13.2 Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 A. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 24 Suryanarayanan, et al. Expires April 18, 2005 [Page 3] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 1. Introduction The IETF v6ops Working Group has identified and analyzed deployment scenarios for IPv4/IPv6 transition mechanisms in various stages of IPv6 deployment and IPv6 and IPv4 coexistence. This work has been carried out for a number of different network environments each with their particular characteristics: Enterprise, ISP, Unmanaged and 3GPP networks, see e.g. [1], [2], [3] and [4]. The work has identified a need for automatic IPv6-in-IPv4 tunneling mechanisms that provide bidirectional IPv6-in-IPv4 tunneled connectivity between dual stack end-nodes located at an IPv4-only access network and dual-stack tunnel servers located at IPv6-IPv4 network boundaries within the Service Providers network. The term Zero-Configuration Tunneling is used in this document to denote a tunneling mechanism that fulfills the goals as put forward here. A Zero-Configuration Tunneling mechanism provides a set of minimal features required for automatic establishment of IPv6 connectivity. For scenarios demanding advanced tunneling features, for example full emulation of native (though tunneled) IPv6 connectivity, a more full-fledged tunneling mechanism is envisaged to be deployed, see [5]. With respect to the latter, an analysis of appropriate mechanisms for automatic discovery of the tunnel endpoint is being done in [6], which will be also useful for the zero-configuration tunneling protocol. One of the major differences between the zero-configuration tunneling mechanism and the full-fledged tunneling mechanism is that the former does not support user authentication, which should not be an issue because the scope of the users of this mechanism are already users of the Service Provider actually deploying it. Consequently, the users are to be authenticated by other means, which are out of the scope of this document. It should be emphasized that unless otherwise specified, in this document the reference, IPv6-in-IPv4 encapsulation as defined in [7], refers to the aspects of Protocol-41 encapsulation related to IPv4 header construction (except for source and destination address determination), MTU and Fragmentation, Hop Limits and ICMP handling as detailed in Section 3.1-3.6 of [7]. The particular aspects of Configured IPv6-In-IPv4 Tunneling in the areas of IPv4 source and destination address determination, tunnel link characteristics and IPv6 Neighbor Discovery operation are not intended referred to by the Suryanarayanan, et al. Expires April 18, 2005 [Page 4] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 above reference. This document only identifies requirements for a zero-configuration tunneling mechanism, based on which solutions can be developed or identified. 2. Terminology Zero-Configuration Tunneling site: A logical IPv4 network over which IPv6 connectivity is provided to dual-stack nodes by means of Zero-Configuration Tunneling. Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4 tunnel encapsulation/decapsulation in accordance with Zero-Configuration Tunneling. Tunnel Server (TS): A dual-stack server node with IPv6 connectivity and which provides IPv6 connectivity to client nodes by performing IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes in accordance with Zero-Configuration Tunneling. A Tunnel Server is likely to be a dual-stack router. Tunnel Client: A dual-stack node that obtains IPv6 connectivity by means of Zero-Configuration Tunneling. A tunnel client relies on IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from Tunnel Servers for IPv6 communications to native IPv6 nodes. Direct Tunneling: Direct tunnelling here refer to the case where end-hosts located within the same Zero-Configuration Tunnelling site may circumvent the Tunnel Server and communicate directly using the tunnel protocol. CPE: Customer Premises Equipment. 3. Applicability Zero-Configuration Tunneling is applicable in different IPv6 transition scenarios. The focus of this document is to define the requirements for Zero-Configuration Tunnelling mechanism in the following Service Provider contexts: o 3GPP scenarios [4]. o Unmanaged network scenarios [3]. o ISP scenarios [2]. o Enterprise scenarios [1]. Suryanarayanan, et al. Expires April 18, 2005 [Page 5] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Zero-Configuration Tunneling does not attempt to provide emulation of the full set of native IPv6 connectivity functions as defined by [8], [9] and [10] It is possible that the same zero-configuration Tunneling mechanism can be used in various deployment scenarios. However, it is not required that same tunnel set-up protocol be deployable in all scenarios. 4. Limitations 4.1 IPv6 address allocation, Scope and Limitations It is not explicitly within the scope to support privacy extensions to IPv6 [11]. It is not explicitly within the scope to support usage of IPv6 multicast. No goals are defined as to how address configuration should be performed. This may be done based on legacy stateless or stateful IPv6 address configuration mechanisms or by some altogether different mechanism particular to the zero-configuration solution. 4.2 IPv6 tunnel link characteristics, Scope and Limitations Direct tunneling is neither an explicit goal nor explicitly excluded in Zero-Configuration Tunneling. It is not an explicit requirement for the zero-configuration tunnel link to support IPv6 link-local multicast. The tunnel protocol should allow for the formation of a link-local address on the tunnel link, though no particular usage of such an address is explicitly demanded by the goals set forward here. It is an explicit goal that nodes attached to a tunnel link must be able to ascertain the reachability of neighbors with which it is communicating (or wish to start communicate). This may be achieved using IPv6 Neighbor Discovery mechanism ([12]) based on unicast link-local packet exchanges (or link-local multicast if such is supported) but it may also be achieved by altogether different mechanisms. 5. Basic Assumptions and Prerequistes Zero-Configuration Tunneling is a tunneling mechanism by virtue of which dual-stacks hosts, attached to IPv4-only networks links, can Suryanarayanan, et al. Expires April 18, 2005 [Page 6] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 use IPv6-in-IPv4 encapsulation as defined in [7] to tunnel servers for global IPv6 connectivity. Zero-configuration Tunneling 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 aim of the document is to define the set of goals to be fulfilled by zero-configured tunneling when the following assumptions are made on the deployment environment: o The first-hop ISP is providing IPv6 connectivity. o The Tunneling protocol must not require prior registration, or require registration during the protocol set-up phases. o The Zero-Configuration Tunneling site is protected from proto-41 encapsulated packets arriving from external IPv4 networks. o At least one authoritative DNS server is IPv4-enabled and at least one recursive DNS server supports IPv4. Further IPv4 DNS Server discovery is provided by already existing means/means outside the scope of the tunnel protocol. o The user is being authenticated to the network by means external to the tunneling protocol. The following assumption is only valid for basic requirements where there is no NAT in the path. o The Zero-Configuration Tunneling network is fully penetrable for intra-site IPv6-in-IPv4 Protocol 41 traffic. It is a prerequisite that the tunnel protocol must work in IPv4 network environments where IPv4 multicast is not provided. 6. Requirements for Zero-Configuration Tunneling Mechanisms 6.1 Basic Requirements The basic requirements described below must be supported by any zero-configuration tunneling protocol. Tunneling protocol satisfying these basic requirements could be used in a deployment scenarios which is NAT-free, does not require IPv6 /64 address or prefix delegation. Suryanarayanan, et al. Expires April 18, 2005 [Page 7] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 6.1.1 Simplicity The tunnel protocol is easy to implement in the targeted environment. Additionally, the protocol should provide a reasonable,limited set of basic IPv6 connectivity features 6.1.2 Automated IPv6-in-IPv4 tunnel establishment The Tunnel protocol should provide for the set up of IPv6-in-IPv4 tunnels, based on IPv6-in-IPv4 encapsulation as defined in [7], from dual-stack nodes, attached to IPv4-only networks, to Tunnel Servers. Zero-configuration tunneling is defined for simple "plug and 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 mechanism must be fully dynamic in the sense that it must not require IP address information such as the IPv4 address of a Tunnel Server and/or the IPv6 address(es) to use for IPv6 connectivity to be configured on the Tunnel Clients beforehand. 6.1.3 IPv6 Address Assignment and Prefix Delegation Assignment of an IPv6 address to the end-node must be supported. No goals are defined as to how address configuration should be performed. This may be done based on legacy stateless or stateful IPv6 address configuration mechanisms or by some altogether different mechanism particular to the zero-configuration solution. Prefix Delegation support is dealt with respect to various deployment scenarios in sections 6, 7, 8 and 9. It is not however required that any tunneling protocol supporting only basic requirements provide support for prefix delegation. It is preferable that the address assignment provides a stable address, that is, an address that can be used for IPv6 connectivity for a certain amount of time rather than solely one address per higher layer session initiation 6.1.4 Use Native Connectivity When available The node should not use Zero-Configuration Tunneling when native IPv6 connectivity is available. The fact that a node should not use Zero-Configuration Tunneling when native IPv6 connectivity is available is not considered to be a Suryanarayanan, et al. Expires April 18, 2005 [Page 8] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 functional requirement on the tunnel protocol. 6.1.5 Tunnel Server End-Point Discovery In order to offer "plug and play", the implementation should allow a mechanism to discover the address of the tunnel server that will provide the tunnel connectivity. This discovery should be automatic within a Service Provider's network. 6.1.6 Tunnel End-Point Reachability Detection The tunnel protocol must allow for means for one tunnel end-point to verify the reachability of other tunnel end-points towards which it intends to send packets in a method similar to IPv6 NUD. It is preferable that a Tunnel Server monitors the reachability of the tunnel client towards which it is sending packets. Full emulation of IPv6 NUD mechanism is however not required to be supported. 6.1.7 Private and public IPv4 addresses The tunnel protocol must work over IPv4 sites deploying both private and public IPv4 addresses. Furthermore, the tunnel protocol should work with both dynamic and static IPv4 address allocation. 6.1.8 Scalability and Load-Balancing The tunnel set-up protocol must be scalable. Load balancing should be planned in advance during the early phases of deployment. Given adequate planning it should be possible for a Service Provider to seamlessly deploy additional Tunnel Servers in order to support an increased amount of Tunnel Clients. This may be achieved using load balancing functions provided by the Tunnel Server End-point Discovery mechanism as detailed in [13]. 6.1.9 Easy to deploy and Easy to Phase Out Zero-configuration Tunneling is a transition mechanism to enable Service Provider to jump start IPv6 service without requiring an immediate global upgrade of access networks. The tunneling protocol should be easy to deploy into the existing network infrastructures. Suryanarayanan, et al. Expires April 18, 2005 [Page 9] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Once IPv6 is available natively in the access network, it should be easy to phase out the tunneling protocol. 6.1.10 Latency in Set-up Phases In certain type of networks, keeping tunnels active all the time is not possible. In such environments, the protocol must be able to set-up tunnels on demand when the IPv6 connectvity either native or through tunneling is unavailable. The tunnel will be set-up only once though for the end-node and not per session. 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. 6.1.11 Security The tunneling Protocol must not introduce any new vulnerability to the network. 6.2 Advanced Requirements It is not required that the tunneling protocol support one or all of the advanced requirements described below. Support to these advanced requirements by tunneling protocol are driven by the deployment scenarios. 6.2.1 Tunnel Link Sustainability In certain environments, like in 3GPP, to minimize the overhead and latency associated with tunnel initialisation, it is highly desirable that tunnels remain active for a large amount of time, ideally infinitely. In such environments, the tunnel protocol must not mandate keep-alive messages to be transmitted by the host simply in order to sustain tunnel link connectivity. In other environments, the Tunnel Server may perform some garbage collection if it is configured to do so. The keep-alive messages can enable the tunnel server to perform garbage collection of its resources when tunnels are not in use anymore. To enable this functionality, the tunnel set-up protocol must include the transmission of keep-alive messages and time interval. Implementations, where keep-alive messages are used, must provide facility to turn-off transmission of keep-alive messages. In such cases the tunnel server might use other metrics to perform garbage Suryanarayanan, et al. Expires April 18, 2005 [Page 10] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 collection. The tunneling protocol should be able to restart the connectivity establishment process if the tunnel no longer is available. 6.2.2 NAT Traversal The Tunnel set-up protocol must be able detect the presence of one or more NATs in its path. It must be able to adapt to the following cases, by choosing the most optimal tunnel encapsulation depending on the presence of a NAT. a single node, a leaf network, using a globally routable IPc4 address, behind a NAT (customer or ISP owned), using dynamic IPv4 address (internally or externally to the NAT). 6.2.3 Firewall Traversal Even if no NAT is in the tunnel path, there may be a firewall which prohibits proto-41. In such case, the tunnel encapsulation selection based on NAT detection 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. 6.2.4 Extensibility The protocol must be extensible to support tunnel encapsulation other than IPv6 in IPv4 and IPv6 in transport in IPv4. In particular, encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined. 6.2.5 IPv6 Address Stability [This section shall be removed after getting more opinions from others.] The IPv6 address is "transient" and may change, but the protocol should offer a mechanism to provide IPv6 address stability (e.g. cookie mechanism). The implementation of this mechanism must allow this feature to be turned off. Suryanarayanan, et al. Expires April 18, 2005 [Page 11] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 7. 3GPP Specific Requirements The 3GPP goals of zero-configuration tunnelling covers the basic requirements in section 6.1 and advanced requirement in section 6.2.1. Any zero-configuration tunneling protocol satisfying the above mentioned sections must take into account constrained conditions of the 3GPP environment. For details see [14] 8. Unmanaged Networks Specific Requirements An unmanaged network is where no network manager or staff is available to configure network devices. Zero-Configuration Tunneling Protocol is quite useful in this context where automation of IPv6 connectivity to first-hop ISP and prefix assignment is handled. Unmanaged Networks [3] may or may not be behind a NAT. A zero-configuration tunneling mechanism should satisfy the basic requirements (see section 6.1) and should take into account the specific requirements described below. 8.1 Address Assignment and Prefix Delegation In unmanaged networks, assignment of an IPv6 address (/64) to the end-node must be supported. Prefix Delegation must also be supported. 8.2 NAT Traversal Zero-configuration Tunneling 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. Hence, Tunneling through IPv4 NAT must be supported. There are actually two cases where the IPv4 address of the customer tunnel end point can be dynamic, and both must be supported: o The device used as tunnel end point is using a dynamic IPv4 address provided by the ISP. o 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. Suryanarayanan, et al. Expires April 18, 2005 [Page 12] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 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 during the set-up phase. 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. 8.3 Firewall Traversal As indicated in section 6.2.3, the tunneling protocol must be able to work in networks where the firewall prohibits proto-41 packets. 8.4 Tunnel Link Sustainability The keep alive messages can enable the ISP tunnel end point to perform garbage collection of its resources when tunnels are not in use anymore. 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. A client may choose not to send those messages (for example on ISDN type links). In this case, the client should be able to handle a tunnel disconnect event and be able to restart the set-up phase to re-establish the tunnel. 8.5 Extensibility 8.5.1 IPv4-in-IPv6 Tunneling Unmanaged networks [3], calls for providing a connectivity solution when the first-hop ISP no longer supports v4. In such a scenario, the connectivity has to be provided by a third party ISP using assisted/managed methods, and hence it is out of scope of this document. 8.6 Scalability Typically, this protocol should be scalable for deployment in broadband ISP. 9. Enterprise Network Requirements The zero-configuration Tunneling protocol is not applicable for Suryanarayanan, et al. Expires April 18, 2005 [Page 13] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 managed enterprise networks to get external IPv6 connectivity. So the scope of this document is restricted to dealing with zero-configuration requirements for internal connectivity in enterprise networks. In an enterprise network where IPv4 is dominant, a tunneled infrastructure can be used to provider IPv6 services to the IPv6 islands (hosts or networks) inside the enterprise, before a full IPv6 native infrastructure is built. Zero-Configuration tunneling protocol can be used to give IPv6 connectivity and prefix information for the islands. This gives to the enterprise a basic deployment of IPv6 while maintaining automation and permanence of the IPv6 assignments to the islands. There can also be a scenario where the remote users use IPv4 VPN to connect to the enterprise, where they are assigned an IPv4 address from the enterprise address space. In such case, zero-configuration tunneling mechanism is applicable since the IPv4 source address is already authenticated for use. But typically, this is the same case where the node is inside the enterprise network. In cases where the network administrator is sure about the absence of internal NAT and firewalls in the network, and end-nodes will need only IPv6 /128 address, a tunneling protocol satisfying only the basic requirements will suffice. A zero-configuration tunneling mechanism should satisfy the basic requirements (see section 6.1) and should take into account the specific requirements described below. 9.1 IPv6 Address Assignment and Prefix Delegation Assignment of an IPv6 address (/64) to the end-node must be supported. Prefix Delegation must be supported. 9.2 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 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 (protocol-41) is enough. 9.3 Firewall Traversal The tunneling Protocol must be able to handle scenario where firewall is in the path. See Section 6.2.3. Suryanarayanan, et al. Expires April 18, 2005 [Page 14] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 9.4 Extensibility 9.4.1 IPv4-in-IPv6 Tunneling The tunneling Protocol should be able to handle automatic establishment of IPv4-in-IPv6 tunnels. It must be able to handle assignment of temporary IPv4 address and other tunnel parameters as required. 10. ISP Network Specific Requirements In some scenarios the ISP has IPv4-only customer connection networks and a backbone that supports both IPv4 and IPv6. If the customer connections might not yet been upgraded, a tunneling mechanism has to be used to provide IPv6 connectivity through the IPv4 customer connection networks. The customer can terminate the tunnel at the CPE (if it has IPv6 support) or at some set of devices internal to its network. That is, either the CPE or a device inside the network could provide global IPv6 connectivity to the rest of the devices in the customer's network. Zero-configuration tunneling mechansim is very useful in such scenarios. NATs might be present at the ISP, if ISP provides IPv4 connectivity using private IPv4 address. In many cases, the customer also has a NAT of his/her own. So its required that the tunneling protocol be able to work when one or more NATs are present in the path. These scenarios are very similar to unmanaged networks, the zero-configuration tunneling requirements described in section 7.1, 7.2, 7.3, 7.4 and 7.6 holds good in ISP networks as well. In a scenario where connection to customer from ISP supports both IPv4 and IPv6, but the customer has IPv6-only network and the ISP backbone is IPv4-only, IPv6 packets from customer needs to be tunneled over the IPv4 backbone to the next upstream ISP. Zero-configuration tunneling mechanism can be used in such scenario as well. 11. Security Considerations 11.1 Access Control Zero-configuration Tunneling does not require explicit authentication of the user. This essentially offers the IPv6 service to any of the provider IPv4 customers. Suryanarayanan, et al. Expires April 18, 2005 [Page 15] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Should an Operator/Administrator wish to implement additional access control, e.g., limiting the service to certain customers, then in the case where IPv4 source spoofing prevention is performed within the Operators network, mere filtering on the IPv4 address could give this. Such mechanisms, however, would be external to the tunnel protocol itself and are outside the scope of this document. In any case, the service should be limited to the provider network and the assumption that the Zero-Configuration Tunneling site is protected from protocol-41 encapsulated packets arriving from external IPv4 networks, should indeed effectively prevent access to the service from outside the provider network. If for some reason an Operator/Administrator deviates from the above assumption or if additional security measures are wanted (just in case) then proper ingress filtering in the ISP core network together with IPv4 source address filtering would limit the access to internal customers only. If the mentioned 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. 11.2 General Threats The following have been identified as potential threats applicable to the network and infrastructure nodes within a Zero-Configuration Tunneling site regardless of whether the individual node implements Zero-Configuration Tunneling or not: o It may be possible to use a tunnel server to reflect tunneled packets into the network, similar to the 6to4-reflection attacks identified in [15]. o In the case of no internal Firewalls or NATs and no interaction with such being performed by the tunnel protocol, the Zero-configuration site must be kept penetrable for intra-site IPv6-in-IPv4 protocol-41 encapsulated packets. This may open up for threats to end-hosts that rely on the network infrastructure to filter out Protocol-41 encapsulated packets. o Zero-configuration tunneling may open up threats to other mechanisms in the network that rely on Protocol-41 encapsulation. Detailed analysis of the validity of these threats will have to depend on the particular Zero-Configuration solution. In general it could be noted that attacks based on the above threats largely should Suryanarayanan, et al. Expires April 18, 2005 [Page 16] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 be preventable if the end-hosts in the network implement appropriate drop policies, either simple drop all protocol-41 policies or more differentiated policies based, e.g., on source addresses. 11.3 Threats to nodes implementing Zero-Configuration Tunneling The following considerations apply to the situation where Zero-Configuration Tunneling is deployed in between tunnel servers and end-hosts only. Special security considerations for the usage of Zero-Configuration Tunneling for direct tunneling in between end-hosts is given in Section 12.4. 11.3.1 Threats to end-hosts In current IPv6 networks hosts need to trust on the benevolence of their default routers as well as hosts must trust that anyone impersonating as a router is indeed one, see, e.g., the trust models and threats described in [16]. Future multi-access IPv6 networks may rely on SEND mechanisms, i.e., mechanisms developed in the SEND WG inorder to mitigate the threats described in [16], to establish a trust relationship in between host and routers. In this context is it constructive to look at the following three categories of Zero-Configuration Tunneling sites: 1. Environments with IPv4 source address spoofing prevention, e.g. 3GPP environments and "filtered" ISP and Unmanaged environments. 2. Open, un-trusted environments without IPv4 source address spoofing prevention, e.g., ȼun-filteredȫ ISP and Unmanaged environments. 3. Closed, trusted, environments without IPv4 source address spoofing prevention, e.g., Enterprise environments. In all environments, but in open environments in particular, it is assumed a prerequisite that a trustworthy Zero-Configuration tunnel server end-point discovery mechanism is implemented. Given this, then in a Zero-Configuration Tunneling Site of the first category (1.), end-host can trust that packets they perceive as stemming from Tunnel Servers (identified by IPv4 address) do actually stem from such and further they can trust on the benevolence of these Tunnel Servers. Suryanarayanan, et al. Expires April 18, 2005 [Page 17] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 In Zero-Configuration Tunneling Sites of the latter two categories (2 and 3), then due to possibility of IPv4 address source spoofing, this is not possible even when a trustworthy Zero-Configuration Tunnel Server end-point discovery mechanism is implemented. For trusted Zero-Configuration Tunneling Sites (category 3), the threats may be considered to be manageable, as the environment itself is assumed to be trusted. End-hosts in Zero-Configuration Tunneling Sites of category 2, however, are exposed to the same threats as hosts in non-SEND multi-access IPv6 networks. 11.3.2 Threats to Tunnel Servers Zero-Configuration Tunneling may be deployed over very large IPv4 sites with low density of active tunnel clients but with a very high number of dormant, but potential tunnel clients. Therefore Denial-of-Service prevention by strict over provisioning of Tunnel Server capacity is unlikely to be performed. 11.3.2.1 Tunnel State related risks If the Tunnel Server relies on state to be kept per tunnel client that it serves, the server risks resource exhaustion. In this situation it is a security prerequisite that no node, whether located within or outside the Zero-Configuration Tunneling site, cannot initiate initialization of tunnel state for other entities than itself (identified with IPv4 address). But even in this case, then in situations where: o IPv4 address spoofing is possible. o An unlimited number of tunnels may created per node, e.g. in NAT traversal environments it may still be possible for one or a limited number of nodes to exhaust the resources of the server. Such attacks, however, may be mitigated by performing IPv4 return routability checks as an intrinsic part of tunnel initialization (first case) or/and by limiting the number of tunnels that may be created per node (second case). 11.3.2.2 Traffic related risks Tunnel encapsulation is recognized as being more resource demanding than mere packet forwarding. Given the same traffic load a Tunnel Server must thus be more generously provisioned that a corresponding router for it not to be more likely to get overthrown by large Suryanarayanan, et al. Expires April 18, 2005 [Page 18] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 unexpected amounts of traffic than the router. The authors have found no plausible treats to the tunnel service, due to large unexpected amounts of traffic needing encapsulation, which can be classified as a security threat rather than a case of under-provision. This regardless of whether the traffic is due to a surge in the density of active tunnel clients or due to a surge in the traffic streams set-up by active clients. 11.3.2.3 Packet Delivery related threats One potential risk related to packet delivery has been identified. This risk is the equivalent of the threat to routers in multi-access environments described in [16] Section 4.3.2. The risk is associated with the special case where the tunnel protocol requires special resource demanding and/or temporary state creation actions to be taken by the Tunnel Server for delivery of packets destined for not recently addressed Tunnel Clients. The situation where such actions must be performed for all packets at all times is considered to be unlikely. The actions required could be buffering of packets while the reachability of the destined node is being verified. In case a malicious node (located either within or outside the zero-configuration site) is able to continuously send packets to continuously changing nodes, which by the Tunnel Server is perceived as being existing or potential client nodes, the malicious node may be able to exhaust the Tunnel Servers capability of delivering packets by saturating the packet buffering mechanism and the reachability state table as well as by keeping the Tunnel Server busy determining the reachability state of the ever changing client nodes. The above threat will not be relevant if reachabilityis performed as an intrinsic part of the, thus stateful, tunnel protocol, e.g., by relying on periodically transmitted keep alive messages. 11.4 Implications of Direct Tunneling In case direct tunneling in between end-hosts is provided by the tunneling protocol, it will not (as described in Section 1.3.1) be possibly for end-hosts to filter out received Protocol-41 encapsulated packets based on whether the IPv4 source is an address belonging to a trusted or perceived Tunnel Server as such behavior evidently would break direct tunneling. As other end-hosts generally are non-trusted, direct tunneling may thus open up for attacks against IPv6 ingress filtering. Suryanarayanan, et al. Expires April 18, 2005 [Page 19] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Detailed analysis of the validity of this threat will have to depend on the particular zero-configuration solution. 12. Acknowledgements The work done by the authors on the zero-configuration tunneling requirements for 3GPP ([14]) and on assisted-tunneling ([5]), has been the main inspiration for the Zero-Configuration Tunneling requirements work. This work has benefited from input and comments provided by IPv6 Team in Samsung India Software Operations (India) for the initial phase of the work. The authors would like to acknowledge also the inputs from Pekka Savola and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 13. References 13.1 Normative References 13.2 Informative References [1] Bound, J., "IPv6 Enterprise Network Scenarios", draft-ietf-v6ops-ent-scenarios-05 (work in progress), July 2004. [2] Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-03 (work in progress), June 2004. [3] Huitema, C., "Evaluation of Transition Mechanisms for Unmanaged Networks", draft-ietf-v6ops-unmaneval-03 (work in progress), June 2004. [4] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in progress), May 2004. [5] "Requirements for assisted tunneling", draft-ietf-v6ops-assisted-tunneling-requirements-00 (work in progress), June 2004. [6] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work in progress), June 2004. Suryanarayanan, et al. Expires April 18, 2005 [Page 20] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 [7] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 (work in progress), September 2004. [8] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [9] Loughney, J., "IPv6 Node Requirements", draft-ietf-ipv6-node-requirements-11 (work in progress), August 2004. [10] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [11] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [13] Palet, J., "IPv6 Tunnel End-point Automatic Discovery Mechanism", draft-palet-v6ops-solution-tun-auto-disc-00 (work in progress), September 2004. [14] Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP", draft-nielsen-v6ops-3GPP-zeroconf-goals-00 (work in progress), October 2004. [15] Savola, P., "Security Considerations for 6to4", draft-ietf-v6ops-6to4-security-04 (work in progress), July 2004. [16] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Authors' Addresses Radhakrishnan Suryanarayanan Samsung India Software Operations No. 3/1 Millers Road Bangalore India Phone: +91 80 51197777 EMail: rkrishnan.s@samsung.com Suryanarayanan, et al. Expires April 18, 2005 [Page 21] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Syam Madanapalli Samsung India Software Operations No. 3/1 Millers Road Bangalore India Phone: +91 80 51197777 EMail: syam@samsung.com Karen Egede Nielsen Ericsson Skanderborgvej 232 8260 Viby J Denmark Phone: +45 89 38 51 00 EMail: karen.e.nielsen@ericsson.com Florent Parent Hexago 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada EMail: florent.parent@hexago.com Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.palet@consulintel.es Appendix A. Out of Scope [Editor's Note: This appendix can be removed in a future revision of this document] The following issues have been considered as being out of scope of this work: o DNS: DNS registration of the IPv6 addresses allocated to dual Suryanarayanan, et al. Expires April 18, 2005 [Page 22] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 stack nodes while deploying Zero-Configuration Tunneling for IPv6 connectivity. o Mobile IPv6: Support of Mobile IPv6 usage over the tunnel-link; here under potential mechanisms required to support MIPv6 movement detection as well as fast tunnel set-up for Mobile IPv6 session survivability. Suryanarayanan, et al. Expires April 18, 2005 [Page 23] Internet-Draft Zero-Configuration Tunneling Requirements October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Suryanarayanan, et al. Expires April 18, 2005 [Page 24]