view Side-By-Side changes
INTERNET DRAFT Alain Durand (IMAG)
Paolo Fasano (CSELT)
Ivano Guardini (CSELT)
Domenico Lento (CSELT)
2 April 1999
Expires
1 October october 1999
Expires 31 march 2000
IPv6 Tunnel Broker
<draft-ietf-ngtrans-broker-00.txt>
<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 build 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 the early IPv6 adopters to hook up
to the 6bone and to provide them 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
in
during the Grenoble IPng & NGtrans interim meeting.
Durand Fasano Guardini Lento Expires 1 October 1999 31 march 2000 [Page 1]
Internet Draft draft-ietf-ngtrans-broker-00.txt 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 fact brought led to the
development of several techniques to manage IPv6 over IPv4 tunnels. At
present most of the 6bone networks network is built using manual tunneling manually configured
tunnels over the Internet. The main drawback of this approach is the
overwhelming management load for network administrators, who have to
perform heavy extensive manual configuration operations for each tunnel. Several
attempts to reduce this management overhead have already been proposed [1-3]. Nevertheless all
and each of them present presents interesting advantages but also solves
different problems than the Tunnel Broker, or poses drawbacks that prevent from wide usage: not
present in the Tunnel Broker:
- [1] was introduced to is the basic IPng Transition Mechanism. It proposes the use
of automatic tunnels with IPv4 compatible
addresses. This 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 in
into the IPv6 one and just making world because this would worsen the routing table
size problem worse by multiplying it by 5. 4.
- [2] is the 6over4 mechanism. This proposal. It is a site local transition
mechanism to based on the use of IPv4 multicast as a layer 2 media. virtual link
layer. It does not solve the problem to
connect of connecting an isolated
user to the global IPv6 Internet.
- [3] is the 6to4 mechanism 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 to so that any
domain border router can 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 endpoints
for outbound IPv6 global network. 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 to early IPv6
network providers the provision of 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 Appendix to this document.
2. Tunnel Broker Model 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 ISP, 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 and 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 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 the 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¦
/ªtunnelª
/ ¦server¦ ªserverª
/ ¦ ¦ ª ª
/ +------+
+----------+ +------+/ +------+
¦dual-stack¦ ¦tunnel¦ ¦tunnel¦
¦
ªdual-stackª ªtunnelª ªtunnelª
ª node ¦<--->¦broker¦<--->¦server¦
¦ ª<--->ªbrokerª<--->ªserverª
ª (user) ¦ ¦ ¦ ¦ ¦ ª ª ª ª ª
+----------+ +------+\ +------+
¦
ª \ +------+
tunnel end-point v \ ¦tunnel¦ ªtunnelª
/\ +---+ \ ¦server¦ ªserverª
|| ¦DNS¦ \¦ ¦ ªDNSª \ª ª
|| +---+ +------+
||
|| tunnel end-point
|| /\
|| ||
|+---------------------------+|
+-----------------------------+
IPv6 over IPv4 tunnel
Figure 1: the Tunnel Broker model
2.1 Tunnel Broker
The TB is a the place where users connect the user connects to register and activate
tunnels. The TB manages tunnels tunnel creation, modification and deletion on
behalf of the users. It shares user.
For scaleability reasons the load of tunnel end-points on broker can share the load of
network side tunnel end-points among potentially several tunnel servers. servers (TSs). It
sends configuration orders to the relevant tunnel server when tunnels are whenever a
tunnel have to be created created, modified or
modified. deleted. The TB also register 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 tunnel server TS is a dual stack (IPv4 & IPv6) router connected to the global
Internet. Upon receipt of a configuration order coming from the tunnel broker, TB, it
creates, modifies or deletes the half part server side of the tunnel toward the
user. each tunnel. It can
also maintain some statistics on the usage of the tunnels. 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 tunnel;
- a nickname to be used for the registration in the DNS of the global
IPv6 addresses assigned to both sides of the tunnel 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 router).
Besides, if the client machine is an IPv6 router willing to provide
geographical connectivity to several IPv6 hosts, the client should be
required
asked to provide also provide some information about the amount of IPv6
addresses required. This allows the TB to allocate to the client an
IPv6 subnet well that will fit to his needs instead of a single IPv6 address.
Otherwise an IPv6 prefix of pre-defined length should (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 (/64 (e.g. /64 or /48) to be used; 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 network server side of the tunnel;
- it registers tunnel end-points addresses in the DNS;
- it prepares activation and de-activation scripts to be run on optionally configures the client machine for easy configuration side of the client side.
Then the TB tunnel;
- it sends back the relevant configuration information to the user,
including tunnel parameters and DNS names. The lifetime of
After the IPv6 addresses are
supposed to be relatively long and potentially longer than above configuration steps have been carried out (including
the lifetime configuration of the client), the IPv6 over IPv4 connection of tunnel between
the user. This will allow client host/router and the selected TS should be up and working,
thus allowing the tunnel broker user to get
semipermanent access to the 6bone or any
other IPv6 addresses and associated DNS names even though he network the TS is connected to.
2.4 IPv6 address assignment
The IPv6 addresses assigned to the Internet via a 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 get gets dynamically his assigned IPv4 addresses by
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 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 various entities in client side of the tunnel broker model. The communication
protocol used between the TB and would be left to the user could be based on SNMP, on an
extension of DHCPv6, on an ad-hoc protocol or even on himself while
the Tunnel Broker Server would provide just some web
forms filled up by for the user. In a similar way, 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 also implementation dependant. dependent as well. It could be some a set of simple RSH
commands, SNMP or
an ad-hoc protocol 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.4
2.7 Open issues
Real usage of the TB service may require to introduce accounting/
billing 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.
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.: 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.
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 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). 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. 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 [5] [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 may face must implement protections against denial of service attack. They must implement some
sort
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. 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-00.txt,
January 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
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 31 march 2000 [Page 6] 8]
Internet Draft draft-ietf-ngtrans-broker-00.txt 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
client uses
tunnel broker service interface is implemented through a WWW server
located on the TB. Using a standard WWW browser and the user can access a WWW Server
home page providing some general information on the TB service interface. This interface offers and two different hyperlinks,
hyperlinks: one for the new users and another for the already registered
users.
The
Each new user has is required to provide fill a web form with some
identification data (Name, Company and e-mail address) and a nickname.
The nickname to be is used as:
- both as the username to login as registered user
-
and as the name identifying the user in the DNS database
This information is submitted to database.
After having received all the TB with a POST method. The TB
starts necessary identification data, the user
configuration procedure and takes place. After that, the TB sends back an e-mail to
the user providing a password for accessing an e-mail specifying the username (it is just the nickname
previously chosen by the registered user pages himself) and the name registered in password to get access
to the DNS database.
The web pages reserved to registered users.
A registered user has the possibility to can create a new tunnel, to view the tunnel
information, to change the tunnel parameters and to remove an established tunnel (only
tunnel. In order to reduce the risk of denial of service attacks (see
section 4) only one active tunnel per user is allowed). To allowed.
In order to create a new tunnel, the user has to provide some
additional information:
- the IPv4 address of the user-side tunnel end-point on the user side (the TB pre-fill
pre-fills this field using http carried the browser information); information carried by http);
- the O.S./IPv6 implementation used;
- if used on the client machine (the user end-point
can choose only among a list of supported client architectures
displayed by the tunnel will be on a TB);
- the client function (i.e. standalone host or router. router).
If the user requests 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 use him instead of a router as single IPv6 address. In
this case, before going through the actual address delegation and
tunnel end-point setup, the TB pushes a new form is
pushed to the user asking: asking for further
information:
- motivation; motivation for the router request;
- desired tunnel life-time.
Then the user submit submits 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 31 march 2000 [Page 7] 9]
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). draft-ietf-ngtrans-broker-01.txt
A.1 User configuration procedure
When the TB receives a request of registration by request from a new user, it
operates as follows:
- it uses the nickname provided by the user to build a the name identifying
that user 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 back specifying the username
and password to access the user. web area on the TB reserved to
registered users.
A.2 Tunnel configuration creation procedure
Once
When a registered user asked asks for the creation of a tunnel providing all
the required information tunnel, the TB first
checks if whether the user requested to terminate the tunnel on a router
or on a host. If the user choice was a
router 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 request based on the
motivation and lifetime indicated by the user. If the user choice was
a host the TB acts automatically as follows: according to the following algorithm:
i) verifies verify if resources are available to set-up setup a new tunnel
(otherwise puts tunnel.
If the user request in a pending state and answer is "yes" go on with step ii, otherwise go to
step viii); viii;
ii) selects select a Tunnel Server from the list of available Tunnel
Servers based on the basis of a simple number-of-tunnels balancing
criteria;
iii) selects an select the IPv6 prefix to be used for assigning IPv6
addresses to the tunnel end-points;
iv) sets an set the Expiration Date for the tunnel (default is 7 days);
v) configures configure the Tunnel Server;
vi) updates update the DNS server; DNS;
vii) prepares prepare the activation and de-activation scripts for tunnel
configuration on the user side;
viii) pushes push to the user browser a new web page displaying the results
of the tunnel request: if OK 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
(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 his end-point of the tunnel manually. At the end
of this procedure the user is gets IPv6
connected and identified by his/her own connectivity together with a
valid name in the DNS.
A similar procedure is performed when the user selected selects a router as
tunnel end-point and the Administrator accepted accepts the request.
Durand Fasano Guardini Lento Expires 1 October 1999 31 march 2000 [Page 8] 10]
Internet Draft draft-ietf-ngtrans-broker-00.txt 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 has includes the following
fields:
- Username
- Password
- DNS entry
- Firstname
- Lastname
- Company
- Country
- E-Mail
- Has Tunnel (yes/not for ("yes" if the user has an active tunnel)
- Tunnel Count (number of tunnel creation performed procedures
carried out by the user)
The Tunnel database has one entry for each active tunnel; each entry has
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
- Use TBSP 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
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, 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 (this hyperlink allows (for the insertion of a new Tunnel Server; the
administrator is asked for has to provide the relevant Tunnel Server
informations
information as described in the previous section);
- Modify Tunnel Server (this subsection is used by the administrator
to change the information configuration of a Tunnel Server, e.g. Max Standalone
Tunnels);
- Delete Tunnel Server (causes to increase
or reduce the removal maximum number of standalone tunnels allowed on
the selected TS);
- Delete Tunnel Server entry (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 to
the administrator) displayed);
- Manual Setup (allows the TB superuser to setup manually a tunnel) tunnel);
- Release (causes (allows the TB superuser to release of the selected tunnel) an active tunnel);
- Change Parameters (allows the (to update of the data associated to
a tunnel) 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
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 lists of supported Tunnel Servers and client OSs is 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 following: follows:
Durand Fasano Guardini Lento Expires 31 march 2000 [Page 13]
Internet Draft draft-ietf-ngtrans-broker-01.txt
<TB plugin home directory> home>
|
+--- script
|
+--- dns
|
+--- server
| |
| +--- local
| | |
| | +--- act
| | |
| | +--- deact
| |
| +--- remote
| |
| +--- act
| |
| +--- deact
|
+--- client
|
+--- act
|
+--- deact
The scripts have to be inserted put in the proper subdirectory accordingly
with according to
their functionality (eg. functionality:
- DNS update scripts must be placed in the directory
<TB home>/script/dns
- tunnel activation and de-activation scripts for a Tunnel Server 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 script and de-activation scripts for a remote Tunnel Server TS must
be placed in inserted 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 directory the directories
<TB home>/script/server/remote/act).
This home>/script/client/act
and
<TB home>/script/client/deact
respectively.
The script tree is scanned by the CGI program 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 requests requires scripts for tunnel activation/deactivation activation and at the insertion of a new
Tunnel Server for building the appropriate list of supported OSes.
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
Client
The client scripts are used to help a TB user to configure his/her his own
host. In order to support a new client architecture, a the TB adminstrator
administrator has to provide both activation and deactivation de-activation scripts
for the selected
configuration. These that architecture. The names of these scripts must include be chosen
according to 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:
- the activation and deactivation de-activation scripts must ave have the same name
but has to be placed in the directories
<TB home>/script/client/act
and
<TB home>/script/client/deact
respectively;
- scripts the script filename has the structure <OS-StackType>.<extension>
(eg.
(e.g. the filename of PERL scripts for a host based on FreeBSD hosts using
and INRIA IPv6 implementation could have as filename FreeBSD-INRIA.pl); the
<OS-StackType> name is might be FreeBSD-INRIA.pl).
The <OS-StackType> keywords (one for every supported client platform)
are also used as by the name TB to build the dynamic list of supported client
types which is displayed in to the user interface selection list.
will be during the tunnel creation
procedure.
Both the activation and de-activation scripts must include the
following keywords that are replaced with proper values for the specific 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 in order to download the activation/deactivation
activation/de-activation scripts, the CGI provides keywords
substitution TB replaces each keyword with
the correct values stored in the TB database. database (e.g. _ipv4client_ is
replaced with the real IPv4 address of the user side tunnel
end-point).
A.4.3 Server scripts
Server
The server scripts are used to both setup and release an IPv6 over IPv4
tunnel on a tunnel server. In order to add support for a new Tunnel
Server, a the TB administrator has to provide both activation adn deactivation script and
de-activation scripts for the new platform. These scripts are invoked
by the CGI program TB at every tunnel setup or release.
The names of the server scripts must be chosen according to the
following parameters are passed 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 :
<tunnel type> (could assume filename has the values 'standalone' 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 'router') released, the TB executes
the relevant server activation or de-activation script as follows:
script_name (<tunnel type>,
<client IPv4 address> address>,
<server IPv4 address> address>,
<client global IPv6 address> address>,
<server global IPv6 address> address>,
<client local link address>
<server local IPv6 address>,
<server link address>.
The executed 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' "dns_act" to add a new
entry in the DNS database and a script named 'dns_deact' "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 These two scripts are invoked by passing two parameters:
<host name> executed as
follows:
dns_act (<host name>,
<global IPv6 address>.
The executed 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 TB tunnel broker service is freely
available at:
http://carmen.cselt.it/ipv6/download
Durand Fasano Guardini Lento Expires 1 October 1999 31 march 2000 [Page 13] 17]
----