As per Relevance of the word approach, we have this rfc below:
Network Working Group A.
Request for Comments: 3053 SUN Microsystems,
Category: Informational P.
I.
CSELT S.p.A
D.
January 2001
IPv6 Tunnel
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
The IPv6 global Internet as of today uses a lot of tunnels over
existing IPv4 infrastructure. Those tunnels are difficult
configure and maintain in a large scale environment. The 6bone
proven that large sites and Internet Service Providers (ISPs) can
it, but this process is too complex for the isolated end user
already has an IPv4 connection and would like to enter the IPv
world. The motivation for the development of the tunnel broker
is to help early IPv6 adopters to hook up to an existing IPv6
(e.g., the 6bone) and to get stable, permanent IPv6 addresses and
names. The concept of the tunnel broker was first presented
Orlando's IETF in December 1998. Two implementations
demonstrated during the Grenoble IPng & NGtrans interim meeting
February 1999.
1.
The growth of IPv6 networks started mainly using the
facilities offered by the current Internet. This led to
development of several techniques to manage IPv6 over IPv4 tunnels
At present most of the 6bone network is built using
configured tunnels over the Internet. The main drawback of
approach is the overwhelming management load for
administrators, who have to perform extensive manual
for each tunnel. Several attempts to reduce this management
Durand, et al. Informational [Page 1]
RFC 3053 IPv6 Tunnel Broker January 2001
have already been proposed and each of them presents
advantages but also solves different problems than the Tunnel Broker
or poses drawbacks not present in the Tunnel Broker
- the use of automatic tunnels with IPv4 compatible addresses [1]
is a simple mechanism to establish early IPv6
among isolated dual-stack hosts and/or routers. The
with this approach is that it does not solve the
exhaustion problem of IPv4. Also there is a great fear
include the complete IPv4 routing table into the IPv6
because this would worsen the routing table size
multiplying it by 5;
- 6over4 [2] is a site local transition mechanism based on
use of IPv4 multicast as a virtual link layer. It does
solve the problem of connecting an isolated user to the
IPv6 Internet
- 6to4 [3] has been designed to allow isolated IPv6 domains
attached to a wide area network with no native IPv6
(e.g., the IPv4 Internet), to communicate with other such IPv
domains with minimal manual configuration. The idea is
embed IPv4 tunnel addresses into the IPv6 prefixes so that
domain border router can automatically discover
endpoints for outbound IPv6 traffic
The Tunnel Broker idea is an alternative approach based on
provision of dedicated servers, called Tunnel Brokers,
automatically manage tunnel requests coming from the users.
approach is expected to be useful to stimulate the growth of IPv
interconnected hosts and to allow early IPv6 network providers
provide easy access to their IPv6 networks
The main difference between the Tunnel Broker and the 6to4
is that the they serve a different segment of the IPv6 community
- the Tunnel Broker fits well for small isolated IPv6 sites,
especially isolated IPv6 hosts on the IPv4 Internet, that
to easily connect to an existing IPv6 network
- the 6to4 approach has been designed to allow isolated IPv
sites to easily connect together without having to wait
their IPv4 ISPs to deliver native IPv6 services. This is
well suited for extranet and virtual private networks.
6to4 relays, 6to4 sites can also reach sites on the IPv
Internet
Durand, et al. Informational [Page 2]
RFC 3053 IPv6 Tunnel Broker January 2001
In addition, the Tunnel Broker approach allows IPv6 ISPs to
perform access control on the users enforcing their own policies
network resources utilization
This document is intended to present a framework describing
guidelines for the provision of a Tunnel Broker service within
Internet. It does not specify any protocol but details the
architecture of the proposed approach. It also outlines a set
viable alternatives for implementing it. Section 2 provides
overall description of the Tunnel Broker model; Section 3
known limitations to the model; Section 4 briefly outlines
possible applications of the Tunnel Broker approach; Section 5
addresses security issues
2. Tunnel Broker
Tunnel brokers can be seen as virtual IPv6 ISPs, providing IPv
connectivity to users already connected to the IPv4 Internet. In
emerging IPv6 Internet it is expected that many tunnel brokers
be available so that the user will just have to pick one. The
of the tunnel brokers should be referenced on a "well known" web
(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
depicted in figure 1.
Durand, et al. Informational [Page 3]
RFC 3053 IPv6 Tunnel Broker January 2001
+------+
/|tunnel
/ |server
/ | |
/ +------+
+----------+ +------+/ +------+
|dual-stack| |tunnel| |tunnel
| node |<--->|broker|<--->|server
| (user) | | | | |
+----------+ +------+\ +------+
| \ +------+
tunnel end-point v \ |tunnel
/\ +---+ \ |server
|| |DNS| \| |
|| +---+ +------+
||
|| tunnel end-
|| /\
|| ||
|+---------------------------+|
+-----------------------------+
IPv6 over IPv4
Figure 1: the Tunnel Broker
2.1 Tunnel Broker (TB
The TB is the place where the user connects to register and
tunnels. The TB manages tunnel creation, modification and
on behalf of the user
For scalability reasons the tunnel broker can share the load
network side tunnel end-points among several tunnel servers.
sends configuration orders to the relevant tunnel server whenever
tunnel has to be created, modified or deleted. The TB may
register the user IPv6 address and name in the DNS
A TB must be IPv4 addressable. It may also be IPv6 addressable,
this is not mandatory. Communications between the broker and
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
Internet. Upon receipt of a configuration order coming from the TB
it creates, modifies or deletes the server side of each tunnel.
may also maintain usage statistics for every active tunnel
Durand, et al. Informational [Page 4]
RFC 3053 IPv6 Tunnel Broker January 2001
2.3 Using the Tunnel
The client of the Tunnel Broker service is a dual-stack IPv6
(host or router) connected to the IPv4 Internet. Approaching the TB
the client should be asked first of all to provide its identity
credentials so that proper user authentication, authorization
(optionally) accounting can be carried out (e.g., relying on
AAA facilities such as RADIUS). This means that the client and
TB have to share a pre-configured or automatically
security association to be used to prevent unauthorized use of
service. With this respect the TB can be seen as an access-
server for IPv4 interconnected IPv6 users
Once the client has been authorized to access the service, it
provide at least the following information
- the IPv4 address of the client side of the tunnel
- a name to be used for the registration in the DNS of the
IPv6 address assigned to the client side of the tunnel
- the client function (i.e., standalone host or router).
Moreover, if the client machine is an IPv6 router willing to
connectivity to several IPv6 hosts, the client should be asked
to provide some information about the amount of IPv6
required. This allows the TB to allocate the client an IPv6
that fits its needs instead of a single IPv6 address
The TB manages the client requests as follows
- it first designates (e.g., according to some load
criteria defined by the TB administrator) a Tunnel Server to
used as the actual tunnel end-point at the network side
- it chooses the IPv6 prefix to be allocated to the client;
prefix length can be anything between 0 and 128, most
values being 48 (site prefix), 64 (subnet prefix) or 128 (
prefix);
- it fixes a lifetime for the tunnel
- it automatically registers in the DNS the global IPv6
assigned to the tunnel end-points
- it configures the server side of the tunnel
Durand, et al. Informational [Page 5]
RFC 3053 IPv6 Tunnel Broker January 2001
- it notifies the relevant configuration information to
client, including tunnel parameters and DNS names
After the above configuration steps have been carried out (
the configuration of the client), the IPv6 over IPv4 tunnel
the client host/router and the selected TS is up and working,
allowing the tunnel broker user to get access to the 6bone or
other IPv6 network the TS is connected to
2.4 IPv6 address
The IPv6 addresses assigned to both sides of each tunnel must
global IPv6 addresses belonging to the IPv6 addressing space
by the TB
The lifetime of these IPv6 addresses should be relatively long
potentially longer than the lifetime of the IPv4 connection of
user. This is to allow the client to get semipermanent IPv
addresses and associated DNS names even though it is connected to
Internet via a dial-up link and gets dynamically assigned IPv
addresses through DHCP
2.5 Tunnel
Active tunnels consume precious resources on the tunnel servers
terms of memory and processing time. For this reason it is
to keep the number of unused tunnels as small as possible deploying
well designed tunnel management mechanism
Each IPv6 over IPv4 tunnel created by the TB should at least
assigned a lifetime and removed after its expiration unless
explicit lifetime extension request is submitted by the client
Obviously this is not an optimal solution especially for
accessing the Internet through short-lived and dynamically
IPv4 connections (e.g., dial-up links). In this case a
established tunnel is likely to be used just for a short time
then never again, in that every time the user reconnects he gets
new IPv4 address and is therefore obliged either to set-up a
tunnel or to update the configuration of the previous one. In such
situation a more effective tunnel management may be achieved
having the TS periodically deliver to the TB IPv6 traffic
reachability statistics for every active tunnel. In this way, the
can enforce a tunnel deletion after a period of inactivity
waiting for the expiration of the related lifetime which can
relatively longer (e.g., several days).
Durand, et al. Informational [Page 6]
RFC 3053 IPv6 Tunnel Broker January 2001
Another solution may be to implement some kind of tunnel
protocol or keep-alive mechanism between the client and the TS (
between the client and the TB) so that each tunnel can be
released after the user disconnects (e.g., removing his tunnel end
point or tearing down his IPv4 connection to the Internet).
drawback of this policy mechanism is that it also requires a
upgrade on the client machine in order to add support for the ad-
keep-alive mechanism described above
Moreover, keeping track of the tunnel configuration even after
user has disconnected from the IPv4 Internet may be worth the
cost. In this way, in fact, when the user reconnects to
Internet, possibly using a different IPv4 address, he could
restart the tunnel by getting in touch with the TB again. The
could then order a TS to re-create the tunnel using the new IPv
address of the client but reusing the previously allocated IPv
addresses. That way, the client could preserve a nearly
(static) IPv6 address even though its IPv4 address is dynamic.
could also preserve the associated DNS name
2.6 Interactions between client, TB, TS and
As previously stated, the definition of a specific set of
and procedures to be used for the communication among the
entities in the Tunnel Broker architecture is outside of the scope
the present framework document. Nevertheless, in the reminder
this section some viable technical alternatives to support client-TB
TB-TS and TB-DNS interactions are briefly described in order to
future implementation efforts or standardization initiatives
The interaction between the TB and the user could be based on http
For example the user could provide the relevant
information (i.e., the IPv4 address of the client side of the tunnel
etc.) by just filling up some forms on a Web server running on
TB. As a result the server could respond with an html page
that the server end-point of the tunnel is configured and
all the relevant tunnel information
After that, the most trivial approach would be to leave the user
configure the client end-point of the tunnel on his own. However,
should be highly valuable to support a mechanism to automate
procedure as much as possible
Several options may be envisaged to assist the Tunnel Broker user
the configuration of his dual-stack equipment. The simplest
is that the TB could just prepare personalized activation and de
activation scripts to be run off-line on the client machine
achieve easy set-up of the client side tunnel end-point.
Durand, et al. Informational [Page 7]
RFC 3053 IPv6 Tunnel Broker January 2001
solution is clearly the easiest to implement and operate in that
does not require any software extension on the client machine
However, it raises several security concerns because it may
difficult for the user to verify that previously downloaded
do not perform illegal or dangerous operations once executed
The above described security issues could be elegantly overcome
defining a new MIME (Multipurpose Internet Mail Extension) content
type (e.g., application/tunnel) [4,5] to be used by the TB to
the tunnel parameters to the client. In this case, there must be
dedicated agent running on the client to process this information
actually set-up the tunnel end-point on behalf of the user. This
a very attractive approach which is worth envisaging. In particular
the definition of the new content-type might be the subject of
future ad-hoc document
Several options are available also to achieve proper
between the broker and the Tunnel Servers. For example a set
simple RSH commands over IPsec could be used for this purpose
Another alternative could be to use SNMP or to adopt any
network management solution
Finally, the Dynamic DNS Update protocol [6] should be used
automatic DNS update (i.e., to add or delete AAAA, A6 and PTR
from the DNS zone reserved for Tunnel Broker users) controlled by
TB. A simple alternative would be for the TB to use a small set
RSH commands to dynamically update the direct and inverse
on the authoritative DNS server for the Tunnel Broker users
(e.g. broker.isp-name.com).
2.7 Open
Real usage of the TB service may require the introduction
accounting/billing functions
3. Known
This mechanism may not work if the user is using private IPv
addresses behind a NAT box
4. Use of the tunnel broker concept in other
The Tunnel Broker approach might be efficiently exploited also
automatically set-up and manage any other kind of tunnel, such as
multicast tunnel (e.g., used to interconnect multicast islands
the unicast Internet) or an IPsec tunnel
Durand, et al. Informational [Page 8]
RFC 3053 IPv6 Tunnel Broker January 2001
Moreover, the idea of deploying a dedicated access-control server
like the TB, to securely authorize and assist users that want to
access to an IPv6 network might prove useful also to enhance
transition mechanisms. For example it would be possible to exploit
similar approach within the 6to4 model to achieve easy
discovery. This would make life easier for early 6to4 adopters
would also allow the ISPs to better control the usage of their 6to
relay facilities (e.g., setting up appropriate usage policies).
5. Security
All the interactions between the functional elements of the
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
is dependent on the implementation choices
For the client-TB interaction, the usage of http allows
exploitation of widely adopted security features, such as SSL (
Socket Layer) [7], to encrypt data sent to and downloaded from
web server. This also makes it possible to rely on a
"username" and "password" authentication procedure and on
AAA facilities (e.g., RADIUS) to enforce access-control
For the TB-TS interaction secure SNMP could be adopted [8,9,10].
the dynamic DNS update procedure is used for the TB-DNS interaction
the security issues are the same as discussed in [11]. Otherwise,
a simpler approach based on RSH commands is used, standard
mechanisms can be applied [12].
Furthermore, if the configuration of the client is achieved
scripts provided by the TB, these scripts must be executed
enough privileges to manage network interfaces, such as
administrator/root role. This can be dangerous and should
considered only for early implementations of the Tunnel
approach. Transferring tunnel configuration parameters in a
type over https is a more secure approach
In addition a loss of confidentiality may occur whenever a dial-
user disconnects from the Internet without tearing down the
previously established through the TB. In fact, the TS
tunneling the IPv6 traffic addressed to that user to his old IPv
Durand, et al. Informational [Page 9]
RFC 3053 IPv6 Tunnel Broker January 2001
address regardless of the fact that in the meanwhile that IPv
address could have been dynamically assigned to another subscriber
the same dial-up ISP. This problem could be solved by
on every tunnel the keep-alive mechanism outlined in section 2.5
allowing the TB to immediately stop IPv6 traffic forwarding
disconnected users
Finally TBs must implement protections against denial of
attacks which may occur whenever a malicious user exhausts all
resources available on the tunnels server by asking for a lot
tunnels to be established altogether. A possible protection
this attack could be achieved by administratively limiting the
of tunnels that a single user is allowed to set-up at the same time
6.
Some of the ideas refining the tunnel broker model came
discussion with Perry Metzger and Marc Blanchet
7.
[1] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv
Hosts and Routers", RFC 1933, April 1996.
[2] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv
Domains without Explicit Tunnels", RFC 2529, March 1999.
[3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv
Clouds without Explicit Tunnels", Work in Progress
[4] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet Message Bodies
RFC 2045, November 1996.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
1996.
[6] Vixie, P., Editor, Thomson, T., Rekhter, Y. and J. Bound
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
2136, April 1997.
[7] Guttman, E., Leong, L. and G. Malkin, "Users'
Handbook", FYI 34, RFC 2504, February 1999.
[8] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture
Describing SNMP Management Frameworks", RFC 2571, April 1999.
Durand, et al. Informational [Page 10]
RFC 3053 IPv6 Tunnel Broker January 2001
[9] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM
for version 3 of the Simple Network Management
(SNMPv3)", RFC 2574, April 1999.
[10] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Control Model (VACM) for the Simple Network Management
(SNMP)", RFC 2575, April 1999.
[11] Eastlake, D., "Secure Domain Name System Dynamic Update",
2137, April 1997.
[12] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
Durand, et al. Informational [Page 11]
RFC 3053 IPv6 Tunnel Broker January 2001
8. Authors'
Alain
SUN Microsystems,
901 San Antonio
MPK17-202
Palo Alto, CA 94303-4900
Phone: +1 650 786 7503
EMail: Alain.Durand@sun.
Paolo Fasano S.p.A
CSELT S.p.A
Switching and Network Services -
via G. Reiss Romoli, 274
10148
Phone: +39 011 2285071
EMail: paolo.fasano@cselt.
Ivano
CSELT S.p.A
Switching and Network Services -
via G. Reiss Romoli, 274
10148
Phone: +39 011 2285424
EMail: ivano.guardini@cselt.
Domenico
Business Unit Project
via Orsini, 9
90100
Phone: +39 091 7583243
EMail: dlento@mail.tim.
Durand, et al. Informational [Page 12]
RFC 3053 IPv6 Tunnel Broker January 2001
9. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Durand, et al. Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
