Internet Engineering Task Force (IETF) M. Amend, Ed.
Request for Comments: 9897 DT
Category: Standards Track A. Brunstrom
ISSN: 2070-1721 A. Kassler
Karlstad University
V. Rakocevic
City St George's, University of London
S. Johnson
BT
January 2026
Datagram Congestion Control Protocol (DCCP) communications, as defined in RFC 4340, are inherently restricted to a single path per connection, despite the availability of multiple network paths between peers. The ability to utilize multiple paths simultaneously for a DCCP session can enhance network resource utilization, improve throughput, and increase resilience to network failures, ultimately enhancing the user experience.
RFC 4340 で定義されているデータグラム輻輳制御プロトコル (DCCP) 通信は、ピア間に複数のネットワーク パスが利用可能であるにもかかわらず、本質的に接続ごとに 1 つのパスに制限されています。DCCP セッションで複数のパスを同時に利用できるため、ネットワーク リソースの使用率が向上し、スループットが向上し、ネットワーク障害に対する回復力が向上し、最終的にユーザー エクスペリエンスが向上します。
Use cases for Multipath DCCP (MP-DCCP) include mobile devices (e.g., handsets and vehicles) and residential home gateways that maintain simultaneous connections to distinct network types such as cellular and Wireless Local Area Networks (WLANs) or cellular and fixed access networks. Compared to existing multipath transport protocols, such as Multipath TCP (MPTCP), MP-DCCP is particularly suited for latency-sensitive applications with varying requirements for reliability and in-order delivery.
マルチパス DCCP (MP-DCCP) の使用例には、セルラーおよびワイヤレス ローカル エリア ネットワーク (WLAN)、またはセルラーおよび固定アクセス ネットワークなどの異なるネットワーク タイプへの同時接続を維持するモバイル デバイス (ハンドセットや車両など) および住宅用ホーム ゲートウェイが含まれます。マルチパス TCP (MPTCP) などの既存のマルチパス トランスポート プロトコルと比較して、MP-DCCP は、信頼性と順序どおりの配信に対するさまざまな要件を持つ、遅延に敏感なアプリケーションに特に適しています。
This document specifies a set of protocol extensions to DCCP that enable multipath operations. These extensions maintain the same service model as DCCP while introducing mechanisms to establish and utilize multiple concurrent DCCP flows across different network paths.
この文書は、マルチパス操作を可能にする DCCP への一連のプロトコル拡張を指定します。これらの拡張機能は、DCCP と同じサービス モデルを維持しながら、異なるネットワーク パス全体で複数の同時 DCCP フローを確立して利用するメカニズムを導入します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9897.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9897 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Multipath DCCP in the Networking Stack
1.2. Terminology
1.3. Requirements Language
2. Operation Overview
2.1. MP-DCCP Concept
3. MP-DCCP Protocol
3.1. Multipath Capable Feature
3.2. Multipath Option
3.2.1. MP_CONFIRM
3.2.2. MP_JOIN
3.2.3. MP_FAST_CLOSE
3.2.4. MP_KEY
3.2.5. MP_SEQ
3.2.6. MP_HMAC
3.2.7. MP_RTT
3.2.8. MP_ADDADDR
3.2.9. MP_REMOVEADDR
3.2.10. MP_PRIO
3.2.11. MP_CLOSE
3.2.12. Experimental Multipath Option MP_EXP for Private Use
3.3. MP-DCCP Handshake Procedure
3.4. Address Knowledge Exchange
3.4.1. Advertising a New Path (MP_ADDADDR)
3.4.2. Removing a Path (MP_REMOVEADDR)
3.5. Closing an MP-DCCP Connection
3.6. Fallback
3.7. State Diagram
3.8. Congestion Control Considerations
3.9. Maximum Packet Size Considerations
3.10. Maximum Number of Subflow Considerations
3.11. Path Usage Strategies
3.11.1. Path Mobility
3.11.2. Concurrent Path Usage
4. Security Considerations
5. Interactions with Middleboxes
6. Implementation
7. IANA Considerations
7.1. New Multipath Capable DCCP Feature
7.2. New MP-DCCP Versions Registry
7.3. New Multipath Option Type and Registry
7.4. New DCCP-Reset Code
7.5. New Multipath Key Type Registry
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Differences from Multipath TCP
Acknowledgments
Authors' Addresses
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP communications are restricted to one single path. Other fundamentals of the DCCP protocol are summarized in Section 1 of [RFC4340] such as the reliable handshake process in Section 4.7 of [RFC4340] and the reliable negotiation of features in Section 4.5 of [RFC4340]. These are an important basis for this document. These fundamentals also apply to the DCCP sequencing scheme, which is packet-based (Section 4.2 of [RFC4340]), and the principles for loss and retransmission of features as described in more detail in Section 6.6.3 of [RFC4340]. This document specifies a set of protocol changes that add multipath support to DCCP, specifically support for signaling and setting up multiple paths (a.k.a., "subflows"), managing these subflows, the reordering of data, and the termination of sessions.
データグラム輻輳制御プロトコル (DCCP) [RFC4340] は、輻輳制御された信頼性の低いデータグラムの双方向ユニキャスト接続を提供するトランスポート プロトコルです。DCCP 通信は 1 つの単一パスに制限されます。[RFC4340] のセクション 4.7 の信頼できるハンドシェイクプロセスや、[RFC4340] のセクション 4.5 の信頼できる機能のネゴシエーションなど、DCCP プロトコルの他の基本は [RFC4340] のセクション 1 にまとめられています。これらはこの文書の重要な基礎です。これらの基本は、パケットベースの DCCP シーケンス方式 ([RFC4340] のセクション 4.2)、および [RFC4340] のセクション 6.6.3 で詳細に説明されている機能の損失と再送信の原則にも適用されます。この文書は、DCCP にマルチパス サポートを追加する一連のプロトコル変更を規定します。具体的には、複数のパス (別名「サブフロー」) のシグナリングと設定、これらのサブフローの管理、データの並べ替え、およびセッションの終了のサポートです。
Multipath DCCP (MP-DCCP) enables a DCCP connection to simultaneously establish a flow across multiple paths. This can be beneficial to applications that transfer large amounts of data, by utilizing the capacity/connectivity offered by multiple paths. In addition, the multipath extensions enable the trade-off of timeliness and reliability, which is important for low-latency applications that do not require guaranteed delivery services such as Audio/Video streaming.
マルチパス DCCP (MP-DCCP) を使用すると、DCCP 接続で複数のパスにわたるフローを同時に確立できます。これは、複数のパスによって提供される容量/接続性を利用することで、大量のデータを転送するアプリケーションにとって有益です。さらに、マルチパス拡張により、適時性と信頼性のトレードオフが可能になります。これは、オーディオ/ビデオ ストリーミングなどの保証された配信サービスを必要としない低遅延アプリケーションにとって重要です。
In addition to the integration into DCCP services, implementers or future specifications could choose MP-DCCP for other use cases such as 3GPP 5G multi-access solutions (e.g., Access Traffic Steering, Switching, and Splitting (ATSSS) specified in [TS23.501]) or hybrid access networks. ATSSS combines 3GPP and non-3GPP access between the user equipment and an operator network, while hybrid access combines fixed and cellular access between a residential gateway and an operator network. MP-DCCP can be used in these scenarios for load balancing, seamless session handover, and bandwidth aggregation when non-DCCP traffic such as IP, UDP, or TCP is encapsulated into MP-DCCP. More details on potential use cases for MP-DCCP are provided in [MP-DCCP.Site], [IETF105.Slides], and [MP-DCCP.Paper]. All of these use cases profit from an Open Source Linux reference implementation provided under [MP-DCCP.Site].
DCCP サービスへの統合に加えて、実装者または将来の仕様は、3GPP 5G マルチアクセス ソリューション ([TS23.501] で規定されているアクセス トラフィック ステアリング、スイッチング、およびスプリット (ATSSS) など) やハイブリッド アクセス ネットワークなどの他の使用例に対して MP-DCCP を選択する可能性があります。ATSSS は、ユーザー機器とオペレーター ネットワーク間の 3GPP アクセスと非 3GPP アクセスを組み合わせます。一方、ハイブリッド アクセスは、住宅用ゲートウェイとオペレーター ネットワーク間の固定アクセスとセルラー アクセスを組み合わせます。MP-DCCP は、IP、UDP、または TCP などの非 DCCP トラフィックが MP-DCCP にカプセル化されている場合、ロード バランシング、シームレスなセッション ハンドオーバー、帯域幅集約などのシナリオで使用できます。MP-DCCP の潜在的な使用例の詳細については、[MP-DCCP.Site]、[IETF105.Slides]、および [MP-DCCP.Paper] で提供されています。これらのユースケースはすべて、[MP-DCCP.Site] で提供されているオープンソース Linux リファレンス実装から利益を得ています。
The encapsulation of non-DCCP traffic (e.g., UDP or IP) in MP-DCCP to enable the above-mentioned use cases is not considered in this specification. Also out of scope is the encapsulation of DCCP traffic in UDP to pass middleboxes (e.g., NATs, firewalls, proxies, intrusion detection systems (IDSs), etc.) that do not support DCCP. However, a possible method is defined in [RFC6773] and considered in [U-DCCP] to achieve the same with less overhead.
上述の使用例を可能にするための MP-DCCP における非 DCCP トラフィック (例: UDP または IP) のカプセル化は、この仕様では考慮されていません。また、DCCP をサポートしないミドルボックス (NAT、ファイアウォール、プロキシ、侵入検知システム (IDS) など) を通過させるための UDP での DCCP トラフィックのカプセル化も範囲外です。ただし、より少ないオーバーヘッドで同じことを実現する可能な方法が [RFC6773] で定義され、[U-DCCP] で検討されています。
MP-DCCP is based exclusively on the lean concept of DCCP. For traffic that is already encrypted or does not need encryption, MP-DCCP is an efficient choice as it does not apply its own encryption mechanisms. Also, the procedures defined by MP-DCCP, which allow subsequent reordering of traffic and efficient traffic scheduling, improve performance, as shown in [MP-DCCP.Paper], and take into account the interaction of the protocol with the further elements required for multipath transport.
MP-DCCP は、DCCP のリーン概念のみに基づいています。すでに暗号化されているトラフィック、または暗号化を必要としないトラフィックの場合、MP-DCCP は独自の暗号化メカニズムを適用しないため、効率的な選択肢となります。また、MP-DCCP によって定義された手順は、[MP-DCCP.Paper] に示されているように、その後のトラフィックの並べ替えと効率的なトラフィック スケジューリングを可能にし、パフォーマンスを向上させ、マルチパス トランスポートに必要な追加の要素とプロトコルの相互作用を考慮します。
MP-DCCP provides a set of features to DCCP; Figure 1 illustrates this layering. MP-DCCP is designed to be used by applications in the same way as DCCP with no changes to the application itself.
MP-DCCP は DCCP に一連の機能を提供します。図 1 は、この階層化を示しています。MP-DCCP は、アプリケーション自体に変更を加えることなく、DCCP と同じ方法でアプリケーションで使用できるように設計されています。
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MP-DCCP |
+---------------+ + - - - - - - - + - - - - - - - +
| DCCP | |Subflow (DCCP) |Subflow (DCCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+
Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks
図 1: 標準 DCCP プロトコル スタックと MP-DCCP プロトコル スタックの比較
A command-line interface (CLI) at the endpoint (or another method) could be used to configure and manage the DCCP connections. This could be extended to also support MP-DCCP, but this specification does not define it.
エンドポイントのコマンドライン インターフェイス (CLI) (または別の方法) を使用して、DCCP 接続を構成および管理できます。これを拡張して MP-DCCP もサポートすることもできますが、この仕様では定義されていません。
This document uses terms that are either specific for multipath transport as defined in [RFC8684] or defined in the context of MP-DCCP, as follows:
この文書では、[RFC8684] で定義されているマルチパス トランスポートに固有の用語、または MP-DCCP のコンテキストで定義されている用語を次のように使用します。
Path:
パス：
A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of the source and destination address and the source and destination ports. This definition follows [RFC8684] and is illustrated in the following two examples for IPv6 and IPv4, which each show a pair of sender IP-address:port and a pair of receiver IP-address:port, which together form the 4-tuple:
送信者と受信者の間の一連のリンク。このコンテキストでは、送信元アドレスと宛先アドレス、および送信元ポートと宛先ポートの 4 つのタプルによって定義されます。この定義は [RFC8684] に従っており、IPv6 と IPv4 の次の 2 つの例で示されています。それぞれ、送信側 IP アドレス:ポートのペアと受信側 IP アドレス:ポートのペアが示されており、これらは合わせて 4 タプルを形成します。
* IPv6: [2001:db8:3333:4444:5555:6666:7777:8888]:1234, [2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321
* IPv6: [2001:db8:3333:4444:5555:6666:7777:8888]:1234、[2001:db8:3333:4444:cccc:dddd:eeee:ffff]:4321
* IPv4: 203.0.113.1:1234, 203.0.113.2:4321
* IPv4: 203.0.113.1:1234、203.0.113.2:4321
Subflow:
サブフロー:
A DCCP flow that is transmitted by using a specific path (4-tuple of source and destination address/port pairs) that forms one of the multipath flows used by a single connection.
単一の接続で使用されるマルチパス フローの 1 つを形成する特定のパス (送信元および宛先アドレス/ポートのペアの 4 タプル) を使用して送信される DCCP フロー。
(MP-DCCP) Connection:
(MP-DCCP) 接続:
A set of one or more subflows, over which an application can communicate between two hosts. The MP-DCCP connection is exposed as a single DCCP socket to the application.
アプリケーションが 2 つのホスト間で通信できる 1 つ以上のサブフローのセット。MP-DCCP 接続は、単一の DCCP ソケットとしてアプリケーションに公開されます。
Connection Identifier (CI):
接続識別子 (CI):
A unique identifier that is assigned to a multipath connection by the host to distinguish several multipath connections locally. The CIs must therefore be locally unique per host and do not have to be the same across the peers.
ローカルで複数のマルチパス接続を区別するために、ホストによってマルチパス接続に割り当てられる一意の識別子。したがって、CI はホストごとにローカルで一意である必要があり、ピア全体で同じである必要はありません。
Host:
ホスト：
An end host that operates an MP-DCCP implementation and either initiates or accepts an MP-DCCP connection.
MP-DCCP 実装を操作し、MP-DCCP 接続を開始または受け入れるエンドホスト。
'+':
「+」:
The plus symbol means the concatenation of values.
プラス記号は値の連結を意味します。
In addition to these terms, within the framework of MP-DCCP, the interpretation of, and effect on, regular single-path DCCP semantics is discussed in Section 3.
これらの用語に加えて、MP-DCCP の枠組み内での通常のシングルパス DCCP セマンティクスの解釈とその影響については、セクション 3 で説明します。
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] で説明されているように解釈されます。
DCCP transmits congestion-controlled unreliable datagrams over a single path. Various congestion control mechanisms have been specified to optimize DCCP performance for specific traffic types in terms of profiles denoted by a Congestion Control IDentifier (CCID). However, DCCP does not provide built-in support for managing multiple subflows within one DCCP connection. The extension of DCCP for Multipath DCCP (MP-DCCP) is described in detail in Section 3.
DCCP は、輻輳制御された信頼性の低いデータグラムを単一のパス上で送信します。輻輳制御 ID (CCID) によって示されるプロファイルに関して、特定のトラフィック タイプの DCCP パフォーマンスを最適化するために、さまざまな輻輳制御メカニズムが仕様化されています。ただし、DCCP は、1 つの DCCP 接続内で複数のサブフローを管理するための組み込みサポートを提供しません。マルチパス DCCP (MP-DCCP) 用の DCCP の拡張については、セクション 3 で詳細に説明します。
At a high level of MP-DCCP operation, the data stream from a DCCP application is split by the MP-DCCP operation into one or more subflows that can be transmitted via different paths, for example, using paths via different links. The corresponding control information allows the receiver to optionally reassemble and deliver the received data in the originally transmitted order to the recipient application. This may be necessary because DCCP does not guarantee in-order delivery. The details of the transmission scheduling mechanism and optional reordering mechanism are up to the sender and receiver, respectively, and are outside the scope of this document.
高レベルの MP-DCCP 動作では、DCCP アプリケーションからのデータ ストリームは、MP-DCCP 動作によって 1 つ以上のサブフローに分割され、異なるパス (たとえば、異なるリンク経由のパスを使用) を介して送信できます。対応する制御情報により、受信側はオプションで受信データを元に送信された順序で再組み立てし、受信側アプリケーションに配信することができます。DCCP は順序どおりの配信を保証しないため、これが必要になる場合があります。送信スケジューリングメカニズムとオプションの並べ替えメカニズムの詳細は、それぞれ送信者と受信者に依存しており、この文書の範囲外です。
An MP-DCCP connection provides a bidirectional connection of datagrams between two hosts exchanging data using DCCP. It does not require any change to the applications. MP-DCCP enables the hosts to use multiple paths with different 4-tuples to transport the packets of an MP-DCCP connection. MP-DCCP manages the request, set-up, authentication, prioritization, modification, and removal of the DCCP subflows on different paths as well as the exchange of performance parameters.
MP-DCCP 接続は、DCCP を使用してデータを交換する 2 つのホスト間でデータグラムの双方向接続を提供します。アプリケーションを変更する必要はありません。MP-DCCP を使用すると、ホストは異なる 4 タプルを持つ複数のパスを使用して MP-DCCP 接続のパケットを転送できます。MP-DCCP は、さまざまなパス上の DCCP サブフローの要求、セットアップ、認証、優先順位付け、変更、削除、およびパフォーマンス パラメータの交換を管理します。
The number of DCCP subflows can vary during the lifetime of an MP-DCCP connection. The details of the path management decisions for when to add or remove subflows are outside the scope of this document.
DCCP サブフローの数は、MP-DCCP 接続の存続期間中に変化する可能性があります。サブフローをいつ追加または削除するかに関するパス管理の決定の詳細については、このドキュメントの範囲外です。
The multipath capability for MP-DCCP is negotiated with a new DCCP feature, as specified in Section 3.1. Once negotiated, all subsequent MP-DCCP operations for that connection are signaled with a variable length multipath-related option, as described in Section 3. All MP-DCCP operations are signaled by Multipath Options described in Section 3.2. Options that require confirmation from the remote peer are retransmitted by the sender until confirmed or until confirmation is no longer considered relevant.
MP-DCCP のマルチパス機能は、セクション 3.1 で指定されているように、新しい DCCP 機能とネゴシエートされます。ネゴシエートが完了すると、その接続に対する後続のすべての MP-DCCP 動作は、セクション 3 で説明するように、可変長のマルチパス関連オプションで通知されます。すべての MP-DCCP 動作は、セクション 3.2 で説明するマルチパス オプションで通知されます。リモート ピアからの確認を必要とするオプションは、確認されるまで、または確認が関連していないとみなされるまで、送信者によって再送信されます。
The sections that follow define MP-DCCP behavior in detail.
以下のセクションでは、MP-DCCP の動作を詳しく定義します。
Figure 2 provides a general overview of the MP-DCCP working mode, whose main characteristics are summarized in this section.
図 2 は MP-DCCP 動作モードの概要を示しており、このセクションではその主な特徴を要約します。
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| (DCCP subflow setup) | |
|----------------------------------->| |
|<-----------------------------------| |
| | | |
| | (DCCP subflow setup)| |
| |--------------------->| |
| |<---------------------| |
| merge individual DCCP subflows to one MP-DCCP connection
| | | |
Figure 2: Example MP-DCCP Usage Scenario
図 2: MP-DCCP の使用シナリオの例
* An MP-DCCP connection begins with a 4-way handshake between two hosts. In Figure 2, an MP-DCCP connection is established between addresses A1 and B1 on Hosts A and B. In the handshake, a Multipath Capable Feature is used to negotiate multipath support for the connection. Host-specific keys are also exchanged between Host A and Host B during the handshake. The details of the MP-DCCP handshake procedure is described in Section 3.3. MP-DCCP does not require both peers to have more than one address.
* MP-DCCP 接続は、2 つのホスト間の 4 ウェイ ハンドシェイクから始まります。図 2 では、ホスト A とホスト B 上のアドレス A1 と B1 の間に MP-DCCP 接続が確立されています。ハンドシェイクでは、マルチパス対応機能を使用して、接続のマルチパス サポートをネゴシエートします。ハンドシェイク中に、ホスト A とホスト B の間でホスト固有のキーも交換されます。MP-DCCP ハンドシェイク手順の詳細については、セクション 3.3 で説明します。MP-DCCP では、両方のピアが複数のアドレスを持つ必要はありません。
* When additional paths and corresponding addresses/ports are available, additional DCCP subflows can be created on these paths and attached to the existing MP-DCCP connection. An MP_JOIN option is used to connect a new DCCP subflow to an existing MP-DCCP connection. It contains a Connection Identifier (CI) during the setup of the initial subflow and is exchanged in the 4-way handshake for the subflow together with the Multipath Capable Feature. The example in Figure 2 illustrates the creation of an additional DCCP subflow between Address A2 on Host A and Address B1 on Host B. The two subflows continue to provide a single connection to the applications at both endpoints.
* 追加のパスおよび対応するアドレス/ポートが利用可能な場合、追加の DCCP サブフローをこれらのパス上に作成し、既存の MP-DCCP 接続に接続できます。MP_JOIN オプションは、新しい DCCP サブフローを既存の MP-DCCP 接続に接続するために使用されます。これには、最初のサブフローのセットアップ中に接続識別子 (CI) が含まれており、マルチパス対応機能とともにサブフローの 4 ウェイ ハンドシェイクで交換されます。図 2 の例は、ホスト A のアドレス A2 とホスト B のアドレス B1 の間に追加の DCCP サブフローの作成を示しています。2 つのサブフローは、両方のエンドポイントのアプリケーションに単一の接続を提供し続けます。
* MP-DCCP identifies multiple paths by the presence of multiple addresses/ports at hosts. Combinations of these multiple addresses/ports indicate the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although the additional subflow in the example is shown as being initiated from A2, an additional subflow could alternatively have been initiated from B1 or B2.
* MP-DCCP は、ホストに複数のアドレス/ポートが存在することによって複数のパスを識別します。これらの複数のアドレス/ポートの組み合わせは、追加のパスを示します。この例では、セットアップできる他の潜在的なパスは A1<->B2 および A2<->B2 です。この例では追加のサブフローが A2 から開始されるように示されていますが、追加のサブフローは B1 または B2 から開始することもできます。
* The discovery and setup of additional subflows is achieved through a path management method including the logic and details of the procedures for adding/removing subflows. This document describes the procedures that enable a host to initiate new subflows or to signal available IP addresses between peers. However, the definition of a path management method, in which sequence and when subflows are created, is outside the scope of this document. This method is subject to a corresponding policy and the specifics of the implementation. If an MP-DCCP peer host wishes to limit the maximum number of paths that can be maintained (e.g., similar to that discussed in Section 3.4 of [RFC8041]), the creation of new subflows from that peer host is omitted when the threshold of maximum paths is exceeded and incoming subflow requests MUST be rejected.
* 追加のサブフローの検出と設定は、サブフローの追加/削除のロジックと手順の詳細を含むパス管理方法を通じて実現されます。この文書では、ホストが新しいサブフローを開始したり、ピア間で利用可能な IP アドレスを通知したりできるようにする手順について説明します。ただし、サブフローがいつどの順序で作成されるかなど、パス管理方法の定義は、このドキュメントの範囲外です。このメソッドは、対応するポリシーと実装の詳細の対象となります。MP-DCCP ピアホストが維持できるパスの最大数を制限したい場合 (たとえば、[RFC8041] のセクション 3.4 で説明されているものと同様)、最大パスのしきい値を超えた場合、そのピアホストからの新しいサブフローの作成は省略され、受信サブフロー要求は拒否されなければなりません(MUST)。
* Through the use of Multipath Options, MP-DCCP adds connection-level sequence numbers and the exchange of Round-Trip Time (RTT) information to enable optional reordering features. As a hint for scheduling decisions, a Multipath Option that allows a peer to indicate its priorities for which path to use is also defined.
* マルチパス オプションの使用により、MP-DCCP は接続レベルのシーケンス番号とラウンドトリップ時間 (RTT) 情報の交換を追加し、オプションの並べ替え機能を有効にします。スケジューリング決定のヒントとして、ピアが使用するパスの優先順位を示すことができるマルチパス オプションも定義されています。
* Subflows are terminated in the same way as regular DCCP connections, as described in Section 8.3 of [RFC4340]. MP-DCCP connections are closed by including an MP_CLOSE option in subflow DCCP-CloseReq or DCCP-Close messages. An MP-DCCP connection may also be reset through the use of an MP_FAST_CLOSE option. Key Data from the initial handshake is included in MP_CLOSE and MP_FAST_CLOSE to protect from an unauthorized shutdown of MP-DCCP connections.
* [RFC4340] のセクション 8.3 で説明されているように、サブフローは通常の DCCP 接続と同じ方法で終了します。MP-DCCP 接続は、サブフロー DCCP-CloseReq または DCCP-Close メッセージに MP_CLOSE オプションを含めることによって閉じられます。MP-DCCP 接続は、MP_FAST_CLOSE オプションを使用してリセットすることもできます。MP-DCCP 接続の不正なシャットダウンから保護するために、初期ハンドシェイクからのキー データが MP_CLOSE および MP_FAST_CLOSE に含まれています。
The DCCP protocol feature list (Section 6.4 of [RFC4340]) is extended in this document by adding a new Multipath Feature with Feature Number 10, as shown in Table 1.
DCCP プロトコル機能リスト ([RFC4340] のセクション 6.4) は、表 1 に示すように、機能番号 10 の新しいマルチパス機能を追加することにより、この文書で拡張されています。
+========+===================+============+===============+=======+
| Number | Meaning | Rec'n Rule | Initial Value | Req'd |
+========+===================+============+===============+=======+
| 10 | Multipath Capable | SP | 0 | N |
+--------+-------------------+------------+---------------+-------+
Table 1: Multipath Feature
表 1: マルチパス機能
Rec'n Rule:
推奨ルール:
The reconciliation rule used for the feature. SP indicates the server-priority as defined in Section 6.3 of [RFC4340].
機能に使用される調整ルール。SP は、[RFC4340] のセクション 6.3 で定義されているサーバー優先度を示します。
Initial Value:
初期値:
The initial value for the feature. Every feature has a known initial value.
機能の初期値。すべての特徴には既知の初期値があります。
Req'd:
必須:
This column is "Y" if and only if every DCCP implementation MUST understand the feature. If it is "N", then the feature behaves like an extension, and it is safe to respond to Change options for the feature with empty Confirm options.
すべての DCCP 実装がその機能を理解する必要がある場合にのみ、この列は「Y」になります。「N」の場合、機能は拡張機能のように動作し、空の確認オプションを使用して機能のオプションの変更に応答しても安全です。
This specification adds a DCCP protocol option as defined in Section 5.8 of [RFC4340], providing a new multipath-related variable-length option with option type 46, as shown in Table 2.
この仕様は、[RFC4340] のセクション 5.8 で定義されている DCCP プロトコル オプションを追加し、表 2 に示すように、オプション タイプ 46 の新しいマルチパス関連の可変長オプションを提供します。
+======+===============+===========+============+
| Type | Option Length | Meaning | DCCP-Data? |
+======+===============+===========+============+
| 46 | variable | Multipath | Y |
+------+---------------+-----------+------------+
Table 2: Multipath Option Set
表 2: マルチパス オプション セット
A DCCP endpoint negotiates the Multipath Capable Feature to determine whether multipath extensions can be enabled for a DCCP connection.
DCCP エンドポイントは、マルチパス対応機能をネゴシエートして、DCCP 接続に対してマルチパス拡張を有効にできるかどうかを決定します。
The Multipath Capable Feature (MP_CAPABLE) has Feature Number 10 and follows the structure for features given in Section 6 of [RFC4340]. Beside the negotiation of the feature itself, one or several values can also be exchanged. The value field specified here for the Multipath Capable Feature has a Length of one byte and can be repeated several times within the DCCP option for feature negotiation. This can be, for example, required to announce support of different versions of the protocol. For that, the leftmost four bits in Figure 3 specify the compatible version of the MP-DCCP implementation and MUST be set to 0 following this specification. The four bits following the Version field are unassigned in version 0 and MUST be set to zero by the sender and MUST be ignored by the receiver.
マルチパス対応機能 (MP_CAPABLE) は機能番号 10 を持ち、[RFC4340] のセクション 6 に示されている機能の構造に従います。機能自体のネゴシエーションに加えて、1 つまたは複数の値を交換することもできます。マルチパス対応機能に対してここで指定される値フィールドの長さは 1 バイトで、機能ネゴシエーションの DCCP オプション内で数回繰り返すことができます。これは、たとえば、プロトコルのさまざまなバージョンのサポートをアナウンスするために必要になる場合があります。そのため、図 3 の左端の 4 ビットは MP-DCCP 実装の互換バージョンを指定し、この仕様に従って 0 に設定しなければなりません (MUST)。Version フィールドに続く 4 ビットは、バージョン 0 では割り当てられておらず、送信者はゼロに設定しなければならず、受信者は無視しなければなりません (MUST)。
0 1 2 3 4 5 6 7
+-----------+------------+
| Version | Unassigned |
+-----------+------------+
Figure 3: Format of the Multipath Capable Feature Value Field
図 3: マルチパス対応機能値フィールドのフォーマット
The setting of the Multipath Capable Feature MUST follow the server-priority reconciliation rule described in Section 6.3.1 of [RFC4340]. This allows multiple versions to be specified in order of priority.
マルチパス対応機能の設定は、[RFC4340] のセクション 6.3.1 に記載されているサーバー優先度調整規則に従わなければなりません (MUST)。これにより、複数のバージョンを優先順位に従って指定できます。
The negotiation MUST be a part of the initial handshake procedure described in Section 3.3. No subsequent renegotiation of the Multipath Capable Feature is allowed for the same MP-DCCP connection.
ネゴシエーションは、セクション 3.3 で説明されている初期ハンドシェイク手順の一部でなければなりません (MUST)。同じ MP-DCCP 接続に対して、その後のマルチパス対応機能の再ネゴシエーションは許可されません。
Clients MUST include a Change R option (Section 6 of [RFC4340]) during the initial handshake request to supply a list of supported MP-DCCP protocol versions, ordered by preference.
クライアントは、サポートされている MP-DCCP プロトコル バージョンのリストを優先順に提供するために、最初のハンドシェイク要求中に Change R オプション ([RFC4340] のセクション 6) を含めなければなりません (MUST)。
Servers MUST include a Confirm L option (Section 6 of [RFC4340]) in the subsequent response to agree on an MP-DCCP version to be used from the Client list, followed by its own supported version(s), ordered by preference. Any subflow added to an existing MP-DCCP connection MUST use the version negotiated for the first subflow.
サーバーは、クライアントリストから使用する MP-DCCP バージョンに同意するために、後続の応答に confirm L オプション ([RFC4340] のセクション 6) を含めなければなりません (MUST)。その後に、優先順に並べた独自のサポート対象バージョンが続きます。既存の MP-DCCP 接続に追加されるサブフローは、最初のサブフローに対してネゴシエートされたバージョンを使用しなければなりません (MUST)。
If no agreement is found, the Server MUST reply with an empty Confirm L option with Feature Number 10 and no values.
合意が見つからない場合、サーバーは、機能番号 10 を指定し、値を指定しない空の確認 L オプションで応答しなければなりません (MUST)。
An example of successful version negotiation is shown hereafter and follows the negotiation example shown in Section 6.5 of [RFC4340]. For better understanding, this example uses the unspecified MP-DCCP versions 1 and 2 in addition to the MP-DCCP version 0 specified in this document:
成功したバージョン ネゴシエーションの例を以下に示します。これは、[RFC4340] のセクション 6.5 に示されているネゴシエーションの例に従います。理解を容易にするために、この例では、このドキュメントで指定されている MP-DCCP バージョン 0 に加えて、未指定の MP-DCCP バージョン 1 および 2 を使用します。
Client Server
------ ------
DCCP-Req + Change R(MP_CAPABLE, 1 0)
----------------------------------->
DCCP-Resp + Confirm L(MP_CAPABLE, 1, 2 1 0)
<-----------------------------------
* agreement on version = 1 *
Figure 4: Example of MP-DCCP Support Negotiation Using MP_CAPABLE
図 4: MP_CAPABLE を使用した MP-DCCP サポート ネゴシエーションの例
This example illustrates the following:
この例は次のことを示しています。
1. The Client indicates support for both MP-DCCP versions 1 and 0, with a preference for version 1.
1. クライアントは、MP-DCCP バージョン 1 と 0 の両方のサポートを示し、バージョン 1 を優先します。
2. The Server agrees on using MP-DCCP version 1 indicated by the first value and supplies its own preference list with the subsequent values.
2. サーバーは、最初の値で示される MP-DCCP バージョン 1 の使用に同意し、後続の値を含む独自の優先リストを提供します。
3. MP-DCCP is then enabled between the Client and Server with version 1.
3. MP-DCCP はクライアントとサーバーの間でバージョン 1 で有効になります。
Unlike the example in Figure 4, this document only allows the negotiation of MP-DCCP version 0. Therefore, per successful negotiation of MP-DCCP as defined in this document, the Client and the Server MUST both support MP-DCCP version 0.
図 4 の例とは異なり、この文書では MP-DCCP バージョン 0 のネゴシエーションのみが許可されています。 したがって、この文書で定義されている MP-DCCP のネゴシエーションが成功するごとに、クライアントとサーバーは両方とも MP-DCCP バージョン 0 をサポートしなければなりません (MUST)。
If the version negotiation fails or the Multipath Capable Feature is not present in the DCCP-Request or DCCP-Response packets of the initial handshake procedure, the MP-DCCP connection either MUST fall back to regular DCCP or MUST close the connection. Further details are specified in Section 3.6.
バージョン ネゴシエーションが失敗するか、初期ハンドシェイク手順の DCCP-Request または DCCP-Response パケットにマルチパス対応機能が存在しない場合、MP-DCCP 接続は通常の DCCP にフォールバックするか、接続を閉じなければなりません (MUST)。詳細については、セクション 3.6 で説明します。
MP-DCCP uses one single option to signal various multipath-related operations. The format of this Multipath Option is shown in Figure 5.
MP-DCCP は、単一のオプションを使用して、さまざまなマルチパス関連の操作を通知します。このマルチパス オプションのフォーマットを図 5 に示します。
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| Length | MP_OPT | Value(s) ...
+--------+--------+--------+--------+--------+
Type=46
Figure 5: Multipath Option Format
図 5: マルチパス オプションのフォーマット
The fields used by the Multipath Option are described in Table 3. MP_OPT refers to a Multipath Option.
マルチパス オプションで使用されるフィールドについては、表 3 で説明します。MP_OPT はマルチパス オプションを指します。
+======+========+================+=================================+
| Type | Option | MP_OPT | Meaning |
| | Length | | |
+======+========+================+=================================+
| 46 | var | 0 =MP_CONFIRM | Confirm reception and |
| | | | processing of an MP_OPT option |
+------+--------+----------------+---------------------------------+
| 46 | 12 | 1 =MP_JOIN | Join subflow to an existing MP- |
| | | | DCCP connection |
+------+--------+----------------+---------------------------------+
| 46 | var | 2 | Close an MP-DCCP connection |
| | | =MP_FAST_CLOSE | unconditionally |
+------+--------+----------------+---------------------------------+
| 46 | var | 3 =MP_KEY | Exchange key material for |
| | | | MP_HMAC |
+------+--------+----------------+---------------------------------+
| 46 | 9 | 4 =MP_SEQ | Multipath sequence number |
+------+--------+----------------+---------------------------------+
| 46 | 23 | 5 =MP_HMAC | Hash-based message |
| | | | authentication code for MP-DCCP |
+------+--------+----------------+---------------------------------+
| 46 | 12 | 6 =MP_RTT | Transmit RTT values and |
| | | | calculation parameters |
+------+--------+----------------+---------------------------------+
| 46 | var | 7 =MP_ADDADDR | Advertise one or more |
| | | | additional addresses/ports |
+------+--------+----------------+---------------------------------+
| 46 | 8 | 8 | Remove one or more addresses/ |
| | | =MP_REMOVEADDR | ports |
+------+--------+----------------+---------------------------------+
| 46 | 4 | 9 =MP_PRIO | Change subflow priority |
+------+--------+----------------+---------------------------------+
| 46 | var | 10 =MP_CLOSE | Close an MP-DCCP connection |
+------+--------+----------------+---------------------------------+
| 46 | var | 11 =MP_EXP | Experimental option for private |
| | | | use |
+------+--------+----------------+---------------------------------+
| 46 | TBD | >11 | (available for future Multipath |
| | | | Options) |
+------+--------+----------------+---------------------------------+
Table 3: MP_OPT Option Types
表 3: MP_OPT オプションの種類
Future Multipath Options could be defined in a later version of or extension to this specification.
将来のマルチパス オプションは、この仕様の新しいバージョンまたは拡張で定義される可能性があります。
These operations are largely inspired by the signals defined in [RFC8684]. The procedures for handling faulty or unknown Multipath Options are described in Section 3.6.
これらの操作は主に [RFC8684] で定義されているシグナルからインスピレーションを得ています。欠陥のある、または不明なマルチパス オプションを処理する手順については、セクション 3.6 で説明されています。
Some Multipath Options require confirmation from the remote peer (see Table 4) for which MP_CONFIRM is specified.
一部のマルチパス オプションでは、MP_CONFIRM が指定されているリモート ピア (表 4 を参照) からの確認が必要です。
1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110| var |00000000| List of confirmations ...
+--------+--------+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=0
Figure 6: Format of the MP_CONFIRM Option
図 6: MP_CONFIRM オプションの形式
Multipath Options that require confirmation will be retransmitted by the sender until an MP_CONFIRM is received or the confirmation of options is considered irrelevant because the data contained in the options has already been replaced by newer information.
確認が必要なマルチパス オプションは、MP_CONFIRM が受信されるか、オプションに含まれるデータがすでに新しい情報に置き換えられているためにオプションの確認が無関係であるとみなされるまで、送信者によって再送信されます。
This can happen, for example, with an MP_PRIO option if the path prioritization is changed while the previous prioritization has not yet been confirmed. The further processing of the Multipath Options in the receiving host is not the subject of MP_CONFIRM.
これは、たとえば MP_PRIO オプションを使用した場合、以前の優先順位がまだ確認されていない間にパスの優先順位が変更された場合に発生する可能性があります。受信側ホストでのマルチパス オプションのその後の処理は MP_CONFIRM の対象ではありません。
Multipath Options could arrive out of order; therefore, Multipath Options defined in Table 4 MUST be sent in a DCCP datagram with MP_SEQ (see Section 3.2.5). This allows a receiver to identify whether Multipath Options are associated with obsolete datasets (information carried in the option header) that would otherwise conflict with newer datasets. In the case of MP_ADDADDR or MP_REMOVEADDR, the same dataset is identified based on AddressID, whereas the same dataset for MP_PRIO is identified by the subflow in use. An outdated multipath Option is detected at the receiver if a previous Multipath Option referring to the same dataset contained a higher sequence number in the MP_SEQ. An MP_CONFIRM MAY be generated for Multipath Options that are identified as outdated.
マルチパス オプションが順序どおりに到着しない可能性があります。したがって、表 4 で定義されたマルチパス オプションは、MP_SEQ を含む DCCP データグラムで送信されなければなりません (セクション 3.2.5 を参照)。これにより、受信側は、マルチパス オプションが、新しいデータセットと競合する古いデータセット (オプション ヘッダーで伝送される情報) に関連付けられているかどうかを識別できます。MP_ADDADDR または MP_REMOVEADDR の場合、同じデータセットは AddressID に基づいて識別されますが、MP_PRIO の同じデータセットは使用中のサブフローによって識別されます。同じデータセットを参照する以前のマルチパス オプションが MP_SEQ 内により高いシーケンス番号を含んでいた場合、古いマルチパス オプションが受信機で検出されます。MP_CONFIRM は、古いと識別されたマルチパス オプションに対して生成されてもよい (MAY)。
Similarly, an MP_CONFIRM could arrive out of order. The associated MP_SEQ received MUST be echoed to ensure that the most recent Multipath Option is confirmed. This protects from inconsistencies that could occur, e.g., if three MP_PRIO options are sent one after the other on one path in order to first set the path priority to 0, then to 1, and finally to 0 again. Without an associated MP_SEQ, a loss of the third MP_PRIO option and a loss of the MP_CONFIRM of the second update and the third update would cause the sender to incorrectly interpret that the priority value was set to 0 without recognizing that the receiver has applied priority value 1.
同様に、MP_CONFIRM が順序どおりに到着しない可能性があります。最新のマルチパス オプションが確認されていることを確認するために、受信した関連する MP_SEQ をエコーしなければなりません (MUST)。これにより、たとえば、パスの優先順位を最初に 0 に設定し、次に 1 に設定し、最後に再び 0 に設定するために 3 つの MP_PRIO オプションが 1 つのパス上で次々に送信される場合などに発生する可能性のある不一致から保護されます。MP_SEQ が関連付けられていない場合、3 番目の MP_PRIO オプションが失われ、2 番目の更新と 3 番目の更新の MP_CONFIRM が失われると、送信側は、受信側が優先順位値 1 を適用したことを認識せず、優先順位値が 0 に設定されていると誤って解釈してしまいます。
The length of the MP_CONFIRM option and the path over which the option is sent depend on the confirmed Multipath Options and the received MP_SEQ, which are both copied verbatim and appended as a list of confirmations. The list is structured by first listing the received MP_SEQ followed by the related Multipath Option or options to confirm. The same rules apply when Multipath Options with different MP_SEQs are confirmed at once. This could happen if the following are received in short succession: a datagram with MP_PRIO and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a second MP_SEQ_2. In this case, the structure described above is concatenated resulting in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO. The order of the confirmed Multipath Options in the list of confirmations MUST reflect the incoming order at the host who sends the MP_CONFIRM, with the most recent suboption received listed first. This could allow the host receiving the MP_CONFIRM to verify that the options were applied in the correct order and to take countermeasures if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR that refers to the same dataset.
MP_CONFIRM オプションの長さとオプションが送信されるパスは、確認されたマルチパス オプションと受信した MP_SEQ によって異なります。これらは両方ともそのままコピーされ、確認のリストとして追加されます。リストは、最初に受信した MP_SEQ をリストし、その後に関連するマルチパス オプションをリストし、確認するためのオプションが続くように構成されています。異なる MP_SEQ を持つマルチパス オプションを一度に確認する場合も、同じルールが適用されます。これは、MP_PRIO と最初の MP_SEQ_1 を含むデータグラムと、MP_ADDADDR と 2 番目の MP_SEQ_2 を含む別のデータグラムを短期間連続で受信した場合に発生する可能性があります。この場合、上記の構造が連結され、MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO になります。確認リスト内の確認されたマルチパス オプションの順序は、MP_CONFIRM を送信するホストでの受信順序を反映し、最後に受信したサブオプションが最初にリストされる必要があります。これにより、MP_CONFIRM を受信するホストは、オプションが正しい順序で適用されたことを確認し、適用されていない場合 (たとえば、MP_REMOVEADDR が同じデータセットを参照する MP_ADDADDR を追い越した場合) に対策を講じることができます。
+======+===============+==================+=========================+
| Type | Option Length | MP_OPT | MP_CONFIRM Sending Path |
+======+===============+==================+=========================+
| 46 | var | 7 =MP_ADDADDR | Any available |
+------+---------------+------------------+-------------------------+
| 46 | 4 | 8 | Any available |
| | | =MP_REMOVEADDR | |
+------+---------------+------------------+-------------------------+
| 46 | 4 | 9 =MP_PRIO | Any available |
+------+---------------+------------------+-------------------------+
Table 4: Multipath Options Requiring Confirmation
表 4: 確認が必要なマルチパス オプション
An example to illustrate the MP-DCCP confirm procedure for the MP_PRIO option is shown in Figure 7. Host A sends a DCCP-Request on path A2-B2 with an MP_PRIO option with value 1 and an associated sequence number of 1. Host B replies on the same path in this instance (any path can be used) with a DCCP-Response containing the MP_CONFIRM option and a list containing the original sequence number (1) together with the associated option (MP_PRIO).
MP_PRIO オプションの MP-DCCP 確認手順を示す例を図 7 に示します。ホスト A は、値 1 の MP_PRIO オプションと関連するシーケンス番号 1 を指定して、パス A2-B2 で DCCP 要求を送信します。ホスト B は、この例では同じパス (任意のパスを使用できます) で、MP_CONFIRM オプションと、元のシーケンス番号 (1) と関連するオプションを含むリストを含む DCCP 応答で応答します。(MP_PRIO)。
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| | DCCP-Request(seqno 1) + MP_PRIO(1)| |
| |------------------------------------------>|
| | | |
| | DCCP-Response + | |
| |<---- MP_CONFIRM(seqno 1, MP_PRIO) --------|
| | | |
Figure 7: Example MP_CONFIRM Procedure
図 7: MP_CONFIRM プロシージャの例
A second example that illustrates the same MP-DCCP confirm procedure but where an out-of-date option is also delivered is shown in Figure 8. Here, the first DCCP-Data is sent from Host A to Host B with option MP_PRIO set to 4. Host A subsequently sends the second DCCP-Data with option MP_PRIO set to 1. In this case, the delivery of the first MP_PRIO is delayed in the network between Host A and Host B and arrives after the second MP_PRIO. Host B ignores this second MP_PRIO as the associated sequence number is earlier than the first. Host B sends a DCCP-Ack with sequence number 2 to confirm the receipt of the MP_PRIO(1).
同じ MP-DCCP 確認手順を示す 2 番目の例ですが、古いオプションも配信される例を図 8 に示します。ここでは、最初の DCCP データが、オプション MP_PRIO を 4 に設定してホスト A からホスト B に送信されます。続いてホスト A は、オプション MP_PRIO を 1 に設定して 2 番目の DCCP データを送信します。この場合、最初の MP_PRIO の配信は、ホスト A とホスト B の間のネットワークで遅延し、2 番目の MP_PRIO の後に到着します。関連するシーケンス番号が最初のものよりも早いため、ホスト B はこの 2 番目の MP_PRIO を無視します。ホスト B は、シーケンス番号 2 の DCCP-Ack を送信して、MP_PRIO(1) の受信を確認します。
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| | DCCP-Data(seqno 1) + MP_PRIO(4) | |
| |------------ | |
| | \ | |
| | DCCP-Data(seqno 2) + MP_PRIO(1) | |
| |--------------\--------------------------->|
| | \ | |
| | -------------------------->|
| | | |
| | DCCP-Ack + | |
| |<---- MP_CONFIRM(seqno 2, MP_PRIO) --------|
| | | |
Figure 8: Example MP_CONFIRM Procedure with an Outdated Suboption
図 8: 古いサブオプションを使用した MP_CONFIRM プロシージャの例
The MP_JOIN option is used to add a new subflow to an existing MP-DCCP connection, and a successful establishment of the first subflow using MP_KEY is REQUIRED.
MP_JOIN オプションは、既存の MP-DCCP 接続に新しいサブフローを追加するために使用され、MP_KEY を使用して最初のサブフローが正常に確立されることが必須です。
1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
|00101110|00001100|00000001| Addr ID|
+--------+--------+--------+--------+
| Connection Identifier |
+--------+--------+--------+--------+
| Nonce |
+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=1
Figure 9: Format of the MP_JOIN Suboption
図 9: MP_JOIN サブオプションの形式
The CI is the one from the peer host, which was previously exchanged with the MP_KEY option. MP_HMAC MUST be set when using MP_JOIN within a DCCP-Response packet; see Section 3.2.6 for details. Similar to the setup of the first subflow, MP_JOIN also exchanges the Multipath Capable Feature MP_CAPABLE as described in Section 3.1. This procedure includes the DCCP Confirm principle and thus ensures a reliable exchange of the MP_JOIN in accordance with Section 6.6.4 of [RFC4340].
CI は、MP_KEY オプションを使用して以前に交換されたピア ホストからの CI です。DCCP-Response パケット内で MP_JOIN を使用する場合は、MP_HMAC を設定しなければなりません。詳細については、セクション 3.2.6 を参照してください。最初のサブフローのセットアップと同様に、MP_JOIN もセクション 3.1 で説明されているようにマルチパス対応機能 MP_CAPABLE を交換します。この手順には DCCP 確認原則が含まれているため、[RFC4340] のセクション 6.6.4 に従って MP_JOIN の信頼できる交換が保証されます。
The MP_JOIN option includes an "Addr ID" (Address ID) generated by the sender of the option, which is used to identify the source address of this packet, even if the IP header was changed in transit by a middlebox. The value of this field is generated by the sender and MUST map uniquely to a source IP address for the sending host. The Address ID allows address removal (Section 3.2.9) without the need to know the source address at the receiver, thus allowing address removal through NATs. The Address ID also allows correlation between new subflow setup attempts and address signaling (Section 3.2.8), to prevent setting up duplicate subflows on the same path, if an MP_JOIN and MP_ADDADDR are sent at the same time.
MP_JOIN オプションには、オプションの送信者によって生成された「Addr ID」（アドレス ID）が含まれます。これは、IP ヘッダーが送信中にミドルボックスによって変更された場合でも、このパケットの送信元アドレスを識別するために使用されます。このフィールドの値は送信者によって生成され、送信ホストの送信元 IP アドレスに一意にマッピングされなければなりません。アドレス ID を使用すると、受信側で送信元アドレスを知る必要がなくてもアドレス削除 (セクション 3.2.9) ができるため、NAT を介したアドレス削除が可能になります。また、アドレス ID により、新しいサブフロー セットアップの試行とアドレス シグナリング (セクション 3.2.8) の間の相関関係が可能になり、MP_JOIN と MP_ADDADDR が同時に送信された場合に、同じパス上に重複するサブフローがセットアップされるのを防ぎます。
The Address IDs of the subflow used in the initial DCCP Request/ Response exchange of the first subflow in the connection are implicit and have the value zero. A host MUST store the mappings between Address IDs and addresses for both itself and the remote host. An implementation will also need to know which local and remote Address IDs are associated with which established subflows for when addresses are removed from a local or remote host. An Address ID MUST always be unique over the lifetime of a subflow and can only be reassigned if sender and receiver no longer have them in use.
接続内の最初のサブフローの最初の DCCP 要求/応答交換で使用されるサブフローのアドレス ID は暗黙的であり、値はゼロです。ホストは、自身とリモート ホストの両方のアドレス ID とアドレス間のマッピングを保存しなければなりません (MUST)。実装では、アドレスがローカルまたはリモート ホストから削除されるときに、どのローカルおよびリモートのアドレス ID がどの確立されたサブフローに関連付けられているかを知る必要もあります。アドレス ID はサブフローの存続期間中常に一意でなければならず、送信者と受信者が使用しなくなった場合にのみ再割り当てできます。
The Nonce is a 32-bit random value locally generated for every MP_JOIN option. Together with the derived key from both hosts' Key Data (as described in Section 3.2.4), the Nonce value builds the basis to calculate the Hash-based Message Authentication Code (HMAC) used in the handshake process (as described in Section 3.3) to avoid replay attacks.
Nonce は、MP_JOIN オプションごとにローカルに生成される 32 ビットのランダム値です。両方のホストの鍵データから導出されたキー (セクション 3.2.4 で説明) とともに、ノンス値は、リプレイ攻撃を回避するためにハンドシェイク プロセス (セクション 3.3 で説明) で使用されるハッシュベースのメッセージ認証コード (HMAC) を計算するための基礎を構築します。
If the CI cannot be verified by the receiving host during a handshake negotiation, the new subflow MUST be closed, as specified in Section 3.6.
ハンドシェイクネゴシエーション中に受信ホストによって CI が検証できない場合、セクション 3.6 で指定されているように、新しいサブフローを閉じなければなりません (MUST)。
DCCP can send a Close or Reset signal to abruptly close a connection. Using MP-DCCP, a regular Close or Reset only has the scope of the subflow over which a signal was received. As such, it will only close the subflow and does not affect other remaining subflows or the MP-DCCP connection (unless it is the last subflow). This permits break-before-make handover between subflows.
DCCP は、Close または Reset 信号を送信して、接続を突然閉じることができます。MP-DCCP を使用すると、通常のクローズまたはリセットのスコープは、信号が受信されたサブフローのみになります。したがって、これはサブフローを閉じるだけであり、他の残りのサブフローや MP-DCCP 接続には影響しません (最後のサブフローでない限り)。これにより、サブフロー間のブレークビフォーメイクハンドオーバーが可能になります。
In order to provide an MP-DCCP-level "reset" and thus allow the abrupt closure of the MP-DCCP connection, the MP_FAST_CLOSE suboption can be used.
MP-DCCP レベルの「リセット」を提供し、MP-DCCP 接続の突然の終了を可能にするために、MP_FAST_CLOSE サブオプションを使用できます。
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| var |00000010| Key Data ...
+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=2
Figure 10: Format of the MP_FAST_CLOSE Suboption
図 10: MP_FAST_CLOSE サブオプションの形式
When Host A wants to abruptly close an MP-DCCP connection with Host B, it will send out the MP_FAST_CLOSE. The MP_FAST_CLOSE suboption MUST be sent from Host A on all subflows using a DCCP-Reset packet with Reset Code 13. The requirement to send the MP_FAST_CLOSE on all subflows increases the probability that Host B will receive the MP_FAST_CLOSE to take the same action. To protect from an unauthorized shutdown of an MP-DCCP connection, the selected Key Data of the peer host during the handshake procedure is carried by the MP_FAST_CLOSE option.
ホスト A がホスト B との MP-DCCP 接続を突然終了したい場合、MP_FAST_CLOSE を送信します。MP_FAST_CLOSE サブオプションは、リセット コード 13 の DCCP-Reset パケットを使用して、すべてのサブフローでホスト A から送信されなければなりません。すべてのサブフローで MP_FAST_CLOSE を送信するという要件により、ホスト B が同じアクションを実行するために MP_FAST_CLOSE を受信する可能性が高くなります。MP-DCCP 接続の不正なシャットダウンから保護するために、ハンドシェイク手順中にピア ホストの選択されたキー データが MP_FAST_CLOSE オプションによって伝送されます。
After sending the MP_FAST_CLOSE on all subflows, Host A MUST tear down all subflows, and the MP-DCCP connection immediately terminates.
すべてのサブフローで MP_FAST_CLOSE を送信した後、ホスト A はすべてのサブフローを破棄しなければなりません (MUST)。MP-DCCP 接続は直ちに終了します。
Upon reception of the first MP_FAST_CLOSE with successfully validated Key Data, Host B will send a DCCP-Reset packet response on all subflows to Host A with Reset Code 13 to clean potential middlebox states. Host B MUST then tear down all subflows and terminate the MP-DCCP connection.
正常に検証されたキー データを含む最初の MP_FAST_CLOSE を受信すると、ホスト B はすべてのサブフローで DCCP-Reset パケット応答をリセット コード 13 とともにホスト A に送信し、潜在的なミドルボックス状態を消去します。その後、ホスト B はすべてのサブフローを破棄し、MP-DCCP 接続を終了しなければなりません。
MP-DCCP protects against some on-path attacker as further outlined in Section 4. The basis of this protection is laid by an initial exchange of keys during the MP-DCCP connection setup, for which MP_KEY is introduced. The basis of this protection is laid by an initial exchange of keys during the MP-DCCP connection setup, for which MP_KEY is introduced.
MP-DCCP は、セクション 4 で詳しく説明するように、パス上の攻撃者から保護します。この保護の基礎は、MP-DCCP 接続セットアップ中の最初の鍵交換によって築かれ、そのために MP_KEY が導入されます。この保護の基礎は、MP-DCCP 接続セットアップ中の最初のキー交換によって確立され、そのために MP_KEY が導入されます。
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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 0 0 1 1| resvd |
+---------------+---------------+---------------+---------------+
| Connection Identifier |
+---------------+---------------+---------------+---------------+
| Key Type (1) | Key Data (1) | Key Type (2) | Key Data (2) |
+---------------+---------------+---------------+---------------+
| Key Type (3) | ...
+---------------+---------------+
Type=46 Length MP_OPT=3
Figure 11: Format of the MP_KEY Suboption
図 11: MP_KEY サブオプションの形式
The MP_KEY suboption is used to exchange a CI and key material between hosts (Host A and Host B) for a given connection. The CI is a unique number in the host for each multipath connection and is generated for inclusion in the first exchange of a connection with MP_KEY. With the CI, it is possible to connect other DCCP subflows to an MP-DCCP connection with MP_JOIN (Section 3.2.2). Its size of 32 bits also defines the maximum number of simultaneous MP-DCCP connections in a host to 2^32. According to the Key-related elements of the MP_KEY suboption, the Length varies between 17 and 73 bytes for a single-key message and up to 82 bytes when all specified Key Types 0 and 255 are provided. The Key Type field specifies the type of the following Key Data. The set of Key Types are shown in Table 5.
MP_KEY サブオプションは、特定の接続のホスト (ホスト A とホスト B) 間で CI とキー マテリアルを交換するために使用されます。CI は、マルチパス接続ごとにホスト内で一意の番号であり、MP_KEY との接続の最初の交換に含めるために生成されます。CI を使用すると、他の DCCP サブフローを MP_JOIN を使用して MP-DCCP 接続に接続できます (セクション 3.2.2)。32 ビットのサイズにより、ホスト内の同時 MP-DCCP 接続の最大数も 2^32 に定義されます。MP_KEY サブオプションのキー関連要素によれば、長さは、単一キー メッセージの場合は 17 ～ 73 バイトの間で変化しますが、指定されたキー タイプ 0 と 255 がすべて指定されている場合は最大 82 バイトになります。「キータイプ」フィールドは、次のキーデータのタイプを指定します。キー タイプのセットを表 5 に示します。
+===============+====================+===================+
| Key Type | Key Length (bytes) | Meaning |
+===============+====================+===================+
| 0 =Plain Text | 8 | Plain text Key |
+---------------+--------------------+-------------------+
| 1-254 | | (available for |
| | | future Key Types) |
+---------------+--------------------+-------------------+
| 255 | 64 | For private use |
| =Experimental | | only |
+---------------+--------------------+-------------------+
Table 5: MP_KEY Key Types
表 5: MP_KEY キーのタイプ
Plain Text:
プレーンテキスト:
Key Data is exchanged in plain text between hosts (Host A and Host B), and the respective key parts (KeyA and KeyB) are used by each host to generate the derived key (d-key) by concatenating the two parts with the local key in front. That is,
キー データはホスト (ホスト A とホスト B) 間でプレーン テキストで交換され、各ホストはそれぞれのキー部分 (KeyA と KeyB) を使用して、先頭にローカル キーを付けて 2 つの部分を連結することによって派生キー (d キー) を生成します。つまり、
Host A:
ホスト A:
d-keyA=(KeyA+KeyB)
d-keyA=(KeyA+KeyB)
Host B:
ホスト B:
d-keyB=(KeyB+KeyA)
d-key=(キーボード+キーS)
Experimental:
実験的:
This Key Type allows the use of other Key Data and can be used to validate other key exchange mechanisms for a possible future specification.
このキー タイプを使用すると、他のキー データの使用が可能になり、将来の仕様に備えて他のキー交換メカニズムを検証するために使用できます。
Multiple keys are only permitted in the DCCP-Request message of the handshake procedure for the first subflow. This allows the hosts to agree on a single Key Type to be used, as described in Section 3.3
複数のキーは、最初のサブフローのハンドシェイク手順の DCCP-Request メッセージでのみ許可されます。これにより、セクション 3.3 で説明されているように、ホストが使用する単一のキー タイプに同意することができます。
It is possible that not all hosts will support all Key Types, and this specification does not recommend or enforce the announcement of any particular Key Type within the MP_KEY option as this could have security implications. However, at least Key Type 0 (Plain Text) MUST be supported for interoperability tests in implementations of MP-DCCP. If the Key Type cannot be agreed in the handshake procedure, the MP-DCCP connection MUST fall back to not using MP-DCCP, as indicated in Section 3.6.
すべてのホストがすべてのキー タイプをサポートしているわけではない可能性があり、セキュリティに影響を与える可能性があるため、この仕様では MP_KEY オプション内で特定のキー タイプをアナウンスすることを推奨または強制しません。ただし、MP-DCCP の実装における相互運用性テストでは、少なくともキー タイプ 0 (プレーン テキスト) がサポートされなければなりません (MUST)。ハンドシェイク手順で鍵タイプが合意できない場合、MP-DCCP 接続は、セクション 3.6 に示されているように、MP-DCCP を使用しないようにフォールバックしなければなりません (MUST)。
DCCP [RFC4340] defines a packet sequencing scheme that continues to apply to the individual DCCP subflows within an MP-DCCP connection. However, for the operation of MP-DCPP, the order of packets within an MP-DCCP connection MUST be known before assigning packets to subflows to apply the received Multipath Options in the correct order or to recognize whether delayed Multipath Options are obsolete. Therefore, MP_SEQ is introduced and can also be used to reorder data packets on the receiver side.
DCCP [RFC4340] は、MP-DCCP 接続内の個々の DCCP サブフローに引き続き適用されるパケット シーケンス スキームを定義します。ただし、MP-DCPP の動作では、受信したマルチパス オプションを正しい順序で適用するため、または遅延マルチパス オプションが廃止されたかどうかを認識するために、パケットをサブフローに割り当てる前に、MP-DCCP 接続内のパケットの順序を知っておく必要があります。したがって、MP_SEQ が導入され、受信側でデータ パケットの順序を変更するためにも使用できます。
1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|00001001|00000100| Multipath Sequence Number
+--------+--------+--------+--------+--------+--------+--------+
|
+--------+--------+
Type=46 Length=9 MP_OPT=4
Figure 12: Format of the MP_SEQ Suboption
図 12: MP_SEQ サブオプションのフォーマット
The MP_SEQ suboption is used for end-to-end 48-bit datagram-based sequence numbers of an MP-DCCP connection. The initial data sequence number (IDSN) SHOULD be set randomly [RFC4086]. As with the standard DCCP sequence number, the data sequence number should not start at zero but at a random value to make blind session hijacking more difficult; see also Section 7.2 of [RFC4340].
MP_SEQ サブオプションは、MP-DCCP 接続のエンドツーエンドの 48 ビット データグラムベースのシーケンス番号に使用されます。初期データシーケンス番号 (IDSN) はランダムに設定されるべきです [RFC4086]。標準 DCCP シーケンス番号と同様、ブラインド セッション ハイジャックをより困難にするために、データ シーケンス番号はゼロではなくランダムな値で始まる必要があります。[RFC4340] のセクション 7.2 も参照してください。
The MP_SEQ number space is independent of the path individual sequence number space and MUST be sent with all DCCP-Data and DCCP-DataACK packets.
MP_SEQ 番号空間は、パスの個別のシーケンス番号空間から独立しており、すべての DCCP-Data パケットおよび DCCP-DataACK パケットとともに送信されなければなりません (MUST)。
When the sequence number space is exhausted, the sequence number MUST be wrapped. [RFC7323] provides guidance on selecting an appropriately sized sequence number space according to the Maximum Segment Lifetime (MSL) of TCP. 64 bits is the recommended size for TCP to avoid the sequence number space going through within the segment lifetime. For DCCP, the MSL is the same as that of TCP as specified in Section 3.4 of [RFC4340]. Compared to TCP, the sequence number for DCCP is incremented per packet rather than per byte transmitted. For this reason, the 48 bits chosen in MP_SEQ are considered sufficiently large per the current globally routable maximum packet size (MPS) of 1500 bytes, which corresponds to roughly 375 pebibytes (PiBs) of data within the sequence number space.
シーケンス番号のスペースが使い果たされた場合、シーケンス番号をラップする必要があります。[RFC7323] は、TCP の最大セグメント存続期間 (MSL) に従って、適切なサイズのシーケンス番号空間を選択するためのガイダンスを提供します。セグメントの有効期間内にシーケンス番号スペースが通過するのを避けるため、TCP の推奨サイズは 64 ビットです。DCCP の場合、MSL は [RFC4340] のセクション 3.4 で指定されている TCP の MSL と同じです。TCP と比較すると、DCCP のシーケンス番号は送信バイトごとではなくパケットごとに増加します。このため、MP_SEQ で選択された 48 ビットは、現在グローバルにルーティング可能な最大パケット サイズ (MPS) の 1500 バイトに対して十分大きいと考えられます。これは、シーケンス番号空間内のデータの約 375 ペビバイト (PiB) に相当します。
MP-DCCP protects against some on-path attacker as further outlined in Section 4. Once an MP-DCCP connection has been established, the MP_HMAC option introduced here provides further protection based on the key material exchanged with MP_KEY when the connection is established.
MP-DCCP は、セクション 4 で詳しく説明するように、パス上の攻撃者から保護します。MP-DCCP 接続が確立されると、ここで紹介する MP_HMAC オプションは、接続の確立時に MP_KEY と交換される鍵マテリアルに基づいてさらなる保護を提供します。
1 2 3 4
01234567 89012345 67890123 45678901 23456789 01234567
+--------+--------+--------+--------+--------+--------+
|00101110|00010111|00000101| HMAC-SHA256 (20 bytes) ...
+--------+--------+--------+--------+--------+--------+
Type=46 Length=23 MP_OPT=5
Figure 13: Format of the MP_HMAC Suboption
図 13: MP_HMAC サブオプションのフォーマット
The MP_HMAC suboption is used to provide authentication for the MP_ADDADDR and MP_REMOVEADDR suboptions. In addition, it provides authentication for subflows joining an existing MP_DCCP connection, as described in the second and third step of the handshake of a subsequent subflow in Section 3.3. For this specification of MP-DCCP, the HMAC code is generated according to [RFC2104] in combination with the SHA-256 hash algorithm described in [RFC6234], with the output in big-endian format truncated to the leftmost 160 bits (20 bytes). It is possible that other versions of MP-DCCP will define other hash algorithms in the future.
MP_HMAC サブオプションは、MP_ADDADDR および MP_REMOVEADDR サブオプションの認証を提供するために使用されます。さらに、セクション 3.3 の後続のサブフローのハンドシェイクの 2 番目と 3 番目のステップで説明されているように、既存の MP_DCCP 接続に参加するサブフローの認証も提供します。MP-DCCP のこの仕様では、HMAC コードは [RFC2104] に従って、[RFC6234] で説明されている SHA-256 ハッシュ アルゴリズムと組み合わせて生成され、ビッグエンディアン形式の出力は左端の 160 ビット (20 バイト) に切り捨てられます。将来、MP-DCCP の他のバージョンで他のハッシュ アルゴリズムが定義される可能性があります。
The "Key" used for the HMAC computation is the derived key (d-keyA for Host A or d-KeyB for Host B) described in Section 3.2.4, while the HMAC "Message" for MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR must be calculated in both hosts in order to protect the Multipath Option when sending and to validate the Multipath Option when receiving; it is a concatenation of:
HMAC の計算に使用される「キー」は、セクション 3.2.4 で説明されている導出キー (ホスト A の場合は d-keyA、ホスト B の場合は d-KeyB) ですが、MP_JOIN、MP_ADDADDR、および MP_REMOVEADDR の HMAC「メッセージ」は、送信時にマルチパス オプションを保護し、受信時にマルチパス オプションを検証するために両方のホストで計算する必要があります。それは次のものを連結したものです:
* For MP_JOIN: The Nonces of the MP_JOIN messages for which authentication shall be performed. Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows:
* MP_JOIN の場合: 認証が実行される MP_JOIN メッセージの Nonce。HMAC-SHA256 計算をホスト A またはホスト B のどちらで実行するかに応じて、計算は次のように実行されます。
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA、Msg=RA+RB)
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB、Msg=RB+RA)
A usage example is shown in Figure 21.
使用例を図 21 に示します。
* For MP_ADDADDR: The Address ID and Nonce with an associated IP address and a port, if defined; otherwise, 2 bytes of value 0. The IP address and port MUST be used in network byte order (NBO). Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows:
* MP_ADDADDR の場合: アドレス ID とナンス、および関連する IP アドレスとポート (定義されている場合)。それ以外の場合は、値 0 の 2 バイト。IP アドレスとポートはネットワーク バイト オーダー (NBO) で使用する必要があります。HMAC-SHA256 計算をホスト A またはホスト B のどちらで実行するかに応じて、計算は次のように実行されます。
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA、Msg=アドレスID+Nonce+NBO(IP)+NBO(ポート))
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce+NBO(IP)+NBO(Port))
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB、Msg=アドレスID+Nonce+NBO(IP)+NBO(ポート))
* For MP_REMOVEADDR: Solely the Address ID. Depending on whether Host A or Host B performs the HMAC-SHA256 calculation, it is carried out as follows:
* MP_REMOVEADDR の場合: アドレス ID のみ。HMAC-SHA256 計算をホスト A またはホスト B のどちらで実行するかに応じて、計算は次のように実行されます。
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=Address ID+Nonce)
- MP_HMAC(A) = HMAC-SHA256(Key=d-keyA、Msg=アドレスID+Nonce)
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=Address ID+Nonce)
- MP_HMAC(B) = HMAC-SHA256(Key=d-keyB、Msg=アドレスID+Nonce)
MP_JOIN, MP_ADDADDR, and MP_REMOVEADDR can coexist or be used multiple times within a single DCCP packet. All these Multipath Options require an individual MP_HMAC option. This ensures that the MP_HMAC is correctly associated. Otherwise, the receiver cannot validate multiple MP_JOIN, MP_ADDADDR, or MP_REMOVEADDR options. Therefore, an MP_HMAC MUST directly follow its associated Multipath Option. In the likely case of sending an MP_JOIN together with an MP_ADDADDR, this results in concatenating MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2, whereas the first MP_HMAC_1 is associated with the MP_JOIN and the second MP_HMAC_2 is associated with the MP_ADDADDR suboption.
MP_JOIN、MP_ADDADDR、および MP_REMOVEADDR は、単一の DCCP パケット内で共存または複数回使用できます。これらすべてのマルチパス オプションには、個別の MP_HMAC オプションが必要です。これにより、MP_HMAC が正しく関連付けられるようになります。そうしないと、受信側は複数の MP_JOIN、MP_ADDADDR、または MP_REMOVEADDR オプションを検証できません。したがって、MP_HMAC は、関連するマルチパス オプションに直接従わなければなりません (MUST)。MP_JOIN を MP_ADDADDR と一緒に送信する可能性の高いケースでは、MP_JOIN + MP_HMAC_1 + MP_ADDADDR + MP_HMAC_2 が連結されますが、最初の MP_HMAC_1 は MP_JOIN に関連付けられ、2 番目の MP_HMAC_2 は MP_ADDADDR サブオプションに関連付けられます。
On the receiver side, the HMAC validation of the suboptions MUST be carried out according to the sending sequence in which the associated MP_HMAC follows a suboption. If the suboption cannot be validated by a receiving host because the HMAC validation fails (HMAC is wrong or missing), the subsequent handling depends on which suboption was being verified. If the suboption to be authenticated was either MP_ADDADDR or MP_REMOVEADDR, the receiving host MUST silently ignore it (see Sections 3.2.8 and 3.2.9). If the suboption to be authenticated was MP_JOIN, the subflow MUST be closed (see Section 3.6).
受信側では、サブオプションの HMAC 検証は、関連する MP_HMAC がサブオプションに続く送信シーケンスに従って実行されなければなりません (MUST)。HMAC 検証が失敗した (HMAC が間違っているか欠落している) ために受信側ホストでサブオプションを検証できない場合、その後の処理はどのサブオプションが検証されているかによって異なります。認証されるサブオプションが MP_ADDADDR または MP_REMOVEADDR の場合、受信ホストはそれを黙って無視しなければなりません (セクション 3.2.8 および 3.2.9 を参照)。認証されるサブオプションが MP_JOIN だった場合、サブフローは閉じられなければなりません (セクション 3.6 を参照)。
In the event that an MP_HMAC cannot be associated with a suboption, this MP_HMAC MUST be ignored, unless it is a single MP_HMAC that was sent in a DCCP-Ack corresponding to a DCCP response packet with MP_JOIN (see the penultimate arrow in Figure 21).
MP_HMAC をサブオプションに関連付けることができない場合、MP_JOIN を含む DCCP 応答パケットに対応する DCCP-Ack で送信された単一の MP_HMAC でない限り、この MP_HMAC は無視されなければなりません (図 21 の最後から 2 番目の矢印を参照)。
The MP_RTT suboption is used to transmit RTT values and Age (represented in milliseconds) that belong to the path over which this information is transmitted. This information is useful for the receiving host to calculate the RTT difference between the subflows and to estimate whether missing data has been lost.
MP_RTT サブオプションは、この情報が送信されるパスに属する RTT 値とエージ (ミリ秒で表される) を送信するために使用されます。この情報は、受信ホストがサブフロー間の RTT の差を計算し、欠落データが失われたかどうかを推定するのに役立ちます。
1 2 3 4 5
01234567 89012345 67890123 45678901 23456789 01234567 89012345
+--------+--------+--------+--------+--------+--------+--------+
|00101110|00001100|00000110|RTT Type| RTT
+--------+--------+--------+--------+--------+--------+--------+
| Age |
+--------+--------+--------+--------+--------+
Type=46 Length=12 MP_OPT=6
Figure 14: Format of the MP_RTT Suboption
図 14: MP_RTT サブオプションのフォーマット
The RTT and Age information is a 32-bit integer. This covers a period of approximately 1193 hours.
RTT と経過時間の情報は 32 ビットの整数です。これは約 1193 時間の期間をカバーします。
The Field RTT type indicates the type of RTT estimation, according to the following description:
フィールド RTT タイプは、次の説明に従って RTT 推定のタイプを示します。
Raw RTT (=0)
生の RTT (=0)
Raw RTT value of the last Datagram round trip.
最後のデータグラム往復の生の RTT 値。
Min RTT (=1)
最小 RTT (=1)
Min RTT value over a given period.
指定された期間における最小 RTT 値。
Max RTT (=2)
最大RTT (=2)
Max RTT value over a given period.
指定された期間の最大 RTT 値。
Smooth RTT (=3)
スムーズな RTT (=3)
Averaged RTT value over a given period.
指定された期間の平均 RTT 値。
Each CCID specifies the algorithms and period applied for their corresponding RTT estimations. The availability of the above-described types, to be used in the MP_RTT option, depends on the CCID implementation in place.
各 CCID は、対応する RTT 推定に適用されるアルゴリズムと期間を指定します。MP_RTT オプションで使用される上記のタイプが利用できるかどうかは、適切な CCID 実装によって異なります。
Age:
Age:
The Age parameter defines the time difference between now -- the creation of the MP_RTT option -- and the conducted RTT measurement in milliseconds. If no previous measurement exists, e.g., when initialized, the value is 0.
Age パラメーターは、現在 (MP_RTT オプションの作成) と実行された RTT 測定の間の時間差をミリ秒単位で定義します。以前の測定値が存在しない場合（初期化時など）、値は 0 です。
An example of a flow showing the exchange of path individual RTT information is provided in Figure 15. RTT1 refers to the first path and RTT2 to the second path. The RTT values could be extracted from the sender's congestion control algorithm and are conveyed to the receiving host using the MP_RTT suboption. With the reception of RTT1 and RTT2, the receiver is able to calculate the path_delta that corresponds to the absolute difference of both values. In the case where the path individual RTTs are symmetric in the down-link and up-link directions and there is no jitter, packets with missing sequence number MP_SEQ, e.g., in a reordering process, can be assumed lost after path_delta/2.
パス個別の RTT 情報の交換を示すフローの例を図 15 に示します。RTT1 は最初のパスを指し、RTT2 は 2 番目のパスを指します。RTT 値は、送信側の輻輳制御アルゴリズムから抽出され、MP_RTT サブオプションを使用して受信側ホストに伝達されます。RTT1 と RTT2 を受信すると、受信機は両方の値の絶対差に対応する path_delta を計算できます。パスの個々の RTT がダウンリンク方向とアップリンク方向で対称であり、ジッターがない場合、順序変更プロセスなどでシーケンス番号 MP_SEQ が欠落しているパケットは、path_delta/2 の後に失われたと想定できます。
MP-DCCP MP-DCCP
Sender Receiver
+--------+ MP_RTT(RTT1) +-------------+
| RTT1 |----------------| |
| | | path_delta= |
| | MP_RTT(RTT2) | |RTT1-RTT2| |
| RTT2 |----------------| |
+--------+ +-------------+
Figure 15: Exemplary Flow of MP_RTT Exchange and Usage
図 15: MP_RTT 交換および使用の流れの例
The MP_ADDADDR suboption announces additional addresses (and, optionally, port numbers) by which a host can be reached. This can be sent at any time during an existing MP-DCCP connection, when the sender wishes to enable multiple paths and/or when additional paths become available. Multiple instances of this suboption within a packet can simultaneously advertise new addresses.
MP_ADDADDR サブオプションは、ホストにアクセスできる追加のアドレス (およびオプションでポート番号) を通知します。これは、既存の MP-DCCP 接続中、送信者が複数のパスを有効にしたいとき、および/または追加のパスが利用可能になったときに、いつでも送信できます。パケット内のこのサブオプションの複数のインスタンスは、新しいアドレスを同時にアドバタイズできます。
The Length is variable depending on the address family (IPv4 or IPv6) and whether a port number is used. This field is in the range between 12 and 26 bytes.
長さは、アドレス ファミリ (IPv4 または IPv6) とポート番号が使用されているかどうかによって異なります。このフィールドの範囲は 12 ～ 26 バイトです。
The Nonce is a 32-bit random value that is generated locally for each MP_ADDADDR option and is used in the HMAC calculation process to prevent replay attacks.
Nonce は、MP_ADDADDR オプションごとにローカルに生成される 32 ビットのランダム値で、リプレイ攻撃を防ぐために HMAC 計算プロセスで使用されます。
The final 2 bytes optionally specify the DCCP port number to use, and their presence can be inferred from the length of the option. Although it is expected that the majority of use cases will use the same port pairs as used for the initial subflow (e.g., port 80 remains port 80 on all subflows, as does the ephemeral port at the client), there could be cases (such as port-based load balancing) where the explicit specification of a different port is required. If no port is specified, the receiving host MUST assume that any attempt to connect to the specified address uses the port already used by the subflow on which the MP_ADDADDR signal was sent.
最後の 2 バイトでは、使用する DCCP ポート番号をオプションで指定します。その存在はオプションの長さから推測できます。ほとんどのユースケースでは、最初のサブフローに使用したのと同じポート ペアを使用することが予想されますが (たとえば、クライアントの一時ポートと同様に、ポート 80 はすべてのサブフローでポート 80 のままです)、別のポートの明示的な指定が必要な場合 (ポート ベースの負荷分散など) が存在する可能性があります。ポートが指定されていない場合、受信ホストは、指定されたアドレスへの接続試行では、MP_ADDADDR 信号が送信されたサブフローによってすでに使用されているポートを使用すると想定しなければなりません (MUST)。
Along with the MP_ADDADDR option, an MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter present in this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as described in Section 3.2.6. Similar to MP_JOIN, the key for the HMAC algorithm will be d-KeyA when the message is transmitted by Host A and d-KeyB when transmitted by Host B. These are the keys that were exchanged and selected in the original MP_KEY handshake. The message for the HMAC is the Address ID, Nonce, IP address, and port number that precede the HMAC in the MP_ADDADDR option. If the port number is not present in the MP_ADDADDR option, the HMAC message will include 2 bytes of value zero. The rationale for the HMAC is to prevent unauthorized entities from injecting MP_ADDADDR signals in an attempt to hijack a connection. Additionally, note that the presence of this HMAC prevents the address from being changed in flight unless the key is known by an intermediary. If a host receives an MP_ADDADDR option for which it cannot validate the HMAC, it MUST silently ignore the option.
MP_ADDADDR オプションとともに、認証のために MP_HMAC オプションを送信する必要があります。この MP_HMAC オプションに存在する切り捨てられた HMAC パラメータは、HMAC の左端の 20 バイトであり、セクション 3.2.6 で説明されているようにネゴシエートおよび計算されます。MP_JOIN と同様に、HMAC アルゴリズムのキーは、メッセージがホスト A によって送信される場合は d-KeyA になり、ホスト B によって送信される場合は d-KeyB になります。これらは、元の MP_KEY ハンドシェイクで交換および選択されたキーです。HMAC のメッセージは、MP_ADDADDR オプションの HMAC の前にあるアドレス ID、ノンス、IP アドレス、およびポート番号です。MP_ADDADDR オプションにポート番号が存在しない場合、HMAC メッセージには値 0 の 2 バイトが含まれます。HMAC の理論的根拠は、権限のないエンティティが接続をハイジャックしようとして MP_ADDADDR 信号を挿入することを防ぐことです。さらに、この HMAC の存在により、キーが仲介者に知られていない限り、送信中にアドレスが変更されることが防止されることに注意してください。ホストが HMAC を検証できない MP_ADDADDR オプションを受け取った場合、そのオプションを黙って無視しなければなりません (MUST)。
The presence of an MP_SEQ (Section 3.2.5) MUST be ensured in a DCCP datagram in which MP_ADDADDR is sent, as described in Section 3.2.1.
セクション 3.2.1 で説明されているように、MP_ADDADDR が送信される DCCP データグラム内に MP_SEQ (セクション 3.2.5) の存在が保証されなければなりません (MUST)。
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
+---------------+---------------+-------+-------+---------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 0 1 1 1| Address ID |
+---------------+---------------+-------+-------+---------------+
| Nonce |
+-------------------------------+-------------------------------+
| Address (IPv4 - 4 bytes / IPv6 - 16 bytes) |
+-------------------------------+-------------------------------+
| Port (2 bytes, optional) | + MP_HMAC option
+-------------------------------+
Type=46 Length MP_OPT=7
Figure 16: Format of the MP_ADDADDR Suboption
図 16: MP_ADDADDR サブオプションのフォーマット
Each address has an Address ID that could be used for uniquely identifying the address within a connection for address removal. Each host maintains a list of unique Address IDs, and it manages these as it wishes. The Address ID is also used to identify MP_JOIN options (see Section 3.2.2) relating to the same address, even when address translators are in use. The Address ID MUST uniquely identify the address for the sender of the option (within the scope of the connection); the mechanism for allocating such IDs is implementation specific.
各アドレスにはアドレス ID があり、アドレスを削除するために接続内でアドレスを一意に識別するために使用できます。各ホストは一意のアドレス ID のリストを維持し、必要に応じてこれらを管理します。アドレス ID は、アドレス変換器が使用されている場合でも、同じアドレスに関連する MP_JOIN オプション (セクション 3.2.2 を参照) を識別するためにも使用されます。アドレス ID は、(接続の範囲内で) オプションの送信者のアドレスを一意に識別しなければなりません。このような ID を割り当てるメカニズムは実装固有です。
All Address IDs learned via either MP_JOIN or MP_ADDADDR can be stored by the receiver in a data structure that gathers all the Address-ID-to-address mappings for a connection (identified by a CI pair). In this way, there is a stored mapping between the Address ID, the observed source address, and the CI pair for future processing of control information for a connection. Note that an implementation MAY discard incoming address advertisements. Reasons for this are, for example:
MP_JOIN または MP_ADDADDR のいずれかを介して学習したすべてのアドレス ID は、受信側によって、接続 (CI ペアで識別される) のすべてのアドレス ID からアドレスへのマッピングを収集するデータ構造に保存できます。このようにして、接続の制御情報を将来処理するために、アドレス ID、観測された送信元アドレス、および CI ペア間のマッピングが保存されます。実装では受信アドレス通知を破棄してもよい(MAY)ことに注意してください。その理由としては、例えば次のようなものが考えられます。
* to avoid the required mapping state, or
* 必要なマッピング状態を回避するため、または
* because advertised addresses are of no use to it.
* なぜなら、アドバタイズされたアドレスは役に立たないからです。
Possible scenarios in which this applies are the lack of resources to store a mapping or when IPv6 addresses are advertised even though the host only supports IPv4. Therefore, a host MUST treat address announcements as soft state. However, a sender MAY choose to update the announcements periodically to overcome temporary limitations.
これが当てはまるシナリオとしては、マッピングを保存するためのリソースが不足している場合や、ホストが IPv4 のみをサポートしているにもかかわらず IPv6 アドレスがアドバタイズされている場合などが考えられます。したがって、ホストはアドレスアナウンスをソフトステートとして扱わなければなりません(MUST)。ただし、送信者は、一時的な制限を克服するために、アナウンスを定期的に更新することを選択してもよい(MAY)。
A host MAY advertise private addresses, e.g., because there is a NAT on the path. It is desirable to allow this as there could be cases where both hosts have additional interfaces on the same private network. The advertisement of broadcast or multicast IP addresses MUST be ignored by the recipient of this option, as it is not permitted according to the unicast principle of the basic DCCP.
ホストは、たとえばパス上に NAT があるため、プライベート アドレスをアドバタイズしてもよい(MAY)。両方のホストが同じプライベート ネットワーク上に追加のインターフェイスを持つ場合があるため、これを許可することが望ましいです。ブロードキャストまたはマルチキャスト IP アドレスのアドバタイズメントは、基本 DCCP のユニキャスト原則に従って許可されていないため、このオプションの受信者は無視しなければなりません (MUST)。
The MP_JOIN handshake used to create a new subflow (Section 3.2.2) provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit CI that uniquely identifies a connection to the receiving host. If the CI is unknown, the host MUST send a DCCP-Reset.
新しいサブフローの作成に使用される MP_JOIN ハンドシェイク (セクション 3.2.2) は、セキュリティ リスクを最小限に抑えるメカニズムを提供します。MP_JOIN メッセージには、受信ホストへの接続を一意に識別する 32 ビット CI が含まれています。CI が不明な場合、ホストは DCCP-Reset を送信しなければなりません。
Further security considerations around the issue of MP_ADDADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in Section 4. If a sending host of an MP_ADDADDR knows that no incoming subflows can be established at a particular address, an MP_ADDADDR MUST NOT announce that address unless the sending host has new knowledge about the possibility to do so. This information can be obtained from local firewall or routing settings, knowledge about availability of an external NAT or a firewall, or connectivity checks performed by the host/application.
新たな MP_JOIN 試行を誤って誘導したり、悪意を持って誘導したりする MP_ADDADDR メッセージの問題に関するさらなるセキュリティ上の考慮事項については、セクション 4 で説明します。 MP_ADDADDR の送信側ホストが、特定のアドレスで着信サブフローを確立できないことを知っている場合、送信側ホストがその可能性について新たな知識を持っていない限り、MP_ADDADDR はそのアドレスをアナウンスしてはなりません (MUST NOT)。この情報は、ローカルのファイアウォールまたはルーティング設定、外部 NAT またはファイアウォールの可用性に関する情報、またはホスト/アプリケーションによって実行される接続チェックから取得できます。
The reception of an MP_ADDADDR message is acknowledged using MP_CONFIRM (Section 3.2.1). This ensures a reliable exchange of address information.
MP_ADDADDR メッセージの受信は、MP_CONFIRM (セクション 3.2.1) を使用して確認されます。これにより、アドレス情報の信頼性の高い交換が保証されます。
A host that receives an MP_ADDADDR but finds that the IP address and port number is unsuccessful at connection setup SHOULD NOT perform further connection attempts to this address/port combination for this connection to save resources. However, if a sender wishes to trigger a new incoming connection attempt on a previously advertised address/ port combination, they can refresh the MP_ADDADDR information by sending the option again.
MP_ADDADDR を受信したが、接続セットアップ時に IP アドレスとポート番号が失敗したことが判明したホストは、リソースを節約するために、この接続に対してこのアドレス/ポートの組み合わせへのさらなる接続試行を実行してはなりません (SHOULD NOT)。ただし、送信者が以前に通知されたアドレスとポートの組み合わせで新しい受信接続の試行をトリガーしたい場合は、オプションを再度送信することで MP_ADDADDR 情報を更新できます。
A host MAY send an MP_ADDADDR message with an already-assigned Address ID using the IP address previously assigned to this Address ID. The new MP_ADDADDR could have the same port number or a different port number. The receiver MUST silently ignore the MP_ADDADDR if the IP address is not the same as that previously assigned to this Address ID. A host wishing to replace an existing Address ID MUST first remove the existing one (Section 3.2.9).
ホストは、このアドレス ID に以前に割り当てられた IP アドレスを使用して、すでに割り当てられたアドレス ID を持つ MP_ADDADDR メッセージを送信してもよい(MAY)。新しい MP_ADDADDR は、同じポート番号を持つことも、異なるポート番号を持つこともできます。IP アドレスがこのアドレス ID に以前に割り当てられたものと同じでない場合、受信者は MP_ADDADDR を黙って無視しなければなりません (MUST)。既存のアドレス ID を置き換えたいホストは、まず既存のアドレス ID を削除しなければなりません (セクション 3.2.9)。
If, during the lifetime of an MP-DCCP connection, a previously announced address becomes invalid (e.g., if an interface disappears), the affected host SHOULD announce this. The peer can remove a previously added address with an Address ID from a connection using the Remove Address (MP_REMOVEADDR) suboption. This will terminate any subflows currently using that address.
MP-DCCP 接続の存続期間中に、以前に通知されたアドレスが無効になった場合 (たとえば、インターフェイスが消失した場合)、影響を受けるホストはこれを通知する必要があります (SHOULD)。ピアは、アドレス削除 (MP_REMOVEADDR) サブオプションを使用して、アドレス ID を持つ以前に追加されたアドレスを接続から削除できます。これにより、現在そのアドレスを使用しているサブフローが終了します。
MP_REMOVEADDR is only used to close already-established subflows that have an invalid address. Functional flows with a valid address MUST be closed with a DCCP Close exchange (as with regular DCCP) instead of using MP_REMOVEADDR. For more information see Section 3.5.
MP_REMOVEADDR は、無効なアドレスを持つすでに確立されたサブフローを閉じるためにのみ使用されます。有効なアドレスを持つ機能フローは、MP_REMOVEADDR を使用する代わりに、DCCP Close 交換 (通常の DCCP と同様) で閉じなければなりません (MUST)。詳細については、セクション 3.5 を参照してください。
The Nonce is a 32-bit random value that is generated locally for each MP_REMOVEADDR option and is used in the HMAC calculation process to prevent replay attacks.
Nonce は、MP_REMOVEADDR オプションごとにローカルで生成される 32 ビットのランダム値で、リプレイ攻撃を防ぐために HMAC 計算プロセスで使用されます。
Along with the MP_REMOVEADDR suboption, an MP_HMAC option MUST be sent for authentication. The truncated HMAC parameter present in this MP_HMAC option is the leftmost 20 bytes of an HMAC, negotiated and calculated as described in Section 3.2.6. Similar to MP_JOIN, the key for the HMAC algorithm will be d-KeyA when the message is transmitted by Host A and d-KeyB when transmitted by Host B. These are the keys that were exchanged and selected in the original MP_KEY handshake. The message for the HMAC is the Address ID.
MP_REMOVEADDR サブオプションとともに、認証のために MP_HMAC オプションを送信する必要があります。この MP_HMAC オプションに存在する切り捨てられた HMAC パラメータは、HMAC の左端の 20 バイトであり、セクション 3.2.6 で説明されているようにネゴシエートおよび計算されます。MP_JOIN と同様に、HMAC アルゴリズムのキーは、メッセージがホスト A によって送信される場合は d-KeyA になり、ホスト B によって送信される場合は d-KeyB になります。これらは、元の MP_KEY ハンドシェイクで交換および選択されたキーです。HMAC のメッセージはアドレス ID です。
The rationale for using an HMAC is to prevent unauthorized entities from injecting MP_REMOVEADDR signals in an attempt to hijack a connection. Additionally, note that the presence of this HMAC prevents the address from being modified in flight unless the key is known by an intermediary. If a host receives an MP_REMOVEADDR option for which it cannot validate the HMAC, it MUST silently ignore the option.
HMAC を使用する理由は、権限のないエンティティが接続をハイジャックしようとして MP_REMOVEADDR 信号を挿入することを防ぐことです。さらに、この HMAC の存在により、キーが仲介者に知られていない限り、送信中にアドレスが変更されることが防止されることに注意してください。ホストが HMAC を検証できない MP_REMOVEADDR オプションを受け取った場合、そのオプションを黙って無視しなければなりません (MUST)。
A receiver MUST include an MP_SEQ (Section 3.2.5) in a DCCP datagram that sends an MP_REMOVEADDR. Further details are given in Section 3.2.1.
受信機は、MP_REMOVEADDR を送信する MP_SEQ (セクション 3.2.5) を DCCP データグラムに含めなければなりません (MUST)。詳細については、セクション 3.2.1 を参照してください。
The reception of an MP_REMOVEADDR message is acknowledged using MP_CONFIRM (Section 3.2.1). This ensures a reliable exchange of address information. To avoid inconsistent states, the sender releases the Address ID only after MP_REMOVEADDR has been confirmed.
MP_REMOVEADDR メッセージの受信は、MP_CONFIRM (セクション 3.2.1) を使用して確認されます。これにより、アドレス情報の信頼性の高い交換が保証されます。不整合な状態を避けるために、送信者は MP_REMOVEADDR が確認された後にのみアドレス ID を解放します。
The sending and receiving of this message SHOULD trigger the closing procedure described in [RFC4340] between the client and the server on the affected subflow(s), if possible. This helps remove middlebox state before removing any local state.
このメッセージの送受信は、可能であれば、影響を受けるサブフロー上のクライアントとサーバーの間で、[RFC4340] で説明されている終了手順をトリガーする必要があります (SHOULD)。これは、ローカル状態を削除する前にミドルボックス状態を削除するのに役立ちます。
Address removal is done by the Address ID to allow the use of NATs and other middleboxes that rewrite source addresses. If there is no address at the requested Address ID, the receiver will silently ignore the request.
アドレスの削除はアドレス ID によって行われ、送信元アドレスを書き換える NAT やその他のミドルボックスの使用を許可します。要求されたアドレス ID にアドレスがない場合、受信者は何も通知せずに要求を無視します。
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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 0| Address ID |
+---------------+---------------+---------------+---------------+
| Nonce |
+-------------------------------+-------------------------------+
Type=46 Length=8 MP_OPT=8
-> followed by the MP_HMAC option
Figure 17: Format of the MP_REMOVEADDR Suboption
図 17: MP_REMOVEADDR サブオプションのフォーマット
The path priority signaled with the MP_PRIO option provides hints for the packet scheduler when making decisions about which path to use for payload traffic. When a single specific path from the set of available paths is treated with higher priority compared to the others when making scheduling decisions for payload traffic, a host can signal such change in priority to the peer. This could be used when there are different costs for using different paths (e.g., Wi-Fi is free while cellular has a limit on volume, and 5G has higher energy consumption). The priority of a path could also change, for example, when a mobile host runs out of battery, and the usage of only a single path may be the preferred choice of the user.
MP_PRIO オプションで通知されるパス優先度は、ペイロード トラフィックにどのパスを使用するかを決定する際に、パケット スケジューラにヒントを提供します。ペイロード トラフィックのスケジューリングを決定する際に、利用可能なパスのセットからの 1 つの特定のパスが他のパスよりも高い優先度で扱われる場合、ホストはそのような優先度の変更をピアに通知できます。これは、さまざまなパスの使用にさまざまなコストがかかる場合に使用できます（たとえば、Wi-Fi は無料ですが、セルラー通信には容量制限があり、5G のエネルギー消費量は高くなります）。たとえば、モバイル ホストのバッテリーが切れた場合など、パスの優先順位も変わる可能性があり、単一のパスのみを使用することがユーザーの優先選択となる場合があります。
The MP_PRIO suboption, shown below, can be used to set a priority value for the subflow over which the suboption is received.
以下に示す MP_PRIO サブオプションは、サブオプションが受信されるサブフローの優先順位値を設定するために使用できます。
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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0|0 0 0 0 0 1 0 0|0 0 0 0 1 0 0 1|(resvd)| prio |
+---------------+---------------+---------------+---------------+
Type=46 Length=4 MP_OPT=9
Figure 18: Format of the MP_PRIO Suboption
図 18: MP_PRIO サブオプションのフォーマット
The following values are available for the Prio field:
Prio フィールドでは次の値を使用できます。
* 0: Do not use. The path is not available.
* 0：使用しません。パスが利用できません。
* 1: Standby: Do not use this path for traffic scheduling if another path (secondary or primary) is available. The path will only be used if other secondary or primary paths are not established.
* 1: スタンバイ: 別のパス (セカンダリまたはプライマリ) が使用可能な場合は、このパスをトラフィック スケジュールに使用しないでください。このパスは、他のセカンダリ パスまたはプライマリ パスが確立されていない場合にのみ使用されます。
* 2: Secondary: Do not use this path for traffic scheduling if the other paths are good enough. The path will be used occasionally for increasing the available capacity temporarily, e.g., when primary paths are congested or are not available. This is the recommended setting for paths that have costs or data caps as these paths will be used less frequently then primary paths.
* 2: セカンダリ: 他のパスで十分な場合は、このパスをトラフィック スケジュールに使用しないでください。このパスは、プライマリ パスが混雑している場合や使用できない場合など、一時的に利用可能な容量を増やすために時々使用されます。コストやデータの上限があるパスはプライマリ パスよりも使用頻度が低いため、これは推奨設定です。
* 3 - 15: Primary: The path can be used for packet scheduling decisions. The priority number indicates the relative priority of one path over the other for primary paths. Higher numbers indicate higher priority. The peer should consider sending traffic first over higher priority paths. This is the recommended setting for paths that do not have a cost or data caps associated with them as these paths will be frequently used.
* 3 ～ 15: プライマリ: パスはパケットのスケジューリングの決定に使用できます。優先順位番号は、プライマリ パスにおける一方のパスのもう一方のパスに対する相対的な優先順位を示します。数値が大きいほど優先度が高くなります。ピアは、優先度の高いパスを介して最初にトラフィックを送信することを検討する必要があります。コストやデータの上限が関連付けられていないパスは頻繁に使用されるため、これはパスに推奨される設定です。
Example use cases include:
ユースケースの例は次のとおりです。
1. Setting the Wi-Fi path to Primary and Cellular path to Secondary. In this case, Wi-Fi will be used and Cellular will be used only if the Wi-Fi path is congested or not available. Such setting results in using the Cellular path only temporally, if more capacity is needed than the Wi-Fi path can provide, indicating a clear priority of the Wi-Fi path over the Cellular due to, e.g., cost reasons.
1. Wi-Fi パスをプライマリに設定し、セルラー パスをセカンダリに設定します。この場合、Wi-Fi が使用され、Wi-Fi パスが混雑しているか利用できない場合にのみセルラーが使用されます。このような設定により、Wi-Fi パスが提供できるよりも多くの容量が必要な場合に、セルラー パスが一時的にのみ使用されることになり、コスト上の理由などにより、セルラーよりも Wi-Fi パスの明確な優先順位が示されます。
2. Setting the Wi-Fi path to Primary and Cellular path to Standby. In this case, Wi-Fi will be used and Cellular will be used only if the Wi-Fi path is not available.
2. Wi-Fi パスをプライマリに設定し、セルラー パスをスタンバイに設定します。この場合、Wi-Fi が使用され、Wi-Fi パスが利用できない場合にのみセルラーが使用されます。
3. Setting the Wi-Fi path to Primary and Cellular path to Primary. In this case, both paths can be used when making packet scheduling decisions.
3. Wi-Fi パスをプライマリに設定し、セルラー パスをプライマリに設定します。この場合、パケットのスケジューリングを決定するときに両方のパスを使用できます。
If not specified, the default behavior is to always use a path for packet scheduling decisions (MP_PRIO=3), when the path has been established and added to an existing MP-DCCP connection. At least one path ought to have an MP_PRIO value greater than or equal to one for it to be allowed to send on the connection. It is RECOMMENDED to update at least one path to a non-zero MP_PRIO value when an MP-DCCP connection enters a state where all paths remain with an MP_PRIO value of zero. This helps an MP-DCCP connection to schedule when the multipath scheduler strictly respects MP_PRIO value 0. To ensure reliable transmission, the MP_PRIO suboption MUST be acknowledged via an MP_CONFIRM (see Table 4).
指定しない場合、デフォルトの動作では、パスが確立され、既存の MP-DCCP 接続に追加されている場合、パケット スケジューリングの決定に常にそのパスが使用されます (MP_PRIO=3)。接続上での送信を許可するには、少なくとも 1 つのパスの MP_PRIO 値が 1 以上である必要があります。MP-DCCP 接続がすべてのパスの MP_PRIO 値が 0 のままの状態になった場合、少なくとも 1 つのパスを 0 以外の MP_PRIO 値に更新することが推奨されます。これは、マルチパス スケジューラが MP_PRIO 値 0 を厳密に尊重するときに MP-DCCP 接続をスケジュールするのに役立ちます。信頼性の高い送信を保証するために、MP_PRIO サブオプションは MP_CONFIRM 経由で確認応答されなければなりません (表 4 を参照)。
The relative ratio of the primary path values 3-15 depends on the path usage strategy, which is described in more detail in Section 3.11. In the case of path mobility (Section 3.11.1), only one path can be used at a time and MUST have the highest available priority value. That also includes the prio numbers 1 and 2. In the other case of concurrent path usage (Section 3.11.2), the definition is up to the multipath scheduler logic.
プライマリ パス値 3 ～ 15 の相対比率は、セクション 3.11 で詳しく説明するパス使用戦略によって異なります。パス モビリティ (セクション 3.11.1) の場合、一度に 1 つのパスのみを使用でき、利用可能な最も高い優先値を持たなければなりません。これには優先番号 1 と 2 も含まれます。同時パス使用の他のケース (セクション 3.11.2) では、定義はマルチパス スケジューラ ロジックによって決まります。
An MP_SEQ (Section 3.2.5) MUST be present in a DCCP datagram in which the MP_PRIO suboption is sent. Further details are given in Section 3.2.1.
MP_SEQ (セクション 3.2.5) は、MP_PRIO サブオプションが送信される DCCP データグラム内に存在しなければなりません (MUST)。詳細については、セクション 3.2.1 を参照してください。
The mechanism available in DCCP [RFC4340] for closing a connection cannot give an indication for closing an MP-DCCP connection, which typically contains several DCCP subflows; therefore, one cannot conclude from the closing of a subflow to the closing of an MP-DCCP connection. This is solved by introducing MP_CLOSE.
接続を閉じるために DCCP [RFC4340] で利用できるメカニズムは、通常、いくつかの DCCP サブフローを含む MP-DCCP 接続を閉じるための指示を与えることができません。したがって、サブフローの終了から MP-DCCP 接続の終了までを結論付けることはできません。これは MP_CLOSE を導入することで解決されます。
1 2 3
01234567 89012345 67890123 45678901 23456789
+--------+--------+--------+--------+--------+
|00101110| var |00001010| Key Data ...
+--------+--------+--------+--------+--------+
Type=46 Length MP_OPT=10
Figure 19: Format of the MP_CLOSE Suboption
図 19: MP_CLOSE サブオプションの形式
An MP-DCCP connection can be gracefully closed by sending an MP_CLOSE to the peer host. On all subflows, the regular termination procedure described in [RFC4340] MUST be initiated using MP_CLOSE in the initial packet (either a DCCP-CloseReq or a DCCP-Close). When a DCCP-CloseReq is used, the following DCCP-Close MUST also carry the MP_CLOSE to avoid keeping a state in the sender of the DCCP-CloseReq. At the initiator of the DCCP-CloseReq, all sockets, including the MP-DCCP connection socket, transition to CLOSEREQ state. To protect from unauthorized shutdown of a multipath connection, the selected Key Data of the peer host MUST be included in the MP_CLOSE option during the handshake procedure and MUST be validated by the peer host. Please note that the Key Data sent in DCCP-CloseReq will not be the same as the Key Data sent in DCCP-Close as these originate from different ends of the connection.
MP-DCCP 接続は、ピア ホストに MP_CLOSE を送信することで正常に閉じることができます。すべてのサブフローにおいて、[RFC4340] で説明されている通常の終了手順は、最初のパケット (DCCP-CloseReq または DCCP-Close) 内の MP_CLOSE を使用して開始されなければなりません (MUST)。DCCP-CloseReq が使用される場合、DCCP-CloseReq の送信側で状態が維持されることを避けるために、後続の DCCP-Close も MP_CLOSE を伝送しなければなりません (MUST)。DCCP-CloseReq のイニシエーターでは、MP-DCCP 接続ソケットを含むすべてのソケットが CLOSEREQ 状態に遷移します。マルチパス接続の不正なシャットダウンから保護するために、ハンドシェイク手順中にピア ホストの選択されたキー データを MP_CLOSE オプションに含める必要があり、ピア ホストによって検証されなければなりません。DCCP-CloseReq で送信されるキー データは、接続の異なる端から送信されるため、DCCP-Close で送信されるキー データと同じではないことに注意してください。
On reception of the first DCCP-CloseReq carrying an MP_CLOSE with valid Key Data, or due to a local decision, all subflows transition to the CLOSING state before transmitting a DCCP-Close carrying MP_CLOSE. The MP-DCCP connection socket on the host sending the DCCP-Close reflects the state of the initial subflow during the handshake with MP_KEY option. If the initial subflow no longer exists, the state moves immediately to CLOSED.
有効なキー データを含む MP_CLOSE を運ぶ最初の DCCP-CloseReq を受信すると、またはローカル決定により、すべてのサブフローは MP_CLOSE を運ぶ DCCP-Close を送信する前に CLOSING 状態に遷移します。DCCP-Close を送信するホスト上の MP-DCCP 接続ソケットは、MP_KEY オプションを使用したハンドシェイク中の最初のサブフローの状態を反映します。最初のサブフローが存在しない場合、状態はただちに CLOSED に移行します。
Upon reception of the first DCCP-Close carrying an MP_CLOSE with valid Key Data at the peer host, all subflows, as well as the MP-DCCP connection socket, move to the CLOSED state. After this, a DCCP-Reset with Reset Code 1 MUST be sent on any subflow in response to a received DCCP-Close containing a valid MP_CLOSE option.
有効なキー データを含む MP_CLOSE を運ぶ最初の DCCP-Close をピア ホストで受信すると、すべてのサブフローと MP-DCCP 接続ソケットが CLOSED 状態に移行します。この後、有効な MP_CLOSE オプションを含む受信した DCCP-Close に応答して、リセット コード 1 を持つ DCCP-Reset をサブフローで送信しなければなりません (MUST)。
When the MP-DCCP connection socket is in CLOSEREQ or CLOSED state, new subflow requests using MP_JOIN MUST be ignored.
MP-DCCP 接続ソケットが CLOSEREQ または CLOSED 状態にある場合、MP_JOIN を使用した新しいサブフロー要求は無視されなければなりません (MUST)。
Contrary to an MP_FAST_CLOSE (Section 3.2.3), no single-sided abrupt termination is applied.
MP_FAST_CLOSE (セクション 3.2.3) とは異なり、片側突然終了は適用されません。
This section reserves a Multipath Option to define and specify any experimental additional feature for improving and optimizing the MP-DCCP protocol. This option could be applicable to specific environments or scenarios according to potential new requirements and is meant for private use only. MP_OPT Feature Number 11 is specified with an exemplary description as below:
このセクションでは、MP-DCCP プロトコルを改善および最適化するための実験的な追加機能を定義および指定するためのマルチパス オプションを予約します。このオプションは、潜在的な新しい要件に応じて特定の環境またはシナリオに適用できる可能性があり、個人使用のみを目的としています。MP_OPT 機能番号 11 は、次のような記述例で指定されます。
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
+---------------+---------------+---------------+---------------+
|0 0 1 0 1 1 1 0| var |0 0 0 0 1 0 1 1| Data |
+---------------+---------------+---------------+---------------+
| ...
+---------------------------------------------------------------+
Type=46 Length MP_OPT=11
Figure 20: Format of the MP_EXP Suboption
図 20: MP_EXP サブオプションのフォーマット
The Data field can carry any data according to the foreseen use by the experimenters with a maximum Length of 252 bytes.
データ フィールドには、実験者による予想される使用に応じて、最大長 252 バイトの任意のデータを含めることができます。
An example MP-DCCP handshake procedure is shown in Figure 21.
MP-DCCP ハンドシェイク手順の例を図 21 に示します。
Host A Host B
------------------------ ----------
Address A1 Address A2 Address B1
---------- ---------- ----------
| | |
| DCCP-Request + Change R (MP_CAPABLE,...) |
|----- MP_KEY(CI-A + KeyA(1), KeyA(2),...) ---------->|
|<------------------- MP_KEY(CI-B + KeyB) ------------|
| DCCP-Response + Confirm L (MP_CAPABLE, ...) |
| | |
| DCCP-Ack | |
|---------------------------------------------------->|
|<----------------------------------------------------|
| DCCP-Ack | |
| | |
| |DCCP-Request + Change R(MP_CAPABLE,...)|
| |--- MP_JOIN(CI-B,RA) ----------------->|
| |<------MP_JOIN(CI-A,RB) + MP_HMAC(B)---|
| |DCCP-Response+Confirm L(MP_CAPABLE,...)|
| | |
| |DCCP-Ack |
| |-------- MP_HMAC(A) ------------------>|
| |<--------------------------------------|
| |DCCP-Ack |
Figure 21: Example MP-DCCP Handshake
図 21: MP-DCCP ハンドシェイクの例
The basic initial handshake for the first subflow is as follows:
最初のサブフローの基本的な初期ハンドシェイクは次のとおりです。
1. Host A sends a DCCP-Request with the Multipath Capable Feature change request and the MP_KEY option with a Host-specific CI-A and a KeyA for each of the supported Key Types as described in Section 3.2.4. CI-A is a unique identifier during the lifetime of an MP-DCCP connection.
1. ホスト A は、セクション 3.2.4 で説明されているように、マルチパス対応機能変更要求を含む DCCP 要求と、ホスト固有の CI-A およびサポートされている各キー タイプの KeyA を含む MP_KEY オプションを送信します。CI-A は、MP-DCCP 接続の存続期間中の一意の識別子です。
2. Host B sends a DCCP-Response with a Confirm feature for MP-Capable and the MP_Key option with a unique Host-specific CI-B and a single Host-specific KeyB. The type of the key is chosen from the list of supported types from the previous request.
2. ホスト B は、MP 対応の確認機能と、一意のホスト固有の CI-B および単一のホスト固有の KeyB を含む MP_Key オプションを備えた DCCP 応答を送信します。キーのタイプは、前のリクエストでサポートされているタイプのリストから選択されます。
3. Host A sends a DCCP-Ack to confirm the proper key exchange.
3. ホスト A は、適切なキー交換を確認するために DCCP-Ack を送信します。
4. Host B sends a DCCP-Ack to complete the handshake and set both connection ends to the OPEN state.
4. ホスト B は DCCP-Ack を送信してハンドシェイクを完了し、両方の接続端を OPEN 状態に設定します。
It should be noted that DCCP is protected against corruption of DCCP header data (Section 9 of [RFC4340]), so no additional mechanisms beyond the general confirmation are required to ensure that the header data has been properly received.
DCCP は DCCP ヘッダー データの破損から保護されている ([RFC4340] のセクション 9) ため、ヘッダー データが正しく受信されたことを確認するために一般的な確認以外の追加メカニズムは必要ないことに注意してください。
Host A waits for the final DCCP-Ack from Host B before starting any establishment of additional subflow connections.
ホスト A は、追加のサブフロー接続の確立を開始する前に、ホスト B からの最後の DCCP-Ack を待ちます。
The handshake for subsequent subflows, based on a successful initial handshake, is as follows:
成功した最初のハンドシェイクに基づく、後続のサブフローのハンドシェイクは次のとおりです。
1. Host A sends a DCCP-Request with the Multipath Capable Feature change request and the MP_JOIN option with Host B's CI-B, obtained during the initial handshake. Additionally, a random Nonce RA is transmitted with the MP_JOIN.
1. ホスト A は、マルチパス対応機能変更要求を含む DCCP 要求と、最初のハンドシェイク中に取得されたホスト B の CI-B を含む MP_JOIN オプションを送信します。さらに、ランダムな Nonce RA が MP_JOIN とともに送信されます。
2. Host B computes the HMAC of the DCCP-Request and sends a DCCP-Response with a Confirm feature option for MP-Capable and the MP_JOIN option with the CI-A and a random Nonce RB together with the computed MP_HMAC. As specified in Section 3.2.6, the HMAC is calculated by taking the leftmost 20 bytes from the SHA-256 hash of an HMAC code that is created by using the Nonce received with MP_JOIN(A) and the local Nonce RB as the Message and the derived key as the Key, as described in Section 3.2.4:
2. ホスト B は、DCCP 要求の HMAC を計算し、MP 対応の確認機能オプションと、計算された MP_HMAC とともに CI-A およびランダムな Nonce RB を含む MP_JOIN オプションを指定した DCCP 応答を送信します。セクション 3.2.6 で指定されているように、HMAC は、セクション 3.2.4 で説明されているように、MP_JOIN(A) で受信した Nonce とローカル Nonce RB をメッセージとして使用し、派生キーをキーとして使用して作成された HMAC コードの SHA-256 ハッシュから左端の 20 バイトを取得することによって計算されます。
MP_HMAC(B) = HMAC-SHA256(Key=d-keyB, Msg=RB+RA)
MP_HMAC(B) = HMAC-SHA256(Key=d-keyB、Msg=RB+RA)
3. Host A sends a DCCP-Ack with the HMAC computed for the DCCP-Response. As specified in Section 3.2.6, the HMAC is calculated by taking the leftmost 20 bytes from the SHA-256 hash of an HMAC code created by using the local Nonce RA and the Nonce received with MP_JOIN(B) as message and the derived key described in Section 3.2.4 as key:
3. ホスト A は、DCCP-Response 用に計算された HMAC を含む DCCP-Ack を送信します。セクション 3.2.6 で指定されているように、HMAC は、ローカル Nonce RA と、メッセージとして MP_JOIN(B) で受信した Nonce を使用して作成された HMAC コードの SHA-256 ハッシュから左端の 20 バイトを取得し、セクション 3.2.4 で説明されている派生キーをキーとして計算されます。
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA, Msg=RA+RB)
MP_HMAC(A) = HMAC-SHA256(Key=d-keyA、Msg=RA+RB)
4. Host B sends a DCCP-Ack to confirm the HMAC and to conclude the handshake.
4. ホスト B は DCCP-Ack を送信して HMAC を確認し、ハンドシェイクを終了します。
When a host (Host A) wants to advertise the availability of a new path, it should use the MP_ADDADDR option (Section 3.2.8) as shown in the example in Figure 22. The MP_ADDADDR option passed in the DCCP-Data contains the following parameters:
ホスト (ホスト A) が新しいパスの可用性をアドバタイズしたい場合は、図 22 の例に示すように MP_ADDADDR オプション (セクション 3.2.8) を使用する必要があります。 DCCP-Data で渡される MP_ADDADDR オプションには次のパラメーターが含まれます。
* an identifier (id 2) for the new IP address, which is used as a reference in subsequent control exchanges
* 新しい IP アドレスの識別子 (id 2)。後続の制御交換で参照として使用されます。
* a Nonce value to prevent replay attacks
* リプレイ攻撃を防ぐための Nonce 値
* the IP address of the new path (A2_IP)
* 新しいパスの IP アドレス (A2_IP)
* a pair of bytes specifying the port number associated with this IP address. The value of 00 here indicates that the port number is the same as that used for the initial subflow address A1_IP.
* この IP アドレスに関連付けられたポート番号を指定するバイトのペア。ここでの値 00 は、ポート番号が最初のサブフロー アドレス A1_IP に使用されるポート番号と同じであることを示します。
According to Section 3.2.8, the following options are required in a packet carrying MP_ADDADDR:
セクション 3.2.8 によると、MP_ADDADDR を伝送するパケットには次のオプションが必要です。
* the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections 3.3 and 3.2.6
* セクション 3.3 および 3.2.6 で説明されている初期ハンドシェイク手順中に生成された HMAC(A) の左端の 20 バイト
* the MP_SEQ option with the sequence number (seqno 12) for this message, according to Section 3.2.5
* セクション 3.2.5 に従って、このメッセージのシーケンス番号 (seqno 12) を含む MP_SEQ オプション
Host B acknowledges receipt of the MP_ADDADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in this response are as follows:
ホスト B は、MP_CONFIRM オプションを含む DCCP-Ack で MP_ADDADDR メッセージの受信を確認します。この応答で指定されるパラメータは次のとおりです。
* an MP_CONFIRM containing the MP_SEQ number (seqno 12) of the packet carrying the option that we are confirming together with the MP_ADDADDR option
* MP_ADDADDR オプションと一緒に確認しているオプションを運ぶパケットの MP_SEQ 番号 (seqno 12) を含む MP_CONFIRM
* the leftmost 20 bytes of the HMAC(B) generated during the initial handshake procedure (Section 3.3)
* 初期ハンドシェイク手順中に生成された HMAC(B) の左端の 20 バイト (セクション 3.3)
Host A Host B
------------------------ -----------
Address A1 Address A2 Address B1
---------- ---------- -----------
| | |
| DCCP-Data + MP_ADDADDR(id 2, Nonce, A2_IP, 00) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 12) -------------->|
| | |
| DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 12, MP_ADDADDR) -------------|
Figure 22: Example MP_ADDADDR Procedure
図 22: MP_ADDADDR プロシージャの例
When a host (Host A) wants to indicate that a path is no longer available, it should use the MP_REMOVEADDR option (Section 3.2.9) as shown in the example in Figure 23. The MP_REMOVEADDR option passed in the DCCP-Data contains the following parameters:
ホスト (ホスト A) がパスがもう利用できないことを示したい場合は、図 23 の例に示すように MP_REMOVEADDR オプション (セクション 3.2.9) を使用する必要があります。 DCCP-Data で渡される MP_REMOVEADDR オプションには次のパラメータが含まれます。
* an identifier (id 2) for the IP address to remove (A2_IP) and that was specified in a previous MP_ADDADDR message
* 前の MP_ADDADDR メッセージで指定された、削除する IP アドレス (A2_IP) の識別子 (id 2)
* a Nonce value to prevent replay attacks
* リプレイ攻撃を防ぐための Nonce 値
According to Section 3.2.9, the following options are required in a packet carrying MP_REMOVEADDR:
セクション 3.2.9 によると、MP_REMOVEADDR を伝送するパケットには次のオプションが必要です。
* the leftmost 20 bytes of the HMAC(A) generated during the initial handshake procedure described in Sections 3.3 and 3.2.6
* セクション 3.3 および 3.2.6 で説明されている初期ハンドシェイク手順中に生成された HMAC(A) の左端の 20 バイト
* the MP_SEQ option with the sequence number (seqno 33) for this message, according to Section 3.2.5
* セクション 3.2.5 に従って、このメッセージのシーケンス番号 (seqno 33) を含む MP_SEQ オプション
Host B acknowledges receipt of the MP_REMOVEADDR message with a DCCP-Ack containing the MP_CONFIRM option. The parameters supplied in this response are as follows:
ホスト B は、MP_CONFIRM オプションを含む DCCP-Ack で MP_REMOVEADDR メッセージの受信を確認します。この応答で指定されるパラメータは次のとおりです。
* an MP_CONFIRM containing the MP_SEQ number (seqno 33) of the packet carrying the option that we are confirming, together with the MP_REMOVEADDR option
* MP_REMOVEADDR オプションとともに、確認しているオプションを運ぶパケットの MP_SEQ 番号 (seqno 33) を含む MP_CONFIRM
* the leftmost 20 bytes of the HMAC(B) generated during the initial handshake procedure (Section 3.3)
* 初期ハンドシェイク手順中に生成された HMAC(B) の左端の 20 バイト (セクション 3.3)
Host A Host B
------------------------ -----------
Address A1 Address A2 Address B1
---------- ---------- -----------
| | |
| DCCP-Data + MP_REMOVEADDR(id 2, Nonce) + |
|------- MP_HMAC(A) + MP_SEQ(seqno 33) -------------->|
| | |
| DCCP-Ack + MP_HMAC(B) + |
|<----- MP_CONFIRM(seqno 33, MP_REMOVEADDR) ----------|
Figure 23: Example MP_REMOVEADDR Procedure
図 23: MP_REMOVEADDR プロシージャの例
When a host wants to close an existing subflow but not the whole MP-DCCP connection, it MUST initiate the regular DCCP connection termination procedure as described in Section 5.6 of [RFC4340], i.e., it sends a DCCP-Close/DCCP-Reset on the subflow. This may be preceded by a DCCP-CloseReq. In the event of an irregular termination of a subflow, e.g., during subflow establishment, it MUST use an appropriate DCCP-Reset Code as specified by IANA [DCCP-PARAMETERS] for DCCP operations. This could be, for example, sending Reset Code 5 (Option Error) when an MP-DCCP option provides invalid data or Reset Code 9 (Too Busy) when the maximum number of maintainable paths is reached. Note that receiving a Reset Code 9 for secondary subflows MUST NOT impact already existing active subflows. If necessary, these subflows are terminated in a subsequent step using the procedures described in this section.
ホストが、MP-DCCP 接続全体ではなく、既存のサブフローを閉じたい場合、[RFC4340] のセクション 5.6 で説明されているように、通常の DCCP 接続終了手順を開始しなければなりません (MUST)。つまり、サブフロー上で DCCP-Close/DCCP-Reset を送信します。この前に DCCP-CloseReq が続く場合があります。サブフローが不規則に終了した場合、たとえばサブフローの確立中、DCCP 動作に対して IANA [DCCP-PARAMETERS] で指定されている適切な DCCP リセット コードを使用しなければなりません (MUST)。これは、たとえば、MP-DCCP オプションが無効なデータを提供する場合にリセット コード 5 (オプション エラー) を送信したり、維持可能なパスの最大数に達した場合にリセット コード 9 (ビジーすぎる) を送信したりすることが考えられます。セカンダリ サブフローのリセット コード 9 を受信しても、既存のアクティブなサブフローに影響を与えてはいけないことに注意してください。必要に応じて、これらのサブフローは、このセクションで説明する手順を使用して後続のステップで終了します。
A host terminates an MP-DCCP connection using the DCCP connection termination specified in Section 5.5 of [RFC4340] on each subflow with the first packet on each subflow carrying MP_CLOSE (see Section 3.2.11).
ホストは、MP_CLOSE を運ぶ各サブフローの最初のパケットで、[RFC4340] のセクション 5.5 で指定されている DCCP 接続終了を使用して MP-DCCP 接続を終了します (セクション 3.2.11 を参照)。
Host A Host B
------ ------
<- Optional DCCP-CloseReq +
MP_CLOSE [A's key]
[on all subflows]
DCCP-Close + MP_CLOSE ->
[B's key] [on all subflows]
<- DCCP-Reset
[on all subflows]
Additionally, an MP-DCCP connection may be closed abruptly using the "fast close" procedure described in Section 3.2.3, where a DCCP-Reset is sent on all subflows, each carrying the MP_FAST_CLOSE option.
さらに、MP-DCCP 接続は、セクション 3.2.3 で説明されている「高速クローズ」手順を使用して突然閉じることができます。この手順では、MP_FAST_CLOSE オプションを含むすべてのサブフローで DCCP-Reset が送信されます。
Host A Host B
------ ------
DCCP-Reset + MP_FAST_CLOSE ->
[B's key] [on all subflows]
<- DCCP-Reset
[on all subflows]
When a subflow fails to operate following the intended behavior of the MP-DCCP, it is necessary to proceed with a fallback. This may be either falling back to regular DCCP [RFC4340] or removing a problematic subflow. The main reasons for a subflow failing include: no MP support at the peer host, failure to negotiate the protocol version, loss of Multipath Options, faulty/non-supported MP-DCCP options, or modification of payload data.
サブフローが MP-DCCP の意図された動作に従って動作しない場合は、フォールバックを続行する必要があります。これは、通常の DCCP [RFC4340] にフォールバックするか、問題のあるサブフローを削除するかのいずれかである可能性があります。サブフローが失敗する主な理由には、ピア ホストでの MP サポートがない、プロトコル バージョンのネゴシエーションの失敗、マルチパス オプションの喪失、障害のある/サポートされていない MP-DCCP オプション、またはペイロード データの変更が含まれます。
At the start of an MP-DCCP connection, the handshake ensures the exchange of the MP-DCCP feature and options and thus ensures that the path is fully MP-DCCP capable. If during the handshake procedure it appears that DCCP-Request or DCCP-Response messages do not carry the Multipath Capable Feature, the MP-DCCP connection will not be established and the handshake SHOULD fall back to regular DCCP. If this is not possible, the connection MUST be closed.
MP-DCCP 接続の開始時に、ハンドシェイクによって MP-DCCP 機能とオプションが確実に交換されるため、パスが完全に MP-DCCP 対応であることが保証されます。ハンドシェイク手順中に、DCCP-Request または DCCP-Response メッセージがマルチパス対応機能を伝送していないように見える場合、MP-DCCP 接続は確立されず、ハンドシェイクは通常の DCCP にフォールバックする必要があります (SHOULD)。それが不可能な場合は、接続を閉じなければなりません。
If the endpoints fail to agree on the protocol version to use during the Multipath Capable Feature negotiation, the connection MUST either be closed or fall back to regular DCCP. This is described in Section 3.1. The protocol version negotiation distinguishes between negotiation for the initial connection establishment and the addition of subsequent subflows. If protocol version negotiation is not successful during the initial connection establishment, the MP-DCCP connection will fall back to regular DCCP.
マルチパス対応機能のネゴシエーション中にエンドポイントが使用するプロトコルのバージョンに同意できない場合、接続を閉じるか、通常の DCCP にフォールバックする必要があります。これについてはセクション 3.1 で説明します。プロトコル バージョンのネゴシエーションは、最初の接続確立のネゴシエーションと後続のサブフローの追加を区別します。最初の接続確立中にプロトコル バージョンのネゴシエーションが成功しなかった場合、MP-DCCP 接続は通常の DCCP に戻ります。
The fallback procedure for regular DCCP MUST also be applied if the MP_KEY (Section 3.2.4) Key Type cannot be negotiated.
通常の DCCP のフォールバック手順は、MP_KEY (セクション 3.2.4) キー タイプをネゴシエートできない場合にも適用しなければなりません (MUST)。
If a subflow attempts to join an existing MP-DCCP connection but MP-DCCP options or the Multipath Capable Feature are not present or are faulty in the handshake procedure, that subflow MUST be closed. This is the case especially if a different MP_CAPABLE version than the originally negotiated version is used. Reception of a non-verifiable MP_HMAC (Section 3.2.6) or an invalid CI used in MP_JOIN (Section 3.2.2) during flow establishment MUST cause the subflow to be closed.
サブフローが既存の MP-DCCP 接続に参加しようとしたが、MP-DCCP オプションまたはマルチパス対応機能が存在しないか、ハンドシェイク手順に欠陥がある場合、そのサブフローは閉じられなければなりません(MUST)。これは、最初にネゴシエートされたバージョンとは異なる MP_CAPABLE バージョンが使用されている場合に特に当てはまります。フロー確立中に検証不可能な MP_HMAC (セクション 3.2.6) または MP_JOIN (セクション 3.2.2) で使用された無効な CI を受信すると、サブフローが閉じられなければなりません (MUST)。
The subflow closing procedure MUST also be applied if a final ACK carrying MP_KEY with the wrong KeyA/KeyB is received or the MP_KEY option is malformed.
サブフロー終了手順は、間違った KeyA/KeyB を持つ MP_KEY を運ぶ最終 ACK を受信した場合、または MP_KEY オプションの形式が不正な場合にも適用されなければなりません。
Another relevant case is when payload data is modified by middleboxes. DCCP uses a checksum to protect the data, as described in Section 9 of [RFC4340]. A checksum will fail if the data has been changed in any way. All data from the start of the segment that failed the checksum onwards cannot be considered trustworthy. As defined by DCCP, if the checksum fails, the receiving endpoint MUST drop the application data and report that data as dropped due to corruption using a Data Dropped option (Drop Code 3, Corrupt). If data is dropped due to corruption for an MP-DCCP connection, the affected subflow MAY be closed. The same procedure applies if the Multipath Option is unknown.
もう 1 つの関連するケースは、ペイロード データがミドルボックスによって変更される場合です。[RFC4340] のセクション 9 で説明されているように、DCCP はチェックサムを使用してデータを保護します。データが何らかの方法で変更されている場合、チェックサムは失敗します。チェックサムに失敗したセグメントの先頭から、それ以降のすべてのデータは信頼できるとは見なされません。DCCP で定義されているように、チェックサムが失敗した場合、受信側エンドポイントはアプリケーション データをドロップし、データ ドロップ オプション (ドロップ コード 3、破損) を使用して、そのデータが破損によりドロップされたものとして報告しなければなりません (MUST)。MP-DCCP 接続の破損によりデータがドロップされた場合、影響を受けるサブフローを閉じてもよい(MAY)。マルチパス オプションが不明な場合も、同じ手順が適用されます。
The MP-DCCP per subflow state transitions follow the state transitions defined for DCCP in [RFC4340] to a large extent, with some modifications due to the MP-DCCP 4-way handshake and fast close procedures. The state diagram below shows the most common state transitions. The diagram is illustrative. For example, there are arcs (not shown) from several additional states to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset.
サブフローごとの MP-DCCP 状態遷移は、[RFC4340] で DCCP に定義された状態遷移に大部分準拠していますが、MP-DCCP 4 ウェイ ハンドシェイクおよび高速クローズ手順によるいくつかの変更が加えられています。以下の状態図は、最も一般的な状態遷移を示しています。図は説明的なものです。たとえば、有効な DCCP-Reset の受信を条件として、いくつかの追加状態から TIMEWAIT までのアーク (図示せず) があります。
When the state moves from CLOSED to OPEN during the 4-way handshake, the transitioned states remain the same as for DCCP, but it is no longer possible to transmit application data while in the REQUEST state. The fast close procedure can be triggered by either the client or the server and results in the transmission of a Reset packet. The fast close procedure moves the state of the Client and Server directly to TIMEWAIT and CLOSED, respectively.
4 ウェイ ハンドシェイク中に状態が CLOSED から OPEN に移行すると、移行後の状態は DCCP の場合と同じですが、REQUEST 状態の間はアプリケーション データを送信できなくなります。高速クローズ手順はクライアントまたはサーバーによってトリガーでき、その結果、リセット パケットが送信されます。高速クローズ手順は、クライアントとサーバーの状態をそれぞれ TIMEWAIT と CLOSED に直接移行します。
+----------------------------+ +------------------------------+
| v v |
| +----------+ |
| +-------------+ CLOSED +-------------+ |
| | passive +----------+ active | |
| | open open | |
| | snd Request | |
| v v |
| +-----------+ +----------+ |
| | LISTEN | | REQUEST | |
| +-----+-----+ +----+-----+ |
| | rcv Request rcv Response | |
| | snd Response snd Ack | |
| v v |
| +-----------+ +----------+ |
| | RESPOND | | PARTOPEN | |
| +-----+-----+ +----+-----+ |
| | rcv Ack rcv Ack/DataAck | |
| | snd Ack | |
| | +-----------+ | |
| +------------>| OPEN |<-----------+ |
| +--+-+-+-+--+ |
| server active close | | | | active close |
| snd CloseReq | | | | or rcv CloseReq |
| | | | | snd Close |
| | | | | |
| +-----------+ | | | | +----------+ |
| | CLOSEREQ |<---------+ | | +----------->| CLOSING | |
| +-----+-----+ | | +----+-----+ |
| | rcv Close | | rcv Reset | |
| | snd Reset | | | |
| | | | active FastClose | |
|<----------+ rcv Close | | or rcv FastClose v |
| or server active FastClose | | snd Reset +----+-----+ |
| or server rcv FastClose | +------------->| TIMEWAIT | |
| snd Reset | +----+-----+ |
+------------------------------+ | |
+-----------+
2MSL timer expires
Figure 24: Most Common State Transitions of an MP-DCCP Subflow
図 24: MP-DCCP サブフローの最も一般的な状態遷移
Senders MUST manage per-path congestion status and avoid sending more data on a given path than congestion control allows for each path.
送信者はパスごとの輻輳ステータスを管理し、各パスで輻輳制御が許可する量を超えるデータを特定のパスに送信することを避けなければなりません。
A DCCP implementation maintains the maximum packet size (MPS) during operation of a DCCP session. This procedure is specified for single-path DCCP in Section 14 of [RFC4340]. Without any restrictions, this is adopted for MP-DCCP operations, in particular the Path MTU (PMTU) measurement and the Sender Behavior. The DCCP application interface SHOULD allow the application to discover the current MPS. This reflects the current largest size supported for the data stream that can be used across the set of all active MP-DCCP subflows.
DCCP 実装では、DCCP セッションの動作中に最大パケット サイズ (MPS) が維持されます。この手順は、[RFC4340] のセクション 14 で単一パス DCCP に対して指定されています。これは何の制限もなく、MP-DCCP 操作、特にパス MTU (PMTU) 測定と送信者の動作に採用されます。DCCP アプリケーション インターフェイスは、アプリケーションが現在の MPS を検出できるようにする必要があります (SHOULD)。これは、すべてのアクティブな MP-DCCP サブフローのセット全体で使用できるデータ ストリームでサポートされている現在の最大サイズを反映しています。
MP-DCCP does not support any explicit procedure to negotiate the maximum number of subflows between endpoints. However, in practical scenarios, there will be resource limitations on the host or use cases that do not benefit from additional subflows.
MP-DCCP は、エンドポイント間のサブフローの最大数をネゴシエートするための明示的な手順をサポートしていません。ただし、実際のシナリオでは、ホスト上のリソース制限や、追加のサブフローのメリットが得られないユースケースが存在します。
It is RECOMMENDED to limit the number of subflows in implementations and to reject incoming subflow requests with a DCCP-Reset using the Reset Code "too busy" according to [RFC4340] if the resource limit is exceeded or it is known that the multipath connection will not benefit from further subflows. Likewise, it is RECOMMENDED that the host that wants to create the subflows considers the available resources and possible gains.
実装におけるサブフローの数を制限し、リソース制限を超えた場合、またはマルチパス接続がそれ以上のサブフローから恩恵を受けないことがわかっている場合、[RFC4340]に従ってリセット コード「toobusy」を使用して DCCP-Reset で受信サブフロー要求を拒否することが推奨されます。同様に、サブフローを作成したいホストは、利用可能なリソースと考えられる利益を考慮することが推奨されます。
To avoid further inefficiencies with subflows due to short-lived connections, it MAY be useful to delay the start of additional subflows. The decision on the initial number of subflows can be based on the occupancy of the socket buffer and/or the timing.
接続の有効期間が短いためにサブフローがさらに非効率になるのを避けるために、追加のサブフローの開始を遅らせると役立つ場合があります。サブフローの初期数は、ソケット バッファの占有量やタイミングに基づいて決定できます。
While in the socket-buffer-based approach the number of initial subflows can be derived by opening new subflows until their initial windows cover the amount of buffered application data, the timing-based approach delays the start of additional subflows based on a certain time period, load, or knowledge of traffic and path properties. The delay-based approach also provides resilience for low-bandwidth but long-lived applications. All this could also be supported by advanced APIs that signal application traffic requests to the MP-DCCP.
ソケット バッファ ベースのアプローチでは、最初のウィンドウがバッファされたアプリケーション データの量をカバーするまで新しいサブフローを開くことによって初期サブフローの数を導き出すことができますが、タイミング ベースのアプローチでは、特定の期間、負荷、またはトラフィックとパスのプロパティの知識に基づいて追加のサブフローの開始を遅らせます。遅延ベースのアプローチは、低帯域幅だが寿命の長いアプリケーションにも回復力を提供します。これらすべては、アプリケーション トラフィック要求を MP-DCCP に通知する高度な API によってもサポートされる可能性があります。
MP-DCCP can be configured to realize one of several strategies for path usage via selecting one DCCP subflow out of the multiple DCCP subflows within an MP-DCCP connection for data transmission. This can be a dynamic process further facilitated by the means of DCCP and MP-DCCP-defined options such as path preference using MP-PRIO; adding or removing DCCP subflows using MP_REMOVEADDR, MP_ADDADDR, or DCCP-Close/DCCP-Reset; and path metrics such as packet loss rate, congestion window (CWND), or RTT provided by the congestion control algorithm. Selecting an appropriate method can allow MP-DCCP to realize different path utilization strategies that make MP-DCCP suitable for end-to-end implementation over the Internet or in controlled environments such as Hybrid Access or 5G ATSSS.
MP-DCCP は、データ送信用の MP-DCCP 接続内の複数の DCCP サブフローから 1 つの DCCP サブフローを選択することにより、パス使用に関するいくつかの戦略の 1 つを実現するように構成できます。これは、MP-PRIO を使用したパス優先などの DCCP および MP-DCCP で定義されたオプションによってさらに促進される動的なプロセスにすることができます。MP_REMOVEADDR、MP_ADDADDR、または DCCP-Close/DCCP-Reset を使用して DCCP サブフローを追加または削除します。および輻輳制御アルゴリズムによって提供されるパケット損失率、輻輳ウィンドウ (CWND)、または RTT などのパス メトリック。適切な方法を選択すると、MP-DCCP はさまざまなパス利用戦略を実現できるようになり、MP-DCCP がインターネット経由、またはハイブリッド アクセスや 5G ATSSS などの制御された環境でのエンドツーエンド実装に適したものになります。
The path mobility strategy provides the use of a single path with a seamless handover function to continue the connection when the currently used path is deemed unsuitable for service delivery. Some of the DCCP subflows of an MP-DCCP connection might become inactive due to either the occurrence of certain error conditions (e.g., DCCP timeout, packet loss threshold, RTT threshold, and closed/removed) or adjustments from the MP-DCCP user. When there is outbound data to send and the primary path becomes inactive (e.g., due to failures) or deprioritized, the MP-DCCP endpoint SHOULD try to send the data through an alternate path with a different source or destination address (depending on the point of failure), if one exists. This process SHOULD respect the path priority configured by the MP_PRIO suboption; otherwise, if the path priority is not available, pick the most divergent source-destination pair from the originally used source-destination pair.
パス モビリティ戦略は、現在使用されているパスがサービス提供に適していないと判断された場合に、接続を継続するためのシームレスなハンドオーバー機能を備えた単一パスの使用を提供します。MP-DCCP 接続の DCCP サブフローの一部は、特定のエラー状態 (DCCP タイムアウト、パケット損失しきい値、RTT しきい値、クローズ/削除など) の発生または MP-DCCP ユーザーによる調整により非アクティブになる場合があります。送信するアウトバウンドデータがあり、プライマリパスが非アクティブになった場合（障害などにより）、または優先順位が低くなった場合、MP-DCCP エンドポイントは、（障害点に応じて）異なる送信元アドレスまたは宛先アドレスが存在する場合、そのアドレスを持つ代替パスを介してデータの送信を試みるべきです（SHOULD）。このプロセスは、MP_PRIO サブオプションによって設定されたパスの優先順位を尊重する必要があります (SHOULD)。それ以外の場合、パスの優先順位が使用できない場合は、最初に使用されていた送信元と宛先のペアから最も発散する送信元と宛先のペアを選択します。
Note: Rules for picking the most appropriate source-destination pair are an implementation decision and are not specified within this document. Path mobility is supported in the current Linux reference implementation [MP-DCCP.Site].
注: 最も適切な送信元と宛先のペアを選択するためのルールは実装上の決定であり、このドキュメントでは指定されていません。パス モビリティは、現在の Linux リファレンス実装 [MP-DCCP.Site] でサポートされています。
Different from a path mobility strategy, the selection between MP-DCCP subflows is a per-packet decision that is a part of the multipath scheduling process. This method would allow multiple subflows to be simultaneously used to aggregate the path resources to obtain higher connection throughput.
パス モビリティ戦略とは異なり、MP-DCCP サブフロー間の選択は、マルチパス スケジューリング プロセスの一部であるパケットごとの決定です。この方法では、複数のサブフローを同時に使用してパス リソースを集約し、より高い接続スループットを得ることができます。
In this scenario, the selection of congestion control, per-packet scheduling, and a potential reordering method determines a concurrent path utilization strategy and result in a particular transport characteristic. A concurrent path usage method uses a scheduling design that could seek to maximize reliability, maximize throughput, minimize latency, etc.
このシナリオでは、輻輳制御、パケットごとのスケジューリング、および潜在的な並べ替え方法の選択により、同時パス利用戦略が決定され、特定のトランスポート特性が得られます。同時パス使用法では、信頼性の最大化、スループットの最大化、遅延の最小化などを追求できるスケジューリング設計が使用されます。
Concurrent path usage over the Internet can have implications. When an MP-DCCP connection uses two or more paths, there is no guarantee that these paths are fully disjoint. When two (or more) subflows share the same bottleneck, using a standard congestion control algorithm could result in an unfair distribution of the capacity with the multipath connection using more capacity than competing single-path connections.
インターネット上でのパスの同時使用は影響を与える可能性があります。MP-DCCP 接続で 2 つ以上のパスが使用される場合、これらのパスが完全に切り離されているという保証はありません。2 つ (またはそれ以上) のサブフローが同じボトルネックを共有している場合、標準の輻輳制御アルゴリズムを使用すると、競合するシングルパス接続よりも多くの容量を使用するマルチパス接続により、容量が不公平に配分される可能性があります。
Multipath TCP uses the coupled congestion control Linked Increases Algorithm (LIA) specified in an experimental specification [RFC6356] to solve this problem. This scheme could also be specified for MP-DCCP. The same applies to other coupled congestion control algorithms that have been proposed for Multipath TCP such as the Opportunistic Linked Increases Algorithm [OLIA].
マルチパス TCP は、実験仕様 [RFC6356] で指定されている結合輻輳制御 Linked Increase Algorithm (LIA) を使用して、この問題を解決します。この方式は MP-DCCP にも指定できます。同じことが、Opportunistic Linked Increase Algorithm [OLIA] など、マルチパス TCP 用に提案されている他の結合された輻輳制御アルゴリズムにも当てはまります。
The specification of scheduling for concurrent multipath and related congestion control algorithms and reordering methods for use in the general Internet are outside the scope of this document. If, and when, the IETF specifies a method for concurrent usage of multiple paths for the general Internet, the framework specified in this document could be used to provide an IETF-recommended method for MP-DCCP.
同時マルチパスのスケジューリングの仕様と、一般的なインターネットで使用される関連する輻輳制御アルゴリズムおよび並べ替え方法は、この文書の範囲外です。IETF が一般的なインターネットの複数パスの同時使用方法を指定する場合、この文書で指定されているフレームワークを使用して、IETF が推奨する MP-DCCP 方法を提供できます。
Similar to DCCP, MP-DCCP does not provide cryptographic security guarantees inherently. Thus, if applications need cryptographic security (integrity, authentication, confidentiality, access control, and anti-replay protection), the use of IPsec, DTLS over DCCP [RFC5238], or other end-to-end security is recommended; the Secure Real-time Transport Protocol (SRTP) [RFC3711] is one candidate protocol for authentication. Integrity would be provided if using SRTP together with the encryption of header extensions described in [RFC6904].
DCCP と同様に、MP-DCCP は本質的に暗号化セキュリティの保証を提供しません。したがって、アプリケーションに暗号化セキュリティ (完全性、認証、機密性、アクセス制御、およびリプレイ防止保護) が必要な場合は、IPsec、DTLS over DCCP [RFC5238]、またはその他のエンドツーエンド セキュリティの使用が推奨されます。Secure Real-time Transport Protocol (SRTP) [RFC3711] は、認証プロトコルの候補の 1 つです。[RFC6904] で説明されているヘッダー拡張の暗号化と SRTP を併用すると、完全性が提供されます。
DCCP [RFC4340] provides protection against hijacking and limits the potential impact of some denial-of-service attacks, but DCCP provides no inherent protection against an on-path attacker snooping on data packets. Regarding the security of MP-DCCP compared to regular DCCP, no additional risks should be introduced. The security objectives for MP-DCCP are:
DCCP [RFC4340] はハイジャックに対する保護を提供し、一部のサービス拒否攻撃の潜在的な影響を制限しますが、DCCP はデータ パケットをスヌーピングするパス上の攻撃者に対する固有の保護を提供しません。通常の DCCP と比較した MP-DCCP のセキュリティに関しては、追加のリスクが導入されるべきではありません。MP-DCCP のセキュリティ目標は次のとおりです。
* Provide assurance that the parties involved in an MP-DCCP handshake procedure are identical to those in the original DCCP connection.
* MP-DCCP ハンドシェイク手順に関与する当事者が元の DCCP 接続の当事者と同一であることを保証します。
* Before a path is used, verify that the new advertised path is valid for receiving traffic.
* パスを使用する前に、新しいアドバタイズされたパスがトラフィックの受信に有効であることを確認してください。
* Provide replay protection, i.e., ensure that a request to add/ remove a subflow is 'fresh'.
* リプレイ保護を提供します。つまり、サブフローの追加/削除リクエストが「新鮮」であることを保証します。
* Allow a party to limit the number of subflows that it allows.
* 当事者が許可するサブフローの数を制限できるようにします。
To achieve these goals, MP-DCCP includes a hash-based handshake algorithm documented in Sections 3.2.4, 3.2.6, and 3.3. The security of the MP-DCCP connection depends on the use of keys that are shared once at the start of the first subflow and are never sent again over the network. Depending on the security requirements, different Key Types can be negotiated in the handshake procedure or must follow the fallback scenario described in Section 3.6. If there are security requirements that go beyond the capabilities of Key Type 0, then it is RECOMMENDED that Key Type 0 not be enabled to avoid downgrade attacks that result in the key being exchanged as plain text. To ease demultiplexing while not revealing cryptographic material, subsequent subflows use the initially exchanged CI information. The keys exchanged once at the beginning are concatenated and used as keys for creating HMACs used on subflow setup, in order to verify that the parties in the handshake of subsequent subflows are the same as in the original connection setup. This also provides verification that the peer can receive traffic at this new address. Replay attacks would still be possible when only keys are used; therefore, the handshakes use single-use random numbers (Nonces) for both parties -- this ensures that the HMAC will never be the same on two handshakes. Guidance on generating random numbers suitable for use as keys is given in [RFC4086]. During normal operation, regular DCCP protection mechanisms (such as the header checksum to protect DCCP headers against corruption) is designed to provide the same level of protection against attacks on individual DCCP subflows as exists for regular DCCP.
これらの目標を達成するために、MP-DCCP には、セクション 3.2.4、3.2.6、および 3.3 で説明されているハッシュベースのハンドシェイク アルゴリズムが含まれています。MP-DCCP 接続のセキュリティは、最初のサブフローの開始時に一度共有され、ネットワーク経由で再度送信されることのないキーの使用に依存します。セキュリティ要件に応じて、ハンドシェイク手順でさまざまなキー タイプをネゴシエートするか、セクション 3.6 で説明するフォールバック シナリオに従う必要があります。キー タイプ 0 の機能を超えるセキュリティ要件がある場合は、キーがプレーン テキストとして交換されるダウングレード攻撃を避けるために、キー タイプ 0 を有効にしないことが推奨されます。暗号マテリアルを公開せずに逆多重化を容易にするために、後続のサブフローでは最初に交換された CI 情報が使用されます。最初に一度交換されたキーは連結され、サブフローのセットアップで使用される HMAC を作成するためのキーとして使用され、後続のサブフローのハンドシェイクの当事者が元の接続セットアップと同じであることを確認します。これにより、ピアがこの新しいアドレスでトラフィックを受信できるかどうかの検証も行われます。キーのみが使用されている場合でも、リプレイ攻撃は可能です。したがって、ハンドシェイクでは両方のパーティで使い捨ての乱数 (Nonce) が使用されます。これにより、2 回のハンドシェイクで HMAC が同じになることはありません。キーとしての使用に適した乱数の生成に関するガイダンスは [RFC4086] に記載されています。通常の動作中、通常の DCCP 保護メカニズム (DCCP ヘッダーを破損から保護するためのヘッダー チェックサムなど) は、個々の DCCP サブフローに対する攻撃に対して、通常の DCCP と同じレベルの保護を提供するように設計されています。
As discussed in Section 3.2.8, a host may advertise its private addresses, but these might point to different hosts in the receiver's network. The MP_JOIN handshake (Section 3.2.2) is designed to ensure that this does not set up a subflow to the incorrect host. However, it could still create unwanted DCCP handshake traffic. This feature of MP-DCCP could be a target for denial-of-service exploits, with malicious participants in MP-DCCP connections encouraging the recipient to target other hosts in the network. Therefore, implementations should consider heuristics at both the sender and receiver to reduce the impact of this.
セクション 3.2.8 で説明したように、ホストはプライベート アドレスをアドバタイズする可能性がありますが、これらは受信側のネットワーク内の別のホストを指す可能性があります。MP_JOIN ハンドシェイク (セクション 3.2.2) は、これによって間違ったホストへのサブフローがセットアップされないように設計されています。ただし、不要な DCCP ハンドシェイク トラフィックが発生する可能性があります。MP-DCCP のこの機能は、MP-DCCP 接続への悪意のある参加者が受信者にネットワーク内の他のホストを標的にするよう促し、サービス拒否攻撃の標的になる可能性があります。したがって、実装では、送信側と受信側の両方でヒューリスティックを考慮して、この影響を軽減する必要があります。
As described in Section 3.9, an MPS is maintained for an MP-DCCP connection. If MP-DCCP exposes a minimum MPS across all paths, any change to one path impacts the sender for all paths. To mitigate attacks that seek to force a low MPS, MP-DCCP could detect an attempt to reduce the MPS to less than a minimum MPS and then stop using these paths.
セクション 3.9 で説明されているように、MPS は MP-DCCP 接続に対して維持されます。MP-DCCP がすべてのパスにわたって最小 MPS を公開する場合、1 つのパスへの変更はすべてのパスの送信者に影響します。強制的に低い MPS を設定しようとする攻撃を軽減するために、MP-DCCP は MPS を最小 MPS 未満に低下させようとする試みを検出し、これらのパスの使用を停止する可能性があります。
Issues from interaction with on-path middleboxes such as NATs, firewalls, proxies, IDSs, and others have to be considered for all extensions to standard protocols; otherwise, unexpected reactions of middleboxes may hinder its deployment. DCCP already provides means to mitigate the potential impact of middleboxes, in comparison to TCP (see Section 16 of [RFC4340]). When both hosts are located behind a NAT or firewall entity, specific measures have to be applied such as the simultaneous-open technique specified in [RFC5596] that updates the asymmetric connection-establishment procedures for DCCP. Further standardized technologies addressing middleboxes operating as NATs are provided in [RFC5597].
NAT、ファイアウォール、プロキシ、IDS などのパス上のミドルボックスとの相互作用による問題は、標準プロトコルのすべての拡張について考慮する必要があります。そうしないと、ミドルボックスの予期しない反応により、その展開が妨げられる可能性があります。DCCP は、TCP と比較して、ミドルボックスの潜在的な影響を軽減する手段をすでに提供しています ([RFC4340] のセクション 16 を参照)。両方のホストが NAT またはファイアウォール エンティティの背後にある場合、DCCP の非対称接続確立手順を更新する [RFC5596] で指定されている同時オープン技術など、特定の対策を適用する必要があります。NAT として動作するミドルボックスに対応するさらに標準化された技術は [RFC5597] で提供されています。
[RFC6773] specifies UDP encapsulation for NAT traversal of DCCP sessions, similar to other UDP encapsulations such as the Stream Control Transmission Protocol (SCTP) [RFC6951]. Future specifications by the IETF could specify other methods for DCCP encapsulation.
[RFC6773] は、ストリーム制御送信プロトコル (SCTP) [RFC6951] などの他の UDP カプセル化と同様に、DCCP セッションの NAT トラバーサル用の UDP カプセル化を指定します。IETF による将来の仕様では、DCCP カプセル化の他の方法が指定される可能性があります。
The security impact of MP-DCCP-aware middleboxes is discussed in Section 4.
MP-DCCP 対応ミドルボックスのセキュリティへの影響については、セクション 4 で説明します。
The approach described above has been implemented in open source across different testbeds, and a new scheduling algorithm has been extensively tested. Also, demonstrations of a laboratory setup have been executed and published; see [MP-DCCP.Site].
上で説明したアプローチは、さまざまなテストベッドにわたってオープンソースで実装されており、新しいスケジューリング アルゴリズムが広範囲にテストされています。また、実験室セットアップのデモンストレーションも実行され、公開されています。[MP-DCCP.サイト]を参照してください。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the registration of values related to the MP extension of the DCCP protocol in accordance with the RFC Required policy in Section 4.7 of [RFC8126]. This document defines one new value that has been allocated in the IANA "DCCP Feature Numbers" registry and creates three new registries that have been added in the "Datagram Congestion Control Protocol (DCCP) Parameters" registry group.
このセクションは、[RFC8126] のセクション 4.7 の RFC Required ポリシーに従って、DCCP プロトコルの MP 拡張に関連する値の登録に関する、Internet Assigned Numbers Authority (IANA) へのガイダンスを提供します。この文書では、IANA「DCCP 機能番号」レジストリに割り当てられた 1 つの新しい値を定義し、「データグラム輻輳制御プロトコル (DCCP) パラメータ」レジストリ グループに追加された 3 つの新しいレジストリを作成します。
Per this document, IANA has assigned a new DCCP feature parameter for negotiating the support of multipath capability for DCCP sessions between hosts as described in Section 3. The following entry in Table 6 has been added to the "Feature Numbers" registry in the DCCP registry group according to Section 19.4 of [RFC4340].
この文書に従って、IANA は、セクション 3 で説明されているように、ホスト間の DCCP セッションのマルチパス機能のサポートをネゴシエートするための新しい DCCP 機能パラメータを割り当てました。表 6 の次のエントリが、[RFC4340] のセクション 19.4 に従って、DCCP レジストリ グループの「機能番号」レジストリに追加されました。
+========+=====================+===========+
| Number | Description/Meaning | Reference |
+========+=====================+===========+
| 10 | Multipath Capable | RFC 9897 |
+--------+---------------------+-----------+
Table 6: Addition to DCCP Feature Numbers Registry
表 6: DCCP フィーチャー番号レジストリへの追加
Section 3.1 specifies the new 1-byte entry above that includes a 4-bit part to specify the version of the used MP-DCCP implementation. IANA has created a new "MP-DCCP Versions" registry in the DCCP registry group to track the MP-DCCP version. The initial content of this registry is as follows:
セクション 3.1 では、使用される MP-DCCP 実装のバージョンを指定するための 4 ビット部分を含む、上記の新しい 1 バイトのエントリを指定します。IANA は、MP-DCCP バージョンを追跡するために、DCCP レジストリ グループに新しい「MP-DCCP Versions」レジストリを作成しました。このレジストリの初期内容は次のとおりです。
+=========+============+===========+
| Version | Value | Reference |
+=========+============+===========+
| 0 | 0000 | RFC 9897 |
+---------+------------+-----------+
| 1-15 | Unassigned | |
+---------+------------+-----------+
Table 7: MP-DCCP Versions Registry
表 7: MP-DCCP バージョンのレジストリ
Future MP-DCCP versions 1 to 15 will be assigned from this registry using the RFC Required policy (Section 4.7 of [RFC8126]).
将来の MP-DCCP バージョン 1 ～ 15 は、RFC Required ポリシー ([RFC8126] のセクション 4.7) を使用してこのレジストリから割り当てられます。
IANA has assigned value 46 in the DCCP "Option Types" registry, as described in Section 3.2.
IANA は、セクション 3.2 で説明されているように、DCCP「オプション タイプ」レジストリに値 46 を割り当てました。
IANA has created a new "Multipath Options" registry within the DCCP registry group. The following entries in Table 8 have been added to the new "Multipath Options" registry. The registry has an upper boundary of 255 in the numeric value field.
IANA は、DCCP レジストリ グループ内に新しい「マルチパス オプション」レジストリを作成しました。表 8 の次のエントリが、新しい「マルチパス オプション」レジストリに追加されました。レジストリの数値フィールドの上限は 255 です。
+===============+===============+=====================+===========+
| Multipath | Name | Description | Reference |
| Option | | | |
+===============+===============+=====================+===========+
| MP_OPT=0 | MP_CONFIRM | Confirm reception/ | Section |
| | | processing of an | 3.2.1 |
| | | MP_OPT option | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=1 | MP_JOIN | Join subflow to an | Section |
| | | existing MP-DCCP | 3.2.2 |
| | | connection | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=2 | MP_FAST_CLOSE | Close an MP-DCCP | Section |
| | | connection | 3.2.3 |
| | | unconditionally | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=3 | MP_KEY | Exchange key | Section |
| | | material for | 3.2.4 |
| | | MP_HMAC | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=4 | MP_SEQ | Multipath sequence | Section |
| | | number | 3.2.5 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=5 | MP_HMAC | Hash-based message | Section |
| | | authentication code | 3.2.6 |
| | | for MP-DCCP | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=6 | MP_RTT | Transmit RTT values | Section |
| | | and calculation | 3.2.7 |
| | | parameters | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=7 | MP_ADDADDR | Advertise one or | Section |
| | | more additional | 3.2.8 |
| | | addresses/ports | |
+---------------+---------------+---------------------+-----------+
| MP_OPT=8 | MP_REMOVEADDR | Remove one or more | Section |
| | | addresses/ports | 3.2.9 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=9 | MP_PRIO | Change subflow | Section |
| | | priority | 3.2.10 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=10 | MP_CLOSE | Close an MP-DCCP | Section |
| | | connection | 3.2.11 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=11 | MP_EXP | Experimental option | Section |
| | | for private use | 3.2.12 |
+---------------+---------------+---------------------+-----------+
| MP_OPT=12-255 | Unassigned | | |
+---------------+---------------+---------------------+-----------+
Table 8: Multipath Options Registry
表 8: マルチパス オプション レジストリ
Future Multipath Options with MP_OPT>11 will be assigned from this registry using the RFC Required policy (Section 4.7 of [RFC8126]).
MP_OPT>11 の将来のマルチパス オプションは、RFC Required ポリシー ([RFC8126] のセクション 4.7) を使用してこのレジストリから割り当てられます。
IANA has assigned a new DCCP-Reset Code, value 13, in the "Reset Codes" registry, with the description "Abrupt MP termination". Use of this Reset Code is defined in Section 3.2.3.
IANA は、「リセット コード」レジストリに新しい DCCP-リセット コード、値 13 を割り当て、「突然の MP 終了」という説明を付けました。このリセット コードの使用はセクション 3.2.3 で定義されています。
IANA has created a new "Multipath Key Type" registry for this version of the MP-DCCP protocol that contains two different suboptions to the MP_KEY option to identify the MP_KEY Key types in terms of 8-bit values as specified in Section 3.2.4. See the initial entries in Table 9 below. Values in the range 1-254 (decimal) inclusive remain unassigned in this specified version 0 of the protocol and will be assigned via the RFC Required policy [RFC8126] in potential future versions of the MP-DCCP protocol.
IANA は、このバージョンの MP-DCCP プロトコル用に新しい「マルチパス キー タイプ」レジストリを作成しました。このレジストリには、セクション 3.2.4 で指定されているように、8 ビット値で MP_KEY キー タイプを識別するための MP_KEY オプションに対する 2 つの異なるサブオプションが含まれています。以下の表 9 の最初のエントリを参照してください。1 ～ 254 (10 進数) の範囲の値は、この指定されたプロトコルのバージョン 0 では未割り当てのままであり、MP-DCCP プロトコルの将来のバージョンでは RFC Required ポリシー [RFC8126] を介して割り当てられます。
+=======+==============+======================+===============+
| Type | Name | Meaning | Reference |
+=======+==============+======================+===============+
| 0 | Plain Text | Plain text Key | Section 3.2.4 |
+-------+--------------+----------------------+---------------+
| 1-254 | Unassigned | | |
+-------+--------------+----------------------+---------------+
| 255 | Experimental | For private use only | Section 3.2.4 |
+-------+--------------+----------------------+---------------+
Table 9: Multipath Key Type Registry with the MP_KEY Key Types for Key Data Exchange on Different Paths
表 9: 異なるパスでの鍵データ交換のための MP_KEY 鍵タイプを含むマルチパス鍵タイプ・レジストリー
[DCCP-PARAMETERS]
IANA, "Datagram Congestion Control Protocol (DCCP)
Parameters",
<https://www.iana.org/assignments/dccp-parameters>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[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>.
[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>.
[IETF105.Slides]
Amend, M., "MP-DCCP for enabling transfer of UDP/IP
traffic over multiple data paths in multi-connectivity
networks", IETF 105 Proceedings, July 2019,
<https://datatracker.ietf.org/meeting/105/materials/
slides-105-tsvwg-sessa-62-dccp-extensions-for-multipath-
operation-00>.
[MP-DCCP.Paper]
Amend, M., Bogenfeld, E., Cvjetkovic, M., Rakocevic, V.,
Pieska, M., Kassler, A., and A. Brunstrom, "A Framework
for Multiaccess Support for Unreliable Internet Traffic
using Multipath DCCP", 2019 IEEE 44th Conference on Local
Computer Networks (LCN), pp. 316-323,
DOI 10.1109/LCN44214.2019.8990746, October 2019,
<https://doi.org/10.1109/LCN44214.2019.8990746>.
[MP-DCCP.Site]
"Multipath extension for DCCP",
<https://multipath-dccp.org/>.
[MULTIPATH-REORDERING]
Amend, M. and D. Von Hugo, "Multipath sequence
maintenance", Work in Progress, Internet-Draft, draft-
amend-iccrg-multipath-reordering-03, 25 October 2021,
<https://datatracker.ietf.org/doc/html/draft-amend-iccrg-
multipath-reordering-03>.
[OLIA] Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J.
Le Boudec, "MPTCP is not pareto-optimal: performance
issues and a possible solution", CoNEXT '12: Proceedings
of the 8th international conference on Emerging networking
experiments and technologies, pp. 1-12,
DOI 10.1145/2413176.2413178, December 2012,
<https://dl.acm.org/doi/10.1145/2413176.2413178>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, DOI 10.17487/RFC5238, May 2008,
<https://www.rfc-editor.org/info/rfc5238>.
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol
(DCCP) Simultaneous-Open Technique to Facilitate NAT/
Middlebox Traversal", RFC 5596, DOI 10.17487/RFC5596,
September 2009, <https://www.rfc-editor.org/info/rfc5596>.
[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT)
Behavioral Requirements for the Datagram Congestion
Control Protocol", BCP 150, RFC 5597,
DOI 10.17487/RFC5597, September 2009,
<https://www.rfc-editor.org/info/rfc5597>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011,
<https://www.rfc-editor.org/info/rfc6356>.
[RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A
Datagram Congestion Control Protocol UDP Encapsulation for
NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November
2012, <https://www.rfc-editor.org/info/rfc6773>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904,
DOI 10.17487/RFC6904, April 2013,
<https://www.rfc-editor.org/info/rfc6904>.
[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>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC8041] Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and
Operational Experience with Multipath TCP", RFC 8041,
DOI 10.17487/RFC8041, January 2017,
<https://www.rfc-editor.org/info/rfc8041>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[TS23.501] 3GPP, "System architecture for the 5G System; Stage 2;
Release 16", Version 16.7.0, Release 16, December 2020,
<https://www.3gpp.org/ftp//Specs/
archive/23_series/23.501/23501-g70.zip>.
[U-DCCP] Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic,
"Lossless and overhead free DCCP - UDP header conversion
(U-DCCP)", Work in Progress, Internet-Draft, draft-amend-
tsvwg-dccp-udp-header-conversion-01, 8 July 2019,
<https://datatracker.ietf.org/doc/html/draft-amend-tsvwg-
dccp-udp-header-conversion-01>.
This appendix is informative.
この付録は有益です。
MP-DCCP is similar to Multipath TCP [RFC8684] in that it extends the related basic DCCP transport protocol [RFC4340] with multipath capabilities in the same way as Multipath TCP extends TCP [RFC9293]. However, because of the differences between the underlying TCP and DCCP protocols, the transport characteristics of MPTCP and MP-DCCP are different.
MP-DCCP は、マルチパス TCP が TCP [RFC9293] を拡張するのと同じ方法で、関連する基本 DCCP トランスポート プロトコル [RFC4340] をマルチパス機能で拡張するという点でマルチパス TCP [RFC8684] に似ています。ただし、基礎となる TCP プロトコルと DCCP プロトコルの違いにより、MPTCP と MP-DCCP のトランスポート特性は異なります。
Table 10 compares the protocol characteristics of TCP and DCCP, which are by nature inherited by their respective multipath extensions. A major difference lies in the delivery of the payload, which for TCP is an exact copy of the generated byte stream. DCCP behaves differently and does not guarantee the delivery of any payload nor the order of delivery. Since this is mainly affecting the receiving endpoint of a TCP or DCCP communication, many similarities on the sender side can be identified. Both transport protocols share the 3-way initiation of a communication and both employ congestion control to adapt the sending rate to the path characteristics.
表 10 は、TCP と DCCP のプロトコル特性を比較しています。これらの特性は、それぞれのマルチパス拡張によって本質的に継承されます。主な違いはペイロードの配信にあり、TCP の場合、ペイロードは生成されたバイト ストリームの正確なコピーです。DCCP の動作は異なり、ペイロードの配信や配信順序は保証されません。これは主に TCP または DCCP 通信の受信エンドポイントに影響を与えるため、送信側の多くの類似点を特定できます。どちらのトランスポート プロトコルも 3 方向の通信開始を共有し、送信レートをパス特性に適応させるために輻輳制御を採用しています。
+=======================+================+======================+
| Feature | TCP | DCCP |
+=======================+================+======================+
| Full-Duplex | yes | yes |
+-----------------------+----------------+----------------------+
| Connection-Oriented | yes | yes |
+-----------------------+----------------+----------------------+
| Header option space | 40 bytes | < 1008 bytes or PMTU |
+-----------------------+----------------+----------------------+
| Data transfer | reliable | unreliable |
+-----------------------+----------------+----------------------+
| Packet-loss handling | retransmission | report only |
+-----------------------+----------------+----------------------+
| Ordered data delivery | yes | no |
+-----------------------+----------------+----------------------+
| Sequence numbers | one per byte | one per PDU |
+-----------------------+----------------+----------------------+
| Flow control | yes | no |
+-----------------------+----------------+----------------------+
| Congestion control | yes | yes |
+-----------------------+----------------+----------------------+
| ECN support | yes | yes |
+-----------------------+----------------+----------------------+
| Selective ACK | yes | depends on |
| | | congestion control |
+-----------------------+----------------+----------------------+
| Fix message | no | yes |
| boundaries | | |
+-----------------------+----------------+----------------------+
| Path MTU discovery | yes | yes |
+-----------------------+----------------+----------------------+
| Fragmentation | yes | no |
+-----------------------+----------------+----------------------+
| SYN flood protection | yes | no |
+-----------------------+----------------+----------------------+
| Half-open connections | yes | no |
+-----------------------+----------------+----------------------+
Table 10: TCP and DCCP Protocol Comparison
表 10: TCP と DCCP プロトコルの比較
Consequently, the multipath characteristics shown in Table 11 are the same, supporting volatile paths that have varying capacities and latency, session handovers, and path aggregation capabilities. All of these features profit by the existence of congestion control.
したがって、表 11 に示すマルチパス特性は同じであり、さまざまな容量と遅延、セッション ハンドオーバー、およびパス集約機能を持つ揮発性パスをサポートします。これらの機能はすべて、輻輳制御の存在によって利益をもたらします。
+==================+=======================+==========+
| Feature | MPTCP | MP-DCCP |
+==================+=======================+==========+
| Volatile paths | yes | yes |
+------------------+-----------------------+----------+
| Session handover | yes | yes |
+------------------+-----------------------+----------+
| Path aggregation | yes | yes |
+------------------+-----------------------+----------+
| Data reordering | yes | optional |
+------------------+-----------------------+----------+
| Expandability | limited by TCP header | flexible |
+------------------+-----------------------+----------+
Table 11: MPTCP and MP-DCCP Protocol Comparison
表 11: MPTCP と MP-DCCP プロトコルの比較
Therefore, the sender logic is not much different between MP-DCCP and MPTCP.
したがって、送信側ロジックは MP-DCCP と MPTCP で大きな違いはありません。
The receiver side for MP-DCCP has to deal with the unreliable delivery provided by DCCP. The multipath sequence numbers included in MP-DCCP (see Section 3.2.5) facilitates adding optional mechanisms for data stream packet reordering at the receiver. Information from the MP_RTT Multipath Option (Section 3.2.7), DCCP path sequencing, and the DCCP Timestamp Option provide further means for advanced reordering approaches, e.g., as proposed in [MULTIPATH-REORDERING]. However, such mechanisms do not affect interoperability and are not part of the MP-DCCP protocol. Many applications that use unreliable transport protocols can also inherently process out-of-sequence data (e.g., through adaptive audio and video buffers), so additional reordering support might not be necessary. The addition of optional reordering mechanisms are likely to be needed when the different DCCP subflows are routed across paths with different latencies. In theory, applications using DCCP are aware that packet reordering could occur, because DCCP does not provide mechanisms to restore the original packet order.
MP-DCCP の受信側は、DCCP によって提供される信頼性の低い配信に対処する必要があります。MP-DCCP (セクション 3.2.5 を参照) に含まれるマルチパス シーケンス番号により、受信側でのデータ ストリーム パケットの並べ替えのためのオプションのメカニズムの追加が容易になります。MP_RTT マルチパス オプション (セクション 3.2.7)、DCCP パス シーケンス、および DCCP タイムスタンプ オプションからの情報は、たとえば [MULTIPATH-REORDERING] で提案されているような、高度な並べ替えアプローチのためのさらなる手段を提供します。ただし、そのようなメカニズムは相互運用性に影響を与えず、MP-DCCP プロトコルの一部ではありません。信頼性の低いトランスポート プロトコルを使用する多くのアプリケーションは、本質的にシーケンス外のデータを処理することもできるため (適応型オーディオおよびビデオ バッファーなどを介して)、追加の並べ替えサポートは必要ない可能性があります。さまざまな DCCP サブフローがさまざまな遅延を持つパスを介してルーティングされる場合は、オプションの並べ替えメカニズムの追加が必要になる可能性があります。理論的には、DCCP を使用するアプリケーションは、パケットの順序変更が発生する可能性があることを認識しています。これは、DCCP が元のパケット順序を復元するメカニズムを提供していないためです。
In contrast to TCP, the receiver processing for MPTCP adopted a rigid "just wait" approach, because TCP guarantees reliable in-order delivery.
TCP とは対照的に、TCP は信頼性の高い順序どおりの配信を保証するため、MPTCP の受信側処理には厳格な「ただ待つ」アプローチが採用されています。
[RFC8684] defines Multipath TCP and provides important inputs for this specification.
[RFC8684] はマルチパス TCP を定義し、この仕様への重要なインプットを提供します。
The authors gratefully acknowledge significant input into this document from Dirk von Hugo, Nathalie Romo Moreno, Omar Nassef, Mohamed Boucadair, Simone Ferlin, Olivier Bonaventure, Gorry Fairhurst, and Behcet Sarikaya.
著者らは、この文書に対する Dirk von Hugo、Nathalie Romo Moreno、Omar Nassef、Mohamed Boucadair、Simone Ferlin、Olivier Bonaventure、Gorry Fairhurst、Behcet Sarikaya からの多大な貢献に感謝します。
Markus Amend (editor)
Deutsche Telekom
Deutsche-Telekom-Allee 9
64295 Darmstadt
Germany
Email: Markus.Amend@telekom.de
Anna Brunstrom
Karlstad University
Universitetsgatan 2
SE-651 88 Karlstad
Sweden
Email: anna.brunstrom@kau.se
Andreas Kassler
Karlstad University
Universitetsgatan 2
SE-651 88 Karlstad
Sweden
Email: andreas.kassler@kau.se
Veselin Rakocevic
City St George's, University of London
Northampton Square
London
United Kingdom
Email: veselin.rakocevic.1@city.ac.uk
Stephen Johnson
BT
Adastral Park
Martlesham Heath
IP5 3RE
United Kingdom
Email: stephen.h.johnson@bt.com