RFC 5766 - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

• ステータス: Proposed Standard
• 発行日: April 2010
• ストリーム: IETF
• 廃止: RFC8656
• エラッタ: エラッタなし

---

概要 (Abstract)

ホストがNATの背後に位置する場合、特定の状況において、そのホストが他のホスト (ピア (Peers)) と直接通信することが不可能な場合があります。このような状況では、ホストは通信リレーとして機能する中間ノードのサービスを使用する必要があります。本仕様は、TURN (Traversal Using Relays around NAT、NAT越えのリレーによるトラバーサル) と呼ばれるプロトコルを定義します。このプロトコルにより、ホストはリレーの動作を制御し、リレーを使用してピアとパケットを交換することができます。TURNは、クライアントが単一のリレーアドレスを使用して複数のピアと通信できる点で、他のリレー制御プロトコルとは異なります。

TURNプロトコルは、ICE (Interactive Connectivity Establishment、対話的接続確立) NATトラバーサル方式の一部として使用されるように設計されていますが、ICEなしでも使用できます。

---

目次 (Table of Contents)

• 1. Introduction (はじめに)
• 2. Overview of Operation (動作の概要)
  • 2.1 Transports (トランスポート)
  • 2.2 Allocations (アロケーション)
  • 2.3 Permissions (パーミッション)
  • 2.4 Send Mechanism (送信メカニズム)
  • 2.5 Channels (チャネル)
  • 2.6 Unprivileged TURN Servers (非特権TURNサーバー)
  • 2.7 Avoiding IP Fragmentation (IPフラグメンテーションの回避)
  • 2.8 RTP Support (RTPサポート)
  • 2.9 Anycast Discovery of Servers (サーバーのエニーキャスト発見)
• 3. Terminology (用語)
• 4. General Behavior (一般的な動作)
• 5. Allocations (アロケーション)
• 6. Creating an Allocation (アロケーションの作成)
  • 6.1 Sending an Allocate Request (Allocateリクエストの送信)
  • 6.2 Receiving an Allocate Request (Allocateリクエストの受信)
  • 6.3 Receiving an Allocate Success Response (Allocate成功レスポンスの受信)
  • 6.4 Receiving an Allocate Error Response (Allocateエラーレスポンスの受信)
• 7. Refreshing an Allocation (アロケーションのリフレッシュ)
  • 7.1 Sending a Refresh Request (Refreshリクエストの送信)
  • 7.2 Receiving a Refresh Request (Refreshリクエストの受信)
  • 7.3 Receiving a Refresh Response (Refreshレスポンスの受信)
• 8. Permissions (パーミッション)
• 9. CreatePermission (パーミッションの作成)
  • 9.1 Forming a CreatePermission Request (CreatePermissionリクエストの構築)
  • 9.2 Receiving a CreatePermission Request (CreatePermissionリクエストの受信)
  • 9.3 Receiving a CreatePermission Response (CreatePermissionレスポンスの受信)
• 10. Send and Data Methods (SendとDataメソッド)
  • 10.1 Forming a Send Indication (Send指示の構築)
  • 10.2 Receiving a Send Indication (Send指示の受信)
  • 10.3 Receiving a UDP Datagram (UDPデータグラムの受信)
  • 10.4 Receiving a Data Indication (Data指示の受信)
• 11. Channels (チャネル)
  • 11.1 Sending a ChannelBind Request (ChannelBindリクエストの送信)
  • 11.2 Receiving a ChannelBind Request (ChannelBindリクエストの受信)
  • 11.3 Receiving a ChannelBind Response (ChannelBindレスポンスの受信)
  • 11.4 The ChannelData Message (ChannelDataメッセージ)
  • 11.5 Sending a ChannelData Message (ChannelDataメッセージの送信)
  • 11.6 Receiving a ChannelData Message (ChannelDataメッセージの受信)
  • 11.7 Relaying Data from the Peer (ピアからのデータのリレー)
• 12. IP Header Fields (IPヘッダーフィールド)
• 13. New STUN Methods (新しいSTUNメソッド)
• 14. New STUN Attributes (新しいSTUN属性)
  • 14.1 CHANNEL-NUMBER
  • 14.2 LIFETIME
  • 14.3 XOR-PEER-ADDRESS
  • 14.4 DATA
  • 14.5 XOR-RELAYED-ADDRESS
  • 14.6 EVEN-PORT
  • 14.7 REQUESTED-TRANSPORT
  • 14.8 DONT-FRAGMENT
  • 14.9 RESERVATION-TOKEN
• 15. New STUN Error Response Codes (新しいSTUNエラーレスポンスコード)
• 16. Detailed Example (詳細な例)
• 17. Security Considerations (セキュリティに関する考察)
  • 17.1 Outsider Attacks (外部攻撃)
  • 17.2 Firewall Considerations (ファイアウォールに関する考察)
  • 17.3 Insider Attacks (内部攻撃)
  • 17.4 Other Considerations (その他の考察)
• 18. IANA Considerations (IANAに関する考察)
• 19. IAB Considerations (IABに関する考察)
• 20. Acknowledgements (謝辞)
• 21. References (参考文献)
  • 21.1 Normative References (規範的参考文献)
  • 21.2 Informative References (情報的参考文献)

---

関連リソース

• 公式RFC: RFC 5766
• 公式ページ: RFC 5766 DataTracker
• 更新版: RFC 8656
• 正誤表: RFC Editor Errata

---