RFC3053 日本語訳
3053 IPv6 Tunnel Broker. A. Durand, P. Fasano, I. Guardini, D. Lento. January 2001. (Format: TXT=27336 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.ジュランドの要求をネットワークでつないでください: 3053年の太陽マイクロシステムズ、Incカテゴリ: 情報のP.のI.グァルディーニCSELT S.ファザーノp.レントのA.D.TIM2001年1月
IPv6 Tunnel Broker
IPv6トンネルのブローカー
Status of this Memo
この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)インターネット協会(2001)。 All rights reserved。
Abstract
要約
The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999.
今日現在IPv6世界的なインターネットは既存のIPv4インフラストラクチャの上で多くのトンネルを使用します。 それらのトンネルは大規模環境で構成して、維持するのは難しいです。 6boneは、大きいサイトとインターネットサービスプロバイダ(ISP)がそれができますが、IPv4接続が既にあって、IPv6世界に入れたがっている孤立しているエンドユーザには、このプロセスが複雑過ぎると立証しました。 トンネルブローカーモデルの進化に関する動機は早くIPv6採用者が既存のIPv6ネットワーク(例えば、6bone)を接続して、安定して、永久的なIPv6アドレスとDNS名を得るのを助けることです。 トンネルのブローカーの概念は1998年12月に最初に、オーランドのIETFに提示されました。 2つの実装が1999年2月にグルノーブルのIPng&NGtransの当座のミーティングの間、示されました。
1. Introduction
1. 序論
The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. At present most of the 6bone network is built using manually configured tunnels over the Internet. The main drawback of this approach is the overwhelming management load for network administrators, who have to perform extensive manual configuration for each tunnel. Several attempts to reduce this management overhead
IPv6ネットワークの成長は現在のインターネットによって提供された運送設備を主に使用し始めました。 これは、IPv4トンネルの上でIPv6を管理するためにいくつかのテクニックの開発に通じました。 現在のところ、インターネットの上で手動で構成されたトンネルを使用するのは6boneネットワークの大部分に建てられます。 このアプローチの主な欠点はネットワーク管理者のための圧倒的な管理負荷です。(その管理者は、各トンネルのための大規模な手動の構成を実行しなければなりません)。 この管理オーバーヘッドを下げるいくつかの試み
Durand, et al. Informational [Page 1] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[1ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
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:
既に提案されてください、おもしろい利点を提示しますが、Tunnel Brokerと異なった問題を解決するか、または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;
- IPv4コンパチブルアドレス[1]による自動トンネルの使用は孤立しているデュアルスタックホスト、そして/または、ルータの中で早めのIPv6の接続性を確立するのが簡単であるメカニズムです。 このアプローチに関する問題はIPv4のアドレス疲労困憊問題を解決しないということです。 また、これはそれを5に掛けることにおける経路指定テーブルサイズ問題を悪化させるでしょう、したがって、完全な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サポート(例えば、IPv4インターネット)なしで広域ネットワークに付けられた孤立しているIPv6ドメインが最小量の手動の構成と共に他のそのようなIPv6ドメインで交信するのを許容するように設計されています。 考えはどんなドメイン境界ルータも外国行きのIPv6トラフィックに関して自動的にトンネル終点を発見できるようにIPv4トンネルアドレスを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.
Tunnel Broker考えは自動的にユーザから来るトンネル要求を管理するためにTunnel Brokersと呼ばれる専用サーバの支給に基づく代替的アプローチです。 このアプローチが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:
Tunnel Brokerと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;
- Tunnel Brokerは容易に既存のIPv6ネットワークに接続したがっている小さい孤立しているIPv6サイト、およびIPv4インターネットの特に孤立している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アプローチは、それらのIPv4ISPがネイティブのIPv6サービスを提供するのを待つ必要はなくて孤立しているIPv6サイトが容易に一緒に接続するのを許容するように設計されています。 これはエクストラネットと仮想私設網に非常によく合っています。 6to4リレーを使用して、また、6to4サイトはIPv6インターネットに関するサイトに達することができます。
Durand, et al. Informational [Page 2] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[2ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
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.
さらに、Tunnel Brokerアプローチで、IPv6ISPは容易にそれら自身の方針にネットワーク資源利用に押しつけているユーザにアクセスコントロールを実行できます。
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.
このドキュメントがインターネットの中でTunnel Brokerサービスの支給のためのガイドラインについて説明するフレームワークを提示することを意図します。 それは、どんなプロトコルも指定しませんが、提案されたアプローチの一般的なアーキテクチャを詳しく述べます。 また、それはそれを実装するための1セットの実行可能な代案を概説します。 セクション2はTunnel Brokerモデルの総合的な記述を提供します。 セクション3は知られている制限をモデルに報告します。 セクション4は簡潔にTunnel Brokerアプローチの他の可能な応用について概説します。 セクション5は、セキュリティが問題であると扱います。
2. Tunnel Broker Model
2. トンネルブローカーモデル
Tunnel brokers can be seen as virtual IPv6 ISPs, providing IPv6 connectivity to users already connected to the IPv4 Internet. In the emerging IPv6 Internet it is expected that many tunnel brokers will be available so that the user will just have to pick one. The list of the tunnel brokers should be referenced on a "well known" web page (e.g. on http://www.ipv6.org) to allow users to choose the "closest" one, the "cheapest" one, or any other one.
既にIPv4インターネットに接続されたユーザにIPv6の接続性を提供して、トンネルのブローカーを仮想のIPv6ISPと考えることができます。 現れているIPv6インターネットでは、ユーザがただ多くのトンネルのブローカーが1つを選ぶことができなければならないと予想されます。 トンネルのブローカーのリストは、ユーザが「最も近いところで」1、「最も安い」もの、またはいかなる他の1つも選ぶのを許容するために「よく知られている」ウェブページ(例えば、 http://www.ipv6.org の)で参照をつけられるべきです。
The tunnel broker model is based on the set of functional elements depicted in figure 1.
トンネルブローカーモデルは図1に表現された機能要素のセットに基づいています。
Durand, et al. Informational [Page 3] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[3ページ]のRFC3053IPv6はブローカー2001年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
+------+ /|トンネル| / |サーバ| / | | / +------+ +----------+ +------+/ +------+ |デュアルスタック| |トンネル| |トンネル| | ノード| <、-、--、>|ブローカー| <、-、--、>|サーバ| | (ユーザ) | | | | | +----------+ +------+\ +------+ | \ +------+ トンネルエンドポイントv\|トンネル| /\ +---+ \ |サーバ| || |DNS| \| | || +---+ +------+ || || トンネルエンドポイント|| /\ || || |+---------------------------+| +-----------------------------+ IPv4トンネルの上のIPv6
Figure 1: the Tunnel Broker model
図1: Tunnel Brokerモデル
2.1 Tunnel Broker (TB)
2.1 トンネルのブローカー(tb)
The TB is the place where the user connects to register and activate tunnels. The TB manages tunnel creation, modification and deletion on behalf of the user.
TBはユーザがトンネルを登録して、動かすために接続する場所です。 TBはユーザを代表してトンネル作成、変更、および削除を管理します。
For scalability reasons the tunnel broker can share the load of network side tunnel end-points among several tunnel servers. It sends configuration orders to the relevant tunnel server whenever a tunnel has to be created, modified or deleted. The TB may also register the user IPv6 address and name in the DNS.
スケーラビリティ理由で、トンネルのブローカーはいくつかのトンネルサーバの中でネットワークサイドトンネルエンドポイントの負荷を共有できます。 トンネルが作成されなければならないか、変更されなければならないか、または削除されなければならないときはいつも、それは関連トンネルサーバに構成注文を送ります。 また、TBはDNSのユーザIPv6アドレスと名前を登録するかもしれません。
A TB must be IPv4 addressable. It may also be IPv6 addressable, but this is not mandatory. Communications between the broker and the servers can take place either with IPv4 or IPv6.
TBはアドレス可能なIPv4であるに違いありません。 また、それはアドレス可能なIPv6であるかもしれませんが、これは義務的ではありません。 ブローカーとサーバとのコミュニケーションはIPv4かIPv6と共に行われることができます。
2.2 Tunnel server (TS)
2.2 トンネルサーバ(ts)
A TS is a dual-stack (IPv4 & IPv6) router connected to the global Internet. Upon receipt of a configuration order coming from the TB, it creates, modifies or deletes the server side of each tunnel. It may also maintain usage statistics for every active tunnel.
TSは世界的なインターネットに関連づけられたデュアルスタック(IPv4&IPv6)ルータです。 TBから来る構成注文を受け取り次第、それは、それぞれのトンネルのサーバ端を作成するか、変更するか、または削除します。 また、それはあらゆるアクティブなトンネルに用法統計を維持するかもしれません。
Durand, et al. Informational [Page 4] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[4ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
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.
Tunnel Brokerサービスのクライアントは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;
- それは最初に、実際のトンネルエンドポイントとしてネットワーク側で使用されるためにTunnel Serverを指定します(例えば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;
- それはトンネルのサーバ端を構成します。
Durand, et al. Informational [Page 5] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[5ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
- it notifies the relevant configuration information to the
client, including tunnel parameters and DNS names.
- それはトンネルパラメタとDNS名を含むクライアントに関連設定情報に通知します。
After the above configuration steps have been carried out (including the configuration of the client), the IPv6 over IPv4 tunnel between the client host/router and the selected TS is up and working, thus allowing the tunnel broker user to get access to the 6bone or any other IPv6 network the TS is connected to.
上の構成ステップが行われた(クライアントの構成を含んでいて)後に、クライアントホスト/ルータと選択されたTSの間のIPv4トンネルの上のIPv6は上がって働いています、その結果、トンネルブローカーのユーザがTSが接続される6boneかいかなる他のIPv6ネットワークにも近づく手段を得るのを許容します。
2.4 IPv6 address assignment
2.4 IPv6アドレス課題
The IPv6 addresses assigned to both sides of each tunnel must be global IPv6 addresses belonging to the IPv6 addressing space managed by the TB.
それぞれのトンネルの両側に割り当てられたIPv6アドレスはTBによって管理されたスペースを扱うIPv6に属すグローバルなIPv6アドレスであるに違いありません。
The lifetime of these IPv6 addresses should be relatively long and potentially longer than the lifetime of the IPv4 connection of the user. This is to allow the client to get semipermanent IPv6 addresses and associated DNS names even though it is connected to the Internet via a dial-up link and gets dynamically assigned IPv4 addresses through DHCP.
これらのIPv6アドレスの寿命は、比較的長くて、ユーザのIPv4接続の生涯より潜在的に長いはずです。 これで、ダイヤルアップリンクを通してインターネットに関連づけられて、DHCPを通してIPv4アドレスがダイナミックに割り当てられるようになりますが、クライアントは半永久のIPv6アドレスと関連DNS名を得ることになっていることができます。
2.5 Tunnel management
2.5 トンネル管理
Active tunnels consume precious resources on the tunnel servers in terms of memory and processing time. For this reason it is advisable to keep the number of unused tunnels as small as possible deploying a well designed tunnel management mechanism.
アクティブなトンネルはメモリと処理時間に関してトンネルサーバに関する貴重な資源を消費します。 この理由で、未使用のトンネルの数をできるだけ小さく保つのはよく設計されたトンネル管理メカニズムを配布するのにおいて賢明です。
Each IPv6 over IPv4 tunnel created by the TB should at least be assigned a lifetime and removed after its expiration unless an explicit lifetime extension request is submitted by the client.
明白な生涯拡大要求がクライアントによって提出されない場合、TBによって作成されたIPv4トンネルの上の各IPv6は少なくとも寿命が割り当てられて、満了の後に取り外されるべきです。
Obviously this is not an optimal solution especially for users accessing the Internet through short-lived and dynamically addressed IPv4 connections (e.g., dial-up links). In this case a newly established tunnel is likely to be used just for a short time and then never again, in that every time the user reconnects he gets a new IPv4 address and is therefore obliged either to set-up a new tunnel or to update the configuration of the previous one. In such a situation a more effective tunnel management may be achieved by having the TS periodically deliver to the TB IPv6 traffic and reachability statistics for every active tunnel. In this way, the TB can enforce a tunnel deletion after a period of inactivity without waiting for the expiration of the related lifetime which can be relatively longer (e.g., several days).
明らかに、これは特に短命でダイナミックに扱われたIPv4接続(例えば、ダイヤルアップリンク)でインターネットにアクセスするユーザの最適解ではありません。 この場合、新設されたトンネルは二度とまさしく短い間使用されそうにはありません、ユーザが再接続するときはいつも、彼が、新しいトンネルをセットアップするか、または前のものの構成をアップデートするのを新しいIPv4アドレスを得て、したがって、強いられます。 そのような状況で、TSをあらゆるアクティブなトンネルのために定期的にTB IPv6トラフィックと可到達性統計に配送させることによって、より効果的なトンネル管理は達成されるかもしれません。 このように、比較的長い場合がある関連する生涯(例えば、数日)の満了を待たないで、TBは不活発の期間の後にトンネル削除を実施できます。
Durand, et al. Informational [Page 6] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[6ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
Another solution may be to implement some kind of tunnel management protocol or keep-alive mechanism between the client and the TS (or between the client and the TB) so that each tunnel can be immediately released after the user disconnects (e.g., removing his tunnel end- point or tearing down his IPv4 connection to the Internet). The drawback of this policy mechanism is that it also requires a software upgrade on the client machine in order to add support for the ad-hoc keep-alive mechanism described above.
他の解決法は、ユーザが切断した(例えば、ポイントかインターネットとの彼のIPv4接続の下側への裂け目を終わらせて、彼のトンネルを取り外してください)後にすぐに各トンネルをリリースできるようにクライアントとTS(またはクライアントとTBの間で)の間である種のトンネル管理プロトコルを実装するか、またはメカニズムを生かすことであるかもしれません。 この方針メカニズムの欠点はまた、臨時のサポートが上で説明されたメカニズムを生かすと言い足すためにクライアントマシンの上でソフトウェアの更新を必要とするということです。
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アドレスを使用しますが、以前に割り当てられたIPv6アドレスを再利用するトンネルを作り直すようTSに命令することができました。 そのように、IPv4アドレスはダイナミックですが、クライアントはほとんど永久的な(静的な)IPv6アドレスを保存できました。 また、それは関連DNS名を保存するかもしれません。
2.6 Interactions between client, TB, TS and DNS
2.6 クライアントと、TBと、TSとDNSとの相互作用
As previously stated, the definition of a specific set of protocols and procedures to be used for the communication among the various entities in the Tunnel Broker architecture is outside of the scope of the present framework document. Nevertheless, in the reminder of this section some viable technical alternatives to support client-TB, TB-TS and TB-DNS interactions are briefly described in order to help future implementation efforts or standardization initiatives.
前述のように、特定のセットのコミュニケーションに様々な実体の中でTunnel Brokerアーキテクチャに使用されるべきプロトコルと手順の定義が現在のフレームワークドキュメントの範囲の外にあります。 それにもかかわらず、このセクションを思い出させるものでは、クライアント-TB、TB-TS、およびTB-DNSに相互作用をサポートするいくつかの実行可能な技術的な選択肢が、将来の実装取り組みか標準化イニシアチブを助けるために簡潔に説明されます。
The interaction between the TB and the user could be based on http. For example the user could provide the relevant configuration information (i.e., the IPv4 address of the client side of the tunnel, etc.) by just filling up some forms on a Web server running on the TB. As a result the server could respond with an html page stating that the server end-point of the tunnel is configured and displaying all the relevant tunnel information.
TBとユーザとの相互作用はhttpに基づくことができました。 例えば、ユーザは、TBの上で作業しながらただウェブサーバのいくつかのフォームを満たすことによって、関連設定情報(すなわち、トンネルのクライアント端の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
いくつかのオプションが、彼のデュアルスタック設備の構成にTunnel Brokerユーザを助けるために考えられるかもしれません。 最も簡単なオプションはTBがクライアントサイドトンネルエンドポイントの簡単なセットアップを達成するためにクライアントマシンにオフラインで実行されるためにただ個人化された起動と反-起動にスクリプトを準備できたということです。 これ
Durand, et al. Informational [Page 7] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[7ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
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.
上の説明された安全保障問題はトンネルパラメタをクライアントに提供するのにTBによって使用されるべき新しいMIMEを定義することによって上品に打ち勝っている(マルチパーパスインターネットメールエクステンション)内容タイプであるかもしれません(例えば、アプリケーション/トンネル)[4、5]。 この場合、この情報を処理して、実際にトンネルエンドポイントをセットアップするためにクライアントで走るひたむきなエージェントはユーザを代表しているに違いありません。 これは考える価値がある非常に魅力的なアプローチです。 新しいcontent typeの定義は特に、将来の臨時のドキュメントの対象であるかもしれません。
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.
いくつかのオプションが、また、ブローカーとTunnel Serversとの適切な相互作用を達成するために利用可能です。 このために例えばIPsecの上の1セットの簡単な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).
最終的に、Dynamic DNS Updateプロトコル[6]はTBによって制御された自動DNSアップデート(すなわち、DNSゾーンからAAAA、A6、およびPTR記録を加えるか、または削除するのがTunnel Brokerのためにユーザを予約した)に使用されるべきです。 簡単な代替手段はTBがダイナミックにTunnel Brokerユーザゾーン(例えば、broker.isp-name.com)に正式のDNSサーバに関するダイレクトで逆さのデータベースをアップデートする小さいRSHコマンドを使用するだろうことです。
2.7 Open issues
2.7 開いている問題
Real usage of the TB service may require the introduction of accounting/billing functions.
本当のTBサービスの用法は会計/課金機能の導入を必要とするかもしれません。
3. Known limitations
3. 知られている制限
This mechanism may not work if the user is using private IPv4 addresses behind a NAT box.
ユーザがNAT箱の後ろで個人的なIPv4アドレスを使用しているなら、このメカニズムは動作しないかもしれません。
4. Use of the tunnel broker concept in other areas
4. 他の領域でのトンネルブローカー概念の使用
The Tunnel Broker approach might be efficiently exploited also to automatically set-up and manage any other kind of tunnel, such as a multicast tunnel (e.g., used to interconnect multicast islands within the unicast Internet) or an IPsec tunnel.
Tunnel Brokerアプローチはまた、自動的にいかなる他の種類のトンネルもセットアップして、管理するのに効率的に利用されるかもしれません、マルチキャストトンネル(例えば、以前はユニキャストインターネットの中でよくマルチキャスト島とインタコネクトしていた)やIPsecトンネルのように。
Durand, et al. Informational [Page 8] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[8ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
Moreover, the idea of deploying a dedicated access-control server, like the TB, to securely authorize and assist users that want to gain access to an IPv6 network might prove useful also to enhance other transition mechanisms. For example it would be possible to exploit a similar approach within the 6to4 model to achieve easy relay discovery. This would make life easier for early 6to4 adopters but would also allow the ISPs to better control the usage of their 6to4 relay facilities (e.g., setting up appropriate usage policies).
そのうえ、しっかりとIPv6ネットワークへのアクセスを得たがっているユーザを権限を与えて、補助するためにTBのようなひたむきなアクセス制御サーバを配布するという考えは可能であるかもしれません。有用であることが分かります。また、他の変遷メカニズムを高めてください、例えば、簡単なリレー発見を達成するのに6to4モデルの中で同様のアプローチを利用するのは可能でしょう。 これで、早い6to4採用者のために暮らしにゆとりを持たせるでしょうが、また、ISPはそれらの6to4リレー施設の使用法をよりよく制御するでしょう(例えば、適切な用法方針をセットアップします)。
5. Security Considerations
5. セキュリティ問題
All the interactions between the functional elements of the proposed architecture need to be secured:
提案されたアーキテクチャの機能要素の間のすべての相互作用が、機密保護される必要があります:
- the interaction between the client and TB;
- クライアントとTBとの相互作用。
- the interaction between the TB and the Tunnel Server;
- TBとTunnel Serverとの相互作用。
- 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(Secure Socket Layer)[7]などの広く採用されたセキュリティ機能の攻略をダウンロードしました。また、これで、アクセスコントロールを実施するために簡単な「ユーザ名」と「パスワード」認証手順と、そして、既存のAAA施設(例えば、RADIUS)を当てにするのは可能になります。
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によって提供された、達成された実行しているスクリプトであるなら、ネットワーク・インターフェースを管理できるくらいの特権でこれらのスクリプトを作成しなければなりません、管理者/根の役割のように。 これは、危険である場合があり、Tunnel Brokerアプローチの早めの実装のためだけに考えられるべきです。 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
さらに、ダイアルアップユーザーがインターネットから以前にTBを通して確立されたトンネルを取りこわさないで切断するときはいつも、秘密性の損失は発生するかもしれません。 事実上、TSはそのユーザに扱われたIPv6トラフィックに彼の古いIPv4にトンネルを堀り続けます。
Durand, et al. Informational [Page 9] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[9ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
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.
その間そのIPv4アドレスがダイナミックに同じダイヤルアップISPの別の加入者に割り当てられたかもしれないという事実にかかわらずアドレス。 TBがすぐに切断しているユーザに向かってIPv6トラフィック推進を止めるのを許容しながら、あらゆるトンネルの上でセクション2.5でこのようにして概説された生きている生活費メカニズムを実装することによって、この問題を解決できるでしょう。
Finally TBs must implement protections against denial of service attacks which may occur whenever a malicious user exhausts all the resources available on the tunnels server by asking for a lot of tunnels to be established altogether. A possible protection against this attack could be achieved by administratively limiting the number of tunnels that a single user is allowed to set-up at the same time.
最終的にTBsは多くのトンネルが全体で確立されるように頼むことによってトンネルサーバで利用可能なすべてのリソースが悪意あるユーザーでくたくたになるときはいつも、起こるかもしれないサービス不能攻撃に対する保護を実装しなければなりません。 行政上シングルユーザーが同時にセットアップできるトンネルの数を制限することによって、この攻撃に対する可能な保護を達成できるでしょう。
6. Acknowledgments
6. 承認
Some of the ideas refining the tunnel broker model came from discussion with Perry Metzger and Marc Blanchet.
トンネルブローカーモデルを洗練する考えのいくつかがペリーメッツガーとマークBlanchetとの議論から来ました。
7. References
7. 参照
[1] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 1933, April 1996.
[1] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。
[2] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[2] 大工とB.とC.ユング、「明白なTunnelsのいないIPv4ドメインの上のIPv6のトランスミッション」、RFC2529、1999年3月。
[3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels", Work in Progress.
[3] 大工とB.とK.ムーア、「Explicit TunnelsのいないIPv4 Cloudsを通したIPv6 Domainsの接続」、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)は1つを分けます」。 1996年11月のインターネットメッセージ本体、RFC2045の形式。
[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を分けます」。 「メディアタイプ」、RFC2046、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アップデート)」、RFC2136(1997年4月)。
[7] Guttman, E., Leong, L. and G. Malkin, "Users' Security
Handbook", FYI 34, RFC 2504, February 1999.
[7]GuttmanとE.とLeongとL.とG.マルキン、「ユーザのセキュリティハンドブック」、FYI34、RFC2504、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、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
Durand, et al. Informational [Page 10] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[10ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
[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、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、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)について議定書の中で述べます」、RFC2575、1999年4月。
[11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
2137, April 1997.
[11] イーストレーク、1997年4月、D.、「安全なドメインネームシステムダイナミック・アップデート」RFC2137。
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
Durand, et al. Informational [Page 11] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[11ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
8. Authors' Addresses
8. 作者のアドレス
Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA
アラン・ジュランド太陽マイクロシステムズ、Inc901サンアントニオ道路MPK17-202パロアルト、カリフォルニア94303-4900米国
Phone: +1 650 786 7503 EMail: Alain.Durand@sun.com
以下に電話をしてください。 +1 7503年の650 786メール: 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.SwitchingとNetwork Services--274歳のG.ライス・ロモリで10148トリノイタリアをネットワークでつなぐこと。
Phone: +39 011 2285071 EMail: paolo.fasano@cselt.it
以下に電話をしてください。 +39 011 2285071 メール: paolo.fasano@cselt.it
Ivano Guardini CSELT S.p.A. Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy
イバノグァルディーニCSELT S.p.のA.SwitchingとNetwork Services--274歳のG.ライス・ロモリで10148トリノイタリアをネットワークでつなぐこと。
Phone: +39 011 2285424 EMail: ivano.guardini@cselt.it
以下に電話をしてください。 +39 011 2285424 メール: ivano.guardini@cselt.it
Domenico Lento TIM Business Unit Project Management via Orsini, 9 90100 Palermo Italy
オルシーニを通したドメニコLento TIM Business Unit Project Management、9 90100パレルモイタリア
Phone: +39 091 7583243 EMail: dlento@mail.tim.it
以下に電話をしてください。 +39 091 7583243 メール: dlento@mail.tim.it
Durand, et al. Informational [Page 12] RFC 3053 IPv6 Tunnel Broker January 2001
ジュランド、他 情報[12ページ]のRFC3053IPv6はブローカー2001年1月にトンネルを堀ります。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Durand, et al. Informational [Page 13]
ジュランド、他 情報[13ページ]
一覧
スポンサーリンク
