IPv6 Tunnel Broker
RFC 3053
|
| Document |
Type |
|
RFC - Informational
(January 2001; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3053 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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 [Page 1]
RFC 3053 IPv6 Tunnel Broker January 2001
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:
- the use of automatic tunnels with IPv4 compatible addresses [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 5;
- 6over4 [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;
- 6to4 [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.
The Tunnel Broker idea is an alternative approach based on the
provision of dedicated servers, called Tunnel 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 mechanisms
is that the they serve a different segment of the IPv6 community:
- the Tunnel Broker fits well for small isolated IPv6 sites, and
especially isolated IPv6 hosts on the IPv4 Internet, that want
to easily connect to an existing IPv6 network;
- the 6to4 approach has been designed to allow isolated IPv6
sites to 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
Show full document text