RFC 8261 - Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8261
タイトル : RFC 8261 - SCTPパケットのデータグラムトランスポート層セキュリティ（DTLS）カプセル化
翻訳編集 : 自動生成

[要約] RFC 8261は、SCTPパケットのDTLSカプセル化に関する仕様です。目的は、SCTPトラフィックをDTLSで保護することで、セキュリティを向上させることです。

Internet Engineering Task Force (IETF)                         M. Tuexen
Request for Comments: 8261              Muenster Univ. of Appl. Sciences
Category: Standards Track                                     R. Stewart
ISSN: 2070-1721                                            Netflix, Inc.
                                                                R. Jesup
                                                WorldGate Communications
                                                               S. Loreto
                                                                Ericsson
                                                           November 2017

Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets

SCTPパケットのデータグラムトランスポート層セキュリティ（DTLS）カプセル化

Abstract

概要

The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, the SCTP associations carried over DTLS can only be single-homed.

ストリーム制御伝送プロトコル（SCTP）は、ネットワークプロトコルIPv4またはIPv6の上で実行するように最初に定義されたトランスポートプロトコルです。このドキュメントでは、データグラムトランスポート層セキュリティ（DTLS）プロトコル上でSCTPを使用する方法について説明します。このドキュメントで説明されているカプセル化方法を使用すると、SCTPはDTLSの下で使用されているプロトコルを認識しません。したがって、明示的なIPアドレスをSCTP制御チャンクで使用することはできません。その結果、DTLSを介して伝送されるSCTPアソシエーションはシングルホームにしかできません。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8261.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8261で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Encapsulation and Decapsulation Procedure . . . . . . . . . .   3
   4.  General Considerations  . . . . . . . . . . . . . . . . . . .   4
   5.  DTLS Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  SCTP Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Overview

1. 概観

The Stream Control Transmission Protocol (SCTP) as defined in [RFC4960] is a transport protocol running on top of the network protocols IPv4 [RFC0791] or IPv6 [RFC8200]. This document specifies how SCTP is used on top of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.0 is defined in [RFC4347], and the latest version when this RFC was published, DTLS 1.2, is defined in [RFC6347]. This encapsulation is used, for example, within the WebRTC protocol suite (see [RTC-OVERVIEW] for an overview) for transporting non-SRTP data between browsers. The architecture of this stack is described in [DATA-CHAN].

[RFC4960]で定義されているStream Control Transmission Protocol（SCTP）は、ネットワークプロトコルIPv4 [RFC0791]またはIPv6 [RFC8200]の上で実行されるトランスポートプロトコルです。このドキュメントでは、SCTPがデータグラムトランスポート層セキュリティ（DTLS）プロトコルの上でどのように使用されるかを指定します。 DTLS 1.0は[RFC4347]で定義されており、このRFCが公開されたときの最新バージョンであるDTLS 1.2は[RFC6347]で定義されています。このカプセル化は、たとえば、ブラウザ間で非SRTPデータを転送するためにWebRTCプロトコルスイート（概要については[RTC-OVERVIEW]を参照）内で使用されます。このスタックのアーキテクチャは[DATA-CHAN]で説明されています。

                               +----------+
                               |   SCTP   |
                               +----------+
                               |   DTLS   |
                               +----------+
                               | ICE/UDP  |
                               +----------+

Figure 1: Basic Stack Diagram

図1：基本的なスタック図

This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see [RFC5245]) can provide a NAT traversal solution in addition to confidentiality, source authentication, and integrity-protected transfers. Please note that using ICE does not necessarily imply that a different packet format is used on the wire.

UDPまたはICE / UDPを介したDTPを介したSCTPのこのカプセル化（[RFC5245]を参照）は、機密性、ソース認証、および整合性保護された転送に加えて、NATトラバーサルソリューションを提供できます。 ICEを使用しても、ネットワーク上で別のパケット形式が使用されるとは限らないことに注意してください。

