Internet Engineering Task Force (IETF)                 S. Perreault, Ed.
Request for Comments: 6062                                      Viagenie
Category: Standards Track                                   J. Rosenberg
ISSN: 2070-1721                                              jdrosen.net
                                                           November 2010
        
Internet Engineering Task Force (IETF)                 S. Perreault, Ed.
Request for Comments: 6062                                      Viagenie
Category: Standards Track                                   J. Rosenberg
ISSN: 2070-1721                                              jdrosen.net
                                                           November 2010
        

Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations

使用NAT(TURN)扩展周围的中继遍历TCP分配

Abstract

摘要

This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server.

本规范定义了使用NAT(TURN)中继的遍历扩展,NAT是一种用于网络地址转换器(NAT)遍历的中继协议。此扩展允许TURN客户端请求TCP分配,并为TURN服务器定义新的请求和指示,以打开和接受与客户端对等方的TCP连接。TURN和此扩展都有意限制中继地址的使用方式。特别是,它防止用户从TURN服务器获得的端口运行通用服务器。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见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/rfc6062.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6062.

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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   4.  Client Processing  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Creating an Allocation . . . . . . . . . . . . . . . . . .  6
     4.2.  Refreshing an Allocation . . . . . . . . . . . . . . . . .  7
     4.3.  Initiating a Connection  . . . . . . . . . . . . . . . . .  7
     4.4.  Receiving a Connection . . . . . . . . . . . . . . . . . .  7
     4.5.  Sending and Receiving Data . . . . . . . . . . . . . . . .  8
     4.6.  Data Connection Maintenance  . . . . . . . . . . . . . . .  8
   5.  TURN Server Behavior . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Receiving a TCP Allocate Request . . . . . . . . . . . . .  8
     5.2.  Receiving a Connect Request  . . . . . . . . . . . . . . .  9
     5.3.  Receiving a TCP Connection on a Relayed Transport
           Address  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  Receiving a ConnectionBind Request . . . . . . . . . . . . 11
     5.5.  Data Connection Maintenance  . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  New STUN Methods . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  New STUN Attributes  . . . . . . . . . . . . . . . . . . . 12
       6.2.1.  CONNECTION-ID  . . . . . . . . . . . . . . . . . . . . 12
     6.3.  New STUN Error Codes . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   4.  Client Processing  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Creating an Allocation . . . . . . . . . . . . . . . . . .  6
     4.2.  Refreshing an Allocation . . . . . . . . . . . . . . . . .  7
     4.3.  Initiating a Connection  . . . . . . . . . . . . . . . . .  7
     4.4.  Receiving a Connection . . . . . . . . . . . . . . . . . .  7
     4.5.  Sending and Receiving Data . . . . . . . . . . . . . . . .  8
     4.6.  Data Connection Maintenance  . . . . . . . . . . . . . . .  8
   5.  TURN Server Behavior . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Receiving a TCP Allocate Request . . . . . . . . . . . . .  8
     5.2.  Receiving a Connect Request  . . . . . . . . . . . . . . .  9
     5.3.  Receiving a TCP Connection on a Relayed Transport
           Address  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  Receiving a ConnectionBind Request . . . . . . . . . . . . 11
     5.5.  Data Connection Maintenance  . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  New STUN Methods . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  New STUN Attributes  . . . . . . . . . . . . . . . . . . . 12
       6.2.1.  CONNECTION-ID  . . . . . . . . . . . . . . . . . . . . 12
     6.3.  New STUN Error Codes . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
        
1. Introduction
1. 介绍

Traversal Using Relays around NAT (TURN) [RFC5766] is an extension to the Session Traversal Utilities for NAT [RFC5389] protocol. TURN allows for clients to communicate with a TURN server and ask it to allocate ports on one of its host interfaces, and then relay traffic between that port and the client itself. TURN, when used in concert with STUN and Interactive Connectivity Establishment (ICE) [RFC5245], forms a solution for NAT traversal for UDP-based media sessions.

使用NAT(TURN)周围的中继进行遍历[RFC5766]是NAT[RFC5389]协议会话遍历实用程序的扩展。TURN允许客户端与TURN服务器通信,并要求它在其中一个主机接口上分配端口,然后在该端口和客户端本身之间中继通信。TURN与STUN和交互式连接建立(ICE)[RFC5245]配合使用时,形成了基于UDP的媒体会话NAT遍历的解决方案。

