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
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のサポートが追加されます。 TURNにおけるIPv6のサポートは、IPv4からIPv6、IPv6の対のIPv6、およびIPv6からIPv4中継を含みます。この文書では、TURNのために要求さ-ADDRESS-FAMILY属性を定義します。 REQUESTED-アドレスファミリ属性は、クライアントが明示的に（例えば、TURNサーバに要求することができるIPv4専用ノードはIPv6アドレスを割り当てる）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/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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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]の周りにリレーを使用トラバーサルは、UDPまたはTCP上の着信データを受信するためのNATの背後にある要素を可能にするプロトコルです。これは、単一のピアへの接続の受信端にあることを望むエンドポイント非依存マッピング[RFC4787]せずNATの背後にある要素のために最も有用です。
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中継を定義します。この文書では、IPv4からIPv6、IPv6のツーのIPv6、およびIPv6からIPv4中継を含む、有効にするにはIPv6のサポートを追加します。この文書では、それは、クライアントが明示的にアドレスを要求することを可能にするオンにする拡張機能ですREQUESTED-ADDRESS-FAMILY属性は、TURNサーバーが割り当てられますタイプ定義（例えば、IPv4のみのノードがIPv6アドレスを割り当てるために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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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サーバーを希望する場合、それは、要求-ADDRESS-FAMILY属性を持つTURNサーバーに割り当て要求を送信します。 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サーバーは、要求-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サーバーが割り当て要求に応答してリレーされたトランスポート・アドレスを返します。この応答は、サーバがクライアントに割り当てられたIPアドレスとポートを示すXOR中継さ-ADDRESS属性が含まれています。
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属性を含みます。クライアントは、割り当て要求に複数のREQUESTED-ADDRESS-FAMILY属性を含んではいけません。割り当て要求を定式化するメカニズムは[RFC5766]のセクション6.1に記載されています。
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute.
クライアントは、ご予約-TOKEN属性を含む割り当て要求で要求-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属性の形式です。なお、TURN属性は、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]で指定されているように、0000と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.
家族：IPv4アドレスの0x01のとIPv6アドレスの0×02：このフィールドに定義されて、[RFC5389]で指定された2つの値は、セクション15.1があります。
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属性は、要求だけを割り当て中に存在してもよいです。
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サーバーが割り当て要求を処理します。それはRESERVATION-TOKENと要求-ADDRESS-FAMILYの両方が含まれている場合、サーバはエラーレスポンスを割り当てる400（不正な要求）で応答します。サーバは、要求・アドレスファミリ属性を理解していない場合は、[RFC5389]のルールに従う、それはエラーコード420（未知の属性）応答コードを持つ属性含む割り当てエラー応答を生成します。この応答は、未知のREQUESTED-ADDRESS-FAMILY属性をリストUNKNOWN-ATTRIBUTE属性が含まれています。
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・中継アドレス属性は、中継されたトランスポートアドレスに設定されています。
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中継さ-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.
サーバがクライアントから要求されたアドレスファミリをサポートしていない場合は、エラーレスポンスを割り当てて生成しなければならない、そしてそれは、セクション4.2で定義されている440（サポートされていないアドレスファミリ）応答コードとERROR-CODE属性を含まなければなりません。 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に記載されるように割り当てリフレッシュを実行するために、クライアントは、リフレッシュ要求を生成します。クライアントは、リフレッシュ要求のいずれかのREQUESTED-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属性が割り当てのために中継されるトランスポートアドレスとは異なるアドレスファミリのアドレスが含まれている場合は、サーバがで定義されている443（ピアアドレスファミリの不一致）応答コードとエラー応答を生成しなければなりません6.2.1。
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属性が割り当てのために中継されるトランスポートアドレスとは異なるアドレスファミリのアドレスが含まれている場合は、サーバがで定義されている443（ピアアドレスファミリの不一致）応答コードとエラー応答を生成しなければなりません6.2.1。
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].
優先行動：リレーは、リレーは、それがIPv6フローラベルフィールド[RFC3697]をサポートしている場合は別の値にフローラベルを設定することを選択できます0にフローラベルを設定します。
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フラグメント属性（[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.
リレーは、2つの異なるの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].
優先行動：リレーは、リレーは、それがIPv6フローラベルフィールド[RFC3697]をサポートしている場合は別の値にフローラベルを設定することを選択できます0にフローラベルを設定します。
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を超えた場合、リレーは、発信パケットを廃棄して、（「パケットが大きすぎる」）コード0の送信者にタイプ2の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.
パケットがピアに送信されている場合、リレーは、MTUはデータ表示のオーバーヘッドのためにスペースを確保するために48バイトICMPメッセージで報告低減します。
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フラグメント属性は、サーバによって無視されなければなりません。
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の巨大パケット）を生成する必要があります。パケットがピアに送信されている場合、MTUを減少させるはずであるリレーは、データ表示のオーバーヘッドのためにスペースを確保するために48バイトICMPメッセージで報告されました。
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フラグメント属性は、サーバによって無視されなければなりません。
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インターネットにアクセスすることが可能です。これは、セキュリティおよび監視ポリシーを確立する際に考慮する必要があります。
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.
[RFC5389]をSTUNと[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アドレスからカプセル化されたパケットを転送することを知っていると仮定します。彼はその後、このアドレスから、これら2つのパケットを偽装したとします
2. A ChannelBind request establishing a channel to the IPv4 address of the tunnel endpoint
トンネルエンドポイントのIPv4アドレスにチャネルを確立する。2. A 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：<ポート> TURN：<チャネルID>のIPv6：SRC = 2001：DB9 :: 1つのDST = 2001：DB8 :: 2 UDP <ポート> TURN：<チャネルID>のIPv6：SRC = 2001：DB9 :: 1つのDST = 2001：DB8 :: 2 UDP：<ポート> TURN：<チャネル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.
最終ターンヘッダが消費されるまで、TURNリレーおよびトンネルエンドポイントは、TURNリレーがトンネルエンドポイントが低下する空パケットを送信するその時点で、前後にそれを送信します。
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によって制限されているので、それは巨大ではありません：あなたは1500バイトのパケットのうち、4対1の増幅を得ることができるように、IPv6は+ UDP + TURNは、334のバイトをとります。しかし、攻撃者は、まだ複数のパケットを送信することにより、または同じトンネルエンドポイントの背後に別のアドレスから偽装された複数のチャネルを確立することにより、トラフィック量を増やすことができます。
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リレーがトンネリングされることが知られているアドレスからの割り当てやチャネル結合の要求を受け入れ、彼らはそのようなアドレスにデータを転送しないことではないことが推奨されます。特に、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：要求-ADDRESS-FAMILY
440 Address Family not Supported
443 Peer Address Family Mismatch
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.
作者はこのドキュメントの彼らのフィードバックのためにアルフレッドE. Heggestad、ダン・ウィング、マグヌスウェスター、マーク・プティ・Huguenin、フィリップ・マシューズ、およびレミデニス-Courmontに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、コンタ、A.、大工、B.、およびS.デアリング、 "IPv6のフローラベル仕様"、RFC 3697、2004年3月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサル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.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年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.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Oscar Novo Ericsson Hirsalantie 11 Jorvas 02420 Finland
オスカーノボエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Oscar.Novo@ericsson.com
メールアドレス：Oscar.Novo@ericsson.com
Simon Perreault (editor) Viagenie 2600 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
サイモン・ペロー（エディタ）Viagénie2600 BOUL。ローリエ、スイートD2-630ケベック、QC G1V 2M2カナダ
Phone: +1 418 656 9254 EMail: simon.perreault@viagenie.ca URI: http://www.viagenie.ca
電話：+1 418 656 9254 Eメール：URI simon.perreault@viagenie.ca：http://www.viagenie.ca