Please note that the procedures defined in [RFC6951] for dealing with the UDP port numbers do not apply here. When using the encapsulation defined in this document, SCTP is unaware about the protocols used below DTLS.

[RFC6951]で定義されているUDPポート番号の処理手順はここでは適用されないことに注意してください。このドキュメントで定義されているカプセル化を使用する場合、SCTPはDTLSの下で使用されるプロトコルを認識しません。

2. Conventions

2. 規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Encapsulation and Decapsulation Procedure

3. カプセル化とカプセル開放の手順

When an SCTP packet is provided to the DTLS layer, the complete SCTP packet, consisting of the SCTP common header and a number of SCTP chunks, is handled as the payload of the application-layer protocol of DTLS. When the DTLS layer has processed a DTLS record containing a message of the application-layer protocol, the payload is passed to the SCTP layer. The SCTP layer expects an SCTP common header followed by a number of SCTP chunks.

SCTPパケットがDTLS層に提供されると、SCTP共通ヘッダーと多数のSCTPチャンクで構成される完全なSCTPパケットが、DTLSのアプリケーション層プロトコルのペイロードとして処理されます。 DTLS層がアプリケーション層プロトコルのメッセージを含むDTLSレコードを処理すると、ペイロードがSCTP層に渡されます。 SCTP層は、SCTP共通ヘッダーの後にいくつかのSCTPチャンクが続くことを期待しています。

4. General Considerations

4. 一般的な考慮事項

An implementation of SCTP over DTLS MUST implement and use a path maximum transmission unit (MTU) discovery method that functions without ICMP to provide SCTP/DTLS with an MTU estimate. An implementation of "Packetization Layer Path MTU Discovery" [RFC4821] either in SCTP or DTLS is RECOMMENDED.

SCTP over DTLSの実装では、ICMPなしで機能するパス最大伝送ユニット（MTU）検出方法を実装して使用し、SCTP / DTLSにMTU推定値を提供する必要があります。 SCTPまたはDTLSでの「パケット化層パスMTU発見」[RFC4821]の実装が推奨されます。

The path MTU discovery is performed by SCTP when SCTP over DTLS is used for data channels (see Section 5 of [DATA-CHAN]).

パスMTU検出は、SCTP over DTLSがデータチャネルに使用される場合にSCTPによって実行されます（[DATA-CHAN]のセクション5を参照）。

5. DTLS Considerations

5. DTLSに関する考慮事項

The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD support the most recently published version of DTLS, which was DTLS 1.2 [RFC6347] when this RFC was published. In the absence of a revision to this document, the latter requirement applies to all future versions of DTLS when they are published as RFCs. This document will only be revised if a revision to DTLS or SCTP makes a revision to the encapsulation necessary.

DTLS実装はDTLS 1.0 [RFC4347]をサポートする必要があり、このRFCが公開されたときのDTLS 1.2 [RFC6347]であるDTLSの最新の公開バージョンをサポートする必要があります（SHOULD）。このドキュメントの改訂がない場合、後者の要件は、RFCとして公開されたときのDTLSの将来のすべてのバージョンに適用されます。このドキュメントは、DTLSまたはSCTPの改訂によりカプセル化の改訂が必要になった場合にのみ改訂されます。

SCTP performs segmentation and reassembly based on the path MTU. Therefore, the DTLS layer MUST NOT use any compression algorithm.

SCTPは、パスMTUに基づいてセグメンテーションと再構成を実行します。したがって、DTLSレイヤーは圧縮アルゴリズムを使用してはなりません（MUST NOT）。

The DTLS MUST support sending messages larger than the current path MTU. This might result in sending IP-level fragmented messages.

DTLSは、現在のパスMTUより大きいメッセージの送信をサポートする必要があります。これにより、IPレベルの断片化されたメッセージが送信される可能性があります。

If path MTU discovery is performed by the DTLS layer, the method described in [RFC4821] MUST be used. For probe packets, the extension defined in [RFC6520] MUST be used.

