Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6156 O. Novo
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Perreault, Ed.
Viagenie
April 2011
Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6156 O. Novo
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Perreault, Ed.
Viagenie
April 2011
Traversal Using Relays around NAT (TURN) Extension for IPv6
在IPv6的NAT（TURN）扩展周围使用中继进行遍历
Abstract
摘要
This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address).
本文档使用NAT（TURN）周围的中继将IPv6支持添加到遍历中。IPv6支持又包括IPv4到IPv6、IPv6到IPv6和IPv6到IPv4中继。本文档为TURN定义了请求的-ADDRESS-FAMILY属性。REQUESTED-ADDRESS-FAMILY属性允许客户端显式请求TURN服务器将分配的地址类型（例如，仅IPv4的节点可以请求TURN服务器分配IPv6地址）。
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/rfc6156.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6156.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4
4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4
4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . . 4
4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5
4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 6
4.3. Receiving an Allocate Error Response . . . . . . . . . . . 6
5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6
5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6
5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6
6. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Sending a CreatePermission Request . . . . . . . . . . . . 6
6.2. Receiving a CreatePermission Request . . . . . . . . . . . 7
6.2.1. Peer Address Family Mismatch . . . . . . . . . . . . . 7
7. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 7
7.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 7
8. Packet Translations . . . . . . . . . . . . . . . . . . . . . 7
8.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . 8
8.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . 9
8.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Tunnel Amplification Attack . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. New STUN Attribute . . . . . . . . . . . . . . . . . . . . 12
10.2. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 4
4.1. Sending an Allocate Request . . . . . . . . . . . . . . . 4
4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . . 4
4.2. Receiving an Allocate Request . . . . . . . . . . . . . . 5
4.2.1. Unsupported Address Family . . . . . . . . . . . . . . 6
4.3. Receiving an Allocate Error Response . . . . . . . . . . . 6
5. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 6
5.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6
5.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6
6. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Sending a CreatePermission Request . . . . . . . . . . . . 6
6.2. Receiving a CreatePermission Request . . . . . . . . . . . 7
6.2.1. Peer Address Family Mismatch . . . . . . . . . . . . . 7
7. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 7
7.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 7
8. Packet Translations . . . . . . . . . . . . . . . . . . . . . 7
8.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . . 8
8.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . . 9
8.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Tunnel Amplification Attack . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10.1. New STUN Attribute . . . . . . . . . . . . . . . . . . . . 12
10.2. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Traversal Using Relays around NAT (TURN) [RFC5766] is a protocol that allows for an element behind a NAT to receive incoming data over UDP or TCP. It is most useful for elements behind NATs without Endpoint-Independent Mapping [RFC4787] that wish to be on the receiving end of a connection to a single peer.
使用NAT周围的中继进行遍历（TURN）[RFC5766]是一种允许NAT后面的元素通过UDP或TCP接收传入数据的协议。它对于NAT后面没有端点独立映射[RFC4787]的元素非常有用，这些元素希望位于连接到单个对等方的接收端。
The base specification of TURN [RFC5766] only defines IPv4-to-IPv4 relaying. This document adds IPv6 support to TURN, which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute, which is an extension to TURN that allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). This document also defines and registers new error response codes.
TURN[RFC5766]的基本规范仅定义IPv4到IPv4中继。本文档添加了对TURN的IPv6支持，其中包括IPv4到IPv6、IPv6到IPv6和IPv6到IPv4中继。本文档定义了REQUESTED-ADDRESS-FAMILY属性，该属性是TURN的扩展，允许客户端显式请求TURN服务器将分配的地址类型（例如，仅IPv4的节点可能会请求TURN服务器分配IPv6地址）。本文件还定义并登记了新的错误响应代码。
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]中所述进行解释。
When a user wishes a TURN server to allocate an address of a specific type, it sends an Allocate request to the TURN server with a REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, and it allows for a client to request address/port pairs for receiving both UDP and TCP.
当用户希望TURN服务器分配特定类型的地址时，它会向TURN服务器发送带有request-address-FAMILY属性的分配请求。TURN可以在UDP和TCP上运行，它允许客户端请求地址/端口对来接收UDP和TCP。
After the request has been successfully authenticated, the TURN server allocates a transport address of the type indicated in the REQUESTED-ADDRESS-FAMILY attribute. This address is called the relayed transport address.
请求成功通过身份验证后，TURN服务器将分配REQUESTED-address-FAMILY属性中指示的类型的传输地址。此地址称为中继传输地址。
The TURN server returns the relayed transport address in the response to the Allocate request. This response contains an XOR-RELAYED-ADDRESS attribute indicating the IP address and port that the server allocated for the client.
TURN服务器在对分配请求的响应中返回中继传输地址。此响应包含一个XOR-RELAYED-ADDRESS属性，该属性指示服务器为客户端分配的IP地址和端口。
TURN servers allocate a single relayed transport address per allocation request. Therefore, Allocate requests cannot carry more than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client that wishes to allocate more than one relayed transport address at a TURN server (e.g., an IPv4 and an IPv6 address) needs to perform several allocation requests (one allocation request per relayed transport address).
TURN服务器为每个分配请求分配一个中继传输地址。因此，分配请求不能包含多个REQUESTED-ADDRESS-FAMILY属性。因此，希望在TURN服务器上分配多个中继传输地址（例如，IPv4和IPv6地址）的客户端需要执行多个分配请求（每个中继传输地址一个分配请求）。
A TURN server that supports a set of address families is assumed to be able to relay packets between them. If a server does not support the address family requested by a client, the server returns a 440 (Address Family not Supported) error response.
假设支持一组地址族的TURN服务器能够在它们之间中继数据包。如果服务器不支持客户端请求的地址系列，服务器将返回440（不支持地址系列）错误响应。
The behavior specified here affects the processing defined in Section 6 of [RFC5766].
此处指定的行为会影响[RFC5766]第6节中定义的处理。
A client that wishes to obtain a relayed transport address of a specific address type includes a REQUESTED-ADDRESS-FAMILY attribute, which is defined in Section 4.1.1, in the Allocate request that it sends to the TURN server. Clients MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in an Allocate request. The mechanisms to formulate an Allocate request are described in Section 6.1 of [RFC5766].
希望获得特定地址类型的中继传输地址的客户机在发送给TURN服务器的分配请求中包含了第4.1.1节中定义的REQUESTED-address-FAMILY属性。客户端在分配请求中不能包含多个request-ADDRESS-FAMILY属性。[RFC5766]第6.1节描述了制定分配请求的机制。
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute.
客户端不得在包含保留令牌属性的分配请求中包含请求的-ADDRESS-FAMILY属性。
The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request the allocation of a specific address type from a server. The following is the format of the REQUESTED-ADDRESS-FAMILY attribute. Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit length, and a variable-length value.
REQUESTED-ADDRESS-FAMILY属性用于客户端请求从服务器分配特定的地址类型。以下是请求的-ADDRESS-FAMILY属性的格式。请注意，转弯属性是TLV（类型长度值）编码的，具有16位类型、16位长度和可变长度值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute
图1：请求的-ADDRESS-FAMILY属性的格式
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. As specified in [RFC5389], attributes with values between 0x0000 and 0x7FFF are comprehension-required, which means that the client or server cannot successfully process the message unless it understands the attribute.
类型：请求的-ADDRESS-FAMILY属性的类型为0x0017。如[RFC5389]中所述，需要值介于0x0000和0x7FFF之间的属性，这意味着客户端或服务器无法成功处理消息，除非它理解该属性。
Length: this 16-bit field contains the length of the attribute in bytes. The length of this attribute is 4 bytes.
长度：此16位字段包含属性的长度（以字节为单位）。此属性的长度为4字节。
Family: there are two values defined for this field and specified in [RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses.
族：此字段定义了两个值，并在[RFC5389]第15.1节中指定：0x01表示IPv4地址，0x02表示IPv6地址。
Reserved: at this point, the 24 bits in the Reserved field MUST be set to zero by the client and MUST be ignored by the server.
保留：此时，客户端必须将保留字段中的24位设置为零，服务器必须忽略该字段。
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate requests.
REQUEST-ADDRESS-TYPE属性只能出现在Allocate请求中。
Once a server has verified that the request is authenticated and has not been tampered with, the TURN server processes the Allocate request. If it contains both a RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the server replies with a 400 (Bad Request) Allocate error response. Following the rules in [RFC5389], if the server does not understand the REQUESTED-ADDRESS-FAMILY attribute, it generates an Allocate error response, which includes an ERROR-CODE attribute with 420 (Unknown Attribute) response code. This response will contain an UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-FAMILY attribute.
一旦服务器验证请求经过身份验证且未被篡改，TURN服务器将处理分配请求。如果它同时包含保留令牌和请求的地址族，服务器将以400（错误请求）分配错误响应进行响应。按照[RFC5389]中的规则，如果服务器不理解request-ADDRESS-FAMILY属性，它将生成一个Allocate error响应，其中包括一个带有420（未知属性）响应代码的错误代码属性。此响应将包含一个UNKNOWN-ATTRIBUTE属性，列出未知的REQUESTED-ADDRESS-FAMILY属性。
If the server can successfully process the request, it allocates a transport address for the TURN client, called the relayed transport address, and returns it in the response to the Allocate request.
如果服务器能够成功处理该请求，它将为TURN客户端分配一个传输地址，称为中继传输地址，并在对分配请求的响应中返回该地址。
As specified in [RFC5766], the Allocate response contains the same transaction ID contained in the Allocate request, and the XOR-RELAYED-ADDRESS attribute is set to the relayed transport address.
如[RFC5766]中所述，分配响应包含分配请求中包含的相同事务ID，并且XOR-RELAYED-ADDRESS属性设置为中继传输地址。
The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address and port. It is encoded in the same way as the XOR-MAPPED-ADDRESS [RFC5389].
XOR-RELAYED-ADDRESS属性表示分配的IP地址和端口。它的编码方式与XOR映射地址[RFC5389]相同。
If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST allocate an IPv4-relayed transport address for the TURN client. If allocation of IPv4 addresses is disabled by local policy, the server returns a 440 (Address Family not Supported) Allocate error response.
如果缺少REQUESTED-ADDRESS-FAMILY属性，则服务器必须为TURN客户端分配IPv4中继传输地址。如果本地策略禁用IPv4地址分配，服务器将返回440（不支持地址系列）分配错误响应。
If the server does not support the address family requested by the client, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code, which is defined in Section 4.2.1.
如果服务器不支持客户端请求的地址系列，则必须生成分配错误响应，并且必须包含错误代码属性和440（不支持地址系列）响应代码，这在第4.2.1节中定义。
This document defines the following new error response code:
本文档定义了以下新的错误响应代码：
440 (Address Family not Supported): The server does not support the address family requested by the client.
440（不支持地址系列）：服务器不支持客户端请求的地址系列。
If the client receives an Allocate error response with the 440 (Unsupported Address Family) error code, the client MUST NOT retry its request.
如果客户端收到带有440（不支持的地址系列）错误代码的分配错误响应，则客户端不得重试其请求。
The behavior specified here affects the processing defined in Section 7 of [RFC5766].
此处指定的行为会影响[RFC5766]第7节中定义的处理。
To perform an allocation refresh, the client generates a Refresh Request as described in Section 7.1 of [RFC5766]. The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request.
为了执行分配刷新，客户机生成一个刷新请求，如[RFC5766]第7.1节所述。客户端的刷新请求中不得包含任何请求的-ADDRESS-FAMILY属性。
If a server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY attribute, and the attribute's value doesn't match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh error response.
如果服务器接收到具有请求的-ADDRESS-FAMILY属性的刷新请求，并且该属性的值与分配的地址系列不匹配，则服务器必须使用443（对等地址系列不匹配）刷新错误响应进行响应。
The behavior specified here affects the processing defined in Section 9 of [RFC5766].
此处指定的行为会影响[RFC5766]第9节中定义的处理。
The client MUST only include XOR-PEER-ADDRESS attributes with addresses of the same address family as that of the relayed transport address for the allocation.
客户端必须仅包含XOR-PEER-ADDRESS属性，其地址与分配的中继传输地址的地址族相同。
If an XOR-PEER-ADDRESS attribute contains an address of an address family different than that of the relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code, which is defined in Section 6.2.1.
如果XOR-PEER-ADDRESS属性包含与分配的中继传输地址不同的地址族地址，则服务器必须使用第6.2.1节中定义的443（对等地址族不匹配）响应代码生成错误响应。
This document defines the following new error response code:
本文档定义了以下新的错误响应代码：
443 (Peer Address Family Mismatch): A peer address was of a different address family than that of the relayed transport address of the allocation.
443（对等地址族不匹配）：对等地址的地址族与分配的中继传输地址的地址族不同。
The behavior specified here affects the processing defined in Section 11 of [RFC5766].
此处指定的行为会影响[RFC5766]第11节中定义的处理。
The client MUST only include an XOR-PEER-ADDRESS attribute with an address of the same address family as that of the relayed transport address for the allocation.
客户端必须仅包含XOR-PEER-ADDRESS属性，该属性的地址族与分配的中继传输地址的地址族相同。
If the XOR-PEER-ADDRESS attribute contains an address of an address family different than that of the relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code, which is defined in Section 6.2.1.
如果XOR-PEER-ADDRESS属性包含不同于分配中继传输地址的地址系列的地址，则服务器必须使用第6.2.1节中定义的443（对等地址系列不匹配）响应代码生成错误响应。
The TURN specification [RFC5766] describes how TURN relays should relay traffic consisting of IPv4 packets (i.e., IPv4-to-IPv4 translations). The relay translates the IP addresses and port numbers of the packets based on the allocation's state data. How to translate other header fields is also specified in [RFC5766]. This document addresses IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6 translations.
TURN规范[RFC5766]描述了TURN中继如何中继由IPv4数据包组成的通信量（即IPv4到IPv4的转换）。中继根据分配的状态数据转换数据包的IP地址和端口号。[RFC5766]中还规定了如何翻译其他标题字段。本文档介绍IPv4到IPv6、IPv6到IPv4和IPv6到IPv6的转换。
TURN relays performing any translation MUST translate the IP addresses and port numbers of the packets based on the allocation's state information as specified in [RFC5766]. The following sections specify how to translate other header fields.
执行任何转换的转向继电器必须根据[RFC5766]中规定的分配状态信息转换数据包的IP地址和端口号。以下各节指定如何转换其他标题字段。
As discussed in Section 2.6 of [RFC5766], translations in TURN are designed so that a TURN server can be implemented as an application that runs in "user-land" under commonly available operating systems and that does not require special privileges. The translations specified in the following sections follow this principle.
如[RFC5766]第2.6节所述，反过来，翻译的设计使得TURN服务器可以作为一个应用程序来实现，该应用程序在通用操作系统下的“用户区域”中运行，并且不需要特殊权限。以下章节中指定的翻译遵循这一原则。
The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior. Otherwise, the server MUST implement the alternate behavior and MUST NOT do anything else.
下面的描述分为两部分：首选行为和备用行为。服务器应该实现首选行为。否则，服务器必须实现替代行为，并且不得执行任何其他操作。
Traffic Class
交通等级
Preferred behavior: as specified in Section 4 of [RFC6145].
首选行为：如[RFC6145]第4节所述。
Alternate behavior: the relay sets the Traffic Class to the default value for outgoing packets.
替代行为：中继将流量类设置为传出数据包的默认值。
Flow Label
流标签
Preferred behavior: the relay sets the Flow label to 0. The relay can choose to set the Flow label to a different value if it supports the IPv6 Flow Label field [RFC3697].
首选行为：继电器将流标签设置为0。如果中继支持IPv6流标签字段[RFC3697]，则可以选择将流标签设置为其他值。
Alternate behavior: the relay sets the Flow label to the default value for outgoing packets.
替代行为：中继将流标签设置为传出数据包的默认值。
Hop Limit
跳数限制
Preferred behavior: as specified in Section 4 of [RFC6145].
首选行为：如[RFC6145]第4节所述。
Alternate behavior: the relay sets the Hop Limit to the default value for outgoing packets.
替代行为：中继将跳转限制设置为传出数据包的默认值。
Fragmentation
碎裂
Preferred behavior: as specified in Section 4 of [RFC6145].
首选行为：如[RFC6145]第4节所述。
Alternate behavior: the relay assembles incoming fragments. The relay follows its default behavior to send outgoing packets.
替代行为：中继组装传入的片段。中继遵循其默认行为发送传出数据包。
For both preferred and alternate behavior, the DONT-FRAGMENT attribute ([RFC5766], Section 14.8) MUST be ignored by the server.
对于首选和备用行为，服务器必须忽略DONT-FRAGMENT属性（[RFC5766]，第14.8节）。
Extension Headers
扩展头
Preferred behavior: the relay sends the outgoing packet without any IPv6 extension headers, with the exception of the Fragment Header as described above.
首选行为：中继发送不带任何IPv6扩展头的传出数据包，但如上所述的片段头除外。
Alternate behavior: same as preferred.
替代行为：与首选行为相同。
Flow Label
流标签
The relay should consider that it is handling two different IPv6 flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as part of the translation.
中继应该考虑它正在处理两个不同的IPv6流。因此，流标签[RFC3697]不应作为翻译的一部分进行复制。
Preferred behavior: the relay sets the Flow label to 0. The relay can choose to set the Flow label to a different value if it supports the IPv6 Flow Label field [RFC3697].
首选行为：继电器将流标签设置为0。如果中继支持IPv6流标签字段[RFC3697]，则可以选择将流标签设置为其他值。
Alternate behavior: the relay sets the Flow label to the default value for outgoing packets.
替代行为：中继将流标签设置为传出数据包的默认值。
Hop Limit
跳数限制
Preferred behavior: the relay acts as a regular router with respect to decrementing the Hop Limit and generating an ICMPv6 error if it reaches zero.
首选行为：中继充当常规路由器，减少跃点限制，并在达到零时生成ICMPv6错误。
Alternate behavior: the relay sets the Hop Limit to the default value for outgoing packets.
替代行为：中继将跳转限制设置为传出数据包的默认值。
Fragmentation
碎裂
Preferred behavior: if the incoming packet did not include a Fragment Header and the outgoing packet size does not exceed the outgoing link's MTU, the relay sends the outgoing packet without a Fragment Header.
首选行为：如果传入数据包不包括片段头，且传出数据包大小不超过传出链路的MTU，则中继发送不带片段头的传出数据包。
If the incoming packet did not include a Fragment Header and the outgoing packet size exceeds the outgoing link's MTU, the relay drops the outgoing packet and sends an ICMP message of Type 2, Code 0 ("Packet too big") to the sender of the incoming packet.
如果传入数据包不包括片段头，且传出数据包大小超过传出链路的MTU，则中继丢弃传出数据包，并向传入数据包的发送方发送类型2、代码0（“数据包太大”）的ICMP消息。
If the packet is being sent to the peer, the relay reduces the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.
如果数据包被发送到对等方，中继器会将ICMP消息中报告的MTU减少48字节，以便为数据指示的开销留出空间。
If the incoming packet included a Fragment Header and the outgoing packet size (with a Fragment Header included) does not exceed the outgoing link's MTU, the relay sends the outgoing packet with a Fragment Header. The relay sets the fields of the Fragment Header as appropriate for a packet originating from the server.
如果传入数据包包含一个片段头，并且传出数据包大小（包含一个片段头）不超过传出链路的MTU，则中继发送带有片段头的传出数据包。中继器将片段头的字段设置为适用于来自服务器的数据包。
If the incoming packet included a Fragment Header and the outgoing packet size exceeds the outgoing link's MTU, the relay MUST fragment the outgoing packet into fragments of no more than 1280 bytes. The relay sets the fields of the Fragment Header as appropriate for a packet originating from the server.
如果传入数据包包含一个片段头，并且传出数据包大小超过传出链路的MTU，则中继必须将传出数据包分成不超过1280字节的片段。中继器将片段头的字段设置为适用于来自服务器的数据包。
Alternate behavior: the relay assembles incoming fragments. The relay follows its default behavior to send outgoing packets.
替代行为：中继组装传入的片段。中继遵循其默认行为发送传出数据包。
For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server.
对于首选行为和备用行为，服务器必须忽略DONT-FRAGMENT属性。
Extension Headers
扩展头
Preferred behavior: the relay sends the outgoing packet without any IPv6 extension headers, with the exception of the Fragment Header as described above.
首选行为：中继发送不带任何IPv6扩展头的传出数据包，但如上所述的片段头除外。
Alternate behavior: same as preferred.
替代行为：与首选行为相同。
Type of Service and Precedence
服务类型和优先级
Preferred behavior: as specified in Section 5 of [RFC6145].
首选行为：如[RFC6145]第5节所述。
Alternate behavior: the relay sets the Type of Service and Precedence to the default value for outgoing packets.
替代行为：中继将服务类型和优先级设置为传出数据包的默认值。
Time to Live
活下去的时间
Preferred behavior: as specified in Section 5 of [RFC6145].
首选行为：如[RFC6145]第5节所述。
Alternate behavior: the relay sets the Time to Live to the default value for outgoing packets.
替代行为：中继将传出数据包的生存时间设置为默认值。
Fragmentation
碎裂
Preferred behavior: as specified in Section 5 of [RFC6145]. Additionally, when the outgoing packet's size exceeds the outgoing link's MTU, the relay needs to generate an ICMP error (ICMPv6 Packet Too Big) reporting the MTU size. If the packet is being sent to the peer, the relay SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.
首选行为：如[RFC6145]第5节所述。此外，当传出数据包的大小超过传出链路的MTU时，中继需要生成报告MTU大小的ICMP错误（ICMPv6数据包太大）。如果数据包被发送到对等方，中继应将ICMP消息中报告的MTU减少48字节，以便为数据指示的开销留出空间。
Alternate behavior: the relay assembles incoming fragments. The relay follows its default behavior to send outgoing packets.
替代行为：中继组装传入的片段。中继遵循其默认行为发送传出数据包。
For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server.
对于首选行为和备用行为，服务器必须忽略DONT-FRAGMENT属性。
Translation between IPv4 and IPv6 creates a new way for clients to obtain IPv4 or IPv6 access that they did not have before. For example, an IPv4-only client having access to a TURN server implementing this specification is now able to access the IPv6 Internet. This needs to be considered when establishing security and monitoring policies.
IPv4和IPv6之间的转换为客户端获得以前没有的IPv4或IPv6访问创建了一种新方法。例如，可以访问实现此规范的TURN服务器的仅IPv4客户端现在可以访问IPv6 Internet。在制定安全和监控策略时，需要考虑这一点。
The loop attack described in [RFC5766], Section 17.1.7, may be more easily done in cases where address spoofing is easier to accomplish over IPv6. Mitigation of this attack over IPv6 is the same as for IPv4.
[RFC5766]第17.1.7节中描述的循环攻击在IPv6上更容易实现地址欺骗的情况下可能更容易实现。IPv6上此攻击的缓解措施与IPv4相同。
All the security considerations applicable to STUN [RFC5389] and TURN [RFC5766] are applicable to this document as well.
适用于STUN[RFC5389]和TURN[RFC5766]的所有安全注意事项也适用于本文件。
An attacker might attempt to cause data packets to loop numerous times between a TURN server and a tunnel between IPv4 and IPv6. The attack goes as follows.
攻击者可能试图使数据包在TURN服务器和IPv4与IPv6之间的隧道之间循环多次。攻击如下。
Suppose an attacker knows that a tunnel endpoint will forward encapsulated packets from a given IPv6 address (this doesn't necessarily need to be the tunnel endpoint's address). Suppose he then spoofs these two packets from this address:
假设攻击者知道隧道端点将转发来自给定IPv6地址的封装数据包（不一定是隧道端点的地址）。假设他然后从这个地址欺骗这两个数据包：
1. An Allocate request asking for a v4 address, and
1. 请求v4地址的分配请求，以及
2. A ChannelBind request establishing a channel to the IPv4 address of the tunnel endpoint
2. 建立到隧道端点IPv4地址的通道的ChannelBind请求
Then he has set up an amplification attack:
然后他设置了一个放大攻击：
o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it to the tunnel endpoint.
o TURN中继将在v4中重新封装IPv6 UDP数据，并将其发送到隧道端点。
o The tunnel endpoint will decapsulate packets from the v4 interface and send them to v6.
o 隧道端点将从v4接口解除数据包的封装，并将其发送到v6。
So, if the attacker sends a packet of the following form:
因此，如果攻击者发送以下形式的数据包：
IPv6: src=2001:db9::1 dst=2001:db8::2 UDP: <ports> TURN: <channel id> IPv6: src=2001:db9::1 dst=2001:db8::2 UDP: <ports> TURN: <channel id> IPv6: src=2001:db9::1 dst=2001:db8::2 UDP: <ports> TURN: <channel id> ...
IPv6:src=2001:db9:：1 dst=2001:db8:：2 UDP:<port>TURN:<channel id>IPv6:src=2001:db9:：1 dst=2001:db8:：2 UDP:<port>TURN:<channel id>IPv6:src=2001:db9:：1 dst=2001:db8:：2 UDP:<port>TURN:<channel id>。。。
Then the TURN relay and the tunnel endpoint will send it back and forth until the last TURN header is consumed, at which point the TURN relay will send an empty packet that the tunnel endpoint will drop.
然后转向中继和隧道端点将来回发送它，直到最后一个转向报头被消耗，此时转向中继将发送隧道端点将丢弃的空数据包。
The amplification potential here is limited by the MTU, so it's not huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one amplification out of a 1500-byte packet. But the attacker could still increase traffic volume by sending multiple packets or by establishing multiple channels spoofed from different addresses behind the same tunnel endpoint.
这里的放大潜力受到MTU的限制，所以不会太大：IPv6+UDP+TURN需要334字节，因此您可以从1500字节的数据包中获得四对一的放大。但是，攻击者仍然可以通过发送多个数据包或在同一隧道端点后建立多个从不同地址伪造的通道来增加通信量。
The attack is mitigated as follows. It is RECOMMENDED that TURN relays not accept allocation or channel binding requests from addresses known to be tunneled, and that they not forward data to such addresses. In particular, a TURN relay MUST NOT accept Teredo or 6to4 addresses in these requests.
攻击减轻如下。建议TURN中继不接受来自已知隧道地址的分配或通道绑定请求，并且不将数据转发到此类地址。特别是，转向继电器在这些请求中不得接受Teredo或6to4地址。
IANA registered the following values under the "STUN Attributes" registry and under the "STUN Error Codes" registry.
IANA在“STUN属性”注册表和“STUN错误代码”注册表下注册了以下值。
0x0017: REQUESTED-ADDRESS-FAMILY
0x0017：请求的地址系列
440 Address Family not Supported 443 Peer Address Family Mismatch
440地址系列不受支持443对等地址系列不匹配
The authors would like to thank Alfred E. Heggestad, Dan Wing, Magnus Westerlund, Marc Petit-Huguenin, Philip Matthews, and Remi Denis-Courmont for their feedback on this document.
作者感谢Alfred E.Heggestad、Dan Wing、Magnus Westerlund、Marc Petit Hugunin、Philip Matthews和Remi Denis Courmont对本文件的反馈。
[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月。
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3697]Rajahalme，J.，Conta，A.，Carpenter，B.，和S.Deering，“IPv6流标签规范”，RFC 36972004年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月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
Authors' Addresses
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Oscar Novo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Oscar Novo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Oscar.Novo@ericsson.com
EMail: Oscar.Novo@ericsson.com
Simon Perreault (editor) Viagenie 2600 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
西蒙·佩雷尔特（编辑）维亚吉尼2600波尔。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