この文書はRFC3053の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。

※pngイメージが1つ入ってるので、コピーする際は忘れずに


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
                      IPv6トンネルブローカー


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.
   IPv6グローバルインターネットは今日の時点で既存のIPv4インフラ
   上で多くのトンネルを使います。これらのトンネルは大規模な環境で設定し
   て維持するのは困難です。6boneは大きいサイトとインターネット・サー
   ビスプロバイダがそれを出来ることを証明しましたが、このプロセスはすで
   にIPv4接続を持っていてIPv6世界に入りたい孤立しているエンドユー
   ザにはあまりにも複雑です。トンネルブローカーモデルの開発の動機づけは、
   初期のIPv6採用者が既存のIPv6ネットワーク(例えば、6bone)
   に接続して、安定した、永住のIPv6アドレスとDNS名を得るのを手伝
   うためです。トンネルのブローカーの概念は1998年12月にオーランド
   のIETFにおいて最初に提出されました。2つの実装が1999年2月の
   グルノーブルIPng&NGtrans仮会合の間に実演されました。

1. Introduction
1. はじめに

   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:
   IPv6ネットワークは主に、現在のインターネットによって提供された転
   送機能を使い始めることで、成長しました。これはIPv4トンネル上にI
   Pv6を管理するいくつかの技術の開発に導きました。目下6boneネッ
   トワークの大部分がインターネット上に手作業で設定されたトンネルを使っ
   て構築されます。このアプローチの主な欠点は各トンネルのために大規模な
   手動の設定を行わなければならないネットワーク管理者のために圧倒的な管
   理負荷です。この管理負荷を減らすいくつかの試みがすでに提案され、そし
   てそれらのそれぞれが面白い利点を引き起こしますが、トンネルブローカー
   とは異なった問題を解くか、あるいはトンネルのブローカーで存在しない欠
   点を提出します:

      -  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;
      -  IPv4コンパチブルアドレス[1]を使う自動的なトンネルの使用は
         孤立しているデュアルスタックホストやルーターの間で初期のIPv
         6接続性を確立するための単純なメカニズムです。このアプローチに
         おける問題は、これがIPv4のアドレス極度の枯渇問題を解かない
         ということです。同じくこれがIPv4ルーティングテーブルをIP
         v6に入れ、ルーティングテーブルサイズを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;
      -  6over4[2]が仮想リンクレイヤとしてIPv4マルチキャストを使
         用する事に基づくサイト移行メカニズムです。それはグローバルなI
         Pv6インターネットに孤立ユーザーを結ぶことの問題を解きません;

      -  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.
      -  6to4[3]がネイティブのIPv6サポートがない広域ネットワーク
         (例えば、IPv4インターネット)に置かれた孤立しているIPv
         6ドメインを許し、最小の手動の設定で他のIPv6ドメインと通信
         できるよう意図されました。アイデアは、ドメイン境界ルータが外行
         きのIPv6トラフィックのために自動的にトンネル終端を発見する
         ことができるように、IPv6プレフィックスの中にIPv4トンネ
         ルアドレスを埋め込む事です。

   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.
   トンネルブローカの考えはトンネルブローカと呼ばれる専用のサーバーの準
   備に基づいて、自動的にユーザーから来るトンネル要求を管理する代わりの
   アプローチです。このアプローチはIPv6相互接続ホストの成長を促進し
   て、初期のIPv6ネットワークプロバイダにそれらのIPv6ネットワー
   クに容易なアクセスを供給することを許すために実用的であることが期待さ
   れます。

   The main difference between the Tunnel Broker and the 6to4 mechanisms
   is that the they serve a different segment of the IPv6 community:
   トンネルブローカと6to4メカニズムの間の主な相違は、それぞれがIPv
   6共同体の異なった部分を果たす事です:。

      -  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;
      -  トンネルブローカは小さく孤立しているIPv6サイトと、特にIP
         v4インターネット上で孤立しているIPv6ホストで、容易に既存
         のIPv6ネットワークに接続したいホストに、適用します;

      -  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.
      -  6to4アプローチは孤立しているIPv6サイトに、IPv4のIS
         PがネイティブIPv6サービスを提供するのを待たずに、容易に接
         続を許すよう意図されました。これはエクストラネットと仮想プライ
         ベートネットワークに大変上手に適しています。6to4リレーを使っ
         て、6to4サイトがIPv6インターネット上のサイトに接続できま
         す。

   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.
   加えるに、トンネルブローカアプローチは、ネットワークリソースの使用に
   ポリシーを適用するIPv6のISPに、容易にユーザーのアクセス制御を
   行うことを許します。

   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章がトンネルブローカモデルの全体的な記述を供給します;
   3章が既知のモデル限界を報告します、4章が手短かにトンネルブローカ
   アプローチの他の可能な応用を概説します、5章がセキュリティ問題を扱
   います。

