Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 8016 Cisco
Category: Standards Track D. Wing
ISSN: 2070-1721
P. Patil
P. Martinsen
Cisco
November 2016
Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 8016 Cisco
Category: Standards Track D. Wing
ISSN: 2070-1721
P. Patil
P. Martinsen
Cisco
November 2016
Mobility with Traversal Using Relays around NAT (TURN)
使用NAT周围的中继进行移动（TURN）
Abstract
摘要
It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.
希望在移动事件期间最小化由改变IP地址引起的通信中断。最小化中断的一种机制是向移动事件公开较短的网络路径，以便只有本地网元知道更改的IP地址，而远程对等方不知道更改的IP地址。
This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.
本文档提供了这样一个IP地址移动解决方案，使用NAT（TURN）周围的中继进行遍历。这是通过允许客户端在客户端的IP地址更改时保留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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8016.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8016.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Mobility Using TURN . . . . . . . . . . . . . . . . . . . . . 4
3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 5
3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 5
3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 6
3.1.3. Receiving an Allocate Success Response . . . . . . . 6
3.1.4. Receiving an Allocate Error Response . . . . . . . . 7
3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 7
3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 7
3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 7
3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 9
3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 9
3.4. New STUN Error Response Code . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example of Ticket Construction . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Mobility Using TURN . . . . . . . . . . . . . . . . . . . . . 4
3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 5
3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 5
3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 6
3.1.3. Receiving an Allocate Success Response . . . . . . . 6
3.1.4. Receiving an Allocate Error Response . . . . . . . . 7
3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 7
3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 7
3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 7
3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 9
3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 9
3.4. New STUN Error Response Code . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example of Ticket Construction . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
When moving between networks, the endpoint's IP address can change or, due to NAT, the endpoint's public IP address can change. Such a change of IP address breaks upper-layer protocols such as TCP and RTP. Various techniques exist to prevent this breakage, all tied to making the endpoint's IP address static (e.g., Mobile IP, Proxy Mobile IP, Locator/ID Separation Protocol (LISP)). Other techniques exist, which make the change in IP address agnostic to the upper-layer protocol (e.g., Stream Control Transmission Protocol (SCTP)). The mechanism described in this document is in that last category.
在网络之间移动时，端点的IP地址可能会更改，或者由于NAT，端点的公共IP地址可能会更改。IP地址的这种变化破坏了上层协议，如TCP和RTP。存在各种技术来防止这种破坏，所有这些技术都与使端点的IP地址保持静态有关（例如，移动IP、代理移动IP、定位器/ID分离协议（LISP））。存在其它技术，使得IP地址的改变与上层协议（例如，流控制传输协议（SCTP））无关。本文档中描述的机制属于最后一类。
A server using Traversal Using Relays around NAT (TURN) [RFC5766] relays media packets and is used for a variety of purposes, including overcoming NAT and firewall traversal issues. The existing TURN specification does not permit a TURN client to reuse an allocation across client IP address changes. Due to this, when the IP address of the client changes, the TURN client has to request a new allocation, create permissions for the remote peer, create channels, etc. In addition, the client has to re-establish communication with its signaling server and send an updated offer to the remote peer conveying the newly relayed candidate address. Then, the remote side has to re-gather all candidates and signal them to the client, and the endpoints have to perform Interactive Connectivity Establishment (ICE) [RFC5245] checks. If the ICE continuous nomination procedure [NOMBIS] is used, then the newly relayed candidate address would have to be "trickled" (i.e., incrementally provisioned as described in [TRICKLE-SIP]), and ICE checks would have to be performed according to [TRICKLE-ICE] by the endpoints to nominate pairs for selection by ICE.
使用NAT（TURN）周围的中继进行遍历的服务器[RFC5766]中继媒体数据包，用于各种目的，包括克服NAT和防火墙遍历问题。现有TURN规范不允许TURN客户端跨客户端IP地址更改重用分配。因此，当客户端的IP地址发生变化时，TURN客户端必须请求新的分配、为远程对等方创建权限、创建通道等。此外，客户端必须与其信令服务器重新建立通信，并向传输新中继的候选地址的远程对等方发送更新的报价。然后，远程端必须重新收集所有候选对象并向客户端发送信号，端点必须执行交互式连接建立（ICE）[RFC5245]检查。如果使用ICE连续提名程序[NOMBIS]，则新中继的候选地址必须是“涓流式”（即，按照[涓流-SIP]中所述的增量设置），并且端点必须根据[涓流-ICE]执行ICE检查，以提名对供ICE选择。
This specification describes a mechanism to seamlessly reuse allocations across client IP address changes without any of the hassles described above. A critical benefit of this technique is that the remote peer does not have to support mobility or deal with any of the address changes. The client, which is subject to IP address changes, does all the work. The mobility technique works across and between network types (e.g., between 3G and wired Internet access), so long as the client can still access the TURN server. The technique should also work seamlessly when (D)TLS is used as a transport protocol for Session Traversal Utilities for NAT (STUN) [RFC5389]. When there is a change in IP address, the client uses (D)TLS Session Resumption without Server-Side State as described in [RFC5077] to resume secure communication with the TURN server, using the changed client IP address.
本规范描述了一种跨客户端IP地址更改无缝重用分配的机制，无需上述任何麻烦。这种技术的一个关键好处是，远程对等方不必支持移动性或处理任何地址更改。受IP地址更改影响的客户端完成所有工作。只要客户端仍然可以访问TURN服务器，移动技术就可以跨网络类型工作（例如，3G和有线互联网接入之间）。当（D）TLS被用作NAT（STUN）会话遍历实用程序的传输协议时，该技术也应该能够无缝工作[RFC5389]。当IP地址发生变化时，客户机使用[RFC5077]中所述的（D）TLS会话恢复（无服务器端状态），以使用变化的客户机IP地址恢复与TURN服务器的安全通信。
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]中所述进行解释。
This document uses terminology defined in [RFC5245] and the following additional terminology:
本文件使用[RFC5245]中定义的术语和以下附加术语：
Break Before Make: The old communication path is broken ("break") before new communication can be created ("make"). Such changes typically occur because a network's physical cable is disconnected, radio transmission is turned off, or a client moves out of radio range.
先断后通：在创建新通信（“通”）之前，旧通信路径已断开（“断开”）。这种变化通常是由于网络的物理电缆断开连接、无线电传输关闭或客户端移出无线电范围而发生的。
Make Before Break: A new communication path is created ("make") before the old communication path is broken ("break"). Such changes typically occur because a network is reconnected with a physical cable, radio transmission is turned on, or a client moves into radio range.
先接通后断开：在旧通信路径断开（“断开”）之前创建新通信路径（“接通”）。这种变化通常是因为网络与物理电缆重新连接，无线电传输打开，或者客户端移动到无线电范围。
To achieve mobility, a TURN client should be able to retain an allocation on the TURN server across changes in the client IP address as a consequence of movement to other networks.
为了实现移动性，TURN客户端应该能够在TURN服务器上保留由于移动到其他网络而导致的客户端IP地址变化的分配。
When the client sends the initial Allocate request to the TURN server, it will include a new STUN attribute MOBILITY-TICKET (with zero length value), which indicates that the client is capable of mobility and desires a ticket. The TURN server provisions a ticket that is sent inside the new STUN attribute MOBILITY-TICKET in the Allocate success response to the client. The ticket will be used by the client when it wants to refresh the allocation but with a new client IP address and port. This ensures that an allocation can only be refreshed by the same client that allocated the relayed transport address. When a client's IP address changes due to mobility, it presents the previously obtained ticket in a Refresh request to the TURN server. If the ticket is found to be valid, the TURN server will retain the same relayed address/port for the new IP address/port allowing the client to continue using previous channel bindings -- thus, the TURN client does not need to obtain new channel bindings. Any data from the external peer will be delivered by the TURN server to this new IP address/port of the client. The TURN client will continue to send application data to its peers using the previously allocated channelBind Requests.
当客户端向TURN服务器发送初始分配请求时，它将包括一个新的STUN属性MOBILITY-TICKET（长度值为零），这表示客户端能够移动并需要一个TICKET。TURN服务器在分配成功响应中向客户端提供在新的STUN属性MOBILITY-ticket内发送的票证。当客户端希望刷新分配但使用新的客户端IP地址和端口时，将使用票据。这确保分配只能由分配中继传输地址的同一客户端刷新。当客户端的IP地址因移动而改变时，它会在刷新请求中将先前获得的票证呈现给TURN服务器。如果发现票证有效，TURN服务器将保留新IP地址/端口的相同中继地址/端口，允许客户端继续使用以前的通道绑定——因此，TURN客户端不需要获得新的通道绑定。来自外部对等方的任何数据都将由TURN服务器传送到客户端的这个新IP地址/端口。TURN客户端将继续使用先前分配的channelBind请求向其对等方发送应用程序数据。
TURN TURN Peer
client server A
|-- Allocate request --------------->| |
| + MOBILITY-TICKET (length=0) | |
| | |
|<--------------- Allocate failure --| |
| (401 Unauthorized) | |
| | |
|-- Allocate request --------------->| |
| + MOBILITY-TICKET (length=0) | |
| | |
|<---------- Allocate success resp --| |
| + MOBILITY-TICKET | |
... ... ...
(changes IP address)
| | |
|-- Refresh request ---------------->| |
| + MOBILITY-TICKET | |
| | |
|<----------- Refresh success resp --| |
| + MOBILITY-TICKET | |
| | |
TURN TURN Peer
client server A
|-- Allocate request --------------->| |
| + MOBILITY-TICKET (length=0) | |
| | |
|<--------------- Allocate failure --| |
| (401 Unauthorized) | |
| | |
|-- Allocate request --------------->| |
| + MOBILITY-TICKET (length=0) | |
| | |
|<---------- Allocate success resp --| |
| + MOBILITY-TICKET | |
... ... ...
(changes IP address)
| | |
|-- Refresh request ---------------->| |
| + MOBILITY-TICKET | |
| | |
|<----------- Refresh success resp --| |
| + MOBILITY-TICKET | |
| | |
Figure 1: Mobility Using TURN
图1：使用转弯的机动性
In Figure 1, the client sends an Allocate request with a MOBILITY-TICKET attribute to the server without credentials. Since the server requires that all requests be authenticated using STUN's long-term credential mechanism, the server rejects the request with a 401 (Unauthorized) error code. The client then tries again, this time including credentials (not shown). This time, the server accepts the Allocate request and returns an Allocate success response and a ticket inside the MOBILITY-TICKET attribute. Sometime later, the client IP address changes, and the client decides to refresh the allocation, and thus sends a Refresh request to the server with a MOBILITY-TICKET attribute containing the ticket it received from the server. The refresh is accepted, and the server replies with a Refresh success response and a new ticket inside the MOBILITY-TICKET attribute.
在图1中，客户端向服务器发送带有MOBILITY-TICKET属性的Allocate请求，而不使用凭据。由于服务器要求使用STUN的长期凭证机制对所有请求进行身份验证，因此服务器会以401（未经授权）错误代码拒绝请求。客户端然后重试，这次包括凭据（未显示）。这一次，服务器接受分配请求，并在MOBILITY-ticket属性内返回分配成功响应和票据。稍后，客户机IP地址更改，客户机决定刷新分配，并因此使用包含从服务器接收的票证的MOBILITY-TICKET属性向服务器发送刷新请求。刷新已被接受，服务器将以刷新成功响应和MOBILITY-ticket属性内的新票证进行响应。
In addition to the process described in Section 6.1 of [RFC5766], the client includes the MOBILITY-TICKET attribute with a length of zero. This indicates that the client is a mobile node and wants a ticket.
除了[RFC5766]第6.1节中描述的过程外，客户端还包括长度为零的MOBILITY-TICKET属性。这表示客户端是一个移动节点，需要一个票证。
In addition to the process described in Section 6.2 of [RFC5766], the server does the following:
除了[RFC5766]第6.2节中描述的过程外，服务器还执行以下操作：
If the MOBILITY-TICKET attribute is included, and has a length of zero, but TURN session mobility is forbidden by local policy, the server will reject the request with the new error code 405 (Mobility Forbidden). If the MOBILITY-TICKET attribute is included and has a non-zero length, then the server will generate an error response with an error code of 400 (Bad Request). Following the rules specified in [RFC5389], if the server does not understand the MOBILITY-TICKET attribute, it ignores the attribute.
如果包括MOBILITY-TICKET属性，并且长度为零，但是本地策略禁止转弯会话移动，则服务器将使用新的错误代码405（禁止移动）拒绝请求。如果包含MOBILITY-TICKET属性且长度非零，则服务器将生成错误代码为400的错误响应（错误请求）。按照[RFC5389]中指定的规则，如果服务器不理解MOBILITY-TICKET属性，则忽略该属性。
If the server can successfully process the request and create an allocation, the server replies with a success response that includes a STUN MOBILITY-TICKET attribute. The TURN server can store system-internal data in the ticket that is encrypted by a key known only to the TURN server and sends the ticket in the STUN MOBILITY-TICKET attribute as part of the Allocate success response. An example of ticket construction is discussed in Appendix A. The ticket is opaque to the client, so the structure is not subject to interoperability concerns, and implementations may diverge from this format. The client could be roaming across networks with a different path MTU and from one address family to another (e.g., IPv6 to IPv4). The TURN server to support mobility must assume that the path MTU is unknown and use a ticket length in accordance with the published guidance on STUN UDP fragmentation (Section 7.1 of [RFC5389]).
如果服务器能够成功处理请求并创建分配，则服务器将以包含STUN MOBILITY-TICKET属性的成功响应进行响应。TURN服务器可以将系统内部数据存储在票据中，该票据由仅TURN服务器知道的密钥加密，并将票据作为分配成功响应的一部分发送到STUN MOBILITY-ticket属性中。附录A中讨论了票证构造的一个示例。票证对客户端是不透明的，因此结构不受互操作性问题的影响，实现可能与此格式不同。客户端可以在具有不同路径MTU的网络之间漫游，也可以从一个地址族漫游到另一个地址族（例如，IPv6到IPv4）。支持移动的TURN服务器必须假设路径MTU未知，并根据已发布的STUN UDP分段指南（RFC5389第7.1节）使用票证长度。
Note: There is no guarantee that the fields in the ticket are going to be decodable to a client, and therefore attempts by a client to examine the ticket are unlikely to be useful.
注意：不能保证票据中的字段对客户端是可解码的，因此客户端检查票据的尝试不太可能有用。
In addition to the process described in Section 6.3 of [RFC5766], the client will store the MOBILITY-TICKET attribute, if present, from the response. This attribute will be presented by the client to the server during a subsequent Refresh request to aid mobility.
除了[RFC5766]第6.3节中描述的过程外，客户机还将存储响应中的MOBILITY-TICKET属性（如果存在）。在后续刷新请求期间，客户端将向服务器显示此属性，以帮助移动。
If the client receives an Allocate error response with error code 405 (Mobility Forbidden), the error is processed as follows:
如果客户端接收到错误代码为405（禁止移动）的分配错误响应，则错误处理如下：
405 (Mobility Forbidden): The request is valid, but the server is refusing to perform it, likely due to administrative restrictions. The client considers the current transaction as having failed.
405（禁止移动）：请求有效，但服务器拒绝执行请求，可能是由于管理限制。客户端认为当前事务已失败。
The client can notify the user or operator. The client SHOULD NOT retry sending the Allocate request containing the MOBILITY-TICKET with this server until it believes the problem has been fixed.
客户端可以通知用户或操作员。在客户端认为问题已解决之前，不应尝试向该服务器发送包含MOBILITY-TICKET的分配请求。
All other error responses must be handled as described in [RFC5766].
必须按照[RFC5766]中的说明处理所有其他错误响应。
If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it sends a Refresh request as described in Section 7.1 of [RFC5766]. If the client's IP address or source port has changed and the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET attribute received in the Allocate success response in the Refresh request. If there has been no IP address or source port number change, the client MUST NOT include a MOBILITY-TICKET attribute, as this would be rejected by the server and the client would need to retransmit the Refresh request without the MOBILITY-TICKET attribute.
如果客户机希望刷新现有分配并更新其到期时间或删除现有分配，它将发送一个刷新请求，如[RFC5766]第7.1节所述。如果客户端的IP地址或源端口已更改，并且客户端希望保留现有分配，则客户端将在刷新请求的分配成功响应中接收到的MOBILITY-TICKET属性包括在内。如果没有IP地址或源端口号更改，则客户端不得包含MOBILITY-TICKET属性，因为这将被服务器拒绝，并且客户端需要在不包含MOBILITY-TICKET属性的情况下重新传输刷新请求。
In addition to the process described in Section 7.2 of [RFC5766], the server does the following:
除了[RFC5766]第7.2节中描述的过程外，服务器还执行以下操作：
If the STUN MOBILITY-TICKET attribute is included in the Refresh request, and the server configuration changed to forbid mobility or the server transparently fails over to another server instance that forbids mobility, then the server rejects the Refresh request with a 405 (Mobility Forbidden) error and the client starts afresh with a new allocation.
如果刷新请求中包含STUN MOBILITY-TICKET属性，并且服务器配置更改为禁止移动，或者服务器透明地故障转移到另一个禁止移动的服务器实例，则服务器将以405（禁止移动）拒绝刷新请求错误，客户端将使用新的分配重新启动。
If the STUN MOBILITY-TICKET attribute is included in the Refresh request, then the server will not retrieve the 5-tuple from the packet to identify an associated allocation. Instead, the TURN server will decrypt the received ticket, verify the ticket's validity, and retrieve the 5-tuple allocation using the ticket. If this 5-tuple obtained does not identify an existing allocation, then
如果刷新请求中包含STUN MOBILITY-TICKET属性，则服务器将不会从数据包中检索5元组以标识相关分配。相反，TURN服务器将解密接收到的票据，验证票据的有效性，并使用票据检索5元组分配。如果获得的这个5元组没有标识现有的分配，那么
the server MUST reject the request with a 437 (Allocation Mismatch) error. If the ticket is invalid, then the server MUST reject the request with a 400 (Bad Request) error.
服务器必须以437（分配不匹配）错误拒绝请求。如果票证无效，则服务器必须以400（错误请求）错误拒绝请求。
If the source IP address and port of the Refresh request with the STUN MOBILITY-TICKET attribute is the same as the stored 5-tuple allocation, then the TURN server rejects the request with a 400 (Bad Request) error. If the source IP address and port of the Refresh request is different from the stored 5-tuple allocation, the TURN server proceeds with a MESSAGE-INTEGRITY validation to identify that it is the same user that had previously created the TURN allocation. If the above check is not successful, then the server MUST reject the request with a 441 (Wrong Credentials) error.
如果具有STUN MOBILITY-TICKET属性的刷新请求的源IP地址和端口与存储的5元组分配相同，则TURN服务器将以400（错误请求）错误拒绝该请求。如果刷新请求的源IP地址和端口与存储的5元组分配不同，TURN服务器将继续进行消息完整性验证，以确定它是先前创建TURN分配的同一用户。如果上述检查未成功，则服务器必须以441（错误凭据）错误拒绝请求。
If all of the above checks pass, the TURN server understands that the client either has moved to a new network and acquired a new IP address (Break Before Make) or is in the process of switching to a new interface (Make Before Break). The source IP address of the request could be either the host transport address or the server-reflexive transport address. The server then updates its state data with the new client IP address and port but does not discard the old 5-tuple from its state data. The TURN server calculates the ticket with the new 5-tuple and sends the new ticket in the STUN MOBILITY-TICKET attribute as part of Refresh success response. The new ticket sent in the refresh response MUST be different from the old ticket.
如果上述所有检查均通过，TURN服务器将了解客户端已移动到新网络并获得新IP地址（先断后接）或正在切换到新接口（先接通后断）。请求的源IP地址可以是主机传输地址或服务器自反传输地址。然后，服务器使用新的客户端IP地址和端口更新其状态数据，但不会从其状态数据中丢弃旧的5元组。TURN服务器使用新的5元组计算票证，并在STUN MOBILITY-ticket属性中发送新票证，作为刷新成功响应的一部分。刷新响应中发送的新票证必须与旧票证不同。
The TURN server MUST continue receiving and processing data on the old 5-tuple and MUST continue transmitting data on the old-5 tuple until it receives a Send Indication or ChannelData message from the client on the new 5-tuple or a message from the client to close the old connection (e.g., a TLS fatal alert or TCP RST). After receiving any of those messages, a TURN server discards the old ticket and the old 5-tuple associated with the old ticket from its state data. Data sent by the client to the peer is accepted on the new 5-tuple and data received from the peer is forwarded to the new 5-tuple. If the refresh request containing the MOBILITY-TICKET attribute does not succeed (e.g., the packet is lost if the request is sent over UDP, or the server is unable to fulfill the request), then the client can continue to exchange data on the old 5-tuple until it receives the Refresh success response.
TURN服务器必须继续接收和处理旧5元组上的数据，并且必须继续传输旧5元组上的数据，直到它从新5元组上的客户端接收到发送指示或ChannelData消息，或者从客户端接收到关闭旧连接的消息（例如，TLS致命警报或TCP RST）。在接收到这些消息之后，TURN服务器从其状态数据中丢弃旧票证和与旧票证关联的旧5元组。客户端发送给对等方的数据在新的5元组上被接受，从对等方接收的数据被转发到新的5元组。如果包含MOBILITY-TICKET属性的刷新请求未成功（例如，如果通过UDP发送请求，则数据包丢失，或者服务器无法完成请求），则客户端可以继续交换旧5元组上的数据，直到收到刷新成功响应。
The old ticket can only be used for the purposes of retransmission. If the client wants to refresh its allocation with a new server-reflexive transport address, it MUST use the new ticket. If the TURN server has not received a Refresh request with the STUN MOBILITY-TICKET attribute but receives Send indications or ChannelData messages from a client, the TURN server MAY discard or queue those Send indications or ChannelData messages (at its discretion). Thus,
旧票只能用于重传目的。如果客户端希望使用新的服务器自反传输地址刷新其分配，则必须使用新的票证。如果TURN服务器未收到具有STUN MOBILITY-TICKET属性的刷新请求，但从客户端接收到发送指示或信道数据消息，TURN服务器可丢弃这些发送指示或信道数据消息或将其排队（自行决定）。因此
it is RECOMMENDED that the client avoid transmitting a Send indication or ChannelData message until it has received an acknowledgement for the Refresh request with the STUN MOBILITY-TICKET attribute.
建议客户端在收到具有STUN MOBILITY-TICKET属性的刷新请求确认之前，避免传输发送指示或信道数据消息。
To accommodate the potential loss of Refresh responses, a server must retain the old STUN MOBILITY-TICKET attribute for a period of at least 30 seconds to be able to recognize a retransmission of the Refresh request with the old STUN MOBILITY-TICKET attribute from the client.
为了适应刷新响应的潜在丢失，服务器必须将旧的STUN MOBILITY-TICKET属性保留至少30秒，以便能够识别来自客户端的具有旧的STUN MOBILITY-TICKET属性的刷新请求的重新传输。
In addition to the process described in Section 7.3 of [RFC5766], the client will store the MOBILITY-TICKET attribute, if present, from the response. This attribute will be presented by the client to the server during a subsequent Refresh request to aid mobility.
除了[RFC5766]第7.3节中描述的过程外，客户端还将存储响应中的MOBILITY-TICKET属性（如果存在）。在后续刷新请求期间，客户端将向服务器显示此属性，以帮助移动。
This attribute is used to retain an allocation on the TURN server. It is exchanged between the client and server to aid mobility. The value of the MOBILITY-TICKET is encrypted and is of variable length.
此属性用于保留回合服务器上的分配。它在客户端和服务器之间交换，以帮助移动。MOBILITY-TICKET的值是加密的，长度可变。
This document defines the following new error response code:
本文档定义了以下新的错误响应代码：
405 (Mobility Forbidden): Mobility request was valid but cannot be performed due to administrative or similar restrictions.
405（禁止移动）：移动请求有效，但由于管理或类似限制而无法执行。
IANA has added the following attribute to the "STUN Attributes" registry [IANA-STUN]:
IANA已将以下属性添加到“STUN属性”注册表[IANA-STUN]：
o MOBILITY-TICKET (0x8030, in the comprehension-optional range)
o MOBILITY-TICKET（0x8030，在可选范围内）
Also, IANA has added a new STUN error code "Mobility Forbidden" with the value 405 to the "STUN Error Codes" registry [IANA-STUN].
此外，IANA还在“STUN错误代码”注册表[IANA-STUN]中添加了一个新的STUN错误代码“禁止移动”，其值为405。
The TURN server MUST always ensure that the ticket is authenticated and encrypted using strong cryptographic algorithms to prevent modification or eavesdropping by an attacker. The ticket MUST be constructed such that it has strong entropy to ensure that nothing can be gleaned by looking at the ticket alone.
TURN服务器必须始终确保使用强加密算法对票据进行身份验证和加密，以防止攻击者修改或窃听。票证的构造必须使其具有强大的熵，以确保仅通过查看票证无法收集任何信息。
An attacker monitoring the traffic between the TURN client and server can impersonate the client and refresh the allocation using the ticket issued to the client with the attacker's IP address and port. The TURN client and server MUST use the STUN long-term credential mechanism [RFC5389], the STUN Extension for Third-Party Authorization [RFC7635], or a (D)TLS connection to prevent malicious users from impersonating the client. With any of those three mechanisms, when the server receives the Refresh request with the STUN MOBILITY-TICKET attribute from the client, it identifies that it is indeed the same client but with a new IP address and port using the ticket it had previously issued to refresh the allocation. If (D)TLS is not used or the (D)TLS handshake fails, and authentication also fails, then the TURN client and server MUST fail and not proceed with TURN mobility.
监视TURN客户端和服务器之间流量的攻击者可以模拟客户端，并使用向客户端发出的带有攻击者IP地址和端口的票证刷新分配。TURN客户端和服务器必须使用STUN长期凭据机制[RFC5389]、第三方授权的STUN扩展[RFC7635]或（D）TLS连接来防止恶意用户模拟客户端。使用这三种机制中的任何一种，当服务器从客户机接收到具有STUN MOBILITY-TICKET属性的刷新请求时，它会识别出它确实是同一个客户机，但具有一个新的IP地址和端口，该端口使用它先前发出的用于刷新分配的票证。如果未使用（D）TLS或（D）TLS握手失败，并且身份验证也失败，则TURN客户端和服务器必须失败，并且不能继续TURN移动。
Security considerations described in [RFC5766] are also applicable to this mechanism.
[RFC5766]中描述的安全注意事项也适用于此机制。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<http://www.rfc-editor.org/info/rfc5077>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[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, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<http://www.rfc-editor.org/info/rfc5766>.
[IANA-STUN] IANA, "Session Traversal Utilities for NAT (STUN) Parameters", <http://www.iana.org/assignments/stun-parameters>.
[IANA-STUN]IANA，“NAT（STUN）参数的会话遍历实用程序”<http://www.iana.org/assignments/stun-parameters>.
[NOMBIS] Uberti, J. and J. Lennox, "Improvements to ICE Candidate Nomination", Work in Progress, draft-uberti-mmusic-nombis-00, March 2015.
[NOMBIS]Uberti，J.和J.Lennox，“ICE候选人提名的改进”，正在进行的工作，草稿-Uberti-mmusic-NOMBIS-00，2015年3月。
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <http://www.rfc-editor.org/info/rfc7635>.
[RFC7635]Reddy，T.，Patil，P.，Ravindranath，R.，和J.Uberti，“第三方授权NAT（STUN）扩展的会话遍历实用程序”，RFC 7635，DOI 10.17487/RFC7635，2015年8月<http://www.rfc-editor.org/info/rfc7635>.
[TRICKLE-ICE] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Work in Progress, draft-ietf-ice-trickle-04, September 2016.
[TRICKLE-ICE]Ivov，E.，Rescorla，E.，Uberti，J.，和P.Saint Andre，“涓流ICE：交互式连接建立（ICE）协议候选方案的增量供应”，正在进行的工作，草案-ietf-ICE-TRICKLE-042016年9月。
[TRICKLE-SIP] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", Work in Progress, draft-ietf-mmusic-trickle-ice-sip-06, October 2016.
[Drickle-SIP]Ivov，E.，Stach，T.，Marocco，E.，和C.Holmberg，“涓流冰的会话启动协议（SIP）使用”，正在进行的工作，草案-ietf-mmusic-Drickle-ICE-SIP-062016年10月。
The TURN server uses two different keys: one 128-bit key for Advance Encryption Standard (AES) in Cipher Block Chaining (CBC) mode (AES_128_CBC) and a 256-bit key for HMAC-SHA-256-128 for integrity protection. The ticket can be structured as follows:
TURN服务器使用两种不同的密钥：一种用于密码块链接（CBC）模式（AES_128_CBC）中的高级加密标准（AES）的128位密钥，另一种用于HMAC-SHA-256-128的256位密钥，用于完整性保护。票证的结构如下所示：
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[16];
} ticket;
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[16];
} ticket;
Figure 2: Ticket Format
图2：票证格式
Here, key_name serves to identify a particular set of keys used to protect the ticket. It enables the TURN server to easily recognize tickets it has issued. The key_name should be randomly generated to avoid collisions between servers. One possibility is to generate new random keys and key_name every time the server is started.
在这里，key_name用于标识用于保护票据的一组特定密钥。它使TURN服务器能够轻松识别已发行的票证。密钥名称应随机生成，以避免服务器之间发生冲突。一种可能是在每次启动服务器时生成新的随机密钥和密钥名。
The TURN state information (which is either self-contained or a handle) in encrypted_state is encrypted using 128-bit AES in CBC mode with the given Initialization Vector (IV). The Message Authentication Code (MAC) is calculated using HMAC-SHA-256-128 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable length).
在CBC模式下，使用128位AES在给定的初始化向量（IV）对处于加密_状态的转弯状态信息（自包含或句柄）进行加密。使用HMAC-SHA-256-128对密钥名称（16个八位字节）和IV（16个八位字节）计算消息身份验证码（MAC），然后是加密状态字段（2个八位字节）的长度及其内容（可变长度）。
Acknowledgements
致谢
Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, Emil Ivov, Oleg Moskalenko, Dave Waltermire, Pete Resnick, Antoni Przygienda, Alissa Cooper, Ben Campbell, Suresh Krishnan, Mirja Kuehlewind, Jonathan Lennox, and Brandon Williams for review and comments.
感谢阿尔弗雷德·赫格斯塔德、利什托、周苏静、马丁·汤姆森、埃米尔·伊沃夫、奥列格·莫斯卡连科、戴夫·沃尔特米尔、皮特·雷斯尼克、安东尼·普济吉恩达、艾莉莎·库珀、本·坎贝尔、苏雷什·克里希南、米尔贾·库勒温德、乔纳森·伦诺克斯和布兰登·威廉姆斯的评论和评论。
Authors' Addresses
作者地址
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems，Inc.印度卡纳塔克邦班加罗尔外环路瓦图尔霍布里萨贾普尔马拉塔利塞斯纳商业园560103
Email: tireddy@cisco.com
Email: tireddy@cisco.com
Dan Wing
丹荣
Email: dwing-ietf@fuggles.com
Email: dwing-ietf@fuggles.com
Prashanth Patil Cisco Systems, Inc. Bangalore India
印度班加罗尔Prashanth Patil思科系统公司
Email: praspati@cisco.com
Email: praspati@cisco.com
Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens vei 22 Lysaker, Akershus 1325 Norway
Paal Erik Martinsen思科系统有限公司Philip Pedersens vei 22 Lysaker，挪威阿克苏
Email: palmarti@cisco.com
Email: palmarti@cisco.com