WDIFF

draft-ietf-ngtrans-broker-02.txt --> draft-ietf-ngtrans-broker-03.txt

INTERNET DRAFT Alain Durand (IMAG)
INTERNET-DRAFT SUN Microsystems, Inc
July 5, 2000 Paolo Fasano (CSELT)
Expires January 4, 2001 Ivano Guardini (CSELT)
CSELT S.p.A.
Domenico Lento (CSELT)

6 October 1999
Expires 5 April 2000
TIM

IPv6 Tunnel Broker
<draft-ietf-ngtrans-broker-02.txt>
<draft-ietf-ngtrans-broker-03.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 an existing IPv6 network (e.g. the 6bone 6bone) and to get stable,
permanent IPv6 addresses and DNS names. The concept of the tunnel broker
was first presented at Orlando's IETF in December 1998. Two
implementations were demonstrated during the Grenoble IPng & NGtrans
interim meeting.

Durand Fasano Guardini Lento Expires 5 April January 4, 2000 [Page 1]

Internet Draft draft-ietf-ngtrans-broker-02.txt draft-ietf-ngtrans-broker-03.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 [1]
is 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. 5;
- [2] is the 6over4 proposal. It [2] 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.
Internet;
- [3] is the 6to4 proposal. It [3] 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

The Tunnel Broker idea is an alternative approach based on the provision
of dedicated servers, called Tunnel Brokers (TBs) Brokers, 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 mechanisms
is that the TB serves they serve a different segment of the IPv6 community: those
who do not wish to involve themselves with a special router and
peering management. The TB
- the Tunnel Broker fits well for small isolated IPv6 sites, and
especially single
systems, isolated IPv6 hosts using dial-up IPv4 connections, that
want to try out IPv6. On the other hand, easily connect to an existing IPv6 network;
- the 6to4 approach has been designed to allow IPv4 isolated IPv6 sites to support IPv6 on a
more production basis
easily connect together without having to wait for their IPv4 ISPs to
deliver native IPv6 services. This is very well suited for extranet
and virtual private networks. Using 6to4 relays, 6to4 sites can also
reach sites on the IPv6 Internet.

In addition, the Tunnel Broker approach allows IPv6 ISPs to easily
perform access control on the users enforcing their own policies on
network resources utilization.

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 2]

Internet Draft draft-ietf-ngtrans-broker-03.txt

This document is intended to present a framework describing the
guidelines for the provision of a Tunnel Broker service within the
Internet. It does not specify any protocol but details the general
architecture of the proposed approach. It also outlines a set of viable
alternatives for implementing it.
Section 2 provides an overall description of the Tunnel Broker Model;
section model;
Section 3 reports known limitations to the model; section
Section 4 addresses
security issues. A first implementation briefly outlines other possible applications of the Tunnel
Broker service
is described in the Appendix.

Durand Fasano Guardini Lento Expires approach;
Section 5 April 2000 [Page 2]

Internet Draft draft-ietf-ngtrans-broker-02.txt addresses security issues.

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
emerging 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

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 3]

Internet Draft draft-ietf-ngtrans-broker-03.txt

2.1 Tunnel Broker (TB)

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 scalability reasons the tunnel broker can share the load of
network side tunnel end-points among several tunnel servers (TSs). servers.
It sends configuration orders to the relevant tunnel server whenever a
tunnel have has to be created, modified or deleted. The TB may also registers register
the user IPv6 address and name in the DNS.

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 3]

Internet Draft draft-ietf-ngtrans-broker-02.txt

2.2 Tunnel server

A TS is a dual stack (IPv4 & IPv6) TB must be IPv4 addressable. It may also be IPv6 addressable,
but this is not mandatory. Communications between the broker
and the servers can take place either with IPv4 or IPv6.

2.2 Tunnel server (TS)

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 may
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 IPv4 Internet. Approaching the TB,
the client must should be asked first of all to provide its identity and
credentials so that proper user authentication, authorization and
(optionally) accounting can be carried out (e.g. relying on existing
AAA facilities such as RADIUS). This means that the client and the
TB have to share a pre-configured or automatically established
security association to be used to prevent unauthorized use of the
service. With this respect the TB can be seen as an access-control
server for IPv4 interconnected IPv6 users.