2. Tunnel Broker Model
2. トンネルブローカモデル

   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.
   トンネルのブローカーが、IPv4インターネットに接続てIPv6接続性
   を供給する、仮想のIPv6のISPの様に見えます。発生しているIPv
   6インターネットで、多くのトンネルのブローカーが利用可能と思われます
   が、ユーザーがちょうど1つを選ばなければなりません。トンネルブローカー
   のリストは、ユーザに「最も近い」か「最も安い」ものを選択できるように、
   「既知」Webページ上で参照されるべきです(例えばhttp://www.ipv6.org)。

   The tunnel broker model is based on the set of functional elements
   depicted in figure 1.
   トンネルブローカモデルは図1で描写される機能的な要素のセットに基づい
   ています。


                 Figure 1: the Tunnel Broker model
                   図1:トンネルブローカモデル

2.1 Tunnel Broker (TB)
2.1 トンネルブローカ(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.
   TBはユーザーがトンネルを登録し活性化するために接続する所です。TB
   はユーザーのためにトンネル作成と修正と削除を管理します。

   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.
   スケーラビリティのためにトンネルブローカはいくつかのトンネルサーバー
   によってネットワーク側のトンネル終端の付加を分散できます。これは、ト
   ンネルを作ったり、修正したり、削除する時に、適切なトンネルサーバーに
   設定命令を送ります。TBはDNSにユーザーIPv6アドレスと名前を登
   録するかもしれません。

   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.
   TBはIPv4でアドレスを扱えなければなりません。これはIPv6アド
   レスも扱えるでしょうが、これは必須ではありません。ブローカーとサーバー
   の間の通信はIPv4でもIPv6でもできます。

2.2 Tunnel server (TS)
2.2 Tunnel サーバー(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.
   TSはグローバルインターネットに接続したデュアルスタック(IPv4
   &IPv6)ルーターです。TBから来ている設定命令の受信により、こ
   れは各トンネルのサーバー側を作り、修正し、削除します。これはすべて
   のアクティブなトンネルのために利用統計値を持続するかもしれません。

2.3 Using the Tunnel Broker
2.3 トンネルブローカの利用

   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.
   トンネルブローカサービスのクライアントはIPv4インターネットと接続
   されるデュアルスタックIPv6ノード(ホストあるいはルーター)です。
   TBの接する際に、適切なユーザー認証と認可と(オプションで)課金を実
   行するために、クライアントはIDと資格をまず第一に尋ねられるべきです
   (例えば、ラディウスのような既存のAAAファシリティを利用します)。
   これはサービスの無許可の使用を妨げるためにクライアントとTBが事前設
   定か自動設定でにセキュリティアソシエーションを共有しなければならない
   ことを意味します。この点でTBは、IPv6ユーザを接続するIPv4の
   アクセス制御サーバーと見られることができます。

   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;
      -  トンネルのクライアント側のIPv4アドレス;

      -  a name to be used for the registration in the DNS of the global
         IPv6 address assigned to the client side of the tunnel;
      -  トンネルのクライアント側に割り当てたグローバルなIPv6アドレ
         スのDNS登録に使われるべき名前;

      -  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.
   さらに、もしクライアントマシンがいくつかのIPv6ホストに接続性を供
   給するIPv6ルーターであるなら、クライアントは同じく必要とされるI
   Pv6アドレスの量についての情報も供給するように頼まれるべきです。こ
   れはTBにクライアントに1つのIPv6アドレスでなく、代わりに必要に
   適したIPv6プレフィックスを割り当てることを許します。

   The TB manages the client requests as follows:
   TBは次のようにクライアント要求を管理します:

      -  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;
      -  最初にネットワーク側において実際のトンネル終端として用いられる
         トンネルサーバを指定します(例えば、基準がTB管理者の定義した
         負荷分散基準によります);

      -  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);
      -  クライアントに充てられるIPv6プレフィックスを選択します;プ
         レフィックス長さは0から128の間に何でもあり得ますが、たいて
         いの常識値が48(サイトプレフィックス)か64(サブネットプレ
         フィックス)か128(ホストプレフィックス)です。

      -  it fixes a lifetime for the tunnel;
      -  トンネルの寿命を固定します;

      -  it automatically registers in the DNS the global IPv6 addresses
         assigned to the tunnel end-points;
      -  自動的にトンネル終端に割り当てられたグローバルなIPv6アドレ
         スをDNSに登録します;

      -  it configures the server side of the tunnel;
      -  トンネルのサーバー側を設定します;

      -  it notifies the relevant configuration information to the
         client, including tunnel parameters and DNS names.
      -  クライアントに、トンネルパラメータとDNS名を含む適切な
         設定情報を知らせます。

   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.
   (クライアントの設定を含めて)上記の設定ステップが実行された後、クラ
   イアントホスト/ルーターと選択されたTSの間のIPv4トンネル上のI
   Pv6は起動し、動作し、トンネルブローカユーザーにTSと接続した6b
   oneや他のIPv6ネットワークにアクセスを許します。

2.4 IPv6 address assignment
2.4 IPv6アドレス割当て

   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.
   トンネルの両側に割り当てられたIPv6アドレスはTBによって管理され
   たIPv6アドレス空間に属するグローバルIPv6アドレスであるに違い
   ありません。

   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.
   これらのIPv6アドレスの寿命は比較的長くて、潜在的にユーザーのIP
   v4接続の寿命より長くあるべきです。これは、たとえダイアルアップリン
   クでインターネットに接続しDHCPで動的に割り当てられたIPv4アド
   レスを得てるとしてもるけれども、クライアントに半永久的IPv6アドレ
   スと関連したDNS名を得ることを可能にします。

2.5 Tunnel management
2.5 トンネル管理

   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.
   TBの作った各IPv4上のIPv6トンネルは少なくとも寿命を割り当て
   られて、クライアントが明白な寿命延長要請を出さないなら、期限後にトン
   ネルを削除するべきです。

   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).
   明らかにこれはユーザーが短命の動的に扱われたIPv4接続を通してイン
   ターネットにアクセスすることに関して特に最適な解決ではありません(例
   えば、ダイアルアップリンク)。この場合新たに確立されたトンネルが短期
   間だけ使われ再度使われる事がなく、ユーザーが再び接続する時に新しいI
   Pv4アドレスを得て、従って新しいトンネルか更新した設定が使われるで
   しょう。このような状況で、TSがすべてのアクティブなトンネルのためにI
   Pv6トラフィックと到達可能性統計値をTBに周期的に送ることで、より効
   果的なトンネル管理が成し遂げられるかもしれません。このようにして、T
   Bは比較的長い寿命が切れるのを待たずに不活性なトンネル削除を強制する
   ことができます(例えば、数日)。

   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.
   他の解決方法は、各トンネルがユーザーが接続を断った後(例えば、トン
   ネル終端点を削除する、インターネットのIPv4接続を停止する)すぐ
   に解放されるように、クライアントとTS間に(あるいはクライアントとT
   B間に)何らかの種類のトンネル管理プロトコルあるいは生存確認機構を
   実装することかもしれません。この保障機構の欠点は上記のアドホックな
   生存確認機構に対するサポートを加えるため、クライアントマシン上のソ
   フトウェアアップグレードを必要とするということです。

   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.
   さらに、ユーザーがIPv4インターネットとの接続を停止した後に、ト
   ンネル設定を記録・追跡することは余分のコストをもたらすかもしれませ
   ん。このようにして、実際、ユーザーが多分異なったIPv4アドレスで
   インターネット接続を再開した際に、彼が再びTBと連絡を取ってトンネ
   ルを再開できます。TBはクライアントの前に割り当てられたIPv6ア
   ドレスを再利用して、新しいIPv4アドレスを使ってトンネルを再現す
   るためにTSに命令します。そのように、クライアントは、IPv4アド
   レスがダイナミックであるが、ほとんど永久の(静的)IPv6アドレス
   を維持することができます。これは同じく関連づけられたDNS名を維持
   できます。

2.6 Interactions between client, TB, TS and DNS
2.6 クライアントとTBとTSと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 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.
   前に述べた通り、トンネルブローカアーキテクチャで様々なエンティティー
   間で通信に使われるプロトコルと手順の特定のセットの定義は現在のフレー
   ムワーク文書の範囲の外です。にもかかわらず、この章でクライアント-TB
   とTB-TSとTB−DNSの対話をサポートする実装可能な技術的方法が将
   来の実装努力あるいは標準化案提出に手を貸すために手短かに記述されます。

   The 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 forms on a Web server running on the
   TB.  As a result the server could respond with an html page stating
   that the server end-point of the tunnel is configured and displaying
   all the relevant tunnel information.
   TBとユーザー間の相互作用はhttpに基づき得ます。例えばユーザーはTB
   上で動作するWebサーバ上のフォームを満たすことで適切な設定情報(すなわ
   ち、トンネルのクライアント側のIPv4アドレスなど)を供給できます。
   サーバーが返答としてトンネルのサーバー終端点の構成が設定され、すべて
   の適切なトンネル情報を示すページをハイパーテキスト化し返送します。

   After that, the most trivial approach would be to leave the user to
   configure the client end-point of the tunnel on his own.  However, it
   should be highly valuable to support a mechanism to automate this
   procedure as much as possible.
   その後に、最もつまらない方法はユーザーが自分でトンネルのクライアント
   終端点を設定することでしょう。しかしながら、可能な限り手順を自動化す
   るメカニズムをサポートすることは極めてこの価値があります。

   Several options may be envisaged to assist the Tunnel Broker user in
   the configuration of his dual-stack equipment.  The simplest option
   is that the TB could just prepare personalized activation and de-
   activation scripts to be run off-line on the client machine to
   achieve easy set-up of the client side tunnel end-point.  This
   solution is clearly the easiest to implement and operate in that it
   does not require any software extension on the client machine.
   However, it raises several security concerns because it may be
   difficult for the user to verify that previously downloaded scripts
   do not perform illegal or dangerous operations once executed.
   トンネルブローカユーザーのデュアルスタック装置の設定をサポートするた
   めのいくつかのオプションが想像されるかもしれません。最も単純なオプショ
   ンは、クライアントマシン上でオフラインで動作し、TBがクライアント側
   のトンネル終端の容易な設定や停止をするための、クライアント固有のスク
   リプトを準備する事です。この解決は明らかにクライアントマシン上のソフ
   トウェア拡張を必要としないという点で、実行と操作が容易です。しかしな
   がら、これはユーザーが前にダウンロードされたスクリプトが誤って実行さ
   れたり、危険な操作が行わないことを確かめることは難しいかもしれないか
   ら、いくつかのセキュリティ問題を発生させます。

   The 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 by the TB to deliver
   the tunnel parameters to the client.  In this case, there must be a
   dedicated agent running on the client to process this information and
   actually set-up the tunnel end-point on behalf of the user.  This is
   a very attractive approach which is worth envisaging.  In particular,
   the definition of the new content-type might be the subject of a
   future ad-hoc document.
   上記述セキュリティ問題はクライアントにトンネルパラメータを届けるため
   にTBの使う新しいMIME(多目的インターネット・メール・エクステン
   ション)コンテンツタイプ(例えば、application/tunnel)[4,5]を定義する
   ことでエレガントに解決できます。この場合、この情報を処理し、ユーザー
   のためにトンネル終端点を実際に準備するクライアント上で走る献身的なエー
   ジェントがあるに違いありません。これは想像する価値があり非常に魅力的
   なアプローチです。特に、新しい内容タイプの定義は将来の特別な文書の主
   題であるかもしれません。

   Several options are available also to achieve proper interaction
   between the broker and the Tunnel Servers.  For example a set of
   simple RSH commands over IPsec could be used for this purpose.
   Another alternative could be to use SNMP or to adopt any other
   network management solution.
   いくつかのオプションはブローカーとトンネルサーバ間で適切な相互作用を
   成し遂げるために利用可能です。例えばIPsec上の単純なRSHコマンドのセッ
   トがこの目的で使うことができます。他の方法はがSNMPか他のネットワー
   ク管理ソリューションを採用することです。

   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 users zone
   (e.g.  broker.isp-name.com).
   最後にTBが制御するダイナミックDNS更新プロトコル[6]が自動的なD
   NS更新(すなわち、トンネルブローカユーザのために確保したAAAAやA6
   やPTRの追加や削除)に使われるべきです。単純な代案は、TBがRSH
   コマンドのいくつかを使い、トンネルブローカーユーザゾーン(例えば
   broker.isp-name.com)の正式DNSサーバの順と逆データベースを動的更
   新する事です。

2.7 Open issues
2.7 オープン問題

   Real usage of the TB service may require the introduction of
   accounting/billing functions.
   TBサービスの真の利用には課金/請求処理機能の導入を必要とするかも
   しれません。

3. Known limitations
3. 既知の限界

   This mechanism may not work if the user is using private IPv4
   addresses behind a NAT box.
   このメカニズムは、もしユーザーがNATボックスの後ろのプライベート
   のIPv4アドレスを使っているなら、働かないかもしれません。

4. Use of the tunnel broker concept in other areas
4. 他のエリアでのトンネルブローカ概念の利用

   The Tunnel Broker approach might be 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 unicast Internet) or an IPsec tunnel.
   トンネルブローカアプローチは、マルチキャストトンネルのような、他の種
   類のトンネルの自動設定や管理を効率的にするかもしれません(例えば、ユ
   ニキャストインターネット内でマルチキャストアイランドを相互に結び付け
   るために使われます)。

   Moreover, the idea of deploying a dedicated access-control server,
   like the 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).
   さらに、IPv6ネットワークにアクセスを望むユーザの安全な認可と支援
   のため、TBの様な専用アクセス制御サーバを配置する考えは、他の以降メ
   カニズムの拡張に有用かもしれません。例えば容易にリレー探索を成し遂げ
   る6to4モデル内で類似のアプローチを採用することは可能でしょう。これ
   は初期の6to4採用者の活動をより容易にするだけでなく、ISPが6to4
   リレー機能をより良く制御するのを許すでしょう(例えば、適切な使用ポリ
   シーの設定)。

