RFC 3053 (rfc3053) - Page 1 of 13
IPv6 Tunnel Broker
Alternative Format: Original Text Document
Network Working Group A. Durand
Request for Comments: 3053 SUN Microsystems, Inc
Category: Informational P. Fasano
I. Guardini
CSELT S.p.A.
D. Lento
TIM
January 2001
IPv6 Tunnel Broker
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
The IPv6 global Internet as of today uses a lot of 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 Internet Service Providers (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) 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 in
February 1999.
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
Durand, et al. Informational