[要約] RFC 6156は、IPv6におけるNATトラバーサルをサポートするためのTURN拡張です。その目的は、IPv6ネットワーク上でのエンドツーエンドの通信を可能にすることです。
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（ターン）拡張の周りのリレーを使用したトラバーサル
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（ターン）の周りのリレーを使用して、トラバーサルにIPv6サポートを追加します。IPv6サポートには、IPv4-to-IPV6、IPv6-to-IPV6、およびIPv6-to-IPV4リレーが含まれます。このドキュメントは、要求されたアドレスファミリー属性のターンを定義します。要求されたアドレス-S-Family属性により、クライアントはターンサーバーが割り当てられるアドレスタイプを明示的に要求できます（たとえば、IPv4のみのノードがターンサーバーに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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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（ターン）[RFC5766]の周りのリレーを使用したトラバーサルは、NATの背後にある要素がUDPまたはTCPを介して着信データを受信できるプロトコルです。これは、単一のピアへの接続の受信側になりたいエンドポイントに依存しないマッピング[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.
ターン[RFC5766]のベース仕様は、IPv4-to-IPV4リレーのみを定義します。このドキュメントは、IPv4-to-IPV6、IPv6-to-IPV6、およびIPv6-to-IPV4リレーを含むIPv6サポートをターンに追加します。このドキュメントでは、要求されたアドレスとファミリーの属性を定義します。これは、クライアントがターンサーバーが割り当てられるアドレスタイプを明示的にリクエストできるようにするターンの拡張機能です（たとえば、IPv4のみのノードがターンサーバーに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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
ユーザーがターンサーバーに特定のタイプのアドレスを割り当てることを希望する場合、要求されたアドレス-ファミリー属性を使用してターンサーバーに割り当て要求を送信します。ターンは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.
リクエストが正常に認証された後、ターンサーバーは、要求されたアドレスファミリー属性に示されているタイプのトランスポートアドレスを割り当てます。このアドレスは、中継輸送アドレスと呼ばれます。
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.
ターンサーバーは、割り当てリクエストへの応答で中継されたトランスポートアドレスを返します。この応答には、サーバーがクライアントに割り当てたIPアドレスとポートを示すXORリレードアドレス属性が含まれています。
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).
ターンサーバーは、割り当て要求ごとに単一のリレー輸送アドレスを割り当てます。したがって、リクエストを割り当てることは、複数の要求されたアドレスとファミリーの属性を運ぶことはできません。したがって、ターンサーバーで複数のリレー輸送アドレスを割り当てたいクライアント（例：IPv4やIPv6アドレス）は、いくつかの割り当て要求を実行する必要があります（リレー輸送アドレスごとに1つの割り当て要求）。
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.
アドレスファミリのセットをサポートするターンサーバーは、それらの間でパケットを中継できると想定されています。サーバーがクライアントから要求されたアドレスファミリをサポートしていない場合、サーバーは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].
特定のアドレスタイプの中継輸送アドレスを取得したいクライアントには、ターンサーバーに送信される割り当て要求で、セクション4.1.1で定義されている要求されたアドレス-Dress-Family属性が含まれます。クライアントは、割り当てリクエストに複数の要求されたアドレスとファミリーの属性を含めるべきではありません。割り当て要求を策定するメカニズムは、[RFC5766]のセクション6.1で説明されています。
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute.
クライアントは、予約トークン属性を含む割り当て要求に要求されたアドレスファミリー属性を含めるべきではありません。
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.
リクエストされたアドレスとファミリーの属性は、サーバーから特定のアドレスタイプの割り当てを要求するためにクライアントによって使用されます。以下は、要求されたアドレス-ファミリー属性の形式です。ターン属性は、16ビットのタイプ、16ビットの長さ、可変長い値を備えたTLV（タイプ長値）エンコードされていることに注意してください。
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：要求されたアドレスファミリー属性の形式
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.
タイプ：リクエストされたアドレスとファミリーの属性のタイプは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.
ファミリ：このフィールドには2つの値が定義されており、[RFC5389]で指定されています。IPv4アドレスのセクション15.1：0x01、IPv6アドレスの場合は0x02です。
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.
リクエストアドレスタイプの属性は、割り当てリクエストにのみ存在する場合があります。
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.
サーバーがリクエストが認証され、改ざんされていないことを確認したら、ターンサーバーは割り当て要求を処理します。予約トークンと要求されたアドレスファミリーの両方が含まれている場合、サーバーは400（悪い要求）を割り当ててエラー応答を割り当てます。[rfc5389]のルールに従って、サーバーが要求されたアドレスとファミリーの属性を理解していない場合、420（不明な属性）応答コードを持つエラーコード属性を含む割り当てエラー応答を生成します。この応答には、未知の要求されたアドレスファミリー属性をリストする未知の属性属性が含まれます。
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.
サーバーがリクエストを正常に処理できる場合、リレー輸送アドレスと呼ばれるターンクライアントのトランスポートアドレスを割り当て、割り当てリクエストへの応答で返します。
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]で指定されているように、Alocate応答には、Alocateリクエストに含まれる同じトランザクション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-Relayed-Address属性は、割り当てられたIPアドレスとポートを示します。Xor-Mapp-Address [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.
要求されたアドレス-Family属性が存在しない場合、サーバーはターンクライアントに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.
サーバーがクライアントが要求したアドレスファミリをサポートしていない場合、Allocateエラー応答を生成する必要があり、セクション4.2で定義されている440（アドレスファミリではない）応答コードを含むエラーコード属性を含める必要があります。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で説明されているように更新要求を生成します。クライアントは、リクエストされたアドレスファミリー属性を更新リクエストに含めるべきではありません。
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.
サーバーがリクエストされたアドレス-Dress-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.
ターン仕様[RFC5766]は、IPv4パケット（つまり、IPv4-to-IPV4翻訳）で構成されるターンリレーがどのようにリレーするべきかを説明しています。リレーは、割り当ての状態データに基づいて、パケットのIPアドレスとポート番号を変換します。他のヘッダーフィールドを翻訳する方法は、[RFC5766]でも指定されています。このドキュメントは、IPv4-to-IPV6、IPv6-to-IPV4、およびIPv6-to-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で説明したように、翻訳は、一般的に利用可能なオペレーティングシステムの下で「ユーザーランド」で実行され、特別な特権を必要としないアプリケーションとしてターンサーバーを実装できるように設計されています。次のセクションで指定されている翻訳は、この原則に従います。
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.
以下の説明には、好みの動作と別の動作の2つの部分があります。サーバーは、優先動作を実装する必要があります。それ以外の場合、サーバーは代替動作を実装する必要があり、他に何もしてはなりません。
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.
リレーは、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].
優先挙動：リレーはフローラベルを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の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.
優先挙動と代替動作の両方について、サーバーは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.
優先挙動と代替動作の両方について、サーバーは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アクセスを取得するための新しい方法を作成します。たとえば、この仕様を実装するターンサーバーにアクセスできる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.
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.
攻撃者は、データパケットがターンサーバーと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つのパケットをproofしていると仮定します。
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アドレスへのチャネルを確立するチャンネルバインドリクエスト
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 ターンリレーは、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>
...
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ターンには334バイトがかかるため、1500バイトのパケットから4対1の増幅を得ることができます。しかし、攻撃者は、複数のパケットを送信するか、同じトンネルエンドポイントの背後にある異なるアドレスからスプーフィングされた複数のチャネルを確立することにより、トラフィック量を増やすことができます。
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.
攻撃は次のように軽減されます。ターンリレーは、トンネルであることが知られているアドレスからの割り当てまたはチャネルバインディングリクエストを受け入れず、そのようなアドレスにデータを転送しないことをお勧めします。特に、ターンリレーは、これらのリクエストで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.
著者は、この文書に関するフィードバックをしてくれたアルフレッド・E・ヘグスタッド、ダン・ウィング、マグナス・ウェスターランド、マグナス・ウェスターランド、マルク・ペチ・フーゲニン、フィリップ・マシューズ、レミ・デニス・コールモントに感謝したいと思います。
[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 3697、2004年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周辺のリレーを使用したトラバーサル：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 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. Jennings、「Unicast 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
Oscar Novo Ericsson Hirsalantie 11 Jorvas 02420 Finland
オスカー・ノヴォ・エリクソン・ヒルサラティエ11ジョルヴァス02420フィンランド
EMail: Oscar.Novo@ericsson.com
Simon Perreault (editor) Viagenie 2600 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
Simon Perreault（編集者）Viagenie 2600 Boul。ローリエ、スイートD2-630ケベック、QC G1V 2M2カナダ
Phone: +1 418 656 9254
EMail: simon.perreault@viagenie.ca
URI: http://www.viagenie.ca