パスMTU発見がDTLS層によって実行される場合、[RFC4821]で説明されている方法を使用する必要があります。プローブパケットについては、[RFC6520]で定義されている拡張機能を使用する必要があります。

If path MTU discovery is performed by the SCTP layer and IPv4 is used as the network-layer protocol, the DTLS implementation SHOULD allow the DTLS user to enforce that the corresponding IPv4 packet is sent with the Don't Fragment (DF) bit set. If controlling the DF bit is not possible (for example, due to implementation restrictions), a safe value for the path MTU has to be used by the SCTP stack. It is RECOMMENDED that the safe value not exceed 1200 bytes. Please note that [RFC1122] only requires that end hosts be able to reassemble fragmented IP packets up to 576 bytes in length.

パスMTUディスカバリーがSCTPレイヤーによって実行され、IPv4がネットワークレイヤープロトコルとして使用されている場合、DTLS実装は、DTLSユーザーが対応するIPv4パケットがDo n't Fragment（DF）ビットセットで送信されることを強制できるようにする必要があります。 DFビットを制御できない場合（たとえば、実装の制限のため）、パスMTUの安全な値をSCTPスタックで使用する必要があります。安全な値が1200バイトを超えないようにすることをお勧めします。 [RFC1122]では、エンドホストが最大576バイトの長さの断片化されたIPパケットを再構成できることだけが必要であることに注意してください。

The DTLS implementation SHOULD allow the DTLS user to set the Differentiated Services Code Point (DSCP) used for IP packets being sent (see [RFC2474]). This requires the DTLS implementation to pass the value through and the lower layer to allow setting this value. If the lower layer does not support setting the DSCP, then the DTLS user will end up with the default value used by the protocol stack. Please note that only a single DSCP value can be used for all packets belonging to the same SCTP association.

DTLS実装は、DTLSユーザーが送信されるIPパケットに使用されるDiffServコードポイント（DSCP）を設定できるようにする必要があります（SHOULD）（[RFC2474]を参照）。これには、DTLS実装が値を渡す必要があり、下位層がこの値を設定できるようにする必要があります。下位層がDSCPの設定をサポートしていない場合、DTLSユーザーはプロトコルスタックで使用されるデフォルト値で終了します。同じSCTPアソシエーションに属するすべてのパケットに使用できるDSCP値は1つだけであることに注意してください。

Using Explicit Congestion Notification (ECN) in SCTP requires the DTLS layer to pass the ECN bits through and its lower layer to expose access to them for sent and received packets (see [RFC3168]). The implementations of DTLS and its lower layer have to provide this support. If this is not possible (for example, due to implementation restrictions), ECN can't be used by SCTP.

SCTPで明示的輻輳通知（ECN）を使用するには、DTLSレイヤーがECNビットを渡す必要があり、その下位レイヤーが送受信パケットのアクセスを公開する必要があります（[RFC3168]を参照）。 DTLSとその下位層の実装は、このサポートを提供する必要があります。これが不可能な場合（たとえば、実装の制限のため）、SCTPはECNを使用できません。

6. SCTP Considerations

6. SCTPに関する考慮事項

This section describes the usage of the base protocol and the applicability of various SCTP extensions.

このセクションでは、基本プロトコルの使用法と、さまざまなSCTP拡張機能の適用性について説明します。

6.1. Base Protocol

6.1. 基本プロトコル

This document uses SCTP [RFC4960] with the following restrictions, which are required to reflect that the lower layer is DTLS instead of IPv4 and IPv6 and that SCTP does not deal with the IP addresses or the transport protocol used below DTLS:

このドキュメントでは、SCTP [RFC4960]を次の制限付きで使用しています。これは、下位層がIPv4およびIPv6ではなくDTLSであり、SCTPがDTLSの下で使用されるIPアドレスまたはトランスポートプロトコルを処理しないことを反映するために必要です。

o A DTLS connection MUST be established before an SCTP association can be set up.