Once the client has been authorized to access the service, it should
provide at least the following information:

- the IPv4 address of the client side of the tunnel;
- a nickname name to be used for the registration in the DNS of the global
IPv6 addresses address assigned to both sides the client side of the tunnel;
- the client function (i.e. standalone host or router).

Besides,

Moreover, if the client machine is an IPv6 router willing to provide
geographical
connectivity to several IPv6 hosts, the client should be asked to also
to provide some information about the amount of IPv6 addresses required.
This allows the TB to allocate to the client an IPv6 subnet prefix that will fit his fits its
needs instead of a single IPv6 address.
Otherwise an IPv6 This prefix of pre-defined length (e.g. /48 or /64)
would can
be assigned to any client acting as an IPv6 router. ether 48 or 64 bits.

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 4]

Internet Draft draft-ietf-ngtrans-broker-03.txt

The TB manages the client requests as follows:
- it first designates (e.g. according to some load sharing criteria
defined by the network TB administrator) a Tunnel Server to be used
as the actual tunnel end-point at the network side;
- it chooses the IPv6 prefix (e.g. /128, /64 or /48) to be used on allocated
to the
tunnel; client;
- 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 notifies the relevant configuration information to the user, client,
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 is 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 each tunnel should must be
global IPv6 addresses belonging to the IPv6 addressing space owned
managed by the organization that manages the TB.

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 4]

Internet Draft draft-ietf-ngtrans-broker-02.txt

The lifetime of the these 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 is likely to be used just for a short time and
then never again, provided in that every time the user reconnects he gets a
new IPv4 address and is therefore obliged either to set up set-up a new IPv6 over
IPv4 connection
tunnel or to update the configuration of the previous one. In
such a situation a more effective tunnel management could may be achieved
by having the TS periodically deliver to the TB IPv6 traffic and
reachability statistics for every active tunnel. In this way way,

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 5]

Internet Draft draft-ietf-ngtrans-broker-03.txt

the TB
could be instructed to release can enforce a tunnel deletion 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

Another solution would may be to implement some kind of tunnel management
protocol or 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 IPv4 connection to the Internet). The drawback of
this policy mechanism is that it may also require requires 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

Moreover, keeping track of the tunnel configuration even after the user
has disconnected from the IPv4 Internet may be worth the extra cost. In
this way, in fact, when the user reconnects to realize the interactions Internet, possibly
using a different IPv4 address, he could just restart the tunnel by
getting in touch with the TB again. The TB could then order a TS to
re-create the tunnel using the new IPv4 address of the client but
reusing the previously allocated IPv6 addresses. That way, the client
could preserve a nearly permanent (static) IPv6 address even though
its IPv4 address is dynamic. It could also preserve the associated
DNS name.

2.6 Interactions between client, TB, TS and DNS

As previously stated, the definition of a specific set of protocols
and procedures to be used for the communication among the various
entities in the tunnel broker architecture. Tunnel Broker architecture is outside of the scope of
the present framework document. Nevertheless, in the reminder of this
section some viable technical alternatives to support client-TB,
TB-TS and TB-DNS interactions are briefly described in order to help
future implementation efforts or standardization initiatives.

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 a Web server running on the TB server.

The configuration of the client from TB.
As a result the TB server could be achieved by means
of simple remote shell (RSH) commands issued by the server, using SNMP
(Simple Network Management Protocol) or developing respond with an ad-hoc protocol

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 5]

Internet Draft draft-ietf-ngtrans-broker-02.txt

or some special extensions to DHCPv6 in order to make it suitable for html page stating that
the configuration server end-point of IPv6 over IPv4 tunnels on the client. In order to
avoid tunnel is configured and displaying all
the use of any configuration protocol relevant tunnel information.

After that, the TB could just prepare
activation and de-activation scripts to most trivial approach would be run off-line on to leave the user to
configure the client
machine for easy configuration end-point of the client side. In order tunnel on his own. However, it
should be highly valuable to keep
things support a mechanism to automate this
procedure as simple much as possible it would possible.