However, TURN itself does not provide a way for a client to allocate a TCP-based port on a TURN server. Such an allocation is needed for cases where a TCP-based session is desired with a peer, and NATs prevent a direct TCP connection. Examples include application sharing between desktop softphones, or transmission of pictures during a voice communications session.

但是,TURN本身并没有为客户端提供在TURN服务器上分配基于TCP的端口的方法。如果需要与对等方进行基于TCP的会话,并且NAT阻止直接TCP连接,则需要这样的分配。示例包括桌面软电话之间的应用程序共享,或在语音通信会话期间传输图片。

This document defines an extension to TURN that allows a client to obtain a TCP allocation. It also allows the client to initiate outgoing TCP connections from that allocation to peers and to accept incoming TCP connection requests from peers made towards that allocation.

本文档定义了一个允许客户机获得TCP分配的TURN扩展。它还允许客户端启动从该分配到对等方的传出TCP连接,并接受对等方向该分配发出的传入TCP连接请求。

The term "TCP allocation" means a TURN allocation where TCP is used as the transport protocol instead of UDP. Such an allocation is uniquely identified by its relayed transport address, which consists of an IP address and TCP port (defined in [RFC5766]).

术语“TCP分配”是指将TCP用作传输协议而不是UDP的回合分配。这种分配由其中继传输地址唯一标识,该地址由IP地址和TCP端口(在[RFC5766]中定义)组成。

2. Conventions
2. 习俗

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]中所述进行解释。

3. Overview of Operation
3. 业务概况
                                                      +--------+
                                                      |        |
                                                      | Peer1  |
                                                   /  |        |
                                                  /   |        |
                                                 /    +--------+
                                                /
                                               /
                                              / Peer Data 1
                                             /
      +--------+  Control       +--------+  /
      |        | -------------- |        | /
      | Client | Client Data 1  | TURN   |
      |        | -------------- | Server | \
      |        | -------------- |        |  \
      +--------+ Client Data 2  +--------+   \
                                              \
                                               \
                                                \     +--------+
                                                 \    |        |
                                      Peer Data 2 \   | Peer2  |
                                                   \  |        |
                                                      |        |
                                                      +--------+
        
                                                      +--------+
                                                      |        |
                                                      | Peer1  |
                                                   /  |        |
                                                  /   |        |
                                                 /    +--------+
                                                /
                                               /
                                              / Peer Data 1
                                             /
      +--------+  Control       +--------+  /
      |        | -------------- |        | /
      | Client | Client Data 1  | TURN   |
      |        | -------------- | Server | \
      |        | -------------- |        |  \
      +--------+ Client Data 2  +--------+   \
                                              \
                                               \
                                                \     +--------+
                                                 \    |        |
                                      Peer Data 2 \   | Peer2  |
                                                   \  |        |
                                                      |        |
                                                      +--------+
        

Figure 1: TURN TCP Model

图1:TURN TCP模型

The overall model for TURN-TCP is shown in Figure 1. The client will have two different types of connections to its TURN server. For each allocated relayed transport address, it will have a single control connection. Control connections are used to obtain allocations and open up new connections. Furthermore, for each connection to a peer, the client will have a single connection to its TURN server. These connections are called data connections. Consequently, there is a data connection from the client to its TURN server (the client data connection) and one from the TURN server to a peer (the peer data connection). Actual application data is sent on these connections. Indeed, after an initial TURN message that binds the client data connection to a peer data connection, only application data can be sent -- no TURN messaging. This is in contrast to the control connection, which only allows TURN messages and not application data.

TURN-TCP的整体模型如图1所示。客户端将有两种不同类型的连接到其TURN服务器。对于每个分配的中继传输地址,它将有一个单独的控制连接。控制连接用于获取分配和打开新连接。此外,对于与对等方的每个连接,客户机将有一个到其TURN服务器的连接。这些连接称为数据连接。因此,存在从客户端到其TURN服务器的数据连接(客户端数据连接)和从TURN服务器到对等机的数据连接(对等数据连接)。实际应用程序数据通过这些连接发送。实际上,在将客户机数据连接绑定到对等数据连接的初始TURN消息之后,只能发送应用程序数据——无TURN消息。这与控制连接不同,控制连接只允许转向消息,不允许应用程序数据。

To obtain a TCP-based allocation, a client first opens a TCP or TLS connection to its TURN server. The client then sends an Allocate request over that control connection. That request contains a REQUESTED-TRANSPORT attribute, which indicates a TCP-based allocation

要获得基于TCP的分配,客户端首先打开到其TURN服务器的TCP或TLS连接。然后,客户端通过该控制连接发送分配请求。该请求包含REQUESTED-TRANSPORT属性,该属性表示基于TCP的分配

