[要約] RFC 8832は、WebRTC Data Channel Establishment Protocol (DCEP) に関する文書です。このプロトコルの主な目的は、WebRTCアプリケーション内でのデータチャネルの確立と管理を行うためのメカニズムを提供することにあります。利用場面としては、ブラウザ間やブラウザとサーバー間でのリアルタイム通信において、テキストやファイルの送受信、ストリーミングデータの共有などが挙げられます。関連するRFCには、WebRTCのコアを定義するRFC 7478や、データチャネルの輸送にSCTPを使用することを定義するRFC 8831などがあります。
Internet Engineering Task Force (IETF) R. Jesup
Request for Comments: 8832 Mozilla
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
M. Tüxen
Münster Univ. of Appl. Sciences
January 2021
WebRTC Data Channel Establishment Protocol
WebRTCデータチャネル確立プロトコル
Abstract
概要
The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete.
WebRTCフレームワークは、2つのピアのWebブラウザー間でオーディオ、ビデオ、およびデータを使用する直接インタラクティブなリッチ通信のプロトコルサポートを指定します。このドキュメントでは、ピア間で対称データチャネルを確立するための簡単なプロトコルを指定します。双方向ハンドシェイクを使用し、ハンドシェイクが完了するのを待たずにユーザーデータを送信できます。
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 7841.
このドキュメントは、インターネット技術特別調査委員会（IETF）の製品です。これは、IETFコミュニティのコンセンサスを表しています。パブリックレビューを受け、Internet Engineering Steering Group（IESG）による公開が承認されました。インターネット標準の詳細については、RFC7841のセクション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/rfc8832.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8832で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2021 IETFTrustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions
3. Terminology
4. Protocol Overview
5. Message Formats
5.1. DATA_CHANNEL_OPEN Message
5.2. DATA_CHANNEL_ACK Message
6. Procedures
7. Security Considerations
8. IANA Considerations
8.1. SCTP Payload Protocol Identifier
8.2. New Standalone Registry for DCEP
8.2.1. New Message Type Registry
8.2.2. New Channel Type Registry
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The Data Channel Establishment Protocol (DCEP) is designed to provide, in the WebRTC data channel context [RFC8831], a simple in-band method for opening symmetric data channels. As discussed in [RFC8831], the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in Datagram Transport Layer Security (DTLS) (described in [RFC8261]). This allows DCEP to benefit from the already standardized transport and security features of SCTP and DTLS. DTLS 1.0 is defined in [RFC4347]; the present latest version, DTLS 1.2, is defined in [RFC6347]; and an upcoming version, DTLS 1.3, is defined in [TLS-DTLS13].
データチャネル確立プロトコル（DCEP）は、WebRTCデータチャネルコンテキスト[RFC8831]で、対称データチャネルを開くための単純な帯域内方式を提供するように設計されています。[RFC8831]で説明されているように、このプロトコルは、Datagram Transport Layer Security（DTLS）（[RFC8261]で説明）にカプセル化されたStream Control Transmission Protocol（SCTP）[RFC4960]を使用します。これにより、DCEPは、SCTPおよびDTLSのすでに標準化されたトランスポートおよびセキュリティ機能の恩恵を受けることができます。DTLS1.0は[RFC4347]で定義されています。現在の最新バージョンであるDTLS1.2は、[RFC6347]で定義されています。今後のバージョンであるDTLS1.3は、[TLS-DTLS13]で定義されています。
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]で説明されているように、ここに示すように、すべて大文字で表示される場合にのみ解釈されます。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
Association: An SCTP association.
アソシエーション：SCTPアソシエーション。
Stream: A unidirectional stream of an SCTP association. It is uniquely identified by an SCTP stream identifier (0-65534). Note: The SCTP stream identifier 65535 is reserved due to SCTP INIT and INIT-ACK chunks only allowing a maximum of 65535 streams to be negotiated (0-65534).
ストリーム：SCTPアソシエーションの単方向ストリーム。これは、SCTPストリーム識別子（0-65534）によって一意に識別されます。注：SCTPストリームID 65535は、SCTP INITおよびINIT-ACKチャンクのために予約されており、最大65535ストリーム（0〜65534）のみをネゴシエートできます。
Stream Identifier: The SCTP stream identifier uniquely identifying a stream.
ストリーム識別子：ストリームを一意に識別するSCTPストリーム識別子。
Data Channel: Two streams with the same stream identifier, one in each direction, which are managed together.
データチャネル：同じストリーム識別子を持つ2つのストリーム（各方向に1つ）は、一緒に管理されます。
The Data Channel Establishment Protocol is a simple, low-overhead way to establish bidirectional data channels over an SCTP association with a consistent set of properties.
データチャネル確立プロトコルは、一貫したプロパティセットを使用して、SCTPアソシエーションを介して双方向データチャネルを確立するためのシンプルでオーバーヘッドの少ない方法です。
The set of consistent properties includes:
一貫性のあるプロパティのセットは次のとおりです。
* reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used.
* 信頼できるまたは信頼できないメッセージ送信。信頼性の低い送信の場合、同じレベルの信頼性の欠如が使用されます。
* in-order or out-of-order message delivery.
* 順不同または順不同のメッセージ配信。
* the priority of the data channel.
* データチャネルの優先度。
* an optional label for the data channel.
* データチャネルのオプションのラベル。
* an optional protocol for the data channel.
* データチャネルのオプションのプロトコル。
* the streams.
* ストリーム。
This protocol uses a two-way handshake to open a data channel. The handshake pairs one incoming and one outgoing stream, both having the same stream identifier, into a single bidirectional data channel. The peer that initiates opening a data channel selects a stream identifier for which the corresponding incoming and outgoing streams are unused and sends a DATA_CHANNEL_OPEN message on the outgoing stream. The peer responds with a DATA_CHANNEL_ACK message on its corresponding outgoing stream. Then the data channel is open. DCEP messages are sent on the same stream as the user messages belonging to the data channel. The demultiplexing is based on the SCTP Payload Protocol Identifier (PPID), since DCEP uses a specific PPID.
このプロトコルは、双方向ハンドシェイクを使用してデータチャネルを開きます。ハンドシェイクは、同じストリームIDを持つ1つの着信ストリームと1つの発信ストリームを、単一の双方向データチャネルにペアリングします。データチャネルのオープンを開始するピアは、対応する着信ストリームと発信ストリームが使用されていないストリーム識別子を選択し、発信ストリームでDATA_CHANNEL_OPENメッセージを送信します。ピアは、対応する発信ストリームでDATA_CHANNEL_ACKメッセージで応答します。次に、データチャネルが開きます。DCEPメッセージは、データチャネルに属するユーザーメッセージと同じストリームで送信されます。DCEPは特定のPPIDを使用するため、逆多重化はSCTPペイロードプロトコル識別子（PPID）に基づいています。
| Note: The opening side MAY send user messages before the | DATA_CHANNEL_ACK is received.
To avoid collisions where both sides try to open a data channel with the same stream identifiers, each side MUST use streams with either even or odd stream identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS [RFC8261], the method used to determine which side uses odd or even is based on the underlying DTLS connection role: the side acting as the DTLS client MUST use streams with even stream identifiers; the side acting as the DTLS server MUST use streams with odd stream identifiers.
両側が同じストリーム識別子でデータチャネルを開こうとする衝突を回避するために、DATA_CHANNEL_OPENメッセージを送信するとき、それぞれの側は偶数または奇数のストリーム識別子を持つストリームを使用する必要があります。SCTP over DTLS [RFC8261]を使用する場合、どちらの側が奇数または偶数を使用するかを決定するために使用される方法は、基礎となるDTLS接続の役割に基づいています。DTLSクライアントとして機能する側は、偶数のストリーム識別子を持つストリームを使用する必要があります。DTLSサーバーとして機能する側は、奇数のストリーム識別子を持つストリームを使用する必要があります。
| Note: There is no attempt to ensure uniqueness for the label;
| if both sides open a data channel labeled "x" at the same time,
| there will be two data channels labeled "x" -- one on an even
| stream pair, one on an odd pair.
The purpose of the protocol field is to ease cross-application interoperation ("federation") by identifying the user data being passed by means of an IANA-registered string from the "WebSocket Subprotocol Name Registry" defined in [RFC6455]. The field may be useful for homogeneous applications that may create more than one type of data channel. Note that there is no attempt to ensure uniqueness for the protocol field.
プロトコルフィールドの目的は、[RFC6455]で定義されている「WebSocketサブプロトコル名レジストリ」からIANA登録文字列を使用して渡されるユーザーデータを識別することにより、アプリケーション間の相互運用（「フェデレーション」）を容易にすることです。このフィールドは、複数のタイプのデータチャネルを作成する可能性のある同種のアプリケーションに役立つ場合があります。プロトコルフィールドの一意性を保証する試みはないことに注意してください。
Every DCEP message starts with a one-byte field called "Message Type" that indicates the type of the message. The corresponding values are managed by IANA (see Section 8.2.1).
すべてのDCEPメッセージは、メッセージのタイプを示す「メッセージタイプ」と呼ばれる1バイトのフィールドで始まります。対応する値はIANAによって管理されます（セクション8.2.1を参照）。
This message is initially sent using the data channel on the stream used for user messages.
このメッセージは、最初はユーザーメッセージに使用されるストリームのデータチャネルを使用して送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Channel Type | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Length | Protocol Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
| Label |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
| Protocol |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type: 1 byte (unsigned integer) This field holds the IANA-defined message type for the DATA_CHANNEL_OPEN message. The value of this field is 0x03, as specified in Section 8.2.1.
メッセージタイプ：1バイト（符号なし整数）このフィールドは、DATA_CHANNEL_OPENメッセージのIANA定義のメッセージタイプを保持します。セクション8.2.1で指定されているように、このフィールドの値は0x03です。
Channel Type: 1 byte (unsigned integer) This field specifies the type of data channel to be opened. The values are managed by IANA (see Section 8.2.2):
チャネルタイプ：1バイト（符号なし整数）このフィールドは、開くデータチャネルのタイプを指定します。値はIANAによって管理されます（セクション8.2.2を参照）。
DATA_CHANNEL_RELIABLE (0x00): The data channel provides a reliable in-order bidirectional communication.
DATA_CHANNEL_RELIABLE（0x00）：データチャネルは、信頼性の高い順序どおりの双方向通信を提供します。
DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The data channel provides a reliable unordered bidirectional communication.
DATA_CHANNEL_RELIABLE_UNORDERED（0x80）：データチャネルは、信頼性の高い順序付けられていない双方向通信を提供します。
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The data channel provides a partially reliable in-order bidirectional communication. User messages will not be retransmitted more times than specified in the Reliability Parameter.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT（0x01）：データチャネルは、部分的に信頼できる順序どおりの双方向通信を提供します。ユーザーメッセージは、信頼性パラメーターで指定された回数を超えて再送信されることはありません。
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The data channel provides a partially reliable unordered bidirectional communication. User messages will not be retransmitted more times than specified in the Reliability Parameter.
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED（0x81）：データチャネルは、部分的に信頼できる順序付けられていない双方向通信を提供します。ユーザーメッセージは、信頼性パラメーターで指定された回数を超えて再送信されることはありません。
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The data channel provides a partially reliable in-order bidirectional communication. User messages might not be transmitted or retransmitted after a specified lifetime given in milliseconds in the Reliability Parameter. This lifetime starts when providing the user message to the protocol stack.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED（0x02）：データチャネルは、部分的に信頼できる順序どおりの双方向通信を提供します。信頼性パラメータでミリ秒単位で指定された有効期間が経過すると、ユーザーメッセージが送信または再送信されない場合があります。この存続期間は、ユーザーメッセージをプロトコルスタックに提供するときに始まります。
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The data channel provides a partially reliable unordered bidirectional communication. User messages might not be transmitted or retransmitted after a specified lifetime given in milliseconds in the Reliability Parameter. This lifetime starts when providing the user message to the protocol stack.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED（0x82）：データチャネルは、部分的に信頼できる順序付けられていない双方向通信を提供します。信頼性パラメータでミリ秒単位で指定された有効期間が経過すると、ユーザーメッセージが送信または再送信されない場合があります。この存続期間は、ユーザーメッセージをプロトコルスタックに提供するときに始まります。
Priority: 2 bytes (unsigned integer) The priority of the data channel, as described in [RFC8831].
優先度：2バイト（符号なし整数）[RFC8831]で説明されているデータチャネルの優先度。
Reliability Parameter: 4 bytes (unsigned integer) For reliable data channels, this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side. If a partially reliable data channel with a limited number of retransmissions is used, this field specifies the number of retransmissions. If a partially reliable data channel with a limited lifetime is used, this field specifies the maximum lifetime in milliseconds. The following table summarizes this:
信頼性パラメータ：4バイト（符号なし整数）信頼性の高いデータチャネルの場合、このフィールドは送信側で0に設定する必要があり、受信側で無視する必要があります。再送信回数が制限された部分的に信頼できるデータチャネルが使用されている場合、このフィールドは再送信回数を指定します。ライフタイムが制限された部分的に信頼できるデータチャネルが使用されている場合、このフィールドは最大ライフタイムをミリ秒単位で指定します。次の表はこれを要約したものです。
+================================================+=============+
| Channel Type | Reliability |
| | Parameter |
+================================================+=============+
| DATA_CHANNEL_RELIABLE | Ignored |
+------------------------------------------------+-------------+
| DATA_CHANNEL_RELIABLE_UNORDERED | Ignored |
+------------------------------------------------+-------------+
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of |
| | RTX |
+------------------------------------------------+-------------+
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of |
| | RTX |
+------------------------------------------------+-------------+
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in |
| | ms |
+------------------------------------------------+-------------+
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in |
| | ms |
+------------------------------------------------+-------------+
Table 1
表1
Label Length: 2 bytes (unsigned integer) The length of the label field in bytes.
ラベルの長さ：2バイト（符号なし整数）バイト単位のラベルフィールドの長さ。
Protocol Length: 2 bytes (unsigned integer) The length of the protocol field in bytes.
プロトコルの長さ：2バイト（符号なし整数）プロトコルフィールドの長さ（バイト単位）。
Label: Variable Length (sequence of characters) The name of the data channel as a UTF-8-encoded string, as specified in [RFC3629]. This may be an empty string.
ラベル：可変長（文字のシーケンス）[RFC3629]で指定されている、UTF-8でエンコードされた文字列としてのデータチャネルの名前。これは空の文字列である可能性があります。
Protocol: Variable Length (sequence of characters) If this is an empty string, the protocol is unspecified. If it is a non-empty string, it specifies a protocol registered in the "WebSocket Subprotocol Name Registry" created in [RFC6455]. This string is UTF-8 encoded, as specified in [RFC3629].
プロトコル：可変長（文字のシーケンス）これが空の文字列の場合、プロトコルは指定されていません。空でない文字列の場合は、[RFC6455]で作成した「WebSocketサブプロトコル名レジストリ」に登録されているプロトコルを指定します。この文字列は、[RFC3629]で指定されているように、UTF-8でエンコードされています。
This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE message. It is sent on the stream used for user messages using the data channel. Reception of this message tells the opener that the data channel setup handshake is complete.
このメッセージは、DATA_CHANNEL_OPEN_RESPONSEメッセージへの応答として送信されます。データチャネルを使用してユーザーメッセージに使用されるストリームで送信されます。このメッセージの受信は、オープナーにデータチャネルセットアップハンドシェイクが完了したことを通知します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+
Message Type: 1 byte (unsigned integer) This field holds the IANA-defined message type for the DATA_CHANNEL_ACK message. The value of this field is 0x02, as specified in Section 8.2.1.
メッセージタイプ：1バイト（符号なし整数）このフィールドは、DATA_CHANNEL_ACKメッセージのIANA定義のメッセージタイプを保持します。セクション8.2.1で指定されているように、このフィールドの値は0x02です。
All DCEP messages MUST be sent using ordered delivery and reliable transmission. They MUST be sent on the same outgoing stream as the user messages belonging to the corresponding data channel. Multiplexing and demultiplexing is done by using the SCTP PPID. Therefore, a DCEP message MUST be sent with the assigned PPID for the Data Channel Establishment Protocol (see Section 8.1). Other messages MUST NOT be sent using this PPID.
すべてのDCEPメッセージは、注文された配信と信頼性の高い送信を使用して送信する必要があります。それらは、対応するデータチャネルに属するユーザーメッセージと同じ発信ストリームで送信する必要があります。多重化と逆多重化は、SCTPPPIDを使用して実行されます。したがって、DCEPメッセージは、データチャネル確立プロトコルに割り当てられたPPIDとともに送信する必要があります（セクション8.1を参照）。他のメッセージは、このPPIDを使用して送信してはなりません。
The peer that initiates opening a data channel selects a stream identifier for which the corresponding incoming and outgoing streams are unused. If the side is acting as the DTLS client, it MUST choose an even stream identifier; if the side is acting as the DTLS server, it MUST choose an odd one. The initiating peer fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on the chosen stream.
データチャネルのオープンを開始するピアは、対応する着信ストリームと発信ストリームが使用されていないストリーム識別子を選択します。サイドがDTLSクライアントとして機能している場合は、偶数のストリーム識別子を選択する必要があります。サイドがDTLSサーバーとして機能している場合は、奇数を選択する必要があります。開始ピアは、DATA_CHANNEL_OPENメッセージのパラメーターを入力し、選択したストリームで送信します。
If a DATA_CHANNEL_OPEN message is received on an unused stream, the stream identifier corresponds to the role of the peer, and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the stream with the same stream identifier as the one the DATA_CHANNEL_OPEN message was received on.
未使用のストリームでDATA_CHANNEL_OPENメッセージが受信され、ストリームIDがピアの役割に対応し、DATA_CHANNEL_OPENメッセージのすべてのパラメーターが有効である場合、対応するDATA_CHANNEL_ACKメッセージが同じストリームIDでストリームに送信されます。DATA_CHANNEL_OPENメッセージがで受信されました。
If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, the receiver MUST close the corresponding data channel using the procedure described in [RFC8831] and MUST NOT send a DATA_CHANNEL_ACK message in response to the received message. This might occur if, for example, a DATA_CHANNEL_OPEN message is received on an already used stream, there are problems with parameters within the DATA_CHANNEL_OPEN message, the odd/even rule is violated, or the DATA_CHANNEL_OPEN message itself is not well formed. Therefore, receiving an SCTP stream-reset request for a stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the data channel setup procedure. After also successfully resetting the corresponding outgoing stream, which concludes the data channel closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be sent on the stream.
DATA_CHANNEL_OPENメッセージが上記の条件を満たさない場合、受信者は[RFC8831]で説明されている手順を使用して、対応するデータチャネルを閉じなければならず、受信したメッセージに応答してDATA_CHANNEL_ACKメッセージを送信してはなりません。これは、たとえば、DATA_CHANNEL_OPENメッセージがすでに使用されているストリームで受信された場合、DATA_CHANNEL_OPENメッセージ内のパラメーターに問題がある場合、奇数/偶数ルールに違反した場合、またはDATA_CHANNEL_OPENメッセージ自体が整形式でない場合に発生する可能性があります。したがって、DATA_CHANNEL_ACKメッセージが受信されていないストリームのSCTPストリームリセット要求を受信すると、対応するDATA_CHANNEL_OPENメッセージの送信者にデータチャネル設定手順の失敗が示されます。対応する発信ストリームも正常にリセットされ、ピアによって開始されたデータチャネルのクローズが終了した後、新しいDATA_CHANNEL_OPENメッセージをストリームで送信できます。
After the DATA_CHANNEL_OPEN message has been sent, the sender of that message MAY start sending messages containing user data without waiting for the reception of the corresponding DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK message or any other message has been received on a data channel, all other messages containing user data and belonging to this data channel MUST be sent ordered, no matter whether the data channel is ordered or not. After the DATA_CHANNEL_ACK or any other message has been received on the data channel, messages containing user data MUST be sent ordered on ordered data channels and MUST be sent unordered on unordered data channels. Therefore, receiving a message containing user data on an unused stream indicates an error. In that case, the corresponding data channel MUST be closed, as described in [RFC8831].
DATA_CHANNEL_OPENメッセージが送信された後、そのメッセージの送信者は、対応するDATA_CHANNEL_ACKメッセージの受信を待たずに、ユーザーデータを含むメッセージの送信を開始してもよい[MAY]。ただし、DATA_CHANNEL_ACKメッセージまたはその他のメッセージがデータチャネルで受信される前に、データチャネルが順序付けられているかどうかに関係なく、ユーザーデータを含み、このデータチャネルに属する他のすべてのメッセージを順序付けて送信する必要があります。DATA_CHANNEL_ACKまたはその他のメッセージがデータチャネルで受信された後、ユーザーデータを含むメッセージは、順序付けられたデータチャネルで順序付けて送信する必要があり、順序付けされていないデータチャネルで順序付けせずに送信する必要があります。したがって、未使用のストリームでユーザーデータを含むメッセージを受信すると、エラーを示します。その場合、[RFC8831]で説明されているように、対応するデータチャネルを閉じる必要があります。
The DATA_CHANNEL_OPEN message contains two variable-length fields: the protocol and the label. A receiver must be prepared to receive DATA_CHANNEL_OPEN messages where these fields have the maximum length of 65535 bytes. Error cases such as using inconsistent lengths of fields, using unknown parameter values, or violating the odd/even rule must also be handled by closing the corresponding data channel. An end point must also be prepared for the peer to open the maximum number of data channels.
DATA_CHANNEL_OPENメッセージには、プロトコルとラベルの2つの可変長フィールドが含まれています。受信者は、これらのフィールドの最大長が65535バイトであるDATA_CHANNEL_OPENメッセージを受信する準備をする必要があります。一貫性のない長さのフィールドの使用、不明なパラメーター値の使用、奇数/偶数ルールへの違反などのエラーケースも、対応するデータチャネルを閉じることによって処理する必要があります。ピアが最大数のデータチャネルを開くためのエンドポイントも準備する必要があります。
This protocol does not provide privacy, integrity, or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [RFC8261].
このプロトコルは、プライバシー、整合性、または認証を提供しません。これらすべてを含むプロトコルスイートの一部として使用する必要があります。このようなプロトコルスイートは[RFC8261]で指定されています。
For general considerations, see [RFC8826] and [RFC8827].
一般的な考慮事項については、[RFC8826]および[RFC8827]を参照してください。
IANA has updated the reference of an already existing SCTP PPID assignment (Section 8.1) and created a new standalone registry with its own URL for DCEP (Section 8.2) containing two new registration tables (Sections 8.2.1 and 8.2.2).
IANAは、既存のSCTP PPID割り当て（セクション8.1）の参照を更新し、2つの新しい登録テーブル（セクション8.2.1および8.2.2）を含むDCEP（セクション8.2）の独自のURLを使用して新しいスタンドアロンレジストリを作成しました。
This document uses an SCTP Payload Protocol Identifier (PPID) previously registered as "WebRTC Control". [RFC4960] created the "SCTP Payload Protocol Identifiers" registry, in which this identifier was assigned. IANA has updated the PPID name from "WebRTC Control" to "WebRTC DCEP" and has updated the reference to point to this document. The corresponding date has been kept.
このドキュメントでは、以前に「WebRTCコントロール」として登録されたSCTPペイロードプロトコル識別子（PPID）を使用しています。[RFC4960]は、この識別子が割り当てられた「SCTPペイロードプロトコル識別子」レジストリを作成しました。IANAは、PPID名を「WebRTCControl」から「WebRTCDCEP」に更新し、このドキュメントを指すように参照を更新しました。対応する日付が保持されています。
Therefore, this assignment now appears as follows:
したがって、この割り当ては次のように表示されます。
+=============+===========+===========+============+
| Value | SCTP PPID | Reference | Date |
+=============+===========+===========+============+
| WebRTC DCEP | 50 | RFC 8832 | 2013-09-20 |
+-------------+-----------+-----------+------------+
Table 2
表2
IANA has created the "Data Channel Establishment Protocol (DCEP) Parameters" registry. It contains the two tables provided in Sections 8.2.1 and 8.2.2.
IANAは、「データチャネル確立プロトコル（DCEP）パラメータ」レジストリを作成しました。これには、セクション8.2.1および8.2.2で提供される2つのテーブルが含まれています。
IANA has created the "Message Types" registry for DCEP to manage the one-byte "Message Type" field in DCEP messages (see Section 5). This registration table is a subregistry of the registry described in Section 8.2.
IANAは、DCEPメッセージの1バイトの「メッセージタイプ」フィールドを管理するために、DCEPの「メッセージタイプ」レジストリを作成しました（セクション5を参照）。この登録テーブルは、セクション8.2で説明されているレジストリのサブレジストリです。
The assignment of new message types is done through an RFC Required action, as defined in [RFC8126]. Documentation of new message types MUST contain the following information:
新しいメッセージタイプの割り当ては、[RFC8126]で定義されているRFCRequiredアクションを介して行われます。新しいメッセージタイプのドキュメントには、次の情報が含まれている必要があります。
1. A name for the new message type.
1. 新しいメッセージタイプの名前。
2. A detailed procedural description of how each message type is used with within DCEP.
2. DCEP内で各メッセージタイプがどのように使用されるかについての詳細な手順の説明。
The following are the initial registrations:
初期登録は次のとおりです。
+===================+===========+===========+
| Name | Type | Reference |
+===================+===========+===========+
| Reserved | 0x00 | RFC 8832 |
+-------------------+-----------+-----------+
| Reserved | 0x01 | RFC 8832 |
+-------------------+-----------+-----------+
| DATA_CHANNEL_ACK | 0x02 | RFC 8832 |
+-------------------+-----------+-----------+
| DATA_CHANNEL_OPEN | 0x03 | RFC 8832 |
+-------------------+-----------+-----------+
| Unassigned | 0x04-0xfe | |
+-------------------+-----------+-----------+
| Reserved | 0xff | RFC 8832 |
+-------------------+-----------+-----------+
Table 3
表3
Note that values 0x00 and 0x01 are reserved to avoid interoperability problems, since they have been used in draft versions of the document. The value 0xff has been reserved for future extensibility. The range of possible values is from 0x00 to 0xff.
値0x00および0x01は、ドキュメントのドラフトバージョンで使用されているため、相互運用性の問題を回避するために予約されていることに注意してください。値0xffは、将来の拡張性のために予約されています。可能な値の範囲は0x00から0xffです。
IANA has created the "Channel Types" registry for DCEP to manage the one-byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). This registration table is a subregistry within the registry described in Section 8.2.
IANAは、DATA_CHANNEL_OPENメッセージの1バイトの「チャネルタイプ」フィールドを管理するために、DCEPの「チャネルタイプ」レジストリを作成しました（セクション5.1を参照）。この登録テーブルは、セクション8.2で説明されているレジストリ内のサブレジストリです。
The assignment of new message types is done through an RFC Required action, as defined in [RFC8126]. Documentation of new Channel Types MUST contain the following information:
新しいメッセージタイプの割り当ては、[RFC8126]で定義されているRFCRequiredアクションを介して行われます。新しいチャネルタイプのドキュメントには、次の情報が含まれている必要があります。
1. A name for the new Channel Type.
1. 新しいチャネルタイプの名前。
2. A detailed procedural description of the user message handling for data channels using this new Channel Type.
2. この新しいチャネルタイプを使用したデータチャネルのユーザーメッセージ処理の詳細な手順の説明。
If new Channel Types support ordered and unordered message delivery, the high-order bit MUST be used to indicate whether or not the message delivery is unordered.
新しいチャネルタイプが順序付きおよび順序なしのメッセージ配信をサポートする場合、メッセージ配信が順序なしであるかどうかを示すために上位ビットを使用する必要があります。
The following are the initial registrations:
初期登録は次のとおりです。
+================================================+======+===========+
| Name | Type | Reference |
+================================================+======+===========+
| DATA_CHANNEL_RELIABLE | 0x00 | RFC 8832 |
+------------------------------------------------+------+-----------+
| DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | RFC 8832 |
+------------------------------------------------+------+-----------+
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | RFC 8832 |
+------------------------------------------------+------+-----------+
| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | RFC 8832 |
+------------------------------------------------+------+-----------+
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | RFC 8832 |
+------------------------------------------------+------+-----------+
| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | RFC 8832 |
+------------------------------------------------+------+-----------+
| Reserved | 0x7f | RFC 8832 |
+------------------------------------------------+------+-----------+
| Reserved | 0xff | RFC 8832 |
+------------------------------------------------+------+-----------+
| Unassigned | rest | |
+------------------------------------------------+------+-----------+
Table 4
表4
Values 0x7f and 0xff have been reserved for future extensibility. The range of possible values is from 0x00 to 0xff.
値0x7fおよび0xffは、将来の拡張性のために予約されています。可能な値の範囲は0x00から0xffです。
[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>。
[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>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/rfc3629>。
[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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCでIANA考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 2017, <https://www.rfc-editor.org/info/rfc8261>.
[RFC8261] Tuexen、M.、Stewart、R.、Jesup、R。、およびS. Loreto、「SCTPパケットのデータグラムトランスポート層セキュリティ（DTLS）カプセル化」、RFC 8261、DOI 10.17487 / RFC8261、2017年11月、<https：//www.rfc-editor.org/info/rfc8261>。
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, <https://www.rfc-editor.org/info/rfc8831>.
[RFC8831] Jesup、R.、Loreto、S。、およびM.Tüxen、「WebRTC Data Channels」、RFC 8831、DOI 10.17487 / RFC8831、2021年1月、<https://www.rfc-editor.org/info/rfc8831>。
[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>。
[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>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https://www.rfc-editor.org/info/rfc6455>。
[RFC8826] Rescorla, E., "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, January 2021, <https://www.rfc-editor.org/info/rfc8826>.
[RFC8826] Rescorla、E。、「WebRTCのセキュリティに関する考慮事項」、RFC 8826、DOI 10.17487 / RFC8826、2021年1月、<https://www.rfc-editor.org/info/rfc8826>。
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.
[RFC8827] Rescorla、E。、「WebRTC Security Architecture」、RFC 8827、DOI 10.17487 / RFC8827、2021年1月、<https://www.rfc-editor.org/info/rfc8827>。
[TLS-DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-39, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
[TLS-DTLS13] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラムトランスポート層セキュリティ（DTLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、draft-ietf-tls-dtls13-39、2020年11月2日、<https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>。
Acknowledgements
謝辞
The authors wish to thank Harald Alvestrand, Richard Barnes, Adam Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Håkansson, Cullen Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick, Irene Rüngeler, Randall Stewart, Peter Thatcher, Martin Thomson, Justin Uberti, and many others for their invaluable comments.
著者は、Harald Alvestrand、Richard Barnes、Adam Bergkvist、Spencer Dawkins、Barry Dingle、StefanHåkansson、Cullen Jennings、Paul Kyzivat、Doug Leonard、Alexey Melnikov、Pete Resnick、IreneRüngeler、Randall Stewart、Peter Thatcher、MartinThomsonに感謝します。Justin Uberti、そして他の多くの人々の貴重なコメント。
Authors' Addresses
著者の住所
Randell Jesup Mozilla United States of America
Randell JesupMozillaアメリカ合衆国
Email: randell-ietf@jesup.org
Salvatore Loreto Ericsson Hirsalantie 11 FI-02420 Jorvas Finland
サルヴァトーレロレートエリクソンヒルサランティ11FI-02420Jorvasフィンランド
Email: salvatore.loreto@ericsson.com
Michael Tüxen Münster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany
ミヒャエルトゥクセンミュンスター応用科学大学Stegerwaldstrasse3948565シュタインフルトドイツ
Email: tuexen@fh-muenster.de