o SCTPアソシエーションを設定する前に、DTLS接続を確立する必要があります。

o Multiple SCTP associations MAY be multiplexed over a single DTLS connection. The SCTP port numbers are used for multiplexing and demultiplexing the SCTP associations carried over a single DTLS connection.

o 複数のSCTPアソシエーションは、単一のDTLS接続を介して多重化される場合があります。 SCTPポート番号は、単一のDTLS接続で伝送されるSCTPアソシエーションを多重化および逆多重化するために使用されます。

o All SCTP associations are single-homed, because DTLS does not expose any address management to its upper layer. Therefore, it is RECOMMENDED to set the SCTP parameter path.max.retrans to association.max.retrans.

o DTLSはアドレス管理を上位層に公開しないため、すべてのSCTPアソシエーションはシングルホームです。したがって、SCTPパラメータpath.max.retransをAssociation.max.retransに設定することをお勧めします。

o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or IPv6 Address parameters. The INIT chunk MUST NOT contain the Supported Address Types parameter.

o INITおよびINIT-ACKチャンクには、IPv4アドレスまたはIPv6アドレスパラメータを含めてはなりません。 INITチャンクには、Supported Address Typesパラメータを含めることはできません。

o The implementation MUST NOT rely on processing ICMP or ICMPv6 packets, since the SCTP layer most likely is unable to access the SCTP common header in the plain text of the packet, which triggered the sending of the ICMP or ICMPv6 packet. This applies in particular to path MTU discovery when performed by SCTP.

o 実装はICMPまたはICMPv6パケットの処理に依存してはなりません。これは、SCTPレイヤーがパケットのプレーンテキストのSCTP共通ヘッダーにアクセスできず、ICMPまたはICMPv6パケットの送信がトリガーされたためです。これは、SCTPによって実行される場合、特にパスMTU検出に適用されます。

o If the SCTP layer is notified about a path change by its lower layers, SCTP SHOULD retest the path MTU and reset the congestion state to the initial state. The window-based congestion control method specified in [RFC4960] resets the congestion window and slow-start threshold to their initial values.

o SCTP層は、下位層からパス変更について通知を受けた場合、パスMTUを再テストして、輻輳状態を初期状態にリセットする必要があります（SHOULD）。 [RFC4960]で指定されたウィンドウベースの輻輳制御方法は、輻輳ウィンドウとスロースタートしきい値を初期値にリセットします。

6.2. Padding Extension

6.2. パディング拡張

When the SCTP layer performs path MTU discovery as specified in [RFC4821], the padding extension defined in [RFC4820] MUST be supported and used for probe packets (HEARTBEAT chunks bundled with PADDING chunks [RFC4820]).

[RFC4821]で指定されているようにSCTPレイヤーがパスMTUディスカバリを実行する場合、[RFC4820]で定義されたパディング拡張がサポートされ、プローブパケット（PADDINGチャンク[RFC4820]にバンドルされたHEARTBEATチャンク）に使用される必要があります。

6.3. Dynamic Address Reconfiguration Extension

6.3. 動的アドレス再構成拡張

If the dynamic address reconfiguration extension defined in [RFC5061] is used, ASCONF chunks MUST use wildcard addresses only.

[RFC5061]で定義されている動的アドレス再構成拡張が使用される場合、ASCONFチャンクはワイルドカードアドレスのみを使用する必要があります。

6.4. SCTP Authentication Extension

6.4. SCTP認証拡張

The SCTP authentication extension defined in [RFC4895] can be used with DTLS encapsulation, but does not provide any additional benefit.

[RFC4895]で定義されているSCTP認証拡張は、DTLSカプセル化で使用できますが、追加の利点はありません。

6.5. Partial Reliability Extension

6.5. 部分信頼性拡張

Partial reliability as defined in [RFC3758] can be used in combination with DTLS encapsulation. It is also possible to use additional Partially Reliable Stream Control Transmission Protocol (PR-SCTP) policies, for example, the ones defined in [RFC7496].

