この文書はRFC3053の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
※pngイメージが１つ入ってるので、コピーする際は忘れずに
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.
ＩＰｖ６グローバルインターネットは今日の時点で既存のＩＰｖ４インフラ
上で多くのトンネルを使います。これらのトンネルは大規模な環境で設定し
て維持するのは困難です。６ｂｏｎｅは大きいサイトとインターネット・サー
ビスプロバイダがそれを出来ることを証明しましたが、このプロセスはすで
にＩＰｖ４接続を持っていてＩＰｖ６世界に入りたい孤立しているエンドユー
ザにはあまりにも複雑です。トンネルブローカーモデルの開発の動機づけは、
初期のＩＰｖ６採用者が既存のＩＰｖ６ネットワーク（例えば、６ｂｏｎｅ）
に接続して、安定した、永住のＩＰｖ６アドレスとＤＮＳ名を得るのを手伝
うためです。トンネルのブローカーの概念は１９９８年１２月にオーランド
のＩＥＴＦにおいて最初に提出されました。２つの実装が１９９９年２月の
グルノーブル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:
ＩＰｖ６ネットワークは主に、現在のインターネットによって提供された転
送機能を使い始めることで、成長しました。これはＩＰｖ４トンネル上にＩ
Ｐｖ６を管理するいくつかの技術の開発に導きました。目下６ｂｏｎｅネッ
トワークの大部分がインターネット上に手作業で設定されたトンネルを使っ
て構築されます。このアプローチの主な欠点は各トンネルのために大規模な
手動の設定を行わなければならないネットワーク管理者のために圧倒的な管
理負荷です。この管理負荷を減らすいくつかの試みがすでに提案され、そし
てそれらのそれぞれが面白い利点を引き起こしますが、トンネルブローカー
とは異なった問題を解くか、あるいはトンネルのブローカーで存在しない欠
点を提出します：
- 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;
- ＩＰｖ４コンパチブルアドレス[1]を使う自動的なトンネルの使用は
孤立しているデュアルスタックホストやルーターの間で初期のＩＰｖ
６接続性を確立するための単純なメカニズムです。このアプローチに
おける問題は、これがＩＰｖ４のアドレス極度の枯渇問題を解かない
ということです。同じくこれがＩＰｖ４ルーティングテーブルをＩＰ
ｖ６に入れ、ルーティングテーブルサイズを５倍に増やする事になる
恐れがあります；
- 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;
- ６over４[2]が仮想リンクレイヤとしてＩＰｖ４マルチキャストを使
用する事に基づくサイト移行メカニズムです。それはグローバルなＩ
Ｐｖ６インターネットに孤立ユーザーを結ぶことの問題を解きません；
- 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.
- ６to４[3]がネイティブのＩＰｖ６サポートがない広域ネットワーク
（例えば、ＩＰｖ４インターネット）に置かれた孤立しているＩＰｖ
６ドメインを許し、最小の手動の設定で他のＩＰｖ６ドメインと通信
できるよう意図されました。アイデアは、ドメイン境界ルータが外行
きのＩＰｖ６トラフィックのために自動的にトンネル終端を発見する
ことができるように、ＩＰｖ６プレフィックスの中にＩＰｖ４トンネ
ルアドレスを埋め込む事です。
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:
トンネルブローカと６to４メカニズムの間の主な相違は、それぞれがＩＰｖ
６共同体の異なった部分を果たす事です：。
- 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.
- ６to４アプローチは孤立しているＩＰｖ６サイトに、ＩＰｖ４のＩＳ
ＰがネイティブＩＰｖ６サービスを提供するのを待たずに、容易に接
続を許すよう意図されました。これはエクストラネットと仮想プライ
ベートネットワークに大変上手に適しています。６to４リレーを使っ
て、６to４サイトがＩＰｖ６インターネット上のサイトに接続できま
す。
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
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.
トンネルのブローカーが、ＩＰｖ４インターネットに接続てＩＰｖ６接続性
を供給する、仮想のＩＰｖ６のＩＳＰの様に見えます。発生しているＩＰｖ
６インターネットで、多くのトンネルのブローカーが利用可能と思われます
が、ユーザーがちょうど１つを選ばなければなりません。トンネルブローカー
のリストは、ユーザに「最も近い」か「最も安い」ものを選択できるように、
「既知」Webページ上で参照されるべきです(例えばhttp://www.ipv6.org)。
The tunnel broker model is based on the set of functional elements
depicted in figure 1.
トンネルブローカモデルは図１で描写される機能的な要素のセットに基づい
ています。
Figure 1: the Tunnel Broker model
図１：トンネルブローカモデル
2.1 Tunnel Broker (TB)
2.1 トンネルブローカ（ＴＢ）
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)
2.2 Tunnel サーバー（ＴＳ）
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.
ＴＳはグローバルインターネットに接続したデュアルスタック（ＩＰｖ４
＆ＩＰｖ６）ルーターです。ＴＢから来ている設定命令の受信により、こ
れは各トンネルのサーバー側を作り、修正し、削除します。これはすべて
のアクティブなトンネルのために利用統計値を持続するかもしれません。
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.
トンネルブローカサービスのクライアントはＩＰｖ４インターネットと接続
されるデュアルスタックＩＰｖ６ノード（ホストあるいはルーター）です。
ＴＢの接する際に、適切なユーザー認証と認可と（オプションで）課金を実
行するために、クライアントはＩＤと資格をまず第一に尋ねられるべきです
（例えば、ラディウスのような既存のＡＡＡファシリティを利用します）。
これはサービスの無許可の使用を妨げるためにクライアントとＴＢが事前設
定か自動設定でにセキュリティアソシエーションを共有しなければならない
ことを意味します。この点でＴＢは、ＩＰｖ６ユーザを接続するＩＰｖ４の
アクセス制御サーバーと見られることができます。
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;
- トンネルのサーバー側を設定します；
- 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
2.4 ＩＰｖ６アドレス割当て
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
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.
ＴＢの作った各ＩＰｖ４上のＩＰｖ６トンネルは少なくとも寿命を割り当て
られて、クライアントが明白な寿命延長要請を出さないなら、期限後にトン
ネルを削除するべきです。
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).
明らかにこれはユーザーが短命の動的に扱われたＩＰｖ４接続を通してイン
ターネットにアクセスすることに関して特に最適な解決ではありません（例
えば、ダイアルアップリンク）。この場合新たに確立されたトンネルが短期
間だけ使われ再度使われる事がなく、ユーザーが再び接続する時に新しいＩ
Ｐｖ４アドレスを得て、従って新しいトンネルか更新した設定が使われるで
しょう。このような状況で、TSがすべてのアクティブなトンネルのためにＩ
Ｐｖ６トラフィックと到達可能性統計値をTBに周期的に送ることで、より効
果的なトンネル管理が成し遂げられるかもしれません。このようにして、Ｔ
Ｂは比較的長い寿命が切れるのを待たずに不活性なトンネル削除を強制する
ことができます（例えば、数日）。
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.
他の解決方法は、各トンネルがユーザーが接続を断った後（例えば、トン
ネル終端点を削除する、インターネットのＩＰｖ４接続を停止する）すぐ
に解放されるように、クライアントとTS間に（あるいはクライアントとＴ
Ｂ間に）何らかの種類のトンネル管理プロトコルあるいは生存確認機構を
実装することかもしれません。この保障機構の欠点は上記のアドホックな
生存確認機構に対するサポートを加えるため、クライアントマシン上のソ
フトウェアアップグレードを必要とするということです。
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
2.6 クライアントとＴＢとＴＳとＤＮＳの間の対話
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.
前に述べた通り、トンネルブローカアーキテクチャで様々なエンティティー
間で通信に使われるプロトコルと手順の特定のセットの定義は現在のフレー
ムワーク文書の範囲の外です。にもかかわらず、この章でクライアント-ＴＢ
とＴＢ-ＴＳとＴＢ−ＤＮＳの対話をサポートする実装可能な技術的方法が将
来の実装努力あるいは標準化案提出に手を貸すために手短かに記述されます。
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.
ＴＢとユーザー間の相互作用はhttpに基づき得ます。例えばユーザーはＴＢ
上で動作するWebサーバ上のフォームを満たすことで適切な設定情報（すなわ
ち、トンネルのクライアント側のＩＰｖ４アドレスなど）を供給できます。
サーバーが返答としてトンネルのサーバー終端点の構成が設定され、すべて
の適切なトンネル情報を示すページをハイパーテキスト化し返送します。
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.
トンネルブローカユーザーのデュアルスタック装置の設定をサポートするた
めのいくつかのオプションが想像されるかもしれません。最も単純なオプショ
ンは、クライアントマシン上でオフラインで動作し、ＴＢがクライアント側
のトンネル終端の容易な設定や停止をするための、クライアント固有のスク
リプトを準備する事です。この解決は明らかにクライアントマシン上のソフ
トウェア拡張を必要としないという点で、実行と操作が容易です。しかしな
がら、これはユーザーが前にダウンロードされたスクリプトが誤って実行さ
れたり、危険な操作が行わないことを確かめることは難しいかもしれないか
ら、いくつかのセキュリティ問題を発生させます。
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.
上記述セキュリティ問題はクライアントにトンネルパラメータを届けるため
にＴＢの使う新しいＭＩＭＥ（多目的インターネット・メール・エクステン
ション）コンテンツタイプ（例えば、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コマンドのセッ
トがこの目的で使うことができます。他の方法はがＳＮＭＰか他のネットワー
ク管理ソリューションを採用することです。
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).
最後にＴＢが制御するダイナミックＤＮＳ更新プロトコル[6]が自動的なＤ
ＮＳ更新（すなわち、トンネルブローカユーザのために確保したAAAAやＡ６
やＰＴＲの追加や削除）に使われるべきです。単純な代案は、ＴＢがＲＳＨ
コマンドのいくつかを使い、トンネルブローカーユーザゾーン（例えば
broker.isp-name.com）の正式ＤＮＳサーバの順と逆データベースを動的更
新する事です。
2.7 Open issues
2.7 オープン問題
Real usage of the TB service may require the introduction of
accounting/billing functions.
ＴＢサービスの真の利用には課金／請求処理機能の導入を必要とするかも
しれません。
3. Known limitations
3. 既知の限界
This mechanism may not work if the user is using private IPv4
addresses behind a NAT box.
このメカニズムは、もしユーザーがＮＡＴボックスの後ろのプライベート
のＩＰｖ４アドレスを使っているなら、働かないかもしれません。
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).
さらに、ＩＰｖ６ネットワークにアクセスを望むユーザの安全な認可と支援
のため、ＴＢの様な専用アクセス制御サーバを配置する考えは、他の以降メ
カニズムの拡張に有用かもしれません。例えば容易にリレー探索を成し遂げ
る６to４モデル内で類似のアプローチを採用することは可能でしょう。これ
は初期の６to４採用者の活動をより容易にするだけでなく、ＩＳＰが６to４
リレー機能をより良く制御するのを許すでしょう（例えば、適切な使用ポリ
シーの設定）。
5. Security Considerations
５．セキュリティの考察
All the interactions between the functional elements of the proposed
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 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.
クライアントＴＢ対話で、http使用は、webサーバへの送信やダウンロードデー
タの暗号化に、SSL（安全なソケットレイヤ）[7]のような広く採用されたセ
キュリティ機能の採用を許します。これは同じく単純な「ユーザ名」と「パス
ワード」認証手順をアクセス制御を実施する既存のＡＡＡ機能（例えば、ラ
ディウス）でも可能です。
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].
ＴＢ−ＴＳの対話は、安全なSNMPの採用でできます[8,9,10]。もしダイナミッ
クＤＮＳ更新手順がＴＢ−ＤＮＳの対話で使われるなら、セキュリティ問題は
[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.
さらに、もしクライアント設定がＴＢの供給したスクリプトを動作させる事
で達成するなら、これらのスクリプトは管理者／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.
加えて、ダイアルアップユーザーがＴＢを通して前に確立されたトンネルを
取り壊さないでインターネットから接続を断つ時はいつでも機密性の損失が
起こるかもしれません。実際、ＴＳはＩＰｖ４アドレスが動的に他のダイア
ルアップＩＳＰ加入者に割り当てられたという事実にかかわらず、そのユー
ザへのＩＰｖ６トラヒックをトンネルして古いＩＰｖ４アドレスに送ります。
この問題は、ＴＢが切断したユーザーに向かうＩＰｖ６トラフィック転送を
止めるため、すべてのトンネルの上に２.５章で概説した生存確認メカニズム
を実装することで解決できます。
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.
最後にＴＢが、悪意があるユーザーが多くのトンネルの設立を求めてトンネ
ルサーバー上で利用可能なすべてのリソースを使い果たす時に起こるかもし
れないサービス妨害攻撃に対して保護を実装しなくてはなりません。この攻
撃に対しての可能な保護が、管理的に一人のユーザーが同時に許されるトン
ネルの数を制限することで成し遂げられます。
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.
著作権（Ｃ）インターネット学会（２００１）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。