is desired. A server that supports this extension will allocate a TCP relayed transport address and begin listening for connection requests on it. It then returns the allocated relayed transport address to the client in the response to the Allocate request. The connection on which the Allocate request was sent is the control connection.

这是需要的。支持此扩展的服务器将分配TCP中继传输地址,并开始侦听其上的连接请求。然后,在对分配请求的响应中,它将分配的中继传输地址返回给客户端。发送分配请求的连接是控制连接。

If a client wishes to establish a TCP connection to a peer from that relayed transport address, it issues a Connect request to the TURN server over the control connection. That request contains an XOR-PEER-ADDRESS attribute identifying the peer IP address and port (i.e., its "transport address") to which a connection is to be made. The TURN server attempts to open the TCP connection, and assuming it succeeds, then responds to the Connect request with a success response. The server also creates a connection identifier associated with this connection and passes that connection identifier back to the client in the success response. Note that a maximum of one connection to a given peer transport address can be established per allocation.

如果客户机希望从该中继传输地址建立到对等机的TCP连接,它将通过控制连接向翻转服务器发出连接请求。该请求包含一个XOR-PEER-ADDRESS属性,该属性标识要进行连接的对等IP地址和端口(即其“传输地址”)。TURN服务器尝试打开TCP连接,并假设连接成功,然后用成功响应响应Connect请求。服务器还创建与此连接关联的连接标识符,并在成功响应中将该连接标识符传递回客户端。请注意,每次分配最多可以建立一个到给定对等传输地址的连接。

Note: Establishing a relayed connection from the client to a peer is done in two steps. First, the allocation is created, and second, the connection is established. Combining the two is not desirable for NAT traversal. It is expected that, between the first and second steps, the client will communicate off-band with the peer (e.g., using ICE [RFC5245]) and tell it the relayed transport address that the TURN server allocated and from which it is about to initiate a connection. The peer can then "get ready": open holes in its firewall, try to poke holes in a NAT, attempt a TCP simultaneous open, etc.

注意:通过两个步骤建立从客户端到对等端的中继连接。首先,创建分配,然后建立连接。将这两者结合起来对于NAT遍历是不可取的。预计在第一和第二步骤之间,客户机将与对等机进行带外通信(例如,使用ICE[RFC5245]),并告诉它TURN服务器分配的中继传输地址以及它将从中启动连接的中继传输地址。然后,对等方可以“准备就绪”:打开防火墙上的漏洞,尝试戳NAT上的漏洞,尝试同时打开TCP,等等。

In order to actually send data on the new connection or otherwise utilize it in any way, the client establishes a new TCP connection to its TURN server. Once established, it issues a ConnectionBind request to the server over this new connection. That request echoes back the connection identifier to the TURN server. The TURN server uses it to correlate the two connections. As a consequence, the TCP connection to the peer is associated with a TCP connection to the client one-to-one. The two connections are now data connections. At this point, if the server receives data from the peer, it forwards that data towards the client, without any kind of encapsulation. Any data received by the TURN server from the client over the client data connection is forwarded to the peer, again without encapsulation or framing of any kind. Once a connection has been bound using the ConnectionBind request, TURN messaging is no longer permitted on the connection.

为了在新连接上实际发送数据或以任何方式利用数据,客户机将建立到其TURN服务器的新TCP连接。一旦建立,它将通过这个新连接向服务器发出ConnectionBind请求。该请求将连接标识符回显到TURN服务器。TURN服务器使用它关联两个连接。因此,到对等方的TCP连接与到客户端的TCP连接一一关联。这两个连接现在是数据连接。此时,如果服务器接收到来自对等方的数据,它将该数据转发给客户端,而不进行任何封装。TURN服务器通过客户机数据连接从客户机接收的任何数据都将转发给对等方,同样不进行任何类型的封装或帧。使用ConnectionBind请求绑定连接后,连接上就不再允许TURN消息传递。

In a similar way, when a peer opens a TCP connection towards the relayed transport address, the server checks if there is a permission in place for that peer. If there is none, the connection is closed. Permissions are created with the CreatePermission request sent over the control connection, just as for UDP TURN. If there is a permission in place, the TURN server sends to the client a ConnectionAttempt Indication over the control connection. That indication contains a connection identifier. Once again, the client initiates a separate TCP connection to its TURN server, and over that connection, issues a ConnectionBind request. Once received, the TURN server will begin relaying data back and forth. The server closes the peer data connection if no ConnectionBind request is received after a timeout.

