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
<draft-ietf-ngtrans-broker-00.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 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:
<TB plugin home directory>
|
+--- 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
<TB home>/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 <OS-StackType>.<extension>
(eg. PERL scripts for FreeBSD hosts using INRIA IPv6
implementation could have as filename FreeBSD-INRIA.pl); the
<OS-StackType> 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 :
<tunnel type> (could assume the values 'standalone' or 'router')
<client IPv4 address>
<server IPv4 address>
<client global IPv6 address>
<server global IPv6 address>
<client local link address>
<server local link address>.
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:
<host name>
<global IPv6 address>.
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]