[RFC3758]で定義されている部分信頼性は、DTLSカプセル化と組み合わせて使用できます。 [RFC7496]で定義されているポリシーなど、追加の部分的に信頼できるストリーム制御伝送プロトコル（PR-SCTP）ポリシーを使用することもできます。

6.6. Stream Reset Extension

6.6. ストリームリセット拡張

The SCTP stream reset extension defined in [RFC6525] can be used with DTLS encapsulation. It is used to reset SCTP streams and add SCTP streams during the lifetime of the SCTP association.

[RFC6525]で定義されているSCTPストリームリセット拡張機能は、DTLSカプセル化で使用できます。 SCTPストリームをリセットし、SCTPアソシエーションのライフタイム中にSCTPストリームを追加するために使用されます。

6.7. Interleaving of Large User Messages

6.7. 大きなユーザーメッセージのインターリーブ

SCTP as defined in [RFC4960] does not support the interleaving of large user messages that need to be fragmented and reassembled by the SCTP layer. The protocol extension defined in [RFC8260] overcomes this limitation and can be used with DTLS encapsulation.

[RFC4960]で定義されているSCTPは、SCTPレイヤーでフラグメント化および再構成する必要がある大きなユーザーメッセージのインターリーブをサポートしていません。 [RFC8260]で定義されたプロトコル拡張は、この制限を克服し、DTLSカプセル化で使用できます。

7. IANA Considerations

7. IANAに関する考慮事項

This document does not require any IANA actions.

このドキュメントでは、IANAアクションは必要ありません。

8. Security Considerations

8. セキュリティに関する考慮事項

Security considerations for DTLS are specified in [RFC4347] and for SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP and DTLS introduces no new security considerations.

DTLSのセキュリティに関する考慮事項は、[RFC4347]と[RFC4960]、[RFC3758]、および[RFC6525]のSCTPで指定されています。 SCTPとDTLSを組み合わせても、新しいセキュリティ上の考慮事項はありません。

SCTP should not process the IP addresses used for the underlying communication since DTLS provides no guarantees about them.

DTLSはIPアドレスを保証しないため、SCTPは基礎となる通信に使用されるIPアドレスを処理しないでください。

It should be noted that the inability to process ICMP or ICMPv6 messages does not add any security issue. When SCTP is carried over a connection-less lower layer like IPv4, IPv6, or UDP, processing of these messages is required to protect other nodes not supporting SCTP. Since DTLS provides a connection-oriented lower layer, this kind of protection is not necessary.

ICMPまたはICMPv6メッセージを処理できなくても、セキュリティ上の問題は発生しないことに注意してください。 SCTPがIPv4、IPv6、UDPなどのコネクションレス型の下位層で実行される場合、SCTPをサポートしていない他のノードを保護するために、これらのメッセージの処理が必要です。 DTLSは接続指向の下位層を提供するため、この種の保護は必要ありません。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, <https://www.rfc-editor.org/info/rfc4347>.