以类似的方式,当对等方打开指向中继传输地址的TCP连接时,服务器将检查该对等方是否具有相应的权限。如果没有,则连接关闭。权限是通过控制连接发送的CreatePermission请求创建的,就像UDP TURN一样。如果有适当的权限,TURN服务器将通过控制连接向客户端发送ConnectionTest指示。该指示包含连接标识符。客户机再次启动到其TURN服务器的单独TCP连接,并通过该连接发出ConnectionBind请求。一旦收到,TURN服务器将开始来回转发数据。如果超时后未收到ConnectionBind请求,服务器将关闭对等数据连接。

If the client closes a client data connection, the corresponding peer data connection is closed. If the peer closes a peer data connection, the corresponding client data connection is closed. In this way, the status of the connection is directly known to the client.

如果客户端关闭客户端数据连接,则相应的对等数据连接将关闭。如果对等方关闭对等数据连接,则相应的客户端数据连接将关闭。这样,客户机就可以直接知道连接的状态。

The TURN server will relay the data between the client and peer data connections. End-to-end flow control is maintained by the relay process: if the relay process is no longer able to write data to the destination of the relayed data, the relay process stops reading data from the source.

TURN服务器将在客户端和对等数据连接之间中继数据。端到端流控制由中继进程维护:如果中继进程不再能够将数据写入中继数据的目标,则中继进程停止从源读取数据。

4. Client Processing
4. 客户端处理
4.1. Creating an Allocation
4.1. 创建分配

To create a TCP allocation, a client MUST initiate a new TCP or TLS connection to its TURN server, identical to the TCP or TLS procedures defined in [RFC5766]. TCP allocations cannot be obtained using a UDP association between client and server.

要创建TCP分配,客户端必须启动到其TURN服务器的新TCP或TLS连接,与[RFC5766]中定义的TCP或TLS过程相同。无法使用客户端和服务器之间的UDP关联获取TCP分配。

Once set up, a client MUST send a TURN Allocate request. That request MUST contain a REQUESTED-TRANSPORT attribute whose value is 6, corresponding to TCP.

设置后,客户端必须发送一个回合分配请求。该请求必须包含一个request-TRANSPORT属性,其值为6,对应于TCP。

The request MUST NOT include a DONT-FRAGMENT, RESERVATION-TOKEN, or EVEN-PORT attribute. The corresponding features are specific to UDP-based capabilities and are not utilized by TURN-TCP. However, a LIFETIME attribute MAY be included, with semantics identical to the UDP case.

请求不能包含DONT-FRAGMENT、RESERVATION-TOKEN甚至-PORT属性。相应的功能特定于基于UDP的功能,TURN-TCP不使用这些功能。但是,可能会包含一个生存期属性,其语义与UDP情况相同。

The procedures for authentication of the Allocate request and processing of success and failure responses are identical to those for UDP.

分配请求的身份验证以及成功和失败响应的处理过程与UDP相同。

Once a success response is received, the TCP connection to the TURN server is called the control connection for that allocation.

收到成功响应后,到TURN服务器的TCP连接称为该分配的控制连接。

4.2. Refreshing an Allocation
4.2. 刷新分配

The procedures for refreshing an allocation are identical to those for UDP. Note that the Refresh MUST be sent on the control connection.

刷新分配的过程与UDP的过程相同。请注意,刷新必须在控制连接上发送。

4.3. Initiating a Connection
4.3. 启动连接

To initiate a TCP connection to a peer, a client MUST send a Connect request over the control connection for the desired allocation. The Connect request MUST include an XOR-PEER-ADDRESS attribute containing the transport address of the peer to which a connection is desired.

要启动到对等方的TCP连接,客户端必须通过控制连接发送连接请求,以进行所需的分配。连接请求必须包含一个XOR-PEER-ADDRESS属性,该属性包含所需连接的对等方的传输地址。

If the connection is successfully established, the client will receive a success response. That response will contain a CONNECTION-ID attribute. The client MUST initiate a new TCP connection to the server, utilizing the same destination transport address to which the control connection was established. This connection MUST be made using a different local transport address. Authentication of the client by the server MUST use the same method and credentials as for the control connection. Once established, the client MUST send a ConnectionBind request over the new connection. That request MUST include the CONNECTION-ID attribute, echoed from the Connect Success response. When a response to the ConnectionBind request is received, if it is a success, the TCP connection on which it was sent is called the client data connection corresponding to the peer.