Several options may be even possible envisaged to avoid
deploying any kind assist the Tunnel Broker user in
the configuration of protocol/mechanism for his dual-stack equipment. The simplest option
is that the TB Server could just prepare personalized activation and de-
activation scripts to
automatically configure the client. In this case be run off-line on the configuration client machine to
achieve easy set-up of the client side of the tunnel would be left to end-point. This solution
is clearly the user himself while easiest to implement and operate in that it does not

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 6]

Internet Draft draft-ietf-ngtrans-broker-03.txt

require any software extension on the Tunnel Broker Server would provide just client machine. However, it
raises several security concerns because it may be difficult for the automatic
configuration of the server side of the tunnel (i.e. the designated
Tunnel Server).
user to verify that previously downloaded scripts do not perform
illegal or dangerous operations once executed.

The communication protocol above described security issues could be elegantly overcome by
defining a new MIME (Multipurpose Internet Mail Extension) content-type
(e.g. application/tunnel) [4,5] to be used between by the TB and to deliver the
tunnel servers
is implementation dependent as well. It could parameters to the client. In this case, there must be a set of simple RSH
commands, SNMP, a specially designed ad-hoc protocol or something
else.

Finally dedicated
agent running on the Dynamic DNS Update protocol [4] should be used for
automatic DNS update (i.e. client to add or delete AAAA, A6 process this information and PTR records
from actually
set-up the DNS zone reserved for tunnel broker users) controlled by end-point on behalf of the
TB. A simple alternative would user. This is a very
attractive approach which is worth envisaging. In particular, the
definition of the new content-type might be for the TB to use a small set subject of RSH
commands a future
ad-hoc document.

Another possibility to dynamically update achieve the direct configuration of the client from the
TB could be the use of simple remote shell (RSH) commands issued by the
broker, the use of SNMP (Simple Network Management Protocol), the
development of a new ad-hoc protocol or the extension of DHCP to make
it suitable for the configuration of IPv6 over IPv4 tunnels on
dual-stack clients.

Several options are available also to achieve proper interaction
between the broker and the Tunnel Servers. For example a set of simple
RSH commands could be used for this purpose. Another alternative could
be to use SNMP or to adopt any other network management solution.

Finally, the Dynamic DNS Update protocol [6] 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 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 Use of the proposed architecture need to tunnel broker concept in other areas

The Tunnel Broker approach might be secured:

- the interaction between the client and TB;
- the interaction between the TB efficiently exploited also to
automatically set-up and manage any other kind of tunnel, such as a
multicast tunnel (e.g. used to interconnect multicast islands within
the Tunnel Server;
- the interaction between the TB and unicast Internet) or an IPsec tunnel.

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 7]

Internet Draft draft-ietf-ngtrans-broker-03.txt

Moreover, the DNS.

The security techniques adopted for each idea of deploying a dedicated access-control server,
like the required interactions
is dependent TB, to securely authorize and assist users that want to gain
access to an IPv6 network might prove useful also to enhance other
transition mechanisms. For example it would be possible to exploit
a similar approach within the 6to4 model to achieve easy relay
discovery. This would make life easier for early 6to4 adopters but
would also allow the ISPs to better control the usage of their 6to4
relay facilities (e.g. setting up appropriate usage policies).

5. Security Considerations

All the 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 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 widely adopted security features, such as SSL (Secure Socket Layer)
[7], to secure e-mail can be used (PGP, PEM). For the
interactions that use SNMP, encrypt data sent to and downloaded from the security issues are basically web server. This
also makes it possible to rely on a simple "username" and "password"
authentication procedure and on existing AAA facilities (e.g. RADIUS) to
enforce access-control.

For the same

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 6]

Internet Draft draft-ietf-ngtrans-broker-02.txt

as those of securing TB-TS interaction secure SNMP [5,6,7]. Otherwise if RSH commands are used
standard IPsec mechanisms may apply. could be adopted [8,9,10]. If the TB - DNS server
interaction is a
dynamic DNS update procedure, procedure is used for the TB-DNS interaction, the
security issues are the same as discussed in [8]. [11]. Otherwise, if a
simpler approach based on RSH commands is used, standard IPsec
mechanisms can be applied [12].

Furthermore, if the configuration of the client is achieved running
scripts provided by the TB, these scripts must be executed as root. with
administrator/root privileges. This can be dangerous and should
be considered only for early implementations of the Tunnel Broker
approach. Transferring tunnel configuration parameters in a MIME type
over https is a more secure approach.

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 keeps
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

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 8]

