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.
著作権（C）インターネット協会（2001）。全著作権所有。
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のは、大規模なサイトやインターネットサービスプロバイダ（ISP）がそれを行うことができますことを証明しているが、このプロセスは、すでにIPv4接続を持っているとIPv6の世界を入力したい孤立エンドユーザにとっては複雑すぎます。トンネルブローカーモデルの開発のための動機は、初期のIPv6は、既存のIPv6ネットワーク（例えば、6boneの）にフックアップし、安定した、永久的なIPv6アドレスとDNS名を取得するために採用支援することです。トンネルブローカーの概念は、最初の2つの実装は、1999年2月グルノーブルのIPng＆NGTRANS暫定会議中に示された1998年12月にオーランドのIETFで発表されました。
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トンネル上でIPv6を管理するために、いくつかの技術の開発につながりました。現在のところ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]単離されたデュアルスタックホストおよび/またはルータ間で初期のIPv6接続性を確立するための単純なメカニズムです。このアプローチの問題は、それは、IPv4のアドレス枯渇問題を解決しないということです。また、これは、ルーティングテーブルのサイズの問題5を掛けることを悪化させてしまうためのIPv6の世界に完全なIPv4ルーティングテーブルを含めるには絶好の恐れがあります。
- 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マルチキャストの使用に基づいて、サイトローカル遷移機構です。これは、グローバルIPv6インターネットに孤立したユーザの接続の問題を解決しません。
- 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をサポートした広域ネットワークに接続されている単離されたIPv6ドメイン、（例えば、IPv4インターネット）、最小限の手動設定を他のこのような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機構との間の主な違いは、それらは、IPv6コミュニティの異なるセグメントを提供することです。
- 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ネットワークに接続したいIPv4インターネット上の特に孤立した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サイトが簡単にネイティブIPv6サービスを提供するために彼らのIPv4のISPを待たずに一緒に接続できるように設計されています。これは、エクストラネットと仮想プライベートネットワークのために非常に適しています。 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節では、セキュリティ上の問題に対処します。
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として見ることができます。新興IPv6インターネットでは、ユーザが1つだけ選択する必要がありますように、多くのトンネルブローカーが利用可能になることが期待されます。トンネルブローカーのリストは、ユーザーが「最も近い」1、一つの「安い」、またはその他を選択できるようにする（例えばhttp://www.ipv6.org上）「周知の」Webページ上で参照する必要があります1。
The tunnel broker model is based on the set of functional elements depicted in figure 1.
トンネルブローカーモデルは、図1に示された機能要素の集合に基づいています。
+------+
/|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
図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.
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で行うことができます。
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からの設定順序を受信すると、それが作成し、各トンネルのサーバ側を変更または削除します。また、すべてのアクティブなトンネルの使用統計を維持することができます。
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に近づいて、クライアントが適切なユーザー認証、認可、および（オプションで）会計（例えば、RADIUSなどの既存のAAA施設に頼って）行うことができるように、そのアイデンティティと資格情報を提供するために、まず第一に求めるべきです。これは、クライアントとTBは、サービスの不正使用を防止するために使用される事前構成済み、または自動的に確立されたセキュリティ協会を共有する必要があることを意味します。 IPv4のアクセス制御サーバがIPv6ユーザを相互接続し、このに関してTBを見ることができます。
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ルーターであればまた、クライアントが必要なIPv6アドレスの量に関する情報を提供することも求めるべきです。これは、TBがクライアントに単一の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;
- それは自動的にDNSにトンネルエンドポイントに割り当てられたグローバルIPv6アドレスを登録します。
- 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との間のIPv6 over IPv4トンネリングが起動されており、従って6boneのへのアクセスを取得するために、トンネルブローカーユーザを可能にし、ワーキングまたは任意の他のIPv6ネットワークTSがに接続されています。
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アドレスの寿命は比較的長く、潜在的に長いユーザーのIPv4接続の寿命よりべきです。これにより、クライアントは、それがダイヤルアップリンクを介してインターネットに接続され、動的にIPv4のは、DHCPを通じてアドレスを割り当てられますにもかかわらず半永久IPv6アドレスと関連付けられているDNS名を取得できるようにすることです。
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によって作成されたそれぞれのIPv6 over IPv4トンネリングは、少なくとも寿命を割り当てられ、明示的な寿命延長要求がクライアントによって提出されていない限り、その満了後に除去されるべきです。
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接続（たとえば、ダイヤルアップリンク）を取り上げました。この場合、新たに設立されたトンネルはその中で、二度と利用者は、彼が新しいIPv4アドレスを取得するため、新しいトンネルをアップしたり、更新するか義務が再接続するたびに、その後の短い時間のためだけに使用される可能性が高いとされ前の1の設定。このような状況では、より効果的なトンネル管理は、TSは、定期的にすべてのアクティブなトンネルのTB IPv6トラフィックと到達可能性の統計に届けることによって達成することができます。このように、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間メカニズム（またはクライアントとTBの間）することであってもよいですエンドポイントまたはインターネットへの彼のIPv4接続を切断）。このポリシーメカニズムの欠点は、それはまた、上記のアドホックキープアライブメカニズムのサポートを追加するために、クライアントマシン上のソフトウェアのアップグレードを必要とすることです。
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は、クライアントの新しいIPv4アドレスを使用して再作成するトンネルにTSを注文したが、以前に割り当てられたIPv6アドレスを再利用することができます。こうすることで、クライアントはIPv4アドレスが動的であってもほぼ永久的（静的）IPv6アドレスを保存することができます。また、関連する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に基づくことができます。例えば、ユーザは、関連する構成情報を提供することができる（すなわち、トンネルなどのクライアント側のIPv4アドレス）だけTB上で実行されているWebサーバー上のいくつかのフォームを埋めることによって。その結果、サーバは、HTMLページがトンネルのサーバエンドポイントが設定されていることを知らせると、関連するすべてのトンネル情報を表示して応答することができます。
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.
上記のセキュリティ問題は、エレガント[4,5]クライアントへのトンネルパラメータを配信するためにTBが使用する新しいMIME（多目的インターネットメール拡張）コンテンツ・タイプ（例えば、アプリケーション/トンネル）を定義することによって克服することができた説明しました。この場合には、ユーザに代わってこの情報と、実際にセットアップトンネルエンドポイントを処理するために、クライアント上で実行されている専用のエージェントが存在しなければなりません。これは想定価値が非常に魅力的なアプローチです。具体的には、新しいコンテンツタイプの定義は、将来のアドホック文書の主題であるかもしれません。
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).
最後に、動的DNS更新プロトコル[6] TBによって制御される（即ち、トンネルブローカーユーザのために予約DNSゾーンからAAAA、A6およびPTRレコードを追加または削除する）自動DNS更新のために使用されるべきです。 TBがRSHの小さなセットを動的に（例えばbroker.isp-name.com）トンネルブローカーユーザゾーンの権限DNSサーバに直接および逆データベースを更新するためにコマンドを使用するための単純な代替案は、あろう。
Real usage of the TB service may require the introduction of accounting/billing functions.
TBサービスの実際の使用量は、会計/課金機能の導入を必要とするかもしれません。
This mechanism may not work if the user is using private IPv4 addresses behind a NAT box.
ユーザーがNATボックスの後ろにプライベートIPv4アドレスを使用している場合は、このメカニズムが機能しない場合があります。
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.
トンネルブローカアプローチは、効率的に自動的にセットアップすることも悪用や、マルチキャストトンネル（例えば、ユニキャストインターネット内のマルチキャストアイランドを相互接続するために使用される）、またはIPsecトンネルのようなトンネルの他の種類を管理するかもしれません。
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リレー施設（例えば、適切な使用ポリシーを設定する）の使用を制御することができるようになります。
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の使用は、SSL（セキュア・ソケット・レイヤー）として広く採用されているセキュリティ機能の活用が[7]、に送信され、Webサーバからダウンロードしたデータを暗号化することができます。また、これは、アクセス制御を実施する（例えば、RADIUS）簡単な「ユーザー名」と「パスワード」認証手続き上、既存の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は、IPv6トラフィックは関係なく、その間にIPv4アドレスが動的に同じダイヤルアップISPの別の加入者に割り当てられている可能性があることという事実の彼の昔のIPv4アドレスにそのユーザ宛のトンネル続けます。この問題は、セクション2.5に概説さキープアライブ機構は、このようにTBが直ちに切断されたユーザーに向けてIPv6トラフィックの転送を停止することを可能にするすべてのトンネル上に実装することによって解決することができます。
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は、悪意のあるユーザーが完全に確立されるトンネルの多くを尋ねることにより、トンネルサーバ上で使用可能なすべてのリソースを使い果たしたときに発生する可能性があり、サービス拒否攻撃に対する保護を実装する必要があります。この攻撃に対する可能な保護は、管理上の単一ユーザーがセットアップすると同時に、許可されているトンネルの数を制限することによって達成することができました。
Some of the ideas refining the tunnel broker model came from discussion with Perry Metzger and Marc Blanchet.
トンネルブローカーモデルを洗練アイデアのいくつかは、ペリーメッツガーとマルク・ブランシェとの議論から来ました。
[1] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[1]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 1933、1996年4月。
[2] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[2]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでのIPv4ドメイン上のIPv6の送信"、RFC 2529、1999年3月。
[3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", Work in Progress.
[3]大工、B.およびK.ムーア、 "明示的なトンネルなしでのIPv4クラウドを介したIPv6ドメインの接続"、ProgressのWork。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996.
[4]解放され、N.とN. Borenstein、「マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット、RFC 2045、1996年11月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[6] Vixie, P., Editor, Thomson, T., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[6]いるVixie、P.、エディタ、トムソン、T.、Rekhter、Y.、およびJ.はバウンド、 "ドメインネームシステムにおける動的更新（DNS更新）"、RFC 2136、1997年4月。
[7] Guttman, E., Leong, L. and G. Malkin, "Users' Security Handbook", FYI 34, RFC 2504, February 1999.
[7]グットマン、E.、レオン、L.とG.マルキン、 "ユーザーのセキュリティハンドブック"、FYI 34、RFC 2504、1999年2月を。
[8] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[8] Wijnenの、B.、ハリントン、D.とR. Presuhn、RFC 2571、1999年4月 "SNMP管理フレームワークを記述するためのアーキテクチャ"。
[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.
[9]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、RFC 2574、1999年4月。
[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.
[10] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、RFC 2575、1999年4月。
[11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[11]イーストレイク、D.は、RFC 2137、1997年4月、 "ドメインネームシステム動的な更新を固定します"。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA
アラン・デュランSUN Microsystems、Inc.の901サンアントニオの道MPK17-202パロアルト、CA 94303から4900 USA
Phone: +1 650 786 7503 EMail: Alain.Durand@sun.com
電話：+1 650 786 7503 Eメール：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
パオロ・ファザーノS.p.A. CSELT S.p.A.スイッチングとネットワークサービス - G.ライスRomoliを経由してネットワーク、274 10148 TORINOイタリア
Phone: +39 011 2285071 EMail: paolo.fasano@cselt.it
電話：+39 011 2285071 Eメール：paolo.fasano@cselt.it
Ivano Guardini CSELT S.p.A. Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy
イバノGuardini CSELT S.p.A.スイッチングとネットワークサービス - G.ライスRomoliを経由してネットワーク、274 10148 TORINOイタリア
Phone: +39 011 2285424 EMail: ivano.guardini@cselt.it
電話：+39 011 2285424 Eメール：ivano.guardini@cselt.it
Domenico Lento TIM Business Unit Project Management via Orsini, 9 90100 Palermo Italy
オルシーニ、9 90100パレルモイタリア経由ドメニコレントTIMビジネスユニットプロジェクト管理
Phone: +39 091 7583243 EMail: dlento@mail.tim.it
電話：+39 091 7583243 Eメール：dlento@mail.tim.it
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 Editor機能のための基金は現在、インターネット協会によって提供されます。