rfc3053.txt

最新的RFC

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
         6to4 relays, 6to4 sites can also reach sites on the IPv6
         Internet.





Durand, et al.               Informational                      [Page 2]

RFC 3053                   IPv6 Tunnel Broker               January 2001


   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.

   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 3 reports
   known limitations to the model; Section 4 briefly outlines other
   possible applications of the Tunnel Broker approach; Section 5
   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
   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.

























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-point
                  ||                           /\
                  ||                           ||
                  |+---------------------------+|
                  +-----------------------------+
                       IPv6 over IPv4 tunnel

                 Figure 1: the Tunnel Broker model

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

   A 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
   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 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 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 name to be used for the registration in the DNS of the global
         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 provide
   connectivity to several IPv6 hosts, the client should be asked also
   to provide some information about the amount of IPv6 addresses
   required.  This allows the TB to allocate the client an IPv6 prefix
   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 sharing
         criteria defined by the TB administrator) a Tunnel Server to be
         used as the actual tunnel end-point at the network side;

      -  it chooses the IPv6 prefix to be allocated to the client; the
         prefix length can be anything between 0 and 128, most common
         values being 48 (site prefix), 64 (subnet prefix) or 128 (host
         prefix);

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





Durand, et al.               Informational                      [Page 5]

RFC 3053                   IPv6 Tunnel Broker               January 2001


      -  it notifies the relevant configuration information to the
         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 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 each tunnel must be
   global IPv6 addresses belonging to the IPv6 addressing space managed
   by the TB.

   The lifetime of 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 a newly
   established tunnel is likely to be used just for a short time and
   then never again, in that every time the user reconnects he gets a
   new IPv4 address and is therefore obliged either to set-up a new
   tunnel or to update the configuration of the previous one.  In such a
   situation a more effective tunnel management may 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
   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).





Durand, et al.               Informational                      [Page 6]

RFC 3053                   IPv6 Tunnel Broker               January 2001


   Another solution 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 also requires a software
   upgrade on the client machine in order to add support for the ad-hoc
   keep-alive mechanism described above.

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