如果成功建立连接,客户端将收到成功响应。该响应将包含CONNECTION-ID属性。客户机必须使用与控制连接建立时相同的目标传输地址启动到服务器的新TCP连接。必须使用不同的本地传输地址建立此连接。服务器对客户端的身份验证必须使用与控制连接相同的方法和凭据。一旦建立,客户端必须通过新连接发送ConnectionBind请求。该请求必须包含Connect-ID属性,该属性从Connect Success响应中回显。当接收到对ConnectionBind请求的响应时,如果成功,则发送该请求的TCP连接称为对应于对等方的客户端数据连接。

If the result of the Connect request was an Error Response, and the response code was 447 (Connection Timeout or Failure), it means that the TURN server was unable to connect to the peer. The client MAY retry with the same XOR-PEER-ADDRESS attribute, but MUST wait at least 10 seconds.

如果连接请求的结果是错误响应,且响应代码为447(连接超时或失败),则表示TURN服务器无法连接到对等服务器。客户端可以使用相同的XOR-PEER-ADDRESS属性重试,但必须至少等待10秒。

As with any other request, multiple Connect requests MAY be sent simultaneously. However, Connect requests with the same XOR-PEER-ADDRESS parameter MUST NOT be sent simultaneously.

与任何其他请求一样,可以同时发送多个连接请求。但是,不能同时发送具有相同XOR-PEER-ADDRESS参数的Connect请求。

4.4. Receiving a Connection
4.4. 接收连接

After an Allocate request is successfully processed by the server, the client will start receiving a ConnectionAttempt indication each time a peer for which a permission has been installed attempts a new connection to the relayed transport address. This indication will contain CONNECTION-ID and XOR-PEER-ADDRESS attributes. If the client

服务器成功处理分配请求后,每当安装了权限的对等方尝试与中继传输地址建立新连接时,客户端将开始接收ConnectionAttent指示。此指示将包含CONNECTION-ID和XOR-PEER-ADDRESS属性。如果客户

wishes to accept this connection, it MUST initiate a new TCP connection to the server, utilizing the same destination transport address to which the control connection was established. This connection MUST be made using a different local transport address. Authentication of the client by the server MUST use the same method and credentials as for the control connection. Once established, the client MUST send a ConnectionBind request over the new connection. That request MUST include the CONNECTION-ID attribute, echoed from the ConnectionAttempt indication. When a response to the ConnectionBind request is received, if it is a success, the TCP connection on which it was sent is called the client data connection corresponding to the peer.

若要接受此连接,它必须使用与控制连接建立时相同的目标传输地址,启动到服务器的新TCP连接。必须使用不同的本地传输地址建立此连接。服务器对客户端的身份验证必须使用与控制连接相同的方法和凭据。一旦建立,客户端必须通过新连接发送ConnectionBind请求。该请求必须包括CONNECTION-ID属性,该属性从connectionattent指示中回显。当接收到对ConnectionBind请求的响应时,如果成功,则发送该请求的TCP连接称为对应于对等方的客户端数据连接。

4.5. Sending and Receiving Data
4.5. 发送和接收数据

Once a client data connection is established, data sent on it by the client will be relayed as-is to the peer by the server. Similarly, data sent by the peer to the server will be relayed as-is to the client over the data connection.

一旦建立了客户机数据连接,由客户机发送的数据将按原样由服务器中继到对等机。类似地,对等方发送到服务器的数据将通过数据连接按原样中继到客户端。

4.6. Data Connection Maintenance
4.6. 数据连接维护

The client MUST refresh the allocation (corresponding to a data connection) using the Refresh request as defined in [RFC5766] for as long as it wants to keep the data connection alive.

客户机必须使用[RFC5766]中定义的刷新请求刷新分配(对应于数据连接),只要它想保持数据连接处于活动状态。

When the client wishes to terminate its relayed connection to the peer, it closes the data connection to the server.

当客户机希望终止其与对等机的中继连接时,它会关闭与服务器的数据连接。

Note: No mechanism for keeping alive the NAT bindings (potentially on the client data connection as well as on the peer data connection) is included. This service is not provided by TURN-TCP. If such a feature is deemed necessary, it can be implemented higher up the stack, in the application protocol being tunneled inside TURN-TCP. Also, TCP keep-alives MAY be used to keep the NAT bindings on the client data connection alive.

注意:不包括保持NAT绑定(可能在客户端数据连接和对等数据连接上)活动的机制。TURN-TCP不提供此服务。如果认为有必要,可以在TURN-TCP内部隧道的应用程序协议中,在堆栈的更高层实现该功能。此外,TCP keep alives可用于保持客户端数据连接上的NAT绑定处于活动状态。

