Independent Submission M. Blanchet
Request for Comments: 5572 Viagenie
Category: Experimental F. Parent
ISSN: 2070-1721 Beon Solutions
February 2010
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上的UDP）内建立各种内部协议（例如IPv6或IPv4）的隧道，以进行IPv4 NAT穿越。隧道客户端使用控制协议（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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
IETF曾考虑过本RFC的内容，因此它可能类似于当前正在进行的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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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）是在两个隧道端点之间设置隧道参数的信令协议。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在两个隧道端点之间协商隧道参数。始终协商的参数包括：
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隧道上的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)
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，并选择IPv6 over UDP-IPv4封装。
The TSP connection can be established between two nodes, where each node can control a tunnel endpoint.
TSP连接可以在两个节点之间建立，其中每个节点可以控制一个隧道端点。
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）。隧道代理可以控制一个或多个隧道服务器。
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和2），第二个节点是配置为另一个隧道端点的服务器（同一节点上的3和4）。该模型如图2所示：
_______________
| TUNNEL BROKER |--> Databases (DNS)
| |
| TSP |
| SERVER |
|_______________|
| |
__________ | | ________
| | | | | |
| TSP |--[TSP]-- +---------| |
| CLIENT | | TUNNEL |--[NETWORK]--
[HOST]--| |<==[CONFIGURED TUNNEL]==>| SERVER |
|___________| | |
|________|
_______________
| 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 |
|________|
___________ ________
| | | 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服务器发送一条TSP消息，其中包含其隧道请求信息（例如其源IPv4地址）。TSP服务器将数据包的IPv4源地址与TSP消息中的地址进行比较。如果它们不同，则路径中有一个或多个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通信。如果TSP服务器在路径中未检测到IPv4 NAT，则使用IPv6 over 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隧道协商IPv6、通过UDP-IPv4隧道协商IPv6以及通过IPv6隧道协商IPv4。IPv4 over 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
当节点移动到不同的IP网络时（即，在通过IPv4封装IPv6时更改其IPv4地址），TSP客户端将自动重新连接到代理以重新建立隧道
(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.
（保持活力机制）。在IPv6层，如果客户端使用用户身份验证，则会保留并重新建立相同的IPv6地址和前缀，即使IPv4地址或隧道封装类型发生更改。
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 多种封装技术的一种解决方案：IPv4中的IPv6、IPv6中的IPv4、IPv4中的IPv6 over UDP over IPv4。可以扩展到其他封装类型，例如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:
隧道设置协议从客户端节点启动到隧道代理。隧道设置协议有三个阶段：
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) |
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).
如果要请求IPv6 over UDP over IPv4（v6udpv4）隧道（例如NAT穿越），则必须使用UDP/v4上的TSP信令。
Tunnel
Encapsulation Valid Valid
Requested Transport Address family
------------------------------------------
v6anyv4 TCP UDP IPv4
v6v4 TCP UDP IPv4
v6udpv4 UDP IPv4
v4v6 TCP UDP IPv6
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 over Generic Routing封装（GRE）或IPv6 over 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
+------+-----------+----------+
| 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不提供任何可靠性。这种可靠性在TSP会话中作为UDP有效负载开头的额外头添加。
+------+-----------+------------+----------+
| IPv4 | UDP | TSP header | TSP data |
| | port 3653 | | |
+------+-----------+------------+----------+
+------+-----------+------------+----------+
| 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].
[UNP]第22.5节描述了用于增加通过UDP发送的TSP数据包可靠性的算法。
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 |
...
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 客户端的协议版本标识
o Server's capability advertisement
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 --
-- 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 --
-- 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 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的公布机制向服务器进行身份验证。如果身份验证失败，服务器将发送错误消息并关闭会话。
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
-- 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
-- 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
-- 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解码版本为：
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: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消息发送。第一行是“Content length”指令，指示以下XML消息的大小。当服务器发送响应时，第一行是“Content length”指令，第二行是返回代码，第三行是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
-- 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: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
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
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
图13中的示例显示了一个请求匿名v6udpv4隧道的客户机，它指示将每隔30秒发送一个保持活动的数据包。隧道代理用隧道进行响应
parameters and indicates its acceptance of the keep-alive period (Section 4.6). Finally, the client sends an accept message to the server.
参数，并表明其接受保持有效期（第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状态。通过重用相同的UDP套接字参数来传输IPv6，流量将使用相同的状态通过NAT。
+------+-----------+--------+
| IPv4 | UDP | IPv6 |
| hdr. | port 3653 | |
+------+-----------+--------+
+------+-----------+--------+
| 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
TSP客户端可以选择定期向服务器发送保持活动的消息，以保持其隧道连接。这允许客户端检测网络更改并启用自动隧道
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.
重建。在通过UDP隧道的IPv6的情况下，如果NAT中的设备位于隧道路径中，则定期保持活动状态消息可以帮助刷新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.
对于IPv4上的IPv6和UDP上的IPv6隧道，保持活动状态消息是从客户端发送到隧道服务器的ICMPv6回显请求[RFC4443]。回送消息的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:
“隧道”消息包含三个元素：
<client>: Client's information
<client>: Client's information
<server>: Server's information
<server>: Server's information
<broker>: List of other servers
<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.
“client”元素包含3个子元素：“address”、“router”和“keepalive”。这些元素用于描述客户端请求，服务器将使用这些元素创建适当的隧道。客户端元素是客户端发送的唯一元素。
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.
“address”元素用于标识隧道的客户端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地址端点和域名。如果代理支持，“client”元素可能包含分配给客户端的地址端点的已注册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.
或者，客户机可以发送包含客户机请求的保持活动时间间隔的“keepalive”元素。
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.
“服务器”元素包含两个元素：“地址”和“路由器”。这些元素用于描述服务器的隧道端点。“address”元素用于提供服务器隧道端点的IPv4和IPv6地址，而“router”元素提供客户端选择的路由方法的信息。
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.
隧道代理使用“broker”元素在服务器无法提供请求的隧道时向客户端提供代理的备用列表。
The 'broker' element contains an 'address' element or a series of 'address' elements.
“broker”元素包含一个“address”元素或一系列“address”元素。
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”隧道封装类型。隧道代理发送的响应是一个“info”操作。请注意，已分配客户端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
-- 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.
带有前缀的隧道请求由包含“地址”元素和“路由器”元素的“隧道”元素组成。“router”元素还包含用于请求分配的IPv6前缀的dns委派的“dns_服务器”元素。“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: 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
-- 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.
如果分配请求被接受，则代理将发送一个“隧道”元素，将属性“action”设置为“info”，“type”设置为“v4v6”，并将“life”属性设置为分配的有效期或租赁时间，从而向客户端确认分配。“tunnel”元素包含“server”和“client”元素。
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
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 over 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进行IPv6和通过IPv4进行UDP进行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
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
在IPv4占主导地位的提供商网络中，在构建完整的IPv6本机基础结构之前，可以使用隧道式基础结构向企业客户提供IPv6服务。为了以可控的方式开始部署并为企业客户提供前缀，使用了TSP框架。TSP服务器可以位于核心、聚合点或节点中
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.
存在性（PoPs）向客户提供服务。可以使用IPv6 over IPv4封装。如果客户支持IPv4 NAT，则可以使用IPv6 over 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.
在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中IPv6的“v6anyv4”或IPv4封装中UDP中的IPv6
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协商终止时创建。静态隧道不是开放式网关，与自动隧道相比，安全问题较少。[RFC4213]中描述了IPv4隧道中的静态IPv6安全注意事项。
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使两个隧道端点能够在经过身份验证的会话中协商隧道参数以及前缀分配、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）做出了贡献。感谢以下人士对改进和澄清本文件的意见：佩卡·萨沃拉、艾伦·福特、杰伦·马萨和让·弗朗索瓦·特雷姆布雷。
[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 28312000年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，“简单身份验证和安全层（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（第三版）”，W3C REC-xml-200402042004年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隧道代理”，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 37042004年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网络编程，第三版”，Addison-Wesley ISBN 0-13-141155-12004。
<?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 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 server (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT client (address+,router?)>
<!ELEMENT broker (address+)>
<!ELEMENT broker (address+)>
<!ELEMENT router (prefix?,dns_server?)>
<!ELEMENT router (prefix?,dns_server?)>
<!ELEMENT dns_server (address+)>
<!ELEMENT dns_server (address+)>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT prefix (#PCDATA)>
<!ATTLIST prefix length CDATA #REQUIRED>
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
<!ATTLIST address length CDATA "">
<!ELEMENT address (#PCDATA)>
<!ATTLIST address type (ipv4|ipv6|dn) #REQUIRED>
<!ATTLIST address length CDATA "">
<!ELEMENT keepalive (address?)>
<!ATTLIST keepalive interval CDATA #REQUIRED>
]>
<!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。加拿大魁北克QC G1V 4W1魁北克625室Laurier
Phone: +1-418-656-9254
EMail: Marc.Blanchet@viagenie.ca
Phone: +1-418-656-9254
EMail: Marc.Blanchet@viagenie.ca
Florent Parent Beon Solutions Quebec, QC Canada
Florent Parent Beon Solutions加拿大魁北克省
Phone: +1 418 265 7357
EMail: Florent.Parent@beon.ca
Phone: +1 418 265 7357
EMail: Florent.Parent@beon.ca