[要約] RFC 5572は、IPv6トンネルブローカーとトンネルセットアッププロトコル（TSP）に関する規格です。このRFCの目的は、IPv6トンネルのセットアップと管理を容易にするためのプロトコルを提供することです。
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)
トンネルセットアッププロトコル（TSP）を備えたIPv6トンネルブローカー
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）を備えたトンネルブローカーは、IPv4、IPv6、またはIPv4 NATトラバーサルのIPv4を介したIPv4、IPv6、またはUDPなど、IPv6やIPv4などのさまざまな内部プロトコルのトンネルの確立を可能にします。コントロールプロトコル（TSP）は、トンネルクライアントがトンネルをブローカーと交渉するために使用します。TSPを実装するモバイルノードは、IPv4とIPv6ネットワークの両方に、IPv4のみ、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.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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フレームワーク、プロトコルの詳細、および使用されるさまざまなプロファイルについて説明します。次に、さまざまな環境でのTSPの適用性について説明します。その一部は、V6OPSシナリオドキュメントで説明されています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、リクエストトンネルエンドポイントで小さなクライアントコードとして実装されています。もう1つのエンドポイントは、トンネルサービスをセットアップするサーバーです。TSPはXML [W3C.REC-XML-2004] TCPまたはUDPを介した基本メッセージを使用します。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
o 匿名を含むあらゆる種類の認証メカニズム（単純な認証とセキュリティレイヤー（SASL）[RFC4422]を介して）を使用して、ユーザーの認証
o Tunnel encapsulation:
o トンネルのカプセル化：
* IPv6 over IPv4 tunnels [RFC4213]
* IPv4オーバーIPv4トンネル[RFC4213]
* IPv4 over IPv6 tunnels [RFC2473]
* IPv4オーバーIPv6トンネル[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)
o IPエンドポイントアドレスのDNS登録（AAAA）
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
o 割り当てられたIPv6プレフィックスに基づく逆ツリーの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. the TSP client
1. TSPクライアント
2. the client tunnel endpoint
2. クライアントトンネルエンドポイント
3. the TSP server
3. TSPサーバー
4. the server tunnel endpoint
4. サーバートンネルエンドポイント
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はトンネルブローカーモデル[RFC3053]を形成します。ここで、3はトンネルブローカー、4はトンネルサーバーです（図1）。トンネルブローカーは、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がパスにあるかどうかを発見するためにも使用されます。この検出モードでは、クライアントはUDPを介してTSPメッセージを送信し、トンネルリクエスト情報（ソースIPv4アドレスなど）をTSPサーバーに含めます。TSPサーバーは、パケットのIPv4ソースアドレスをTSPメッセージのアドレスと比較します。それらが異なる場合、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チャネルにトンネルが確立されるため、TSPセッションとIPv6トラフィックの両方に同じNATアドレスポートマッピングが使用されます。TSPサーバーによってパスでIPv4 NATが検出されない場合、IPv4オーバーIPv4カプセル化が使用されます。
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は、IPv4トンネル、UDP-IPv4トンネルを介してIPv6を介してIPv6、およびIPv6トンネル上のIPv4をネゴシエートするために使用されます。IPv4オーバーIPv6トンネルは、TSP [DSTM]とともにデュアルスタック遷移メカニズム（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を実行するときにIPv4アドレスを変更する）、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.
o TSPによって確立されたトンネルは静的なトンネルであり、自動トンネルよりも安全な[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.
o 多くのカプセル化技術の1つの解決策：IPv4のIPv6、IPv6のIPv4、IPv4を超えるUDP上のIPv6。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-over-udp-over-ipv4トンネルカプセル化
v4v6: IPv4-over-IPv6 tunnel encapsulation
V4v6：IPv4-Over-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).
UDP/V4を介したTSPシグナル伝達を使用する必要があります。IPv4（V6UDPV4）トンネルを超えるUDP上のV6が要求される場合（たとえば、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フレームワークにより、一般的なルーティングカプセル化（GRE）を介したIPv6やIPv6を介したIPv6など、他のタイプのカプセル化が定義されることに注意してください。
TSP over TCP is sent over port number 3653 (IANA assigned). TSP data used during signaling is detailed in the next sections.
TSPを介した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
バージョン= 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
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を使用して広告されたメカニズムの1つを使用してサーバーに認証されます。認証が失敗した場合、サーバーはエラーメッセージを送信してセッションを閉じます。
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
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
Figure 11: Successful Anonymous Authentication
図11：成功した匿名認証
Digest-MD5 authentication with SASL follows [RFC2831]. Figure 12 shows a successful digest-MD5 SASL authentication.
SASLを使用したDigest-MD5認証は[RFC2831]に続きます。図12は、Digest-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
Figure 12: Successful Digest-MD5 Authentication
図12：Digest-MD5認証の成功
The base64-decoded version of the SASL exchange is:
SASL ExchangeのBase64-Decodedバージョンは次のとおりです。
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
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.
コマンドフェーズは、トンネルクライアントがトンネルリクエストまたはトンネルの更新をサーバーに送信する場所です。このフェーズでは、コマンドはXMLメッセージとして送信されます。最初の行は、次のXMLメッセージのサイズを示す「コンテンツ長」指令です。サーバーが応答を送信する場合、最初の行は「コンテンツレングス」ディレクティブ、2番目は返品コード、3つ目はXMLメッセージがあれば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
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
C:Content-length: 35 CR LF
<tunnel action="accept"></tunnel> 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の例は、匿名のV6UDPV4トンネルを要求するクライアントを示しています。これは、30秒ごとにキープアライブパケットが送信されることを示しています。トンネルブローカーは、トンネルパラメーターで応答し、キープアライブ期間の受け入れを示します（セクション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]が確立されます。クライアントノードでは、これはTSPクライアントが適切なOSコマンドまたはシステム呼び出しを呼び出すことによって達成されます。
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.
V6UDPV4トンネルが構成されている場合、TSPシグナル伝達中に使用される同じソース/宛先アドレスとポートを使用して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セッションがトンネルと同じUDPマッピングをNATで使用している場合、クライアントが新しい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-over-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-over-ipv4およびIPv6-over-udpトンネルの場合、キープアライブメッセージは、クライアントからトンネルサーバーに送信されたICMPV6エコー要求[RFC4443]です。ECHOメッセージのIPv6宛先アドレスは、TSPシグナル伝達中にトンネル応答で送信された「KeepAlive」要素のアドレスでなければなりません（セクション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]。これは、[0.75t -t]の範囲の間隔値を使用することによって達成されます。ここで、tはサーバーによって指定されたキープアリブ間隔です。
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'.
クライアントとサーバーは、アクション属性を使用してトンネルトークンを使用します。このプロファイルの有効なアクションは、「作成」、「削除」、「情報」、「受け入れる」、および「拒否」です。
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.
「サーバー」要素には、「アドレス」と「ルーター」の2つの要素が含まれています。これらの要素は、サーバーのトンネルエンドポイントを記述するために使用されます。「アドレス」要素は、サーバーのトンネルエンドポイントの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
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」に「[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：IPv6トンネル応答を超えるIPv4
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を介してIPv4を超えるIPv6とIPv4を介してIPv4を介してIPv4を介してIPv4を介してIPv6を介してIPv6を使用している場合、「V6anyv4」トンネルモードを使用して、NATの背後にあるかどうかを判断し、適切なトンネルカプセル化モードを送信することができます。応答の一部。クライアントは、リクエストで「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秒ごとにKeep-Alivesを送信することを要求することを通知します。その応答では、ブローカーはクライアントが接続したキープアリブ間隔を受け入れ、キープアライブパケットの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
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.
IPv4が優勢なプロバイダーネットワークでは、完全なIPv6ネイティブインフラストラクチャが構築される前に、トンネルインフラストラクチャを使用してIPv6サービスをエンタープライズ顧客に提供できます。制御された方法で展開を開始し、エンタープライズの顧客にプレフィックスを提供するために、TSPフレームワークが使用されます。TSPサーバーは、顧客にサービスを提供するために、コア、集約ポイント、または存在ポイント（POPS）にあることができます。IPv4オーバーIPv4カプセル化を使用できます。顧客がIPv4 NATの背後にいる場合、UDP-IPV4上のIPv6カプセル化を使用できます。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サービスをホーム/スモールオフィスの顧客に提供できます。Home/Small Officeなどの小さなネットワークには、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.
IPv4が支配的なエンタープライズネットワークでは、トンネル付きインフラストラクチャを使用して、完全なIPv6ネイティブインフラストラクチャが構築される前に、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]。TSPは、IPv6接続に必要なすべての情報の自動化がTSPで処理されるこのコンテキストで特に役立ちます：トンネルエンドポイントパラメーター、プレフィックス割り当て、DNS委任、およびルーティング。
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)
o IPv4カプセル化のIPv6の「V6V4」（IPv4プロトコル41を使用）
o "v6udpv4" for IPv6 in UDP in IPv4 encapsulation
o IPv4カプセル化のUDPにおけるIPv6の「V6UDPV4」
o "v6anyv4" for IPv6 in IPv4 or IPv6 in UDP in IPv4 encapsulation
o IPv4またはIPv4のIPv6のIPv6の「V6anyv4」
o "v4v6" for IPv4 in IPv6 encapsulation
o IPv6カプセル化におけるIPv4の「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は3653をTSPポート番号として割り当てました。
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の背後にある顧客は、多数の（プライベート）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に関する多くの以前のドキュメントのマージです。Octavio Medinaは、以前のドキュメント（IPv6のIPv4）に貢献しています。このドキュメントの改善と明確化に関するコメントについて、次の人々に感謝します：Pekka Savola、Alan Ford、Jeroen Massar、Jean-Francois Tremblay。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831] Leach、P。およびC. Newman、「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. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（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] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン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.、Paoli、J.、Sperberg-Mcqueen、C.、Bray、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] Bound、J.、Toutain、L。、およびJl。Richier、「デュアルスタックIPv6ドミナント遷移メカニズム」、2005年10月、進行中の作業。
[FJ93] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", Proceedings of ACM SIGCOMM, September 1993.
[FJ93] Floyd、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] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、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. van der Pol、「管理されていないネットワークのIPv6遷移メカニズムの評価」、RFC 3904、2004年9月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティ上の考慮事項」、RFC 3964、2004年12月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057] Bound、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] Stevens、R.、Fenner、B。、およびA. Rudoff、「Unix Networkプログラミング、第3版」、Addison Wesley ISBN 0-13-141155-1、2004。
<?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" >
<!ELEMENT server (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT broker (address+)>
<!ELEMENT router (prefix?,dns_server?)>
<!ELEMENT dns_server (address+)>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
<!ATTLIST address length CDATA "">
<!ELEMENT keepalive (address?)>
<!ATTLIST keepalive interval CDATA #REQUIRED>
]>
Figure 20: TSP DTD
図20：TSP DTD
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アドレス：同じIPv4アドレスエンドポイントを使用して、IPv6-Over-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
Marc Blanchet Viagenie 2600 Boul。ローリエ、スイート625ケベック、QC G1V 4W1カナダ
Phone: +1-418-656-9254
EMail: Marc.Blanchet@viagenie.ca
Florent Parent Beon Solutions Quebec, QC Canada
Florent Parent Beon Solutions Quebec、QC Canada
Phone: +1 418 265 7357
EMail: Florent.Parent@beon.ca