Internet Engineering Task Force Authors INTERNET DRAFT Alain Durand (IMAG) Paolo Fasano (CSELT) Ivano Guardini (CSELT) Domenico Lento (CSELT) 2 April 1999 Expires 1 October 1999 IPv6 Tunnel Broker Status of Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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. Abstract The IPv6 global Internet as of today is mostly build using tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and ISPs can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help the early IPv6 adopters to hook up to the 6bone and to provide them stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated in Grenoble IPng & NGtrans interim meeting. Durand Fasano Guardini Lento Expires 1 October 1999 [Page 1] Internet Draft draft-ietf-ngtrans-broker-00.txt 1. Introduction The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This fact brought to the development of several techniques to manage IPv6 over IPv4 tunnels. At present most of the 6bone networks is built using manual tunneling over the Internet. The main drawback of this approach is the overwhelming management load for network administrators, who have to perform heavy configuration operations for each tunnel. Several attempts to reduce this management overhead have been proposed [1-3]. Nevertheless all of them present drawbacks that prevent from wide usage: - [1] was introduced to use automatic tunnels with IPv4 compatible addresses. This approach does not solve the address exhaustion problem of IPv4. Also there is a great fear to include the complete IPv4 routing table in the IPv6 one and just making the routing table size problem worse by multiplying it by 5. - [2] is the 6over4 mechanism. This is a site local mechanism to use IPv4 multicast as a layer 2 media. It does not solve the problem to connect an isolated user to the global IPv6 Internet. - [3] is the 6to4 mechanism to embed IPv4 tunnel addresses into IPv6 prefixes to automatically discover tunnel endpoints. Some important technical issues such as source address selection and global routing are currently debated in the IETF. But the main difference are in the premises of the two approaches: 6to4 consider that isolated sites are to be dynamically connected in the absence of native IPv6 infrastructure and tunnel brokers consider the pre- existence of a large IPv6 global network. This document presents an alternative approach based on the provision of Tunnel Brokers (TBs) to automatically manage tunnel requests coming from the users. This approach is expected to be useful to stimulate the growth of IPv6 interconnected hosts and to allow to early IPv6 network providers the provision of easy access to their IPv6 networks. Section 2 provides an overall description of the Tunnel Broker Model; section 3 reports known limitations to the model; section 4 addresses security issues. A first implementation of the Tunnel Broker service is described in Appendix to this document. 2. Tunnel Broker Model Tunnel brokers can be seen as virtual IPv6 ISP, providing IPv6 connectivity to users already connected to the IPv4 Internet. In the global IPv6 Internet it is expected that many tunnel brokers will be available and the user will just have to pick one. The list of the tunnel brokers should be referenced on a "well known" web page on http://www.ipv6.org to allow users to choose the "closest" one, the "cheapest" one, or any other one. The tunnel broker model is based on a set of functional elements depicted in figure 1. Durand Fasano Guardini Lento Expires 1 October 1999 [Page 2] Internet Draft draft-ietf-ngtrans-broker-00.txt +------+ /¦tunnel¦ / ¦server¦ / ¦ ¦ / +------+ +----------+ +------+/ +------+ ¦dual-stack¦ ¦tunnel¦ ¦tunnel¦ ¦ node ¦<--->¦broker¦<--->¦server¦ ¦ (user) ¦ ¦ ¦ ¦ ¦ +----------+ +------+\ +------+ ¦ \ +------+ tunnel end-point v \ ¦tunnel¦ /\ +---+ \ ¦server¦ || ¦DNS¦ \¦ ¦ || +---+ +------+ || || tunnel end-point || /\ || || |+---------------------------+| +-----------------------------+ IPv6 over IPv4 tunnel Figure 1: the Tunnel Broker model 2.1 Tunnel Broker The TB is a place where users connect to register and activate tunnels. The TB manages tunnels creation, modification and deletion on behalf of the users. It shares the load of tunnel end-points on the network side among potentially several tunnel servers. It sends configuration orders to the relevant tunnel server when tunnels are to be created or modified. The TB also register the user in the DNS. 2.2 Tunnel server A tunnel server is a dual stack (IPv4 & IPv6) router connected to the global Internet. Upon configuration order from the tunnel broker, it creates, modifies or deletes the half part of the tunnel toward the user. It can also maintain some statistics on the usage of the tunnels. 2.3 Using the Tunnel Broker The client of the service is a dual-stack IPv6 node (host or router) connected to Internet. Approaching the TB, the client must provide the following information: - the IPv4 address of the client side of the tunnel - a nickname to be used for the registration in the DNS of the global IPv6 addresses assigned to both sides of the tunnel - the client function (i.e. standalone host or router) Durand Fasano Guardini Lento Expires 1 October 1999 [Page 3] Internet Draft draft-ietf-ngtrans-broker-00.txt Besides, if the client machine is an IPv6 router willing to provide geographical connectivity to several IPv6 hosts, the client should be required to provide also some information about the amount of IPv6 addresses required. This allows the TB to allocate to the client an IPv6 subnet well fit to his needs instead of a single IPv6 address. Otherwise an IPv6 prefix of pre-defined length should be assigned to any client acting as an IPv6 router. The TB manages the client requests as follows: - it first designates (e.g. according to some load sharing criteria defined by the network administrator) a Tunnel Server to be used as the actual tunnel end-point at the network side; - it chooses the IPv6 prefix (/64 or /48) to be used; - it fixes a lifetime for the tunnel; - it configures the network side of the tunnel; - it registers tunnel end-points addresses in the DNS; - it prepares activation and de-activation scripts to be run on the client machine for easy configuration of the client side. Then the TB sends back configuration information to the user, including tunnel parameters and DNS names. The lifetime of the IPv6 addresses are supposed to be relatively long and potentially longer than the lifetime of the IPv4 connection of the user. This will allow the user to get semipermanent IPv6 addresses and associated DNS names even though he is connected to the Internet via a dial-up link and get dynamically his IPv4 addresses by DHCP. There are many technical alternatives to realize the interactions among the various entities in the tunnel broker model. The communication protocol used between the TB and the user could be based on SNMP, on an extension of DHCPv6, on an ad-hoc protocol or even on just some web forms filled up by the user. In a similar way, the communication protocol used between the TB and the tunnel servers is also implementation dependant. It could be some simple RSH commands, SNMP or an ad-hoc protocol specially designed or something else. Finally the Dynamic DNS Update protocol [4] should be used for automatic DNS update (i.e. to add or delete AAAA, A6 and PTR records from the DNS zone reserved for tunnel broker users) controlled by the TB. A simple alternative would be for the TB to use a small set of RSH commands to dynamically update the direct and inverse databases on the authoritative DNS server for the tunnel broker users zone (e.g. broker.isp-name.com). 2.4 Open issues Real usage of the TB service may require to introduce accounting/ billing functions. 3. Known limitations This mechanism may not work if the user is using private IPv4 addresses behind a NAT box. Durand Fasano Guardini Lento Expires 1 October 1999 [Page 4] Internet Draft draft-ietf-ngtrans-broker-00.txt 4. Security Considerations The TB service raises several security issues. All interactions between the functional elements of the proposed architecture need to be secured, i.e.: - the interaction between the client and TB; - the interaction between the TB and the Tunnel Server; - the interaction between the TB and the DNS. Furthermore, if the client chooses to run the configuration scripts provided by TB, these scripts must be executed as root. The security techniques adopted for each of the required interaction is dependent on the implementation choices. For the client - TB interaction, the usage of http allows the exploitation of standard secure http features (SSL, S- HTTP). If e-mail exchanges are used standard mechanisms to secure e-mail can be used (PGP, PEM). For the interactions that use SNMP, the security issues are basically the same as those of securing SNMP. Otherwise if RSH commands are used standard IPsec mechanisms may apply. If the TB - DNS server interaction is a dynamic DNS update procedure, the security issues are the same discussed in [5] Finally TBs may face denial of service attack. They must implement some sort of protection against this. 5. Acknowledgments Some of the ideas refining the tunnel broker model came from discussion with Perry Metzger and Marc Blanchet. 6. References [1] Gilligan, R., Nordmark, E., "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [2] Carpenter, B., Jung, C., " Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", draft-ietf-ipngwg-6over4-02.txt, January 1998. [3] Carpenter, B., Moore, K., "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-00.txt, January 1999. [4] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [5] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997. 7. Author's addresses Alain Durand IMAG Direction des Moyens Informatiques BP 53 38041 GRENOBLE CEDEX 9 France Tel: +33 4 76635703 Mail: Alain.Durand@imag.fr Durand Fasano Guardini Lento Expires 1 October 1999 [Page 5] Internet Draft draft-ietf-ngtrans-broker-00.txt Paolo Fasano S.p.A. CSELT Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy Tel: +39 011 2285071 Mail: paolo.fasano@cselt.it Ivano Guardini CSELT S.p.A. Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy Tel: +39 011 2285424 Mail: ivano.guardini@cselt.it Domenico Lento CSELT S.p.A. Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy Tel: +39 011 2286993 Mail: domenico.lento@cselt.it Durand Fasano Guardini Lento Expires 1 October 1999 [Page 6] Internet Draft draft-ietf-ngtrans-broker-00.txt Appendix Implementation Example This appendix describes an early implementation of the TB service developed at CSELT, based on widely available communication tools. The basic communications between the clients and the TB run over http. The client uses a browser and can access a WWW Server providing the TB service interface. This interface offers two different hyperlinks, one for the new users and another for the registered users. The new user has to provide some identification data (Name, Company and e-mail address) and a nickname to be used as: - the username to login as registered user - the name identifying the user in the DNS database This information is submitted to the TB with a POST method. The TB starts the user configuration procedure and sends back an e-mail to the user providing a password for accessing the registered user pages and the name registered in the DNS database. The registered user has the possibility to create a new tunnel, to view tunnel information, to change tunnel parameters and to remove an established tunnel (only one active tunnel per user is allowed). To create a new tunnel, the user has to provide some additional information: - the IPv4 address of the user-side tunnel end-point (the TB pre-fill this field using http carried browser information); - the O.S./IPv6 implementation used; - if the user end-point of the tunnel will be on a host or router. If the user requests to use a router as tunnel end-point a new form is pushed to the user asking: - motivation; - life-time. Then the user submit this information to the TB and the tunnel configuration procedure takes place. A registered user who has already set-up a tunnel can view a display of the following tunnel parameters: - Server IPv4 Address - Server IPv6 Address - Server IPv6 Link Local Addr - Client IPv4 Address - Client IPv6 Address - Client IPv6 Link Local Addr - Expiration Date The user can also modify the Client IPv4 Address if this is changed, can Durand Fasano Guardini Lento Expires 1 October 1999 [Page 7] Internet Draft draft-ietf-ngtrans-broker-00.txt extend the tunnel life-time a day before the Expiration date and can delete the tunnel anytime. The communication between the client and the TB may be secured using SSL (access to the TB using the https scheme). A.1 User configuration procedure When the TB receives a request of registration by a new user, it operates as follows: - uses the nickname to build a name identifying that user in the DNS system; - updates an internal user database; - sends an e-mail back to the user. A.2 Tunnel configuration procedure Once a registered user asked for the creation of a tunnel providing all the required information the TB first checks if the user requested to terminate the tunnel on a router or on a host. If the user choice was a router the request is put in a pending state and managed administratively: the administrator of the TB has the possibility to accept or refuse the motivations and lifetime indicated by the user. If the user choice was a host the TB acts automatically as follows: i) verifies if resources are available to set-up a new tunnel (otherwise puts the user request in a pending state and go to step viii); ii) selects a Tunnel Server from the list of available Tunnel Servers on the basis of simple number-of-tunnels balancing criteria; iii) selects an IPv6 prefix to be used for assigning IPv6 addresses to the tunnel end-points; iv) sets an Expiration Date for the tunnel (default 7 days); v) configures the Tunnel Server; vi) updates the DNS server; vii) prepares activation and de-activation scripts for tunnel configuration on the user side; viii) pushes to the user browser a new page displaying the results of the tunnel request: if OK the new page displays tunnel parameters and hyperlinks to the activation and de-activation scripts. The user who receives positive acknowledgment can then execute (downloading the scripts or not) the activation script to configure the user side of the tunnel. There is still the possibility for a user that do not want to run the configuration scripts or that has an IPv6 implementation not supported by the TB to set up his/her end-point of the tunnel manually. At the end of this procedure the user is IPv6 connected and identified by his/her own name in the DNS. A similar procedure is performed when the user selected a router as tunnel end-point and the Administrator accepted the request. Durand Fasano Guardini Lento Expires 1 October 1999 [Page 8] Internet Draft draft-ietf-ngtrans-broker-00.txt A.3 User, Tunnel and Tunnel Server management The TB maintains three databases, one for users, one for active tunnels and the last one for Tunnel Servers. The User database has one entry for each user of the service; each entry has the following fields: - Username - Password - DNS entry - Firstname - Lastname - Company - Country - E-Mail - Has Tunnel (yes/not for active tunnel) - Tunnel Count (number of tunnel creation performed by the user) The Tunnel database has one entry for each active tunnel; each entry has the following fields: - Identifier - Owner - User IPv4 Address - Server IPv4 Address - User Global IPv6 Address - Server Global IPv6 Address - User Link Local Address - Server Link Local Address - User OS Type - Creation Date - Expiration Date - Standalone - Manual The Tunnel Server database has one entry for each Tunnel Server; each entry has the following fields: - Identifier - IPv4 - IPv6 - OS - Use TBSP - Used Standalone Tunnels - Max Standalone Tunnels - Used Router Tunnels - Max Router Tunnels The TB manages the service updating these databases. An Administrator Interface gives to the TB manager a full control (add, modify and remove any time) over users, tunnels and Tunnel Servers. In order to access to the administrative web pages, the TB administrator has to log as Registered User using the administrative username and Durand Fasano Guardini Lento Expires 1 October 1999 [Page 9] Internet Draft draft-ietf-ngtrans-broker-00.txt password. The page presented to the administrator contains hyperlinks to the following sections: - Administrator Profile Change - User Administration - Tunnel Server Administration - Tunnel Administration The Administrator Profile Change lets the administrator to change his password. The User Administration section, once selected, allows the administrator to interact with the User database in order to list the database content or delete an entry in the database. If the administration deletes an entry with an associated tunnel, the tunnel is released. The Tunnel Server Administration section allows the administrator to manage the data contained in the Tunnel Server database. The page presented to the TB superuser contains hyperlinks to the following subsections: - Tunnel Server List (the content of the Tunnel Server database is displayed with the relevant informations); - Add Tunnel Server (this hyperlink allows the insertion of a new Tunnel Server; the administrator is asked for the Tunnel Server informations as described in the previous section); - Modify Tunnel Server (this subsection is used by the administrator to change the information of a Tunnel Server, e.g. Max Standalone Tunnels); - Delete Tunnel Server (causes the removal of the selected Tunnel Server entry from the Tunnel Server database; the tunnels managed by this Tunnel Server are released). The Tunnel Administration section is used to perform tunnel management. The page presented to the administrator contains hyperlinks to the following subsections: - Tunnel List (the content of the Tunnel database is displayed to the administrator) - Manual Setup (allows the TB superuser to setup manually a tunnel) - Release (causes the release of the selected tunnel) - Change Parameters (allows the update of the data associated to a tunnel) - Pending Router Request (displays the list of the user requests for a tunnel towards a router; two hyperlinks are associated to each entry allowing the administrator to accept or refuse the request). A.4 Modularity The Tunnel Broker implements a plugin-like mechanism for adding support for new Tunnel Servers or client operating systems without modifying the TB scripts or breaking the service. To achieve this result the scripts Durand Fasano Guardini Lento Expires 1 October 1999 [Page 10] Internet Draft draft-ietf-ngtrans-broker-00.txt has to follow a predefined template and are kept in a plugin directory checked at every request for a new tunnel. This implies that the list of supported Tunnel Servers and client OSs is built dynamically, based on the content of the plugin directory. A.4.1 Script directory structure The scripts for interacting with users, Tunnel Servers and DNS are stored in a plugin directory structured as following: | +--- script | +--- dns | +--- server | | | +--- local | | | | | +--- act | | | | | +--- deact | | | +--- remote | | | +--- act | | | +--- deact | +--- client | +--- act | +--- deact The scripts have to be inserted in the proper subdirectory accordingly with their functionality (eg. a Tunnel Server activation script for a remote Tunnel Server in inserted in directory /script/server/remote/act). This tree is scanned by the CGI program every time a user requests scripts for tunnel activation/deactivation and at the insertion of a new Tunnel Server for building the appropriate list of supported OSes. A.4.2 Client scripts Client scripts are used to help a TB user to configure his/her own host. In order to support a new client architecture, a TB adminstrator has to provide both activation and deactivation scripts for the selected configuration. These scripts must include the following keywords, that Durand Fasano Guardini Lento Expires 1 October 1999 [Page 11] Internet Draft draft-ietf-ngtrans-broker-00.txt Scripts follow a naming convention: - activation and deactivation scripts must ave the same name - scripts filename has the structure . (eg. PERL scripts for FreeBSD hosts using INRIA IPv6 implementation could have as filename FreeBSD-INRIA.pl); the name is used as the name displayed in the user interface selection list. will be replaced with proper values for the specific user request: - _ipv4client_ for the client IPv4 address; - _ipv4server_ for server IPv4 address; - _ipv6client_ for the client global IPv6 address; - _ipv6server_ for the server global IPv6 address; - _ipv6llclient_ for the client link local address; - _ipv6llserver_ for the server link local address. Every time a TB user interacts with the TB web pages in order to download the activation/deactivation scripts, the CGI provides keywords substitution with the correct values stored in the TB database. A.4.3 Server scripts Server scripts are used to both setup and release an IPv6 over IPv4 tunnel on a tunnel server. In order to support a new Tunnel Server, a TB administrator has to provide both activation adn deactivation script for the new platform. These scripts are invoked by the CGI program at every tunnel setup or release. The following parameters are passed to the script : (could assume the values 'standalone' or 'router') . The executed script has to return the value 0 on success and -1 on failure. A.4.4 DNS scripts DNS scripts are used to interact with the DNS in order to update its resolution tables. All parameters specific to the DNS (IP address, software, file structure, etc.) and the interaction mode between the TB and the DNS are embedded within the DNS scripts and do not affect other TB scripts. The TB uses a script called 'dns_act' to add a new entry in the DNS database and a script named 'dns_deact' to remove a host entry Durand Fasano Guardini Lento Expires 1 October 1999 [Page 12] Internet Draft draft-ietf-ngtrans-broker-00.txt from the DNS tables. Both scripts are invoked by passing two parameters: . The executed script has to return the value 0 on success and -1 on failure. A.5 CSELT's Tunnel Broker location The TB service is up and running at: https://carmen.cselt.it/ipv6tb The software implementing the TB is freely available at: http://carmen.cselt.it/ipv6/download Durand Fasano Guardini Lento Expires 1 October 1999 [Page 13]