Internet Draft draft-ietf-ngtrans-broker-03.txt

Finally TBs must implement protections against denial of service
attacks which may occur whenever a malicious user finishes off exhausts all the
resources available on the tunnels 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 set-up at the same time.

6. Acknowledgments

Some of the ideas refining the tunnel broker model came from discussion
with Perry Metzger and Marc Blanchet.

7. References

[1] Gilligan, R., Nordmark, E., "Transition Mechanisms for IPv6 Hosts
and Routers", RFC 1933, April 1996.
[2] Carpenter, B., Jung, C., " Transmission "Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels", draft-ietf-ipngwg-6over4-02.txt,
January 1998. RFC 2529, March 1999.
[3] Carpenter, B., Moore, K., "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-02.txt,
June 1999. draft-ietf-ngtrans-6to4-05.txt,
work in progress, May 2000.
[4] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies, RFC 2045,
November 1996.
[5] Freed, N., Borenstein, N., "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, November 1996.
[6] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997.
[5]
[7] Guttman, E., Leong, L., Malkin, G., "Users' Security Handbook",
RFC 2504, February 1999.
[8] Wijnen, B., Harrington, D., Presuhn, R., "An Architecture for
Decribing SNMP Management Frameworks", RFC 2571, April 1999.
[6]
[9] Blumenthal, U., Wijnen, B., "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)",
RFC 2574, April 1999.
[7]
[10] Wijnen, B., Presuhn, R., McCloghrie, K., "View-based Access Control
Model (VACM) for the Simple Network Management Protocol (SNMP)",
RFC 2575, April 1999.

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 7]

Internet Draft draft-ietf-ngtrans-broker-02.txt

[8]
[11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137,
April 1997.

7.
[12] Kent, S., Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.

Durand Fasano Guardini Lento Expires January 4, 2000 [Page 9]

Internet Draft draft-ietf-ngtrans-broker-03.txt

8. Author's addresses

Alain Durand
IMAG
Direction des Moyens Informatiques
BP 53
38041 GRENOBLE CEDEX 9
France
SUN Microsystems, Inc
901 San Antonio Road
MPK17-202
Palo Alto, CA 94303-4900
USA
Tel: +33 4 76635703 +1 650 786 7503
Mail: Alain.Durand@imag.fr Alain.Durand@sun.com

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
TIM
Business Unit Project Management
via G. Reiss Romoli, 274
10148 TORINO Orsini, 9
90100 Palermo
Italy
Tel: +39 011 2286993 091 7583243
Mail: domenico.lento@cselt.it dlento@mail.tim.it

Durand Fasano Guardini Lento Expires 5 April January 4, 2000 [Page 8]

Internet Draft draft-ietf-ngtrans-broker-02.txt

Appendix
Implementation Example

This appendix describes an early implementation of the TB service
developed at CSELT, based on widely available communication tools. The
basic communications between the clients and the TB run over http. The
tunnel broker service interface is implemented through a WWW server
located on the TB. Using a standard WWW browser the user can access a
home page providing some general information on the service and two
hyperlinks: one for new users and another for already registered
users.

Each new user is required to fill a web form with some
identification data (Name, Company and e-mail address) and a nickname.
The nickname is used both as the username to login as registered user
and as the name identifying the user in the DNS database.

After having received all the necessary identification data, the user
configuration procedure takes place. After that, the TB sends back to
the user an e-mail specifying the username (it is just the nickname
previously chosen by the user himself) and the password to get access
to the web pages reserved to registered users.

A registered user can create a new tunnel, view the tunnel
information, change the tunnel parameters and remove an established
tunnel. In order to reduce the risk of denial of service attacks (see
section 4) only one active tunnel per user is allowed.

In order to create a new tunnel, the user has to provide some
additional information:

- the IPv4 address of the tunnel end-point on the user side (the TB
pre-fills this field using the browser information carried by http);
- the O.S./IPv6 implementation used on the client machine (the user
can choose only among a list of supported client architectures
displayed by the TB);
- the client function (i.e. standalone host or router).

If the user declares that the client machine will be a router
providing IPv6 connectivity for a whole site, a wide IPv6 addressing
space should be delegated to him instead of a single IPv6 address. In
this case, before going through the actual address delegation and
tunnel setup, the TB pushes a new form to the user asking for further
information:

- motivation for the router request;
- desired tunnel life-time.

Then the user submits this information to the TB and the tunnel
configuration procedure takes place.

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 9]