[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、DOI 10.17487 / RFC4347、2006年4月、<https://www.rfc-editor.org/info/rfc4347>。

[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, <https://www.rfc-editor.org/info/rfc4820>.

[RFC4820] Tuexen、M.、Stewart、R。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）のパディングチャンクとパラメータ」、RFC 4820、DOI 10.17487 / RFC4820、2007年3月、<https：// www.rfc-editor.org/info/rfc4820>。

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。

[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。

[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <https://www.rfc-editor.org/info/rfc6520>.

[RFC6520] Seggelmann、R.、Tuexen、M。、およびM. Williams、「Transport Layer Security（TLS）and Datagram Transport Layer Security（DTLS）Heartbeat Extension」、RFC 6520、DOI 10.17487 / RFC6520、2012年2月、<https ：//www.rfc-editor.org/info/rfc6520>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

9.2. Informative References

9.2. 参考引用

[DATA-CHAN] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, draft-ietf-rtcweb-data-channel-13, January 2015.

[DATA-CHAN] Jesup、R.、Loreto、S。、およびM. Tuexen、「WebRTCデータチャネル」、Work in Progress、draft-ietf-rtcweb-data-channel-13、2015年1月。

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。

[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, <https://www.rfc-editor.org/info/rfc3758>.

[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「Stream Control Transmission Protocol（SCTP）Partial Reliability Extension」、RFC 3758、DOI 10.17487 / RFC3758、May 2004、<https://www.rfc-editor.org/info/rfc3758>。

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.

[RFC4895] Tuexen、M.、Stewart、R.、Lei、P。、およびE. Rescorla、「Authenticated Chunks for the Stream Control Transmission Protocol（SCTP）」、RFC 4895、DOI 10.17487 / RFC4895、2007年8月、<https ：//www.rfc-editor.org/info/rfc4895>。

[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/RFC5061, September 2007, <https://www.rfc-editor.org/info/rfc5061>.

[RFC5061] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（SCTP）Dynamic Address Reconfiguration」、RFC 5061、DOI 10.17487 / RFC5061、9月2007、<https://www.rfc-editor.org/info/rfc5061>。

[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.

[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<https：// www .rfc-editor.org / info / rfc5245>。

[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, DOI 10.17487/RFC6525, February 2012, <https://www.rfc-editor.org/info/rfc6525>.

[RFC6525] Stewart、R.、Tuexen、M。、およびP. Lei、「Stream Control Transmission Protocol（SCTP）Stream Reconfiguration」、RFC 6525、DOI 10.17487 / RFC6525、2012年2月、<https：//www.rfc- editor.org/info/rfc6525>。

[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.

[RFC6951] Tuexen、M。、およびR. Stewart、「エンドホストからエンドホストへの通信用のストリーム制御伝送プロトコル（SCTP）パケットのUDPカプセル化」、RFC 6951、DOI 10.17487 / RFC6951、2013年5月、<https：/ /www.rfc-editor.org/info/rfc6951>。

[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, <https://www.rfc-editor.org/info/rfc7496>.

[RFC7496] Tuexen、M.、Seggelmann、R.、Stewart、R。、およびS. Loreto、「Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension」、RFC 7496、DOI 10.17487 / RFC7496、2015年4月、<https ：//www.rfc-editor.org/info/rfc7496>。

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。

[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, November 2017.

[RFC8260] Stewart、R.、Tuexen、M.、Loreto、S。、およびR. Seggelmann、「Stream Scheduler and User Message Interleaving for the Stream Control Transmission Protocol」、RFC 8260、2017年11月。

[RTC-OVERVIEW] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-18, March 2017.

[RTC-OVERVIEW] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-ietf-rtcweb-overview-18、2017年3月。

Acknowledgments

謝辞

The authors wish to thank David Black, Benoit Claise, Spencer Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch, and Magnus Westerlund for their invaluable comments.

著者は、David Black、Benoit Claise、Spencer Dawkins、Francis Dupont、Gorry Fairhurst、Stephen Farrell、Christer Holmberg、Barry Leiba、Eric Rescorla、Tom Taylor、Joe Touch、およびMagnus Westerlundの貴重なコメントに感謝します。

Authors' Addresses

著者のアドレス

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany

Michael Tuexen Muenster応用科学大学Stegerwaldstrasse 39 48565シュタインフルトドイツ

   Email: tuexen@fh-muenster.de

Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America

Randall R. Stewart Netflix、Inc. Chapin、SC 29036アメリカ合衆国

   Email: randall@lakerest.net

Randell Jesup WorldGate Communications 3800 Horizon Blvd, Suite #103 Trevose, PA 19053-4947 United States of America

Randell Jesup WorldGate Communications 3800 Horizon Blvd、Suite＃103 Trevose、PA 19053-4947アメリカ合衆国

   Phone: +1-215-354-5166
   Email: randell-ietf@jesup.org

Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland

Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420フィンランド

   Email: Salvatore.Loreto@ericsson.com