[要約] RFC 3053はIPv6トンネルブローカーの仕様を定義し、IPv6ネットワークへのアクセスを提供するためのプロトコルを提案しています。目的は、IPv6の普及を促進し、IPv4からIPv6への移行を支援することです。
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.
Copyright（c）The Internet Society（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名を取得できるようにすることです。トンネルブローカーの概念は、1998年12月にオーランドのIETFで初めて発表されました。1999年2月のGrolenoble IPNG＆NGTRANS暫定会議で2つの実装が実証されました。
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のアドレス疲労問題を解決しないことです。また、完全なIPv4ルーティングテーブルをIPv6ワールドに含めることは大きな恐怖があります。
- 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ドメインと通信できるように設計されています。アイデアは、IPv4トンネルアドレスをIPv6プレフィックスに埋め込むことで、ドメインボーダールーターがアウトバウンドIPv6トラフィックのトンネルエンドポイントを自動的に発見できるようにすることです。
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アプローチは、IPv4 ISPがネイティブIPv6サービスを提供するのを待つことなく、分離された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では、セキュリティの問題について説明します。
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.
トンネルブローカーは、仮想IPv6 ISPSと見なすことができ、IPv4インターネットに既に接続されているユーザーにIPv6接続を提供します。新しいIPv6インターネットでは、多くのトンネルブローカーが利用可能になるため、ユーザーが1つだけ選択する必要があることが期待されています。トンネルブローカーのリストは、ユーザーが「最も近い」もの、「最も安い」もの、またはその他を選択できるようにするために、「よく知られている」Webページ（http://www.ipv6.orgなど）で参照する必要があります。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）ルーターです。結核から来る構成順序を受け取ると、各トンネルのサーバー側を作成、変更、または削除します。また、すべてのアクティブトンネルの使用統計を維持する場合があります。
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ノード（ホストまたはルーター）です。結核に近づくと、クライアントは、適切なユーザー認証、承認、および（オプションで）会計を実行できるように、まずアイデンティティと資格情報を提供するように依頼する必要があります（たとえば、RADIUSなどの既存のAAA施設に依存します）。これは、クライアントとTBが、サービスの不正使用を防ぐために使用されるために、事前に構成または自動的に確立されたセキュリティ協会を共有する必要があることを意味します。これにより、TBはIPv4相互接続されたIPv6ユーザーのアクセス制御サーバーと見なすことができます。
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オーバーIPv4トンネルが機能しているため、トンネルブローカーユーザーが6boneにアクセスできるようになります。またはTSが接続されている他の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アドレスの寿命は、ユーザーのIPv4接続の寿命よりも比較的長く、潜在的に長くなければなりません。これは、ダイヤルアップリンクを介してインターネットに接続され、DHCPを介して動的に割り当てられたIPv4アドレスを取得するにもかかわらず、クライアントがSemipermanent 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オーバー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アドレスを取得するため、新しいトンネルを設定するか更新する義務があります。前のものの構成。このような状況では、TSがすべてのアクティブトンネルのTB IPv6トラフィックと到達可能性統計に定期的に配信することにより、より効果的なトンネル管理を実現することができます。このようにして、結核は、比較的長くなる可能性のある関連寿命の有効期限を待たずに、不活性の期間の後にトンネル削除を強制することができます（例：数日）。
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の間の何らかのトンネル管理プロトコルまたはキープアライブメカニズムを実装して、ユーザーが切断された後に各トンネルをすぐにリリースできるようにすることですエンドポイントまたはインターネットへの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.
結核とユーザーの間の相互作用は、HTTPに基づいている可能性があります。たとえば、ユーザーは、TBで実行されているWebサーバーでいくつかのフォームを記入するだけで、関連する構成情報（つまり、トンネルのクライアント側のIPv4アドレスなど）を提供できます。その結果、サーバーは、トンネルのサーバーエンドポイントが構成され、関連するすべてのトンネル情報が表示されていることを示す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.
上記のセキュリティの問題は、新しいMIME（多目的インターネットメールエクステンション）コンテンツタイプ（アプリケーション/トンネルなど）[4,5]を定義することにより、TBがクライアントに提供するために使用することにより、エレガントに克服できます。この場合、この情報を処理し、実際にユーザーに代わってトンネルのエンドポイントを設定するために、クライアントで献身的なエージェントが実行されている必要があります。これは非常に魅力的なアプローチであり、想像する価値があります。特に、新しいコンテンツタイプの定義は、将来のアドホックドキュメントの主題である可能性があります。
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アップデート（つまり、トンネルブローカーユーザー用に予約されたDNSゾーンからAAAA、A6、およびPTRレコードを追加または削除するために）に使用する必要があります。単純な代替案は、TBがRSHコマンドの小さなセットを使用して、トンネルブローカーユーザーゾーン（Broker.isp-name.comなど）の権威あるDNSサーバーのダイレクトデータベースと逆データベースを動的に更新することです。
Real usage of the TB service may require the introduction of accounting/billing functions.
結核サービスの実際の使用には、会計/請求機能の導入が必要になる場合があります。
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).
さらに、TBなどの専用アクセス制御サーバーを展開するというアイデアは、IPv6ネットワークへのアクセスを取得したいユーザーを安全に承認および支援することで、他の遷移メカニズムを強化するのにも役立つかもしれません。たとえば、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.
- 結核と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.
Client-TBの相互作用の場合、HTTPの使用により、SSL（Secure Socket Layer）[7]などの広く採用されたセキュリティ機能を利用して、Webサーバーに送信されてダウンロードされたデータを暗号化できます。これにより、簡単な「ユーザー名」および「パスワード」認証手順、および既存の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によって提供された[スクリプトの実行]を達成された場合、これらのスクリプトは、管理者/ルートロールなどのネットワークインターフェイスを管理するのに十分な特権で実行する必要があります。これは危険な場合があり、トンネルブローカーアプローチの早期実装のためにのみ考慮する必要があります。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アドレスにトンネルし続けています。この問題は、セクション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.
最後に、TBSは、悪意のあるユーザーが多くのトンネルを完全に確立するよう求めることにより、Tunnelsサーバーで利用可能なすべてのリソースを排出するときに発生する可能性のあるサービス攻撃に対する保護を実装する必要があります。この攻撃に対する可能性のある保護は、単一のユーザーが同時にセットアップすることが許可されているトンネルの数を管理的に制限することで達成できます。
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] Gilligan、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] Carpenter、B。およびC. Jung、「明示的なトンネルなしの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] Carpenter、B。およびK. Moore、「明示的なトンネルなしのIPv4クラウドを介したIPv6ドメインの接続」は、進行中の作業です。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996.
[4] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式、RFC 2045、1996年11月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] Freed、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.、Editor、Thomson、T.、Rekhter、Y.、J。Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[7] Guttman, E., Leong, L. and G. Malkin, "Users' Security Handbook", FYI 34, RFC 2504, February 1999.
[7] Guttman、E.、Leong、L。and G. Malkin、「ユーザーセキュリティハンドブック」、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.、Harrington、D。、およびR. Presuhn、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2571、1999年4月。
[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] Blumenthal、U.およびB. Wijnen、「シンプルネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、RFC 2575、1999年4月。
[11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[11] EastLake、D。、「Secure Domain Name System Dynamic Update」、RFC 2137、1997年4月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA
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
Paolo Fasano S.P.A. CSELT S.P.A.スイッチングおよびネットワークサービス - 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
Ivano Guardini CSELT S.P.A.スイッチングおよびネットワークサービス - 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
ドメニコレントティムビジネスユニットプロジェクト管理オルシーニ、9 90100パレルモイタリア
Phone: +39 091 7583243
EMail: dlento@mail.tim.it
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。