Internet Draft draft-ietf-ngtrans-broker-02.txt

A.1 User configuration procedure

When the TB receives a registration request from a new user, it
operates as follows:

- it uses the nickname provided by the user to build the name
that will identify the IPv6 addresses of both sides of the
tunnel in the DNS system;
- it updates an internal user database;
- it sends back to the user an e-mail specifying the username
and password to access the web area on the TB reserved to
registered users.

A.2 Tunnel creation procedure

When a registered user asks for the creation of a tunnel, the TB first
checks whether the user requested to terminate the tunnel on a router
or on a host. If the user choice was a router, the request is put in a
pending state and managed administratively: the administrator of the
TB has the possibility to accept or refuse the request based on the
motivation and lifetime indicated by the user. If the user choice was
a host the TB acts automatically according to the following algorithm:

i) verify if resources are available to setup a new tunnel.
If the answer is "yes" go on with step ii, otherwise go to
step viii;
ii) select a Tunnel Server from the list of available Tunnel
Servers based on a simple number-of-tunnels balancing
criteria;
iii) select the IPv6 prefix to be used for assigning IPv6
addresses to the tunnel end-points;
iv) set the Expiration Date for the tunnel (default is 7 days);
v) configure the Tunnel Server;
vi) update the DNS;
vii) prepare the activation and de-activation scripts for tunnel
configuration on the user side;
viii) push to the user browser a new web page displaying the results
of the tunnel request. If the tunnel creation procedure
terminated successfully this new page displays the tunnel
parameters and hyperlinks to the activation and de-activation
scripts.

The user who receives positive acknowledgment can then execute the
activation script to configure the user side of the tunnel. There is
still the possibility for a user that do not want to run the
configuration scripts or that has an IPv6 implementation not supported
by the TB to set up his end-point of the tunnel manually. At the end
of this procedure the user gets IPv6 connectivity together with a
valid name in the DNS.

A similar procedure is performed when the user selects a router as
tunnel end-point and the Administrator accepts the request.

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 10]

Internet Draft draft-ietf-ngtrans-broker-02.txt

A registered user who has already setup a tunnel can view a display of
the following tunnel parameters:

- Server IPv4 Address
- Server IPv6 Address
- Server IPv6 Link Local Address
- Client IPv4 Address
- Client IPv6 Address
- Client IPv6 Link Local Address
- Expiration Date

The user can also modify the Client IPv4 Address if this is changed,
can extend the tunnel life-time a day before the Expiration date and
can delete the tunnel anytime. The communication between the client
and the TB has been secured using SSL (access to the TB using the
https scheme).

A.3 User, Tunnel and Tunnel Server management

The TB maintains three databases, one for users, one for active
tunnels and the last one for Tunnel Servers. The User database has one
entry for each user of the service; each entry includes the following
fields:

- Username
- Password
- DNS entry
- Firstname
- Lastname
- Company
- Country
- e-mail
- Has Tunnel ("yes" if the user has an active tunnel)
- Tunnel Count (number of tunnel creation procedures
carried out by the user)

The Tunnel database has one entry for each active tunnel; each entry
includes the following fields:

- Identifier
- Owner
- User IPv4 Address
- Server IPv4 Address
- User Global IPv6 Address
- Server Global IPv6 Address
- User Link Local Address
- Server Link Local Address
- User OS Type
- Creation Date
- Expiration Date
- Standalone ("yes" if the tunnel is terminated on a standalone
host at the user side; "no" if the tunnel is terminated on an
IPv6 router)

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 11]

Internet Draft draft-ietf-ngtrans-broker-02.txt

- Manual ("yes" if the tunnel has been setup manually by the TB
administrator)

The Tunnel Server database has one entry for each Tunnel Server; each
entry has the following fields:

- Identifier
- IPv4 address
- IPv6 prefix (is the IPv6 prefix identifying the IPv6
addressing space dynamically administered by the TB to
number the tunnel end-points and the user sites)
- OS Type (is a keyword identifying the Operating System type
and the IPv6 implementation installed on the TS; the
administrator can choose only among a list of supported TS
architectures displayed by the TB)
- Used Standalone Tunnels (is the number of active standalone
tunnels on this TS)
- Max Standalone Tunnels (is the maximum number of active
standalone tunnels allowed on this TS)
- Used Router Tunnels (is the number of active router tunnels
on this TS)
- Max Router Tunnels (is the maximum number of active
router tunnels allowed on this TS)

The TB manages the service updating these databases. An Administrator
Interface gives to the TB manager a full control (add, modify and
remove any time) over users, tunnels and Tunnel Servers.

In order to get access to the administrative web pages, the TB
administrator has to log as Registered User using the administrative
username (root) and password. The page presented to the administrator
contains hyperlinks to the following sections:

- Administrator Profile Change
- User Administration
- Tunnel Server Administration
- Tunnel Administration

The Administrator Profile Change lets the administrator to change his
password.

The User Administration section allows the administrator to interact
with the User database in order to list the database content or delete
an entry in the database. If the administration deletes an entry with
an associated tunnel, the tunnel is released.

The Tunnel Server Administration section allows the administrator to
manage the data contained in the Tunnel Server database. The page
presented to the TB superuser contains hyperlinks to the following
subsections:

- Tunnel Server List (the content of the Tunnel Server database is
displayed with the relevant informations);

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 12]

Internet Draft draft-ietf-ngtrans-broker-02.txt

- Add Tunnel Server (for the insertion of a new Tunnel Server; the
administrator has to provide the relevant Tunnel Server
information as described in the previous section);
- Modify Tunnel Server (this subsection is used by the administrator
to change the configuration of a Tunnel Server, e.g. to increase
or reduce the maximum number of standalone tunnels allowed on
the TS);
- Delete Tunnel Server (to remove a TS from the Tunnel Server
database; the tunnels managed by this Tunnel Server are released).

The Tunnel Administration section is used to perform tunnel
management. The page presented to the administrator contains
hyperlinks to the following subsections:

- Tunnel List (the content of the Tunnel database is displayed);
- Manual Setup (allows the TB superuser to setup manually a tunnel);
- Release (allows the TB superuser to release an active tunnel);
- Change Parameters (to update the configuration of an active
tunnel);
- Pending Router Request (displays the list of the user requests
for a tunnel towards a router; two hyperlinks are associated to
each entry allowing the administrator to accept or refuse the
request).

A.4 Modularity

The Tunnel Broker implements a plugin-like mechanism for adding
support for new Tunnel Servers or client operating systems without
modifying the TB scripts or breaking the service. To achieve this
result the scripts has to follow a predefined template and are kept in
a plugin directory checked at every request for a new tunnel. This
implies that the lists of supported Tunnel Servers and client OSs are
built dynamically, based on the content of the plugin directory.

A.4.1 Script directory structure

The scripts for interacting with users, Tunnel Servers and DNS are
stored in a plugin directory structured as follows:

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 13]

Internet Draft draft-ietf-ngtrans-broker-02.txt

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 5 April 2000 [Page 14]

Internet Draft draft-ietf-ngtrans-broker-02.txt

de-activation.

A.4.2 Client scripts

The client scripts are used to help a TB user to configure his own
host. In order to support a new client architecture, the TB
administrator has to provide both activation and de-activation scripts
for that architecture. The names of these scripts must be chosen
according to the following convention:

- the activation and de-activation scripts must have the same name
but has to be placed in the directories
<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 5 April 2000 [Page 15]

Internet Draft draft-ietf-ngtrans-broker-02.txt

- the activation and de-activation scripts must have the
same name but has to be placed in the directories
<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 5 April 2000 [Page 16]

Internet Draft draft-ietf-ngtrans-broker-02.txt

A.5 CSELT's Tunnel Broker location

The TB service is up and running at:
https://carmen.cselt.it/ipv6tb

The software implementing the tunnel broker service is freely
available at:
http://carmen.cselt.it/ipv6/download

Durand Fasano Guardini Lento Expires 5 April 2000 [Page 17] 10]
----