5. TURN Server Behavior
5. 转向服务器行为
5.1. Receiving a TCP Allocate Request
5.1. 接收TCP分配请求

The process is similar to that defined in [RFC5766], Section 6.2, with the following exceptions:

该过程与[RFC5766]第6.2节中定义的过程相似,但以下情况除外:

1. If the REQUESTED-TRANSPORT attribute is included and specifies a protocol other than UDP or TCP, the server MUST reject the request with a 442 (Unsupported Transport Protocol) error. If the value is UDP, and if UDP transport is allowed by local

1. 如果包含REQUESTED-TRANSPORT属性并指定UDP或TCP以外的协议,则服务器必须以442(不支持的传输协议)错误拒绝请求。如果值为UDP,并且本地允许UDP传输

policy, the server MUST continue with the procedures of [RFC5766] instead of this document. If the value is UDP, and if UDP transport is forbidden by local policy, the server MUST reject the request with a 403 (Forbidden) error.

策略,服务器必须继续执行[RFC5766]的过程,而不是本文档。如果该值为UDP,并且本地策略禁止UDP传输,则服务器必须以403(禁止)错误拒绝请求。

2. If the client connection transport is not TCP or TLS, the server MUST reject the request with a 400 (Bad Request) error.

2. 如果客户端连接传输不是TCP或TLS,则服务器必须以400(错误请求)错误拒绝请求。

3. If the request contains the DONT-FRAGMENT, EVEN-PORT, or RESERVATION-TOKEN attribute, the server MUST reject the request with a 400 (Bad Request) error.

3. 如果请求包含DONT-FRAGMENT、EVEN-PORT或RESERVATION-TOKEN属性,则服务器必须以400(错误请求)错误拒绝该请求。

4. A TCP relayed transport address MUST be allocated instead of a UDP one.

4. 必须分配TCP中继传输地址,而不是UDP地址。

5. The RESERVATION-TOKEN attribute MUST NOT be present in the success response.

5. RESERVATION-TOKEN属性不能出现在成功响应中。

If all checks pass, the server MUST start accepting incoming TCP connections on the relayed transport address. Refer to Section 5.3 for details.

如果所有检查都通过,服务器必须开始接受中继传输地址上的传入TCP连接。详见第5.3节。

5.2. Receiving a Connect Request
5.2. 接收连接请求

When the server receives a Connect request, it processes the request as follows.

当服务器收到连接请求时,它将按如下方式处理该请求。

If the request is received on a TCP connection for which no allocation exists, the server MUST return a 437 (Allocation Mismatch) error.

如果在不存在分配的TCP连接上接收请求,则服务器必须返回437(分配不匹配)错误。

If the server is currently processing a Connect request for this allocation with the same XOR-PEER-ADDRESS, it MUST return a 446 (Connection Already Exists) error.

如果服务器当前正在使用相同的XOR-PEER地址处理此分配的连接请求,则必须返回446(连接已存在)错误。

If the server has already successfully processed a Connect request for this allocation with the same XOR-PEER-ADDRESS, and the resulting client and peer data connections are either pending or active, it MUST return a 446 (Connection Already Exists) error.

如果服务器已使用相同的XOR-PEER地址成功处理此分配的连接请求,并且生成的客户端和对等数据连接处于挂起或活动状态,则必须返回446(连接已存在)错误。

If the request does not contain an XOR-PEER-ADDRESS attribute, or if such attribute is invalid, the server MUST return a 400 (Bad Request) error.

如果请求不包含XOR-PEER-ADDRESS属性,或者该属性无效,则服务器必须返回400(错误请求)错误。

If the new connection is forbidden by local policy, the server MUST reject the request with a 403 (Forbidden) error.

如果本地策略禁止新连接,服务器必须以403(禁止)错误拒绝请求。

Otherwise, the server MUST initiate an outgoing TCP connection. The local endpoint is the relayed transport address associated with the allocation. The remote endpoint is the one indicated by the XOR-PEER-ADDRESS attribute. If the connection attempt fails or times out, the server MUST return a 447 (Connection Timeout or Failure) error. The timeout value MUST be at least 30 seconds.

否则,服务器必须启动传出TCP连接。本地端点是与分配关联的中继传输地址。远程端点是由XOR-PEER-ADDRESS属性指示的端点。如果连接尝试失败或超时,服务器必须返回447(连接超时或失败)错误。超时值必须至少为30秒。

