Independent Submission M. Blanchet
Request for Comments: 5572 Viagenie
Category: Experimental F. Parent
ISSN: 2070-1721 Beon Solutions
February 2010
IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
Abstract
抽象
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model.
トンネルセットアッププロトコル（TSP）とのトンネルブローカは、IPv6のまたはIPv4のような種々の内部プロトコルのトンネルの確立を可能にし、このようなIPv4のNATトラバーサルのIPv4上のIPv4、IPv6の、またはUDPのような様々な外プロトコルパケット、内部。制御プロトコル（TSP）は、ブローカとのトンネルを交渉するトンネルクライアントによって使用されます。 TSPを実装するモバイルノードは、IPv4のみにあるかどうか、IPv4とIPv6ネットワークの両方に接続することができ、NATの背後のIPv4、またはIPv6にのみ。トンネルブローカは、リモートトンネルサーバーにまたはそれ自体にトンネルを終了させることができます。この文書では、トンネルブローカーモデルのモデル内のTSPを説明しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5572.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5572で取得することができます。
IESG Note
IESG注意
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work.
このRFCの内容は、IETFによって考慮一度だったので、それが進行または公開されたIETF仕事で現在IETFの作業に似ていてもよいです。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................4
2. Description of the TSP Framework ................................4
2.1. NAT Discovery ..............................................6
2.2. Any Encapsulation ..........................................6
2.3. Mobility ...................................................6
3. Advantages of TSP ...............................................7
4. Protocol Description ............................................7
4.1. Terminology ................................................7
4.2. Topology ...................................................8
4.3. Overview ...................................................8
4.4. TSP Signaling ..............................................9
4.4.1. Signaling Transport .................................9
4.4.2. Authentication Phase ...............................11
4.4.3. Command and Response Phase .........................14
4.5. Tunnel Establishment ......................................16
4.5.1. IPv6-over-IPv4 Tunnels .............................16
4.5.2. IPv6-over-UDP Tunnels ..............................16
4.6. Tunnel Keep-Alive .........................................16
4.7. XML Messaging .............................................17
4.7.1. Tunnel .............................................17
4.7.2. Client Element .....................................18
4.7.3. Server Element .....................................19
4.7.4. Broker Element .....................................19
5. Tunnel Request Examples ........................................19
5.1. Host Tunnel Request and Reply .............................19
5.2. Router Tunnel Request with a /48 Prefix Delegation
and Reply .................................................20
5.3. IPv4 over IPv6 Tunnel Request .............................22
5.4. NAT Traversal Tunnel Request ..............................23
6. Applicability of TSP in Different Networks .....................24
6.1. Provider Networks with Enterprise Customers ...............24
6.2. Provider Networks with Home/Small Office Customers ........25
6.3. Enterprise Networks .......................................25
6.4. Wireless Networks .........................................25
6.5. Unmanaged Networks ........................................26
6.6. Mobile Hosts and Mobile Networks ..........................26
7. IANA Considerations ............................................26
8. Security Considerations ........................................27
9. Conclusion .....................................................27
10. Acknowledgements ..............................................27
11. References ....................................................28
11.1. Normative References .....................................28
11.2. Informative References ...................................28
Appendix A. The TSP DTD ..........................................30
Appendix B. Error Codes ..........................................31
This document first describes the TSP framework, the protocol details, and the different profiles used. It then describes the applicability of TSP in different environments, some of which were described in the v6ops scenario documents.
この文書では、最初のTSPフレームワーク、プロトコルの詳細、および使用される異なるプロファイルを記述する。その後v6opsシナリオ文書に記載されたそのうちのいくつかは、異なる環境でのTSPの適用性を、説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Tunnel Setup Protocol (TSP) is a signaling protocol to set up tunnel parameters between two tunnel endpoints. TSP is implemented as a tiny client code in the requesting tunnel endpoint. The other endpoint is the server that will set up the tunnel service. TSP uses XML [W3C.REC-xml-2004] basic messaging over TCP or UDP. The use of XML gives extensibility and easy option processing.
トンネルセットアッププロトコル（TSP）は、2つのトンネルエンドポイント間のトンネルパラメータを設定するためのシグナリングプロトコルです。 TSPは、要求トンネルのエンドポイントでの小さなクライアント・コードとして実装されます。他のエンドポイントは、トンネルサービスを設定するサーバです。 TSPは、TCPやUDP上のXML [W3C.REC-XML-2004]基本的なメッセージングを使用しています。 XMLの使用は、拡張性と容易なオプションの処理を提供します。
TSP negotiates tunnel parameters between the two tunnel endpoints. Parameters that are always negotiated are:
TSPは、2つのトンネルエンドポイント間のトンネルパラメータをネゴシエート。常にネゴシエーションされるパラメータは次のとおりです。
o Authentication of the users, using any kind of authentication mechanism (through Simple Authentication and Security Layer (SASL) [RFC4422]) including anonymous
匿名を含む（簡易認証セキュリティー層（SASL）[RFC4422]を介して）認証メカニズムのいずれかの種類を使用して、ユーザーのO認証、
o Tunnel encapsulation:
Oのトンネルカプセル化：
* IPv6 over IPv4 tunnels [RFC4213]
IPv4トンネル経由のIPv6 * [RFC4213]
* IPv4 over IPv6 tunnels [RFC2473]
IPv6トンネル経由のIPv4 * [RFC2473]
* IPv6 over UDP-IPv4 tunnels for NAT traversal
NATトラバーサルのためのUDP-IPv4トンネル経由のIPv6 *
o IP address assignment for the tunnel endpoints
トンネルエンドポイントO IPアドレスの割り当て
o DNS registration of the IP endpoint address (AAAA)
IPエンドポイントアドレス（AAAA）のOのDNS登録
Other tunnel parameters that may be negotiated are:
ネゴシエートされてもよい他のトンネルパラメータは次のとおりです。
o Tunnel keep-alive
Oトンネルキープアライブ
o IPv6 prefix assignment when the client is a router
クライアントがルータであるO IPv6プレフィックスの割り当て
o DNS delegation of the inverse tree, based on the IPv6 prefix assigned
割り当てられたIPv6プレフィックスに基づいて、逆ツリーのOのDNS委任、
o Routing protocols
Oルーティングプロトコル
The tunnel encapsulation can be explicitly specified by the client, or can be determined during the TSP exchange by the broker. The latter is used to detect the presence of NAT in the path and select IPv6 over UDP-IPv4 encapsulation.
トンネルカプセル化は、明示的にクライアントによって指定することができ、またはブローカーによってTSP交換中に決定することができます。後者は、パスにNATの存在を検出し、UDP-IPv4のカプセル化の上にIPv6を選択するために使用されます。
The TSP connection can be established between two nodes, where each node can control a tunnel endpoint.
TSPの接続は、各ノードがトンネルエンドポイントを制御することができる2つのノード間で確立することができます。
The nodes involved in the framework are:
フレームワークに関与するノードは、次のとおりです。
1,3, and 4 form the tunnel broker model [RFC3053], where 3 is the tunnel broker and 4 is the tunnel server (Figure 1). The tunnel broker may control one or many tunnel servers.
1,3、および4フォーム3は、トンネルブローカおよび4は、トンネルサーバ（図1）であるトンネルブローカーモデル[RFC3053]。トンネルブローカーは、1台のまたは多数のトンネルサーバを制御することができます。
In its simplest model, one node is the client configured as a tunnel endpoint (1 and 2 on the same node), and the second node is the server configured as the other tunnel endpoint (3 and 4 on the same node). This model is shown in Figure 2:
その最も単純なモデルでは、1つのノードがトンネルエンドポイント（同じノード上の1及び2）のように構成されたクライアントであり、第2のノードは、他のトンネル端点（同じノード上の3および4）のように構成されたサーバです。このモデルは、図2に示されています。
_______________
| TUNNEL BROKER |--> Databases (DNS)
| |
| TSP |
| SERVER |
|_______________|
| |
__________ | | ________
| | | | | |
| TSP |--[TSP]-- +---------| |
| CLIENT | | TUNNEL |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| SERVER |
|___________| | |
|________|
Figure 1: Tunnel Setup Protocol Used on Tunnel Broker Model
図1：トンネルブローカーモデルに使用されるトンネルセットアッププロトコル
___________ ________
| | | TSP |
| TSP |-----------[TSP]---------| SERVER |
| CLIENT | | |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| TUNNEL |
|___________| | SERVER |
|________|
Figure 2: Tunnel Setup Protocol Used on Tunnel Server Model
図2：トンネルサーバモデルに使用されるトンネルセットアッププロトコル
From the point of view of an operating system, TSP is implemented as a client application that is able to configure network parameters of the operating system.
オペレーティング・システムの観点から、TSPは、オペレーティング・システムのネットワークパラメータを設定することができるクライアント・アプリケーションとして実装されます。
TSP is also used to discover if a NAT is in the path. In this discovery mode, the client sends a TSP message over UDP, containing its tunnel request information (such as its source IPv4 address) to the TSP server. The TSP server compares the IPv4 source address of the packet with the address in the TSP message. If they differ, one or many IPv4 NATs are in the path.
TSPはまた、NATがパスである場合に発見するために使用されます。この発見モードでは、クライアントは、TSPサーバに（例えば、その送信元IPv4アドレスのような）そのトンネル要求情報を含む、UDP上TSPメッセージを送信します。 TSPサーバは、TSPメッセージ内のアドレスを持つパケットのIPv4ソースアドレスとを比較します。それらが異なる場合は、1つのまたは多くのIPv4 NATはパスです。
If an IPv4 NAT is discovered, then IPv6 over UDP-IPv4 tunnel encapsulation is selected. Once the TSP signaling is done, the tunnel is established over the same UDP channel used for TSP, so the same NAT address-port mapping is used for both the TSP session and the IPv6 traffic. If no IPv4 NAT is detected in the path by the TSP server, then IPv6 over IPv4 encapsulation is used.
IPv4のNATが発見された場合、UDP-IPv4トンネルカプセル化の上にIPv6が選択されています。 TSPシグナリングが完了すると、トンネルがTSPのために使用したのと同じUDPチャネルを介して確立されるので、同じNATアドレスポートマッピングはTSPセッションとIPv6トラフィックの両方のために使用されます。何のIPv4 NATがTSPサーバによってパスに検出されない場合、その後のIPv4カプセル化上のIPv6が使用されます。
A keep-alive mechanism is also included to keep the NAT mapping active.
キープアライブメカニズムはまた、アクティブなNATマッピングを維持するために含まれています。
The IPv4 NAT discovery builds the most effective tunnel for all cases, including in a dynamic situation where the client moves.
IPv4のNATの発見は、クライアントが動くダイナミックな状況に含めたすべてのケースのための最も効果的なトンネルを構築します。
TSP is used to negotiate IPv6 over IPv4 tunnels, IPv6 over UDP-IPv4 tunnels, and IPv4 over IPv6 tunnels. IPv4 over IPv6 tunnels is used in the Dual-Stack Transition Mechanism (DSTM) together with TSP [DSTM].
TSPは、IPv6トンネル経由のIPv4トンネル、UDP-IPv4トンネル経由のIPv6、とIPv4上でIPv6を交渉するために使用されます。 IPv6トンネル上のIPv4は、一緒になって[DSTM] TSPを有するデュアルスタック遷移メカニズム（DSTM）に使用されます。
When a node moves to a different IP network (i.e., change of its IPv4 address when doing IPv6 over IPv4 encapsulation), the TSP client reconnects automatically to the broker to re-establish the tunnel (keep-alive mechanism). On the IPv6 layer, if the client uses user authentication, the same IPv6 address and prefix are kept and re-established, even if the IPv4 address or tunnel encapsulation type changes.
異なるIPネットワークにノードが移動する（すなわち、そのIPv4アドレスの変更のIPv4カプセル化上のIPv6を行う）、TSPクライアントがトンネルを再確立するブローカーに自動的に再接続するとき（キープアライブ機構）。 IPv6の層の上にあっても、IPv4アドレスまたはトンネルカプセル化タイプが変更された場合、クライアントは、ユーザ認証を使用する場合、同一のIPv6アドレスとプレフィックスが維持され、再確立します。
o Tunnels established by TSP are static tunnels, which are more secure than automated tunnels [RFC3964]; no third-party relay required.
TSPによって確立Oトンネルは、自動トンネル[RFC3964]よりも安全である静的トンネルです。何のサードパーティ製のリレーは必要ありません。
o Stability of the IP address and prefix, enabling applications needing stable address to be deployed and used. For example, when tunneling IPv6, there is no dependency on the underlying IPv4 address.
O IPアドレスとプレフィックスの安定性は、安定したアドレスを必要とすることが可能なアプリケーションをデプロイして使用します。 IPv6をトンネリングする場合たとえば、基盤となるIPv4アドレスの依存性はありません。
o Prefix assignment supported. Can use provider address space.
Oプレフィックスの割り当てがサポートされています。プロバイダーのアドレス空間を使用することができます。
o Signaling protocol flexible and extensible (XML, SASL)
Oシグナリングプロトコル柔軟で拡張（XML、SASL）
o One solution to many encapsulation techniques: IPv6 in IPv4, IPv4 in IPv6, IPv6 over UDP over IPv4. Can be extended to other encapsulation types, such as IPv6 in IPv6.
IPv6のIPv4の、IPv4のIPv6の、IPv6でのUDP経由のIPv4以上：多くのカプセル化技術に対する一つの解決策O。このようIPv6ではIPv6などの他のカプセル化タイプに拡張することができます。
o Discovery of IPv4 NAT in the path, establishing the most optimized tunneling technique depending on the discovery.
Oパス内のIPv4 NATの発見は、発見に応じて、最も最適化されたトンネリング技術を確立します。
Tunnel Broker: In a tunnel broker model, the broker is taking charge of all communication between tunnel servers (TSs) and tunnel clients (TCs). Tunnel clients query brokers for a tunnel and the broker finds a suitable tunnel server, asks the tunnel server to set up the tunnel, and sends the tunnel information to the tunnel Client.
トンネルブローカ：トンネルブローカーモデルでは、ブローカはトンネルサーバ（TSS）とトンネルクライアント（TCS）との間のすべての通信を担当します。トンネルクライアントは、トンネルのブローカーを照会し、ブローカが、適切なトンネルサーバを見つけ、トンネルを設定するトンネルサーバを要求し、トンネルクライアントへのトンネル情報を送信します。
Tunnel Server: Tunnel servers are providing the specific tunnel service to a tunnel client. It can receive the tunnel request from a tunnel broker (as in the tunnel broker model) or directly from the tunnel client. The tunnel server is the tunnel endpoint.
トンネルサーバ：トンネルサーバーは、トンネルクライアントに特定のトンネルサービスを提供しています。これは、トンネルクライアントから直接（トンネルブローカーモデルのように）トンネルブローカーからのトンネルリクエストを受信またはすることができます。トンネルサーバは、トンネルエンドポイントです。
Tunnel Client: The tunnel client is the entity that needs a tunnel for a particular service or connectivity. A tunnel client can be either a host or a router. The tunnel client is the other tunnel endpoint.
トンネルクライアント：トンネルクライアントは、特定のサービスまたは接続用のトンネルを必要とするエンティティです。トンネルクライアントは、ホストまたはルータのいずれかになります。トンネルクライアントは、他のトンネルエンドポイントです。
v6v4: IPv6-over-IPv4 tunnel encapsulation
v6v4：IPv6-over-IPv4トンネルカプセル化
v6udpv4: IPv6-over-UDP-over-IPv4 tunnel encapsulation
v6udpv4：IPv6のオーバーUDPオーバーIPv4トンネルカプセル化
v4v6: IPv4-over-IPv6 tunnel encapsulation
v4v6：IPv4のオーバーIPv6トンネルカプセル化
The following diagrams describe typical TSP scenarios. The goal is to establish a tunnel between tunnel client and tunnel server.
以下の図は、典型的なTSPのシナリオについて説明します。目標は、トンネルクライアントとトンネルサーバー間のトンネルを確立することです。
The Tunnel Setup Protocol is initiated from a client node to a tunnel broker. The Tunnel Setup Protocol has three phases:
トンネルセットアッププロトコルは、トンネルブローカーへのクライアント・ノードから開始されます。トンネルセットアッププロトコルは、次の3つのフェーズがあります。
Authentication phase: The Authentication phase is when the tunnel broker/server advertises its capability to a tunnel client and when a tunnel client authenticate to the broker/server.
認証フェーズ：トンネルブローカー/サーバーがトンネルクライアントにその機能をアドバタイズするときやトンネルクライアントは、ブローカー/サーバーへの認証時に認証フェーズです。
Command phase: The command phase is where the client requests or updates a tunnel.
コマンドフェーズ：コマンドフェーズはどこクライアントの要求であるかトンネルを更新します。
Response phase: The response phase is where the tunnel client receives the request response from the tunnel broker/server, and the client accepts or rejects the tunnel offered.
応答フェーズ：トンネルクライアントはトンネルブローカ/サーバから要求応答を受信し、クライアントが提供トンネルを受け入れまたは拒否ここ応答フェーズがあります。
For each command sent by a tunnel client, there is an expected response from the server.
トンネルクライアントによって送信される各コマンドに対して、サーバから期待される応答があります。
After the response phase is completed, a tunnel is established as requested by the client. If requested, periodic keep-alive packets can be sent from the client to the server.
応答フェーズが完了した後、クライアントの要求に応じて、トンネルが確立されます。要求された場合は、定期的にキープアライブパケットは、クライアントからサーバに送信することができます。
tunnel tunnel
client broker
+| Send version +
||---------------------------------> ||
|| Send capabilities ||
||<--------------------------------- +| Authentication
|| SASL authentication || phase
||<--------------------------------> ||
TSP || Authentication OK ||
signaling||<--------------------------------- +
|| Tunnel request || Command
||---------------------------------> || phase
|| Tunnel response +
||<--------------------------------- || Response
|| Tunnel acknowledge || phase
||---------------------------------> +
+| |
|| Tunnel established |
Data ||===================================|
phase || |
+| (keep-alive) |
Figure 3: Tunnel Setup Protocol Exchange
図3：トンネルセットアッププロトコル交換
The following sections describe in detail the TSP and the different phases in the TSP signaling.
以下のセクションでは、詳細にTSPとTSPシグナル伝達の異なる位相を記述する。
TSP signaling can be transported over TCP or UDP, and over IPv4 or IPv6. The tunnel client selects the transport according to the tunnel encapsulation being requested. Figure 4 shows the transport used for TSP signaling with possible tunnel encapsulation requested.
TSPシグナリングは、TCPやUDP上、及びIPv4またはIPv6上で転送することができます。トンネルクライアントは、要求されるトンネルカプセル化に応じてトランスポートを選択します。図4は、TSPが要求可能トンネルカプセル化とシグナリングのために使用されるトランスポートを示します。
TSP signaling over UDP/v4 MUST be used if a v6 over UDP over IPv4 (v6udpv4) tunnel is to be requested (e.g., for NAT traversal).
IPv4の（v6udpv4）トンネルを介してUDP上V6が要求される場合UDP / V4を超えるシグナルTSP（例えば、NATトラバーサルのために）使用されなければなりません。
Tunnel
Encapsulation Valid Valid
Requested Transport Address family
------------------------------------------
v6anyv4 TCP UDP IPv4
v6v4 TCP UDP IPv4
v6udpv4 UDP IPv4
v4v6 TCP UDP IPv6
Figure 4: TSP Signaling Transport
図4：TSPシグナリング交通
Note that the TSP framework allows for other type of encapsulation to be defined, such as IPv6 over Generic Routing Encapsulation (GRE) or IPv6 over IPv6.
TSPのフレームワークは、IPv6を介し総称ルーティングカプセル化（GRE）またはIPv6上のIPv6として、定義されるカプセルの他のタイプを可能にすることに留意されたいです。
TSP over TCP is sent over port number 3653 (IANA assigned). TSP data used during signaling is detailed in the next sections.
TCP上のTSPは、ポート番号3653（IANAが割り当てられている）を介して送信されます。シグナリング中に使用されるTSPデータは、次のセクションで詳述されています。
+------+-----------+----------+
| IP | TCP | TSP data |
| | port 3653 | |
+------+-----------+----------+
where IP is IPv4 or IPv6
Figure 5: Tunnel Setup Protocol Packet Format (TCP)
図5：トンネルセットアッププロトコルパケットフォーマット（TCP）
While TCP provides the connection-oriented and reliable data delivery features required during the TSP signaling session, UDP does not offer any reliability. This reliability is added inside the TSP session as an extra header at the beginning of the UDP payload.
TCPは、TSPのシグナリングセッションの間に必要な接続指向と信頼性の高いデータ配信機能を提供しますが、UDPは、任意の信頼性を提供していません。この信頼性はUDPペイロードの先頭に余分なヘッダとしてTSPセッション内で添加されます。
+------+-----------+------------+----------+
| IPv4 | UDP | TSP header | TSP data |
| | port 3653 | | |
+------+-----------+------------+----------+
Figure 6: Tunnel Setup Protocol Packet Format (UDP)
図6：トンネルセットアッププロトコルパケットフォーマット（UDP）
The algorithm used to add reliability to TSP packets sent over UDP is described in Section 22.5 of [UNP].
UDPを介して送信されるTSPパケットに信頼性を追加するために使用されるアルゴリズムは[UNP]のセクション22.5に記載されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xF | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSP data |
...
Figure 7: TSP Header for Reliable UDP
図7：信頼性の高いUDPのためのTSPのヘッダー
The 4-bit field (0-3) is set to 0xF. This marker is used by the tunnel broker to identify a TSP signaling packet that is sent after an IPv6 over UDP is established. This is explained in Section 4.5.2
4ビットのフィールド（0-3）が0xFのに設定されています。このマーカーは、UDP上のIPv6が確立された後に送信されるTSPシグナリングパケットを識別するために、トンネルブローカによって使用されます。これは、4.5.2項で説明されています
Sequence Number: 28-bit field. Set by the tunnel client. Value is increased by one for every new packet sent to the tunnel broker. The return packet from the broker contains the unaltered sequence number.
シーケンス番号：28ビットのフィールド。トンネルクライアントによって設定されます。値は、トンネルブローカーに送信されたすべての新しいパケットのために1つずつ増加されます。ブローカーからの戻りパケットは変更されていないシーケンス番号が含まれています。
Timestamp: 32-bit field. Set by the tunnel client. Generated from the client local-time value. The return packet from the broker contains the unaltered timestamp.
タイムスタンプ：32ビットのフィールド。トンネルクライアントによって設定されます。クライアントのローカル・タイム値から生成されました。ブローカーからの戻りパケットは変更されていないタイムスタンプが含まれています。
TSP data: Same as in the TCP/v4 case. Content described in later sections.
TSPデータ：TCP / v4の場合と同じ。コンテンツは、後のセクションで説明しました。
The TSP client builds its UDP packet as described above and sends it to the tunnel broker. When the tunnel broker responds, the same values for the sequence number and timestamp MUST be sent back to the client. The TSP client can use the timestamp to determine the retransmission timeout (current time minus the packet timestamp). The client SHOULD retransmit the packet when the retransmission timeout is reached. The retransmitted packet MUST use the same sequence number as the original packet so that the server can detect duplicate packets. The client SHOULD use exponential backoff when retransmitting packets to avoid network congestion.
TSPクライアントは、上記のようにそのUDPパケットを構築し、トンネルブローカーに送信します。トンネルブローカーが応答すると、シーケンス番号とタイムスタンプと同じ値は、クライアントに送り返さなければなりません。 TSPクライアントは、再送タイムアウト（現在の時刻マイナスのパケットのタイムスタンプ）を決定するためにタイムスタンプを使用することができます。再送タイムアウトに達したときにクライアントがパケットを再送すべきです。サーバが重複したパケットを検出することができるように再送されたパケットは、元のパケットと同じシーケンス番号を使用しなければなりません。ネットワークの混雑を避けるために、パケットを再送信する場合、クライアントは、指数バックオフを使用すべきです。
The authentication phase has 3 steps:
認証フェーズは、3つのステップがあります。
o Client's protocol version identification o Server's capability advertisement
サーバーの能力広告O oクライアントのプロトコルバージョン識別
o Client authentication
oクライアント認証
When a TCP or UDP session is established to a tunnel broker, the tunnel client sends the current protocol version it is supporting. The version number syntax is:
TCPやUDPセッションがトンネルブローカーに確立されると、トンネルクライアントは、それがサポートしている現在のプロトコルバージョンを送信します。バージョン番号の構文は次のとおりです。
VERSION=2.0.0 CR LF
VERSION = 2.0.0 CR LF
Version 2.0.0 is the version number of this specification. Version 1.0.0 was defined in earlier documents.
バージョン2.0.0は、この仕様のバージョン番号です。バージョン1.0.0は、以前の文書で定義されました。
If the server doesn't support the protocol version, it sends an error message and closes the session. The server can optionally send a server list that may support the protocol version of the client.
サーバはプロトコルバージョンをサポートしていない場合は、エラーメッセージを送信し、セッションを終了します。サーバーは、必要に応じて、クライアントのプロトコルバージョンをサポートすることが可能で、サーバのリストを送信することができます。
Example of an unsupported client version (without a server list):
（サーバーリストなし）サポートされていないクライアントバージョンの例：
-- Successful TCP Connection --
C:VERSION=0.1 CR LF
S:302 Unsupported client version CR LF
-- Connection closed --
Figure 8: Example of Unsupported Client Version
図8：サポートされていないクライアントバージョンの例
Example of a version not supported (with a server list):
（サーバーリストで）サポートされていないバージョンの例：
-- Successful TCP Connection --
C:VERSION=1.1 CR LF
S:1302 Unsupported client version CR LF
<tunnel action="list" type="broker">
<broker>
<address type="ipv4">1.2.3.4</address>
</broker>
<broker>
<address type="dn">ts1.isp1.com</address>
</broker>
</tunnel>
-- Connection closed --
Figure 9: Example of Unsupported Client Version, with Server Redirection
図9：サポートされていないクライアントバージョンの例、サーバーリダイレクトで
If the server supports the version sent by the client, then the server sends a list of the capabilities supported for authentication and tunnels.
サーバがクライアントから送信されたバージョンをサポートしている場合、サーバーは認証やトンネルのためのサポート機能のリストを送信します。
CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN AUTH=DIGEST-MD5 CR LF
CAPABILITYトンネル= V6V4トンネル= V6UDPV4 AUTH =匿名AUTH = PLAIN AUTH = DIGEST-MD5 CR LF
Tunnel types must be registered with IANA and their profiles are defined in Section 7. Authentication is done using SASL [RFC4422]. Each authentication mechanism should be a registered SASL mechanism. Description of such mechanisms is not in the scope of this document.
トンネルタイプはIANAに登録されなければならず、そのプロファイルは、7認証をSASL [RFC4422]を使用して行われるセクションで定義されています。各認証機構は、登録されたSASL機構でなければなりません。そのようなメカニズムの説明は、このドキュメントの範囲内にありません。
The tunnel client can then choose to close the session if none of the capabilities fit its needs. If the tunnel client chooses to continue, it authenticates to the server using one of the advertised mechanisms using SASL. If the authentication fails, the server sends an error message and closes the session.
トンネルクライアントは、能力のどれもがそのニーズに適合しない場合は、セッションを終了することができます。トンネルクライアントが継続することを選択した場合、それはSASLを使用してアドバタイズメカニズムのいずれかを使用してサーバに認証を行います。認証が失敗した場合、サーバーはエラー・メッセージを送信し、セッションを終了します。
The example in Figure 10 shows a failed authentication where the tunnel client requests an anonymous authentication that is not supported by the server.
図10の例では、トンネルクライアントは、サーバによってサポートされていない匿名認証を要求する認証失敗を示します。
Note that linebreaks and indentation within a "C:" or "S:" are editorial and not part of the protocol.
「C：」または「S：」プロトコルの編集と一部ではない改行やインデント内ことに注意してください。
-- Successful TCP Connection -- C:VERSION=2.0.0 CR LF S:CAPABILITY TUNNEL=V6V4 AUTH=DIGEST-MD5 CR LF C:AUTHENTICATE ANONYMOUS CR LF S:300 Authentication failed CR LF
- 成功したTCPコネクション - C：VERSION = 2.0.0 CR LF S：CAPABILITY TUNNEL = V6V4 AUTH = DIGEST-MD5 CR LF C：匿名CR LF Sを認証：300認証CR LFが失敗しました
Figure 10: Example of Failed Authentication
図10：失敗した認証の例
Figure 11 shows a successful anonymous authentication.
図11は、成功した匿名認証を示しています。
-- Successful TCP Connection -- C:VERSION=2.0.0 CR LF S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN AUTH=DIGEST-MD5 CR LF C:AUTHENTICATE ANONYMOUS CR LF S:200 Success CR LF
- 成功したTCPコネクション - C：VERSION = 2.0.0 CR LF S：CAPABILITYトンネル= V6V4トンネル= V6UDPV4 AUTH =匿名AUTH = PLAIN AUTH = DIGEST-MD5 CR LF C：200成功CR LF：匿名CR LF Sを認証
Figure 11: Successful Anonymous Authentication
図11：成功した匿名認証
Digest-MD5 authentication with SASL follows [RFC2831]. Figure 12 shows a successful digest-MD5 SASL authentication.
SASLとダイジェスト-MD5認証は、[RFC2831]に従います。図12は、成功したダイジェスト-MD5 SASL認証を示しています。
-- Successful TCP Connection -- C:VERSION=2.0.0 CR LF S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS AUTH=PLAIN AUTH=DIGEST-MD5 CR LF C:AUTHENTICATE DIGEST-MD5 CR LF S:cmVhbG09aGV4b3Msbm9uY2U9MTExMzkwODk2OCxxb3A9YXV0aCxhbGdvcml0aG09bWQ 1LXNlc3MsY2hhcnNldD11dGY4 C:Y2hhcnNldD11dGY4LHVzZXJuYW1lPSJ1c2VybmFtZTEiLHJlYWxtPSJoZXhvcyIsbm9 uY2U9IjExMTM5MDg5NjgiLG5jPTAwMDAwMDAxLGNub25jZT0iMTExMzkyMzMxMSIsZG lnZXN0LXVyaT0idHNwL2hleG9zIixyZXNwb25zZT1mOGU0MmIzYzUwYzU5NzcxODUzZ jYyNzRmY2ZmZDFjYSxxb3A9YXV0aA== S:cnNwYXV0aD03MGQ1Y2FiYzkyMzU1NjhiZTM4MGJhMmM5MDczODFmZQ== S:200 Success CR LF
- 成功したTCPコネクション - C：VERSION = 2.0.0 CR LF S：CAPABILITYトンネル= V6V4トンネル= V6UDPV4 AUTH =匿名AUTH = PLAIN AUTH = DIGEST-MD5 CR LF C：DIGEST-MD5 CR LF Sを認証：cmVhbG09aGV4b3Msbm9uY2U9MTExMzkwODk2OCxxb3A9YXV0aCxhbGdvcml0aG09bWQ 1LXNlc3MsY2hhcnNldD11dGY4 C：Y2hhcnNldD11dGY4LHVzZXJuYW1lPSJ1c2VybmFtZTEiLHJlYWxtPSJoZXhvcyIsbm9 uY2U9IjExMTM5MDg5NjgiLG5jPTAwMDAwMDAxLGNub25jZT0iMTExMzkyMzMxMSIsZG lnZXN0LXVyaT0idHNwL2hleG9zIixyZXNwb25zZT1mOGU0MmIzYzUwYzU5NzcxODUzZ jYyNzRmY2ZmZDFjYSxxb3A9YXV0aA == S：cnNwYXV0aD03MGQ1Y2FiYzkyMzU1NjhiZTM4MGJhMmM5MDczODFmZQ == S：200成功CR LF
Figure 12: Successful Digest-MD5 Authentication
図12：成功ダイジェスト-MD5認証
The base64-decoded version of the SASL exchange is:
SASL交換のbase64でデコードされたバージョンです。
S:realm="hexos",nonce="1113908968",qop="auth",algorithm=md5-sess, charset=utf8 C:charset=utf8,username="username1",realm="hexos",nonce="1113908968", nc=00000001,cnonce="1113923311",digest-uri="tsp/hexos", response=f8e42b3c50c59771853f6274fcffd1ca,qop=auth S:rspauth=70d5cabc9235568be380ba2c907381fe
S：レルム= "hexos"、ノンス= "1113908968"、QOP = "認証"、アルゴリズム= MD5-SESの、文字セット= UTF8のC：文字セット= UTF8、ユーザ名= "USERNAME1"、レルム= "hexos"、ノンス=」 1113908968" 、NC = 00000001、cnonce = "1113923311"、ダイジェスト-URI = "TSP / hexos"、応答= f8e42b3c50c59771853f6274fcffd1ca、QOP = AUTH S：rspauth = 70d5cabc9235568be380ba2c907381fe
Once the authentication succeeds, the server sends a success return code and the protocol enters the Command phase.
認証が成功すると、サーバは成功のリターンコードを送信し、プロトコルは、コマンドフェーズに入ります。
The Command phase is where the tunnel client sends a tunnel request or a tunnel update to the server. In this phase, commands are sent as XML messages. The first line is a "Content-length" directive that indicates the size of the following XML message. When the server sends a response, the first line is the "Content-length" directive, the second is the return code, and third one is the XML message, if any. The "Content-length" is calculated from the first character of the return code line to the last character of the XML message, inclusively.
トンネルクライアントがサーバーへのトンネル要求またはトンネル更新を送信するwhereコマンドフェーズがあります。このフェーズでは、コマンドはXMLメッセージとして送信されます。最初の行は、次のXMLメッセージのサイズを示す「コンテンツ長」ディレクティブです。サーバが応答を送信すると、最初の行は、「コンテンツ長」指令で、第二は、戻りコードであり、そしてもしあれば3つ目は、XMLメッセージです。 「コンテンツ長は」包括的、XMLメッセージの最後の文字に戻りコード行の最初の文字から計算されます。
Spaces can be inserted freely.
スペースが自由に挿入することができます。
-- UDP session established --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=ANONYMOUS
AUTH=PLAIN AUTH=DIGEST-MD5 CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Success CR LF
C:Content-length: 205 CR LF <tunnel action="create" type="v6udpv4"> <client> <address type="ipv4">192.0.2.135</address> <keepalive interval="30"></keepalive> </client> </tunnel> CR LF
C：コンテンツ長：205 CR LF <トンネルアクション= "作成" タイプ= "v6udpv4"> <クライアント> <アドレスタイプは、= "はIPv4"> 192.0.2.135 </アドレス> <キープアライブ間隔= "30"> </キープアライブ> </クライアント> </トンネル> CR LF
S:Content-length: 501 CR LF 200 Success CR LF <tunnel action="info" type="v6udpv4" lifetime="604800"> <server> <address type="ipv4">192.0.2.115</address> <address type="ipv6"> 2001:db8:8000:0000:0000:0000:0000:38b2 </address> </server> <client> <address type="ipv4">192.0.2.135</address> <address type="ipv6"> 2001:db8:8000:0000:0000:0000:0000:38b3 </address> <keepalive interval="30"> <address type="ipv6"> 2001:db8:8000:0000:0000:0000:0000:38b2 </address> </keepalive> </client> </tunnel> CR LF
S：コンテンツ長：501 CR LF 200成功CR LF <トンネルアクション= "情報" タイプ= "v6udpv4" 寿命= "604800"> <サーバ> <アドレスタイプ= "のIPv4"> 192.0.2.115 </アドレス> <アドレスタイプ= "IPv6の"> 2001：DB8：8000：0000：0000：0000：0000：38b2 </アドレス> </サーバー> <クライアント> <アドレスタイプ= "IPv4の"> 192.0.2.135 </アドレス> <アドレスタイプ= "IPv6の"> 2001：DB8：8000：0000：0000：0000：0000：38b3 </アドレス> <キープアライブ間隔= "30"> <アドレスタイプ= "IPv6の"> 2001：DB8：0000：0000 8000 ：0000：0000：38b2 </アドレス> </キープアライブ> </クライアント> </トンネル> CR LF
C:Content-length: 35 CR LF <tunnel action="accept"></tunnel> CR LF
C：コンテンツ長：35 CR LF <トンネルアクション= "受諾"> </トンネル> CR LF
Figure 13: Example of a Command/Response Sequence
図13：コマンド/応答シーケンスの例
The example in Figure 13 shows a client requesting an anonymous v6udpv4 tunnel, indicating that a keep-alive packet will be sent every 30 seconds. The tunnel broker responds with the tunnel parameters and indicates its acceptance of the keep-alive period (Section 4.6). Finally, the client sends an accept message to the server.
図13の例では、キープアライブパケットが30秒ごとに送信されることを示し、匿名v6udpv4トンネルを要求するクライアントを示しています。トンネルブローカはトンネルパラメータで応答し、キープアライブ期間（セクション4.6）の受諾を示します。最後に、クライアントはサーバに受け入れメッセージを送信します。
Once the accept message has been sent, the server and client configure their tunnel endpoint based on the negotiated tunnel parameters.
受け入れメッセージが送信されると、サーバーとクライアントが交渉されたトンネルのパラメータに基づいて、そのトンネルエンドポイントを設定します。
Once the TSP signaling is complete, a tunnel can be established on the tunnel server and client node. If a v6v4 tunnel has been negotiated, then an IPv6-over-IPv4 tunnel [RFC4213] is established using the operating system tunneling interface. On the client node, this is accomplished by the TSP client calling the appropriate OS commands or system calls.
TSPシグナリングが完了すると、トンネルは、トンネルサーバーとクライアント・ノード上に確立することができます。 v6v4トンネルがネゴシエートされている場合、IPv6-over-IPv4トンネル[RFC4213]は、オペレーティングシステムのトンネルインタフェースを使用して確立されます。クライアント・ノードで、これは、適切なOSコマンドまたはシステムコールを呼び出しTSPクライアントによって達成されます。
If a v6udpv4 tunnel is configured, the same source/destination address and port used during the TSP signaling are used to configure the v6udpv4 tunnel. If a NAT is in the path between the TSP client and the tunnel broker, the TSP signaling session will have created a UDP state in the NAT. By reusing the same UDP socket parameters to transport IPv6, the traffic will flow across the NAT using the same state.
TSPシグナリング中に使用されるv6udpv4トンネルが設定されている場合、同じソース/宛先アドレスとポートv6udpv4トンネルを設定するために使用されます。 NATは、TSPクライアントとトンネルブローカーとの間のパスにある場合は、TSPのシグナリングセッションはNATでUDPの状態を作成しています。 IPv6を輸送する同じUDPソケットのパラメータを再利用することにより、トラフィックが同じ状態を使用してNAT越えて流れます。
+------+-----------+--------+
| IPv4 | UDP | IPv6 |
| hdr. | port 3653 | |
+------+-----------+--------+
Figure 14: IPv6 Transport over UDP
図14：UDP上でのIPv6交通
At any time, a client may re-establish a TSP signaling session. The client disconnects the current tunnel and starts a new TSP signaling session as described in Section 4.4.1.2. If a NAT is present and the new TSP session uses the same UDP mapping in the NAT as for the tunnel, the tunnel broker will need to disconnect the client tunnel before the client can establish a new TSP session.
任意の時点で、クライアントは、TSPシグナリングセッションを再確立することができます。クライアントは、現在のトンネルを切断し、セクション4.4.1.2に記載されるように新しいTSPシグナリングセッションを開始します。 NATが存在し、新しいTSPのセッションがトンネルのようNATで同じUDPマッピングを使用している場合、クライアントは新しいTSPセッションを確立する前に、トンネルブローカーがクライアントのトンネルを切断する必要があります。
A TSP client may select to send periodic keep-alive messages to the server in order to maintain its tunnel connectivity. This allows the client to detect network changes and enable automatic tunnel re-establishment. In the case of IPv6-over-UDP tunnels, periodic keep-alive messages can help refresh the connection state in a NAT if such a device is in the tunnel path.
TSPクライアントは、そのトンネル接続性を維持するために、サーバーに定期的にキープアライブメッセージを送信するように選択することができます。これは、クライアントがネットワークの変更を検出し、自動トンネルの再確立を可能にすることを可能にします。 IPv6のオーバーUDPトンネルの場合には、定期的にキープアライブメッセージは、そのようなデバイスがトンネルパスにある場合、NATで接続状態をリフレッシュすることができます。
For IPv6-over-IPv4 and IPv6-over-UDP tunnels, the keep-alive message is an ICMPv6 echo request [RFC4443] sent from the client to the tunnel server. The IPv6 destination address of the echo message MUST be the address from the 'keepalive' element sent in the tunnel response during the TSP signaling (Section 4.4.3). The echo message is sent over the configured tunnel.
IPv6のオーバーIPv4およびIPv6オーバーUDPトンネルため、キープ・アライブ・メッセージは、トンネルクライアントからサーバに送信されるICMPv6エコー要求[RFC4443]です。エコーメッセージのIPv6宛先アドレスは、TSPシグナリング（セクション4.4.3）の間のトンネル応答で送信された「キープアライブ」要素からアドレスでなければなりません。エコーメッセージは、設定されたトンネルを介して送信されます。
The tunnel server responds to the ICMPv6 echo requests and can keep track of which tunnel is active. Any client traffic can also be used to verify if the tunnel is active. This can be used by the broker to disconnect tunnels that are no longer in use.
トンネルサーバは、ICMPv6のエコー要求に応答し、トンネルがアクティブであるかを追跡することができます。任意のクライアントトラフィックもトンネルがアクティブであるかどうかを確認するために使用することができます。これは、使用されなくなったトンネルを切断するブローカーで使用することができます。
The broker can send a different keep-alive interval from the value specified in the client request. The client MUST conform to the broker-specified keep-alive interval. The client SHOULD apply a random "jitter" value to avoid synchronization of keep-alive messages from many clients to the server [FJ93]. This is achieved by using an interval value in the range of [0.75T - T], where T is the keep-alive interval specified by the server.
ブローカーは、クライアントの要求で指定された値と異なるキープアライブ間隔を送信することができます。クライアントは、ブローカーが指定したキープアライブ間隔に従わなければなりません。クライアントがサーバー[FJ93]に多くのクライアントからのキープアライブメッセージの同期化を避けるために、ランダムな「ジッター」の値を適用する必要があります。 Tは、サーバによって指定されたキープアライブ間隔であり、 - これは、[T 0.75T]の範囲内の間隔値を使用することによって達成されます。
This section describes the XML messaging used in the TSP signaling during the command and response phase. The XML elements and attributes are listed in the DTD (Appendix A).
このセクションでは、コマンドと応答の位相の間にTSPシグナリングで使用されるXMLメッセージについて説明します。 XMLの要素と属性は、DTD（付録A）に記載されています。
The client and server use the tunnel token with an action attribute. Valid actions for this profile are: 'create', 'delete', 'info', 'accept', and 'reject'.
クライアントとサーバは、action属性でトンネルトークンを使用しています。このプロファイルの有効なアクションは次のとおりです。「拒否」、「作成」「削除」、「情報を」、「受け入れる」、と。
create: action used to request a new tunnel or update an existing tunnel. Sent by the tunnel client.
作成：新しいトンネルを要求したり、既存のトンネルを更新するために使用されるアクションを。トンネルクライアントによって送信されます。
delete: action used to remove an existing tunnel from the server. Sent by the tunnel client.
削除：サーバーから既存のトンネルを削除するために使用されるアクションを。トンネルクライアントによって送信されます。
info: action used to request current properties of an existing tunnel. This action is also used by the tunnel broker to send tunnel parameters following a client 'create' action.
情報：既存のトンネルの現在のプロパティを要求するために使用されるアクション。このアクションは、クライアント「を作成」アクション、次のトンネルパラメータを送信するためにトンネルブローカーによって使用されています。
accept: action used by the client to acknowledge the server that the tunnel parameters are accepted. The client will establish a tunnel.
受け入れ：トンネルパラメータが受け入れているサーバーを確認するために、クライアントによって使用されるアクションを。クライアントがトンネルを確立します。
reject: action used by the client to signal the server that the tunnel parameters offered are rejected and no tunnel will be established.
拒否：クライアントによって使用されるアクションが拒否され提供トンネルパラメータなしのトンネルが確立されるサーバーを合図します。
The tunnel 'lifetime' attribute is set by the tunnel broker and specifies the lifetime of the tunnel in minutes. The lifetime is an administratively set value. When a tunnel lifetime has expired, it is disconnected on the tunnel server.
トンネル「寿命」属性は、トンネルブローカーによって設定され、数分でトンネルの寿命を指定しています。寿命は管理上設定された値です。トンネル寿命が満了している場合は、トンネルサーバ上で切断されています。
The 'tunnel' message contains three elements:
「トンネル」メッセージは、3つの要素が含まれています。
<client>: Client's information
<クライアント>：クライアントの情報
<server>: Server's information
<サーバー>：サーバーの情報
<broker>: List of other servers
<ブローカー>：他のサーバーの一覧
The 'client' element contains 3 sub-elements: 'address', 'router', and 'keepalive'. These elements are used to describe the client request and will be used by the server to create the appropriate tunnel. The client element is the only element sent by a client.
「アドレス」、「ルータ」、および「キープアライブ」：「クライアント」要素は3つのサブ要素が含まれています。これらの要素は、クライアント・リクエストを記述するために使用され、適切なトンネルを作成するためにサーバによって使用されるであろう。クライアント要素は、クライアントから送信された唯一の要素です。
The 'address' element is used to identify the client IP endpoint of the tunnel. When tunneling over IPv4, the client MUST send only its IPv4 address to the server. When tunneling over IPv6, the client MUST only send its IPv6 address to the server.
「アドレス」要素は、トンネルのクライアントIPエンドポイントを識別するために使用されます。とき、トンネルがIPv4上で、クライアントがサーバにのみそのIPv4アドレスを送らなければなりません。 IPv6を介した場合、トンネル、クライアントはサーバーへのIPv6アドレスを送らなければなりません。
The broker then returns the assigned IPv6 or IPv4 address endpoint and domain name inside the 'client' element when the tunnel is created or updated. If supported by the broker, the 'client' element MAY contain the registered DNS name for the address endpoint assigned to the client.
トンネルが作成または更新されたときのブローカーは、「クライアント」要素の内側に割り当てられたIPv6またはIPv4アドレスエンドポイントとドメイン名を返します。ブローカーでサポートされている場合は、「クライアント」の要素は、クライアントに割り当てられたアドレスエンドポイントの登録DNS名を含むかもしれません。
Optionally, a client MAY send a 'router' element to ask for a prefix delegation.
必要に応じて、クライアントは、プレフィックス委任を求めるために「ルータの要素を送信することができます。
Optionally, a client MAY send a 'keepalive' element that contains the keep-alive time interval requested by the client.
必要に応じて、クライアントは、クライアントから要求されたキープアライブ時間間隔が含まれている「キープアライブ」要素を送信することができます。
The 'server' element contains two elements: 'address' and 'router'. These elements are used to describe the server's tunnel endpoint. The 'address' element is used to provide both IPv4 and IPv6 addresses of the server's tunnel endpoint, while the 'router' element provides information for the routing method chosen by the client.
「アドレス」と「ルータ」：「サーバー」要素には、二つの要素が含まれています。これらの要素は、サーバのトンネルのエンドポイントを記述するために使用されています。 「ルータ」要素は、クライアントによって選択されたルーティング方法のための情報を提供しながら、「アドレス」要素は、サーバのトンネルエンドポイントのIPv4およびIPv6アドレスの両方を提供するために使用されます。
The 'broker' element is used by a tunnel broker to provide an alternate list of brokers to a client in the case where the server is not able to provide the requested tunnel.
「ブローカ」要素は、サーバーが要求トンネルを提供できない場合に、クライアントにブローカの代替リストを提供するために、トンネルブローカによって使用されます。
The 'broker' element contains an 'address' element or a series of 'address' elements.
「ブローカー」要素は、「アドレス」要素や「アドレス」要素のシリーズが含まれています。
This section presents multiple examples of requests.
このセクションでは、要求の複数の例を示します。
A simple tunnel request consist of a 'tunnel' element that contains only an 'address' element. The tunnel action is 'create', specifying a 'v6v4' tunnel encapsulation type. The response sent by the tunnel broker is an 'info' action. Note that the registered Fully-Qualified Domain Name (FQDN) of the assigned client IPv6 address is also returned to the tunnel client.
単純なトンネル要求は、「アドレス」要素が含まれている「トンネル」の要素から成ります。トンネル動作は「v6v4」トンネルカプセル化タイプを指定し、「作成」です。トンネルブローカーによって送信された応答は、「情報」のアクションです。割り当てられたクライアントのIPv6アドレスの登録された完全修飾ドメイン名（FQDN）は、トンネルクライアントに返されることに留意されたいです。
-- Successful TCP Connection --
C:VERSION=2.0.0 CR LF
S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:200 Authentication successful CR LF
C:Content-length: 123 CR LF
<tunnel action="create" type="v6v4">
<client>
<address type="ipv4">1.1.1.1</address>
</client>
</tunnel> CR LF
S: Content-length: 234 CR LF
200 OK CR LF
<tunnel action="info" type="v6v4" lifetime="1440">
<server>
<address type="ipv4">192.0.2.114</address>
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0000
</address>
</server>
<client>
<address type="ipv4">1.1.1.1</address>
<address type="ipv6">
2001:db8:c18:ffff::0000:0000:0000:0001
</address>
<address type="dn">userid.domain</address>
</client>
</tunnel> CR LF
C: Content-length: 35 CR LF
<tunnel action="accept"></tunnel> CR LF
Figure 15: Simple Tunnel Request Made by a Client
図15：クライアントによるシンプルなトンネルリクエスト
A tunnel request with a prefix consists of a 'tunnel' element that contains an 'address' element and a 'router' element. The 'router' element also contains the 'dns_server' element that is used to request a DNS delegation of the assigned IPv6 prefix. The 'dns_server' element lists the IP address of the DNS servers to be registered for the reverse-mapping zone.
接頭辞トンネル要求は「アドレス」要素と「ルータ」要素が含まれている「トンネル」の要素から構成されています。 「ルータの要素は、割り当てられたIPv6プレフィックスのDNS委任を要求するために使用される「dns_server」要素が含まれています。 「dns_server」要素は、逆マッピングゾーンに登録するDNSサーバのIPアドレスが表示されます。
Tunnel request with prefix and static routes.
プレフィックスとスタティックルートとトンネル要求。
C: Content-length: 234 CR LF <tunnel action="create" type="v6v4"> <client> <address type="ipv4">192.0.2.9</address> <router> <prefix length="48"/> <dns_server> <address type="ipv4">192.0.2.5</address> <address type="ipv4">192.0.2.4</address> <address type="ipv6">2001:db8::1</address> </dns_server> </router> </client> </tunnel> CR LF S: Content-length: 234 CR LF 200 OK CR LF <tunnel action="info" type="v6v4" lifetime="1440"> <server> <address type="ipv4">192.0.2.114</address> <address type="ipv6"> 2001:db8:c18:ffff:0000:0000:0000:0000 </address> </server> <client> <address type="ipv4">192.0.2.9</address> <address type="ipv6"> 2001:db8:c18:ffff::0000:0000:0000:0001 </address> <address type="dn">userid.domain</address> <router> <prefix length="48">2001:db8:c18:1234::</prefix> <dns_server> <address type="ipv4">192.0.2.5</address> <address type="ipv4">192.0.2.4</address> <address type="ipv6">2001:db8::1</address> </dns_server> </router> </client> </tunnel> CR LF C: Content-length: 35 CR LF <tunnel action="accept"></tunnel> CR LF
C：コンテンツ長：234 CR LF <トンネルアクション= "作成" タイプ= "v6v4"> <クライアント> <アドレスタイプ= "のIPv4"> 192.0.2.9 </ ADDRESS> <ルータ> <プレフィックス長= "48" /> <dns_server> <アドレスタイプ= "IPv4の"> 192.0.2.5 </アドレス> <アドレスタイプ= "IPv4の"> 192.0.2.4 </アドレス> <アドレスタイプ= "IPv6の"> 2001：DB8 :: 1 <アドレス/> </ dns_server> </ルータ> </クライアント> </トンネル> CR LF S：コンテンツ長：234 CR LF 200 OK CR LF <トンネルアクション= "情報" タイプ= "v6v4" 寿命= "1440 "> <サーバー> <アドレスタイプ=" IPv4の "> 192.0.2.114 </アドレス> <アドレスタイプ=" IPv6" の> 2001：DB8：C18：FFFF：0000：0000：0000：0000 </アドレス> </サーバー> <クライアント> <アドレスタイプ= "IPv4の"> 192.0.2.9 </アドレス> <アドレスタイプ= "IPv6の"> 2001：DB8：C18：0000：0000：0001 </アドレス> <アドレスタイプ0000 :: FFFF = "DN"> userid.domain </アドレス> <ルータ> <プレフィックス長= "48"> 2001：DB8：C18：1234 :: </プレフィックス> <dns_server> <アドレスタイプ= "IPv4の"> 192.0.2.5 </アドレス> <アドレスタイプ= "IPv4の"> 192.0.2.4 </アドレス> <アドレスタイプ= "IPv6の"> 2001：DB8 :: 1 </アドレス> </ dns_server> </ルータ> </クライアント> < /トンネル> CR LF C：コンテンツ長：35 CR LF <トンネルアクション= "受諾"> </トンネル> CR LF
Figure 16: Tunnel Request with Prefix and DNS Delegation
図16：プレフィックスとDNS委任とトンネルリクエスト
This is similar to the previous 'create' action, but with the tunnel type is set to 'v4v6'.
これは、以前の「作成」動作と同様であるが、トンネル型と「v4v6」に設定されています。
-- Successful TCP Connection --
C:VERSION=1.0 CR LF
S:CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
CR LF
C:AUTHENTICATE ANONYMOUS CR LF
S:OK Authentication successful CR LF
C:Content-length: 228 CR LF
<tunnel action="create" type="v4v6">
<client>
<address type="ipv6">
2001:db8:0c18:ffff:0000:0000:0000:0001
</address>
</client>
</tunnel> CR LF
Figure 17: Simple Tunnel Request Made by a Client
図17：クライアントによるシンプルなトンネルリクエスト
If the allocation request is accepted, the broker will acknowledge the allocation to the client by sending a 'tunnel' element with the attribute 'action' set to 'info', 'type' set to 'v4v6' and the 'lifetime' attribute set to the period of validity or lease time of the allocation. The 'tunnel' element contains 'server' and 'client' elements.
割り当て要求が受け入れられた場合、ブローカーは「v4v6」と「生涯」属性セットに設定「情報」、「タイプ」に設定された属性「アクション」で「トンネル」の要素を送信することによって、クライアントへの割り当てを確認します配分の妥当性や、リースの期間に。 「トンネル」要素は、「サーバ」および「クライアント」の要素が含まれています。
S: Content-length: 370 CR LF
200 OK CR LF
<tunnel action="info" type="v4v6" lifetime="1440">
<server>
<address type="ipv4" length="30">
192.0.2.2
</address>
<address type="ipv6">
2001:db8:c18:ffff:0000:0000:0000:0002
</address>
</server>
<client>
<address type="ipv4" length="30">
192.0.2.1
</address>
<address type="ipv6">
2001:db8:c18:ffff::0000:0000:0000:0001
</address>
</client>
</tunnel> CR LF
Figure 18: IPv4 over IPv6 Tunnel Response
図18：IPv4からIPv6トンネル対応オーバー
In DSTM [DSTM] terminology, the DSTM server is the TSP broker and the Tunnel Endpoint (TEP) is the tunnel server.
DSTM [DSTM]用語では、DSTMサーバーがTSPブローカとトンネルエンドポイント（TEP）は、トンネルサーバです。
When a client is capable of both IPv6 over IPv4 and IPv6 over UDP over IPv4 encapsulation, it can request the broker, by using the "v6anyv4" tunnel mode, to determine if it is behind a NAT and to send the appropriate tunnel encapsulation mode as part of the response. The client can also explicitly request an IPv6 over UDP over IPv4 tunnel by specifying "v6udpv4" in its request.
クライアントがIPv4カプセル化オーバーUDP上のIPv4とIPv6の上IPv6の両方が可能である場合、それはNATの背後にあるかどうかを決定するために、「v6anyv4」トンネルモードを使用して、ブローカーを要求することができ、適宜、トンネルカプセル化モードを送信します応答の一部。また、クライアントは、明示的にその要求に「v6udpv4」を指定することにより、IPv4トンネル上でUDP上でのIPv6を要求することができます。
In the following example, the client informs the broker that it requests to send keep-alives every 30 seconds. In its response, the broker accepted the client-suggested keep-alive interval, and the IPv6 destination address for the keep-alive packets is specified.
次の例では、クライアントはキープアライブを30秒ごとに送信するために要求ブローカーに通知します。その応答では、ブローカーは、クライアント・提案キープアライブ間隔を受け入れ、およびキープアライブパケットのIPv6宛先アドレスが指定されています。
C:VERSION=2.0.0 CR LF S:CAPABILITY TUNNEL=V6V4 TUNNEL=V6UDPV4 AUTH=DIGEST-MD5 CR LF C:AUTHENTICATE ... CR LF S:200 Authentication successful CR LF C:Content-length: ... CR LF <tunnel action="create" type="v6anyv4"> <client> <address type="ipv4">10.1.1.1</address> <keepalive interval="30"></keepalive> </client> </tunnel> CR LF S: Content-length: ... CR LF 200 OK CR LF <tunnel action="info" type="v6udpv4" lifetime="1440"> <server> <address type="ipv4">192.0.2.114</address> <address type="ipv6"> 2001:db8:c18:ffff:0000:0000:0000:0002 </address> </server> <client> <address type="ipv4">10.1.1.1</address> <address type="ipv6"> 2001:db8:c18:ffff::0000:0000:0000:0003 </address> <keepalive interval="30"> <address type="ipv6"> 2001:db8:c18:ffff:0000:0000:0000:0002 </address> </keepalive> </client> </tunnel> CR LF
C：VERSION = 2.0.0 CR LF S：CAPABILITYトンネル= V6V4トンネル= V6UDPV4 AUTH = DIGEST-MD5 CR LF C：... CR LF Sを認証：200認証成功CR LF C：のContent-Length：... CR LF <トンネルアクション= "作成" タイプ= "v6anyv4"> <クライアント> <アドレスタイプ= "のIPv4"> 10.1.1.1 </アドレス> <キープアライブ間隔= "30"> </キープアライブ> </クライアント> </トンネル> CR LF S：コンテンツの長さ：... CR LF 200 OK CR LF <トンネルアクション= "情報" タイプ= "v6udpv4" 生涯= "1440"> <サーバー> <アドレスタイプ= "IPv4の"> 192.0。 2.114 </アドレス> <アドレスタイプ= "IPv6の"> 2001：DB8：C18：FFFF：0000：0000：0000：0002 </アドレス> </サーバー> <クライアント> <アドレスタイプ= "IPv4の"> 10.1.1.1 </アドレス> <アドレスタイプ= "のIPv6"> 2001：DB8：C18：FFFF 0000 :: 0000：0000：0003 </アドレス> <キープアライブ間隔= "30"> <アドレスタイプ= "のIPv6"> 2001： DB8：C18：FFFF：0000：0000：0000：0002 </アドレス> </キープアライブ> </クライアント> </トンネル> CR LF
Figure 19: Tunnel Request Using v6anyv4 Mode
図19：v6anyv4モードを使用したトンネルリクエスト
This section describes the applicability of TSP in different networks.
このセクションでは、異なるネットワークにおけるTSPの適用可能性を説明しています。
In a provider network where IPv4 is dominant, a tunneled infrastructure can be used to provide IPv6 services to the enterprise customers, before a full IPv6 native infrastructure is built. In order to start deploying in a controlled manner and to give enterprise customers a prefix, the TSP framework is used. The TSP server can be in the core, in the aggregation points or in the Points of Presence (PoPs) to offer the service to the customers. IPv6 over IPv4 encapsulation can be used. If the customers are behind an IPv4 NAT, then IPv6 over UDP-IPv4 encapsulation can be used. TSP can be used in combination with other techniques.
完全なIPv6ネイティブインフラが構築される前に、IPv4のが支配的であるプロバイダ・ネットワークでは、トンネリングされたインフラストラクチャは、企業顧客へのIPv6サービスを提供するために使用することができます。制御された方法で展開を開始し、企業顧客に接頭語を与えるために、TSPのフレームワークが使用されます。 TSPサーバは、顧客にサービスを提供するために集約ポイントやプレゼンスのポイント（のPoP）で、コアにすることができます。 IPv4のカプセル化の上にIPv6が使用することができます。顧客はIPv4のNATの背後にある場合には、IPv6のUDP-IPv4のオーバーカプセル化を使用することができます。 TSPは、他の技術と組み合わせて使用することができます。
In a provider network where IPv4 is dominant, a tunneled infrastructure can be used to provide IPv6 services to the home/small office customers, before a full IPv6 native infrastructure is built. The small networks such as Home/Small offices have a non-upgradable gateway with NAT. TSP with NAT traversal is used to offer IPv6 connectivity and a prefix to the internal network.
IPv4のが支配的であるプロバイダ・ネットワークでは、トンネリングされたインフラストラクチャは完全なIPv6ネイティブインフラが構築される前に、ホーム/小規模オフィスのお客様にIPv6サービスを提供するために使用することができます。こうしたホーム/小規模オフィスなどの小規模なネットワークでは、NAT非アップグレードゲートウェイを持っています。 NATトラバーサルとのTSPは、IPv6接続と内部ネットワークへの接頭辞を提供するために使用されます。
Automation of the prefix assignment and DNS delegation, done by TSP, is a very important feature for a provider in order to substantially decrease support costs. The provider can use the same Authentication, Authorization, and Accounting (AAA) database that is used to authenticate the IPv4 broadband users. Customers can deploy home IPv6 networks without any intervention of the provider support people.
TSPによって行わプレフィックスの割り当てとDNS委任の自動化は、実質的にサポートコストを低減するために、プロバイダにとって非常に重要な機能です。プロバイダは、IPv4ブロードバンドユーザーを認証するために使用されるのと同じ認証、許可、アカウンティング（AAA）データベースを使用することができます。お客様は、プロバイダのサポート人々の任意の介入なしに、家庭用のIPv6ネットワークを展開することができます。
With the NAT discovery function of TSP, providers can use the same TSP infrastructure for both NAT and non-NAT parts of the network.
TSPのNATディスカバリ機能により、プロバイダは、NAT、ネットワークの非NAT部品の両方に同じTSPインフラストラクチャを使用することができます。
In an enterprise network where IPv4 is dominant, a tunneled infrastructure can be used to provide IPv6 services to the IPv6 islands (hosts or networks) inside the enterprise, before a full IPv6 native infrastructure is built [RFC4057]. TSP can be used to give IPv6 connectivity, prefix, and routing for the islands. This gives the enterprise a fully controlled deployment of IPv6 while maintaining automation and permanence of the IPv6 assignments to the islands.
完全なIPv6ネイティブインフラが構築される前のIPv4が支配的な企業ネットワークにおいて、トンネル化インフラストラクチャは、企業内部のIPv6アイランド（ホストまたはネットワーク）にIPv6サービスを提供するために使用することができる[RFC4057]。 TSPは、島のためのIPv6接続、接頭辞、およびルーティングを与えるために使用することができます。島へのIPv6割り当ての自動化と耐久性を維持しながら、これは、企業にIPv6のの完全に制御された展開を提供します。
In a wireless network where IPv4 is dominant, hosts and networks move and change IPv4 address. TSP enables the automatic re-establishment of the tunnel when the IPv4 address changes.
IPv4のが支配的な無線ネットワークでは、ホストおよびネットワークはIPv4アドレスを移動して変更します。 TSPは、トンネルのIPv4アドレスの変更を自動的に再確立を可能にします。
In a wireless network where IPv6 is dominant, hosts and networks move. TSP enables the automatic re-establishment of the IPv4 over IPv6 tunnel.
IPv6が支配的である無線ネットワークでは、ホストとネットワークが移動します。 TSPは、IPv6トンネル上のIPv4の自動再確立を可能にします。
An unmanaged network is where no network manager or staff is available to configure network devices [RFC3904]. TSP is particularly useful in this context where automation of all necessary information for the IPv6 connectivity is handled by TSP: tunnel endpoint parameters, prefix assignment, DNS delegation, and routing.
何のネットワーク管理者やスタッフがネットワークデバイス[RFC3904]を設定するために利用できない場所を非管理ネットワークがあります。トンネルエンドポイントパラメータ、プレフィックス割り当て、DNS委任、およびルーティング：TSPは、このIPv6接続のために必要なすべての情報の自動化は、TSPによって処理される状況において特に有用です。
An unmanaged network may (or may not) be behind a NAT. With the NAT discovery function, TSP works automatically in both cases.
非管理ネットワークは（またはしない場合があります）NATの背後にあります。 NATディスカバリ機能により、TSPは両方のケースで自動的に動作します。
Mobile hosts are common and used. Laptops moving from wireless, wired in an office, home, etc., are examples. They often have IPv4 connectivity, but not necessarily IPv6. The TSP framework enables the mobile hosts to have IPv6 connectivity wherever they are, by having the TSP client send updated information of the new environment to the TSP server, when a change occurs. Together with NAT discovery and traversal, the mobile host can always be IPv6 connected wherever it is.
モバイルホストは共通して使用されています。などオフィスで有線無線、自宅から移動するラップトップは、例です。彼らは多くの場合、IPv4接続を持っているが、必ずしもそうではないのIPv6。 TSPフレームワークはどこにいても変更が発生した場合に、TSPクライアントは、TSPサーバーに新しい環境の更新情報を送信することによって、IPv6の接続を持っているモバイルホストを可能にします。それはどこに一緒にNATトラバーサル発見として、モバイルホストは常にIPv6は接続することができます。
Mobile here means only the change of IPv4 address. Mobile-IP mechanisms and fast hand-off take care of additional constraints in mobile environments.
ここでは、モバイルは、IPv4アドレスの変更のみを意味します。モバイルIPの仕組みと高速ハンドオフは、モバイル環境で追加の制約の世話をします。
Mobile networks share the applicability of the mobile hosts. Moreover, in the TSP framework, they also keep their prefix assignment and can control the routing. NAT discovery can also be used.
モバイルネットワークは、モバイルホストの適用性を共有します。また、TSPの枠組みの中で、彼らはまた、それらのプレフィックスの割り当てを維持し、ルーティングを制御することができます。 NATの発見にも使用することができます。
A tunnel type registry has been created by IANA. The following strings are defined in this document:
トンネルタイプレジストリは、IANAによって作成されました。以下の文字列が、この文書で定義されています。
o "v6v4" for IPv6 in IPv4 encapsulation (using IPv4 protocol 41)
（IPv4プロトコル41を使用して）のIPv4カプセル化におけるIPv6のO "v6v4"
o "v6udpv4" for IPv6 in UDP in IPv4 encapsulation
IPv4のカプセル化ではUDPでのIPv6のO "v6udpv4"
o "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4 encapsulation
IPv4のカプセル化ではUDPでのIPv4またはIPv6でIPv6のO "v6anyv4"
o "v4v6" for IPv4 in IPv6 encapsulation
IPv6のカプセル化におけるIPv4のO "v4v6"
Registration of a new tunnel type can be obtained on a first come, first served policy [RFC5226]. A new registration should provide a point of contact, the tunnel type string, and a brief description on the applicability.
新しいトンネルタイプの登録は来る最初に得ることができ、最初のポリシー[RFC5226]を務めました。新規登録は接触のポイント、トンネル型の文字列、および適用性について簡単な説明を提供する必要があります。
IANA assigned 3653 as the TSP port number.
IANAは、TSPのポート番号として3653を割り当てられました。
Authentication of the TSP session uses the SASL [RFC4422] framework, where the authentication mechanism is negotiated between the client and the server. The framework uses the level of authentication needed for securing the session, based on the policies.
TSPセッションの認証は、認証メカニズムは、クライアントとサーバの間でネゴシエートされたSASL [RFC4422]のフレームワークを使用します。フレームワークは、ポリシーに基づいて、セッションを確保するために必要な認証レベルを使用しています。
Static tunnels are created when the TSP negotiation is terminated. Static tunnels are not open gateways and exhibit less security issues than automated tunnels. Static IPv6 in IPv4 tunnel security considerations are described in [RFC4213].
TSPの交渉が終了したときに、静的トンネルが作成されます。静的トンネルはゲートウェイを開いて、自動化されたトンネル未満のセキュリティ問題を示されていません。 IPv4の静的IPv6のトンネルのセキュリティ問題は、[RFC4213]に記載されています。
In order to help ensure that the traffic is traceable to its correct source network, a tunnel server implementation should allow ingress filtering on the user tunnel [RFC3704].
トラフィックは、その正しいソースネットワークにトレーサブルであることを確保するために、トンネルサーバの実装は、ユーザトンネル[RFC3704]にイングレスフィルタリングを可能にすべきです。
A customer A behind a NAT can use a large number of (private) IPv4 addresses and/or source ports and request multiple v6udpv4 tunnels. That would quickly saturate the tunnel server capacity. The tunnel broker implementation should offer a way to throttle and limit the number of tunnel established to the same IPv4 address.
NATの背後にある顧客Aは、（プライベート）のIPv4アドレス及び/又は送信元ポートの多数を使用して複数v6udpv4トンネルを要求することができます。それはすぐにトンネルサーバの容量を飽和さでしょう。トンネルブローカーの実装では、同じIPv4アドレスに確立されたトンネルの数を絞ると制限する方法を提供すべきです。
The Tunnel Setup Protocol (TSP) is applicable in many environments, such as: providers, enterprises, wireless, unmanaged networks, mobile hosts, and networks. TSP gives the two tunnel endpoints the ability to negotiate tunnel parameters, as well as prefix assignment, DNS delegation and routing in an authenticated session. It also provides an IPv4 NAT discovery function by using the most effective encapsulation. It also supports the IPv4 mobility of the nodes.
プロバイダ、企業、ワイヤレス、管理されていないネットワーク、モバイルホスト、およびネットワーク：トンネルセットアッププロトコル（TSP）は次のような多くの環境で適用されます。 TSPは、2つのトンネルエンドポイントに認証されたセッションにトンネルパラメータ、ならびに接頭割り当て、DNS委任およびルーティングを交渉する能力を与えます。また、最も効果的なカプセル化を使用することで、IPv4 NAT発見機能を提供します。また、ノードのIPv4のモビリティをサポートしています。
This document is the merge of many previous documents about TSP. Octavio Medina has contributed to an earlier document (IPv4 in IPv6). Thanks to the following people for comments on improving and clarifying this document: Pekka Savola, Alan Ford, Jeroen Massar, and Jean-Francois Tremblay.
この文書では、TSPについての多くの以前の文書のマージです。オクタビオメディナは、以前の文書（IPv6ではIPv4）のに貢献してきました。このドキュメントを改善し、明確化についてのコメントについて以下の方々に感謝します：ペッカSavola、アラン・フォード、イェルーンMassar、とジャン・フランソワ・トレンブレイ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]コンタ、A.、およびS.デアリング、 "IPv6の仕様の汎用パケットトンネリング"、RFC 2473、1998年12月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831]リーチ、P.とC.ニューマン、 "SASLメカニズムとしてダイジェスト認証を使用する"、RFC 2831、2000年5月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[W3C.REC-xml-2004] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.
[W3C.REC-XML-2004] Yergeau、F.、パオリ、J.、Sperberg-マックィーン、C.、ブレイ、T.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第3版）"、 W3C REC REC-XML-20040204、2004年2月。
[DSTM] Bound, J., Toutain, L., and JL. Richier, "Dual Stack IPv6 Dominant Transition Mechanism", Work in Progress, October 2005.
[DSTM]、J.、Toutain、L.、およびJLに結合しました。リシエ、「デュアルスタックIPv6の支配的な移行メカニズム」、進歩、2005年10月に作業。
[FJ93] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", Proceedings of ACM SIGCOMM, September 1993.
[FJ93]フロイド、S.およびV. Jacobsonの "周期的ルーティングメッセージの同期"、ACM SIGCOMM、1993年9月の議事。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004.
[RFC3904]のHuitema、C.、Austeinと、R.、Satapati、S.、およびR.のファンデルポール、 "非管理ネットワークのIPv6移行メカニズムの評価"、RFC 3904、2004年9月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P.とC.パテル、 "6to4のためのセキュリティの考慮事項"、RFC 3964、2004年12月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057]バウンド、J.、 "IPv6のエンタープライズネットワークシナリオ"、RFC 4057、2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[UNP] Stevens, R., Fenner, B., and A. Rudoff, "Unix Network Programming, 3rd edition", Addison Wesley ISBN 0-13-141155-1, 2004.
[UNP]スティーブンス、R.、フェナー、B.、およびA. Rudoff、 "UNIXネットワークプログラミング第3版"、アディソンウェズリーISBN 0-13-141155-1、2004。
Appendix A. The TSP DTD
付録A.ザ・TSP DTD
<?xml version="1.0"?> <!DOCTYPE tunnel [ <!ELEMENT tunnel (server?,client?,broker?)> <!ATTLIST tunnel action (create|delete|info|accept|reject) #REQUIRED > <!ATTLIST tunnel type (v6v4|v4v6|v6anyv4|v6udpv4) #REQUIRED > <!ATTLIST tunnel lifetime CDATA "1440" >
<？xml version = "1.0"？> <DOCTYPEトンネル[<ELEMENTトンネル（サーバー、クライアント、ブローカー？？？）> <ATTLISTトンネルアクション（作成|情報| |受け入れる|削除拒否）！！！#REQUIRED> < ！ATTLISTトンネルタイプ（v6v4 | v4v6 | v6anyv4 | v6udpv4）！#REQUIRED> <ATTLISTトンネル寿命CDATA "1440">
<!ELEMENT server (address+,router?)>
<！ELEMENTサーバー（アドレス+、ルータ？）>
<!ELEMENT client (address+,router?)>
<！ELEMENTクライアント（アドレス+、ルータ？）>
<!ELEMENT broker (address+)>
<！ELEMENTブローカー（アドレス）>
<!ELEMENT router (prefix?,dns_server?)>
<！ELEMENTルータ（接頭辞？、dns_server？）>
<!ELEMENT dns_server (address+)>
<！ELEMENT DNSサーバ（アドレス）>
<!ELEMENT prefix (#PCDATA)> <!ATTLIST prefix length CDATA #REQUIRED>
<！ELEMENTプレフィックス（#PCDATA）> <！ATTLISTプレフィックス長CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)> <!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED> <!ATTLIST address length CDATA "">
<ELEMENTアドレス（#PCDATA）> <！ATTLISTアドレスタイプ！（IPv4の|のIPv6 | DN）#REQUIRED> <！ATTLISTアドレス長CDATA "">
<!ELEMENT keepalive (address?)> <!ATTLIST keepalive interval CDATA #REQUIRED> ]>
<！ELEMENTキープアライブ（アドレス？）> <！ATTLISTキープアライブ間隔CDATA #REQUIRED>]>
Figure 20: TSP DTD
図20：TSP DTD
Appendix B. Error Codes
付録B.エラーコード
Error codes are sent as a numeric value followed by a text message describing the code, similar to SMTP. The codes are sent from the broker to the client. The currently defined error codes are shown below. Upon receiving an error, the client will display the appropriate message to the user.
エラーコードは、SMTPのようなコードを記述したテキストメッセージ、続いて数値として送信されます。コードは、クライアントにブローカーから送信されます。現在定義されているエラーコードを以下に示します。エラーを受信すると、クライアントは、ユーザーに適切なメッセージを表示します。
New error messages may be defined in the future. For interoperability purpose, the error code range to use should be from 300 to 599.
新しいエラーメッセージは、将来的に定義されてもよいです。相互運用性の目的のために、使用するエラー・コードの範囲は、300から599までであるべきです。
The reply code 200 is used to inform the client that an action successfully completed. For example, this reply code is used in response to an authentication request and a tunnel creation request.
応答コード200は、アクションが正常に完了し、クライアントに通知するために使用されています。例えば、この応答コードが認証要求とトンネル生成要求に応じて使用されます。
The server may redirect the client to another broker. The details on how these brokers are known or discovered is beyond the scope of this document. When a list of tunnel brokers follows the error code as a referral service, then 1000 is added to the error code.
サーバが別のブローカにクライアントをリダイレクトすることがあります。これらのブローカーが知られているか、または発見される方法の詳細は、このドキュメントの範囲を超えています。トンネルブローカーのリストが紹介サービスとしてエラーコードを以下のとき、1000はエラーコードに追加されます。
The predefined values are:
事前に定義された値は次のとおりです。
200 Success: Successful operation.
200の成功：成功した操作。
300 Authentication failed: Invalid userid, password, or authentication mechanism.
300認証に失敗しました：無効なユーザーID、パスワード、または認証メカニズムを。
301 No more tunnels available: The server has reached its capacity limit.
利用できる301これ以上のトンネル：サーバは、その容量の上限に達しました。
302 Unsupported client version: The client version is not supported by the server.
302サポートされていないクライアントバージョン：クライアントのバージョンはサーバーでサポートされていません。
303 Unsupported tunnel type: The server does not provide the requested tunnel type.
303サポートされていないトンネル型：サーバは、要求されたトンネルタイプを提供しません。
310 Server side error: Undefined server error.
310サーバー側のエラー：未定義のサーバーエラー。
500 Invalid request format or specified length: The received request has invalid syntax or is truncated.
500不正なリクエスト形式または指定された長さ：受信した要求が無効な構文を有するか、または切り捨てられます。
501 Invalid IPv4 address: The IPv4 address specified by the client is invalid.
501無効なIPv4アドレス：クライアントが指定したIPv4アドレスが無効です。
502 Invalid IPv6 address: The IPv6 address specified by the client is invalid.
502無効なIPv6アドレス：クライアントが指定したIPv6アドレスが無効です。
506 IPv4 address already used for existing tunnel: An IPv6-over-IPv4 tunnel already exists using the same IPv4 address endpoints.
既存のトンネルに使用される506個のIPv4アドレス：IPv6-over-IPv4トンネルが既に同一のIPv4アドレスのエンドポイントを使用して存在します。
507 Requested prefix length cannot be assigned: The requested prefix length cannot be allocated on the server.
507要求されたプレフィックス長を割り当てることができません：要求されたプレフィックス長は、サーバー上で割り当てることができません。
521 Request already in progress: The client tunnel request is being processed by the server. Temporary error.
既に進行中の521要求：クライアントトンネル要求はサーバによって処理されています。一時的なエラーが発生しました。
530 Server too busy: Request cannot be processed, insufficient resources. Temporary error.
530サーバービジー状態：リクエストは、リソース不足を処理することはできません。一時的なエラーが発生しました。
Authors' Addresses
著者のアドレス
Marc Blanchet Viagenie 2600 boul. Laurier, suite 625 Quebec, QC G1V 4W1 Canada
マルク・ブランシェViagénie2600 BOUL。ローリエ、スイート625ケベック、QC G1V 4W1カナダ
Phone: +1-418-656-9254 EMail: Marc.Blanchet@viagenie.ca
電話：+ 1-418-656-9254 Eメール：Marc.Blanchet@viagenie.ca
Florent Parent Beon Solutions Quebec, QC Canada
フロラン親BEONソリューションケベック、QCカナダ
Phone: +1 418 265 7357 EMail: Florent.Parent@beon.ca
電話：+1 418 265 7357 Eメール：Florent.Parent@beon.ca