Internet Engineering Task Force Authors
INTERNET DRAFT Alain Durand (IMAG)
Paolo Fasano (CSELT)
Ivano Guardini (CSELT)
Domenico Lento (CSELT)
1 october 1999
Expires 31 march 2000
IPv6 Tunnel Broker
<draft-ietf-ngtrans-broker-01.txt>
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 31 march 2000 [Page 1]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 2]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 3]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 4]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 5]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 6]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 7]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 8]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 9]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 10]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 11]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 12]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 13]
Internet Draft draft-ietf-ngtrans-broker-01.txt
<TB home>
|
+--- 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
<TB home>/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
<TB home>/script/server/local/act
and
<TB home>/script/server/local/deact
respectively;
- tunnel activation and de-activation scripts for a remote TS must
be placed in the directories
<TB home>/script/server/remote/act
and
<TB home>/script/server/remote/deact
respectively;
- tunnel activation and de-activation scripts for a given client
must be placed in the directories
<TB home>/script/client/act
and
<TB home>/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 31 march 2000 [Page 14]
Internet Draft draft-ietf-ngtrans-broker-01.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
<TB home>/script/client/act
and
<TB home>/script/client/deact
respectively;
- the script filename has the structure <OS-StackType>.<extension>
(e.g. the filename of PERL scripts for a host based on FreeBSD
and INRIA IPv6 implementation might be FreeBSD-INRIA.pl).
The <OS-StackType> 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 31 march 2000 [Page 15]
Internet Draft draft-ietf-ngtrans-broker-01.txt
- the activation and de-activation scripts must have the
same name but has to be placed in the directories
<TB home>/script/server/[local|remote]/act
and
<TB home>/script/server/[local|remote]/deact
respectively;
- the script filename has the structure <OS-StackType>.<extension>
(e.g. the filename of PERL scripts for a TS based on FreeBSD
and INRIA IPv6 implementation might be FreeBSD-INRIA.pl).
The <OS-StackType> 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 (<tunnel type>,
<client IPv4 address>,
<server IPv4 address>,
<client global IPv6 address>,
<server global IPv6 address>,
<client link local IPv6 address>,
<server link local IPv6 address>);
where <tunnel type> 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 (<host name>,
<global IPv6 address>)
dns_deact (<host name>,
<global IPv6 address>)
After its execution each script has to return the value 0 on success
and -1 on failure.
Durand Fasano Guardini Lento Expires 31 march 2000 [Page 16]
Internet Draft draft-ietf-ngtrans-broker-01.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 31 march 2000 [Page 17]