If the connection is successful, it is now called a peer data connection. The server MUST buffer any data received from the client. The server adjusts its advertised TCP receive window to reflect the amount of empty buffer space.

如果连接成功,现在称为对等数据连接。服务器必须缓冲从客户端接收的任何数据。服务器调整其播发的TCP接收窗口以反映空缓冲区空间的大小。

The server MUST include the CONNECTION-ID attribute in the Connect success response. The attribute's value MUST uniquely identify the peer data connection.

服务器必须在连接成功响应中包含CONNECTION-ID属性。该属性的值必须唯一标识对等数据连接。

If no ConnectionBind request associated with this peer data connection is received after 30 seconds, the peer data connection MUST be closed.

如果30秒后未收到与此对等数据连接关联的ConnectionBind请求,则必须关闭对等数据连接。

5.3. Receiving a TCP Connection on a Relayed Transport Address
5.3. 在中继传输地址上接收TCP连接

When a server receives an incoming TCP connection on a relayed transport address, it processes the request as follows.

当服务器接收到中继传输地址上的传入TCP连接时,它将按如下方式处理请求。

The server MUST accept the connection. If it is not successful, nothing is sent to the client over the control connection.

服务器必须接受连接。如果失败,则不会通过控制连接向客户端发送任何内容。

If the connection is successfully accepted, it is now called a peer data connection. The server MUST buffer any data received from the peer. The server adjusts its advertised TCP receive window to reflect the amount of empty buffer space.

如果连接被成功接受,则现在称为对等数据连接。服务器必须缓冲从对等方接收的任何数据。服务器调整其播发的TCP接收窗口以反映空缓冲区空间的大小。

If no permission for this peer has been installed for this allocation, the server MUST close the connection with the peer immediately after it has been accepted.

如果没有为此分配安装对此对等方的权限,则服务器必须在接受该对等方后立即关闭与该对等方的连接。

Otherwise, the server sends a ConnectionAttempt indication to the client over the control connection. The indication MUST include an XOR-PEER-ADDRESS attribute containing the peer's transport address, as well as a CONNECTION-ID attribute uniquely identifying the peer data connection.

否则,服务器将通过控制连接向客户端发送ConnectionTest指示。指示必须包括包含对等方传输地址的XOR-PEER-ADDRESS属性,以及唯一标识对等方数据连接的CONNECTION-ID属性。

If no ConnectionBind request associated with this peer data connection is received after 30 seconds, the peer data connection MUST be closed.

如果30秒后未收到与此对等数据连接关联的ConnectionBind请求,则必须关闭对等数据连接。

5.4. Receiving a ConnectionBind Request
5.4. 接收ConnectionBind请求

When a server receives a ConnectionBind request, it processes the request as follows.

当服务器收到ConnectionBind请求时,它将按如下方式处理该请求。

If the client connection transport is not TCP or TLS, the server MUST return a 400 (Bad Request) error.

如果客户端连接传输不是TCP或TLS,则服务器必须返回400(错误请求)错误。

If the request does not contain the CONNECTION-ID attribute, or if this attribute does not refer to an existing pending connection, the server MUST return a 400 (Bad Request) error.

如果请求不包含CONNECTION-ID属性,或者该属性未引用现有的挂起连接,则服务器必须返回400(错误请求)错误。

Otherwise, the client connection is now called a client data connection. Data received on it MUST be sent as-is to the associated peer data connection.

否则,客户端连接现在称为客户端数据连接。在其上接收的数据必须按原样发送到相关的对等数据连接。

Data received on the associated peer data connection MUST be sent as-is on this client data connection. This includes data that was received after the associated Connect or request was successfully processed and before this ConnectionBind request was received.

在关联的对等数据连接上接收的数据必须按此客户端数据连接上的原样发送。这包括成功处理关联的Connect或请求之后以及接收此ConnectionBind请求之前接收的数据。

5.5. Data Connection Maintenance
5.5. 数据连接维护

If the allocation associated with a data connection expires, the data connection MUST be closed.

如果与数据连接关联的分配过期,则必须关闭数据连接。

When a client data connection is closed, the server MUST close the corresponding peer data connection.

当客户端数据连接关闭时,服务器必须关闭相应的对等数据连接。

When a peer data connection is closed, the server MUST close the corresponding client data connection.

当对等数据连接关闭时,服务器必须关闭相应的客户端数据连接。

6. IANA Considerations
6. IANA考虑

This specification defines several new STUN methods, STUN attributes, and STUN error codes. IANA added these new protocol elements to the Session Traversal Utilities for NAT (STUN) Parameters registry.

