Internet Engineering Task Force J. Palet Internet-Draft Consulintel Expires: August 18, 2005 K. Nielsen Ericsson F. Parent Hexago A. Durand Sun Microsystems, inc. R. Suryanarayanan Samsung India Software Operations P. Savola CSC/FUNET February 14, 2005 Goals for Tunneling Configuration draft-palet-v6tc-goals-tunneling-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 August 18, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Palet, et al. Expires August 18, 2005 [Page 1] Internet-Draft Goals for Tunneling Configuration February 2005 Abstract This memo describes the set of goals for a tunneling setup protocol that could be used in several network cases to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity through a simplistic tunneling mechanism. The basic network cases, which may have different sets of goals, are also introduced, including 3GPP and other Service Providers. Two cases are analyzed in the Service Provider scenario, one which apply to simplistic mechanism where the user is already authenticated by other network existing means, and another which also takes care of the user authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Assumptions and Prerequisites . . . . . . . . . . . . . . . . 6 4. Goals of the Tunneling Configuration Protocol . . . . . . . . 7 4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2 Easy to deploy and Easy to Phase-out . . . . . . . . . 7 4.2 Tunnel Set-up . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1 Tunnel End-Point Auto-Discovery and tunnel establishment . . . . . . . . . . . . . . . . . . . . 8 4.2.2 Tunnel End-Point Reachability Detection . . . . . . . 8 4.2.3 Scalability and Load-Balancing . . . . . . . . . . . . 9 4.2.4 Latency in Set-up Phases . . . . . . . . . . . . . . . 9 4.2.5 Tunnel Link Sustainability . . . . . . . . . . . . . . 9 4.2.6 NAT Traversal . . . . . . . . . . . . . . . . . . . . 10 4.2.7 Firewall Traversal . . . . . . . . . . . . . . . . . . 10 4.2.8 Use Native Connectivity when Available . . . . . . . . 10 4.3 IPv6 Configuration . . . . . . . . . . . . . . . . . . . . 10 4.3.1 IPv6 Address Assignment . . . . . . . . . . . . . . . 10 4.3.2 IPv6 Address Stability . . . . . . . . . . . . . . . . 11 4.3.3 IPv6 Prefix Delegation . . . . . . . . . . . . . . . . 11 4.3.4 IPv6 DNS . . . . . . . . . . . . . . . . . . . . . . . 11 4.4 Implementation Considerations . . . . . . . . . . . . . . 11 4.4.1 Private and Public IPv4 Addresses . . . . . . . . . . 11 4.4.2 Extensibility . . . . . . . . . . . . . . . . . . . . 11 4.4.3 Stateful or Stateless . . . . . . . . . . . . . . . . 12 4.5 Management and Security . . . . . . . . . . . . . . . . . 12 4.5.1 Security . . . . . . . . . . . . . . . . . . . . . . . 12 4.5.2 Traceability . . . . . . . . . . . . . . . . . . . . . 12 4.5.3 Registration . . . . . . . . . . . . . . . . . . . . . 12 4.5.4 Authentication . . . . . . . . . . . . . . . . . . . . 13 4.5.5 Confidentiality . . . . . . . . . . . . . . . . . . . 13 Palet, et al. Expires August 18, 2005 [Page 2] Internet-Draft Goals for Tunneling Configuration February 2005 4.5.6 Accounting . . . . . . . . . . . . . . . . . . . . . . 13 5. Applicability of the Tunneling Configuration to Different Network Cases . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 3GPP Access Networks . . . . . . . . . . . . . . . . . . . 14 5.1.1 Simplicity . . . . . . . . . . . . . . . . . . . . . . 15 5.1.2 Automated IPv6-in-IPv4 tunnel establishment . . . . . 15 5.1.3 IPv6 Address Assignment and Prefix Delegation . . . . 15 5.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2 Narrowband Access Networks . . . . . . . . . . . . . . . . 16 5.3 Broadband Access Networks . . . . . . . . . . . . . . . . 16 5.4 Unmanaged Networks . . . . . . . . . . . . . . . . . . . . 16 5.5 Enterprise Networks . . . . . . . . . . . . . . . . . . . 16 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 21 Palet, et al. Expires August 18, 2005 [Page 3] Internet-Draft Goals for Tunneling Configuration February 2005 1. Introduction Regardless of which is the network that is involved in the transition from IPv4 to IPv6, generally this could involve several phases, often in different networks parts (i.e., core, access). The transition of the core network usually can be done in a much more easy way than the access network. This is the case even if the core network is only connected via tunnels to other IPv6 networks. The setup of those tunnels involves a small effort and is not a big trouble, even in the case of a manual configuration. However, this is not the case for the access network, which may involve different types of layer two technologies. In all the cases, in order to facilitate the transition of those access networks, which will be impossible to do manually and efficiently, there is a need for an automatic IPv6-in-IPv4 tunneling mechanism. The goal is to 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. This should be applicable to all kind of ISPs and access networks. They could be regular ISPs, providing service through DSL, PSTN, ISDN, cable, PLC or any other technologies, but could be also a wireless ISP, or even an enterprise with its own service provider infrastructure for the employees at remote locations. In order to simplify the text, "customers" is used in the rest of this document to refer to both Customers of Service Providers (3GPP, other ISPs) and users (Enterprise, others). In this document, the refereces to "Service Provider" is a general one, meaning whatever network/technology is used for providing access to IP connectivity. In the case of an ISP starting its IPv6 offering to its customers, without initially upgrading its access network to support IPv6, as indicated in section 5.1 of [3], could use a "tunnel brokering solution", as described in [5]. However the tunnel set-up protocol has been identified as a missing piece. Similarly, in an 3GPP, ISP or enterprise network, the provision of the native IPv6 connectivity to the customers/users, can take a long time and may be costly, while a tunneled infrastructure can be used as a low cost transition path, which can be deployed easily and in a short time, enabling progressive native IPv6 deployment when/where justified. Palet, et al. Expires August 18, 2005 [Page 4] Internet-Draft Goals for Tunneling Configuration February 2005 Such tunneling infrastructure can connect the customers/users to the IPv6 network using available production IPv6 address space, thus facilitating the transition towards native IPv6 deployment, so the roadmap may become: o Tunneling infrastructure for early adopters. o Native IPv6 to some customers/user groups once economically justified. o Native IPv6 to all customers/users. "Tunneling Configuration" (TC) is used in this document to describe a protocol which takes care of the setup and maintenance of the bidirectional tunnel between a dual-stack end-node (or leaf network) and a dual-stack tunnel server. The exchange of parameters needed for the setup and maintenance of the tunnel (such as address, prefix, routing, encapsulation, filtering, authentication, accounting, ...), should be automated to avoid manual user/operator intervention. The tunneling configuration protocol is envisaged to be deployed as an initial and temporary mechanism to provide basic IPv6 connectivity services only. This basic IPv6 connectivity may be limited, in the sense than may be not 100% comparable to a native IPv6 service. However this basic IPv6 connectivity should be enough while it allows the communication through IPv6 during the transition phase, until the native IPv6 service is available, and consequently is expected that the tunneling will be phased out as soon as native IPv6 access service is available. This document analyzes the goals for a such tunnel setup protocol, taking in consideration the different possible common network cases for deploying IPv6. 2. Terminology Tunneling-Configured Site (TCS): A logical network over which IPv6 connectivity is provided by means of Tunneling Configuration. At least one dual-stack node is required in this logical network. Tunnel End-Point (TEP): A dual-stack node performing IPv6-in-IPv4 tunnel encapsulation/decapsulation in accordance with Tunneling Configuration. There will be always two TEPs in order to establish the communication, the local one at the customer site (TCS) and the remote one at the ISP site. Tunnel Server (TS): A dual-stack server node with IPv6 connectivity and which provides IPv6 connectivity to client nodes by performing Palet, et al. Expires August 18, 2005 [Page 5] Internet-Draft Goals for Tunneling Configuration February 2005 IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from client nodes in accordance with Tunneling Configuration. A Tunnel Server is likely to be a dual-stack router, but could be also a node behaving as a router. The TS is often the ISP TEP. Tunnel Client (TCL): A dual-stack node that obtains IPv6 connectivity by means of Tunneling Configuration. A tunnel client relies on IPv6-in-IPv4 tunnel encapsulation/decapsulation to/from Tunnel Servers for IPv6 communications to native IPv6 nodes. This is often the customer TEP. Direct Tunneling (DT): Direct tunnelling here refer to the case where end-hosts located within different Tunneling-Configured Sites, in the same ISP network, may circumvent the Tunnel Server and communicate directly using the tunnel protocol. CPE: Customer Premises Equipment. 3. Assumptions and Prerequisites Tunneling Configuration may be applicable in different IPv6 transition network cases. The focus of this document is to define the goals to apply this mechanism in the Service Provider context making the following assumptions and prerequisites: o The customer configuration may be diverse and not necessarily predictable. Consequently the tunneling configuration protocol must be able to adapt to different cases or combinations of: * The TCS is a single node or leaf network. * The TCL at the TCS has a global IPv4 address or is behind one or more NATs. * The TCL at the TCS has a static or dynamic IPv4 address. * In case of NAT, the external IPv4 address is a static or dynamic. * In case of NAT, it can be customer or ISP owned. o IPv4 multicast is not widely available, so the tunnel configuration protocol should work in IPv4 network environments where IPv4 multicast is not provided. o The tunnel configuration protocol should 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. Palet, et al. Expires August 18, 2005 [Page 6] Internet-Draft Goals for Tunneling Configuration February 2005 o This tunneling configuration protocol is provided within a restrictive timescale, in the sense that it should be phased out as soon as native access can be provided. o The tunneling configuration is a protocol to be used in the transition phase, thus does not need to be perfect. As a matter of fact, making it perfect would be counter productive, as it would first delay its definition, then make its deployment more cumbersome and, last but not least, diminish the incentives to deploy native IPv6. Furhermore, should not rely in a complex set of devices, which may not be readily available, and could even mean a more expensive cost than the support of native IPv6 itself. 4. Goals of the Tunneling Configuration Protocol As introduced above, there are different ISP types and different access networks. This means that that there are different goals related to different network cases and situations. For instance, factors as presence of NAT or not, low/high bandwidth, expensive/cheap, strong internal access control or not, etc. Different access media or network cases brings up different sets of goals. Obviously, once choice will be to create a protocol for each specific case, but this is not optimal. Instead, the motivation of this document is to combine all the goals and look for a common solution, which can fit as much as possible and in the most optimal way, in all the cases. Some of those goals could be conflictual and that need to be resolved as well. This section groups these different goals. 4.1 General 4.1.1 Simplicity The Tunneling Configuration protocol should be easy to implement, implying a lightweight protocol. The protocol should provide a reasonable, even if limited, set of basic IPv6 connectivity features. 4.1.2 Easy to deploy and Easy to Phase-out The Tunneling Configuration protocol should be easy to deploy into the existing IPv4 and IPv6 network infrastructure. The Tunneling Configuration protocol should have no major impact on protocols and infrastructure nodes deployed in existing infrastructures providing IPv4 and native IPv6 connectivity. Palet, et al. Expires August 18, 2005 [Page 7] Internet-Draft Goals for Tunneling Configuration February 2005 The Tunneling Configuration protocol should coexist and work seamlessly together with any native IPv6 infrastructure that gradually may be implemented in the network. The Tunneling Configuration protocol should have no negative implications on how such infrastructure is implemented. The Tunneling Configuration protocol should be easy to take out of service once native IPv6 is available. 4.2 Tunnel Set-up 4.2.1 Tunnel End-Point Auto-Discovery and tunnel establishment The tunnel protocol should provide a mechanism for the automated discovery of the Tunnel End-Point, by the virtue of which end-hosts automatically and at run-time can determine the IPv4 addresses of available Tunnel Servers. The discovery mechanism should rely on intrinsic services, read services already universally deployed, to the particular network environment. It should not require the addition of additional IP network infrastructure elements for this function only. The mechanism should 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. The analysis done in [11] may apply. The Tunneling Configuration protocol should provide for the set of IPv6-in-IPv4 tunnels, based on IPv6-in-IPv4 encapsulation as defined in [10], from dual-stack nodes, attached to IPv4-only networks, to Tunnel Servers. The IPv6-in-IPv4 tunnels and the IPv6 connectivity should be established in an automated manner, i.e., without requiring manual intervention at any of the tunnel end-points at tunnel establishment time. We can typically describe it as a "plug and play" protocol, which can be triggered through the execution of a simple program. 4.2.2 Tunnel End-Point Reachability Detection The Tunneling Configuration protocol should 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. Palet, et al. Expires August 18, 2005 [Page 8] Internet-Draft Goals for Tunneling Configuration February 2005 The unicast neighbor reachability discovery functions provided by IPv6 Neighbor Discovery ([6]), i.e., unicast NS/NA exchanges, should be supported on the tunnel link. 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 an explicit goal. 4.2.3 Scalability and Load-Balancing In order to ensure the scalability of the tunnel service, in terms of not limiting the number of simultaneous connections to the service and consequently limiting possible service denial situations, it should be possible for a Service Provider to load-balance those connections among several available Tunnel Servers. Load balancing should be planned already during the early phases of deployment. Given adequate planning it should be possible for an ISP to seamlessly deploy additional Tunnel Servers in order to support an increased amount of Tunnel Clients. This may be achieved, for example, by using the load balancing functions provided by the Tunnel Server End-point discovery mechanism as detailed in [12]. 4.2.4 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 connectivity either natively or through tunneling is unavailable. The tunnel will be set-up only once though for the tunnel client and not per session. The Tunneling Configuration 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. 4.2.5 Tunnel Link Sustainability The tunnel link established in between a host deploying Tunneling Configuration and an associated Tunnel Server should be expected to remain in administrative active state for the lifetime of the IPv6 address provided to the host. The Tunneling Configuration protocol should not mandate keep-alive messages to be transmitted by the host simply in order to sustain tunnel link connectivity. However, this may be required when a Palet, et al. Expires August 18, 2005 [Page 9] Internet-Draft Goals for Tunneling Configuration February 2005 tunnel has to cross a NAT box. In this case, 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 3GPP or 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. 4.2.6 NAT Traversal The Tunneling Configuration protocol should be able to detect the presence of one or more NATs in its path. The tunnel should be able to traverse NAT, if present, so it may be necessary to choose among several tunnel encapsulation protocols for the most optimal one. 4.2.7 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 could select a tunnel that will not work. To cope with this situation, the Tunnel Configuration protocol implementation may allow a user to explicitly specify the desired tunnel encapsulation, regardless of the NAT detection process. 4.2.8 Use Native Connectivity when Available The node should not use the Tunneling Configuration protocol when native IPv6 connectivity is available. The fact that a node should not initiate the Tunneling Configuration protocol when native IPv6 connectivity is available is not considered to be a functional goal on the tunnel protocol per se. For example, rather it is related to the activation and deactivation of the protocol. 4.3 IPv6 Configuration 4.3.1 IPv6 Address Assignment Assignment of at least one globally routable IPv6 unicast address Palet, et al. Expires August 18, 2005 [Page 10] Internet-Draft Goals for Tunneling Configuration February 2005 (/128) to the end-node should be supported. No goals are defined as to how address configuration should be performed. This may be done based on stateless or stateful IPv6 address configuration mechanisms or by some altogether different mechanism particular to the Tunneling Configuration protocol. 4.3.2 IPv6 Address Stability The IPv6 address is "transient" and may change, but the protocol should offer a mechanism to provide IPv6 address stability (for example, a cookie mechanism). The implementation of this mechanism should allow this feature to be turned off. 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. 4.3.3 IPv6 Prefix Delegation Prefix Delegation support may depend on the different deployment cases. It is not however required that a Tunneling Configuration protocol supporting only basic requirements provides support for prefix delegation. 4.3.4 IPv6 DNS Dual-stack nodes could use both IPv4 and IPv6 DNS discovery mechanisms and both, IPv4 and IPv6 transport for DNS services. Consequently IPv6 DNS discovery and IPv6 transport for DNS services should not be a goal of the Tunneling Configuration protocol. 4.4 Implementation Considerations 4.4.1 Private and Public IPv4 Addresses The Tunneling Configuration protocol should work over IPv4 sites deploying both private and public IPv4 addresses. Furthermore, the Tunneling Configuration protocol should work with both dynamic and static IPv4 address allocation. 4.4.2 Extensibility The Tunneling Configuration protocol should be extensible to support tunnel encapsulation other than IPv6 in IPv4 and IPv6 in transport in Palet, et al. Expires August 18, 2005 [Page 11] Internet-Draft Goals for Tunneling Configuration February 2005 IPv4. In particular, encapsulation of IPv4 in IPv6 or IPv6 in IPv6 could be defined. 4.4.3 Stateful or Stateless By a stateful mechanism we mean a mechanism that require the Tunnel Server to maintain tunnel state per client it serves. Tunnel state here is considered to be any parameter kept by the server per client and without which the server is unable to serve the client (receive packets from/send packets to). Tunnel state must be distinguished from state used to optimize the packet delivery function of the tunnel server and which is kept in a fixed or upper limited amount of memory space, such as, e.g., reachability information. It should be emphasized that this document makes no deliberate assumptions on whether a Tunneling Configuration protocol should be based on a stateful or stateless Tunnel Server mechanism. Indeed it is anticipated that the goals of Tunneling Configuration as put forward here could be served both by a stateless as well as by a stateful mechanism. 4.5 Management and Security 4.5.1 Security The Tunneling Configuration protocol should not impose any new vulnerability to the existing network infrastructure. The Tunneling Configuration protocol should not impose any new vulnerability to the nodes implementing it than what is already present in existing multi-access IPv6 networks, where multiple hosts are served by the same router or possibly multiple routers. 4.5.2 Traceability In some environments, traceability is an important consideration. The Tunneling Configuration protocol should be instrumentable to enable the collection of usage data which can be used, for example, for capacity planning. 4.5.3 Registration The registration of credentials should be external to the Tunneling Configuration protocol. The user may require registration prior to using this service (through some web based service or other means). Palet, et al. Expires August 18, 2005 [Page 12] Internet-Draft Goals for Tunneling Configuration February 2005 Alternatively, the service provider may use an existing authentication database to pre-register its users, or even not require registration at all, depending on the network configuration. In order to allow a service provider to use its existing authentication database, 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 access to a registered mode (e.g. URL to provider registration web page). 4.5.4 Authentication Authentication can be used to control that the user has access to the IPv6 services. 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 should be supported. Other authentication may be supported and should be negotiated between the client and server (e.g., SASL [13]). 4.5.5 Confidentiality Tunneling Configuration can be used across networks which are not under the service provider control (e.g., roaming users). The Tunneling Configuration protocol should allow protection of the authentication data. This can be achieve by selecting an authentication mechanism that protects the credentials (e.g., digest-md5). Protecting the tunneled data (IPv6 in this case) should be possible, for instance by means of using IPsec tunneling. 4.5.6 Accounting The Tunneling Configuration 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): o Tunnel counters (traffic in/out). o User utilization (tunnel uptime). Palet, et al. Expires August 18, 2005 [Page 13] Internet-Draft Goals for Tunneling Configuration February 2005 o 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). 5. Applicability of the Tunneling Configuration to Different Network Cases Note: Section to be completed in a new version. The goals enumerated in the precedent section are not all necessarily applicable and not in the same degree to different network cases. However seems feasible to build a common ground to these different network cases in order to define a single Tunneling Configuration protocol, which can accommodate to the different combinations of those goals and network cases. The v6ops working group has identified and analyzed several deployment scenarios for IPv4/IPv6 transition mechanisms in various stages of the IPv6 deployment and its coexistence with IPv4. This work has been carried out for a number of different network environments each with their particular characteristics including 3GPP [1], Unmanaged [2], ISP [3] and Enterprise networks [4]. The following sub-sections basically look into those different network environments to provide an analysis of the common and uncommon goals. 5.1 3GPP Access Networks IPv6-in-IPv4 tunneling is envisaged to be deployed in 3GPP networks as an initial and temporary mechanism to provide limited and basic IPv6 connectivity services only. The IPv6-in-IPv4 tunneling mechanism demanded by the 3GPP environment falls within the realm of Tunneling Configuration. Native IPv6-like 3GPP connectivity services, e.g. services including flexible charging and quality of service on demand, will be feasible, in 3GPP environments by virtue of true native IPv6 only. This is due to the interrelation between the native IPv6 3GPP service and various 3GPP signaling interfaces. The latter which is not envisaged upgraded to support the IPv6-in-IPv4 tunneling situation. It is important to note that the IPv6 connectivity provided by 3GPP Tunneling Configuration IPv6-in-IPv4 tunneling does not compare with the native IPv6 3GPP connectivity in terms of the services offered. Palet, et al. Expires August 18, 2005 [Page 14] Internet-Draft Goals for Tunneling Configuration February 2005 This differentiates the 3GPP IPv6-in-IPv4 tunneling transition case somewhat from some of the other transition scenarios considered in the IETF v6ops WG and unlike some of these scenarios, the 3GPP IPv6-in-IPv4 tunneling deployment case is not a case of progressive and gradual roll out of native IPv6-like services. Rather, Tunneling Configuration will in the 3GPP environment be deployed for the following purposes: o To provide temporary provisioning of basic IPv6 services, which users may deploy for the simplest IPv6 services only. o To allow an Operator, possibly a native IPv6 enabled Operator, to provide basic IPv6 services to users roaming into foreign networks which supports IPv4 bearer connectivity only. The scope of Tunneling Configuration in the 3GPP network environment is restricted to an absolute minimal set of functions required to provide automatic IPv6 connectivity establishment to dual stack nodes by means of IPv6-in-IPv4 encapsulation as defined in [10] to Tunnel Servers. Tunneling Configuration in the 3GPP network environment does not attempt to provide emulation of the full set of native IPv6 connectivity functions as defined by [14], [15] and [16]. With this in mind the following goals are applicable to the 3GPP Access Networks: 5.1.1 Simplicity . 5.1.2 Automated IPv6-in-IPv4 tunnel establishment . 5.1.3 IPv6 Address Assignment and Prefix Delegation It is only an explicit goal to have a /128 address allocated for global connectivity on the tunnel link. 5.1.4 . 5.1.5 . Palet, et al. Expires August 18, 2005 [Page 15] Internet-Draft Goals for Tunneling Configuration February 2005 5.1.6 . 5.1.7 . 5.2 Narrowband Access Networks Somehow this type of networks are very similar to the 3GPP case, because the main constrain is the low bandwidth and the high cost of the usage of the access network. Examples of this are PSTN and ISDN access networks. . 5.3 Broadband Access Networks This is typically the case when an ISP is offering IPv6 connectivity to its customers, initially using controlled tunneling infrastructure, as described in section 5.1 "Steps in Transitioning Customer Connection Networks" of [3]. . 5.4 Unmanaged Networks In unmanaged networks [2], Tunneling Configuration is applicable in the case A where a gateway does not provide IPv6 at all (section 3), and case C where a dual-stack gateway is connected to an IPv4-only ISP (section 5). In the case the link is not IPv4 capable, Tunneling Configuration is applicable by means of IPv4 in IPv6 tunneling. This will actually fall into the same set of goals as already described for narrow or broadband access networks, depending on the media. 5.5 Enterprise Networks In the enterprise scenario [4], Tunneling Configuration can be used to support both, remote users connecting to the enterprise network (section 7.5.2) and internal users if the native infrastructure is not yet available. Palet, et al. Expires August 18, 2005 [Page 16] Internet-Draft Goals for Tunneling Configuration February 2005 6. Conclusions TBD. 7. Security Considerations TBD. 8. Acknowledgements This memo was written starting from previous existing work at v6ops, such as "Goals for Zero-Configuration Tunneling in 3GPP" [7], "Zero-Configuration Tunneling Requirements" [8] and "Goals for Registered Assisted Tunneling" [9]. The authors would also like to acknowledge inputs from Tim Chown and the European Commission support in the co-funding of the Euro6IX project, where this work is being developed. 9. References 9.1 Normative References [1] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", Internet-Draft draft-ietf-v6ops-3gpp-analysis-11, October 2004. [2] Huitema, C., Austein, R., Satapati, S. and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004. [3] Lind, M., Ksinant, V., Park, S., Baudot, A. and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", Internet-Draft draft-ietf-v6ops-isp-scenarios-analysis-03, June 2004. [4] Bound, J., "IPv6 Enterprise Network Scenarios", Internet-Draft draft-ietf-v6ops-ent-scenarios-05, July 2004. [5] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 9.2 Informative References [7] Nielsen, k., "Goals for Zero-Configuration Tunneling in 3GPP", Internet-Draft draft-nielsen-v6ops-3GPP-zeroconf-goals-00, October 2004. Palet, et al. Expires August 18, 2005 [Page 17] Internet-Draft Goals for Tunneling Configuration February 2005 [8] Suryanarayanan, R., "Zero-Configuration Tunneling Requirements", Internet-Draft draft-suryanarayanan-v6ops-zeroconf-reqs-00, October 2004. [9] Parent, F., "Goals for Registered Assisted Tunneling", Internet-Draft draft-ietf-v6ops-assisted-tunneling-requirements-01 , October 2004. [10] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", Internet-Draft draft-ietf-v6ops-mech-v2-06, September 2004. [11] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Internet-Draft draft-palet-v6ops-tun-auto-disc-03, January 2005. [12] Palet, J., "IPv6 Tunnel End-point Automatic Discovery Mechanism", Internet-Draft draft-palet-v6ops-solution-tun-auto-disc-01, October 2004. [13] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [14] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. [15] Loughney, J., "IPv6 Node Requirements", Internet-Draft draft-ietf-ipv6-node-requirements-11, August 2004. [16] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. Palet, et al. Expires August 18, 2005 [Page 18] Internet-Draft Goals for Tunneling Configuration February 2005 Authors' Addresses 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 Karen Egede Nielsen Ericsson Skanderborgvej 232 8260 Viby J zip - Denmark Phone: +45 89 38 51 00 Fax: Email: karen.e.nielsen@ericsson.com Florent Parent Hexago 2875 boul. Laurier, suite 300 Sainte-Foy, QC G1V 2M2 Canada Phone: Fax: Email: florent.parent@hexago.com Alain Durand Sun Microsystems, inc. 17 Network Circle UMPK17-202 Menlo Park, CA 94025 USA Phone: Fax: Email: alain.durand@sun.com Palet, et al. Expires August 18, 2005 [Page 19] Internet-Draft Goals for Tunneling Configuration February 2005 Radhakrishnan Suryanarayanan Samsung India Software Operations No. 3/1 Millers Road Bangalore India Phone: +91 80 51197777 Fax: Email: rkrishnan.s@samsung.com Pekka Savola CSC/FUNET Espoo Finland Phone: Fax: Email: psavola@funet.fi Palet, et al. Expires August 18, 2005 [Page 20] Internet-Draft Goals for Tunneling Configuration February 2005 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 (2005). 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. Palet, et al. Expires August 18, 2005 [Page 21]