5. Security Considerations
5.セキュリティの考察

   All the interactions between the functional elements of the proposed
   architecture need to be secured:
   提案されたアーキテクチャの機能的な要素の間のすべての相互作用は保証さ
   れる必要があります:

      -  the interaction between the client and TB;
      -  クライアントとTBの間の対話;

      -  the interaction between the TB and the Tunnel Server;
      -  TBとトンネルサーバ間の対話;

      -  the interaction between the TB and the DNS.
      -  TBとDNS間の対話

   The security techniques adopted for each of the required interactions
   is dependent on the implementation choices.
   必要な対話のそれぞれに採用するセキュリティ技術は実装に依存ます。

   For the client-TB interaction, the usage of http allows the
   exploitation of widely adopted security features, such as SSL (Secure
   Socket Layer) [7], to encrypt data sent to and downloaded from the
   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.
   クライアントTB対話で、http使用は、webサーバへの送信やダウンロードデー
   タの暗号化に、SSL(安全なソケットレイヤ)[7]のような広く採用されたセ
   キュリティ機能の採用を許します。これは同じく単純な「ユーザ名」と「パス
   ワード」認証手順をアクセス制御を実施する既存のAAA機能(例えば、ラ
   ディウス)でも可能です。

   For the TB-TS interaction secure SNMP could be adopted [8,9,10].  If
   the dynamic DNS update procedure is used for the TB-DNS interaction,
   the security issues are the same as discussed in [11].  Otherwise, if
   a simpler approach based on RSH commands is used, standard IPsec
   mechanisms can be applied [12].
   TB−TSの対話は、安全なSNMPの採用でできます[8,9,10]。もしダイナミッ
   クDNS更新手順がTB−DNSの対話で使われるなら、セキュリティ問題は
   [11]で論じられのと同じです。もしRSHコマンドに基づいたより単純なアプ
   ローチが使われるなら、標準IPsecメカニズムを用いる事ができます[12]。

   Furthermore, if the configuration of the client is achieved running
   scripts provided by the TB, these scripts must be executed with
   enough privileges to manage network interfaces, such as an
   administrator/root role.  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.
   さらに、もしクライアント設定がTBの供給したスクリプトを動作させる事
   で達成するなら、これらのスクリプトは管理者/rootのような、ネットワー
   クインタフェースを管理するのに十分な権限で実行されなくてはなりません。
   これは危険であり得て、トンネルブローカアプローチの初期の実行でだけ考
   えられるべきです。https上にMIMEタイプでトンネル設定パラメータを転送
   することはより安全なアプローチです。

   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 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.
   加えて、ダイアルアップユーザーがTBを通して前に確立されたトンネルを
   取り壊さないでインターネットから接続を断つ時はいつでも機密性の損失が
   起こるかもしれません。実際、TSはIPv4アドレスが動的に他のダイア
   ルアップISP加入者に割り当てられたという事実にかかわらず、そのユー
   ザへのIPv6トラヒックをトンネルして古いIPv4アドレスに送ります。
   この問題は、TBが切断したユーザーに向かうIPv6トラフィック転送を
   止めるため、すべてのトンネルの上に2.5章で概説した生存確認メカニズム
   を実装することで解決できます。

   Finally TBs must implement protections against denial of service
   attacks which may occur whenever a malicious user exhausts all the
   resources available on the tunnels server 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 at the same time.
   最後にTBが、悪意があるユーザーが多くのトンネルの設立を求めてトンネ
   ルサーバー上で利用可能なすべてのリソースを使い果たす時に起こるかもし
   れないサービス妨害攻撃に対して保護を実装しなくてはなりません。この攻
   撃に対しての可能な保護が、管理的に一人のユーザーが同時に許されるトン
   ネルの数を制限することで成し遂げられます。

