Internet Engineering Task Force Authors INTERNET DRAFT Alain Durand (IMAG) Paolo Fasano (CSELT) Ivano Guardini (CSELT) Domenico Lento (CSELT) 6 October 1999 Expires 5 April 2000 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 built 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 early IPv6 adopters to hook up to the 6bone and to get 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 during the Grenoble IPng & NGtrans interim meeting. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 1] Internet Draft draft-ietf-ngtrans-broker-02.txt 1. Introduction The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. At present most of the 6bone network is built using manually configured tunnels over the Internet. The main drawback of this approach is the overwhelming management load for network administrators, who have to perform extensive manual configuration for each tunnel. Several attempts to reduce this management overhead have already been proposed and each of them presents interesting advantages but also solves different problems than the Tunnel Broker, or poses drawbacks not present in the Tunnel Broker: - [1] is the basic IPng Transition Mechanism. It proposes the use of automatic tunnels with IPv4 compatible addresses as a simple mechanism to establish early IPv6 connectivity among isolated dual-stack hosts and/or routers. The problem with this approach is that it does not solve the address exhaustion problem of IPv4. Also there is a great fear to include the complete IPv4 routing table into the IPv6 world because this would worsen the routing table size problem multiplying it by 4. - [2] is the 6over4 proposal. It is a site local transition mechanism based on the use of IPv4 multicast as a virtual link layer. It does not solve the problem of connecting an isolated user to the global IPv6 Internet. - [3] is the 6to4 proposal. It has been designed to allow isolated IPv6 domains, attached to a wide area network with no native IPv6 support (e.g. the IPv4 Internet), to communicate with other such IPv6 domains with minimal manual configuration. The idea is to embed IPv4 tunnel addresses into the IPv6 prefixes so that any domain border router can automatically discover tunnel endpoints for outbound IPv6 traffic. 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 early IPv6 network providers to provide easy access to their IPv6 networks. The main difference between the Tunnel Broker and the 6to4 mechanism is that the TB serves a different segment of the IPv6 community: those who do not wish to involve themselves with a special router and peering management. The TB fits well for sites, and especially single systems, that want to try out IPv6. On the other hand, the 6to4 approach has been designed to allow IPv4 sites to support IPv6 on a more production basis without having to wait for their IPv4 ISPs to deliver native IPv6 services. 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 the Appendix. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 2] Internet Draft draft-ietf-ngtrans-broker-02.txt 2. Tunnel Broker Model Tunnel brokers can be seen as virtual IPv6 ISPs, 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 so that the user will just have to pick one. The list of the tunnel brokers should be referenced on a "well known" web page (e.g. 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 the set of functional elements depicted in figure 1. +------+ /|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 the place where the user connects to register and activate tunnels. The TB manages tunnel creation, modification and deletion on behalf of the user. For scaleability reasons the tunnel broker can share the load of network side tunnel end-points among several tunnel servers (TSs). It sends configuration orders to the relevant tunnel server whenever a tunnel have to be created, modified or deleted. The TB also registers the user in the DNS. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 3] Internet Draft draft-ietf-ngtrans-broker-02.txt 2.2 Tunnel server A TS is a dual stack (IPv4 & IPv6) router connected to the global Internet. Upon receipt of a configuration order coming from the TB, it creates, modifies or deletes the server side of each tunnel. It can also maintain usage statistics for every active tunnel. 2.3 Using the Tunnel Broker The client of the Tunnel Broker service is a dual-stack IPv6 node (host or router) connected to the 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). Besides, if the client machine is an IPv6 router willing to provide geographical connectivity to several IPv6 hosts, the client should be asked to also provide some information about the amount of IPv6 addresses required. This allows the TB to allocate to the client an IPv6 subnet that will fit his needs instead of a single IPv6 address. Otherwise an IPv6 prefix of pre-defined length (e.g. /48 or /64) would 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 (e.g. /64 or /48) to be used on the tunnel; - it fixes a lifetime for the tunnel; - it automatically registers in the DNS the global IPv6 addresses assigned to the tunnel end-points; - it configures the server side of the tunnel; - it optionally configures the client side of the tunnel; - it sends back the relevant configuration information to the user, including tunnel parameters and DNS names. After the above configuration steps have been carried out (including the configuration of the client), the IPv6 over IPv4 tunnel between the client host/router and the selected TS should be up and working, thus allowing the tunnel broker user to get access to the 6bone or any other IPv6 network the TS is connected to. 2.4 IPv6 address assignment The IPv6 addresses assigned to both sides of every tunnel should be global IPv6 addresses belonging to the IPv6 addressing space owned by the organization that manages the TB. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 4] Internet Draft draft-ietf-ngtrans-broker-02.txt The lifetime of the IPv6 addresses should be relatively long and potentially longer than the lifetime of the IPv4 connection of the user. This is to allow the client to get semipermanent IPv6 addresses and associated DNS names even though it is connected to the Internet via a dial-up link and gets dynamically assigned IPv4 addresses through DHCP. 2.5 Tunnel management Active tunnels consume precious resources on the tunnel servers in terms of memory and processing time. For this reason it is advisable to keep the number of unused tunnels as small as possible deploying a well designed tunnel management mechanism. Each IPv6 over IPv4 tunnel created by the TB should at least be assigned a lifetime and removed after its expiration unless an explicit lifetime extension request is submitted by the client. Obviously this is not an optimal solution especially for users accessing the Internet through short-lived and dynamically addressed IPv4 connections (e.g. dial-up links). In this case it is likely that a newly established tunnel will be used just for a short time and then never again, provided that every time the user reconnects he gets a new IPv4 address and is therefore obliged to set up a new IPv6 over IPv4 connection or to update the configuration of the previous one. In such a situation more effective tunnel management could be achieved by having the TS periodically deliver to the TB IPv6 traffic and reachability statistics for every active tunnel. In this way the TB could be instructed to release a tunnel after a period of inactivity without waiting for the expiration of the related lifetime which can be relatively longer (e.g. several days). The optimal solution would be to implement some kind of keep-alive mechanism between the client and the TS (or between the client and the TB) so that each tunnel can be immediately released after the user disconnects (e.g. removing his tunnel end-point or tearing down his connection to the Internet). The drawback of this policy mechanism is that it may also require a software upgrade on the client machine in order to add support for the ad-hoc keep-alive mechanism described above. 2.6 Interactions between client, TB, TS and DNS There are many technical alternatives to realize the interactions among the various entities in the tunnel broker architecture. The simplest interaction between the TB and the user could be based on http. For example the user could provide the relevant configuration information (i.e. the IPv4 address of the client side of the tunnel, etc.) by just filling up some web forms on the TB server. The configuration of the client from the TB could be achieved by means of simple remote shell (RSH) commands issued by the server, using SNMP (Simple Network Management Protocol) or developing an ad-hoc protocol Durand Fasano Guardini Lento Expires 5 April 2000 [Page 5] Internet Draft draft-ietf-ngtrans-broker-02.txt or some special extensions to DHCPv6 in order to make it suitable for the configuration of IPv6 over IPv4 tunnels on the client. In order to avoid the use of any configuration protocol the TB could just prepare activation and de-activation scripts to be run off-line on the client machine for easy configuration of the client side. In order to keep things as simple as possible it would be even possible to avoid deploying any kind of protocol/mechanism for the TB Server to automatically configure the client. In this case the configuration of the client side of the tunnel would be left to the user himself while the Tunnel Broker Server would provide just for the automatic configuration of the server side of the tunnel (i.e. the designated Tunnel Server). The communication protocol used between the TB and the tunnel servers is implementation dependent as well. It could be a set of simple RSH commands, SNMP, a specially designed ad-hoc protocol 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.7 Open issues Real usage of the TB service may require the introduction of accounting/billing functions. 3. Known limitations This mechanism may not work if the user is using private IPv4 addresses behind a NAT box. 4. Security Considerations The TB service raises several security issues. All interactions between the functional elements of the proposed architecture need to be secured: - the interaction between the client and TB; - the interaction between the TB and the Tunnel Server; - the interaction between the TB and the DNS. The security techniques adopted for each of the required interactions 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 Durand Fasano Guardini Lento Expires 5 April 2000 [Page 6] Internet Draft draft-ietf-ngtrans-broker-02.txt as those of securing SNMP [5,6,7]. 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 as discussed in [8]. Furthermore, if the configuration of the client is achieved running scripts provided by the TB, these scripts must be executed as root. In addition a loss of confidentiality may occur whenever a dial-up user disconnects from the Internet without tearing down the tunnel previously established through the TB. In fact, the TS continues tunneling the IPv6 traffic addressed to that user to his old IPv4 address regardless of the fact that in the meanwhile that IPv4 address could have been dynamically assigned to another subscriber of the same dial-up ISP. This problem could be solved by implementing on every tunnel the keep-alive mechanism outlined in section 2.5 thus allowing the TB to immediately stop IPv6 traffic forwarding towards disconnected users. Finally TBs must implement protections against denial of service attacks which may occur whenever a malicious user finishes off all the resources available on the server side by asking for a lot of tunnels to be established altogether. A possible protection against this attack could be achieved by administratively limiting the number of tunnels that a single user is allowed to set up at the same time. 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-02.txt, June 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] Wijnen, B., Harrington, D., Presuhn, R., "An Architecture for Decribing SNMP Management Frameworks", RFC 2571, April 1999. [6] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [7] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 7] Internet Draft draft-ietf-ngtrans-broker-02.txt [8] 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 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 5 April 2000 [Page 8] Internet Draft draft-ietf-ngtrans-broker-02.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 tunnel broker service interface is implemented through a WWW server located on the TB. Using a standard WWW browser the user can access a home page providing some general information on the service and two hyperlinks: one for new users and another for already registered users. Each new user is required to fill a web form with some identification data (Name, Company and e-mail address) and a nickname. The nickname is used both as the username to login as registered user and as the name identifying the user in the DNS database. After having received all the necessary identification data, the user configuration procedure takes place. After that, the TB sends back to the user an e-mail specifying the username (it is just the nickname previously chosen by the user himself) and the password to get access to the web pages reserved to registered users. A registered user can create a new tunnel, view the tunnel information, change the tunnel parameters and remove an established tunnel. In order to reduce the risk of denial of service attacks (see section 4) only one active tunnel per user is allowed. In order to create a new tunnel, the user has to provide some additional information: - the IPv4 address of the tunnel end-point on the user side (the TB pre-fills this field using the browser information carried by http); - the O.S./IPv6 implementation used on the client machine (the user can choose only among a list of supported client architectures displayed by the TB); - the client function (i.e. standalone host or router). If the user declares that the client machine will be a router providing IPv6 connectivity for a whole site, a wide IPv6 addressing space should be delegated to him instead of a single IPv6 address. In this case, before going through the actual address delegation and tunnel setup, the TB pushes a new form to the user asking for further information: - motivation for the router request; - desired tunnel life-time. Then the user submits this information to the TB and the tunnel configuration procedure takes place. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 9] Internet Draft draft-ietf-ngtrans-broker-02.txt A.1 User configuration procedure When the TB receives a registration request from a new user, it operates as follows: - it uses the nickname provided by the user to build the name that will identify the IPv6 addresses of both sides of the tunnel in the DNS system; - it updates an internal user database; - it sends back to the user an e-mail specifying the username and password to access the web area on the TB reserved to registered users. A.2 Tunnel creation procedure When a registered user asks for the creation of a tunnel, the TB first checks whether 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 request based on the motivation and lifetime indicated by the user. If the user choice was a host the TB acts automatically according to the following algorithm: i) verify if resources are available to setup a new tunnel. If the answer is "yes" go on with step ii, otherwise go to step viii; ii) select a Tunnel Server from the list of available Tunnel Servers based on a simple number-of-tunnels balancing criteria; iii) select the IPv6 prefix to be used for assigning IPv6 addresses to the tunnel end-points; iv) set the Expiration Date for the tunnel (default is 7 days); v) configure the Tunnel Server; vi) update the DNS; vii) prepare the activation and de-activation scripts for tunnel configuration on the user side; viii) push to the user browser a new web page displaying the results of the tunnel request. If the tunnel creation procedure terminated successfully this new page displays the tunnel parameters and hyperlinks to the activation and de-activation scripts. The user who receives positive acknowledgment can then execute 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 end-point of the tunnel manually. At the end of this procedure the user gets IPv6 connectivity together with a valid name in the DNS. A similar procedure is performed when the user selects a router as tunnel end-point and the Administrator accepts the request. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 10] Internet Draft draft-ietf-ngtrans-broker-02.txt A registered user who has already setup a tunnel can view a display of the following tunnel parameters: - Server IPv4 Address - Server IPv6 Address - Server IPv6 Link Local Address - Client IPv4 Address - Client IPv6 Address - Client IPv6 Link Local Address - Expiration Date The user can also modify the Client IPv4 Address if this is changed, can 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 has been secured using SSL (access to the TB using the https scheme). 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 includes the following fields: - Username - Password - DNS entry - Firstname - Lastname - Company - Country - e-mail - Has Tunnel ("yes" if the user has an active tunnel) - Tunnel Count (number of tunnel creation procedures carried out by the user) The Tunnel database has one entry for each active tunnel; each entry includes 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 ("yes" if the tunnel is terminated on a standalone host at the user side; "no" if the tunnel is terminated on an IPv6 router) Durand Fasano Guardini Lento Expires 5 April 2000 [Page 11] Internet Draft draft-ietf-ngtrans-broker-02.txt - Manual ("yes" if the tunnel has been setup manually by the TB administrator) The Tunnel Server database has one entry for each Tunnel Server; each entry has the following fields: - Identifier - IPv4 address - IPv6 prefix (is the IPv6 prefix identifying the IPv6 addressing space dynamically administered by the TB to number the tunnel end-points and the user sites) - OS Type (is a keyword identifying the Operating System type and the IPv6 implementation installed on the TS; the administrator can choose only among a list of supported TS architectures displayed by the TB) - Used Standalone Tunnels (is the number of active standalone tunnels on this TS) - Max Standalone Tunnels (is the maximum number of active standalone tunnels allowed on this TS) - Used Router Tunnels (is the number of active router tunnels on this TS) - Max Router Tunnels (is the maximum number of active router tunnels allowed on this TS) 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 get access to the administrative web pages, the TB administrator has to log as Registered User using the administrative username (root) and 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 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); Durand Fasano Guardini Lento Expires 5 April 2000 [Page 12] Internet Draft draft-ietf-ngtrans-broker-02.txt - Add Tunnel Server (for the insertion of a new Tunnel Server; the administrator has to provide the relevant Tunnel Server information as described in the previous section); - Modify Tunnel Server (this subsection is used by the administrator to change the configuration of a Tunnel Server, e.g. to increase or reduce the maximum number of standalone tunnels allowed on the TS); - Delete Tunnel Server (to remove a TS 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); - Manual Setup (allows the TB superuser to setup manually a tunnel); - Release (allows the TB superuser to release an active tunnel); - Change Parameters (to update the configuration of an active 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 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 lists of supported Tunnel Servers and client OSs are 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 follows: Durand Fasano Guardini Lento Expires 5 April 2000 [Page 13] Internet Draft draft-ietf-ngtrans-broker-02.txt | +--- script | +--- dns | +--- server | | | +--- local | | | | | +--- act | | | | | +--- deact | | | +--- remote | | | +--- act | | | +--- deact | +--- client | +--- act | +--- deact The scripts have to be put in the proper subdirectory according to their functionality: - DNS update scripts must be placed in the directory /script/dns - tunnel activation and de-activation scripts for a local TS (i.e. co-located on the TB) must be placed in the directories /script/server/local/act and /script/server/local/deact respectively; - tunnel activation and de-activation scripts for a remote TS must be placed in the directories /script/server/remote/act and /script/server/remote/deact respectively; - tunnel activation and de-activation scripts for a given client must be placed in the directories /script/client/act and /script/client/deact respectively. The script tree is scanned by the TB whenever the DNS system has to be updated, whenever a tunnel on a TS has to be established or released and every time a user requires scripts for tunnel activation and Durand Fasano Guardini Lento Expires 5 April 2000 [Page 14] Internet Draft draft-ietf-ngtrans-broker-02.txt de-activation. A.4.2 Client scripts The client scripts are used to help a TB user to configure his own host. In order to support a new client architecture, the TB administrator has to provide both activation and de-activation scripts for that architecture. The names of these scripts must be chosen according to the following convention: - the activation and de-activation scripts must have the same name but has to be placed in the directories /script/client/act and /script/client/deact respectively; - the script filename has the structure . (e.g. the filename of PERL scripts for a host based on FreeBSD and INRIA IPv6 implementation might be FreeBSD-INRIA.pl). The keywords (one for every supported client platform) are also used by the TB to build the dynamic list of supported client types which is displayed to the user during the tunnel creation procedure. Both the activation and de-activation scripts must include the following keywords that are replaced with proper values at every 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 to download the activation/de-activation scripts, the TB replaces each keyword with the correct values stored in the TB database (e.g. _ipv4client_ is replaced with the real IPv4 address of the user side tunnel end-point). A.4.3 Server scripts The server scripts are used to setup and release an IPv6 over IPv4 tunnel on a tunnel server. In order to add support for a new Tunnel Server, the TB administrator has to provide both activation and de-activation scripts for the new platform. These scripts are invoked by the TB at every tunnel setup or release. The names of the server scripts must be chosen according to the following convention: Durand Fasano Guardini Lento Expires 5 April 2000 [Page 15] Internet Draft draft-ietf-ngtrans-broker-02.txt - the activation and de-activation scripts must have the same name but has to be placed in the directories /script/server/[local|remote]/act and /script/server/[local|remote]/deact respectively; - the script filename has the structure . (e.g. the filename of PERL scripts for a TS based on FreeBSD and INRIA IPv6 implementation might be FreeBSD-INRIA.pl). The keywords (one for every supported TS platform) are also used by the TB to build the list of supported TS types which is displayed to the TB administrator when a new Tunnel Server has to be added. Whenever a tunnel has to be established or released, the TB executes the relevant server activation or de-activation script as follows: script_name (, , , , , , ); where can assume the values "standalone" or "router". After its execution each script has to return the value 0 on success and -1 on failure. A.4.4 DNS scripts The 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 from the DNS tables. These two scripts are executed as follows: dns_act (, ) dns_deact (, ) After its execution each script has to return the value 0 on success and -1 on failure. Durand Fasano Guardini Lento Expires 5 April 2000 [Page 16] Internet Draft draft-ietf-ngtrans-broker-02.txt A.5 CSELT's Tunnel Broker location The TB service is up and running at: https://carmen.cselt.it/ipv6tb The software implementing the tunnel broker service is freely available at: http://carmen.cselt.it/ipv6/download Durand Fasano Guardini Lento Expires 5 April 2000 [Page 17]