本规范定义了几种新的眩晕方法、眩晕属性和眩晕错误代码。IANA将这些新的协议元素添加到NAT(STUN)参数的会话遍历实用程序注册表中。

6.1. New STUN Methods
6.1. 新的眩晕方法

This section lists the codepoints for the new STUN methods defined in this specification. See Sections 4 and 5 for the semantics of these new methods.

本节列出了本规范中定义的新STUN方法的代码点。有关这些新方法的语义,请参见第4节和第5节。

0x000a : Connect 0x000b : ConnectionBind 0x000c : ConnectionAttempt

0x000a:连接0x000b:连接绑定0x000c:连接尝试

6.2. New STUN Attributes
6.2. 新眩晕属性

This STUN extension defines the following new attributes:

此眩晕扩展定义了以下新属性:

0x002a : CONNECTION-ID

0x002a:CONNECTION-ID

6.2.1. CONNECTION-ID
6.2.1. 连接ID

The CONNECTION-ID attribute uniquely identifies a peer data connection. It is a 32-bit unsigned integral value.

CONNECTION-ID属性唯一标识对等数据连接。它是一个32位无符号整数值。

6.3. New STUN Error Codes
6.3. 新的STUN错误代码

446 Connection Already Exists 447 Connection Timeout or Failure

446连接已存在447连接超时或失败

7. Security Considerations
7. 安全考虑

After a TCP connection is established between the server and a peer, and before a ConnectionBind request is received from the client, the server buffers all data received from the peer. This protocol specification lets the server drop the connection if the buffer size is about to exceed a limit defined by local policy. This policy should ensure that memory resources are not exceeded. See also [RFC4732], Section 2.1.3.

在服务器和对等方之间建立TCP连接之后,在从客户端接收到ConnectionBind请求之前,服务器缓冲从对等方接收的所有数据。如果缓冲区大小即将超过本地策略定义的限制,此协议规范允许服务器断开连接。此策略应确保不会超过内存资源。另见[RFC4732],第2.1.3节。

All the security considerations applicable to STUN [RFC5389] and TURN [RFC5766] are applicable to this document as well.

适用于STUN[RFC5389]和TURN[RFC5766]的所有安全注意事项也适用于本文件。

8. Acknowledgements
8. 致谢

Thanks to Rohan Mahy and Philip Matthews for their initial work on getting this document started.

感谢Rohan Mahy和Philip Matthews为启动本文档所做的初步工作。

The authors would also like to thank Alfred E. Heggestad, Ari Keranen, Marc Petit-Huguenin, Dave Thaler, and Dan Wing for their comments and suggestions.

作者还要感谢阿尔弗雷德·赫格斯塔德、阿里·凯拉宁、马克·佩蒂特·胡格宁、戴夫·泰勒和丹·温的评论和建议。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[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月。

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.

[RFC5389]Rosenberg,J.,Mahy,R.,Matthews,P.,和D.Wing,“NAT的会话遍历实用程序(STUN)”,RFC 5389,2008年10月。

[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

[RFC5766]Mahy,R.,Matthews,P.,和J.Rosenberg,“使用NAT周围的中继进行遍历(TURN):NAT(STUN)会话遍历实用程序的中继扩展”,RFC 5766,2010年4月。

9.2. Informative References
9.2. 资料性引用

[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.

[RFC4732]Handley,M.,Rescorla,E.,和IAB,“互联网拒绝服务注意事项”,RFC 4732,2006年12月。

[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.

[RFC5245]Rosenberg,J.,“交互式连接建立(ICE):提供/应答协议的网络地址转换器(NAT)遍历协议”,RFC 52452010年4月。

Authors' Addresses

作者地址

Simon Perreault (editor) Viagenie 2875 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada

西蒙·佩雷尔特(编辑)维亚吉尼2875波尔。Laurier,加拿大魁北克QC G1V 2M2 D2-630套房

   Phone: +1 418 656 9254
   EMail: simon.perreault@viagenie.ca
   URI:   http://www.viagenie.ca
        
   Phone: +1 418 656 9254
   EMail: simon.perreault@viagenie.ca
   URI:   http://www.viagenie.ca
        

Jonathan Rosenberg jdrosen.net Monmouth, NJ US

Jonathan Rosenberg jdrosen.net美国新泽西州蒙茅斯

   EMail: jdrosen@jdrosen.net
   URI:   http://www.jdrosen.net
        
   EMail: jdrosen@jdrosen.net
   URI:   http://www.jdrosen.net