6. Acknowledgments
6. 謝辞

   Some of the ideas refining the tunnel broker model came from
   discussion with Perry Metzger and Marc Blanchet.
   トンネルブローカモデルを洗練する考えがPerry MetzgerとMarc Blanchetの
   論議から来ました。

7. References
7. 参考文献

   [1]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
        Hosts and Routers", RFC 1933, April 1996.

   [2]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
        Domains without Explicit Tunnels", RFC 2529, March 1999.

   [3]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
        Clouds without Explicit Tunnels", Work in Progress.

   [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part One: Format of Internet Message Bodies,
        RFC 2045, November 1996.

   [5]  Freed, N. and N. Borenstein, "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.

   [7]  Guttman, E., Leong, L. and G. Malkin, "Users' Security
        Handbook", FYI 34, RFC 2504, February 1999.

   [8]  Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for
        Describing SNMP Management Frameworks", RFC 2571, April 1999.

   [9]  Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
        for version 3 of the Simple Network Management Protocol
        (SNMPv3)", RFC 2574, April 1999.

   [10] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
        Control Model (VACM) for the Simple Network Management Protocol
        (SNMP)", RFC 2575, April 1999.

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

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


8. Authors' Addresses
8. 著者のアドレス


   Alain Durand
   SUN Microsystems, Inc
   901 San Antonio Road
   MPK17-202
   Palo Alto, CA 94303-4900
   USA

   Phone: +1 650 786 7503
   EMail: Alain.Durand@sun.com


   Paolo Fasano S.p.A.

   CSELT S.p.A.
   Switching and Network Services - Networking
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy

   Phone: +39 011 2285071
   EMail: paolo.fasano@cselt.it


   Ivano Guardini
   CSELT S.p.A.
   Switching and Network Services - Networking
   via G. Reiss Romoli, 274
   10148 TORINO
   Italy

   Phone: +39 011 2285424
   EMail: ivano.guardini@cselt.it


   Domenico Lento
   TIM
   Business Unit Project Management
   via Orsini, 9
   90100 Palermo
   Italy

   Phone: +39 091 7583243
   EMail: dlento@mail.tim.it


9. Full Copyright Statement
9. 著作権表示全文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.
   著作権(C)インターネット学会(2001)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So