[要約] RFC 8684は、複数のアドレスを使用したマルチパス操作のためのTCP拡張に関するものです。その目的は、複数のネットワークパスを同時に使用してTCP接続の性能を向上させることです。
Internet Engineering Task Force (IETF) A. Ford
Request for Comments: 8684 Pexip
Obsoletes: 6824 C. Raiciu
Category: Standards Track U. Politehnica of Bucharest
ISSN: 2070-1721 M. Handley
U. College London
O. Bonaventure
U. catholique de Louvain
C. Paasch
Apple, Inc.
March 2020
TCP Extensions for Multipath Operation with Multiple Addresses
複数のアドレスを持つマルチパス操作のためのTCP拡張
Abstract
概要
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.
TCP / IP通信は現在、接続ごとに1つのパスに制限されていますが、ピア間に複数のパスが存在することがよくあります。 TCP / IPセッションでこれらの複数のパスを同時に使用すると、ネットワーク内のリソースの使用率が向上し、スループットの向上とネットワーク障害に対する回復力の向上により、ユーザーエクスペリエンスが向上します。
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.
マルチパスTCPは、ピア間の複数のパスを同時に使用する機能を提供します。このドキュメントでは、マルチパス操作をサポートするための、従来のTCPに対する一連の拡張機能について説明します。このプロトコルは、TCPと同じタイプのサービスをアプリケーションに提供し（つまり、信頼性の高いバイトストリーム）、互いに素である可能性のあるパス全体で複数のTCPフローを確立して使用するために必要なコンポーネントを提供します。
This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.
このドキュメントでは、マルチパスTCPのv1を指定し、RFC 6824で指定されているv0を廃止し、主に導入経験に基づいて明確化および変更を行いました。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、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/rfc8684.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8684で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよび文書の作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction 1.1. Design Assumptions 1.2. Multipath TCP in the Networking Stack 1.3. Terminology 1.4. MPTCP Concept 1.5. Requirements Language 2. Operation Overview 2.1. Initiating an MPTCP Connection 2.2. Associating a New Subflow with an Existing MPTCP Connection 2.3. Informing the Other Host about Another Potential Address 2.4. Data Transfer Using MPTCP 2.5. Requesting a Change in a Path's Priority 2.6. Closing an MPTCP Connection 2.7. Notable Features 3. MPTCP Operations: An Overview 3.1. Connection Initiation 3.2. Starting a New Subflow 3.3. MPTCP Operation and Data Transfer 3.3.1. Data Sequence Mapping 3.3.2. Data Acknowledgments 3.3.3. Closing a Connection 3.3.4. Receiver Considerations 3.3.5. Sender Considerations 3.3.6. Reliability and Retransmissions 3.3.7. Congestion Control Considerations 3.3.8. Subflow Policy 3.4. Address Knowledge Exchange (Path Management) 3.4.1. Address Advertisement 3.4.2. Remove Address 3.5. Fast Close 3.6. Subflow Reset 3.7. Fallback 3.8. Error Handling 3.9. Heuristics 3.9.1. Port Usage 3.9.2. Delayed Subflow Start and Subflow Symmetry 3.9.3. Failure Handling 4. Semantic Issues 5. Security Considerations 6. Interactions with Middleboxes 7. IANA Considerations 7.1. TCP Option Kind Numbers 7.2. MPTCP Option Subtypes 7.3. MPTCP Handshake Algorithms 7.4. MP_TCPRST Reason Codes 8. References 8.1. Normative References 8.2. Informative References Appendix A. Notes on Use of TCP Options Appendix B. TCP Fast Open and MPTCP B.1. TFO Cookie Request with MPTCP B.2. Data Sequence Mapping under TFO B.3. Connection Establishment Examples Appendix C. Control Blocks C.1. MPTCP Control Block C.1.1. Authentication and Metadata C.1.2. Sending Side C.1.3. Receiving Side C.2. TCP Control Blocks C.2.1. Sending Side C.2.2. Receiving Side Appendix D. Finite State Machine Appendix E. Changes from RFC 6824 Acknowledgments Authors' Addresses
1. はじめに1.1。設計の前提1.2。ネットワークスタック1.3のマルチパスTCP。用語1.4。 MPTCPコンセプト1.5。要件言語2.操作の概要2.1。 MPTCP接続の開始2.2。新しいサブフローと既存のMPTCP接続の関連付け2.3。他の潜在的なアドレスについて他のホストに通知する2.4。 MPTCP 2.5を使用したデータ転送。パスの優先度の変更を要求する2.6。 MPTCP接続を閉じる2.7。注目すべき機能3. MPTCPオペレーション：概要3.1。接続開始3.2。新しいサブフローの開始3.3。 MPTCPの操作とデータ転送3.3.1。データシーケンスマッピング3.3.2。データの確認3.3.3。接続を閉じる3.3.4。レシーバーの考慮事項3.3.5。送信者の考慮事項3.3.6。信頼性と再送信3.3.7。輻輳制御の考慮事項3.3.8。サブフローポリシー3.4。ナレッジエクスチェンジ（パス管理）への対応3.4.1。アドレスアドバタイズメント3.4.2。アドレス3.5を削除します。高速クローズ3.6。サブフローのリセット3.7。フォールバック3.8。エラー処理3.9。ヒューリスティックス3.9.1。ポートの使用3.9.2。遅延サブフローの開始とサブフローの対称性3.9.3。障害処理4.セマンティックの問題5.セキュリティの考慮事項6.ミドルボックスとの相互作用7. IANAの考慮事項7.1。 TCPオプションの種類番号7.2。 MPTCPオプションサブタイプ7.3。 MPTCPハンドシェイクアルゴリズム7.4。 MP_TCPRST理由コード8.参考資料8.1。規範的な参考文献8.2。有益な参考資料付録A. TCPオプションの使用に関する注記付録B. TCP Fast OpenおよびMPTCP B.1。 MPTCP B.2を使用したTFO Cookie要求。 TFOでのデータシーケンスマッピングB.3。接続確立の例付録C.制御ブロックC.1。 MPTCP制御ブロックC.1.1。認証とメタデータC.1.2。送信側C.1.3。受信側C.2。 TCP制御ブロックC.2.1。送信側C.2.2。受信側付録D.有限状態マシン付録E. RFC 6824からの変更点謝辞著者のアドレス
Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793] to provide a Multipath TCP service [RFC6182], which enables a transport connection to operate across multiple paths simultaneously. This document presents the protocol changes required to add multipath capability to TCP -- specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of data, and termination of sessions. This is not the only information required to create a Multipath TCP implementation, however. This document is complemented by three others:
マルチパスTCP（MPTCP）は、マルチパスTCPサービス[RFC6182]を提供するための通常のTCP [RFC0793]の拡張セットであり、トランスポート接続が複数のパスで同時に動作できるようにします。このドキュメントでは、TCPにマルチパス機能を追加するために必要なプロトコルの変更について説明します。具体的には、マルチパス（「サブフロー」）のシグナリングとセットアップ、これらのサブフローの管理、データの再構成、セッションの終了などです。ただし、マルチパスTCP実装を作成するために必要な情報はこれだけではありません。このドキュメントは、他の3つによって補足されます。
* [RFC6182] (MPTCP architecture), which explains the motivations behind Multipath TCP, contains a discussion of high-level design decisions on which this design is based, and provides an explanation of a functional separation through which an extensible MPTCP implementation can be developed.
* [RFC6182]（MPTCPアーキテクチャ）は、マルチパスTCPの背後にある動機を説明し、この設計の基礎となる高レベルの設計決定についての議論を含み、拡張可能なMPTCP実装を開発できる機能的な分離について説明します。
* [RFC6356] (congestion control), which presents a safe congestion control algorithm for coupling the behavior of the multiple paths in order to "do no harm" to other network users.
* [RFC6356]（輻輳制御）。これは、他のネットワークユーザーに「害を与えない」ために複数のパスの動作を結合するための安全な輻輳制御アルゴリズムを示します。
* [RFC6897] (application considerations), which discusses what impact MPTCP will have on applications, what applications will want to do with MPTCP, and as a consequence of these factors, what API extensions an MPTCP implementation should present.
* [RFC6897]（アプリケーションの考慮事項）。MPTCPがアプリケーションに与える影響、アプリケーションがMPTCPでどのようなことを実行するか、およびこれらの要因の結果としてMPTCP実装が提供する必要があるAPI拡張について説明します。
This document obsoletes the v0 specification of Multipath TCP [RFC6824]. This document specifies MPTCP v1, which is not backward compatible with MPTCP v0. This document additionally defines version negotiation procedures for implementations that support both versions.
このドキュメントは、マルチパスTCP [RFC6824]のv0仕様を廃止します。このドキュメントではMPTCP v1を指定していますが、これはMPTCP v0との下位互換性がありません。このドキュメントでは、両方のバージョンをサポートする実装のバージョンネゴシエーション手順をさらに定義します。
In order to limit the potentially huge design space, the MPTCP Working Group imposed two key constraints on the Multipath TCP design presented in this document:
潜在的に巨大な設計スペースを制限するために、MPTCPワーキンググループは、このドキュメントで提示されているマルチパスTCP設計に2つの重要な制約を課しました。
* It must be backward compatible with current, regular TCP, to increase its chances of deployment.
* 展開の可能性を高めるには、現在の通常のTCPとの下位互換性が必要です。
* It can be assumed that one or both hosts are multihomed and multiaddressed.
* 一方または両方のホストがマルチホーム化され、マルチアドレス指定されていると想定できます。
To simplify the design, we assume that the presence of multiple addresses at a host is sufficient to indicate the existence of multiple paths. These paths need not be entirely disjoint: they may share one or many routers between them. Even in such a situation, making use of multiple paths is beneficial, improving resource utilization and resilience to a subset of node failures. The congestion control algorithm defined in [RFC6356] ensures that the use of multiple paths does not act detrimentally. Furthermore, there may be some scenarios where different TCP ports on a single host can provide disjoint paths (such as through certain Equal-Cost Multipath (ECMP) implementations [RFC2992]), and so the MPTCP design also supports the use of ports in path identifiers.
設計を簡略化するために、ホストに複数のアドレスが存在すれば、複数のパスが存在することを示すのに十分であると想定しています。これらのパスは完全にばらばらである必要はありません。パス間で1つまたは複数のルーターを共有する場合があります。このような状況でも、複数のパスを使用することは有益であり、リソース使用率とノード障害のサブセットに対する回復力を向上させます。 [RFC6356]で定義されている輻輳制御アルゴリズムは、複数のパスの使用が有害な動作をしないことを保証します。さらに、単一のホスト上の異なるTCPポートがばらばらのパスを提供できる（特定の等コストマルチパス（ECMP）実装[RFC2992]などを介して）場合があるため、MPTCP設計はパス内のポートの使用もサポートします。識別子。
There are three aspects to the backward compatibility listed above (discussed in more detail in [RFC6182]):
上記の下位互換性には3つの側面があります（[RFC6182]で詳細に説明されています）。
External Constraints: The protocol must function through the vast majority of existing middleboxes such as NATs, firewalls, and proxies, and as such must resemble existing TCP as far as possible on the wire. Furthermore, the protocol must not assume that the segments it sends on the wire arrive unmodified at the destination: they may be split or coalesced; TCP options may be removed or duplicated.
外部制約：プロトコルは、NAT、ファイアウォール、プロキシなどの既存のミドルボックスの大部分を介して機能する必要があり、回線上で可能な限り既存のTCPに類似している必要があります。さらに、プロトコルは、ネットワーク上で送信するセグメントが変更されずに宛先に到着することを前提としてはなりません。これらのセグメントは分割または合体される場合があります。 TCPオプションは削除または複製される場合があります。
Application Constraints: The protocol must be usable with no change to existing applications that use the common TCP API (although it is reasonable that not all features would be available to such legacy applications). Furthermore, the protocol must provide the same service model as regular TCP to the application.
アプリケーションの制約：プロトコルは、共通のTCP APIを使用する既存のアプリケーションを変更せずに使用できる必要があります（ただし、そのようなレガシーアプリケーションですべての機能を使用できるわけではありません）。さらに、プロトコルは通常のTCPと同じサービスモデルをアプリケーションに提供する必要があります。
Fallback: The protocol should be able to fall back to standard TCP with no interference from the user, to be able to communicate with legacy hosts.
フォールバック：プロトコルは、レガシーホストと通信できるように、ユーザーからの干渉なしに標準TCPにフォールバックできる必要があります。
The complementary application considerations document [RFC6897] discusses the necessary features of an API to provide backward compatibility, as well as API extensions to convey the behavior of MPTCP at a level of control and information equivalent to that available with regular, single-path TCP.
補足的なアプリケーションの考慮事項に関するドキュメント[RFC6897]では、後方互換性を提供するために必要なAPIの機能と、通常の単一パスTCPで利用可能なものと同等の制御および情報レベルでMPTCPの動作を伝えるためのAPI拡張について説明しています。
Further discussion of the design constraints and associated design decisions is given in the MPTCP architecture document [RFC6182] and in [howhard].
設計の制約と関連する設計の決定の詳細については、MPTCPアーキテクチャドキュメント[RFC6182]と[howhard]に記載されています。
MPTCP operates at the transport layer and aims to be transparent to both higher and lower layers. It is a set of additional features on top of standard TCP; Figure 1 illustrates this layering. MPTCP is designed to be usable by legacy applications with no changes; detailed discussion of its interactions with applications is given in [RFC6897].
MPTCPはトランスポート層で動作し、上位層と下位層の両方に対して透過的であることを目的としています。これは、標準TCPに追加された一連の追加機能です。図1は、この階層化を示しています。 MPTCPは、変更なしでレガシーアプリケーションで使用できるように設計されています。アプリケーションとの相互作用の詳細な議論は[RFC6897]で与えられます。
+-------------------------------+
| Application |
+---------------+ +-------------------------------+
| Application | | MPTCP |
+---------------+ + - - - - - - - + - - - - - - - +
| TCP | | Subflow (TCP) | Subflow (TCP) |
+---------------+ +-------------------------------+
| IP | | IP | IP |
+---------------+ +-------------------------------+
Figure 1: Comparison of Standard TCP and MPTCP Protocol Stacks
図1：標準TCPとMPTCPプロトコルスタックの比較
This document makes use of a number of terms that are either MPTCP specific or have defined meaning in the context of MPTCP, as follows:
このドキュメントでは、次のように、MPTCP固有の用語や、MPTCPのコンテキストで定義された意味を持ついくつかの用語を使用しています。
Path: A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination address/port pairs.
パス：送信元と受信先の間の一連のリンク。このコンテキストでは、送信元と宛先のアドレス/ポートのペアの4タプルによって定義されます。
Subflow: A flow of TCP segments operating over an individual path, which forms part of a larger MPTCP connection. A subflow is started and terminated similarly to a regular TCP connection.
サブフロー：個々のパスで動作するTCPセグメントのフロー。これは、より大きなMPTCP接続の一部を形成します。サブフローは、通常のTCP接続と同様に開始および終了します。
(MPTCP) Connection: A set of one or more subflows, over which an application can communicate between two hosts. There is a one-to-one mapping between a connection and an application socket.
（MPTCP）接続：アプリケーションが2つのホスト間で通信できる1つ以上のサブフローのセット。接続とアプリケーションソケットの間には1対1のマッピングがあります。
Data-level: The payload data is nominally transferred over a connection, which in turn is transported over subflows. Thus, the term "data-level" is synonymous with "connection-level", in contrast to "subflow-level", which refers to properties of an individual subflow.
データ・レベル：ペイロード・データは、名目上、接続を介して転送され、次に接続がサブフローを介して転送されます。したがって、「データレベル」という用語は、個々のサブフローのプロパティを指す「サブフローレベル」とは対照的に、「接続レベル」と同義です。
Token: A locally unique identifier given to a multipath connection by a host. May also be referred to as a "Connection ID".
トークン：ホストによってマルチパス接続に与えられたローカルで一意の識別子。 「接続ID」とも呼ばれます。
Host: An end host operating an MPTCP implementation, and either initiating or accepting an MPTCP connection.
ホスト：MPTCP実装を操作し、MPTCP接続を開始または受け入れるエンドホスト。
In addition to these terms, note that MPTCP's interpretation of, and effect on, regular single-path TCP semantics are discussed in Section 4.
これらの用語に加えて、通常の単一パスTCPセマンティクスのMPTCPの解釈とその影響については、セクション4で説明しています。
This section provides a high-level summary of normal operation of MPTCP; this type of scenario is illustrated in Figure 2. A detailed description of how MPTCP operates is given in Section 3.
このセクションでは、MPTCPの通常の操作の概要を説明します。このタイプのシナリオを図2に示します。MPTCPの動作の詳細については、セクション3で説明します。
Host A Host B
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| (initial connection setup) | |
|----------------------------------->| |
|<-----------------------------------| |
| | | |
| (additional subflow setup) |
| |--------------------->| |
| |<---------------------| |
| | | |
| | | |
Figure 2: Example MPTCP Usage Scenario
図2：MPTCP使用シナリオの例
* To a non-MPTCP-aware application, MPTCP will behave the same as normal TCP. Extended APIs could provide additional control to MPTCP-aware applications [RFC6897]. An application begins by opening a TCP socket in the normal way. MPTCP signaling and operation are handled by the MPTCP implementation.
* MPTCP非対応のアプリケーションでは、MPTCPは通常のTCPと同じように動作します。拡張APIは、MPTCP対応アプリケーションに追加の制御を提供できます[RFC6897]。アプリケーションは、通常の方法でTCPソケットを開くことから始まります。 MPTCPシグナリングと操作は、MPTCP実装によって処理されます。
* An MPTCP connection begins similarly to a regular TCP connection. This is illustrated in Figure 2, where an MPTCP connection is established between addresses A1 and B1 on Hosts A and B, respectively.
* MPTCP接続は、通常のTCP接続と同様に始まります。これを図2に示します。MPTCP接続は、ホストAとBのアドレスA1とB1の間にそれぞれ確立されます。
* If extra paths are available, additional TCP sessions (termed MPTCP "subflows") are created on these paths and are combined with the existing session, which continues to appear as a single connection to the applications at both ends. The creation of the additional TCP session is illustrated between Address A2 on Host A and Address B1 on Host B.
* 追加のパスが使用可能な場合、追加のTCPセッション（MPTCP "サブフロー"と呼ばれる）がこれらのパス上に作成され、既存のセッションと結合され、両端のアプリケーションへの単一の接続として表示され続けます。追加のTCPセッションの作成は、ホストAのアドレスA2とホストBのアドレスB1の間で示されています。
* MPTCP identifies multiple paths by the presence of multiple addresses at hosts. Combinations of these multiple addresses equate to the additional paths. In the example, other potential paths that could be set up are A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1 or B2.
* MPTCPは、ホストに複数のアドレスが存在することにより、複数のパスを識別します。これらの複数のアドレスの組み合わせは、追加のパスと同じです。この例では、設定できる他の潜在的なパスはA1 <-> B2およびA2 <-> B2です。この追加セッションはA2から開始されたものとして示されていますが、B1またはB2からも同様に開始された可能性があります。
* The discovery and setup of additional subflows will be achieved through a path management method; this document describes a mechanism by which a host can initiate new subflows by using its own additional addresses or by signaling its available addresses to the other host.
* 追加のサブフローの検出とセットアップは、パス管理方法によって実現されます。このドキュメントでは、ホストが独自の追加アドレスを使用するか、使用可能なアドレスを他のホストにシグナリングすることにより、ホストが新しいサブフローを開始できるメカニズムについて説明します。
* MPTCP adds connection-level sequence numbers to allow the reassembly of segments arriving on multiple subflows with differing network delays.
* MPTCPは、接続レベルのシーケンス番号を追加して、ネットワーク遅延が異なる複数のサブフローに到着するセグメントを再構成できるようにします。
* Subflows are terminated as regular TCP connections, with a four-way FIN handshake. The MPTCP connection is terminated by a connection-level FIN.
* サブフローは、4方向FINハンドシェイクにより、通常のTCP接続として終了します。 MPTCP接続は、接続レベルのFINによって終了します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This section presents a single description of common MPTCP operation, with reference to the protocol operation. This is a high-level overview of the key functions; the full specification follows in Section 3. Extensibility and negotiated features are not discussed here. Considerable reference is made to symbolic names of MPTCP options throughout this section -- these are subtypes of the IANA-assigned MPTCP option (see Section 7), and their formats are defined in the detailed protocol specification provided in Section 3.
このセクションでは、プロトコル操作を参照しながら、一般的なMPTCP操作について1つ説明します。これは、主要な機能の概要です。完全な仕様はセクション3に続きます。拡張性と交渉された機能については、ここでは説明しません。このセクション全体で、MPTCPオプションのシンボリック名がかなり参照されています。これらは、IANAによって割り当てられたMPTCPオプション（セクション7を参照）のサブタイプであり、そのフォーマットは、セクション3で提供される詳細なプロトコル仕様で定義されています。
A Multipath TCP connection provides a bidirectional bytestream between two hosts communicating like normal TCP and thus does not require any change to the applications. However, Multipath TCP enables the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. A Multipath TCP connection appears like a normal TCP connection to an application. However, to the network layer, each MPTCP subflow looks like a regular TCP flow whose segments carry a new TCP option type. Multipath TCP manages the creation, removal, and utilization of these subflows to send data. The number of subflows that are managed within a Multipath TCP connection is not fixed, and it can fluctuate during the lifetime of the Multipath TCP connection.
マルチパスTCP接続は、通常のTCPのように通信する2つのホスト間に双方向バイトストリームを提供するため、アプリケーションを変更する必要はありません。ただし、マルチパスTCPを使用すると、ホストは異なるIPアドレスの異なるパスを使用して、MPTCP接続に属するパケットを交換できます。マルチパスTCP接続は、アプリケーションへの通常のTCP接続のように見えます。ただし、ネットワーク層では、各MPTCPサブフローは通常のTCPフローのように見え、そのセグメントには新しいTCPオプションタイプが含まれます。マルチパスTCPは、データを送信するためのこれらのサブフローの作成、削除、および利用を管理します。マルチパスTCP接続内で管理されるサブフローの数は固定されておらず、マルチパスTCP接続の存続期間中に変動する可能性があります。
All MPTCP operations are signaled with a TCP option -- a single numerical type for MPTCP, with "subtypes" for each MPTCP message. What follows is a summary of the purpose and rationale of these messages.
すべてのMPTCP操作は、TCPオプション-各MPTCPメッセージに「サブタイプ」を持つMPTCPの単一の数値タイプ-で通知されます。以下は、これらのメッセージの目的と根拠の要約です。
This is the same signaling as for initiating a normal TCP connection, but the SYN, SYN/ACK, and initial ACK (and data) packets also carry the MP_CAPABLE option. This option has a variable length and serves multiple purposes. Firstly, it verifies whether the remote host supports Multipath TCP; secondly, this option allows the hosts to exchange some information to authenticate the establishment of additional subflows. Further details are given in Section 3.1.
これは、通常のTCP接続を開始する場合と同じシグナリングですが、SYN、SYN / ACK、および初期ACK（およびデータ）パケットにもMP_CAPABLEオプションが含まれます。このオプションは可変長であり、複数の目的に役立ちます。まず、リモートホストがマルチパスTCPをサポートしているかどうかを確認します。次に、このオプションにより、ホストはいくつかの情報を交換して、追加のサブフローの確立を認証できます。詳細については、セクション3.1を参照してください。
Host A Host B
------ ------
MP_CAPABLE ->
[flags]
<- MP_CAPABLE
[B's key, flags]
ACK + MP_CAPABLE (+ data) ->
[A's key, B's key, flags, (data-level details)]
Retransmission of the ACK + MP_CAPABLE can occur if it is not known if it has been received. The following diagrams show all possible exchanges for the initial subflow setup to ensure this reliability.
ACK + MP_CAPABLEの再送信は、受信されたかどうか不明な場合に発生する可能性があります。次の図は、この信頼性を確保するための初期サブフロー設定で可能なすべての交換を示しています。
Host A (with data to send immediately) Host B
------ ------
MP_CAPABLE ->
[flags]
<- MP_CAPABLE
[B's key, flags]
ACK + MP_CAPABLE + data ->
[A's key, B's key, flags, data-level details]
Host A (with data to send later) Host B
------ ------
MP_CAPABLE ->
[flags]
<- MP_CAPABLE
[B's key, flags]
ACK + MP_CAPABLE ->
[A's key, B's key, flags]
ACK + MP_CAPABLE + data ->
[A's key, B's key, flags, data-level details]
Host A Host B (sending first)
------ ------
MP_CAPABLE ->
[flags]
<- MP_CAPABLE
[B's key, flags]
ACK + MP_CAPABLE ->
[A's key, B's key, flags]
<- ACK + DSS + data [data-level details]
<-ACK + DSS +データ[データレベルの詳細]
The exchange of keys in the MP_CAPABLE handshake provides material that can be used to authenticate the endpoints when new subflows will be set up. Additional subflows begin in the same way as initiating a normal TCP connection, but the SYN, SYN/ACK, and ACK packets also carry the MP_JOIN option.
MP_CAPABLEハンドシェイクでの鍵の交換により、新しいサブフローがセットアップされるときにエンドポイントを認証するために使用できる資料が提供されます。追加のサブフローは、通常のTCP接続の開始と同じ方法で始まりますが、SYN、SYN / ACK、およびACKパケットもMP_JOINオプションを伝送します。
Host A initiates a new subflow between one of its addresses and one of Host B's addresses. The token -- generated from the key -- is used to identify which MPTCP connection it is joining, and the Hash-based Message Authentication Code (HMAC) is used for authentication. The HMAC uses the keys exchanged in the MP_CAPABLE handshake and the random numbers (nonces) exchanged in these MP_JOIN options. MP_JOIN also contains flags and an Address ID that can be used to refer to the source address without the sender needing to know if it has been changed by a NAT. Further details are given in Section 3.2.
ホストAは、そのアドレスの1つとホストBのアドレスの1つとの間に新しいサブフローを開始します。トークン（キーから生成されたもの）は、参加しているMPTCP接続を識別するために使用され、ハッシュベースのメッセージ認証コード（HMAC）が認証に使用されます。 HMACは、MP_CAPABLEハンドシェイクで交換される鍵と、これらのMP_JOINオプションで交換される乱数（ノンス）を使用します。 MP_JOINには、送信元がNATによって変更されたかどうかを知る必要なく送信元アドレスを参照するために使用できるフラグとアドレスIDも含まれています。詳細については、セクション3.2を参照してください。
Host A Host B
------ ------
MP_JOIN ->
[B's token, A's nonce,
A's Address ID, flags]
<- MP_JOIN
[B's HMAC, B's nonce,
B's Address ID, flags]
ACK + MP_JOIN ->
[A's HMAC]
<- ACK
<-ACK
The set of IP addresses associated to a multihomed host may change during the lifetime of an MPTCP connection. MPTCP supports the addition and removal of addresses on a host both implicitly and explicitly. If Host A has established a subflow starting at address/port pair IP#-A1 and wants to open a second subflow starting at address/port pair IP#-A2, it simply initiates the establishment of the subflow as explained above. The remote host will then be implicitly informed about the new address.
マルチホームホストに関連付けられたIPアドレスのセットは、MPTCP接続の存続期間中に変更される可能性があります。 MPTCPは、ホスト上でのアドレスの追加と削除を暗黙的および明示的にサポートしています。ホストAがアドレス/ポートペアIP＃-A1で始まるサブフローを確立し、アドレス/ポートペアIP＃-A2で始まる2番目のサブフローを開きたい場合、ホストAは上記のようにサブフローの確立を開始します。その後、リモートホストに新しいアドレスが暗黙的に通知されます。
In some circumstances, a host may want to advertise to the remote host the availability of an address without establishing a new subflow -- for example, when a NAT prevents setup in one direction. In the example below, Host A informs Host B about its alternative IP address/port pair (IP#-A2). Host B may later send an MP_JOIN to this new address. The ADD_ADDR option contains an HMAC to authenticate the address as having been sent from the originator of the connection. The receiver of this option echoes it back to the client to indicate successful receipt. Further details are given in Section 3.4.1.
状況によっては、ホストが新しいサブフローを確立せずにアドレスの可用性をリモートホストにアドバタイズする場合があります。たとえば、NATが一方向のセットアップを妨げる場合などです。次の例では、ホストAがホストBに代替IPアドレス/ポートのペア（IP＃-A2）を通知しています。ホストBは後でこの新しいアドレスにMP_JOINを送信できます。 ADD_ADDRオプションには、接続の発信元から送信されたものとしてアドレスを認証するためのHMACが含まれています。このオプションの受信側は、それをクライアントにエコーバックして、正常に受信されたことを示します。詳細については、セクション3.4.1を参照してください。
Host A Host B
------ ------
ADD_ADDR ->
[Echo-flag=0,
IP#-A2,
IP#-A2's Address ID,
HMAC of IP#-A2]
<- ADD_ADDR [Echo-flag=1, IP#-A2, IP#-A2's Address ID, HMAC of IP#-A2]
<-ADD_ADDR [Echo-flag = 1、IP＃-A2、IP＃-A2のアドレスID、IP＃-A2のHMAC]
There is a corresponding signal for address removal, making use of the Address ID that is signaled in the ADD_ADDR handshake. Further details are given in Section 3.4.2.
ADD_ADDRハンドシェイクで通知されるアドレスIDを利用して、アドレス削除に対応する信号があります。詳細については、セクション3.4.2を参照してください。
Host A Host B
------ ------
REMOVE_ADDR ->
[IP#-A2's Address ID]
To ensure reliable, in-order delivery of data over subflows that may appear and disappear at any time, MPTCP uses a 64-bit Data Sequence Number (DSN) to number all data sent over the MPTCP connection. Each subflow has its own 32-bit sequence number space, utilizing the regular TCP sequence number header, and an MPTCP option maps the subflow sequence space to the data sequence space. In this way, data can be retransmitted on different subflows (mapped to the same DSN) in the event of failure.
MPTCPは、64ビットのデータシーケンス番号（DSN）を使用して、MPTCP接続を介して送信されるすべてのデータに番号を付けるため、64ビットのデータシーケンス番号（DSN）を使用します。各サブフローには、通常のTCPシーケンス番号ヘッダーを利用する独自の32ビットシーケンス番号スペースがあり、MPTCPオプションはサブフローシーケンススペースをデータシーケンススペースにマップします。このようにして、障害が発生した場合に、データを異なるサブフロー（同じDSNにマップ）で再送信できます。
The Data Sequence Signal (DSS) carries the Data Sequence Mapping. The Data Sequence Mapping consists of the subflow sequence number, data sequence number, and length for which this mapping is valid. This option can also carry a connection-level acknowledgment (the "Data ACK") for the received DSN.
データシーケンス信号（DSS）は、データシーケンスマッピングを伝送します。データシーケンスマッピングは、このマッピングが有効なサブフローシーケンス番号、データシーケンス番号、および長さで構成されます。このオプションは、受信したDSNの接続レベルの確認応答（「データACK」）を運ぶこともできます。
With MPTCP, all subflows share the same receive buffer and advertise the same receive window. There are two levels of acknowledgment in MPTCP. Regular TCP acknowledgments are used on each subflow to acknowledge the reception of the segments sent over the subflow independently of their DSN. In addition, there are connection-level acknowledgments for the data sequence space. These acknowledgments track the advancement of the bytestream and slide the receive window.
MPTCPでは、すべてのサブフローが同じ受信バッファを共有し、同じ受信ウィンドウをアドバタイズします。 MPTCPには2つのレベルの確認応答があります。 DSNとは無関係にサブフローを介して送信されたセグメントの受信を確認するために、定期的なTCP確認応答が各サブフローで使用されます。さらに、データシーケンススペースに対する接続レベルの確認応答があります。これらの確認応答は、バイトストリームの進歩を追跡し、受信ウィンドウをスライドさせます。
Further details are given in Section 3.3.
詳細については、3.3節を参照してください。
Host A Host B
------ ------
DSS ->
[Data Sequence Mapping]
[Data ACK]
[Checksum]
Hosts can indicate at initial subflow setup whether they wish the subflow to be used as a regular or backup path -- a backup path only being used if there are no regular paths available. During a connection, Host A can request a change in the priority of a subflow through the MP_PRIO signal to Host B. Further details are given in Section 3.3.8.
ホストは、サブフローの初期設定時に、サブフローを通常のパスとして使用するか、バックアップパスとして使用するかを指定できます。バックアップパスは、使用可能な通常のパスがない場合にのみ使用されます。接続中に、ホストAはMP_PRIO信号を介してホストBへのサブフローの優先度の変更を要求できます。詳細については、3.3.8項を参照してください。
Host A Host B
------ ------
MP_PRIO ->
When a host wants to close an existing subflow but not the whole connection, it can initiate a regular TCP FIN/ACK exchange.
ホストが接続全体ではなく既存のサブフローを閉じたい場合、通常のTCP FIN / ACK交換を開始できます。
When Host A wants to inform Host B that it has no more data to send, it signals this "Data FIN" as part of the DSS (see above). It has the same semantics and behavior as a regular TCP FIN, but at the connection level. Once all the data on the MPTCP connection has been successfully received, this message is acknowledged at the connection level with a Data ACK. Further details are given in Section 3.3.3.
ホストAがホストBに送信するデータがないことを通知する場合、ホストAはこの「データFIN」をDSSの一部として通知します（上記を参照）。通常のTCP FINと同じセマンティクスと動作を持っていますが、接続レベルです。 MPTCP接続のすべてのデータが正常に受信されると、このメッセージはデータACKで接続レベルで確認されます。詳細はセクション3.3.3に記載されています。
Host A Host B
------ ------
DSS ->
[Data FIN]
<- DSS
[Data ACK]
There is an additional method of connection closure, referred to as "Fast Close", which is analogous to closing a single-path TCP connection with a RST signal. The MP_FASTCLOSE signal is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. This can be used on an ACK (which ensures reliability of the signal) or a RST (which does not). Both examples are shown in the following diagrams. Further details are given in Section 3.5.
「ファストクローズ」と呼ばれる接続クローズの追加の方法があります。これは、RST信号を使用したシングルパスTCP接続のクローズに類似しています。 MP_FASTCLOSE信号は、接続が突然閉じられ、データが受け入れられなくなることをピアに示すために使用されます。これは、ACK（信号の信頼性を保証する）またはRST（そうしない）で使用できます。次の図に両方の例を示します。詳細はセクション3.5に記載されています。
Host A Host B
------ ------
ACK + MP_FASTCLOSE ->
[B's key]
[RST on all other subflows] ->
[他のすべてのサブフローのRST]->
<- [RST on all subflows]
<-[すべてのサブフローでRST]
Host A Host B
------ ------
RST + MP_FASTCLOSE ->
[B's key] [on all subflows]
<- [RST on all subflows]
<-[すべてのサブフローでRST]
It is worth highlighting that MPTCP's signaling has been designed with several key requirements in mind:
MPTCPのシグナリングがいくつかの重要な要件を念頭に置いて設計されていることを強調する価値があります。
* To cope with NATs on the path, addresses are referred to by Address IDs, in case the IP packet's source address gets changed by a NAT. Setting up a new TCP flow is not possible if the receiver of the SYN is behind a NAT; to allow subflows to be created when either end is behind a NAT, MPTCP uses the ADD_ADDR message.
* パス上のNATに対処するため、NATによってIPパケットの送信元アドレスが変更された場合に備えて、アドレスはアドレスIDによって参照されます。 SYNの受信側がNATの背後にある場合、新しいTCPフローを設定することはできません。どちらかの端がNATの背後にあるときにサブフローを作成できるようにするために、MPTCPはADD_ADDRメッセージを使用します。
* MPTCP falls back to ordinary TCP if MPTCP operation is not possible -- for example, if one host is not MPTCP capable or if a middlebox alters the payload. This is discussed in Section 3.7.
* MPTCP操作が不可能な場合、たとえば、1つのホストがMPTCPに対応していない場合や、ミドルボックスがペイロードを変更した場合、MPTCPは通常のTCPにフォールバックします。これについては、セクション3.7で説明します。
* To address the threats identified in [RFC6181], the following steps are taken: keys are sent in the clear in the MP_CAPABLE messages; MP_JOIN messages are secured with HMAC-SHA256 ([RFC2104] using the algorithm in [RFC6234]) using those keys; and standard TCP validity checks are made on the other messages (ensuring that sequence numbers are in-window [RFC5961]). Residual threats to MPTCP v0 were identified in [RFC7430], and those affecting the protocol (i.e., modifications to ADD_ADDR) have been incorporated in this document. Further discussion of security can be found in Section 5.
* [RFC6181]で特定された脅威に対処するために、次の手順が実行されます。キーは、MP_CAPABLEメッセージで平文で送信されます。 MP_JOINメッセージは、これらのキーを使用するHMAC-SHA256（[RFC6234]のアルゴリズムを使用する[RFC2104]）で保護されています。他のメッセージに対して標準のTCP妥当性チェックが行われます（シーケンス番号がウィンドウ内にあることを確認します[RFC5961]）。 MPTCP v0に対する残りの脅威は[RFC7430]で特定されており、プロトコルに影響を与える脅威（つまり、ADD_ADDRへの変更）がこのドキュメントに組み込まれています。セキュリティの詳細については、セクション5を参照してください。
This section describes the operation of MPTCP. The subsections below discuss each key part of the protocol operation.
このセクションでは、MPTCPの操作について説明します。以下のサブセクションでは、プロトコル操作の各主要部分について説明します。
All MPTCP operations are signaled using optional TCP header fields. A single TCP option number ("Kind") has been assigned by IANA for MPTCP (see Section 7), and then individual messages will be determined by a "subtype", the values of which are also stored in an IANA registry (and are also listed in Section 7). As with all TCP options, the Length field is specified in bytes and includes the 2 bytes of Kind and Length.
すべてのMPTCP操作は、オプションのTCPヘッダーフィールドを使用して通知されます。単一のTCPオプション番号（「種類」）がITCPによってMPTCP（セクション7を参照）に割り当てられており、個々のメッセージは「サブタイプ」によって決定され、その値もIANAレジストリに格納されます（およびセクション7にも記載されています。すべてのTCPオプションと同様に、長さフィールドはバイト単位で指定され、種類と長さの2バイトが含まれます。
Throughout this document, when reference is made to an MPTCP option by symbolic name, such as "MP_CAPABLE", this refers to a TCP option with the single MPTCP option type, and with the subtype value of the symbolic name as defined in Section 7. This subtype is a 4-bit field -- the first 4 bits of the option payload, as shown in Figure 3. The MPTCP messages are defined in the following sections.
このドキュメント全体を通して、「MP_CAPABLE」などのシンボリック名でMPTCPオプションを参照する場合、これは、1つのMPTCPオプションタイプと、セクション7で定義されているシンボリック名のサブタイプ値を持つTCPオプションを指します。このサブタイプは4ビットのフィールドです。図3に示すように、オプションペイロードの最初の4ビットです。MPTCPメッセージは次のセクションで定義されています。
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
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| |
+---------------+---------------+-------+ |
| Subtype-specific data |
| (variable length) |
+---------------------------------------------------------------+
Figure 3: MPTCP Option Format
図3：MPTCPオプションの形式
Those MPTCP options associated with subflow initiation are used on packets with the SYN flag set. Additionally, there is one MPTCP option for signaling metadata to ensure that segmented data can be recombined for delivery to the application.
サブフローの開始に関連するMPTCPオプションは、SYNフラグが設定されたパケットで使用されます。さらに、メタデータをシグナリングするための1つのMPTCPオプションがあり、セグメント化されたデータを確実に再結合してアプリケーションに配信できます。
The remaining options, however, are signals that do not need to be on a specific packet, such as those for signaling additional addresses. While an implementation may desire to send MPTCP options as soon as possible, it may not be possible to combine all desired options (both those for MPTCP and for regular TCP, such as SACK (selective acknowledgment) [RFC2018]) on a single packet. Therefore, an implementation may choose to send duplicate ACKs containing the additional signaling information. This changes the semantics of a duplicate ACK; these are usually only sent as a signal of a lost segment [RFC5681] in regular TCP. Therefore, an MPTCP implementation receiving a duplicate ACK that contains an MPTCP option MUST NOT treat it as a signal of congestion. Additionally, an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for the purposes of sending MPTCP options alone, in order to ensure that no middleboxes misinterpret this as a sign of congestion.
ただし、残りのオプションは、追加のアドレスをシグナリングするためのものなど、特定のパケット上にある必要がない信号です。実装はできるだけ早くMPTCPオプションを送信することを望む場合がありますが、単一のパケットですべての必要なオプション（MPTCPのオプションとSACK（選択的確認応答）[RFC2018]などの通常のTCPのオプション）を組み合わせることができない場合があります。したがって、実装は、追加のシグナリング情報を含む重複したACKを送信することを選択できます。これにより、重複するACKのセマンティクスが変更されます。これらは通常、通常のTCPで失われたセグメント[RFC5681]の信号としてのみ送信されます。したがって、MPTCPオプションを含む重複ACKを受信するMPTCP実装は、それを輻輳の信号として処理してはなりません（MUST NOT）。さらに、ミドルボックスがこれを輻輳の兆候と誤って解釈しないようにするために、MPTCP実装は、MPTCPオプションのみを送信する目的で、2つ以上の重複したACKを続けて送信しないでください。
Furthermore, standard TCP validity checks (such as ensuring that the sequence number and acknowledgment number are within the window) MUST be undertaken before processing any MPTCP signals, as described in [RFC5961], and initial subflow sequence numbers SHOULD be generated according to the recommendations in [RFC6528].
さらに、標準のTCP有効性チェック（シーケンス番号と確認応答番号がウィンドウ内にあることの確認など）は、[RFC5961]で説明されているように、MPTCPシグナルを処理する前に実行する必要があり、推奨に従って初期サブフローシーケンス番号を生成する必要があります（SHOULD） [RFC6528]。
Connection initiation begins with a SYN, SYN/ACK, ACK exchange on a single path. Each packet contains the Multipath Capable (MP_CAPABLE) MPTCP option (Figure 4). This option declares its sender capable of performing Multipath TCP and wishes to do so on this particular connection.
接続の開始は、単一パスでのSYN、SYN / ACK、ACK交換で始まります。各パケットには、マルチパス対応（MP_CAPABLE）MPTCPオプションが含まれています（図4）。このオプションは、マルチパスTCPを実行できる送信者を宣言し、この特定の接続で実行することを望んでいます。
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
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype|Version|A|B|C|D|E|F|G|H|
+---------------+---------------+-------+-------+---------------+
| Option Sender's Key (64 bits) |
| (if option Length > 4) |
| |
+---------------------------------------------------------------+
| Option Receiver's Key (64 bits) |
| (if option Length > 12) |
| |
+-------------------------------+-------------------------------+
| Data-Level Length (16 bits) | Checksum (16 bits, optional) |
+-------------------------------+-------------------------------+
Figure 4: Multipath Capable (MP_CAPABLE) Option
図4：マルチパス対応（MP_CAPABLE）オプション
The MP_CAPABLE exchange in this specification (v1) is different than that specified in v0. If a host supports multiple versions of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the highest version number it supports. In return, in its MP_CAPABLE option, the receiver will signal the version number it wishes to use, which MUST be equal to or lower than the version number indicated in the initial MP_CAPABLE. There is a caveat, though, with respect to this version negotiation with old listeners that only support v0. A listener that supports v0 expects that the MP_CAPABLE option in the SYN segment will include the initiator's key. If, however, the initiator already upgraded to v1, it won't include the key in the SYN segment. Thus, the listener will ignore the MP_CAPABLE of this SYN segment and reply with a SYN/ACK that does not include an MP_CAPABLE. The initiator MAY choose to immediately fall back to TCP or MAY choose to attempt a connection using MPTCP v0 (if the initiator supports v0), in order to discover whether the listener supports the earlier version of MPTCP. In general, an MPTCP v0 connection will likely be preferred over a TCP connection; however, in a particular deployment scenario, it may be known that the listener is unlikely to support MPTCP v0 and so the initiator may prefer not to attempt a v0 connection. An initiator MAY cache information for a peer about what version of MPTCP it supports, if any, and use this information for future connection attempts.
この仕様（v1）のMP_CAPABLE交換は、v0で指定されたものとは異なります。ホストが複数のバージョンのMPTCPをサポートする場合、MP_CAPABLEオプションの送信者は、サポートする最大のバージョン番号を通知する必要があります（SHOULD）。代わりに、そのMP_CAPABLEオプションで、レシーバーは使用したいバージョン番号を通知します。これは、最初のMP_CAPABLEで示されたバージョン番号以下でなければなりません（MUST）。ただし、v0のみをサポートする古いリスナーとのこのバージョンのネゴシエーションに関しては注意が必要です。 v0をサポートするリスナーは、SYNセグメントのMP_CAPABLEオプションにイニシエーターのキーが含まれることを期待しています。ただし、イニシエーターが既にv1にアップグレードされている場合、SYNセグメントにキーは含まれません。したがって、リスナーはこのSYNセグメントのMP_CAPABLEを無視し、MP_CAPABLEを含まないSYN / ACKで応答します。イニシエーターは、リスナーが以前のバージョンのMPTCPをサポートしているかどうかを検出するために、すぐにTCPにフォールバックするか、またはMPTCP v0（イニシエーターがv0をサポートしている場合）を使用して接続を試みることを選択する場合があります。一般に、MPTCP v0接続はTCP接続よりも優先される可能性があります。ただし、特定の展開シナリオでは、リスナーがMPTCP v0をサポートする可能性が低いことがわかっているため、イニシエーターがv0接続を試行しないことを選択する場合があります。イニシエーターは、ピアがサポートしているMPTCPのバージョン（ある場合）に関する情報をキャッシュし、今後の接続試行にこの情報を使用できます（MAY）。
The MP_CAPABLE option is of variable length, with different fields included, depending on which packet the option is used on. The full MP_CAPABLE option is shown in Figure 4.
MP_CAPABLEオプションは可変長であり、オプションが使用されるパケットに応じて異なるフィールドが含まれます。完全なMP_CAPABLEオプションを図4に示します。
The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets that start the first subflow of an MPTCP connection, as well as the first packet that carries data, if the initiator wishes to send first. The data carried by each option is as follows, where A = initiator and B = listener.
MP_CAPABLEオプションは、MPTCP接続の最初のサブフローを開始するSYN、SYN / ACK、およびACKパケットと、イニシエーターが最初に送信したい場合にデータを運ぶ最初のパケットで運ばれます。各オプションで伝送されるデータは次のとおりです。ここで、A =イニシエーターおよびB =リスナーです。
* SYN (A->B): only the first 4 octets (Length = 4).
* SYN（A-> B）：最初の4オクテットのみ（長さ= 4）。
* SYN/ACK (B->A): B's key for this connection (Length = 12).
* SYN / ACK（B-> A）：この接続のBのキー（長さ= 12）。
* ACK (no data) (A->B): A's key followed by B's key (Length = 20).
* ACK（データなし）（A-> B）：Aのキーの後にBのキー（長さ= 20）。
* ACK (with first data) (A->B): A's key followed by B's key followed by Data-Level Length, and optional Checksum (Length = 22 or 24).
* ACK（最初のデータあり）（A-> B）：Aのキー、Bのキー、データレベルの長さ、オプションのチェックサム（長さ= 22または24）。
The contents of the option are determined by the SYN and ACK flags of the packet, along with the option's Length field. In Figure 4, "Sender" and "Receiver" refer to the sender or receiver of the TCP packet (which can be either host).
オプションの内容は、オプションの長さフィールドと共に、パケットのSYNおよびACKフラグによって決定されます。図4の「送信者」と「受信者」は、TCPパケットの送信者または受信者（どちらのホストでもかまいません）を指します。
The initial SYN, containing just the MP_CAPABLE header, is used to define the version of MPTCP being requested and also to exchange flags to negotiate connection features, as described later.
MP_CAPABLEヘッダーのみを含む最初のSYNを使用して、要求されるMPTCPのバージョンを定義し、フラグを交換して、後で説明するように接続機能をネゴシエートします。
This option is used to declare the 64-bit keys that the end hosts have generated for this MPTCP connection. These keys are used to authenticate the addition of future subflows to this connection. This is the only time the key will be sent in the clear on the wire (unless "Fast Close" (Section 3.5) is used); all future subflows will identify the connection using a 32-bit "token". This token is a cryptographic hash of this key. The algorithm for this process is dependent on the authentication algorithm selected; the method of selection is defined later in this section.
このオプションは、エンドホストがこのMPTCP接続用に生成した64ビットキーを宣言するために使用されます。これらの鍵は、この接続への将来のサブフローの追加を認証するために使用されます。鍵が平文で送信されるのはこのときだけです（「Fast Close」（セクション3.5）が使用されている場合を除く）。今後のすべてのサブフローは、32ビットの「トークン」を使用して接続を識別します。このトークンは、このキーの暗号化ハッシュです。このプロセスのアルゴリズムは、選択した認証アルゴリズムによって異なります。選択方法は、このセクションの後半で定義されています。
Upon reception of the initial SYN segment, a stateful server generates a random key and replies with a SYN/ACK. The key's method of generation is implementation specific. The key MUST be hard to guess, and it MUST be unique for the sending host across all its current MPTCP connections. Recommendations for generating random numbers for use in keys are given in [RFC4086]. Connections will be indexed at each host by the token (a one-way hash of the key). Therefore, an implementation will require a mapping from each token to the corresponding connection, and in turn to the keys for the connection.
最初のSYNセグメントを受信すると、ステートフルサーバーはランダムなキーを生成し、SYN / ACKで応答します。キーの生成方法は実装固有です。キーは推測が困難でなければならず、現在のすべてのMPTCP接続で送信側ホストに対して一意である必要があります。キーで使用する乱数を生成するための推奨事項は、[RFC4086]で提供されています。接続は、各ホストでトークン（キーの一方向ハッシュ）によってインデックスが作成されます。したがって、実装では、各トークンから対応する接続へ、そして接続のキーへのマッピングが必要になります。
There is a risk that two different keys will hash to the same token. The risk of hash collisions is usually small, unless the host is handling many tens of thousands of connections. Therefore, an implementation SHOULD check its list of connection tokens to ensure that there is no collision before sending its key, and if there is, then it should generate a new key. This would, however, be costly for a server with thousands of connections. The subflow handshake mechanism (Section 3.2) will ensure that new subflows only join the correct connection, however, through the cryptographic handshake, as well as checking the connection tokens in both directions, and ensuring that sequence numbers are in-window. So, in the worst case, if there was a token collision, the new subflow would not succeed, but the MPTCP connection would continue to provide a regular TCP service.
2つの異なるキーが同じトークンにハッシュされるリスクがあります。ホストが何万もの接続を処理していない限り、ハッシュの衝突のリスクは通常小さいです。したがって、実装はその接続トークンのリストをチェックして、キーを送信する前に衝突がないことを確認する必要があります。衝突がある場合は、新しいキーを生成する必要があります。ただし、これは何千もの接続を持つサーバーにとってはコストがかかります。サブフローハンドシェイクメカニズム（セクション3.2）は、新しいサブフローが正しい接続に参加することを保証します。ただし、暗号化ハンドシェイクを介して、双方向の接続トークンをチェックし、シーケンス番号がウィンドウ内にあることを確認します。したがって、最悪の場合、トークンの衝突があった場合、新しいサブフローは成功しませんが、MPTCP接続は通常のTCPサービスを提供し続けます。
Since key generation is implementation specific, there is no requirement that they simply be random numbers. An implementation is free to exchange cryptographic material out of band and generate these keys from this material, in order to provide additional mechanisms by which to verify the identity of the communicating entities. For example, an implementation could choose to link its MPTCP keys to those used in higher-layer TLS or SSH connections.
キーの生成は実装固有であるため、単に乱数である必要はありません。実装は、通信エンティティのIDを検証するための追加のメカニズムを提供するために、帯域外の暗号素材を自由に交換し、この素材からこれらの鍵を生成できます。たとえば、実装では、MPTCPキーを上位層のTLSまたはSSH接続で使用されるものにリンクすることを選択できます。
If the server behaves in a stateless manner, it has to generate its own key in a verifiable fashion. This verifiable way of generating the key can be done by using a hash of the 4-tuple, sequence number, and a local secret (similar to what is done for the TCP sequence number [RFC4987]). It will thus be able to verify whether it is indeed the originator of the key echoed back in the subsequent MP_CAPABLE option. As for a stateful server, the tokens SHOULD be checked for uniqueness; however, if uniqueness is not met and there is no way to generate an alternative verifiable key, then the connection MUST fall back to using regular TCP by not sending an MP_CAPABLE in the SYN/ACK.
サーバーがステートレスな方法で動作する場合、サーバーは検証可能な方法で独自のキーを生成する必要があります。鍵を生成するこの検証可能な方法は、4タプルのハッシュ、シーケンス番号、およびローカルシークレットを使用して行うことができます（TCPシーケンス番号[RFC4987]に対して行われるものと同様）。したがって、それが実際に、後続のMP_CAPABLEオプションでエコーバックされたキーの発信者であるかどうかを確認できます。ステートフルサーバーの場合、トークンの一意性を確認する必要があります。ただし、一意性が満たされておらず、検証可能な代替キーを生成する方法がない場合は、SYN / ACKでMP_CAPABLEを送信しないことにより、接続は通常のTCPの使用にフォールバックする必要があります。
The ACK carries both A's key and B's key. This is the first time that A's key is seen on the wire, although it is expected that A will have generated a key locally before the initial SYN. The echoing of B's key allows B to operate statelessly, as described above. Therefore, A's key must be delivered reliably to B, and in order to do this, the transmission of this packet must be made reliable.
ACKはAのキーとBのキーの両方を伝送します。 Aが最初のSYNの前にローカルでキーを生成すると予想されますが、これはAのキーがネットワーク上で見られるのは初めてです。 Bのキーのエコーにより、Bは上記のようにステートレスに動作できます。したがって、Aの鍵は確実にBに配信される必要があり、これを行うには、このパケットの送信の信頼性を高める必要があります。
If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space). If, however, A wishes to send data first, it has two options to ensure the reliable delivery of the ACK + MP_CAPABLE. If it immediately has data to send, then the first ACK (with data) would also contain an MP_CAPABLE option with additional data parameters (the Data-Level Length and optional Checksum as shown in Figure 4). If A does not immediately have data to send, it MUST include the MP_CAPABLE on the first ACK, but without the additional data parameters. When A does have data to send, it must repeat the sending of the MP_CAPABLE option from the first ACK, with additional data parameters. This MP_CAPABLE option is used in place of the DSS and simply specifies (1) the Data-Level Length of the payload and (2) the checksum (if the use of checksums is negotiated). This is the minimal data required to establish an MPTCP connection -- it allows validation of the payload, and given that it is the first data, the Initial Data Sequence Number (IDSN) is also known (as it is generated from the key, as described below). Conveying the keys on the first data packet allows the TCP reliability mechanisms to ensure that the packet is successfully delivered. The receiver will acknowledge this data at the connection level with a Data ACK, as if a DSS option has been received.
Bが最初に送信するデータを持っている場合、ACK_MP_CAPABLEの信頼できる配信は、MP_CAPABLEのDATA_ACKを含むMPTCPデータシーケンス信号（DSS）オプション（セクション3.3）でこのデータを受信することによって保証されます（これが最初です）。データシーケンススペースのオクテット）。ただし、Aが最初にデータを送信したい場合は、ACK + MP_CAPABLEを確実に配信するために2つのオプションがあります。送信するデータがすぐにある場合、最初のACK（データあり）には、追加のデータパラメーター（図4に示すように、データレベルの長さとオプションのチェックサム）を持つMP_CAPABLEオプションも含まれます。 Aがすぐに送信するデータを持たない場合、最初のACKにMP_CAPABLEを含める必要がありますが、追加のデータパラメータは必要ありません。 Aに送信するデータがある場合、追加のデータパラメータを使用して、最初のACKからMP_CAPABLEオプションの送信を繰り返す必要があります。このMP_CAPABLEオプションはDSSの代わりに使用され、（1）ペイロードのデータレベルの長さと（2）チェックサム（チェックサムの使用がネゴシエートされている場合）を指定するだけです。これは、MPTCP接続を確立するために必要な最小限のデータです。これにより、ペイロードの検証が可能になり、最初のデータであることから、初期データシーケンス番号（IDSN）もわかります（キーから生成されるため、以下で説明します）。最初のデータパケットでキーを伝達することにより、TCP信頼性メカニズムは、パケットが確実に正常に配信されるようにします。受信側は、DSSオプションが受信されたかのように、接続レベルでデータACKを使用してこのデータを確認します。
There could be situations where both A and B attempt to transmit initial data at the same time. For example, if A did not initially have data to send but then needed to transmit data before it had received anything from B, it would use an MP_CAPABLE option with data parameters (since it would not know if the MP_CAPABLE on the ACK was received). In such a situation, B may also have transmitted data with a DSS option, but it had not yet been received at A. Therefore, B has received data with an MP_CAPABLE mapping after it has sent data with a DSS option. To ensure that these situations can be handled, it follows that the data parameters in an MP_CAPABLE are semantically equivalent to those in a DSS option and can be used interchangeably. Similar situations could occur when the MP_CAPABLE with data is lost and retransmitted. Furthermore, in the case of TCP segmentation offloading, the MP_CAPABLE with data parameters may be duplicated across multiple packets, and implementations must also be able to cope with duplicate MP_CAPABLE mappings as well as duplicate DSS mappings.
AとBの両方が同時に初期データを送信しようとする状況が発生する可能性があります。たとえば、Aには最初に送信するデータがなかったが、Bから何かを受信する前にデータを送信する必要があった場合、データパラメータを指定したMP_CAPABLEオプションを使用します（ACKのMP_CAPABLEが受信されたかどうかがわからないため）。 。このような状況では、BもDSSオプションでデータを送信した可能性がありますが、Aでまだ受信されていません。したがって、BはDSSオプションでデータを送信した後、MP_CAPABLEマッピングでデータを受信しました。これらの状況を確実に処理できるようにするために、MP_CAPABLEのデータパラメータは意味的にDSSオプションのデータパラメータと同等であり、互換的に使用できます。データを含むMP_CAPABLEが失われ、再送信された場合も、同様の状況が発生する可能性があります。さらに、TCPセグメンテーションオフロードの場合、データパラメータ付きのMP_CAPABLEは複数のパケット間で重複する可能性があり、実装は重複したMP_CAPABLEマッピングと重複したDSSマッピングにも対応できる必要があります。
Additionally, the MP_CAPABLE exchange allows the safe passage of MPTCP options on SYN packets to be determined. If any of these options are dropped, MPTCP will gracefully fall back to regular single-path TCP, as documented in Section 3.7. If at any point in the handshake either party thinks the MPTCP negotiation is compromised -- for example, by a middlebox corrupting the TCP options or by unexpected ACK numbers being present -- the host MUST stop using MPTCP and no longer include MPTCP options in future TCP packets. The other host will then also fall back to regular TCP using the fallback mechanism. Note that new subflows MUST NOT be established (using the process documented in Section 3.2) until a DSS option has been successfully received across the path (as documented in Section 3.3).
さらに、MP_CAPABLE交換により、SYNパケットのMPTCPオプションを安全に通過させることができます。これらのオプションのいずれかが削除された場合、セクション3.7に記載されているように、MPTCPは通常の単一パスTCPに正常にフォールバックします。ハンドシェイクのいずれかの時点で、いずれかの当事者がMPTCPネゴシエーションが侵害されていると考えた場合（たとえば、ミドルボックスがTCPオプションを破損したり、予期しないACK番号が存在したりした場合）、ホストはMPTCPの使用を停止し、今後MPTCPオプションを含めないようにする必要がありますTCPパケット。他のホストも、フォールバックメカニズムを使用して通常のTCPにフォールバックします。 （セクション3.3に記載されているように）パス全体でDSSオプションが正常に受信されるまで、（サブセクション3.2に記載されているプロセスを使用して）新しいサブフローを確立してはならないことに注意してください。
Like all MPTCP options, the MP_CAPABLE option starts with the Kind and Length to specify the TCP option's kind and length. This information is followed by the MP_CAPABLE option. The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP Option Subtype (see Section 7; for MP_CAPABLE, this value is 0x0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this value is 1).
すべてのMPTCPオプションと同様に、MP_CAPABLEオプションは、TCPオプションの種類と長さを指定するKindおよびLengthで始まります。この情報の後にMP_CAPABLEオプションが続きます。 MP_CAPABLEオプション（図4）の最初のオクテットの最初の4ビットはMPTCPオプションサブタイプを定義し（セクション7を参照。MP_CAPABLEの場合、この値は0x0です）、このオクテットの残りの4ビットは使用中のMPTCPバージョンを指定します（この仕様の場合、この値は1）です。
The second octet is reserved for flags, allocated as follows:
2番目のオクテットはフラグ用に予約されており、次のように割り当てられます。
A: The leftmost bit, labeled "A", SHOULD be set to 1 to indicate "Checksum required", unless the system administrator has decided that checksums are not required (for example, if the environment is controlled and no middleboxes exist that might adjust the payload).
A：「A」というラベルの付いた左端のビットは、チェックサムが不要であるとシステム管理者が判断しない限り（たとえば、環境が制御されていて、調整される可能性のあるミドルボックスが存在しない場合）、1に設定して「チェックサムが必要」であることを示す必要があります。ペイロード）。
B: The second bit, labeled "B", is an extensibility flag. It MUST be set to 0 for current implementations. This flag will be used for an extensibility mechanism in a future specification, and the impact of this flag will be defined at a later date. It is expected, but not mandated, that this flag would be used as part of an alternative security mechanism that does not require a full version upgrade of the protocol but does require redefining some elements of the handshake. If receiving a message with the "B" flag set to 1 and this is not understood, then the MP_CAPABLE in this SYN MUST be silently ignored, which triggers a fallback to regular TCP; the sender is expected to retry with a format compatible with this legacy specification. Note that the length of the MP_CAPABLE option, and the meanings of bits "D" through "H", may be altered by setting B=1.
B：「B」というラベルが付いた2番目のビットは、拡張性フラグです。現在の実装では、0に設定する必要があります。このフラグは将来の仕様で拡張メカニズムに使用され、このフラグの影響は後日定義されます。このフラグは、プロトコルの完全なバージョンアップグレードを必要としないが、ハンドシェイクの一部の要素を再定義する必要がある代替のセキュリティメカニズムの一部として使用されることが期待されますが、必須ではありません。 「B」フラグが1に設定されたメッセージを受信し、これが理解されない場合、このSYNのMP_CAPABLEは黙って無視されなければならず（MUST）、通常のTCPへのフォールバックをトリガーします。送信者は、このレガシー仕様と互換性のあるフォーマットで再試行することが期待されています。 MP_CAPABLEオプションの長さ、およびビット "D"から "H"の意味は、B = 1を設定することによって変更できることに注意してください。
C: The third bit, labeled "C", is set to 1 to indicate that the sender of this option will not accept additional MPTCP subflows to the source address and port, and therefore the receiver MUST NOT try to open any additional subflows toward this address and port. This improves efficiency in situations where the sender knows a restriction is in place -- for example, if the sender is behind a strict NAT or operating behind a legacy Layer 4 load balancer.
C：「C」というラベルの付いた3番目のビットは1に設定され、このオプションの送信者が送信元アドレスとポートへの追加のMPTCPサブフローを受け入れないことを示します。したがって、受信者はこれに向けて追加のサブフローを開かないでください。アドレスとポート。これにより、たとえば送信者が厳密なNATの背後にある場合や、レガシーレイヤー4ロードバランサーの背後で動作している場合など、送信者が制限があることを知っている状況で効率が向上します。
D through H: The remaining bits, labeled "D" through "H", are used for crypto algorithm negotiation. In this specification, only the rightmost bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC-SHA256 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1 and bits "D" through "G" to 0.
DからH：「D」から「H」のラベルが付いた残りのビットは、暗号アルゴリズムのネゴシエーションに使用されます。この仕様では、「H」というラベルの付いた右端のビットのみが割り当てられます。ビット「H」は、HMAC-SHA256の使用を示します（セクション3.2で定義）。このメソッドのみをサポートする実装では、ビット「H」を1に、ビット「D」から「G」を0に設定する必要があります。
A crypto algorithm MUST be specified. If flag bits "D" through "H" are all 0, the MP_CAPABLE option MUST be treated as invalid and ignored (that is, it must be treated as a regular TCP handshake).
暗号アルゴリズムを指定する必要があります。フラグビット "D"から "H"がすべて0の場合、MP_CAPABLEオプションは無効として扱われ、無視されなければなりません（つまり、通常のTCPハンドシェイクとして扱われなければなりません）。
The selection of the authentication algorithm also impacts the algorithm used to generate the token and the IDSN. In this specification, with only the SHA-256 algorithm (bit "H") specified and selected, the token MUST be a truncated (most significant 32 bits) SHA-256 hash [RFC6234] of the key. A different, 64-bit truncation (the least significant 64 bits) of the SHA-256 hash of the key MUST be used as the IDSN. Note that the key MUST be hashed in network byte order. Also note that the "least significant" bits MUST be the rightmost bits of the SHA-256 digest, as per [RFC6234]. Future specifications of the use of the crypto bits may choose to specify different algorithms for token and IDSN generation.
認証アルゴリズムの選択は、トークンとIDSNの生成に使用されるアルゴリズムにも影響します。この仕様では、SHA-256アルゴリズム（ビット "H"）のみが指定および選択されているため、トークンはキーの切り捨てられた（最上位32ビット）SHA-256ハッシュ[RFC6234]である必要があります。鍵のSHA-256ハッシュの別の64ビット切り捨て（最下位64ビット）をIDSNとして使用する必要があります。キーはネットワークバイトオーダーでハッシュされなければならないことに注意してください。 [RFC6234]のように、「最下位」ビットはSHA-256ダイジェストの右端のビットでなければならないことに注意してください。暗号ビットの使用に関する将来の仕様では、トークンとIDSNの生成に異なるアルゴリズムを指定することを選択する可能性があります。
Both the crypto and checksum bits negotiate capabilities in similar ways. For the "Checksum required" bit (labeled "A"), if either host requires the use of checksums, checksums MUST be used. In other words, the only way for checksums not to be used is if both hosts in their SYNs set A=0. This decision is confirmed by the setting of the "A" bit in the third packet (the ACK) of the handshake. For example, if the initiator sets A=0 in the SYN but the responder sets A=1 in the SYN/ACK, checksums MUST be used in both directions, and the initiator will set A=1 in the ACK. The decision regarding whether to use checksums will be stored by an implementation in a per-connection binary state variable. If A=1 is received by a host that does not want to use checksums, it MUST fall back to regular TCP by ignoring the MP_CAPABLE option as if it was invalid.
暗号ビットとチェックサムビットの両方が、同様の方法で機能をネゴシエートします。 「チェックサムが必要」ビット（「A」のラベルが付いている）の場合、いずれかのホストでチェックサムの使用が必要な場合は、チェックサムを使用する必要があります。つまり、チェックサムを使用しない唯一の方法は、SYN内の両方のホストがA = 0を設定する場合です。この決定は、ハンドシェイクの3番目のパケット（ACK）の「A」ビットの設定によって確認されます。たとえば、イニシエーターがSYNでA = 0を設定し、レスポンダーがSYN / ACKでA = 1を設定する場合、チェックサムを両方向で使用する必要があり、イニシエーターはACKでA = 1を設定します。チェックサムを使用するかどうかの決定は、接続ごとのバイナリ状態変数に実装によって格納されます。チェックサムを使用したくないホストがA = 1を受信した場合、MP_CAPABLEオプションを無効であるかのように無視して、通常のTCPにフォールバックする必要があります。
For crypto negotiation, the responder has the choice. The initiator creates a proposal setting a bit for each algorithm it supports to 1 (in this version of the specification, there is only one proposal, so bit "H" will always be set to 1). The responder responds with only 1 bit set -- this is the chosen algorithm. The rationale for this behavior is that the responder will typically be a server with potentially many thousands of connections, so it may wish to choose an algorithm with minimal computational complexity, depending on the load. If a responder does not support (or does not want to support) any of the initiator's proposals, it MUST respond without an MP_CAPABLE option, thus forcing a fallback to regular TCP.
暗号ネゴシエーションの場合、レスポンダが選択できます。イニシエーターは、サポートする各アルゴリズムのビットを1に設定する提案を作成します（このバージョンの仕様では、提案は1つしかないため、ビット "H"は常に1に設定されます）。レスポンダは1ビットセットだけで応答します。これが選択されたアルゴリズムです。この動作の理論的根拠は、レスポンダーは通常、何千もの接続を持つ可能性のあるサーバーであるため、負荷に応じて、計算の複雑さが最小限のアルゴリズムを選択することです。レスポンダがイニシエータの提案をサポートしない（またはサポートしたくない）場合は、MP_CAPABLEオプションなしで応答する必要があるため、通常のTCPへのフォールバックが強制されます。
The MP_CAPABLE option is only used in the first subflow of a connection, in order to identify the connection; all subsequent subflows will use the MP_JOIN option (see Section 3.2) to join the existing connection.
MP_CAPABLEオプションは、接続を識別するために、接続の最初のサブフローでのみ使用されます。後続のすべてのサブフローは、MP_JOINオプション（セクション3.2を参照）を使用して既存の接続に参加します。
If a SYN contains an MP_CAPABLE option but the SYN/ACK does not, it is assumed that the sender of the SYN/ACK is not multipath capable; thus, the MPTCP session MUST operate as a regular, single-path TCP session. If a SYN does not contain an MP_CAPABLE option, the SYN/ACK MUST NOT contain one in response. If the third packet (the ACK) does not contain the MP_CAPABLE option, then the session MUST fall back to operating as a regular, single-path TCP session. This is done to maintain compatibility with middleboxes on the path that drop some or all TCP options. Note that an implementation MAY choose to attempt sending MPTCP options more than one time before making this decision to operate as regular TCP (see Section 3.9).
SYNにMP_CAPABLEオプションが含まれているが、SYN / ACKには含まれていない場合、SYN / ACKの送信側はマルチパスに対応していないと見なされます。したがって、MPTCPセッションは、通常の単一パスTCPセッションとして動作する必要があります。 SYNにMP_CAPABLEオプションが含まれていない場合、SYN / ACKは応答でオプションを含んではいけません（MUST NOT）。 3番目のパケット（ACK）にMP_CAPABLEオプションが含まれていない場合、セッションは通常の単一パスTCPセッションとして動作するようにフォールバックする必要があります。これは、一部またはすべてのTCPオプションをドロップするパス上のミドルボックスとの互換性を維持するために行われます。実装は、通常のTCPとして動作することを決定する前に、MPTCPオプションの送信を複数回試みることを選択してもよいことに注意してください（セクション3.9を参照）。
If the SYN packets are unacknowledged, it is up to local policy to decide how to respond. It is expected that a sender will eventually fall back to single-path TCP (i.e., without the MP_CAPABLE option) in order to work around middleboxes that may drop packets with unknown options; however, the number of multipath-capable attempts that are made first will be up to local policy. It is possible that MPTCP and non-MPTCP SYNs could get reordered in the network. Therefore, the final state is inferred from the presence or absence of the MP_CAPABLE option in the third packet of the TCP handshake. If this option is not present, the connection SHOULD fall back to regular TCP, as documented in Section 3.7.
SYNパケットが未確認の場合、応答方法を決定するのはローカルポリシー次第です。不明なオプションでパケットをドロップする可能性のあるミドルボックスを回避するために、送信者は最終的にシングルパスTCP（つまり、MP_CAPABLEオプションなし）にフォールバックすることが予想されます。ただし、最初に行われるマルチパス対応の試行回数は、ローカルポリシー次第です。 MPTCPと非MPTCP SYNがネットワークで並べ替えられる可能性があります。したがって、最終的な状態は、TCPハンドシェイクの3番目のパケット内のMP_CAPABLEオプションの有無から推測されます。このオプションが存在しない場合、セクション3.7で説明されているように、接続は通常のTCPにフォールバックする必要があります（SHOULD）。
The IDSN on an MPTCP connection is generated from the key. The algorithm for IDSN generation is also determined from the negotiated authentication algorithm. In this specification, with only the SHA-256 algorithm specified and selected, the IDSN of a host MUST be the least significant 64 bits of the SHA-256 hash of its key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). This deterministic generation of the IDSN allows a receiver to ensure that there are no gaps in sequence space at the start of the connection. The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
MPTCP接続のIDSNはキーから生成されます。 IDSN生成のアルゴリズムも、ネゴシエートされた認証アルゴリズムから決定されます。この仕様では、SHA-256アルゴリズムのみが指定および選択されているため、ホストのIDSNは、そのキーのSHA-256ハッシュの最下位64ビットである必要があります。つまり、IDSN-A = Hash（Key-A）およびIDSN-B = Hash（Key-B）。 IDSNのこの確定的な生成により、受信者は、接続の開始時にシーケンススペースにギャップがないことを確認できます。 MP_CAPABLEを指定したSYNは、データシーケンススペースの最初のオクテットを占有しますが、最初のデータが送信されるまで接続レベルで確認応答する必要はありません（セクション3.3を参照）。
Once an MPTCP connection has begun with the MP_CAPABLE exchange, further subflows can be added to the connection. Hosts have knowledge of their own address(es) and can become aware of the other host's addresses through signaling exchanges as described in Section 3.4. Using this knowledge, a host can initiate a new subflow over a currently unused pair of addresses. It is permissible for either host in a connection to initiate the creation of a new subflow, but it is expected that this will normally be the original connection initiator (see Section 3.9 for heuristics).
MP_CAPABLE交換でMPTCP接続が開始されると、さらにサブフローを接続に追加できます。ホストは自身のアドレスを知っており、3.4節で説明されているように、信号交換を通じて他のホストのアドレスを知ることができます。この知識を使用して、ホストは現在未使用のアドレスのペアに対して新しいサブフローを開始できます。接続内のどちらのホストでも新しいサブフローの作成を開始することは許可されていますが、これは通常、元の接続イニシエーターであることが予想されます（ヒューリスティックについてはセクション3.9を参照）。
A new subflow is started as a normal TCP SYN/ACK exchange. The Join Connection (MP_JOIN) MPTCP option is used to identify the connection to be joined by the new subflow. It uses keying material that was exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that handshake also negotiates the crypto algorithm in use for the MP_JOIN handshake.
新しいサブフローは、通常のTCP SYN / ACK交換として開始されます。結合の接続（MP_JOIN）MPTCPオプションは、新しいサブフローによって結合される接続を識別するために使用されます。最初のMP_CAPABLEハンドシェイク（セクション3.1）で交換されたキー生成情報を使用し、そのハンドシェイクはMP_JOINハンドシェイクに使用されている暗号アルゴリズムもネゴシエートします。
This section specifies the behavior of MP_JOIN using the HMAC-SHA256 algorithm. An MP_JOIN option is present in the SYN, SYN/ACK, and ACK of the three-way handshake, although in each case with a different format.
このセクションでは、HMAC-SHA256アルゴリズムを使用したMP_JOINの動作を指定します。 MP_JOINオプションは、スリーウェイハンドシェイクのSYN、SYN / ACK、およびACKにありますが、どちらの場合もフォーマットは異なります。
In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the initiator sends a token, random number, and Address ID.
図5に示すように、SYNパケットの最初のMP_JOINでは、イニシエーターがトークン、乱数、およびアドレス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
+---------------+---------------+-------+-----+-+---------------+
| Kind | Length = 12 |Subtype|(rsv)|B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
Figure 5: Join Connection (MP_JOIN) Option (for Initial SYN)
The token is used to identify the MPTCP connection and is a cryptographic hash of the receiver's key, as exchanged in the initial MP_CAPABLE handshake (Section 3.1). In this specification, the tokens presented in this option are generated by the SHA-256 algorithm [RFC6234], truncated to the most significant 32 bits. The token included in the MP_JOIN option is the token that the receiver of the packet uses to identify this connection; i.e., Host A will send Token-B (which is generated from Key-B). Note that the hash generation algorithm can be overridden by the choice of cryptographic handshake algorithm, as defined in Section 3.1.
トークンはMPTCP接続を識別するために使用され、最初のMP_CAPABLEハンドシェイク（セクション3.1）で交換されるように、受信者のキーの暗号化ハッシュです。この仕様では、このオプションで提示されるトークンは、SHA-256アルゴリズム[RFC6234]によって生成され、最上位の32ビットに切り捨てられます。 MP_JOINオプションに含まれるトークンは、パケットの受信者がこの接続を識別するために使用するトークンです。つまり、ホストAがトークンB（Key-Bから生成）を送信します。ハッシュ生成アルゴリズムは、セクション3.1で定義されているように、暗号化ハンドシェイクアルゴリズムを選択することでオーバーライドできることに注意してください。
The MP_JOIN SYN sends not only the token (which is static for a connection) but also random numbers (nonces) that are used to prevent replay attacks on the authentication method. Recommendations for the generation of random numbers for this purpose are given in [RFC4086].
MP_JOIN SYNは、トークン（接続では静的）だけでなく、認証方法へのリプレイアタックを防ぐために使用される乱数（ナンス）も送信します。この目的で乱数を生成するための推奨事項は、[RFC4086]で提供されています。
The MP_JOIN option includes an "Address ID". This is an identifier generated by the sender of the option, used to identify the source address of this packet, even if the IP header has been changed in transit by a middlebox. The numeric 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.4.2) without needing to know what the source address at the receiver is, thus allowing address removal through NATs. The Address ID also allows correlation between new subflow setup attempts and address signaling (Section 3.4.1), to prevent setting up duplicate subflows on the same path, if an MP_JOIN and ADD_ADDR are sent at the same time.
MP_JOINオプションには、「アドレスID」が含まれています。これはオプションの送信者によって生成された識別子であり、ミドルボックスによって転送中にIPヘッダーが変更された場合でも、このパケットの送信元アドレスを識別するために使用されます。このフィールドの数値は送信者によって生成され、送信ホストの送信元IPアドレスに一意にマッピングする必要があります。アドレスIDを使用すると、受信側の送信元アドレスが何であるかを知る必要なくアドレスを削除でき（セクション3.4.2）、NATを介してアドレスを削除できます。 MP_JOINとADD_ADDRが同時に送信された場合、アドレスIDを使用すると、新しいサブフローのセットアップ試行とアドレスシグナリング（セクション3.4.1）を関連付けて、同じパスに重複するサブフローをセットアップすることを防ぐことができます。
The Address IDs of the subflow used in the initial SYN 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 both for 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.
接続の最初のサブフローの最初のSYN交換で使用されるサブフローのアドレスIDは暗黙的であり、値はゼロです。ホストは、自身とリモートホストの両方のアドレスIDとアドレスの間のマッピングを保存する必要があります。ローカルまたはリモートのホストからアドレスが削除された場合、実装では、確立されたサブフローに関連付けられているローカルおよびリモートのアドレスIDを知る必要もあります。
The MP_JOIN option on packets with the SYN flag set also includes 4 bits of flags, 3 of which are currently reserved and MUST be set to 0 by the sender. The final bit, labeled "B", indicates whether the sender of this option (1) wishes this subflow to be used as a backup path (B=1) in the event of failure of other paths or (2) wants the subflow to be used as part of the connection immediately. By setting B=1, the sender of the option is requesting that the other host only send data on this subflow if there are no available subflows where B=0. Subflow policy is discussed in more detail in Section 3.3.8.
SYNフラグが設定されたパケットのMP_JOINオプションには、4ビットのフラグも含まれます。そのうち3つは現在予約されており、送信者が0に設定する必要があります。 「B」というラベルの付いた最後のビットは、このオプションの送信者が、（1）他のパスで障害が発生した場合にこのサブフローをバックアップパスとして使用する（B = 1）か、または（2）サブフローに接続の一部としてすぐに使用できます。 B = 1を設定することにより、オプションの送信者は、B = 0の使用可能なサブフローがない場合に、他のホストがこのサブフローでのみデータを送信することを要求します。サブフローポリシーについては、3.3.8項で詳しく説明します。
When receiving a SYN with an MP_JOIN option that contains a valid token for an existing MPTCP connection, the recipient SHOULD respond with a SYN/ACK also containing an MP_JOIN option containing a random number and a truncated (leftmost 64 bits) HMAC. This version of the option is shown in Figure 6. If the token is unknown or the host wants to refuse subflow establishment (for example, due to a limit on the number of subflows it will permit), the receiver will send back a reset (RST) signal, analogous to an unknown port in TCP, containing an MP_TCPRST option (Section 3.6) with an "MPTCP specific error" reason code. Although calculating an HMAC requires cryptographic operations, it is believed that the 32-bit token in the MP_JOIN SYN gives sufficient protection against blind state exhaustion attacks; therefore, there is no need to provide mechanisms to allow a responder to operate statelessly at the MP_JOIN stage.
既存のMPTCP接続の有効なトークンを含むMP_JOINオプションを使用してSYNを受信すると、受信者は、乱数と切り捨てられた（左端の64ビット）HMACを含むMP_JOINオプションを含むSYN / ACKで応答する必要があります（SHOULD）。このバージョンのオプションを図6に示します。トークンが不明であるか、ホストがサブフローの確立を拒否したい場合（たとえば、許可するサブフローの数が制限されているため）、レシーバーはリセット（ RST）信号。TCPの不明なポートに似ており、MP_TCPRSTオプション（セクション3.6）に「MPTCP固有のエラー」理由コードが含まれています。 HMACの計算には暗号化操作が必要ですが、MP_JOIN SYNの32ビットトークンは、ブラインドステート枯渇攻撃に対する十分な保護を提供すると考えられています。したがって、レスポンダがMP_JOINステージでステートレスに動作できるようにするメカニズムを提供する必要はありません。
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
+---------------+---------------+-------+-----+-+---------------+
| Kind | Length = 16 |Subtype|(rsv)|B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| |
| Sender's Truncated HMAC (64 bits) |
| |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)
An HMAC is sent by both hosts -- by the initiator (Host A) in the third packet (the ACK) and by the responder (Host B) in the second packet (the SYN/ACK). Doing the HMAC exchange at this stage allows both hosts to have first exchanged random data (in the first two SYN packets) that is used as the "message". This specification defines that HMAC as defined in [RFC2104] is used, along with the SHA-256 hash algorithm [RFC6234], and that the output is truncated to the leftmost 160 bits (20 octets). Due to option space limitations, the HMAC included in the SYN/ACK is truncated to the leftmost 64 bits, but this is acceptable, since random numbers are used; thus, an attacker only has one chance to correctly guess the HMAC that matches the random number previously sent by the peer (if the HMAC is incorrect, the TCP connection is closed, so a new MP_JOIN negotiation with a new random number is required).
HMACは両方のホストから送信されます。3番目のパケット（ACK）でイニシエーター（ホストA）が送信し、2番目のパケット（SYN / ACK）でレスポンダー（ホストB）が送信します。この段階でHMAC交換を行うと、両方のホストが最初にランダムなデータを交換し（最初の2つのSYNパケットで）、「メッセージ」として使用されます。この仕様は、[RFC2104]で定義されているHMACがSHA-256ハッシュアルゴリズム[RFC6234]とともに使用され、出力が左端の160ビット（20オクテット）に切り捨てられることを定義しています。オプションのスペース制限により、SYN / ACKに含まれるHMACは左端の64ビットに切り捨てられますが、乱数が使用されるため、これは許容されます。したがって、攻撃者は、ピアによって以前に送信された乱数と一致するHMACを正しく推測する1回の機会しかありません（HMACが正しくない場合、TCP接続が閉じられるため、新しい乱数による新しいMP_JOINネゴシエーションが必要です）。
The initiator's authentication information is sent in its first ACK (the third packet of the handshake), as shown in Figure 7. This data needs to be sent reliably, since it is the only time this HMAC is sent; therefore, receipt of this packet MUST trigger a regular TCP ACK in response, and the packet MUST be retransmitted if this ACK is not received. In other words, sending the ACK/MP_JOIN packet places the subflow in the PRE_ESTABLISHED state, and it moves to the ESTABLISHED state only on receipt of an ACK from the receiver. It is not permissible to send data while in the PRE_ESTABLISHED state. The reserved bits in this option MUST be set to 0 by the sender.
イニシエーターの認証情報は、図7に示すように、最初のACK（ハンドシェイクの3番目のパケット）で送信されます。このHMACが送信されるのはこのデータだけなので、このデータは確実に送信される必要があります。したがって、このパケットの受信は応答として通常のTCP ACKをトリガーする必要があり、このACKが受信されない場合はパケットを再送信する必要があります。つまり、ACK / MP_JOINパケットを送信するとサブフローがPRE_ESTABLISHED状態になり、受信側からACKを受信した場合にのみESTABLISHED状態に移行します。 PRE_ESTABLISHED状態のときにデータを送信することはできません。このオプションの予約ビットは、送信者が0に設定する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length = 24 |Subtype| (reserved) |
+---------------+---------------+-------+-----------------------+
| |
| |
| Sender's Truncated HMAC (160 bits) |
| |
| |
+---------------------------------------------------------------+
Figure 7: Join Connection (MP_JOIN) Option (for Initiator's First ACK)
図7：接続への参加（MP_JOIN）オプション（イニシエーターの最初のACK用）
The key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B; and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged in the original MP_CAPABLE handshake. The "message" for the HMAC algorithm in each case is the concatenations of random numbers for each host (denoted by R): for Host A, R-A followed by R-B; and for Host B, R-B followed by R-A.
HMACアルゴリズムのキーは、ホストAから送信されたメッセージの場合、Key-Aの後にKey-Bが続きます。ホストBの場合、Key-Bの後にKey-Aが続きます。これらは、元のMP_CAPABLEハンドシェイクで交換されたキーです。それぞれの場合のHMACアルゴリズムの「メッセージ」は、各ホストの乱数（Rで示される）の連結です。ホストAの場合、R-Aの後にR-Bが続きます。ホストBの場合、R-Bの後にR-Aが続きます。
These various MPTCP options fit together to enable authenticated subflow setup as illustrated in Figure 8.
図8に示すように、これらのさまざまなMPTCPオプションを組み合わせて、認証済みサブフローのセットアップを有効にします。
Host A Host B
------------------------ ----------
Address A1 Address A2 Address B1
---------- ---------- ----------
| | |
| | SYN + MP_CAPABLE |
|--------------------------------------------->|
|<---------------------------------------------|
| SYN/ACK + MP_CAPABLE(Key-B) |
| | |
| ACK + MP_CAPABLE(Key-A, Key-B) |
|--------------------------------------------->|
| | |
| | SYN + MP_JOIN(Token-B, R-A) |
| |------------------------------->|
| |<-------------------------------|
| | SYN/ACK + MP_JOIN(HMAC-B, R-B) |
| | |
| | ACK + MP_JOIN(HMAC-A) |
| |------------------------------->|
| |<-------------------------------|
| | ACK |
HMAC-A = HMAC(Key=(Key-A + Key-B), Msg=(R-A + R-B))
HMAC-B = HMAC(Key=(Key-B + Key-A), Msg=(R-B + R-A))
Figure 8: Example Use of MPTCP Authentication
図8：MPTCP認証の使用例
If the token received at Host B is unknown or local policy prohibits the acceptance of the new subflow, the recipient MUST respond with a TCP RST for the subflow. If appropriate, an MP_TCPRST option with an "Administratively prohibited" reason code (Section 3.6) should be included.
ホストBで受信したトークンが不明であるか、ローカルポリシーが新しいサブフローの受け入れを禁止している場合、受信者はサブフローのTCP RSTで応答する必要があります。必要に応じて、「管理上禁止」の理由コード（セクション3.6）を含むMP_TCPRSTオプションを含める必要があります。
If the token is accepted at Host B but the HMAC returned to Host A does not match the one expected, Host A MUST close the subflow with a TCP RST. In this and all subsequent cases of sending a RST as described in this section, the sender SHOULD send an MP_TCPRST option (Section 3.6) on this RST packet with the reason code for an "MPTCP-specific error".
トークンがホストBで受け入れられたが、ホストAに返されたHMACが予期されたものと一致しない場合、ホストAはTCP RSTでサブフローを閉じる必要があります。このセクションで説明するように、RSTを送信するこれ以降のすべてのケースでは、送信者は、このRSTパケットに「MPTCP固有のエラー」の理由コードとともにMP_TCPRSTオプション（セクション3.6）を送信する必要があります（SHOULD）。
If Host B does not receive the expected HMAC or the MP_JOIN option is missing from the ACK, it MUST close the subflow with a TCP RST.
ホストBが予期されたHMACを受信しないか、MP_JOINオプションがACKにない場合、TCP RSTでサブフローを閉じる必要があります。
If the HMACs are verified as correct, then both hosts have verified each other as being the same peers as those that existed at the start of the connection, and they have agreed of which connection this subflow will become a part.
HMACが正しいことが検証された場合、両方のホストは、接続の開始時に存在していたものと同じピアであることを互いに検証し、このサブフローがどの接続になるかについて合意しました。
If the SYN/ACK as received at Host A does not have an MP_JOIN option, Host A MUST close the subflow with a TCP RST.
ホストAで受信したSYN / ACKにMP_JOINオプションがない場合、ホストAはTCP RSTでサブフローを閉じる必要があります。
This covers all cases of the loss of an MP_JOIN. In more detail, if an MP_JOIN is stripped from the SYN on the path from A to B and Host B does not have a listener on the relevant port, it will respond with a RST in the normal way. If in response to a SYN with an MP_JOIN option a SYN/ACK is received without the MP_JOIN option (because it was either stripped on the return path, or stripped on the outgoing path leading to Host B responding as if it was a new regular TCP session), then the subflow is unusable and Host A MUST close it with a RST.
これは、MP_JOINの損失のすべてのケースをカバーします。より詳細には、MP_JOINがAからBへのパス上のSYNから削除され、ホストBが関連するポートにリスナーを持っていない場合、通常の方法でRSTで応答します。 MP_JOINオプション付きのSYNに応答して、SYN / ACKがMP_JOINオプションなしで受信された場合（戻りパスで取り除かれたか、ホストBが新しい通常のTCPであるかのように応答するホストBにつながる発信パスで取り除かれたため）セッション）、サブフローは使用できず、ホストAはRSTでサブフローを閉じる必要があります。
Note that additional subflows can be created between any pair of ports (but see Section 3.9 for heuristics); no explicit application-level accept calls or bind calls are required to open additional subflows. To associate a new subflow with an existing connection, the token supplied in the subflow's SYN exchange is used for demultiplexing. This then binds the 5-tuple of the TCP subflow to the local token of the connection. One consequence is that it is possible to allow any port pairs to be used for a connection.
追加のサブフローを任意のポートのペア間に作成できることに注意してください（ただし、ヒューリスティックについてはセクション3.9を参照）。追加のサブフローを開くために、明示的なアプリケーションレベルの受け入れ呼び出しまたはバインド呼び出しは必要ありません。新しいサブフローを既存の接続に関連付けるには、サブフローのSYN交換で提供されるトークンを逆多重化に使用します。次に、TCPサブフローの5タプルを接続のローカルトークンにバインドします。 1つの結果として、任意のポートペアを接続に使用できるようにすることができます。
Demultiplexing subflow SYNs MUST be done using the token; this is unlike traditional TCP, where the destination port is used for demultiplexing SYN packets. Once a subflow is set up, demultiplexing packets is done using the 5-tuple, as in traditional TCP. The 5-tuples will be mapped to the local connection identifier (token). Note that Host A will know its local token for the subflow even though it is not sent on the wire -- only the responder's token is sent.
サブフローSYNの逆多重化は、トークンを使用して実行する必要があります。これは、宛先ポートがSYNパケットの逆多重化に使用される従来のTCPとは異なります。サブフローがセットアップされると、パケットの逆多重化は、従来のTCPと同様に5タプルを使用して行われます。 5タプルはローカル接続識別子（トークン）にマップされます。ホストAは、ワイヤーで送信されなくても、サブフローのローカルトークンを知っていることに注意してください。レスポンダのトークンのみが送信されます。
This section discusses the operation of MPTCP for data transfer. At a high level, an MPTCP implementation will take one input data stream from an application and split it into one or more subflows, with sufficient control information to allow it to be reassembled and delivered reliably and in order to the recipient application. The following subsections define this behavior in detail.
このセクションでは、データ転送のためのMPTCPの操作について説明します。高レベルでは、MPTCP実装は、アプリケーションから1つの入力データストリームを取得し、それを1つ以上のサブフローに分割します。十分な制御情報を使用して、再組み立てし、受信側アプリケーションに確実に配信できるようにします。以下のサブセクションでは、この動作を詳細に定義しています。
The Data Sequence Mapping and the Data ACK are signaled in the DSS option (Figure 9). Either or both can be signaled in one DSS, depending on the flags set. The Data Sequence Mapping defines how the sequence space on the subflow maps to the connection level, and the Data ACK acknowledges receipt of data at the connection level. These functions are described in more detail in the following two subsections.
データシーケンスマッピングとデータACKは、DSSオプションで通知されます（図9）。設定されたフラグに応じて、どちらかまたは両方を1つのDSSで通知できます。データシーケンスマッピングは、サブフローのシーケンススペースを接続レベルにマップする方法を定義し、データACKは接続レベルでのデータの受信を確認します。これらの関数については、次の2つのサブセクションで詳しく説明します。
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
+---------------+---------------+-------+----------------------+
| Kind | Length |Subtype| (reserved) |F|m|M|a|A|
+---------------+---------------+-------+----------------------+
| Data ACK (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Data Sequence Number (4 or 8 octets, depending on flags) |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Checksum (2 octets) |
+-------------------------------+------------------------------+
Figure 9: Data Sequence Signal (DSS) Option
図9：データシーケンス信号（DSS）オプション
The flags, when set, define the contents of this option, as follows:
フラグを設定すると、このオプションの内容が次のように定義されます。
* A = Data ACK present
* A =データACKが存在する
* a = Data ACK is 8 octets (if not set, Data ACK is 4 octets)
* a =データACKは8オクテット（設定されていない場合、データACKは4オクテット）
* M = Data Sequence Number (DSN), Subflow Sequence Number (SSN), Data-Level Length, and Checksum (if negotiated) present
* M =データシーケンス番号（DSN）、サブフローシーケンス番号（SSN）、データレベルの長さ、およびチェックサム（ネゴシエートされている場合）が存在する
* m = Data Sequence Number is 8 octets (if not set, DSN is 4 octets)
* m =データシーケンス番号は8オクテット（設定されていない場合、DSNは4オクテット）
The flags "a" and "m" only have meaning if the corresponding "A" or "M" flags are set; otherwise, they will be ignored. The maximum length of this option, with all flags set, is 28 octets.
フラグ「a」と「m」は、対応する「A」または「M」フラグが設定されている場合にのみ意味があります。それ以外の場合は無視されます。このオプションの最大長は、すべてのフラグが設定された状態で、28オクテットです。
The "F" flag indicates "Data FIN". If present, this means that this mapping covers the final data from the sender. This is the connection-level equivalent of the FIN flag in single-path TCP. A connection is not closed unless there has been a Data FIN exchange, an MP_FASTCLOSE (Section 3.5) message, or an implementation-specific connection-level send timeout. The purpose of the Data FIN and the interactions between this flag, the subflow-level FIN flag, and the Data Sequence Mapping are described in Section 3.3.3. The remaining reserved bits MUST be set to 0 by an implementation of this specification.
「F」フラグは「データFIN」を示します。存在する場合、これは、このマッピングが送信者からの最終データをカバーすることを意味します。これは、シングルパスTCPのFINフラグに相当する接続レベルです。データFIN交換、MP_FASTCLOSE（セクション3.5）メッセージ、または実装固有の接続レベルの送信タイムアウトがない限り、接続は閉じられません。データFINの目的と、このフラグ、サブフローレベルのFINフラグ、およびデータシーケンスマッピング間の相互作用については、セクション3.3.3で説明します。残りの予約済みビットは、この仕様の実装によって0に設定する必要があります。
Note that the checksum is only present in this option if the use of MPTCP checksumming has been negotiated at the MP_CAPABLE handshake (see Section 3.1). The presence of the checksum can be inferred from the length of the option. If a checksum is present but its use had not been negotiated in the MP_CAPABLE handshake, the receiver MUST close the subflow with a RST, as it is not behaving as negotiated. If a checksum is not present when its use has been negotiated, the receiver MUST close the subflow with a RST, as it is considered broken. In both cases, this RST SHOULD be accompanied by an MP_TCPRST option (Section 3.6) with the reason code for an "MPTCP-specific error".
チェックサムは、MPTCPチェックサムの使用がMP_CAPABLEハンドシェイクでネゴシエートされている場合にのみ、このオプションに存在することに注意してください（セクション3.1を参照）。チェックサムの存在は、オプションの長さから推測できます。チェックサムは存在するが、その使用がMP_CAPABLEハンドシェイクでネゴシエートされていなかった場合、レシーバーは、ネゴシエートされたように動作しないため、サブフローをRSTで閉じる必要があります。使用がネゴシエートされたときにチェックサムが存在しない場合、壊れていると見なされるため、受信者はRSTでサブフローを閉じる必要があります。どちらの場合も、このRSTには、「MPTCP固有のエラー」の理由コードとともにMP_TCPRSTオプション（セクション3.6）が付随する必要があります（SHOULD）。
The data stream as a whole can be reassembled through the use of the Data Sequence Mapping components of the DSS option (Figure 9), which define the mapping from the subflow sequence number to the data sequence number. This is used by the receiver to ensure in-order delivery to the application layer. Meanwhile, the subflow-level sequence numbers (i.e., the regular sequence numbers in the TCP header) are only relevant to the subflow. It is expected (but not mandated) that SACK [RFC2018] will be used at the subflow level to improve efficiency.
データストリームは、サブフローシーケンス番号からデータシーケンス番号へのマッピングを定義するDSSオプションのデータシーケンスマッピングコンポーネント（図9）を使用して、全体として再構成できます。これは、アプリケーション層への順序どおりの配信を保証するために受信者によって使用されます。一方、サブフローレベルのシーケンス番号（つまり、TCPヘッダーの通常のシーケンス番号）は、サブフローにのみ関連しています。 SACK [RFC2018]が効率を改善するためにサブフローレベルで使用されることが期待されます（必須ではありません）。
The Data Sequence Mapping specifies a mapping from the subflow sequence space to the data sequence space. This is expressed in terms of starting sequence numbers for the subflow and the data level, and a length of bytes for which this mapping is valid. This explicit mapping for a range of data, rather than per-packet signaling, was chosen to assist with compatibility with situations where TCP/IP segmentation or coalescing is undertaken separately from the stack that is generating the data flow (e.g., through the use of TCP segmentation offloading on network interface cards, or by middleboxes such as Performance Enhancing Proxies (PEPs) [RFC3135]). It also allows a single mapping to cover many packets; this may be useful in bulk-transfer situations.
データシーケンスマッピングは、サブフローシーケンススペースからデータシーケンススペースへのマッピングを指定します。これは、サブフローとデータレベルの開始シーケンス番号、およびこのマッピングが有効なバイト長で表されます。パケットごとのシグナリングではなく、一連のデータのこの明示的なマッピングは、データフローを生成しているスタックとは別に（たとえば、ネットワークインターフェイスカードでのTCPセグメンテーションオフロード、またはPerformance Enhancing Proxies（PEP）[RFC3135]などのミドルボックスによる。また、単一のマッピングで多くのパケットをカバーできます。これは、一括転送の状況で役立ちます。
A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT change this mapping after it has been declared; however, the same data sequence number can be mapped to by different subflows for retransmission purposes (see Section 3.3.6). This would also permit the same data to be sent simultaneously on multiple subflows for resilience or efficiency purposes, especially in the case of lossy links. Although the detailed specification of such operation is outside the scope of this document, an implementation SHOULD treat the first data that is received at a subflow for the data sequence space as the data that should be delivered to the application, and any subsequent data for that sequence space SHOULD be ignored.
マッピングは固定されており、マッピングが処理された後、サブフローシーケンス番号がデータシーケンス番号にバインドされます。送信者は、宣言後にこのマッピングを変更してはなりません（MUST NOT）。ただし、同じデータシーケンス番号は、再送信のために異なるサブフローによってマッピングできます（セクション3.3.6を参照）。これにより、特に損失の多いリンクの場合に、回復力または効率性の目的で、同じデータを複数のサブフローで同時に送信することもできます。そのような操作の詳細な仕様はこのドキュメントの範囲外ですが、実装では、データシーケンススペースのサブフローで受信された最初のデータを、アプリケーションに配信する必要があるデータとして処理する必要があります。シーケンススペースは無視してください。
The data sequence number is specified as an absolute value, whereas the subflow sequence numbering is relative (the SYN at the start of the subflow has a relative subflow sequence number of 0). This is done to allow middleboxes to change the Initial Sequence Number (ISN) of a subflow, such as firewalls that undertake ISN randomization.
データシーケンス番号は絶対値として指定されますが、サブフローシーケンス番号は相対的です（サブフローの開始時のSYNの相対サブフローシーケンス番号は0です）。これは、ミドルボックスがISNランダム化を行うファイアウォールなどのサブフローの初期シーケンス番号（ISN）を変更できるようにするために行われます。
The Data Sequence Mapping also contains a checksum of the data that this mapping covers, if the use of checksums has been negotiated at the MP_CAPABLE exchange. Checksums are used to detect if the payload has been adjusted in any way by a non-MPTCP-aware middlebox. If this checksum fails, it will trigger a failure of the subflow, or a fallback to regular TCP, as documented in Section 3.7, since MPTCP can no longer reliably know the subflow sequence space at the receiver to build Data Sequence Mappings. Without checksumming enabled, corrupt data may be delivered to the application if a middlebox alters segment boundaries, alters content, or does not deliver all segments covered by a Data Sequence Mapping. It is therefore RECOMMENDED that checksumming be used, unless it is known that the network path contains no such devices.
チェックサムの使用がMP_CAPABLE交換でネゴシエートされている場合、データシーケンスマッピングには、このマッピングがカバーするデータのチェックサムも含まれます。チェックサムは、ペイロードがMPTCP非対応のミドルボックスによって何らかの方法で調整されたかどうかを検出するために使用されます。このチェックサムが失敗すると、セクション3.7で説明されているように、サブフローの失敗、または通常のTCPへのフォールバックがトリガーされます。MPTCPは、データシーケンスマッピングを構築するためにレシーバーでサブフローシーケンススペースを確実に認識できないためです。チェックサムを有効にしないと、ミドルボックスがセグメントの境界を変更したり、コンテンツを変更したり、データシーケンスマッピングの対象となるすべてのセグメントを配信しなかったりすると、破損したデータがアプリケーションに配信される可能性があります。したがって、ネットワークパスにそのようなデバイスが含まれていないことがわかっている場合を除き、チェックサムを使用することをお勧めします。
The checksum algorithm used is the standard TCP checksum [RFC0793], operating over the data covered by this mapping, along with a pseudo-header as shown in Figure 10.
使用されるチェックサムアルゴリズムは、標準のTCPチェックサム[RFC0793]であり、図10に示すように、このマッピングでカバーされるデータと疑似ヘッダーを操作します。
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
+--------------------------------------------------------------+
| |
| Data Sequence Number (8 octets) |
| |
+--------------------------------------------------------------+
| Subflow Sequence Number (4 octets) |
+-------------------------------+------------------------------+
| Data-Level Length (2 octets) | Zeros (2 octets) |
+-------------------------------+------------------------------+
Figure 10: Pseudo-Header for DSS Checksum
図10：DSSチェックサムの疑似ヘッダー
Note that the data sequence number used in the pseudo-header is always the 64-bit value, irrespective of what length is used in the DSS option itself. The standard TCP checksum algorithm has been chosen, since it will be calculated anyway for the TCP subflow, and if calculated first over the data before adding the pseudo-headers, it only needs to be calculated once. Furthermore, since the TCP checksum is additive, the checksum for a DSN_MAP can be constructed by simply adding together the checksums for the data of each constituent TCP segment and adding the checksum for the DSS pseudo-header.
疑似ヘッダーで使用されるデータシーケンス番号は、DSSオプション自体で使用される長さに関係なく、常に64ビット値であることに注意してください。標準のTCPチェックサムアルゴリズムが選択されています。これは、TCPサブフローに対してとにかく計算されるためです。疑似ヘッダーを追加する前にデータに対して最初に計算される場合は、1回だけ計算する必要があります。さらに、TCPチェックサムは付加的であるため、DSN_MAPのチェックサムは、構成する各TCPセグメントのデータのチェックサムを加算し、DSS疑似ヘッダーのチェックサムを追加するだけで作成できます。
Note that checksumming relies on the TCP subflow containing contiguous data; therefore, a TCP subflow MUST NOT use the Urgent Pointer to interrupt an existing mapping. Further note, however, that if Urgent data is received on a subflow, it SHOULD be mapped to the data sequence space and delivered to the application, analogous to Urgent data in regular TCP.
チェックサムは、連続したデータを含むTCPサブフローに依存していることに注意してください。したがって、TCPサブフローは、既存のマッピングを中断するために緊急ポインターを使用してはなりません（MUST NOT）。ただし、サブフローで緊急データを受信した場合、通常のTCPの緊急データと同様に、データシーケンススペースにマップしてアプリケーションに配信する必要があります（SHOULD）。
To avoid possible deadlock scenarios, subflow-level processing should be undertaken separately from processing at the connection level. Therefore, even if a mapping does not exist from the subflow space to the data-level space, the data SHOULD still be ACKed at the subflow (if it is in-window). This data cannot, however, be acknowledged at the data level (Section 3.3.2) because its data sequence numbers are unknown. Implementations MAY hold onto such unmapped data for a short while, in the expectation that a mapping will arrive shortly. Such unmapped data cannot be counted as being within the connection-level receive window because this is relative to the data sequence numbers, so if the receiver runs out of memory to hold this data, it will have to be discarded. If a mapping for that subflow-level sequence space does not arrive within a receive window of data, that subflow SHOULD be treated as broken, closed with a RST, and any unmapped data silently discarded.
起こり得るデッドロックシナリオを回避するために、サブフローレベルの処理は、接続レベルでの処理とは別に行う必要があります。したがって、サブフロースペースからデータレベルスペースへのマッピングが存在しない場合でも、データはサブフローでACKされる必要があります（ウィンドウ内の場合）。ただし、このデータはデータシーケンス番号が不明であるため、データレベル（セクション3.3.2）では確認できません。実装は、マッピングが間もなく到着することを期待して、このようなマッピングされていないデータをしばらく保持する場合があります。このようなマッピングされていないデータは、データシーケンス番号に関連しているため、接続レベルの受信ウィンドウ内にあるとは見なされないため、レシーバーがこのデータを保持するためのメモリを使い果たした場合は、破棄する必要があります。そのサブフローレベルのシーケンススペースのマッピングがデータの受信ウィンドウ内に到着しない場合、そのサブフローは壊れたものとして扱われ、RSTで閉じられ、マッピングされていないデータはサイレントに破棄される必要があります（SHOULD）。
Data sequence numbers are always 64-bit quantities and MUST be maintained as such in implementations. If a connection is progressing at a slow rate, so protection against wrapped sequence numbers is not required, then an implementation MAY include just the lower 32 bits of the data sequence number in the Data Sequence Mapping and/or Data ACK as an optimization, and an implementation can make this choice independently for each packet. An implementation MUST be able to receive and process both 64-bit and 32-bit sequence number values, but it is not required that an implementation be able to send both.
データシーケンス番号は常に64ビットの数量であり、実装ではそのように維持する必要があります。接続が低速で進行しているため、ラップされたシーケンス番号に対する保護が不要な場合、実装は、データシーケンスマッピングの下位32ビットだけを最適化としてデータシーケンスマッピングまたはデータACKに含めることができます。実装は、この選択を各パケットに対して個別に行うことができます。実装は64ビットと32ビットの両方のシーケンス番号値を受信および処理できなければなりません（MUST）が、実装が両方を送信できる必要はありません。
An implementation MUST send the full 64-bit data sequence number if it is transmitting at a sufficiently high rate that the 32-bit value could wrap within the Maximum Segment Lifetime (MSL) [RFC7323]. The lengths of the DSNs used in these values (which may be different) are declared with flags in the DSS option. Implementations MUST accept a 32-bit DSN and implicitly promote it to a 64-bit quantity by incrementing the upper 32 bits of the sequence number each time the lower 32 bits wrap. A sanity check MUST be implemented to ensure that a wrap occurs at an expected time (e.g., the sequence number jumps from a very high number to a very low number) and is not triggered by out-of-order packets.
32ビット値が最大セグメントライフタイム（MSL）[RFC7323]内でラップできる十分に高いレートで送信している場合、実装は完全な64ビットデータシーケンス番号を送信する必要があります。これらの値で使用されるDSNの長さ（異なる場合があります）は、DSSオプションのフラグで宣言されます。実装は32ビットDSNを受け入れ、下位32ビットがラップするたびにシーケンス番号の上位32ビットをインクリメントすることにより、暗黙的に64ビット数量に昇格させる必要があります。正常性チェックを実装して、予期した時間にラップが発生し（シーケンス番号が非常に高い番号から非常に低い番号にジャンプするなど）、順序が乱れたパケットによってトリガーされないようにする必要があります。
As with the standard TCP sequence number, the data sequence number should not start at zero, but at a random value to make blind session hijacking harder. This specification requires setting the IDSN of each host to the least significant 64 bits of the SHA-256 hash of the host's key, as described in Section 3.1. This is also required in order for the receiver to know what the expected IDSN is and thus determine if any initial connection-level packets are missing; this is particularly relevant if two subflows start transmitting simultaneously.
標準のTCPシーケンス番号と同様に、データシーケンス番号はゼロではなくランダムな値で開始して、ブラインドセッションのハイジャックを困難にする必要があります。この仕様では、セクション3.1で説明されているように、各ホストのIDSNをホストのキーのSHA-256ハッシュの最下位64ビットに設定する必要があります。これは、受信側が予期されるIDSNを認識し、初期の接続レベルのパケットが欠落しているかどうかを判断するためにも必要です。これは、2つのサブフローが同時に送信を開始する場合に特に関係があります。
The mapping provided by a Data Sequence Mapping MUST apply to some or all of the subflow sequence space in the TCP segment that carries the option. It does not need to be included in every MPTCP packet, as long as the subflow sequence space in that packet is covered by a mapping known at the receiver. This can be used to reduce overhead in cases where the mapping is known in advance. One such case is when there is a single subflow between the hosts, and another is when segments of data are scheduled in larger-than-packet-sized chunks.
データシーケンスマッピングによって提供されるマッピングは、オプションを運ぶTCPセグメントのサブフローシーケンススペースの一部またはすべてに適用する必要があります。パケット内のサブフローシーケンススペースが受信側で既知のマッピングによってカバーされている限り、すべてのMPTCPパケットに含める必要はありません。これは、マッピングが事前にわかっている場合にオーバーヘッドを削減するために使用できます。そのようなケースの1つは、ホスト間に単一のサブフローが存在する場合であり、別のケースは、データのセグメントがパケットサイズより大きいチャンクでスケジュールされる場合です。
An "infinite" mapping can be used to fall back to regular TCP by mapping the subflow-level data to the connection-level data for the remainder of the connection (see Section 3.7). This is achieved by setting the Data-Level Length field of the DSS option to the reserved value of 0. The checksum, in such a case, will also be set to 0.
「無限」マッピングを使用して、サブフローレベルのデータを残りの接続の接続レベルのデータにマッピングすることで、通常のTCPにフォールバックできます（セクション3.7を参照）。これは、DSSオプションのData-Level Lengthフィールドを予約済みの値0に設定することによって実現されます。このような場合、チェックサムも0に設定されます。
To provide full end-to-end resilience, MPTCP provides a connection-level acknowledgment, to act as a cumulative ACK for the connection as a whole. This is done via the "Data ACK" field of the DSS option (Figure 9). The Data ACK is analogous to the behavior of the standard TCP cumulative ACK -- indicating how much data has been successfully received (with no holes). This can be compared to the subflow-level ACK, which acts in a fashion analogous to TCP SACK, given that there may still be holes in the data stream at the connection level. The Data ACK specifies the next data sequence number it expects to receive.
完全なエンドツーエンドの復元力を提供するために、MPTCPは接続レベルの確認応答を提供し、接続全体の累積ACKとして機能します。これは、DSSオプションの「データACK」フィールドを介して行われます（図9）。データACKは、標準のTCP累積ACKの動作に似ています-正常に受信されたデータ（ホールなし）の量を示します。これは、接続レベルのデータストリームにまだホールがある場合、TCP SACKに類似した方法で機能するサブフローレベルのACKと比較できます。データACKは、受信する予定の次のデータシーケンス番号を指定します。
The Data ACK, as for the DSN, can be sent as the full 64-bit value or as the lower 32 bits. If data is received with a 64-bit DSN, it MUST be acknowledged with a 64-bit Data ACK. If the DSN received is 32 bits, an implementation can choose whether to send a 32-bit or 64-bit Data ACK, and an implementation MUST accept either in this situation.
DSNの場合と同様に、データACKは完全な64ビット値または下位32ビットとして送信できます。データが64ビットDSNで受信された場合、64ビットデータACKで確認する必要があります。受信したDSNが32ビットの場合、実装は32ビットと64ビットのどちらのデータACKを送信するかを選択でき、実装はこの状況でどちらも受け入れる必要があります。
The Data ACK proves that the data, and all required MPTCP signaling, have been received and accepted by the remote end. One key use of the Data ACK signal is that it is used to indicate the left edge of the advertised receive window. As explained in Section 3.3.4, the receive window is shared by all subflows and is relative to the Data ACK. Because of this, an implementation MUST NOT use the RCV.WND field of a TCP segment at the connection level if it does not also carry a DSS option with a Data ACK field. Furthermore, separating the connection-level acknowledgments from the subflow level allows processing to be done separately, and a receiver has the freedom to drop segments after acknowledgment at the subflow level -- for example, due to memory constraints when many segments arrive out of order.
データACKは、データと必要なすべてのMPTCPシグナリングがリモートエンドで受信され、受け入れられたことを証明します。データACK信号の主な用途の1つは、アドバタイズされた受信ウィンドウの左端を示すために使用されることです。セクション3.3.4で説明したように、受信ウィンドウはすべてのサブフローで共有され、データACKに関連しています。このため、実装は、データACKフィールドを含むDSSオプションも伝送しない場合、接続レベルでTCPセグメントのRCV.WNDフィールドを使用してはなりません（MUST NOT）。さらに、接続レベルの確認応答をサブフローレベルから分離することで、処理を個別に行うことができ、レシーバーはサブフローレベルで確認応答後にセグメントを自由にドロップできます。 。
An MPTCP sender MUST NOT free data from the send buffer until it has been acknowledged by both a Data ACK received on any subflow and at the subflow level by all subflows on which the data was sent. The former condition ensures liveness of the connection, and the latter condition ensures liveness and self-consistence of a subflow when data needs to be retransmitted. Note, however, that if some data needs to be retransmitted multiple times over a subflow, there is a risk of blocking the send window. In this case, the MPTCP sender can decide to terminate the subflow that is behaving badly by sending a RST, using an appropriate MP_TCPRST (Section 3.6) error code.
MPTCP送信者は、任意のサブフローで受信されたデータACKと、データが送信されたすべてのサブフローによるサブフローレベルの両方で確認されるまで、送信バッファーからデータを解放してはなりません（MUST NOT）。前者の条件は接続の活性を保証し、後者の条件はデータを再送信する必要があるときにサブフローの活性と自己整合性を保証します。ただし、一部のデータをサブフローで複数回再送信する必要がある場合は、送信ウィンドウをブロックするリスクがあることに注意してください。この場合、MPTCP送信者は、適切なMP_TCPRST（セクション3.6）エラーコードを使用して、RSTを送信することにより、動作が正しくないサブフローを終了することを決定できます。
The Data ACK MAY be included in all segments; however, optimizations SHOULD be considered in more advanced implementations, where the Data ACK is present in segments only when the Data ACK value advances, and this behavior MUST be treated as valid. This behavior ensures that the send buffer is freed, while reducing overhead when the data transfer is unidirectional.
データACKはすべてのセグメントに含まれる場合があります。ただし、最適化は、データACK値が進んだときにのみデータACKがセグメントに存在する、より高度な実装で検討する必要があります（SHOULD）。この動作は有効として扱う必要があります。この動作により、送信バッファーが確実に解放され、データ転送が単方向の場合のオーバーヘッドが削減されます。
In regular TCP, a FIN announces to the receiver that the sender has no more data to send. In order to allow subflows to operate independently and to keep the appearance of TCP over the wire, a FIN in MPTCP only affects the subflow on which it is sent. This allows nodes to exercise considerable freedom over which paths are in use at any one time. The semantics of a FIN remain as for regular TCP; i.e., it is not until both sides have ACKed each other's FINs that the subflow is fully closed.
通常のTCPでは、FINは受信側に送信側に送信するデータがないことを通知します。サブフローが独立して動作し、回線上でTCPの外観を維持できるようにするために、MPTCPのFINは、サブフローが送信されるサブフローにのみ影響します。これにより、ノードはいつでも使用中のパスに対してかなりの自由度を行使できます。 FINのセマンティクスは通常のTCPの場合と同じです。つまり、サブフローが完全に閉じられるのは、両側が互いのFINにACKするまでです。
When an application calls close() on a socket, this indicates that it has no more data to send; for regular TCP, this would result in a FIN on the connection. For MPTCP, an equivalent mechanism is needed; this is referred to as the DATA_FIN.
アプリケーションがソケットでclose（）を呼び出すと、これは送信するデータがなくなったことを示します。通常のTCPの場合、これにより接続でFINが発生します。 MPTCPの場合、同等のメカニズムが必要です。これはDATA_FINと呼ばれます。
A DATA_FIN is an indication that the sender has no more data to send, and as such it can be used to verify that all data has been successfully received. A DATA_FIN, as with the FIN on a regular TCP connection, is a unidirectional signal.
DATA_FINは、送信者に送信するデータがないことを示しているため、すべてのデータが正常に受信されたことを確認するために使用できます。 DATA_FINは、通常のTCP接続のFINと同様に、単方向信号です。
The DATA_FIN is signaled by setting the "F" flag in the DSS option (Figure 9) to 1. A DATA_FIN occupies 1 octet (the final octet) of the connection-level sequence space. Note that the DATA_FIN is included in the Data-Level Length but not at the subflow level: for example, a segment with a DSN value of 80 and a Data-Level Length of 11, with DATA_FIN set, would map 10 octets from the subflow into data sequence space 80-89, and the DATA_FIN would be DSN 90; therefore, this segment, including DATA_FIN, would be acknowledged with a DATA_ACK of 91.
DATA_FINは、DSSオプション（図9）の「F」フラグを1に設定することによって通知されます。DATA_FINは、接続レベルのシーケンススペースの1オクテット（最後のオクテット）を占有します。 DATA_FINはデータレベルの長さには含まれますが、サブフローレベルには含まれません。たとえば、DSN値が80でデータレベルの長さが11で、DATA_FINが設定されているセグメントは、サブフローから10オクテットをマッピングします。データシーケンススペース80〜89に、DATA_FINはDSN 90になります。したがって、DATA_FINを含むこのセグメントは、91のDATA_ACKで確認されます。
Note that when the DATA_FIN is not attached to a TCP segment containing data, the DSS MUST have a subflow sequence number of 0, a Data-Level Length of 1, and the data sequence number that corresponds with the DATA_FIN itself. The checksum in this case will only cover the pseudo-header.
DATA_FINがデータを含むTCPセグメントにアタッチされていない場合、DSSはサブフローシーケンス番号0、データレベル長1、およびDATA_FIN自体に対応するデータシーケンス番号を持たなければならないことに注意してください。この場合のチェックサムは、疑似ヘッダーのみを対象とします。
A DATA_FIN has the same semantics and behavior as a regular TCP FIN, but at the connection level. Notably, it is only DATA_ACKed once all data has been successfully received at the connection level. Note, therefore, that a DATA_FIN is decoupled from a subflow FIN. It is only permissible to combine these signals on one subflow if there is no data outstanding on other subflows. Otherwise, it may be necessary to retransmit data on different subflows. Essentially, a host MUST NOT close all functioning subflows unless it is safe to do so, i.e., until all outstanding data has been DATA_ACKed or until the segment with the DATA_FIN flag set is the only outstanding segment.
DATA_FINのセマンティクスと動作は通常のTCP FINと同じですが、接続レベルです。特に、接続レベルですべてのデータが正常に受信されると、DATA_ACKのみが返されます。したがって、DATA_FINはサブフローFINから切り離されていることに注意してください。他のサブフローで未解決のデータがない場合にのみ、これらの信号を1つのサブフローで組み合わせることが許可されます。そうでない場合は、異なるサブフローでデータを再送信する必要がある場合があります。基本的に、ホストは、安全である限り、つまり、すべての未処理のデータがDATA_ACKされるまで、またはDATA_FINフラグが設定されたセグメントが唯一の未処理のセグメントになるまで、機能しているすべてのサブフローを閉じてはなりません。
Once a DATA_FIN has been acknowledged, all remaining subflows MUST be closed with standard FIN exchanges. Both hosts SHOULD send FINs on all subflows, as a courtesy, to allow middleboxes to clean up state even if an individual subflow has failed. Reducing the timeouts (MSL) on subflows at end hosts after receiving a DATA_FIN is also encouraged. In particular, any subflows where there is still outstanding data queued (which has been retransmitted on other subflows in order to get the DATA_FIN acknowledged) MAY be closed with a RST with an MP_TCPRST (Section 3.6) error code for "too much outstanding data".
DATA_FINが確認されたら、残りのすべてのサブフローを標準のFIN交換で閉じる必要があります。両方のホストは、個々のサブフローが失敗した場合でもミドルボックスが状態をクリーンアップできるように、礼儀としてすべてのサブフローにFINを送信する必要があります（SHOULD）。 DATA_FINを受信した後のエンドホストでのサブフローのタイムアウト（MSL）の削減も推奨されます。特に、未処理のデータがキューに残っているサブフロー（DATA_FINを確認するために他のサブフローで再送信されたもの）は、「未処理のデータが多すぎます」というエラーコードがMP_TCPRST（セクション3.6）のRSTで閉じられる場合があります。 。
A connection is considered closed once both hosts' DATA_FINs have been acknowledged by DATA_ACKs.
両方のホストのDATA_FINがDATA_ACKによって確認されると、接続は閉じられたと見なされます。
As specified above, a standard TCP FIN on an individual subflow only shuts down the subflow on which it was sent. If all subflows have been closed with a FIN exchange but no DATA_FIN has been received and acknowledged, the MPTCP connection is treated as closed only after a timeout. This implies that an implementation will have TIME_WAIT states at both the subflow level and the connection level (see Appendix D). This permits "break-before-make" scenarios where connectivity is lost on all subflows before a new one can be re-established.
上記のように、個々のサブフローの標準TCP FINは、それが送信されたサブフローのみをシャットダウンします。すべてのサブフローがFIN交換で閉じられたが、DATA_FINが受信および確認されなかった場合、MPTCP接続はタイムアウト後にのみ閉じられたものとして扱われます。これは、実装がサブフローレベルと接続レベルの両方でTIME_WAIT状態になることを意味します（付録Dを参照）。これにより、「break-before-make」シナリオが可能になり、新しいサブフローを再確立する前に、すべてのサブフローで接続が失われます。
Regular TCP advertises a receive window in each packet, telling the sender how much data the receiver is willing to accept past the cumulative ACK. The receive window is used to implement flow control, throttling down fast senders when receivers cannot keep up.
通常のTCPは、各パケットで受信ウィンドウをアドバタイズし、受信者が累積ACKを超えて受け入れたいデータの量を送信者に伝えます。受信ウィンドウはフロー制御を実装するために使用され、受信側が追いつけないときに高速送信側を抑制します。
MPTCP also uses a unique receive window, shared between the subflows. The idea is to allow any subflow to send data as long as the receiver is willing to accept it. The alternative -- maintaining per-subflow receive windows -- could end up stalling some subflows while others would not use up their window.
MPTCPは、サブフロー間で共有される一意の受信ウィンドウも使用します。アイデアは、受信者がデータを受け入れる用意がある限り、任意のサブフローがデータを送信できるようにすることです。別の方法、つまりサブフローごとの受信ウィンドウを維持すると、一部のサブフローが停止し、他のサブフローがウィンドウを使い果たしなくなる可能性があります。
The receive window is relative to the DATA_ACK. As in TCP, a receiver MUST NOT shrink the right edge of the receive window (i.e., DATA_ACK + receive window). The receiver will use the data sequence number to tell if a packet should be accepted at the connection level.
受信ウィンドウはDATA_ACKに関連しています。 TCPの場合と同様に、受信者は受信ウィンドウの右端を縮小してはなりません（つまり、DATA_ACK +受信ウィンドウ）。受信側は、データシーケンス番号を使用して、接続レベルでパケットを受け入れる必要があるかどうかを通知します。
When deciding to accept packets at the subflow level, regular TCP checks the sequence number in the packet against the allowed receive window. With MPTCP, such a check is done using only the connection-level window. A sanity check SHOULD be performed at the subflow level to ensure that the subflow and mapped sequence numbers meet the following test: SSN - SUBFLOW_ACK <= DSN - DATA_ACK, where SSN is the subflow sequence number of the received packet and SUBFLOW_ACK is the RCV.NXT (next expected sequence number) of the subflow (with the equivalent connection-level definitions for DSN and DATA_ACK).
サブフローレベルでパケットを受け入れることを決定すると、通常のTCPは許可された受信ウィンドウに対してパケットのシーケンス番号をチェックします。 MPTCPでは、このようなチェックは接続レベルのウィンドウのみを使用して行われます。サニティチェックは、サブフローレベルで実行して、サブフローとマップされたシーケンス番号が次のテストを満たすことを確認する必要があります。SSN-SUBFLOW_ACK <= DSN-DATA_ACK。サブフローのNXT（次に予期されるシーケンス番号）（DSNおよびDATA_ACKの同等の接続レベル定義を使用）。
In regular TCP, once a segment is deemed in-window, it is put in either the in-order receive queue or the out-of-order queue. In Multipath TCP, the same thing happens, but at the connection level: a segment is placed in the connection-level in-order or out-of-order queue if it is in-window at both the connection level and the subflow level. The stack still has to remember, for each subflow, which segments were received successfully so that it can ACK them at the subflow level appropriately. Typically, this will be implemented by keeping per-subflow out-of-order queues (containing only message headers -- not the payloads) and remembering the value of the cumulative ACK.
通常のTCPでは、セグメントがウィンドウ内と見なされると、順序付き受信キューまたは順序外キューのいずれかに配置されます。マルチパスTCPでも同じことが起こりますが、接続レベルで行われます。接続レベルとサブフローレベルの両方でウィンドウ内にある場合、セグメントは接続レベルの順序どおりまたは順序外のキューに配置されます。スタックは、サブフローごとに、サブフローレベルで適切にACKできるように、正常に受信されたセグメントを覚えておく必要があります。通常、これは、サブフローごとの順不同キュー（ペイロードではなくメッセージヘッダーのみを含む）を保持し、累積ACKの値を記憶することで実装されます。
It is important for implementers to understand how large a receive buffer is appropriate. The lower bound for full network utilization is the maximum bandwidth-delay product of any one of the paths. However, this might be insufficient when a packet is lost on a slower subflow and needs to be retransmitted (see Section 3.3.6). A tight upper bound would be the maximum round-trip time (RTT) of any path multiplied by the total bandwidth available across all paths. This permits all subflows to continue at full speed while a packet is fast-retransmitted on the maximum RTT path. Even this might be insufficient to maintain full performance in the event of a retransmit timeout on the maximum RTT path. Determining the relationship between retransmission strategies and receive buffer sizing is left for future study.
実装者にとって、受信バッファの大きさが適切であることを理解することが重要です。完全なネットワーク使用率の下限は、いずれかのパスの最大帯域幅遅延積です。ただし、低速のサブフローでパケットが失われ、再送信する必要がある場合は、これでは不十分な場合があります（セクション3.3.6を参照）。厳密な上限は、すべてのパスで利用可能な合計帯域幅を乗じたパスの最大往復時間（RTT）です。これにより、パケットが最大RTTパスで高速に再送信されている間、すべてのサブフローをフルスピードで続行できます。これでも、最大RTTパスで再送信タイムアウトが発生した場合に完全なパフォーマンスを維持するには不十分な場合があります。再送信戦略と受信バッファーのサイズ設定の関係の決定は、今後の研究に残します。
The sender remembers receive window advertisements from the receiver. It should only update its local receive window values when the largest sequence number allowed (i.e., DATA_ACK + receive window) increases on the receipt of a DATA_ACK. This is important for allowing the use of paths with different RTTs and thus different feedback loops.
送信者は、受信者から受信したウィンドウ広告を覚えています。 DATA_ACKの受信時に許可された最大シーケンス番号（つまり、DATA_ACK +受信ウィンドウ）が増加した場合にのみ、ローカルの受信ウィンドウ値を更新する必要があります。これは、RTTが異なる、したがってフィードバックループが異なるパスを使用できるようにするために重要です。
MPTCP uses a single receive window across all subflows, and if the receive window was guaranteed to be unchanged end to end, a host could always read the most recent receive window value. However, some classes of middleboxes may alter the TCP-level receive window. Typically, these will shrink the offered window, although for short periods of time it may be possible for the window to be larger (however, note that this would not continue for long periods, since ultimately the middlebox must keep up with delivering data to the receiver). Therefore, if receive window sizes differ on multiple subflows, when sending data MPTCP SHOULD take the largest of the most recent window sizes as the one to use in calculations. This rule is implicit in the requirement not to reduce the right edge of the window.
MPTCPはすべてのサブフローで単一の受信ウィンドウを使用します。受信ウィンドウがエンドツーエンドで変更されないことが保証されている場合、ホストは常に最新の受信ウィンドウ値を読み取ることができます。ただし、ミドルボックスのクラスによっては、TCPレベルの受信ウィンドウが変更される場合があります。通常、これらは提供されるウィンドウを縮小しますが、短期間ではウィンドウが大きくなる可能性があります（ただし、これは長期間継続しないことに注意してください。最終的にミドルボックスは、データの配信に追いつく必要があるためです。レシーバー）。したがって、受信ウィンドウサイズが複数のサブフローで異なる場合、データを送信するときに、MPTCPは最新のウィンドウサイズの最大のものを計算に使用するものとして使用する必要があります（SHOULD）。このルールは、ウィンドウの右端を縮小しないという要件に暗黙的に含まれています。
The sender MUST also remember the receive windows advertised by each subflow. The allowed window for subflow i is (ack_i, ack_i + rcv_wnd_i), where ack_i is the subflow-level cumulative ACK of subflow i. This ensures that data will not be sent to a middlebox unless there is enough buffering for the data.
送信者は、各サブフローによってアドバタイズされた受信ウィンドウも記憶する必要があります。サブフローiに許可されるウィンドウは（ack_i、ack_i + rcv_wnd_i）です。ここで、ack_iはサブフローiのサブフローレベルの累積ACKです。これにより、データに十分なバッファリングがない限り、データがミドルボックスに送信されなくなります。
Putting the two rules together, we get the following: a sender is allowed to send data segments with data-level sequence numbers between (DATA_ACK, DATA_ACK + receive_window). Each of these segments will be mapped onto subflows, as long as subflow sequence numbers are in the allowed windows for those subflows. Note that subflow sequence numbers do not generally affect flow control if the same receive window is advertised across all subflows. They will perform flow control for those subflows with a smaller advertised receive window.
2つのルールをまとめると、次のようになります。送信者は、（DATA_ACK、DATA_ACK + receive_window）の間にデータレベルのシーケンス番号を持つデータセグメントを送信できます。これらの各セグメントは、サブフローのシーケンス番号がそれらのサブフローの許可されたウィンドウ内にある限り、サブフローにマップされます。すべてのサブフローにわたって同じ受信ウィンドウがアドバタイズされる場合、サブフローシーケンス番号は一般にフロー制御に影響を与えないことに注意してください。アドバタイズされた受信ウィンドウが小さいサブフローに対してフロー制御を実行します。
The send buffer MUST, at a minimum, be as big as the receive buffer, to enable the sender to reach maximum throughput.
送信者が最大スループットに到達できるように、送信バッファは、少なくとも受信バッファと同じ大きさである必要があります。
The Data Sequence Mapping allows senders to resend data with the same data sequence number on a different subflow. When doing this, a host MUST still retransmit the original data on the original subflow, in order to preserve the subflow's integrity (middleboxes could replay old data and/or could reject holes in subflows), and a receiver will ignore these retransmissions. While this is clearly suboptimal, for compatibility reasons this is sensible behavior. Optimizations could be negotiated in future versions of this protocol. Note also that this property would also permit a sender to always send the same data, with the same data sequence number, on multiple subflows, if desired for reliability reasons.
データシーケンスマッピングにより、送信者は同じデータシーケンス番号のデータを別のサブフローに再送信できます。これを行うとき、サブフローの整合性を維持するために、ホストは引き続き元のサブフローで元のデータを再送信する必要があります（ミドルボックスは古いデータを再生したり、サブフローのホールを拒否したりする可能性があります）。受信者はこれらの再送信を無視します。これは明らかに最適ではありませんが、互換性の理由から、これは賢明な動作です。最適化は、このプロトコルの将来のバージョンで交渉される可能性があります。信頼性の理由から必要な場合は、このプロパティを使用すると、送信者が複数のサブフローで同じデータシーケンス番号を使用して常に同じデータを送信できることにも注意してください。
This protocol specification does not mandate any mechanisms for handling retransmissions, and much will be dependent upon local policy (as discussed in Section 3.3.8). One can imagine aggressive connection-level retransmission policies where every packet lost at the subflow level is retransmitted on a different subflow (hence wasting bandwidth but possibly reducing application-to-application delays) or conservative retransmission policies where connection-level retransmissions are only used after a few subflow-level retransmission timeouts occur.
このプロトコル仕様は、再送信を処理するためのメカニズムを義務付けておらず、多くはローカルポリシーに依存します（セクション3.3.8で説明）。サブフローレベルで失われたすべてのパケットが別のサブフローで再送信される積極的な接続レベルの再送信ポリシー（帯域幅を浪費するが、アプリケーション間の遅延を減らす可能性がある）または接続レベルの再送信が後にのみ使用される保守的な再送信ポリシーを想像できます。いくつかのサブフローレベルの再送信タイムアウトが発生します。
It is envisaged that a standard connection-level retransmission mechanism would be implemented around a connection-level data queue: all segments that haven't been DATA_ACKed are stored. A timer is set when the head of the connection level is ACKed at the subflow level but is not DATA_ACKed at the data level. This timer will guard against retransmission failures by middleboxes that proactively ACK data.
標準の接続レベルの再送信メカニズムが接続レベルのデータキューの周りに実装されることが想定されています。DATA_ACKされていないすべてのセグメントが格納されます。接続レベルの先頭がサブフローレベルでACKされ、データレベルでDATA_ACKされない場合、タイマーが設定されます。このタイマーは、積極的にデータにACKを送信するミドルボックスによる再送信の失敗を防ぎます。
The sender MUST keep data in its send buffer as long as the data has not been acknowledged both (1) at the connection level and (2) on all subflows on which it has been sent. In this way, the sender can always retransmit the data if needed, on the same subflow or on a different one. A special case is when a subflow fails: the sender will typically resend the data on other working subflows after a timeout and will keep trying to retransmit the data on the failed subflow too. The sender will declare the subflow failed after a predefined upper bound on retransmissions is reached (which MAY be lower than the usual TCP limits of the MSL) or on the receipt of an ICMP error, and only then delete the outstanding data segments.
送信者は、データが（1）接続レベルで、および（2）データが送信されたすべてのサブフローで確認されていない限り、データを送信バッファーに保持する必要があります。このようにして、送信者は同じサブフローまたは別のサブフローで、必要に応じて常にデータを再送信できます。特殊なケースは、サブフローが失敗した場合です。送信者は通常、タイムアウト後に他の動作中のサブフローでデータを再送信し、失敗したサブフローでもデータの再送信を試み続けます。送信者は、再送信の事前定義された上限に達した後（MSLの通常のTCP制限よりも低い場合があります）、またはICMPエラーの受信時にサブフローが失敗したと宣言し、未処理のデータセグメントのみを削除します。
If multiple retransmissions that indicate that a subflow is performing badly are triggered, this MAY lead to a host resetting the subflow with a RST. However, additional research is required to understand the heuristics of how and when to reset underperforming subflows. For example, a highly asymmetric path may be misdiagnosed as underperforming. A RST for this purpose SHOULD be accompanied by an "Unacceptable performance" MP_TCPRST option (Section 3.6).
サブフローのパフォーマンスが悪いことを示す複数の再送信がトリガーされた場合、これによりホストがRSTでサブフローをリセットする可能性があります。ただし、パフォーマンスの低いサブフローをリセットする方法とタイミングのヒューリスティックを理解するには、追加の調査が必要です。たとえば、非対称性の高いパスは、パフォーマンスが低いと誤って診断されることがあります。この目的のためのRSTは、「許容できないパフォーマンス」のMP_TCPRSTオプション（セクション3.6）を伴う必要があります（SHOULD）。
Different subflows in an MPTCP connection have different congestion windows. To achieve fairness at bottlenecks and resource pooling, it is necessary to couple the congestion windows in use on each subflow, in order to push most traffic to uncongested links. One algorithm for achieving this is presented in [RFC6356]; the algorithm does not achieve perfect resource pooling but is "safe" in that it is readily deployable in the current Internet. By this we mean that it does not take up more capacity on any one path than if it was a single path flow using only that route, so this ensures fair coexistence with single-path TCP at shared bottlenecks.
MPTCP接続の異なるサブフローには、異なる輻輳ウィンドウがあります。ボトルネックとリソースプールで公平性を実現するには、ほとんどのトラフィックを輻輳していないリンクにプッシュするために、各サブフローで使用中の輻輳ウィンドウを結合する必要があります。これを達成するための1つのアルゴリズムは[RFC6356]に提示されています。アルゴリズムは完全なリソースプーリングを実現しませんが、現在のインターネットに容易に展開できるという点で「安全」です。これは、1つのパスがそのルートのみを使用する単一パスフローである場合よりも、1つのパスで多くの容量を消費しないことを意味します。これにより、共有ボトルネックで単一パスTCPとの公平な共存が保証されます。
It is foreseeable that different congestion controllers will be implemented for MPTCP, each aiming to achieve different properties in the resource pooling / fairness / stability design space, as well as those for achieving different properties in quality of service, reliability, and resilience.
さまざまな輻輳コントローラーがMPTCPに実装され、それぞれがリソースプーリング/公平性/安定性の設計スペースで異なるプロパティを実現することを目的としており、サービスの品質、信頼性、および回復力で異なるプロパティを実現することが予想されます。
Regardless of the algorithm used, the design of MPTCP aims to provide the congestion control implementations with sufficient information to make the right decisions; this information includes, for each subflow, which packets were lost and when.
使用されるアルゴリズムに関係なく、MPTCPの設計は、輻輳制御の実装に適切な決定を行うのに十分な情報を提供することを目的としています。この情報には、サブフローごとに、どのパケットがいつ失われたかが含まれます。
Within a local MPTCP implementation, a host may use any local policy it wishes to decide how to share the traffic to be sent over the available paths.
ローカルMPTCP実装内では、ホストは、利用可能なパスを介して送信されるトラフィックを共有する方法を決定したいローカルポリシーを使用できます。
In the typical use case, where the goal is to maximize throughput, all available paths will be used simultaneously for data transfer, using coupled congestion control as described in [RFC6356]. It is expected, however, that other use cases will appear.
[RFC6356]で説明されているように、結合された輻輳制御を使用して、スループットを最大化することを目的とする一般的な使用例では、すべての利用可能なパスが同時にデータ転送に使用されます。ただし、他のユースケースが現れることが予想されます。
For instance, one possibility is an "all-or-nothing" approach, i.e., have a second path ready for use in the event of failure of the first path, but alternatives could include entirely saturating one path before using an additional path (the "overflow" case). Such choices would be most likely based on the monetary cost of links but may also be based on properties such as the delay or jitter of links, where stability (of delay or bandwidth) is more important than throughput. Application requirements such as these are discussed in detail in [RFC6897].
たとえば、1つの可能性は、「オールオアナッシング」アプローチです。つまり、最初のパスで障害が発生した場合に使用できる2番目のパスを用意しますが、代替策として、追加のパス（ 「オーバーフロー」の場合）。このような選択は、リンクの金銭的コストに基づく可能性が最も高いですが、リンクの遅延やジッターなどのプロパティにも基づく場合があり、スループットよりも（遅延または帯域幅の）安定性が重要です。これらのようなアプリケーション要件は[RFC6897]で詳細に議論されます。
The ability to make effective choices at the sender requires full knowledge of the path "cost", which is unlikely to be the case. It would be desirable for a receiver to be able to signal their own preferences for paths, since they will often be the multihomed party and may have to pay for metered incoming bandwidth.
送信側で効果的な選択を行う機能には、パスの「コスト」についての完全な知識が必要ですが、そうではありません。それらはしばしばマルチホームパーティであり、計測された着信帯域幅の代金を支払わなければならない可能性があるため、受信機がパスの独自の設定を通知できることが望ましいでしょう。
To enable this behavior, the MP_JOIN option (see Section 3.2) contains the "B" bit, which allows a host to indicate to its peer that this path should be treated as a backup path to use only in the event of failure of other working subflows (i.e., a subflow where the receiver has indicated that B=1 SHOULD NOT be used to send data unless there are no usable subflows where B=0).
この動作を有効にするには、MP_JOINオプション（セクション3.2を参照）に「B」ビットを含めます。これにより、ホストは、このパスをバックアップパスとして処理して、他の動作に障害が発生した場合にのみ使用することをピアに示すことができますサブフロー（つまり、B = 0の使用可能なサブフローがない場合を除き、データの送信にB = 1を使用してはならないことを受信者が示したサブフロー）。
In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as a backup should now take priority over all remaining subflows). Therefore, the MP_PRIO option, shown in Figure 11, can be used to change the "B" flag of the subflow on which it is sent.
使用可能なパスのセットが変更された場合、ホストはサブフローの優先度の変更をピアに通知したい場合があります（たとえば、以前にバックアップとして設定されていたサブフローが残りのすべてのサブフローよりも優先されるようになります）。したがって、図11に示すMP_PRIOオプションを使用して、送信されるサブフローの「B」フラグを変更できます。
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
+---------------+---------------+-------+-----+-+
| Kind | Length |Subtype|(rsv)|B|
+---------------+---------------+-------+-----+-+
Figure 11: Change Subflow Priority (MP_PRIO) Option
図11：サブフローの優先度の変更（MP_PRIO）オプション
Another use of the MP_PRIO option is to set the "B" flag on a subflow to cleanly "retire" its use before closing it and removing it with REMOVE_ADDR (Section 3.4.2) -- for example, to support make-before-break session continuity, where new subflows are added before the previously used subflows are closed.
MP_PRIOオプションの別の用途は、サブフローの「B」フラグを設定して、その使用を完全に「リタイア」してから、REMOVE_ADDR（セクション3.4.2）で削除することです。たとえば、make-before-breakをサポートします。セッションの継続性。以前に使用されたサブフローが閉じられる前に、新しいサブフローが追加されます。
It should be noted that the backup flag is a request from a data receiver to a data sender only, and the data sender SHOULD adhere to these requests. A host cannot assume that the data sender will do so, however, since local policies -- or technical difficulties -- may override MP_PRIO requests. Note also that this signal applies to a single direction, and so the sender of this option could choose to continue using the subflow to send data even if it has signaled B=1 to the other host.
バックアップフラグはデータレシーバーからデータセンダーのみへの要求であり、データセンダーはこれらの要求に従う必要があることに注意してください。ただし、ローカルポリシーまたは技術的な問題によりMP_PRIO要求が上書きされる可能性があるため、ホストはデータ送信者がそうすることを想定できません。また、この信号は単一方向に適用されるため、このオプションの送信者は、B = 1を他のホストに通知した場合でも、サブフローを使用してデータを送信し続けることもできます。
We use the term "path management" to refer to the exchange of information about additional paths between hosts, which in this design is managed by multiple addresses at hosts. For more details regarding the architectural thinking behind this design, see the MPTCP architecture document [RFC6182].
「パス管理」という用語は、ホスト間の追加のパスに関する情報の交換を指すために使用します。この設計では、ホストの複数のアドレスによって管理されます。この設計の背後にあるアーキテクチャの考え方に関する詳細については、MPTCPアーキテクチャドキュメント[RFC6182]を参照してください。
This design makes use of two methods of sharing such information, and both can be used on a connection. The first is the direct setup of new subflows (described in Section 3.2), where the initiator has an additional address. The second method (described in the following subsections) signals addresses explicitly to the other host to allow it to initiate new subflows. The two mechanisms are complementary: the first is implicit and simple, while the second (explicit) is more complex but is more robust. Together, these mechanisms allow addresses to change in flight (and thus support operation through NATs, since the source address need not be known); they also allow the signaling of previously unknown addresses and of addresses belonging to other address families (e.g., both IPv4 and IPv6).
この設計では、このような情報を共有する2つの方法を利用しており、どちらも接続で使用できます。 1つ目は、イニシエーターが追加のアドレスを持つ新しいサブフローの直接セットアップです（セクション3.2で説明）。 2番目の方法（以下のサブセクションで説明）は、他のホストにアドレスを明示的に通知して、新しいサブフローを開始できるようにします。 2つのメカニズムは補完的です。最初のメカニズムは暗黙的で単純ですが、2番目のメカニズム（明示的）はより複雑ですがより堅牢です。これらのメカニズムを組み合わせることで、アドレスを変更することができます（ソースアドレスを知る必要がないため、NATを介した操作をサポートします）。また、以前は不明だったアドレスや、他のアドレスファミリー（IPv4とIPv6の両方など）に属するアドレスのシグナリングも可能です。
Here is an example of typical operation of the protocol:
これは、プロトコルの典型的な操作の例です：
* An MPTCP connection is initially set up between address/port A1 of Host A and address/port B1 of Host B. If Host A is multihomed and multiaddressed, it can start an additional subflow from its address A2 to B1, by sending a SYN with an MP_JOIN option from A2 to B1, using B's previously declared token for this connection. Alternatively, if B is multihomed, it can try to set up a new subflow from B2 to A1, using A's previously declared token. In either case, the SYN will be sent to the port already in use for the original subflow on the receiving host.
* MPTCP接続は、最初にホストAのアドレス/ポートA1とホストBのアドレス/ポートB1の間にセットアップされます。ホストAがマルチホームでマルチアドレスの場合、SYNをこの接続にBが以前に宣言したトークンを使用して、A2からB1へのMP_JOINオプション。あるいは、Bがマルチホームである場合、Aの以前に宣言されたトークンを使用して、B2からA1への新しいサブフローのセットアップを試みることができます。どちらの場合でも、SYNは受信ホストの元のサブフローですでに使用されているポートに送信されます。
* Simultaneously (or after a timeout), an ADD_ADDR option (Section 3.4.1) is sent on an existing subflow, informing the receiver of the sender's alternative address(es). The recipient can use this information to open a new subflow to the sender's additional address(es). In our example, A will send the ADD_ADDR option informing B of address/port A2. The mix of using the SYN-based option and the ADD_ADDR option, including timeouts, is implementation specific and can be tailored to agree with local policy.
* 同時に（またはタイムアウト後に）、ADD_ADDRオプション（セクション3.4.1）が既存のサブフローで送信され、送信者の代替アドレスを受信者に通知します。受信者はこの情報を使用して、送信者の追加アドレスへの新しいサブフローを開くことができます。この例では、AはBにアドレス/ポートA2を通知するADD_ADDRオプションを送信します。タイムアウトを含む、SYNベースのオプションとADD_ADDRオプションの使用の組み合わせは実装固有であり、ローカルポリシーに一致するように調整できます。
* If subflow A2-B1 is successfully set up, Host B can use the Address ID in the MP_JOIN option to correlate this source address with the ADD_ADDR option that will also arrive on an existing subflow; now B knows not to open A2-B1, ignoring the ADD_ADDR. Otherwise, if B has not received the A2-B1 MP_JOIN SYN but received the ADD_ADDR, it can try to initiate a new subflow from one or more of its addresses to address A2. This permits new sessions to be opened if one host is behind a NAT.
* サブフローA2-B1が正常にセットアップされた場合、ホストBはMP_JOINオプションのアドレスIDを使用して、このソースアドレスを、既存のサブフローに到着するADD_ADDRオプションと関連付けることができます。これでBは、ADD_ADDRを無視してA2-B1を開かないことを認識します。そうでない場合、BはA2-B1 MP_JOIN SYNを受信していないがADD_ADDRを受信している場合、1つ以上のアドレスからアドレスA2への新しいサブフローの開始を試みることができます。これにより、1つのホストがNATの背後にある場合、新しいセッションを開くことができます。
Other ways of using the two signaling mechanisms are possible; for instance, signaling addresses in other address families can only be done explicitly using the Add Address (ADD_ADDR) option.
2つの信号メカニズムを使用する他の方法も可能です。たとえば、他のアドレスファミリのシグナリングアドレスは、アドレスの追加（ADD_ADDR）オプションを使用して明示的にのみ実行できます。
The ADD_ADDR MPTCP option announces additional addresses (and, optionally, ports) on which a host can be reached (Figure 12). This option can be used at any time during a connection, depending on when the sender wishes to enable multiple paths and/or when paths become available. As with all MPTCP signals, the receiver MUST undertake standard TCP validity checks, e.g., per [RFC5961], before acting upon it.
ADD_ADDR MPTCPオプションは、ホストに到達できる追加のアドレス（およびオプションでポート）を通知します（図12）。このオプションは、送信者が複数のパスを有効にしたい場合やパスが使用可能になった場合に応じて、接続中いつでも使用できます。すべてのMPTCP信号と同様に、受信者は、[RFC5961]に従って、それに基づいて動作する前に、標準のTCP有効性チェックを実行する必要があります。
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
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype|(rsv)|E| Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4: 4 octets / IPv6: 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) | |
+-------------------------------+ |
| Truncated HMAC (8 octets, if E=0) |
| +-------------------------------+
| |
+-------------------------------+
Figure 12: Add Address (ADD_ADDR) Option
図12：アドレスの追加（ADD_ADDR）オプション
Every address has an Address ID that can be used for uniquely identifying the address within a connection for address removal. The Address ID is also used to identify MP_JOIN options (see Section 3.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は、同じアドレスに関連するMP_JOINオプション（セクション3.2を参照）を識別するためにも使用されます。アドレスIDは、オプションの送信者のアドレスを（接続の範囲内で）一意に識別しなければなりません（MUST）。このようなIDを割り当てるメカニズムは実装固有です。
All Address IDs learned via either MP_JOIN or ADD_ADDR SHOULD be stored by the receiver in a data structure that gathers all the Address-ID-to-address mappings for a connection (identified by a token pair). In this way, there is a stored mapping between the Address ID, observed source address, and token pair for future processing of control information for a connection. Note that an implementation MAY discard incoming address advertisements at will -- for example, to avoid updating mapping state or because advertised addresses are of no use to it (for example, IPv6 addresses when it has IPv4 only). Therefore, a host MUST treat address advertisements as soft state, and it MAY choose to refresh advertisements periodically. Note also that an implementation MAY choose to cache these address advertisements even if they are not currently relevant but may be relevant in the future, such as IPv4 addresses when IPv6 connectivity is available but IPv4 is awaiting DHCP.
MP_JOINまたはADD_ADDRのいずれかを介して学習されたすべてのアドレスIDは、（トークンペアで識別される）接続のすべてのアドレス-ID-to-アドレスマッピングを収集するデータ構造にレシーバーによって格納される必要があります（SHOULD）。このようにして、接続の制御情報を将来処理するために、アドレスID、観測された送信元アドレス、およびトークンペアの間にマッピングが保存されます。実装は、着信アドレスアドバタイズを自由に破棄できることに注意してください。たとえば、マッピングステートの更新を回避したり、アドバタイズされたアドレスが役に立たないためです（たとえば、IPv4のみのIPv6アドレス）。したがって、ホストはアドレスアドバタイズメントをソフトステートとして扱う必要があり、アドバタイズメントを定期的に更新することを選択できます（MAY）。また、実装はこれらのアドレスアドバタイズをキャッシュすることを選択してもよいことに注意してください。これらは現在は関係ないが、将来的には関係する可能性があります（IPv6接続は使用可能であるがIPv4がDHCPを待機している場合のIPv4アドレスなど）。
This option is shown in Figure 12. The illustration is sized for IPv4 addresses. For IPv6, the length of the address will be 16 octets (instead of 4).
このオプションを図12に示します。この図は、IPv4アドレス用にサイズ変更されています。 IPv6の場合、アドレスの長さは（4ではなく）16オクテットになります。
The 2 octets that specify the TCP port number to use are optional, 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 those used for the initial subflow (e.g., port 80 remains port 80 on all subflows, as does the ephemeral port at the client), there may be cases (such as port-based load balancing) where the explicit specification of a different port is required. If no port is specified, MPTCP SHOULD attempt to connect to the specified address on the same port as the port that is already in use by the subflow on which the ADD_ADDR signal was sent; this is discussed in more detail in Section 3.9.
使用するTCPポート番号を指定する2オクテットはオプションであり、それらの存在はオプションの長さから推測できます。大部分の使用例では、最初のサブフローに使用されるものと同じポートのペアが使用されることが予想されます（たとえば、ポート80は、クライアントの一時ポートと同様に、すべてのサブフローでポート80のままです）。ポートベースのロードバランシングなど）、異なるポートの明示的な指定が必要な場合。ポートが指定されていない場合、MPTCPは、ADD_ADDRシグナルが送信されたサブフローによってすでに使用されているポートと同じポートの指定されたアドレスへの接続を試行する必要があります（SHOULD）。これについては、セクション3.9で詳しく説明します。
The Truncated HMAC parameter present in this option is the rightmost 64 bits of an HMAC, negotiated and calculated in the same way as for MP_JOIN as described in Section 3.2. For this specification of MPTCP, as there is only one hash algorithm option specified, this will be HMAC as defined in [RFC2104], using the SHA-256 hash algorithm [RFC6234]. In the same way as for MP_JOIN, the key for the HMAC algorithm, in the case of the message transmitted by Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B followed by Key-A. These are the keys that were exchanged in the original MP_CAPABLE handshake. The message for the HMAC is the Address ID, IP address, and port that precede the HMAC in the ADD_ADDR option. If the port is not present in the ADD_ADDR option, the HMAC message will nevertheless include 2 octets of value zero. The rationale for the HMAC is to prevent unauthorized entities from injecting ADD_ADDR signals in an attempt to hijack a connection. Note that, additionally, 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 ADD_ADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option.
このオプションにあるTruncated HMACパラメータは、HMACの右端の64ビットであり、セクション3.2で説明したMP_JOINと同じ方法でネゴシエートおよび計算されます。このMPTCPの仕様では、ハッシュアルゴリズムオプションは1つしか指定されていないため、[RFC2104]で定義されているように、SHA-256ハッシュアルゴリズム[RFC6234]を使用したHMACになります。 MP_JOINの場合と同様に、HMACアルゴリズムのキーは、ホストAから送信されたメッセージの場合、Key-Aの後にKey-Bが続き、ホストBの場合はKey-Bの後に続きます。 Key-A。これらは、元のMP_CAPABLEハンドシェイクで交換されたキーです。 HMACのメッセージは、ADD_ADDRオプションでHMACの前にあるアドレスID、IPアドレス、およびポートです。 ADD_ADDRオプションにポートが存在しない場合でも、HMACメッセージには値0の2オクテットが含まれます。 HMACの理論的根拠は、無許可のエンティティーが接続を乗っ取ろうとしてADD_ADDR信号を注入するのを防ぐことです。さらに、このHMACの存在により、仲介者がキーを知らない限り、アドレスが飛行中に変更されるのを防ぎます。ホストがHMACを検証できないADD_ADDRオプションを受け取った場合、そのオプションは通知なく無視する必要があります（SHOULD）。
A set of four flags is present after the subtype and before the Address ID. Only the rightmost bit -- labeled "E" -- is assigned in this specification. The other bits are currently unassigned; they MUST be set to 0 by a sender and MUST be ignored by the receiver.
4つのフラグのセットは、サブタイプの後、アドレスIDの前にあります。この仕様では、「E」というラベルの付いた右端のビットのみが割り当てられています。他のビットは現在割り当てられていません。それらは送信者によって0に設定されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
The "E" flag exists to provide reliability for this option. Because this option will often be sent on pure ACKs, there is no guarantee of reliability. Therefore, a receiver receiving a fresh ADD_ADDR option (where E=0) will send the same option back to the sender, but not including the HMAC and with E=1, to indicate receipt. According to local policy, the lack of this type of "echo" can indicate to the initial ADD_ADDR sender that the ADD_ADDR needs to be retransmitted.
このオプションに信頼性を提供するために、「E」フラグが存在します。このオプションは純粋なACKで送信されることが多いため、信頼性は保証されません。したがって、新しいADD_ADDRオプション（ここでE = 0）を受信する受信者は、同じオプションを送信者に送り返しますが、HMACを含まず、E = 1で受信したことを示します。ローカルポリシーによると、このタイプの「エコー」の欠如は、ADD_ADDRを再送信する必要があることを最初のADD_ADDR送信者に示すことができます。
Due to the proliferation of NATs, it is reasonably likely that one host may attempt to advertise private addresses [RFC1918]. It is not desirable to prohibit this behavior, since there may be cases where both hosts have additional interfaces on the same private network, and a host MAY advertise such addresses. The MP_JOIN handshake to create a new subflow (Section 3.2) provides mechanisms to minimize security risks. The MP_JOIN message contains a 32-bit token that uniquely identifies the connection to the receiving host. If the token is unknown, the host will respond with a RST. In the unlikely event that the token is valid at the receiving host, subflow setup will continue, but the HMAC exchange must occur for authentication. The HMAC exchange will fail and will provide sufficient protection against two unconnected hosts accidentally setting up a new subflow upon the signal of a private address. Further security considerations around the issue of ADD_ADDR messages that accidentally misdirect, or maliciously direct, new MP_JOIN attempts are discussed in Section 5.
NATの急増により、1つのホストがプライベートアドレスのアドバタイズを試みる可能性はかなり高くなります[RFC1918]。両方のホストが同じプライベートネットワーク上に追加のインターフェースを持ち、ホストがそのようなアドレスをアドバタイズする場合があるため、この動作を禁止することは望ましくありません。新しいサブフローを作成するためのMP_JOINハンドシェイク（セクション3.2）は、セキュリティリスクを最小限に抑えるメカニズムを提供します。 MP_JOINメッセージには、受信ホストへの接続を一意に識別する32ビットトークンが含まれています。トークンが不明な場合、ホストはRSTで応答します。トークンが受信ホストで有効であるというまれなイベントでは、サブフローのセットアップは続行されますが、認証のためにHMAC交換が発生する必要があります。 HMAC交換は失敗し、プライベートアドレスの信号で誤って新しいサブフローを設定する2つの接続されていないホストに対する十分な保護を提供します。新しいMP_JOINの試みを誤って誤って、または悪意を持って誘導するADD_ADDRメッセージの問題に関するセキュリティ上の考慮事項については、セクション5で説明します。
A host that receives an ADD_ADDR but finds that a connection set up to that IP address and port number is unsuccessful SHOULD NOT perform further connection attempts to this address/port combination for this connection. A sender that wants to trigger a new incoming connection attempt on a previously advertised address/port combination can therefore refresh ADD_ADDR information by sending the option again.
ADD_ADDRを受信したが、そのIPアドレスとポート番号に設定された接続が失敗したことを検出したホストは、この接続のこのアドレス/ポートの組み合わせに対して、それ以上の接続試行を行わないでください。したがって、以前にアドバタイズされたアドレスとポートの組み合わせで新しい着信接続試行をトリガーする送信者は、オプションを再度送信することでADD_ADDR情報を更新できます。
A host can therefore send an ADD_ADDR message with an already-assigned Address ID, but the address MUST be the same as the address previously assigned to this Address ID. A new ADD_ADDR may have the same port number or a different port number. If the port number is different, the receiving host SHOULD try to set up a new subflow to this new address/port combination.
したがって、ホストは、すでに割り当てられたアドレスIDを使用してADD_ADDRメッセージを送信できますが、アドレスは、このアドレスIDに以前に割り当てられたアドレスと同じである必要があります。新しいADD_ADDRは、同じポート番号または異なるポート番号を持つ場合があります。ポート番号が異なる場合、受信ホストは、この新しいアドレスとポートの組み合わせに新しいサブフローをセットアップする必要があります（SHOULD）。
A host wishing to replace an existing Address ID MUST first remove the existing one (Section 3.4.2).
既存のアドレスIDを置き換えたいホストは、まず既存のものを削除しなければなりません（セクション3.4.2）。
During normal MPTCP operation, it is unlikely that there will be sufficient TCP option space for ADD_ADDR to be included along with those for data sequence numbering (Section 3.3.1). Therefore, it is expected that an MPTCP implementation will send the ADD_ADDR option on separate ACKs. As discussed earlier, however, an MPTCP implementation MUST NOT treat duplicate ACKs with any MPTCP option, with the exception of the DSS option, as indications of congestion [RFC5681], and an MPTCP implementation SHOULD NOT send more than two duplicate ACKs in a row for signaling purposes.
通常のMPTCP操作中、ADD_ADDRに十分なTCPオプションスペースがデータシーケンス番号（3.3.1）に含まれるスペースとともに含まれることはほとんどありません。したがって、MPTCP実装は、個別のACKでADD_ADDRオプションを送信することが予想されます。ただし、前述のように、MPTCP実装は、DSSオプションを除いて、MPTCPオプションを使用して重複したACKを輻輳の兆候として処理してはなりません[RFC5681]。シグナリング用。
If, during the lifetime of an MPTCP connection, a previously announced address becomes invalid (e.g., if the interface disappears or an IPv6 address is no longer preferred), the affected host SHOULD announce this situation so that the peer can remove subflows related to this address. Even if an address is not in use by an MPTCP connection, if it has been previously announced, an implementation SHOULD announce its removal. A host MAY also choose to announce that a valid IP address should not be used any longer -- for example, for make-before-break session continuity.
MPTCP接続の存続期間中に、以前にアナウンスされたアドレスが無効になる場合（たとえば、インターフェースが消えるか、IPv6アドレスが優先されなくなった場合）、影響を受けるホストはこの状況をアナウンスする必要があるため（SHOULD）、ピアはこれに関連するサブフローを削除できる住所。アドレスがMPTCP接続で使用されていない場合でも、以前にアナウンスされている場合、実装はその削除をアナウンスする必要があります（SHOULD）。ホストは、有効なIPアドレスが使用されなくなったことをアナウンスすることを選択することもできます（たとえば、メイクビフォアブレークセッションの継続性のため）。
This is achieved through the Remove Address (REMOVE_ADDR) option (Figure 13), which will remove a previously added address (or list of addresses) from a connection and terminate any subflows currently using that address.
これは、アドレスの削除（REMOVE_ADDR）オプション（図13）によって実現されます。これにより、以前に追加されたアドレス（またはアドレスのリスト）が接続から削除され、そのアドレスを現在使用しているサブフローが終了します。
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
+---------------+---------------+-------+-------+---------------+
| Kind |Length = 3 + n |Subtype|(resvd)| Address ID | ...
+---------------+---------------+-------+-------+---------------+
(followed by n-1 Address IDs, if required)
Figure 13: Remove Address (REMOVE_ADDR) Option
図13：アドレスの削除（REMOVE_ADDR）オプション
For security purposes, if a host receives a REMOVE_ADDR option, it must ensure that the affected path or paths are no longer in use before it instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger the sending of a TCP keepalive [RFC1122] on the path, and if a response is received, the path SHOULD NOT be removed. If the path is found to still be alive, the receiving host SHOULD no longer use the specified address for future connections, but it is the responsibility of the host that sent the REMOVE_ADDR to shut down the subflow. Before the address is removed, the requesting host MAY also use MP_PRIO (Section 3.3.8) to request that a path no longer be used. Typical TCP validity tests on the subflow (e.g., ensuring that sequence and ACK numbers are correct) MUST also be undertaken. An implementation can use indications of these test failures as part of intrusion detection or error logging.
セキュリティ上の理由から、ホストがREMOVE_ADDRオプションを受け取った場合、影響を受けるパスがクロージャを開始する前に使用されていないことを確認する必要があります。 REMOVE_ADDRの受信は、最初にパス上のTCPキープアライブ[RFC1122]の送信をトリガーする必要があります（SHOULD）。応答が受信された場合、パスは削除されるべきではありません（SHOULD NOT）。パスがまだ生きていることが判明した場合、受信ホストは今後の接続に指定されたアドレスを使用する必要はありませんが、サブフローをシャットダウンするのはREMOVE_ADDRを送信したホストの責任です。アドレスが削除される前に、要求側のホストはMP_PRIO（セクション3.3.8）を使用して、パスが使用されないことを要求することもできます（MAY）。サブフローの一般的なTCP有効性テスト（たとえば、シーケンスとACK番号が正しいことを確認する）も実施する必要があります。実装では、侵入検知またはエラーログの一部として、これらのテストの失敗の兆候を使用できます。
The sending and receipt (if no keepalive response was received) of this message SHOULD trigger the sending of RSTs by both hosts on the affected subflow(s) (if possible), as a courtesy, to allow the cleanup of middlebox state before cleaning up any local state.
このメッセージの送受信（キープアライブ応答が受信されなかった場合）は、礼儀として、影響を受けるサブフロー（可能であれば）の両方のホストによるRSTの送信をトリガーして、クリーンアップ前にミドルボックス状態をクリーンアップできるようにする必要があります（SHOULD）。あらゆる地方の州。
Address removal is undertaken according to the Address ID, so as to permit the use of NATs and other middleboxes that rewrite source addresses. If an Address ID is not known, the receiver will silently ignore the request.
アドレスの削除は、送信元アドレスを書き換えるNATおよびその他のミドルボックスの使用を許可するために、アドレスIDに従って行われます。アドレスIDが不明の場合、受信者は要求を黙って無視します。
A subflow that is still functioning MUST be closed with a FIN exchange as in regular TCP, rather than using this option. For more information, see Section 3.3.3.
まだ機能しているサブフローは、このオプションを使用するのではなく、通常のTCPのようにFIN交換で閉じる必要があります。詳細は、3.3.3項を参照してください。
Regular TCP has the means of sending a RST signal to abruptly close a connection. With MPTCP, a regular RST only has the scope of the subflow; it will only close the applicable subflow and will not affect the remaining subflows. MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection; this is done via the MP_FASTCLOSE option.
通常のTCPには、RST信号を送信して接続を突然閉じる手段があります。 MPTCPでは、通常のRSTにはサブフローのスコープしかありません。該当するサブフローを閉じるだけで、残りのサブフローには影響しません。 MPTCPの接続は、サブフロー間のブレークビフォアメイクハンドオーバーを可能にするために、データレベルで存続します。したがって、MPTCP接続全体の突然のクローズを可能にするために、MPTCPレベルの「リセット」を提供する必要があります。これは、MP_FASTCLOSEオプションを介して行われます。
MP_FASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MP_FASTCLOSE are implementation specific. Regular TCP does not allow the sending of a RST while the connection is in a synchronized state [RFC0793]. Nevertheless, implementations allow the sending of a RST in this state if, for example, the operating system is running out of resources. In these cases, MPTCP should send the MP_FASTCLOSE. This option is illustrated in Figure 14.
MP_FASTCLOSEは、接続が突然閉じられ、データが受け入れられなくなることをピアに示すために使用されます。 MP_FASTCLOSEをトリガーする理由は実装固有です。通常のTCPでは、接続が同期状態にある間はRSTを送信できません[RFC0793]。それにもかかわらず、たとえばオペレーティングシステムのリソースが不足している場合、実装はこの状態でRSTの送信を許可します。これらの場合、MPTCPはMP_FASTCLOSEを送信する必要があります。このオプションを図14に示します。
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
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| (reserved) |
+---------------+---------------+-------+-----------------------+
| Option Receiver's Key |
| (64 bits) |
| |
+---------------------------------------------------------------+
Figure 14: Fast Close (MP_FASTCLOSE) Option
図14：高速クローズ（MP_FASTCLOSE）オプション
If Host A wants to force the closure of an MPTCP connection, it can do so via two options:
ホストAがMPTCP接続を強制的に閉じたい場合は、次の2つのオプションを使用できます。
* Option A (ACK): Host A sends an ACK containing the MP_FASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake. On all the other subflows, Host A sends a regular TCP RST to close these subflows and tears them down. Host A now enters FASTCLOSE_WAIT state.
* オプションA（ACK）：ホストAは、最初の接続ハンドシェイクで宣言されたホストBのキーを含む、1つのサブフローでMP_FASTCLOSEオプションを含むACKを送信します。他のすべてのサブフローでは、ホストAは通常のTCP RSTを送信してこれらのサブフローを閉じ、それらを破棄します。これで、ホストAはFASTCLOSE_WAIT状態になります。
* Option R (RST): Host A sends a RST containing the MP_FASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake. Host A can tear down the subflows and the connection immediately.
* オプションR（RST）：ホストAは、すべてのサブフローでMP_FASTCLOSEオプションを含むRSTを送信し、初期接続ハンドシェイクで宣言されたホストBのキーを含みます。ホストAは、サブフローと接続をすぐに切断できます。
If Host A decides to force the closure by using Option A and sending an ACK with the MP_FASTCLOSE option, the connection shall proceed as follows:
ホストAがオプションAを使用して強制的に閉じることを決定し、MP_FASTCLOSEオプションを使用してACKを送信する場合、接続は次のように進行します。
* Upon receipt of an ACK with MP_FASTCLOSE by Host B, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows also through sending TCP RST signals. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state).
* 有効なキーを含むホストBによるMP_FASTCLOSEを含むACKを受信すると、ホストBはTCP RSTを使用して同じサブフローで応答し、TCP RST信号の送信を通じてすべてのサブフローを破棄します。これで、ホストBはMPTCP接続全体を閉じることができます（直接CLOSED状態に移行します）。
* As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSE_WAIT state to CLOSED state). If Host A receives an MP_FASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection.
* ホストAが残りのサブフローでTCP RSTを受信するとすぐに、このサブフローを閉じて接続全体を切断できます（FASTCLOSE_WAIT状態からCLOSED状態への遷移）。ホストAがTCP RSTではなくMP_FASTCLOSEを受信した場合、両方のホストが同時に高速クローズを試みました。ホストAはTCP RSTで応答し、接続を切断する必要があります。
* If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow where the MP_FASTCLOSE has been sent), it SHOULD retransmit the MP_FASTCLOSE. To keep this connection from being retained for a long time, the number of retransmissions SHOULD be limited; this limit is implementation specific. A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP RST with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes.
* ホストAが1回の再送信タイムアウト（RTO）（MP_FASTCLOSEが送信されたサブフローのRTO）の後でMP_FASTCLOSEに応答してTCP RSTを受信しない場合、MP_FASTCLOSEを再送信する必要があります（SHOULD）。この接続が長期間保持されないようにするには、再送信の数を制限する必要があります。この制限は実装固有です。推奨番号は3です。TCPRSTが応答で受信されない場合、ホストAは、ミドルボックスの残りの状態をクリアするために、状態を解放するときにMP_FASTCLOSEオプション自体を使用してTCP RSTを送信する必要があります（SHOULD）。
If, however, Host A decides to force the closure by using Option R and sending a RST with the MP_FASTCLOSE option, Host B will act as follows: upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows by sending a TCP RST. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state).
ただし、ホストAがオプションRを使用してMP_FASTCLOSEオプションでRSTを送信することにより強制的に閉じることを決定した場合、ホストBは次のように動作します。有効なキーを含むMP_FASTCLOSEでRSTを受信すると、ホストBはすべてのサブフローを破棄します。 TCP RSTを送信する。これで、ホストBはMPTCP接続全体を閉じることができます（直接CLOSED状態に移行します）。
An implementation of MPTCP may also need to send a regular TCP RST to force the closure of a subflow. A host sends a TCP RST in order to close a subflow or reject an attempt to open a subflow (MP_JOIN). In order to let the receiving host know why a subflow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRST option (Figure 15). The host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never.
MPTCPの実装では、サブフローを強制的に閉じるために、通常のTCP RSTを送信する必要がある場合もあります。ホストは、サブフローを閉じるか、サブフローを開く試みを拒否するためにTCP RSTを送信します（MP_JOIN）。サブフローがクローズまたは拒否されている理由を受信ホストに知らせるために、TCP RSTパケットにはMP_TCPRSTオプションが含まれている場合があります（図15）。ホストはこの情報を使用して、たとえば、サブフローをすぐに再確立しようとするか、後で再確立しようとするか、まったくしないかを決定できます。
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
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype|U|V|W|T| Reason |
+---------------+---------------+-------+-----------------------+
Figure 15: TCP RST Reason (MP_TCPRST) Option
図15：TCP RST理由（MP_TCPRST）オプション
The MP_TCPRST option contains a reason code that allows the sender of the option to provide more information about the reason for the termination of the subflow. Using 12 bits of option space, the first 4 bits are reserved for flags (only one of which is currently defined), and the remaining octet is used to express a reason code for this subflow termination, from which a receiver MAY infer information about the usability of this path.
MP_TCPRSTオプションには、オプションの送信者がサブフローの終了の理由に関する詳細情報を提供できるようにする理由コードが含まれています。 12ビットのオプションスペースを使用して、最初の4ビットはフラグ用に予約されており（そのうちの1つのみが現在定義されています）、残りのオクテットはこのサブフロー終了の理由コードを表すために使用されます。このパスのユーザビリティ。
The "T" flag is used by the sender to indicate whether the error condition that is reported is Transient ("T" bit set to 1) or Permanent ("T" bit set to 0). If the error condition is considered to be Transient by the sender of the RST segment, the recipient of this segment MAY try to re-establish a subflow for this connection over the failed path. The time at which a receiver may try to re-establish this subflow is implementation specific but SHOULD take into account the properties of the failure as defined by the provided reason code. If the error condition is considered to be Permanent, the receiver of the RST segment SHOULD NOT try to re-establish a subflow for this connection over this path. The "U", "V", and "W" flags are not defined by this specification and are reserved for future use. An implementation of this specification MUST set these flags to 0, and a receiver MUST ignore them.
「T」フラグは、報告されたエラー状態が一時的（「T」ビットが1に設定されている）か、永続的（「T」ビットが0に設定されている）かを示すために送信側によって使用されます。エラー状態がRSTセグメントの送信者によって一時的であると見なされる場合、このセグメントの受信者は、失敗したパスを介してこの接続のサブフローを再確立しようとする場合があります。受信者がこのサブフローを再確立しようとする可能性のある時間は実装固有ですが、提供された理由コードで定義されている障害のプロパティを考慮する必要があります（SHOULD）。エラー状態が永続的であると見なされる場合、RSTセグメントの受信側は、このパスを介したこの接続のサブフローの再確立を試みるべきではありません（SHOULD NOT）。 「U」、「V」、および「W」フラグはこの仕様では定義されておらず、将来の使用のために予約されています。この仕様の実装はこれらのフラグを0に設定しなければならず（MUST）、受信者はそれらを無視しなければなりません（MUST）。
"Reason" is an 8-bit field that indicates the reason code for the termination of the subflow. The following codes are defined in this document:
「理由」は、サブフローの終了の理由コードを示す8ビットのフィールドです。このドキュメントでは、次のコードが定義されています。
* Unspecified error (code 0x00). This is the default error; it implies that the subflow is no longer available. The presence of this option shows that the RST was generated by an MPTCP-aware device.
* 不明なエラー（コード0x00）。これはデフォルトのエラーです。これは、サブフローが使用できなくなったことを意味します。このオプションの存在は、RSTがMPTCP対応デバイスによって生成されたことを示しています。
* MPTCP-specific error (code 0x01). An error has been detected in the processing of MPTCP options. This is the usual reason code to return in the cases where a RST is being sent to close a subflow because of an invalid response.
* MPTCP固有のエラー（コード0x01）。 MPTCPオプションの処理中にエラーが検出されました。これは、無効な応答のためにRSTが送信されてサブフローを閉じる場合に返される通常の理由コードです。
* Lack of resources (code 0x02). This code indicates that the sending host does not have enough resources to support the terminated subflow.
* リソースの不足（コード0x02）。このコードは、終了したサブフローをサポートするのに十分なリソースが送信側ホストにないことを示しています。
* Administratively prohibited (code 0x03). This code indicates that the requested subflow is prohibited by the policies of the sending host.
* 管理上禁止されています（コード0x03）。このコードは、要求されたサブフローが送信元ホストのポリシーによって禁止されていることを示しています。
* Too much outstanding data (code 0x04). This code indicates that there is an excessive amount of data that needs to be transmitted over the terminated subflow while having already been acknowledged over one or more other subflows. This may occur if a path has been unavailable for a short period and it is more efficient to reset and start again than it is to retransmit the queued data.
* 未処理のデータが多すぎます（コード0x04）。このコードは、1つ以上の他のサブフローですでに確認されているにもかかわらず、終了したサブフローで送信する必要があるデータの量が多すぎることを示しています。これは、パスが短期間使用できず、キューに入れられたデータを再送信するよりもリセットして再開する方が効率的である場合に発生することがあります。
* Unacceptable performance (code 0x05). This code indicates that the performance of this subflow was too low compared to the other subflows of this Multipath TCP connection.
* 許容できないパフォーマンス（コード0x05）。このコードは、このサブフローのパフォーマンスが、このマルチパスTCP接続の他のサブフローと比較して低すぎることを示しています。
* Middlebox interference (code 0x06). Middlebox interference has been detected over this subflow, making MPTCP signaling invalid. For example, this may be sent if the checksum does not validate.
* ミドルボックス干渉（コード0x06）。このサブフローでミドルボックス干渉が検出されたため、MPTCPシグナリングが無効になっています。たとえば、チェックサムが検証されない場合に送信されます。
Sometimes, middleboxes will exist on a path that could prevent the operation of MPTCP. MPTCP has been designed to cope with many middlebox modifications (see Section 6), but there are still some cases where a subflow could fail to operate within the MPTCP requirements. Notably, these cases are the following: the loss of MPTCP options on a path and the modification of payload data. If such an event occurs, it is necessary to "fall back" to the previous, safe operation. This may be either falling back to regular TCP or removing a problematic subflow.
MPTCPの動作を妨げる可能性のあるパス上にミドルボックスが存在する場合があります。 MPTCPは、ミドルボックスの多くの変更（セクション6を参照）に対応するように設計されていますが、サブフローがMPTCP要件内で動作しない可能性がある場合もあります。特に、これらのケースは次のとおりです。パスでのMPTCPオプションの損失とペイロードデータの変更。そのようなイベントが発生した場合、以前の安全な操作に「フォールバック」する必要があります。これは、通常のTCPにフォールバックするか、問題のあるサブフローを削除するかのいずれかです。
At the start of an MPTCP connection (i.e., the first subflow), it is important to ensure that the path is fully MPTCP capable and the necessary MPTCP options can reach each host. The handshake as described in Section 3.1 SHOULD fall back to regular TCP if either of the SYN messages does not have the MPTCP options: this is the same, and desired, behavior in the case where a host is not MPTCP capable or the path does not support the MPTCP options. When attempting to join an existing MPTCP connection (Section 3.2), if a path is not MPTCP capable and the MPTCP options do not get through on the SYNs, the subflow will be closed according to the MP_JOIN logic.
MPTCP接続の開始時（つまり、最初のサブフロー）では、パスが完全にMPTCP対応であり、必要なMPTCPオプションが各ホストに到達できることを確認することが重要です。セクション3.1で説明されているハンドシェイクは、SYNメッセージのいずれかにMPTCPオプションがない場合、通常のTCPにフォールバックする必要があります。これは、ホストがMPTCPに対応していない場合やパスにパスがない場合と同じ、望ましい動作です。 MPTCPオプションをサポートします。既存のMPTCP接続（セクション3.2）に参加しようとしたときに、パスがMPTCPに対応しておらず、MPTCPオプションがSYNを通過しない場合、サブフローはMP_JOINロジックに従って閉じられます。
There is, however, another corner case that should be addressed: the case where MPTCP options get through on the SYN but not on regular packets. If the subflow is the first subflow and thus all data in flight is contiguous, this situation can be resolved by using the following rules:
ただし、対処する必要がある別のコーナーケースがあります。MPTCPオプションがSYNで通過するが、通常のパケットでは通過しない場合です。サブフローが最初のサブフローであり、したがって進行中のすべてのデータが連続している場合、この状況は次のルールを使用して解決できます。
* A sender MUST include a DSS option with Data Sequence Mapping in every segment until one of the sent segments has been acknowledged with a DSS option containing a Data ACK. Upon reception of the acknowledgment, the sender has the confirmation that the DSS option passes in both directions and may choose to send fewer DSS options than once per segment.
* 送信者は、送信されたセグメントの1つがデータACKを含むDSSオプションで確認されるまで、すべてのセグメントにデータシーケンスマッピングのDSSオプションを含める必要があります。確認応答を受信すると、送信者はDSSオプションが両方向に渡されることを確認し、セグメントごとに1回よりも少ないDSSオプションを送信することを選択できます。
* If, however, an ACK is received for data (not just for the SYN) without a DSS option containing a Data ACK, the sender determines that the path is not MPTCP capable. In the case of this occurring on an additional subflow (i.e., one started with MP_JOIN), the host MUST close the subflow with a RST, which SHOULD contain an MP_TCPRST option (Section 3.6) with a "Middlebox interference" reason code.
* ただし、データACKを含むDSSオプションなしでデータ（SYNだけでなく）に対してACKが受信された場合、送信者はパスがMPTCPに対応していないと判断します。これが追加のサブフロー（MP_JOINで開始されたサブフロー）で発生した場合、ホストはRSTでサブフローを閉じる必要があります。RSTには、「ミドルボックス干渉」理由コードを含むMP_TCPRSTオプション（セクション3.6）が含まれている必要があります（SHOULD）。
* In the case of such an ACK being received on the first subflow (i.e., that started with MP_CAPABLE), before any additional subflows are added, the implementation MUST drop out of MPTCP mode and fall back to regular TCP. The sender will send one final Data Sequence Mapping, with the Data-Level Length value of 0 indicating an infinite mapping (to inform the other end in case the path drops options in one direction only), and then revert to sending data on the single subflow without any MPTCP options.
* そのようなACKが最初のサブフロー（つまり、MP_CAPABLEで開始された）で受信される場合、追加のサブフローが追加される前に、実装はMPTCPモードを終了し、通常のTCPにフォールバックする必要があります。送信側は、1つの最終的なデータシーケンスマッピングを送信し、データレベルの長さの値0は無限のマッピングを示し（パスが一方向にのみオプションをドロップした場合にもう一方の端に通知するため）、単一のデータの送信に戻ります。 MPTCPオプションのないサブフロー。
* If a subflow breaks during operation, e.g., if it is rerouted and MPTCP options are no longer permitted, then once this is detected (by the subflow-level receive buffer filling up, since there is no mapping available in order to DATA_ACK this data), the subflow SHOULD be treated as broken and closed with a RST, since no data can be delivered to the application layer and no fallback signal can be reliably sent. This RST SHOULD include the MP_TCPRST option (Section 3.6) with a "Middlebox interference" reason code.
* 操作中にサブフローが壊れた場合、たとえば、再ルーティングされてMPTCPオプションが許可されなくなった場合、これが検出されると（サブフローレベルの受信バッファーがいっぱいになると、このデータをDATA_ACKするために使用できるマッピングがないため） 、データがアプリケーション層に配信されず、フォールバック信号を確実に送信できないため、サブフローは壊れたものとして扱われ、RSTで閉じられる必要があります。このRST SHOULDには、「ミドルボックス干渉」理由コードとともにMP_TCPRSTオプション（セクション3.6）を含める必要があります。
These rules should cover all cases where such a failure could happen -- whether it's on the forward or reverse path and whether the server or the client first sends data.
これらのルールは、そのような障害が発生する可能性のあるすべてのケースをカバーする必要があります。それが順方向パスであるか逆方向パスであるか、サーバーまたはクライアントが最初にデータを送信するかどうかです。
So far, this section has discussed the loss of MPTCP options, either initially or during the course of the connection. As described in Section 3.3, each portion of data for which there is a mapping is protected by a checksum, if checksums have been negotiated. This mechanism is used to detect if middleboxes have made any adjustments to the payload (added, removed, or changed data). A checksum will fail if the data has been changed in any way. The use of a checksum will also detect whether the length of data on the subflow is increased or decreased, and this means the Data Sequence Mapping is no longer valid. The sender no longer knows what subflow-level sequence number the receiver is genuinely operating at (the middlebox will be faking ACKs in return), and it cannot signal any further mappings. Furthermore, in addition to the possibility of payload modifications that are valid at the application layer, it is possible that such modifications could be triggered across MPTCP segment boundaries, corrupting the data. Therefore, all data from the start of the segment that failed the checksum onward is not trustworthy.
これまでのところ、このセクションでは、最初または接続中にMPTCPオプションが失われることについて説明しました。セクション3.3で説明したように、マッピングがあるデータの各部分は、チェックサムがネゴシエートされている場合、チェックサムによって保護されます。このメカニズムは、ミドルボックスがペイロードに調整（データの追加、削除、または変更）を行ったかどうかを検出するために使用されます。データが何らかの方法で変更されている場合、チェックサムは失敗します。チェックサムを使用すると、サブフローのデータの長さが増減したかどうかも検出されます。これは、データシーケンスマッピングが無効になったことを意味します。送信側は、受信側が実際に動作しているサブフローレベルのシーケンス番号を認識できなくなり（ミドルボックスは代わりにACKを偽装します）、それ以上のマッピングを通知できません。さらに、アプリケーション層で有効なペイロード変更の可能性に加えて、そのような変更がMPTCPセグメントの境界を越えてトリガーされ、データが破損する可能性があります。したがって、チェックサムに失敗したセグメントの開始以降のすべてのデータは信頼できません。
Note that if checksum usage has not been negotiated, this fallback mechanism cannot be used unless there is some higher-layer or lower-layer signal to inform the MPTCP implementation that the payload has been tampered with.
チェックサムの使用がネゴシエートされていない場合、ペイロードが改ざんされたことをMPTCP実装に通知する上位層または下位層の信号がない限り、このフォールバックメカニズムは使用できません。
When multiple subflows are in use, the data in flight on a subflow will likely involve data that is not contiguously part of the connection-level stream, since segments will be spread across the multiple subflows. Due to the problems identified above, it is not possible to determine what adjustments have been done to the data (notably, any changes to the subflow sequence numbering). Therefore, it is not possible to recover the subflow, and the affected subflow must be immediately closed with a RST that includes an MP_FAIL option (Figure 16), which defines the data sequence number at the start of the segment (defined by the Data Sequence Mapping) that had the checksum failure. Note that the MP_FAIL option requires the use of the full 64-bit sequence number, even if 32-bit sequence numbers are normally in use in the DSS signals on the path.
複数のサブフローが使用されている場合、セグメントは複数のサブフローに分散されるため、サブフローで処理中のデータには、接続レベルのストリームの連続部分ではないデータが含まれる可能性があります。上記の問題により、データに対して行われた調整（特に、サブフローのシーケンス番号の変更）を特定することはできません。したがって、サブフローを回復することは不可能であり、影響を受けるサブフローは、MP_FAILオプション（図16）を含むRSTですぐに閉じる必要があります。マッピング）チェックサムエラーが発生しました。パスのDSS信号で32ビットのシーケンス番号が通常使用されている場合でも、MP_FAILオプションでは完全な64ビットのシーケンス番号を使用する必要があることに注意してください。
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
+---------------+---------------+-------+----------------------+
| Kind | Length=12 |Subtype| (reserved) |
+---------------+---------------+-------+----------------------+
| |
| Data Sequence Number (8 octets) |
| |
+--------------------------------------------------------------+
Figure 16: Fallback (MP_FAIL) Option
図16：フォールバック（MP_FAIL）オプション
The receiver of this option MUST discard all data following the data sequence number specified. Failed data MUST NOT be DATA_ACKed and so will be retransmitted on other subflows (Section 3.3.6).
このオプションの受信者は、指定されたデータシーケンス番号に続くすべてのデータを破棄する必要があります。失敗したデータはDATA_ACKされてはならず（MUST NOT）、他のサブフローで再送信されます（セクション3.3.6）。
A special case is when there is a single subflow and it fails with a checksum error. If it is known that all unacknowledged data in flight is contiguous (which will usually be the case with a single subflow), an infinite mapping can be applied to the subflow without the need to close it first, essentially turning off all further MPTCP signaling. In this case, if a receiver identifies a checksum failure when there is only one path, it will send back an MP_FAIL option on the subflow-level ACK, referring to the data-level sequence number of the start of the segment on which the checksum error was detected. The sender will receive this information and, if all unacknowledged data in flight is contiguous, will signal an infinite mapping. This infinite mapping will be a DSS option (Section 3.3) on the first new packet, containing a Data Sequence Mapping that acts retroactively, referring to the start of the subflow sequence number of the most recent segment that was known to be delivered intact (i.e., was successfully DATA_ACKed). From that point onward, data can be altered by a middlebox without affecting MPTCP, as the data stream is equivalent to a regular, legacy TCP session. While in theory paths may only be damaged in one direction -- and the MP_FAIL signal affects only one direction of traffic -- for simplicity of implementation, the receiver of an MP_FAIL MUST also respond with an MP_FAIL in the reverse direction and entirely revert to a regular TCP session.
特殊なケースは、単一のサブフローがあり、チェックサムエラーで失敗する場合です。進行中のすべての未確認のデータが連続していることがわかっている場合（通常、単一のサブフローの場合が該当します）、最初にサブフローを閉じなくても、無限のマッピングをサブフローに適用できます。これにより、以降のすべてのMPTCPシグナリングが実質的にオフになります。この場合、レシーバーは、パスが1つしかないときにチェックサム障害を識別した場合、チェックサムが適用されているセグメントの開始のデータレベルのシーケンス番号を参照して、サブフローレベルのACKにMP_FAILオプションを返します。エラーが検出されました。送信者はこの情報を受信し、進行中のすべての未確認データが連続している場合は、無限マッピングを通知します。この無限マッピングは、最初の新しいパケットのDSSオプション（3.3節）であり、無傷で配信されることがわかっている最新のセグメントのサブフローシーケンス番号の開始を参照する（つまり、遡及的に機能するデータシーケンスマッピングを含む）（つまり、 、正常にDATA_ACKされました）。それ以降は、データストリームは通常のレガシーTCPセッションと同等であるため、MPTCPに影響を与えることなく、ミドルボックスによってデータを変更できます。理論的にはパスは一方向にのみ損傷する可能性があります-MP_FAIL信号はトラフィックの一方向にのみ影響します-実装を簡単にするために、MP_FAILのレシーバーは逆方向にMP_FAILで応答し、完全に通常のTCPセッション。
In the rare case that the data is not contiguous (which could happen when there is only one subflow but it is retransmitting data from a subflow that has recently been uncleanly closed), the receiver MUST close the subflow with a RST with MP_FAIL. The receiver MUST discard all data that follows the data sequence number specified. The sender MAY attempt to create a new subflow belonging to the same connection and, if it chooses to do so, SHOULD immediately place the single subflow in single-path mode by setting an infinite Data Sequence Mapping. This mapping will begin from the data-level sequence number that was declared in the MP_FAIL.
データが連続していないというまれなケース（サブフローが1つしかないが、最近完全にクローズされていないサブフローからデータを再送信している場合に発生する可能性があります）では、レシーバーはMP_FAILを使用してRSTでサブフローをクローズする必要があります。受信者は、指定されたデータシーケンス番号に続くすべてのデータを破棄する必要があります。送信者は、同じ接続に属する新しいサブフローを作成しようとする場合があり、そうすることを選択した場合は、無限のデータシーケンスマッピングを設定することにより、単一のサブフローをただちにシングルパスモードにする必要があります。このマッピングは、MP_FAILで宣言されたデータレベルのシーケンス番号から始まります。
After a sender signals an infinite mapping, it MUST only use subflow ACKs to clear its send buffer. This is because Data ACKs may become misaligned with the subflow ACKs when middleboxes insert or delete data. The receiver SHOULD stop generating Data ACKs after it receives an infinite mapping.
送信者が無限マッピングを通知した後、送信バッファをクリアするためにサブフローACKのみを使用する必要があります。これは、ミドルボックスがデータを挿入または削除すると、データACKがサブフローACKとずれてしまう可能性があるためです。受信者は、無限のマッピングを受信した後、データACKの生成を停止する必要があります（SHOULD）。
When a connection has fallen back with an infinite mapping, only one subflow can send data; otherwise, the receiver would not know how to reorder the data. In practice, this means that all MPTCP subflows will have to be terminated except one. Once MPTCP falls back to regular TCP, it MUST NOT revert to MPTCP later in the connection.
接続が無限マッピングでフォールバックした場合、データを送信できるのは1つのサブフローのみです。そうしないと、受信者はデータを並べ替える方法がわかりません。実際には、これは、1つを除いてすべてのMPTCPサブフローを終了する必要があることを意味します。 MPTCPが通常のTCPにフォールバックした後は、接続の後半でMPTCPに戻してはなりません。
It should be emphasized that MPTCP is not attempting to prevent the use of middleboxes that want to adjust the payload. An MPTCP-aware middlebox could provide such functionality by also rewriting checksums.
MPTCPは、ペイロードを調整するミドルボックスの使用を妨げようとしているわけではないことを強調しておく必要があります。 MPTCP対応のミドルボックスは、チェックサムも書き換えることにより、このような機能を提供できます。
In addition to the fallback mechanism described above, the standard classes of TCP errors may need to be handled in an MPTCP-specific way. Note that changing semantics -- such as the relevance of a RST -- are covered in Section 4. Where possible, we do not want to deviate from regular TCP behavior.
上記のフォールバックメカニズムに加えて、TCPエラーの標準クラスは、MPTCP固有の方法で処理する必要がある場合があります。 RSTの関連性などのセマンティクスの変更については、セクション4で説明しています。可能な場合は、通常のTCPの動作から逸脱しないようにします。
The following list covers possible errors and the appropriate MPTCP behavior:
次のリストは、考えられるエラーと適切なMPTCPの動作を示しています。
* Unknown token in MP_JOIN (or HMAC failure in MP_JOIN ACK, or missing MP_JOIN in SYN/ACK response): send RST (analogous to TCP's behavior on an unknown port)
* MP_JOIN内の不明なトークン（またはMP_JOIN ACK内のHMAC障害、またはSYN / ACK応答内のMP_JOINがない）：RSTを送信（不明なポートでのTCPの動作に類似）
* DSN out of window (during normal operation): drop the data; do not send Data ACKs
* ウィンドウ外のDSN（通常の操作中）：データをドロップします。データACKを送信しない
* Remove request for unknown Address ID: silently ignore
* 不明なアドレスIDの要求を削除します：黙って無視します
There are a number of heuristics that are needed for performance or deployment but that are not required for protocol correctness. In this section, we detail such heuristics. Note that discussions of buffering and certain sender and receiver window behaviors are presented in Sections 3.3.4 and 3.3.5, and retransmission is discussed in Section 3.3.6.
パフォーマンスまたはデプロイメントに必要なヒューリスティックがいくつかありますが、プロトコルの正確性には必要ありません。このセクションでは、そのようなヒューリスティックについて詳しく説明します。バッファリングと特定の送信側ウィンドウと受信側ウィンドウの動作については、セクション3.3.4と3.3.5で説明し、再送信についてはセクション3.3.6で説明します。
Under typical operation, an MPTCP implementation SHOULD use the same ports as the ports that are already in use. In other words, the destination port of a SYN containing an MP_JOIN option SHOULD be the same as the remote port of the first subflow in the connection. The local port for such SYNs SHOULD also be the same as the port for the first subflow (and as such, an implementation SHOULD reserve ephemeral ports across all local IP addresses), although there may be cases where this is infeasible. This strategy is intended to maximize the probability of the SYN being permitted by a firewall or NAT at the recipient and to avoid confusing any network-monitoring software.
通常の操作では、MPTCP実装は、すでに使用されているポートと同じポートを使用する必要があります（SHOULD）。つまり、MP_JOINオプションを含むSYNの宛先ポートは、接続の最初のサブフローのリモートポートと同じである必要があります（SHOULD）。このようなSYNのローカルポートは、最初のサブフローのポートと同じである必要があります（したがって、実装では、すべてのローカルIPアドレスにまたがる一時的なポートを予約する必要があります）。ただし、これが実行できない場合もあります。この戦略は、SYNが受信側でファイアウォールまたはNATによって許可される確率を最大化し、ネットワーク監視ソフトウェアの混乱を避けることを目的としています。
There may also be cases, however, where a host wishes to signal that a specific port should be used; this facility is provided in the ADD_ADDR option as documented in Section 3.4.1. It is therefore feasible to allow multiple subflows between the same two addresses but using different port pairs, and such a facility could be used to allow load balancing within the network based on 5-tuples (e.g., some ECMP implementations [RFC2992]).
ただし、ホストが特定のポートを使用する必要があることを通知したい場合もあります。この機能は、セクション3.4.1で説明されているように、ADD_ADDRオプションで提供されます。したがって、同じ2つのアドレス間で異なるポートペアを使用して複数のサブフローを許可することは可能であり、そのような機能を使用して、5タプルに基づいてネットワーク内のロードバランシングを許可できます（たとえば、一部のECMP実装[RFC2992]）。
Many TCP connections are short-lived and consist only of a few segments, and so the overhead of using MPTCP outweighs any benefits. A heuristic is required, therefore, to decide when to start using additional subflows in an MPTCP connection. Experimental deployments have shown that MPTCP can be applied in a range of scenarios, so an implementation will likely need to take into account such factors as the type of traffic being sent and the duration of the session; this information MAY be signaled by the application layer.
多くのTCP接続は存続期間が短く、数個のセグメントのみで構成されているため、MPTCPを使用することによるオーバーヘッドはすべての利点を上回ります。したがって、MPTCP接続で追加のサブフローの使用をいつ開始するかを決定するには、ヒューリスティックが必要です。実験的な導入により、MPTCPはさまざまなシナリオに適用できることが示されているため、実装では、送信されるトラフィックのタイプやセッションの継続時間などの要素を考慮する必要があります。この情報は、アプリケーション層によって通知される場合があります。
However, for standard TCP traffic, a suggested general-purpose heuristic that an implementation MAY choose to employ is as follows.
ただし、標準TCPトラフィックの場合、実装が採用することを選択できる推奨される汎用ヒューリスティックは次のとおりです。
If a host has data buffered for its peer (which implies that the application has received a request for data), the host opens one subflow for each initial window's worth of data that is buffered.
ホストがピア用にバッファリングされたデータを持っている場合（アプリケーションがデータの要求を受け取ったことを意味します）、ホストは、バッファリングされた各初期ウィンドウに相当するデータごとに1つのサブフローを開きます。
Consideration should also be given to limiting the rate of adding new subflows, as well as limiting the total number of subflows open for a particular connection. A host may choose to vary these values based on its load or knowledge of traffic and path characteristics.
また、新しいサブフローを追加する速度を制限すること、および特定の接続に対して開いているサブフローの総数を制限することも考慮する必要があります。ホストは、負荷またはトラフィックとパスの特性に関する知識に基づいて、これらの値を変更することを選択できます。
Note that this heuristic alone is probably insufficient. Traffic for many common applications, such as downloads, is highly asymmetric, and the host that is multihomed may well be the client that will never fill its buffers and thus never use MPTCP according to this heuristic. Advanced APIs that allow an application to signal its traffic requirements would aid in these decisions.
このヒューリスティックだけではおそらく不十分であることに注意してください。ダウンロードなどの多くの一般的なアプリケーションのトラフィックは非常に非対称であり、マルチホーム化されたホストは、バッファをいっぱいにしないクライアントである可能性があり、このヒューリスティックによるとMPTCPを使用しません。アプリケーションがトラフィック要件を通知できる高度なAPIは、これらの決定に役立ちます。
An additional time-based heuristic could be applied, opening additional subflows after a given period of time has passed. This would alleviate the above issue and also provide resilience for low-bandwidth but long-lived applications.
追加の時間ベースのヒューリスティックを適用して、一定期間が経過した後に追加のサブフローを開くことができます。これにより、上記の問題が緩和され、低帯域幅で長寿命のアプリケーションに回復力が提供されます。
Another issue is that both communicating hosts may simultaneously try to set up a subflow between the same pair of addresses. This leads to an inefficient use of resources.
別の問題は、通信している両方のホストが同じアドレスのペア間にサブフローを同時にセットアップしようとする可能性があることです。これは、リソースの非効率的な使用につながります。
If the same ports are used on all subflows, as recommended above, then standard TCP simultaneous-open logic should take care of this situation and only one subflow will be established between the address pairs. However, this relies on the same ports being used at both end hosts. If a host does not support TCP simultaneous open, it is RECOMMENDED that some element of randomization be applied to the time to wait before opening new subflows, so that only one subflow is created between a given address pair. If, however, hosts signal additional ports to use (for example, for leveraging ECMP on-path), this heuristic is not appropriate.
上記で推奨されているように、すべてのサブフローで同じポートが使用されている場合、標準のTCP同時オープンロジックがこの状況を処理し、アドレスペア間に1つのサブフローのみが確立されます。ただし、これは両方のエンドホストで使用されている同じポートに依存しています。ホストがTCP同時オープンをサポートしていない場合は、ランダム化の一部の要素を新しいサブフローを開くまでの待機時間に適用して、特定のアドレスペア間に1つのサブフローのみが作成されるようにすることをお勧めします。ただし、ホストが使用する追加のポートに信号を送る場合（たとえば、パス上のECMPを活用するため）、このヒューリスティックは適切ではありません。
This section has shown some of the factors that an implementer should consider when developing MPTCP heuristics, but it is not intended to be prescriptive.
このセクションでは、MPTCPヒューリスティックを開発する際に実装者が考慮すべきいくつかの要素を示しましたが、規範となることを意図したものではありません。
Requirements for MPTCP's handling of unexpected signals are given in Section 3.8. There are other failure cases, however, where hosts can choose appropriate behavior.
MPTCPが予期しないシグナルを処理するための要件は、セクション3.8に記載されています。ただし、ホストが適切な動作を選択できる場合もあります。
For example, Section 3.1 suggests that a host SHOULD fall back to trying regular TCP SYNs after one or more failures of MPTCP SYNs for a connection. A host may keep a system-wide cache of such information, so that it can back off from using MPTCP, firstly for that particular destination host and, eventually, on a whole interface, if MPTCP connections continue to fail. The duration of such a cache would be implementation specific.
たとえば、セクション3.1では、接続のMPTCP SYNで1つ以上の障害が発生した後、ホストは通常のTCP SYNを試すようにフォールバックする必要があることを示唆しています。ホストは、そのような情報のシステム全体のキャッシュを保持できるため、最初にその特定の宛先ホストに対して、最終的にはMPTCP接続が失敗し続ける場合は最終的にインターフェイス全体で、MPTCPの使用をバックオフできます。このようなキャッシュの期間は、実装によって異なります。
Another failure could occur when the MP_JOIN handshake fails. Section 3.8 specifies that an incorrect handshake MUST lead to the subflow being closed with a RST. A host operating an active intrusion-detection system may choose to start blocking MP_JOIN packets from the source host if multiple failed MP_JOIN attempts are seen. From the connection initiator's point of view, if an MP_JOIN fails, it SHOULD NOT attempt to connect to the same IP address and port during the lifetime of the connection, unless the other host refreshes the information with another ADD_ADDR option. Note that the ADD_ADDR option is informational only and does not guarantee that the other host will attempt a connection.
MP_JOINハンドシェイクが失敗すると、別の障害が発生する可能性があります。セクション3.8では、不適切なハンドシェイクによってサブフローがRSTで閉じられる必要があることを明記しています。アクティブな侵入検知システムを操作しているホストは、複数のMP_JOINの試行が失敗した場合に、ソースホストからのMP_JOINパケットのブロックを開始することを選択できます。接続イニシエーターの観点から見ると、MP_JOINが失敗した場合、他のホストが別のADD_ADDRオプションで情報を更新しない限り、接続の存続期間中に同じIPアドレスとポートへの接続を試みるべきではありません（SHOULD NOT）。 ADD_ADDRオプションは情報提供のみを目的としており、他のホストが接続を試行することを保証するものではないことに注意してください。
In addition, an implementation may learn, over a number of connections, that certain interfaces or destination addresses consistently fail and may default to not trying to use MPTCP for such interfaces or addresses. The behavior of subflows that perform particularly badly or subflows that regularly fail during use could also be learned, so that an implementation can temporarily choose not to use these paths.
さらに、実装は、特定のインターフェースまたは宛先アドレスが一貫して失敗し、デフォルトでそのようなインターフェースまたはアドレスにMPTCPを使用しないことを、多くの接続にわたって学習する場合があります。特にパフォーマンスが悪いサブフローや、使用中に定期的に失敗するサブフローの動作も学習できるため、実装はこれらのパスを使用しないように一時的に選択できます。
In order to support multipath operation, the semantics of some TCP components have changed. To help clarify, this section lists these semantic changes as a point of reference.
マルチパス操作をサポートするために、一部のTCPコンポーネントのセマンティクスが変更されました。明確にするために、このセクションでは、これらのセマンティックの変更を参照ポイントとしてリストします。
Sequence number: The (in-header) TCP sequence number is specific to the subflow. To allow the receiver to reorder application data, an additional data-level sequence space is used. In this data-level sequence space, the initial SYN and the final DATA_FIN occupy 1 octet of sequence space. This is done to ensure that these signals are acknowledged at the connection level. There is an explicit mapping of data sequence space to subflow sequence space, which is signaled through TCP options in data packets.
シーケンス番号：（ヘッダー内の）TCPシーケンス番号は、サブフローに固有です。レシーバーがアプリケーションデータを並べ替えられるようにするには、追加のデータレベルのシーケンススペースが使用されます。このデータレベルのシーケンススペースでは、最初のSYNと最後のDATA_FINが1オクテットのシーケンススペースを占めます。これは、これらの信号が接続レベルで確認されるようにするために行われます。データシーケンススペースからサブフローシーケンススペースへの明示的なマッピングがあり、データパケットのTCPオプションを通じて通知されます。
ACK: The ACK field in the TCP header acknowledges only the subflow sequence number -- not the data-level sequence space. Implementations SHOULD NOT attempt to infer a data-level acknowledgment from the subflow ACKs. This separates subflow-level and connection-level processing at an end host.
ACK：TCPヘッダーのACKフィールドは、サブフローシーケンス番号のみを確認します。データレベルのシーケンススペースは確認しません。実装は、サブフローACKからデータレベルの確認応答を推測しようとしないでください。これにより、エンドホストでサブフローレベルと接続レベルの処理が分離されます。
Duplicate ACK: A duplicate ACK that includes any MPTCP signaling (with the exception of the DSS option) MUST NOT be treated as a signal of congestion. To limit the chances of non-MPTCP-aware entities mistakenly interpreting duplicate ACKs as a signal of congestion, MPTCP SHOULD NOT send more than two duplicate ACKs containing (non-DSS) MPTCP signals in a row.
重複ACK：MPDSシグナリング（DSSオプションを除く）を含む重複ACKは、輻輳の信号として扱われてはなりません。非MPTCP対応エンティティが重複ACKを混雑の信号として誤って解釈する可能性を制限するために、MPTCPは、（非DSS）MPTCP信号を連続して含む2つ以上の重複ACKを送信してはなりません（SHOULD NOT）。
Receive Window: The receive window in the TCP header indicates the amount of free buffer space for the whole data-level connection (as opposed to the amount of space for this subflow) that is available at the receiver. The semantics are the same as for regular TCP, but to maintain these semantics the receive window must be interpreted at the sender as relative to the sequence number given in the DATA_ACK rather than the subflow ACK in the TCP header. In this way, the original role of flow control is preserved. Note that some middleboxes may change the receive window, and so a host SHOULD use the maximum value of those recently seen on the constituent subflows for the connection-level receive window and also needs to maintain a subflow-level window for subflow-level processing.
受信ウィンドウ：TCPヘッダーの受信ウィンドウは、（このサブフローのスペースの量ではなく）データレベルの接続全体の空きバッファースペースの量を示し、受信側で使用できます。セマンティクスは通常のTCPと同じですが、これらのセマンティクスを維持するには、受信ウィンドウをTCPヘッダーのサブフローACKではなく、DATA_ACKで指定されたシーケンス番号と比較して送信側で解釈する必要があります。このようにして、フロー制御の元の役割が維持されます。一部のミドルボックスは受信ウィンドウを変更する可能性があるため、ホストは接続レベルの受信ウィンドウの構成サブフローで最近確認された最大値を使用する必要があり、サブフローレベルの処理のためにサブフローレベルのウィンドウを維持する必要もあります。
FIN: The FIN flag in the TCP header applies only to the subflow it is sent on -- not to the whole connection. For connection-level FIN semantics, the DATA_FIN option is used.
FIN：TCPヘッダーのFINフラグは、それが送信されるサブフローにのみ適用され、接続全体には適用されません。接続レベルのFINセマンティクスの場合、DATA_FINオプションが使用されます。
RST: The RST flag in the TCP header applies only to the subflow it is sent on -- not to the whole connection. The MP_FASTCLOSE option provides the Fast Close functionality of a RST at the MPTCP connection level.
RST：TCPヘッダーのRSTフラグは、送信されたサブフローにのみ適用され、接続全体には適用されません。 MP_FASTCLOSEオプションは、MPTCP接続レベルでのRSTの高速クローズ機能を提供します。
Address List: Address list management (i.e., knowledge of the local and remote hosts' lists of available IP addresses) is handled on a per-connection basis (as opposed to per subflow, per host, or per pair of communicating hosts). This permits the application of per-connection local policy. Adding an address to one connection (either explicitly through an ADD_ADDR message or implicitly through an MP_JOIN) has no implications for other connections between the same pair of hosts.
アドレスリスト：アドレスリスト管理（つまり、ローカルおよびリモートホストの利用可能なIPアドレスのリストに関する知識）は、接続ごとに（サブフローごと、ホストごと、または通信するホストのペアごとではなく）処理されます。これにより、接続ごとのローカルポリシーを適用できます。 1つの接続にアドレスを追加しても（ADD_ADDRメッセージを介して明示的に、またはMP_JOINを介して暗黙的に）、同じホストのペア間の他の接続には影響しません。
5-tuple: The 5-tuple (protocol, local address, local port, remote address, remote port) presented by kernel APIs to the application layer in a non-multipath-aware application is that of the first subflow, even if the subflow has since been closed and removed from the connection. This decision, and other related API issues, are discussed in more detail in [RFC6897].
5タプル：カーネルAPIによって非マルチパス対応アプリケーションのアプリケーションレイヤーに提示される5タプル（プロトコル、ローカルアドレス、ローカルポート、リモートアドレス、リモートポート）は、サブフローであっても、最初のサブフローのものです。その後、閉じられ、接続から削除されました。この決定、およびその他の関連するAPIの問題については、[RFC6897]で詳細に説明されています。
As identified in [RFC6181], the addition of multipath capability to TCP will bring with it a number of new classes of threats. In order to prevent these threats, [RFC6182] presents a set of requirements for a security solution for MPTCP. The fundamental goal is for the security of MPTCP to be "no worse" than regular TCP today. The key security requirements are as follows:
[RFC6181]で確認されているように、TCPにマルチパス機能を追加すると、TCPにいくつかの新しいクラスの脅威がもたらされます。これらの脅威を防ぐために、[RFC6182]はMPTCPのセキュリティソリューションに対する一連の要件を提示しています。基本的な目標は、MPTCPのセキュリティが今日の通常のTCPよりも「悪くない」ことです。主なセキュリティ要件は次のとおりです。
* Provide a mechanism to confirm that the parties in a subflow handshake are the same as the parties in the original connection setup.
* サブフローハンドシェイクの当事者が元の接続設定の当事者と同じであることを確認するメカニズムを提供します。
* Provide verification that the peer can receive traffic at a new address before using it as part of a connection.
* ピアが接続の一部として使用する前に、ピアが新しいアドレスでトラフィックを受信できることを確認します。
* Provide replay protection, i.e., ensure that a request to add/remove a subflow is "fresh".
* 再生保護を提供します。つまり、サブフローを追加/削除するリクエストが「新鮮」であることを確認します。
In order to achieve these goals, MPTCP includes a hash-based handshake algorithm, as documented in Sections 3.1 and 3.2.
これらの目標を達成するために、MPTCPには、セクション3.1および3.2で説明されているように、ハッシュベースのハンドシェイクアルゴリズムが含まれています。
The security of the MPTCP connection hangs on the use of keys that are shared once at the start of the first subflow and are never sent again over the network (unless used in the Fast Close mechanism (Section 3.5)). To ease demultiplexing while not giving away any cryptographic material, future subflows use a truncated cryptographic hash of this key as the connection identification "token". The keys are concatenated and used as keys for creating Hash-based Message Authentication Codes (HMACs) used on subflow setup, in order to verify that the parties in the handshake are the same as the parties in the original connection setup. It 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) at both ends -- 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] and discussed in Section 3.1. The nonces are valid for the lifetime of the TCP connection attempt. HMAC is also used to secure the ADD_ADDR option, due to the threats identified in [RFC7430].
MPTCP接続のセキュリティは、最初のサブフローの開始時に一度共有され、ネットワークを介して再度送信されることのないキーを使用するとハングします（高速クローズメカニズム（セクション3.5）で使用されない限り）。暗号化マテリアルを提供せずに逆多重化を容易にするために、将来のサブフローでは、このキーの切り捨てられた暗号化ハッシュを接続識別「トークン」として使用します。キーは連結され、ハンドシェイクのパーティが元の接続セットアップのパーティと同じであることを確認するために、サブフローセットアップで使用されるハッシュベースのメッセージ認証コード（HMAC）を作成するためのキーとして使用されます。また、ピアがこの新しいアドレスでトラフィックを受信できることを確認します。キーのみを使用した場合でも、リプレイ攻撃は可能です。したがって、ハンドシェイクは両端で使い捨ての乱数（ノンス）を使用します。これにより、HMACが2つのハンドシェイクで同じになることはありません。キーとしての使用に適した乱数の生成に関するガイダンスは、[RFC4086]で提供され、セクション3.1で説明されています。ナンスは、TCP接続試行の存続期間中有効です。 [RFC7430]で特定された脅威により、HMACはADD_ADDRオプションを保護するためにも使用されます。
The use of crypto capability bits in the initial connection handshake to negotiate the use of a particular algorithm allows the deployment of additional crypto mechanisms in the future. This negotiation would nevertheless be susceptible to a bid-down attack by an on-path active attacker who could modify the crypto capability bits in the response from the receiver to use a less secure crypto mechanism. The security mechanism presented in this document should therefore protect against all forms of flooding and hijacking attacks discussed in [RFC6181].
特定のアルゴリズムの使用をネゴシエートするための初期接続ハンドシェイクで暗号機能ビットを使用すると、将来的に追加の暗号メカニズムを導入できます。それでも、このネゴシエーションは、受信者からの応答の暗号機能ビットを変更して安全性の低い暗号化メカニズムを使用する可能性がある、パス上のアクティブな攻撃者による落札攻撃の影響を受けます。したがって、このドキュメントで提示されているセキュリティメカニズムは、[RFC6181]で説明されているあらゆる形式のフラッディングおよびハイジャック攻撃から保護する必要があります。
The version negotiation specified in Section 3.1, if differing MPTCP versions shared a common negotiation format, would allow an on-path attacker to apply a theoretical bid-down attack. Since the v1 and v0 protocols have a different handshake, such an attack would require that the client re-establish the connection using v0 and that the server support v0. Note that an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms. As also noted in Appendix E, this document specifies the removal of the AddrID field [RFC6824] in the MP_PRIO option (Section 3.3.8). This change eliminates the possibility of a theoretical attack where a subflow could be placed in "backup" mode by an attacker.
セクション3.1で指定されたバージョンネゴシエーションは、異なるMPTCPバージョンが共通のネゴシエーションフォーマットを共有している場合、パス上の攻撃者が理論的なビッドダウン攻撃を適用できるようにします。 v1とv0のプロトコルではハンドシェイクが異なるため、このような攻撃では、クライアントがv0を使用して接続を再確立し、サーバーがv0をサポートする必要があります。パス上の攻撃者が生データにアクセスし、他のTCPレベルのセキュリティメカニズムを無効にすることに注意してください。付録Eにも記載されているように、このドキュメントでは、MP_PRIOオプション（セクション3.3.8）でAddrIDフィールド[RFC6824]を削除することを指定しています。この変更により、攻撃者がサブフローを「バックアップ」モードにする可能性がある理論的な攻撃の可能性が排除されます。
During normal operation, regular TCP protection mechanisms (such as ensuring that sequence numbers are in-window) will provide the same level of protection against attacks on individual TCP subflows as the level of protection that exists for regular TCP today. Implementations will introduce additional buffers compared to regular TCP, to reassemble data at the connection level. The application of window sizing will minimize the risk of denial-of-service attacks consuming resources.
通常の操作中、通常のTCP保護メカニズム（シーケンス番号がウィンドウ内にあることの確認など）は、現在の通常のTCPに存在する保護レベルと同じレベルの個々のTCPサブフローに対する攻撃に対する保護を提供します。実装では、接続レベルでデータを再構築するために、通常のTCPと比較して追加のバッファーが導入されます。ウィンドウサイジングを適用すると、リソースを消費するサービス拒否攻撃のリスクを最小限に抑えることができます。
As discussed in Section 3.4.1, 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) will ensure that this does not succeed in setting up a subflow to the incorrect host. However, it could still create unwanted TCP handshake traffic. This feature of MPTCP could be a target for denial-of-service exploits, with malicious participants in MPTCP connections encouraging the recipient to target other hosts in the network. Therefore, implementations should consider heuristics (Section 3.9) at both the sender and receiver to reduce the impact of this.
セクション3.4.1で説明したように、ホストはプライベートアドレスをアドバタイズできますが、これらはレシーバのネットワーク内の異なるホストをポイントしている場合があります。 MP_JOINハンドシェイク（セクション3.2）は、これが正しくないホストへのサブフローの設定に成功しないことを保証します。ただし、それでも不要なTCPハンドシェイクトラフィックが作成される可能性があります。 MPTCPのこの機能は、サービス拒否攻撃の標的になる可能性があり、MPTCP接続の悪意のある参加者は、受信者にネットワーク内の他のホストを標的にするように仕向けます。したがって、実装では、この影響を減らすために、送信側と受信側の両方でヒューリスティック（セクション3.9）を検討する必要があります。
To further protect against malicious ADD_ADDR messages sent by an off-path attacker, the ADD_ADDR includes an HMAC using the keys negotiated during the handshake. This effectively prevents an attacker from diverting an MPTCP connection through an off-path ADD_ADDR injection into the stream.
パス外の攻撃者によって送信された悪意のあるADD_ADDRメッセージからさらに保護するために、ADD_ADDRには、ハンドシェイク中にネゴシエートされたキーを使用するHMACが含まれています。これにより、攻撃者がオフパスADD_ADDRインジェクションを介してストリームにMPTCP接続を迂回するのを効果的に防ぎます。
A small security risk could theoretically exist with key reuse, but in order to accomplish a replay attack, both the sender and receiver keys, and the sender and receiver random numbers, in the MP_JOIN handshake (Section 3.2) would have to match.
理論的にはキーの再利用には小さなセキュリティリスクが存在する可能性がありますが、リプレイアタックを実行するには、MP_JOINハンドシェイク（セクション3.2）で送信者と受信者のキー、および送信者と受信者の乱数の両方が一致する必要があります。
While this specification defines a "medium" security solution, meeting the criteria specified at the start of this section and in the threat analysis document [RFC6181], since attacks only ever get worse, it is likely that a future version of MPTCP would need to be able to support stronger security. There are several ways the security of MPTCP could potentially be improved; some of these would be compatible with MPTCP as defined in this document, while others may not be. For now, the best approach is to gain experience with the current approach, establish what might work, and check that the threat analysis is still accurate.
この仕様は「中」のセキュリティソリューションを定義していますが、このセクションの冒頭と脅威分析ドキュメント[RFC6181]で指定された基準を満たしていますが、攻撃は悪化するだけなので、MPTCPの将来のバージョンでは、より強力なセキュリティをサポートできる。 MPTCPのセキュリティを向上させる方法はいくつかあります。これらの一部は、このドキュメントで定義されているようにMPTCPと互換性がありますが、他の互換性はありません。現在のところ、最善のアプローチは、現在のアプローチの経験を積み、何が機能するかを確認し、脅威分析が依然として正確であることを確認することです。
Possible ways of improving MPTCP security could include:
MPTCPセキュリティを改善するための考えられる方法には、次のものがあります。
* defining a new MPTCP cryptographic algorithm, as negotiated in MP_CAPABLE. If an implementation was being deployed in a controlled environment where additional assumptions could be made, such as the ability for the servers to store state during the TCP handshake, then it may be possible to use a stronger cryptographic algorithm than would otherwise be possible.
* MP_CAPABLEでネゴシエートされた新しいMPTCP暗号化アルゴリズムを定義します。 TCPハンドシェイク中にサーバーが状態を保存する機能など、追加の仮定を行うことができる制御された環境に実装が展開されていた場合、他の方法よりも強力な暗号化アルゴリズムを使用できる可能性があります。
* defining how to secure data transfer with MPTCP, while not changing the signaling part of the protocol.
* プロトコルのシグナリング部分を変更せずに、MPTCPでデータ転送を保護する方法を定義します。
* defining security that requires more option space, perhaps in conjunction with a "long options" proposal for extending the TCP option space (such as those surveyed in [TCPLO]), or perhaps building on the current approach with a second stage of security based on MPTCP options.
* より多くのオプションスペースを必要とするセキュリティを定義し、おそらくTCPオプションスペースを拡張するための「長いオプション」の提案（[TCPLO]で調査されたものなど）と組み合わせて、またはおそらくMPTCPオプション。
* revisiting the working group's decision to exclusively use TCP options for MPTCP signaling and instead looking at the possibility of using TCP payloads as well.
* MPTCPシグナリングにTCPオプションのみを使用するというワーキンググループの決定を再検討し、代わりにTCPペイロードを使用する可能性も検討します。
MPTCP has been designed with several methods available to indicate a new security mechanism, including:
MPTCPは、次のような新しいセキュリティメカニズムを示すために利用できるいくつかの方法で設計されています。
* available flags in MP_CAPABLE (Figure 4).
* MP_CAPABLEの利用可能なフラグ（図4）。
* available subtypes in the MPTCP option (Figure 3).
* MPTCPオプションで使用可能なサブタイプ（図3）。
* the Version field in MP_CAPABLE (Figure 4).
* MP_CAPABLEのVersionフィールド（図4）。
Multipath TCP was designed to be deployable in the present world. Its design takes into account "reasonable" existing middlebox behavior. In this section, we outline a few representative middlebox-related failure scenarios and show how Multipath TCP handles them. Next, we list the design decisions Multipath TCP has made to accommodate the different middleboxes.
マルチパスTCPは、現在の世界で展開できるように設計されています。その設計では、「合理的な」既存のミドルボックスの動作が考慮されています。このセクションでは、いくつかの代表的なミドルボックス関連の障害シナリオを概説し、マルチパスTCPがそれらを処理する方法を示します。次に、さまざまなミドルボックスに対応するためにマルチパスTCPが行った設計上の決定を示します。
A primary concern is our use of a new TCP option. Middleboxes should forward packets with unknown options unchanged, yet there are some that don't. We expect these middleboxes to strip options and pass the data, drop packets with new options, copy the same option into multiple segments (e.g., when doing segmentation), or drop options during segment coalescing.
主な懸念事項は、新しいTCPオプションの使用です。ミドルボックスは、不明なオプションが変更されていないパケットを転送する必要がありますが、そうでないものもあります。これらのミドルボックスは、オプションを取り除いてデータを渡し、新しいオプションでパケットをドロップし、同じオプションを複数のセグメントにコピーして（たとえば、セグメンテーションを行う場合）、またはセグメントの結合中にオプションをドロップします。
MPTCP uses a single new TCP option called "Kind", and all message types are defined by "subtype" values (see Section 7). This should reduce the chances of only some types of MPTCP options being passed; instead, the key differing characteristics are different paths and the presence of the SYN flag.
MPTCPは「種類」と呼ばれる単一の新しいTCPオプションを使用し、すべてのメッセージタイプは「サブタイプ」の値によって定義されます（セクション7を参照）。これにより、一部のタイプのMPTCPオプションのみが渡される可能性が減ります。代わりに、主要な異なる特性は、異なるパスとSYNフラグの存在です。
MPTCP SYN packets on the first subflow of a connection contain the MP_CAPABLE option (Section 3.1). If this is dropped, MPTCP SHOULD fall back to regular TCP. If packets with the MP_JOIN option (Section 3.2) are dropped, the paths will simply not be used.
接続の最初のサブフローのMPTCP SYNパケットには、MP_CAPABLEオプションが含まれています（セクション3.1）。これがドロップされた場合、MPTCPは通常のTCPにフォールバックする必要があります（SHOULD）。 MP_JOINオプション（セクション3.2）を含むパケットがドロップされた場合、パスは単に使用されません。
If a middlebox strips options but otherwise passes the packets unchanged, MPTCP will behave safely. If an MP_CAPABLE option is dropped on either the outgoing path or the return path, the initiating host can fall back to regular TCP, as illustrated in Figure 17 and discussed in Section 3.1.
ミドルボックスがオプションを削除しても、パケットを変更せずに渡す場合、MPTCPは安全に動作します。 MP_CAPABLEオプションが発信パスまたは戻りパスのいずれかにドロップされた場合、図17に示され、セクション3.1で説明されているように、開始ホストは通常のTCPにフォールバックできます。
Host A Host B
| Middlebox M |
| | |
| SYN (MP_CAPABLE) | SYN |
|-------------------|---------------->|
| SYN/ACK |
|<------------------------------------|
a) MP_CAPABLE option stripped on outgoing path
Host A Host B
| SYN (MP_CAPABLE) |
|-------------------------------------->|
| Middlebox M |
| | |
| SYN/ACK |SYN/ACK (MP_CAPABLE)|
|<-----------------|--------------------|
b) MP_CAPABLE option stripped on return path
Figure 17: Connection Setup with Middleboxes That Strip Options from Packets
図17：パケットからオプションを取り除くミドルボックスを使用した接続設定
Subflow SYNs contain the MP_JOIN option. If this option is stripped on the outgoing path, the SYN will appear to be a regular SYN to Host B. Depending on whether there is a listening socket on the target port, Host B will reply with either a SYN/ACK or a RST (subflow connection fails). When Host A receives the SYN/ACK, it sends a RST because the SYN/ACK does not contain the MP_JOIN option and its token. Either way, the subflow setup fails but otherwise does not affect the MPTCP connection as a whole.
サブフローSYNには、MP_JOINオプションが含まれています。このオプションが発信パスで削除される場合、SYNはホストBへの通常のSYNであるように見えます。ターゲットポートにリスニングソケットがあるかどうかに応じて、ホストBはSYN / ACKまたはRST（サブフロー接続は失敗します）。ホストAはSYN / ACKを受信すると、SYN / ACKにMP_JOINオプションとそのトークンが含まれていないため、RSTを送信します。どちらの方法でも、サブフローのセットアップは失敗しますが、それ以外の場合はMPTCP接続全体には影響しません。
We now examine data flow with MPTCP, assuming that the flow is correctly set up, which implies that the options in the SYN packets were allowed through by the relevant middleboxes. If options are allowed through and there is no resegmentation or coalescing to TCP segments, Multipath TCP flows can proceed without problems.
次に、フローが正しく設定されていると仮定して、MPTCPを使用したデータフローを調べます。これは、SYNパケットのオプションが関連するミドルボックスによって許可されたことを意味します。オプションの通過が許可されており、TCPセグメントへの再分割または合体がない場合、マルチパスTCPフローは問題なく続行できます。
The case when options get stripped on data packets is discussed in Section 3.7. If only some MPTCP options are stripped, behavior is not deterministic. If some Data Sequence Mappings are lost, the connection can continue so long as mappings exist for the subflow-level data (e.g., if multiple maps have been sent that reinforce each other). If some subflow-level space is left unmapped, however, the subflow is treated as broken and is closed, using the process described in Section 3.7. MPTCP should survive with a loss of some Data ACKs, but performance will degrade as the fraction of stripped options increases. We do not expect such cases to appear in practice, though: most middleboxes will either strip all options or let them all through.
オプションがデータパケットから取り除かれるケースについては、セクション3.7で説明します。一部のMPTCPオプションのみが削除される場合、動作は確定的ではありません。一部のデータシーケンスマッピングが失われた場合、サブフローレベルのデータのマッピングが存在する限り、接続は継続できます（たとえば、互いに補強する複数のマップが送信されている場合）。ただし、サブフローレベルのスペースがマップされていないままになっている場合、サブフローは壊れているものとして扱われ、セクション3.7で説明されているプロセスを使用して閉じられます。 MPTCPは一部のデータACKが失われても存続するはずですが、除去されたオプションの割合が増えるとパフォーマンスが低下します。ただし、このようなケースが実際に発生することは想定されていません。ほとんどのミドルボックスでは、すべてのオプションが削除されるか、すべてが通過します。
We end this section with a list of middlebox classes, their behavior, and the elements in the MPTCP design that allow operation through such middleboxes. Issues surrounding dropping packets with options or stripping options were discussed above and are not included here:
このセクションの最後に、ミドルボックスクラス、それらの動作、およびそのようなミドルボックスを介した操作を可能にするMPTCP設計の要素のリストを示します。オプション付きのパケットのドロップまたはオプションのストリッピングに関する問題は上記で説明されており、ここには含まれていません。
* NATs (Network Address (and port) Translators) [RFC3022] change the source address (and often the source port) of packets. This means that a host will not know its public-facing address for signaling in MPTCP. Therefore, MPTCP permits implicit address addition via the MP_JOIN option, and the handshake mechanism ensures that connection attempts to private addresses [RFC1918], since they are authenticated, will only set up subflows to the correct hosts. Explicit address removal is undertaken by an Address ID to allow no knowledge of the source address.
* NAT（ネットワークアドレス（およびポート）トランスレータ）[RFC3022]は、パケットの送信元アドレス（および多くの場合、送信元ポート）を変更します。これは、ホストがMPTCPでのシグナリング用の公開アドレスを知らないことを意味します。したがって、MPTCPはMP_JOINオプションを介した暗黙のアドレス追加を許可し、ハンドシェイクメカニズムは、プライベートアドレス[RFC1918]への接続試行が認証されるため、正しいホストへのサブフローのみをセットアップすることを保証します。明示的なアドレスの削除は、送信元アドレスを認識できないようにするために、アドレスIDによって行われます。
* Performance Enhancing Proxies (PEPs) [RFC3135] might proactively ACK data to increase performance. MPTCP, however, relies on accurate congestion control signals from the end host, and non-MPTCP-aware PEPs will not be able to provide such signals. MPTCP will, therefore, fall back to single-path TCP or close the problematic subflow (see Section 3.7).
* Performance Enhancing Proxies（PEPs）[RFC3135]は、データを積極的にACKしてパフォーマンスを向上させる場合があります。ただし、MPTCPはエンドホストからの正確な輻輳制御信号に依存しており、MPTCP非対応のPEPはそのような信号を提供できません。したがって、MPTCPはシングルパスTCPにフォールバックするか、問題のあるサブフローを閉じます（セクション3.7を参照）。
* Traffic normalizers [norm] may not allow holes in sequence numbers, and they may cache packets and retransmit the same data. MPTCP looks like standard TCP on the wire and will not retransmit different data on the same subflow sequence number. In the event of a retransmission, the same data will be retransmitted on the original TCP subflow even if it is additionally retransmitted at the connection level on a different subflow.
* トラフィックノーマライザ[norm]はシーケンス番号のホールを許可しない場合があり、パケットをキャッシュして同じデータを再送信する場合があります。 MPTCPは標準のTCPのように見え、同じサブフローシーケンス番号で異なるデータを再送信しません。再送信が発生した場合、同じデータは、別のサブフローの接続レベルでさらに再送信されても、元のTCPサブフローで再送信されます。
* Firewalls [RFC2979] might perform Initial Sequence Number (ISN) randomization on TCP connections. MPTCP uses relative sequence numbers in Data Sequence Mappings to cope with this. Like NATs, firewalls will not permit many incoming connections, so MPTCP supports address signaling (ADD_ADDR) so that a multiaddressed host can invite its peer behind the firewall/NAT to connect out to its additional interface.
* ファイアウォール[RFC2979]は、TCP接続で初期シーケンス番号（ISN）のランダム化を実行する場合があります。 MPTCPは、これに対処するために、データシーケンスマッピングで相対シーケンス番号を使用します。 NATと同様に、ファイアウォールは多くの着信接続を許可しないため、MPTCPはアドレスシグナリング（ADD_ADDR）をサポートしているため、マルチアドレスホストは、ファイアウォール/ NATの背後にあるピアを招待して、追加のインターフェイスに接続できます。
* Intrusion Detection Systems / Intrusion Prevention Systems (IDSs/IPSs) observe packet streams for patterns and content that could threaten a network. MPTCP may require the instrumentation of additional paths, and an MPTCP-aware IDS or IPS would need to read MPTCP tokens to correlate data from multiple subflows to maintain comparable visibility into all of the traffic between devices. Without such changes, an IDS would get an incomplete view of the traffic, increasing the risk of missing traffic of interest (false negatives) and increasing the chances of erroneously identifying a subflow as a risk due to only seeing partial data (false positives).
* 侵入検知システム/侵入防止システム（IDS / IPS）は、ネットワークを脅かす可能性のあるパターンやコンテンツのパケットストリームを監視します。 MPTCPは追加のパスの計測を必要とする場合があり、MPTCP対応のIDSまたはIPSはMPTCPトークンを読み取って複数のサブフローからのデータを相関させ、デバイス間のすべてのトラフィックの可視性を同等に保つ必要があります。そのような変更がない場合、IDSはトラフィックの不完全なビューを取得し、関心のあるトラフィックを見逃すリスク（偽陰性）を増大させ、部分的なデータしか表示しないため（偽陽性）、サブフローをリスクとして誤って識別する可能性を増大させます。
* Application-level middleboxes such as content-aware firewalls may alter the payload within a subflow -- for example, rewriting URIs in HTTP traffic. MPTCP will detect such changes using the checksum and close the affected subflow(s), if there are other subflows that can be used. If all subflows are affected, MPTCP will fall back to TCP, allowing such middleboxes to change the payload. MPTCP-aware middleboxes should be able to adjust the payload and MPTCP metadata in order not to break the connection.
* コンテンツ対応ファイアウォールなどのアプリケーションレベルのミドルボックスは、サブフロー内のペイロードを変更する可能性があります。たとえば、HTTPトラフィックのURIを書き換えます。 MPTCPは、使用できる他のサブフローがある場合、チェックサムを使用してそのような変更を検出し、影響を受けるサブフローを閉じます。すべてのサブフローが影響を受ける場合、MPTCPはTCPにフォールバックし、そのようなミドルボックスがペイロードを変更できるようにします。 MPTCP対応のミドルボックスは、接続を切断しないように、ペイロードとMPTCPメタデータを調整できる必要があります。
In addition, all classes of middleboxes may affect TCP traffic in the following ways:
さらに、ミドルボックスのすべてのクラスは、次のようにTCPトラフィックに影響を与える可能性があります。
* TCP options may be removed, or packets with unknown options dropped, by many classes of middleboxes. It is intended that the initial SYN exchange, with a TCP option, will be sufficient to identify the path's capabilities. If such a packet does not get through, MPTCP will end up falling back to regular TCP.
* ミドルボックスの多くのクラスによって、TCPオプションが削除されるか、不明なオプションを持つパケットが削除される場合があります。パスの機能を識別するには、TCPオプションを使用した最初のSYN交換で十分であることを意図しています。そのようなパケットが通過しない場合、MPTCPは通常のTCPにフォールバックします。
* Segmentation/coalescing (e.g., TCP segmentation offloading) might copy options between packets and might strip some options. MPTCP's Data Sequence Mapping includes the relative subflow sequence number instead of using the sequence number in the segment. In this way, the mapping is independent of the packets that carry it.
* セグメンテーション/結合（TCPセグメンテーションオフロードなど）により、パケット間でオプションがコピーされ、一部のオプションが削除される場合があります。 MPTCPのデータシーケンスマッピングには、セグメント内のシーケンス番号を使用する代わりに、相対サブフローシーケンス番号が含まれます。このように、マッピングはそれを運ぶパケットから独立しています。
* The receive window may be shrunk by some middleboxes at the subflow level. MPTCP will use the maximum window at the data level but will also obey subflow-specific windows.
* 受信ウィンドウは、サブフローレベルのミドルボックスによって縮小される場合があります。 MPTCPは、データレベルで最大ウィンドウを使用しますが、サブフロー固有のウィンドウにも従います。
This document obsoletes [RFC6824]. As such, IANA has updated several registries to point to this document. In addition, this document creates one new registry. These topics are described in the following subsections.
このドキュメントは廃止されました[RFC6824]。そのため、IANAは、このドキュメントを指すようにいくつかのレジストリを更新しました。さらに、このドキュメントは1つの新しいレジストリを作成します。これらのトピックについては、以下のサブセクションで説明します。
IANA has updated the "TCP Option Kind Numbers" registry to point to this document for Multipath TCP, as shown in Table 1:
IANAは、「TCPオプションの種類番号」レジストリを更新して、表1に示すように、マルチパスTCPに関するこのドキュメントを指すようにしました。
+------+--------+-----------------------+-----------+
| Kind | Length | Meaning | Reference |
+======+========+=======================+===========+
| 30 | N | Multipath TCP (MPTCP) | RFC 8684 |
+------+--------+-----------------------+-----------+
Table 1: TCP Option Kind Numbers
表1：TCPオプションの種類番号
The 4-bit MPTCP subtype in the "MPTCP Option Subtypes" subregistry under the "Transmission Control Protocol (TCP) Parameters" registry was defined in [RFC6824]. Since [RFC6824] is an Experimental RFC and not a Standards Track RFC, and since no further entries have occurred beyond those pointing to [RFC6824], IANA has replaced the existing registry with the contents of Table 2 and with the following explanatory note.
「Transmission Control Protocol（TCP）Parameters」レジストリの「MPTCP Option Subtypes」サブレジストリにある4ビットMPTCPサブタイプは、[RFC6824]で定義されています。 [RFC6824]は試験的なRFCであり、Standards Track RFCではないため、[RFC6824]を指すエントリ以外にエントリが発生していないため、IANAは既存のレジストリを表2の内容と以下の説明に置き換えました。
Note: This registry specifies the MPTCP Option Subtypes for MPTCP v1, which obsoletes the Experimental MPTCP v0. For the MPTCP v0 subtypes, please refer to [RFC6824].
注：このレジストリは、MPTCP v1のMPTCPオプションサブタイプを指定します。これは、実験的なMPTCP v0を廃止します。 MPTCP v0サブタイプについては、[RFC6824]を参照してください。
+-------+-----------------+----------------------+-------------+
| Value | Symbol | Name | Reference |
+=======+=================+======================+=============+
| 0x0 | MP_CAPABLE | Multipath Capable | RFC 8684, |
| | | | Section 3.1 |
+-------+-----------------+----------------------+-------------+
| 0x1 | MP_JOIN | Join Connection | RFC 8684, |
| | | | Section 3.2 |
+-------+-----------------+----------------------+-------------+
| 0x2 | DSS | Data Sequence Signal | RFC 8684, |
| | | (Data ACK and Data | Section 3.3 |
| | | Sequence Mapping) | |
+-------+-----------------+----------------------+-------------+
| 0x3 | ADD_ADDR | Add Address | RFC 8684, |
| | | | Section |
| | | | 3.4.1 |
+-------+-----------------+----------------------+-------------+
| 0x4 | REMOVE_ADDR | Remove Address | RFC 8684, |
| | | | Section |
| | | | 3.4.2 |
+-------+-----------------+----------------------+-------------+
| 0x5 | MP_PRIO | Change Subflow | RFC 8684, |
| | | Priority | Section |
| | | | 3.3.8 |
+-------+-----------------+----------------------+-------------+
| 0x6 | MP_FAIL | Fallback | RFC 8684, |
| | | | Section 3.7 |
+-------+-----------------+----------------------+-------------+
| 0x7 | MP_FASTCLOSE | Fast Close | RFC 8684, |
| | | | Section 3.5 |
+-------+-----------------+----------------------+-------------+
| 0x8 | MP_TCPRST | Subflow Reset | RFC 8684, |
| | | | Section 3.6 |
+-------+-----------------+----------------------+-------------+
| 0xf | MP_EXPERIMENTAL | Reserved for Private | |
| | | Use | |
+-------+-----------------+----------------------+-------------+
Table 2: MPTCP Option Subtypes
表2：MPTCPオプションのサブタイプ
Values 0x9 through 0xe are currently unassigned. Option 0xf is reserved for use by private experiments. Its use may be formalized in a future specification. Future assignments in this registry are to be defined by Standards Action as defined by [RFC8126]. Assignments consist of the MPTCP subtype's symbolic name, its associated value, and a reference to its specification.
0x9から0xeまでの値は現在割り当てられていません。オプション0xfは、プライベートな実験で使用するために予約されています。その使用は、将来の仕様で正式化される可能性があります。このレジストリの将来の割り当ては、[RFC8126]で定義されているように、標準化アクションによって定義されます。割り当ては、MPTCPサブタイプの記号名、それに関連付けられた値、およびその仕様への参照で構成されます。
The "MPTCP Handshake Algorithms" subregistry under the "Transmission Control Protocol (TCP) Parameters" registry was defined in [RFC6824]. Since [RFC6824] is an Experimental RFC and not a Standards Track RFC, and since no further entries have occurred beyond those pointing to [RFC6824], IANA has replaced the existing registry with the contents of Table 3 and with the following explanatory note.
「Transmission Control Protocol（TCP）Parameters」レジストリの下の「MPTCP Handshake Algorithms」サブレジストリは、[RFC6824]で定義されています。 [RFC6824]は試験的なRFCであり、Standards Track RFCではないため、[RFC6824]を指すエントリ以外にエントリが発生していないため、IANAは既存のレジストリを表3の内容と以下の説明に置き換えました。
Note: This registry specifies the MPTCP Handshake Algorithms for MPTCP v1, which obsoletes the Experimental MPTCP v0. For the MPTCP v0 subtypes, please refer to [RFC6824].
注：このレジストリは、MPTCP v1のMPTCPハンドシェイクアルゴリズムを指定します。これは、実験的MPTCP v0を廃止します。 MPTCP v0サブタイプについては、[RFC6824]を参照してください。
+----------+---------------------------------+-------------+
| Flag Bit | Meaning | Reference |
+==========+=================================+=============+
| A | Checksum required | RFC 8684, |
| | | Section 3.1 |
+----------+---------------------------------+-------------+
| B | Extensibility | RFC 8684, |
| | | Section 3.1 |
+----------+---------------------------------+-------------+
| C | Do not attempt to establish new | RFC 8684, |
| | subflows to the source address. | Section 3.1 |
+----------+---------------------------------+-------------+
| D-G | Unassigned | |
+----------+---------------------------------+-------------+
| H | HMAC-SHA256 | RFC 8684, |
| | | Section 3.2 |
+----------+---------------------------------+-------------+
Table 3: MPTCP Handshake Algorithms
表3：MPTCPハンドシェイクアルゴリズム
Note that the meanings of bits "D" through "H" can be dependent upon bit "B", depending on how the Extensibility parameter is defined in future specifications; see Section 3.1 for more information.
ビット「D」から「H」の意味は、ビット「B」に依存する可能性があることに注意してください。これは、拡張性パラメータが将来の仕様でどのように定義されるかによって異なります。詳細については、セクション3.1を参照してください。
Future assignments in this registry are also to be defined by Standards Action as defined by [RFC8126]. Assignments consist of the value of the flags, a symbolic name for the algorithm, and a reference to its specification.
このレジストリの将来の割り当ても、[RFC8126]で定義されているように、標準アクションによって定義されます。割り当ては、フラグの値、アルゴリズムのシンボル名、およびその仕様への参照で構成されます。
IANA has created a further subregistry, "MPTCP MP_TCPRST Reason Codes" under the "Transmission Control Protocol (TCP) Parameters" registry, based on the reason code in the MP_TCPRST (Section 3.6) message. Initial values for this registry are given in Table 4; future assignments are to be defined by Specification Required as defined by [RFC8126]. Assignments consist of the value of the code, a short description of its meaning, and a reference to its specification. The maximum value is 0xff.
IANAは、MP_TCPRST（セクション3.6）メッセージの理由コードに基づいて、「Transmission Control Protocol（TCP）Parameters」レジストリの下に、さらにサブレジストリ「MPTCP MP_TCPRST Reason Codes」を作成しました。このレジストリの初期値を表4に示します。将来の割り当ては、[RFC8126]で定義されている仕様要求によって定義されます。割り当ては、コードの値、その意味の簡単な説明、およびその仕様への参照で構成されます。最大値は0xffです。
+------+-----------------------------+-----------------------+
| Code | Meaning | Reference |
+======+=============================+=======================+
| 0x00 | Unspecified error | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
| 0x01 | MPTCP-specific error | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
| 0x02 | Lack of resources | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
| 0x03 | Administratively prohibited | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
| 0x04 | Too much outstanding data | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
| 0x05 | Unacceptable performance | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
| 0x06 | Middlebox interference | RFC 8684, Section 3.6 |
+------+-----------------------------+-----------------------+
Table 4: MPTCP MP_TCPRST Reason Codes
表4：MPTCP MP_TCPRST理由コード
As guidance to the designated expert [RFC8126], assignments should not normally be refused unless codepoint space is becoming scarce, provided that there is a clear distinction from other, already-existing codes and also provided that there is sufficient guidance for implementers both sending and receiving these codes.
指定された専門家[RFC8126]へのガイダンスとして、他の既存のコードと明確な区別があり、送信者と送信者の両方に十分なガイダンスがあることを条件として、コードポイントスペースが不足しない限り、割り当ては通常拒否されるべきではありません。これらのコードを受け取ります。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[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>.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-editor .org / info / rfc2104>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>.
[RFC5961]ラマイア、A。、スチュワート、R。、およびM.ダラル、「ウィンドウ内のブラインド攻撃に対するTCPの堅牢性の向上」、RFC 5961、DOI 10.17487 / RFC5961、2010年8月、<https：//www.rfc- editor.org/info/rfc5961>。
[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>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：//www.rfc- editor.org/info/rfc6234>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[deployments] Bonaventure, O. and S. Seo, "Multipath TCP Deployments", IETF Journal 2016, November 2016, <https://www.ietfjournal.org/multipath-tcp-deployments/>.
[デプロイメント] Bonaventure、O。およびS. Seo、「マルチパスTCPデプロイメント」、IETF Journal 2016、2016年11月、<https://www.ietfjournal.org/multipath-tcp-deployments/>。
[howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., and M. Handley, "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP", Usenix Symposium on Networked Systems Design and Implementation 2012, April 2012, <https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu>.
[ハウハード] Raiciu、C.、Paasch、C.、Barre、S.、Ford、A.、Honda、M.、Duchene、F.、Bonaventure、O。、およびM. Handley、「どれほど難しいか展開可能なマルチパスTCPの設計と実装」、ネットワークシステムの設計と実装に関するUsenixシンポジウム2012、2012年4月、<https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu>。
[norm] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", Usenix Security Symposium 2001, August 2001, <https://www.usenix.org/legacy/events/sec01/full_papers/ handley/handley.pdf>.
[標準] Handley、M.、Paxson、V。、およびC. Kreibich、「ネットワーク侵入検知：回避、トラフィックの正規化、およびエンドツーエンドのプロトコルセマンティクス」、Usenixセキュリティシンポジウム2001、2001年8月、<https：/ /www.usenix.org/legacy/events/sec01/full_papers/handley/handley.pdf>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、GJ、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、 <https://www.rfc-editor.org/info/rfc1918>。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<https：//www.rfc- editor.org/info/rfc2018>。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, <https://www.rfc-editor.org/info/rfc2979>.
[RFC2979] Freed、N。、「インターネットファイアウォールの動作と要件」、RFC 2979、DOI 10.17487 / RFC2979、2000年10月、<https://www.rfc-editor.org/info/rfc2979>。
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.
[RFC2992] Hopps、C。、「Analysis of an Equal-Cost Multi-Path Algorithm」、RFC 2992、DOI 10.17487 / RFC2992、2000年11月、<https://www.rfc-editor.org/info/rfc2992>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<https://www.rfc-editor.org/info/ rfc3022>。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <https://www.rfc-editor.org/info/rfc3135>.
[RFC3135] Border、J.、Kojo、M.、Griner、J。、モンテネグロ、G。、およびZ. Shelby、「リンク関連の劣化を軽減するためのパフォーマンス強化プロキシ」、RFC 3135、DOI 10.17487 / RFC3135、6月2001、<https://www.rfc-editor.org/info/rfc3135>。
[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>.
[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>。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.
[RFC4987] Eddy、W。、「TCP SYN Flooding Attacks and Common Mitigations」、RFC 4987、DOI 10.17487 / RFC4987、2007年8月、<https://www.rfc-editor.org/info/rfc4987>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https://www.rfc-editor.org/info/ rfc5681>。
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, <https://www.rfc-editor.org/info/rfc6181>.
[RFC6181] Bagnulo、M。、「複数のアドレスを使用したマルチパス操作のためのTCP拡張の脅威分析」、RFC 6181、DOI 10.17487 / RFC6181、2011年3月、<https://www.rfc-editor.org/info/rfc6181> 。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.
[RFC6182] Ford、A.、Raiciu、C.、Handley、M.、Barre、S.、J。Iyengar、「マルチパスTCP開発のアーキテクチャガイドライン」、RFC 6182、DOI 10.17487 / RFC6182、2011年3月、<https ：//www.rfc-editor.org/info/rfc6182>。
[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>.
[RFC6356] Raiciu、C.、Handley、M。、およびD. Wischik、「マルチパストランスポートプロトコルの結合された輻輳制御」、RFC 6356、DOI 10.17487 / RFC6356、2011年10月、<https：//www.rfc-editor。 org / info / rfc6356>。
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC6528] Gont、F。、およびS. Bellovin、「Defenceingに対するSequence Number Attacks」、RFC 6528、DOI 10.17487 / RFC6528、2012年2月、<https://www.rfc-editor.org/info/rfc6528>。
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <https://www.rfc-editor.org/info/rfc6824>.
[RFC6824] Ford、A.、Raiciu、C.、Handley、M。、およびO. Bonaventure、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、RFC 6824、DOI 10.17487 / RFC6824、2013年1月、<https：// www.rfc-editor.org/info/rfc6824>。
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, <https://www.rfc-editor.org/info/rfc6897>.
[RFC6897] Scharf、M。およびA. Ford、「マルチパスTCP（MPTCP）アプリケーションインターフェイスの考慮事項」、RFC 6897、DOI 10.17487 / RFC6897、2013年3月、<https://www.rfc-editor.org/info/rfc6897 >。
[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>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V。、およびR. Scheffenegger、編、「高性能のTCP拡張機能」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：// www.rfc-editor.org/info/rfc7323>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：//www.rfc-editor .org / info / rfc7413>。
[RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, July 2015, <https://www.rfc-editor.org/info/rfc7430>.
[RFC7430] Bagnulo、M.、Paasch、C.、Gont、F.、Bonaventure、O。、およびC. Raiciu、「Analysis of Residual Threats and Potible Fix for Multipath TCP（MPTCP）」、RFC 7430、DOI 10.17487 / RFC7430、2015年7月、<https://www.rfc-editor.org/info/rfc7430>。
[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>.
[RFC8041] Bonaventure、O.、Paasch、C。、およびG. Detal、「マルチパスTCPの使用例と運用経験」、RFC 8041、DOI 10.17487 / RFC8041、2017年1月、<https：//www.rfc-editor .org / info / rfc8041>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[TCPLO] Ramaiah, A., "TCP option space extension", Work in Progress, Internet-Draft, draft-ananth-tcpm-tcpoptext-00, 26 March 2012, <https://tools.ietf.org/html/draft-ananth-tcpm-tcpoptext-00>.
[TCPLO]ラマイア、A。、「TCPオプションスペース拡張」、作業中、インターネットドラフト、draft-ananth-tcpm-tcpoptext-00、2012年3月26日、<https://tools.ietf.org/html/ draft-ananth-tcpm-tcpoptext-00>。
The TCP option space is limited due to the length of the Data Offset field in the TCP header (4 bits), which defines the TCP header length in 32-bit words. With the standard TCP header being 20 bytes, this leaves a maximum of 40 bytes for options, and many of these may already be used by options such as timestamp and SACK.
TCPヘッダーの長さを32ビットワードで定義するTCPヘッダーのデータオフセットフィールドの長さ（4ビット）により、TCPオプションスペースは制限されます。標準のTCPヘッダーが20バイトなので、オプションには最大40バイトが残り、これらの多くはタイムスタンプやSACKなどのオプションですでに使用されている可能性があります。
We performed a brief study on the commonly used TCP options in SYN, data, and pure ACK packets and found that there is enough room to fit all the options discussed in this document.
SYN、データ、および純粋なACKパケットで一般的に使用されるTCPオプションについて簡単な調査を行ったところ、このドキュメントで説明されているすべてのオプションに適合する十分な余地があることがわかりました。
SYN packets typically include the following options: Maximum Segment Size (MSS) (4 bytes), window scale (3 bytes), SACK permitted (2 bytes), and timestamp (10 bytes). The sum of these options is 19 bytes. Some operating systems appear to pad each option up to a word boundary, thus using 24 bytes (a brief survey suggests that Windows XP and Mac OS X do this, whereas Linux does not). Optimistically, therefore, we have 21 bytes available, or 16 if options have to be word-aligned. In either case, however, the SYN versions of MP_CAPABLE (12 bytes) and MP_JOIN (12 or 16 bytes) will fit in this remaining space.
SYNパケットには通常、最大セグメントサイズ（MSS）（4バイト）、ウィンドウスケール（3バイト）、許可されるSACK（2バイト）、およびタイムスタンプ（10バイト）のオプションが含まれます。これらのオプションの合計は19バイトです。一部のオペレーティングシステムは、各オプションを単語の境界まで埋めるため、24バイトを使用しているように見えます（簡単な調査では、Windows XPとMac OS Xはこれを行うが、Linuxはそうしないことを示唆しています）。したがって、楽観的には、21バイト、またはオプションをワード境界で整列させる必要がある場合は16バイトを使用できます。ただし、どちらの場合も、SYNバージョンのMP_CAPABLE（12バイト）およびMP_JOIN（12または16バイト）がこの残りのスペースに収まります。
Note that due to the use of a 64-bit data-level sequence space, it is feasible that MPTCP will not require the timestamp option for protection against wrapped sequence numbers (per the Protection Against Wrapped Sequences (PAWS) mechanism, as described in [RFC7323]), since the data-level sequence space has far less chance of wrapping. Confirmation of the validity of this optimization is left for further study.
64ビットのデータレベルのシーケンススペースを使用しているため、MPTCPは、ラップされたシーケンス番号に対する保護のためにタイムスタンプオプションを必要としない可能性があることに注意してください（[Protected Against Wrapped Sequences（PAWS）メカニズムによる。 RFC7323]）、データレベルのシーケンススペースはラップする可能性がはるかに少ないためです。この最適化の有効性の確認は、今後の調査に委ねられます。
TCP data packets typically carry timestamp options in every packet, taking 10 bytes (or 12, with padding). That leaves 30 bytes (or 28, if word-aligned). The DSS option varies in length, depending on (1) whether the Data Sequence Mapping, DATA_ACK, or both are included, (2) whether the sequence numbers in use are 4 or 8 octets, and (3) whether the checksum is present. The maximum size of the DSS option is 28 bytes, so even that will fit in the available space. But unless a connection is both bidirectional and high-bandwidth, it is unlikely that all that option space will be required on each DSS option.
TCPデータパケットは、通常、すべてのパケットにタイムスタンプオプションを持ち、10バイト（または12、パディングあり）を使用します。これにより、30バイト（ワード境界で整列されている場合は28バイト）が残ります。 DSSオプションの長さは、（1）データシーケンスマッピング、DATA_ACK、またはその両方が含まれるかどうか、（2）使用中のシーケンス番号が4または8オクテットかどうか、（3）チェックサムが存在するかどうかによって異なります。 DSSオプションの最大サイズは28バイトであるため、それでも使用可能なスペースに収まります。ただし、接続が双方向かつ高帯域幅である場合を除き、各DSSオプションでそのすべてのオプションスペースが必要になることはほとんどありません。
Within the DSS option, it is not necessary to include the Data Sequence Mapping and DATA_ACK in each packet, and in many cases it may be possible to alternate their presence (so long as the mapping covers the data being sent in the subsequent packet). It would also be possible to alternate between 4-byte and 8-byte sequence numbers in each option.
DSSオプション内では、各パケットにデータシーケンスマッピングとDATA_ACKを含める必要はありません。多くの場合、それらの存在を変更できます（マッピングが後続のパケットで送信されるデータをカバーする限り）。各オプションで4バイトと8バイトのシーケンス番号を交互に使用することもできます。
On subflow and connection setup, an MPTCP option is also set on the third packet (an ACK). These are 20 bytes (for MP_CAPABLE) and 24 bytes (for MP_JOIN), both of which will fit in the available option space.
サブフローと接続のセットアップでは、MPTCPオプションも3番目のパケット（ACK）に設定されます。これらは、20バイト（MP_CAPABLEの場合）および24バイト（MP_JOINの場合）で、どちらも使用可能なオプションスペースに収まります。
Pure ACKs in TCP typically contain only timestamps (10 bytes). Here, Multipath TCP typically needs to encode only the DATA_ACK (maximum of 12 bytes). Occasionally, ACKs will contain SACK information. Depending on the number of lost packets, SACK may utilize the entire option space. If a DATA_ACK had to be included, then it is probably necessary to reduce the number of SACK blocks to accommodate the DATA_ACK. However, the presence of the DATA_ACK is unlikely to be necessary in a case where SACK is in use, since until at least some of the SACK blocks have been retransmitted, the cumulative data-level ACK will not be moving forward (or if it does, due to retransmissions on another path, then that path can also be used to transmit the new DATA_ACK).
TCPの純粋なACKには、通常、タイムスタンプ（10バイト）のみが含まれます。ここで、マルチパスTCPは通常、DATA_ACK（最大12バイト）のみをエンコードする必要があります。時折、ACKにはSACK情報が含まれます。失われたパケットの数に応じて、SACKはオプションスペース全体を利用する場合があります。 DATA_ACKを含める必要がある場合は、DATA_ACKに対応するためにSACKブロックの数を減らす必要があるでしょう。ただし、SACKが使用されている場合は、DATA_ACKの存在が必要になることはほとんどありません。SACKブロックの少なくとも一部が再送信されるまで、累積データレベルのACKは前進しないためです（または、 、別のパスでの再送信により、そのパスは新しいDATA_ACKの送信にも使用できます。
The ADD_ADDR option can be between 16 and 30 bytes, depending on (1) whether IPv4 or IPv6 is used and (2) whether or not the port number is present. It is unlikely that such signaling would fit in a data packet (although if there is space, it is fine to include it). It is recommended that duplicate ACKs not be used with any other payload or options, in order to transmit these rare signals. Note that this is the reason for mandating that duplicate ACKs with MPTCP options not be taken as a signal of congestion.
ADD_ADDRオプションは、（1）IPv4とIPv6のどちらを使用するか、および（2）ポート番号が存在するかどうかに応じて、16から30バイトの間になる場合があります。そのようなシグナリングがデータパケットに収まる可能性は低いです（スペースがある場合は、それを含めても問題ありません）。これらのまれな信号を送信するために、他のペイロードやオプションで重複したACKを使用しないことをお勧めします。これは、MPTCPオプションを使用したACKの重複を輻輳の信号と見なさないように義務付けている理由です。
TCP Fast Open (TFO) is an experimental TCP extension, described in [RFC7413], which has been introduced to allow the sending of data one RTT earlier than with regular TCP. This is considered a valuable gain, as very short connections are very common, especially for HTTP request/response schemes. It achieves this by sending the SYN segment together with the application's data and allowing the listener to reply immediately with data after the SYN/ACK. [RFC7413] secures this mechanism by using a new TCP option that includes a cookie that is negotiated in a preceding connection.
TCP Fast Open（TFO）は、[RFC7413]で説明されている実験的なTCP拡張であり、通常のTCPよりも1 RTT早くデータを送信できるようにするために導入されました。非常に短い接続が非常に一般的であり、特にHTTP要求/応答スキームの場合、これは貴重な利益と見なされます。これは、SYNセグメントをアプリケーションのデータと一緒に送信し、リスナーがSYN / ACKの後にデータですぐに応答できるようにすることでこれを実現します。 [RFC7413]は、前の接続でネゴシエートされるCookieを含む新しいTCPオプションを使用して、このメカニズムを保護します。
When using TFO in conjunction with MPTCP, there are two key points to take into account, as detailed below.
TTCPをMPTCPと組み合わせて使用する場合、以下で説明するように、考慮すべき2つの重要なポイントがあります。
When a TFO initiator first connects to a listener, it cannot immediately include data in the SYN for security reasons [RFC7413]. Instead, it requests a cookie that will be used in subsequent connections. This is done with the TCP cookie request/response options, of 2 bytes and 6-18 bytes, respectively (depending on the chosen cookie length).
TFOイニシエータが最初にリスナーに接続するとき、セキュリティ上の理由から[SYCにデータをすぐに含めることはできません[RFC7413]。代わりに、後続の接続で使用されるCookieを要求します。これは、それぞれ2バイトと6〜18バイトのTCP Cookie要求/応答オプションを使用して行われます（選択したCookieの長さに応じて異なります）。
TFO and MPTCP can be combined, provided that the total length of all the options does not exceed the maximum 40 bytes possible in TCP:
TFOとMPTCPを組み合わせることができます。ただし、すべてのオプションの合計長がTCPで可能な最大40バイトを超えないことが条件です。
* In the SYN: MPTCP uses a 4-byte MP_CAPABLE option. The sum of the MPTCP and TFO options is 6 bytes. With typical TCP options using up to 19 bytes in the SYN (24 bytes if options are padded at a word boundary), there is enough space to combine the MP_CAPABLE with the TFO cookie request.
* SYN：MPTCPは4バイトのMP_CAPABLEオプションを使用します。 MPTCPオプションとTFOオプションの合計は6バイトです。 SYNで最大19バイトを使用する一般的なTCPオプション（オプションがワード境界でパディングされる場合は24バイト）では、MP_CAPABLEをTFO Cookieリクエストと組み合わせるのに十分なスペースがあります。
* In the SYN + ACK: MPTCP uses a 12-byte MP_CAPABLE option, but now the TFO option can be as long as 18 bytes. Since the maximum option length may be exceeded, it is up to the listener to avoid this problem by using a shorter cookie. As an example, if we consider that 19 bytes are used for classical TCP options, the maximum possible cookie length would be 7 bytes. Note that, for the SYN packet, the same limitation applies to subsequent connections (because the initiator then echoes the cookie back to the listener). Finally, if the security impact of reducing the cookie size is not deemed acceptable, the listener can reduce the amount of space used by other TCP options by omitting the TCP timestamps (as outlined in Appendix A).
* SYN + ACKでは、MPTCPは12バイトのMP_CAPABLEオプションを使用しますが、TFOオプションは18バイトまでの長さにできるようになりました。オプションの最大長を超える可能性があるため、短いCookieを使用してこの問題を回避するのはリスナーの責任です。例として、19バイトが従来のTCPオプションに使用されていると考えると、可能な最大のCookieの長さは7バイトになります。 SYNパケットの場合、同じ制限が後続の接続に適用されることに注意してください（イニシエーターがCookieをリスナーにエコーバックするため）。最後に、Cookieサイズを減らすことによるセキュリティへの影響が許容できないと見なされた場合、リスナーは、TCPタイムスタンプを省略することで、他のTCPオプションが使用するスペースの量を減らすことができます（付録Aで概説）。
In the TCP establishment phase, MPTCP uses a key exchange that is used to generate the Initial Data Sequence Numbers (IDSNs). In particular, the SYN with MP_CAPABLE occupies the first octet of data sequence space. With TFO, one way to handle the data sent together with the SYN would be to consider an implicit DSS mapping that covers that SYN segment (since there is not enough space in the SYN to include a DSS option). The problem with that approach is that if a middlebox modifies the TFO data, this will not be noticed by MPTCP because of the absence of a DSS checksum. For example, a TCP-aware (but not MPTCP-aware) middlebox could insert bytes at the beginning of the stream and adapt the TCP checksum and sequence numbers accordingly. With an implicit mapping, this information would give to the initiator and listener a different view of the DSS mapping; there would be no way to detect this inconsistency, because the DSS checksum is not present.
TCP確立フェーズでは、MPTCPは、初期データシーケンス番号（IDSN）の生成に使用されるキー交換を使用します。特に、MP_CAPABLEを指定したSYNは、データシーケンススペースの最初のオクテットを占有します。 TFOを使用する場合、SYNと共に送信されるデータを処理する1つの方法は、そのSYNセグメントをカバーする暗黙のDSSマッピングを検討することです（SYNにはDSSオプションを含めるのに十分なスペースがないため）。このアプローチの問題は、ミドルボックスがTFOデータを変更した場合、DSSチェックサムがないため、MPTCPがこれを認識しないことです。たとえば、TCP対応（MPTCP対応ではない）ミドルボックスは、ストリームの先頭にバイトを挿入し、それに応じてTCPチェックサムとシーケンス番号を適合させることができます。暗黙的なマッピングでは、この情報により、イニシエーターとリスナーにDSSマッピングの異なるビューが提供されます。 DSSチェックサムが存在しないため、この不整合を検出する方法はありません。
To solve this issue, the TFO data must not be considered part of the data sequence number space: the SYN with MP_CAPABLE still occupies the first octet of data sequence space, but then the first non-TFO data byte occupies the second octet. This guarantees that, if the use of the DSS checksum is negotiated, all data in the data sequence number space is checksummed. We also note that this does not entail a loss of functionality, because TFO data is always only sent on the initial subflow, before any attempt to create additional subflows.
この問題を解決するには、TFOデータをデータシーケンス番号スペースの一部と見なしてはなりません。MP_CAPABLEを含むSYNはデータシーケンススペースの最初のオクテットを占有しますが、最初の非TFOデータバイトは2番目のオクテットを占有します。これにより、DSSチェックサムの使用がネゴシエートされた場合、データシーケンス番号スペース内のすべてのデータがチェックサムされることが保証されます。また、追加のサブフローを作成しようとする前に、TFOデータは常に最初のサブフローでのみ送信されるため、これによって機能が失われることはありません。
A few examples of possible "TFO + MPTCP" establishment scenarios are shown below.
可能な「TFO + MPTCP」確立シナリオのいくつかの例を以下に示します。
Before an initiator can send data together with the SYN, it must request a cookie from the listener, as shown in Figure 18. (Note: The sequence number and length are annotated in Figure 18 as Seq(Length) (e.g., "S. 0(0)") and used as such in the subsequent figures (e.g., "S 0(20)" in Figure 19).) This is done by simply combining the TFO and MPTCP options.
イニシエーターがSYNと一緒にデータを送信する前に、図18に示すように、リスナーにCookieを要求する必要があります。 0（0） "）であり、後続の図でそのまま使用されます（たとえば、図19の" S 0（20） "）。これは、TFOオプションとMPTCPオプションを単に組み合わせることによって行われます。
initiator listener
| |
| S Seq=0(Length=0) <MP_CAPABLE>, <TFO cookie request> |
| --------------------------------------------------------> |
| |
| S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie> |
| <-------------------------------------------------------- |
| |
| . 0(0) ack 1 <MP_CAPABLE> |
| --------------------------------------------------------> |
| |
Figure 18: Cookie Request
図18：Cookieリクエスト
Once this is done, the received cookie can be used for TFO, as shown in Figure 19. In this example, the initiator first sends 20 bytes in the SYN. The listener immediately replies with 100 bytes following the SYN-ACK, to which the initiator replies with 20 more bytes. Note that the last segment in the figure has a TCP sequence number of 21, while the DSS subflow sequence number is 1 (because the TFO data is not part of the data sequence number space, as explained in Appendix B.2.
これが完了すると、図19に示すように、受信したCookieをTFOに使用できます。この例では、イニシエーターは最初にSYNで20バイトを送信します。リスナーはすぐにSYN-ACKに続く100バイトで応答し、イニシエーターはさらに20バイトで応答します。図の最後のセグメントのTCPシーケンス番号は21ですが、DSSサブフローシーケンス番号は1です（TFOデータは付録B.2で説明されているように、データシーケンス番号スペースの一部ではないため）。
initiator listener
| |
| S 0(20) <MP_CAPABLE>, <TFO cookie> |
| --------------------------------------------------------> |
| |
| S. 0(0) ack 21 <MP_CAPABLE> |
| <-------------------------------------------------------- |
| |
| . 1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100> |
| <-------------------------------------------------------- |
| |
| . 21(0) ack 1 <MP_CAPABLE> |
| --------------------------------------------------------> |
| |
| . 21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20> |
| --------------------------------------------------------> |
| |
Figure 19: The Listener Supports TFO
図19：リスナーはTFOをサポートします
In Figure 20, the listener does not support TFO. The initiator detects that no state is created in the listener (as no data is ACKed) and now sends the MP_CAPABLE in the third packet, in order for the listener to build its MPTCP context at the end of the establishment. Now, the TFO data, when retransmitted, becomes part of the Data Sequence Mapping because it is effectively sent (in fact re-sent) after the establishment.
図20では、リスナーはTFOをサポートしていません。イニシエーターは、リスナーに状態が作成されていないことを検出し（データがACKされないため）、3番目のパケットでMP_CAPABLEを送信して、リスナーが確立の最後にMPTCPコンテキストを構築できるようにします。これで、TFOデータは、再送信されると、確立後に効果的に送信される（実際には再送信される）ため、データシーケンスマッピングの一部になります。
initiator listener
| |
| S 0(20) <MP_CAPABLE>, <TFO cookie> |
| --------------------------------------------------------> |
| |
| S. 0(0) ack 1 <MP_CAPABLE> |
| <-------------------------------------------------------- |
| |
| . 1(0) ack 1 <MP_CAPABLE> |
| --------------------------------------------------------> |
| |
| . 1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20> |
| --------------------------------------------------------> |
| |
| . 0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0> |
| <-------------------------------------------------------- |
| |
Figure 20: The Listener Does Not Support TFO
図20：リスナーはTFOをサポートしていません
It is also possible that the listener acknowledges only part of the TFO data, as illustrated in Figure 21. The initiator will simply retransmit the missing data together with a DSS mapping.
図21に示すように、リスナーがTFOデータの一部のみを確認することも可能です。イニシエーターは、不足しているデータをDSSマッピングと一緒に再送信するだけです。
initiator listener
| |
| S 0(1000) <MP_CAPABLE>, <TFO cookie> |
| --------------------------------------------------------> |
| |
| S. 0(0) ack 501 <MP_CAPABLE> |
| <-------------------------------------------------------- |
| |
| . 501(0) ack 1 <MP_CAPABLE> |
| --------------------------------------------------------> |
| |
| . 501(500) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=500> |
| --------------------------------------------------------> |
| |
Figure 21: Partial Data Acknowledgment
図21：部分的なデータの確認
Conceptually, an MPTCP connection can be represented as an MPTCP protocol control block (PCB) that contains several variables that track the progress and the state of the MPTCP connection and a set of linked TCP control blocks that correspond to the subflows that have been established.
概念的には、MPTCP接続は、MPTCP接続の進行状況と状態を追跡するいくつかの変数と、確立されたサブフローに対応するリンクされたTCP制御ブロックのセットを含むMPTCPプロトコル制御ブロック（PCB）として表すことができます。
RFC 793 [RFC0793] specifies several state variables. Whenever possible, we reuse the same terminology as RFC 793 to describe the state variables that are maintained by MPTCP.
RFC 793 [RFC0793]は、いくつかの状態変数を指定しています。可能な限り、RFC 793と同じ用語を再利用して、MPTCPによって維持される状態変数について説明します。
The MPTCP control block contains the following variables per connection.
MPTCP制御ブロックには、接続ごとに次の変数が含まれています。
Local.Token (32 bits): This is the token chosen by the local host on this MPTCP connection. The token must be unique among all established MPTCP connections and is generated from the local key.
Local.Token（32ビット）：これは、このMPTCP接続のローカルホストによって選択されたトークンです。トークンは、確立されたすべてのMPTCP接続間で一意である必要があり、ローカルキーから生成されます。
Local.Key (64 bits): This is the key sent by the local host on this MPTCP connection.
Local.Key（64ビット）：これは、このMPTCP接続でローカルホストによって送信されるキーです。
Remote.Token (32 bits): This is the token chosen by the remote host on this MPTCP connection, generated from the remote key.
Remote.Token（32ビット）：これは、このMPTCP接続でリモートホストによって選択されたトークンで、リモートキーから生成されます。
Remote.Key (64 bits): This is the key chosen by the remote host on this MPTCP connection.
Remote.Key（64ビット）：これは、このMPTCP接続でリモートホストによって選択されたキーです。
MPTCP.Checksum (flag): This flag is set to true if at least one of the hosts has set the "A" bit in the MP_CAPABLE options exchanged during connection establishment; otherwise, it is set to false. If this flag is set, the checksum must be computed in all DSS options.
MPTCP.Checksum（フラグ）：このフラグは、接続の確立中に交換されるMP_CAPABLEオプションで少なくとも1つのホストが「A」ビットを設定した場合にtrueに設定されます。それ以外の場合は、falseに設定されます。このフラグが設定されている場合、すべてのDSSオプションでチェックサムを計算する必要があります。
SND.UNA (64 bits): This is the data sequence number of the next byte to be acknowledged, at the MPTCP connection level. This variable is updated upon reception of a DSS option containing a DATA_ACK.
SND.UNA（64ビット）：これは、MPTCP接続レベルで確認される次のバイトのデータシーケンス番号です。この変数は、DATA_ACKを含むDSSオプションを受信すると更新されます。
SND.NXT (64 bits): This is the data sequence number of the next byte to be sent. SND.NXT is used to determine the value of the DSN in the DSS option.
SND.NXT（64ビット）：これは、送信される次のバイトのデータシーケンス番号です。 SND.NXTは、DSSオプションのDSNの値を決定するために使用されます。
SND.WND (32 bits): This is the send window. 32 bits if the features in RFC 7323 are used; 16 bits otherwise. MPTCP maintains the send window at the MPTCP connection level, and the same window is shared by all subflows. All subflows use the MPTCP connection-level SND.WND to compute the SEQ.WND value that is sent in each transmitted segment.
SND.WND（32ビット）：これは送信ウィンドウです。 RFC 7323の機能を使用する場合は32ビット。それ以外の場合は16ビット。 MPTCPは送信ウィンドウをMPTCP接続レベルで維持し、同じウィンドウがすべてのサブフローで共有されます。すべてのサブフローは、MPTCP接続レベルのSND.WNDを使用して、送信された各セグメントで送信されるSEQ.WND値を計算します。
RCV.NXT (64 bits): This is the data sequence number of the next byte that is expected on the MPTCP connection. This state variable is modified upon reception of in-order data. The value of RCV.NXT is used to specify the DATA_ACK that is sent in the DSS option on all subflows.
RCV.NXT（64ビット）：これは、MPTCP接続で予期される次のバイトのデータシーケンス番号です。この状態変数は、順序正しいデータを受信すると変更されます。 RCV.NXTの値は、すべてのサブフローのDSSオプションで送信されるDATA_ACKを指定するために使用されます。
RCV.WND (32 bits): This is the connection-level receive window, which is the maximum of the RCV.WND on all the subflows. 32 bits if the features in RFC 7323 are used; 16 bits otherwise.
RCV.WND（32ビット）：これは接続レベルの受信ウィンドウであり、すべてのサブフローのRCV.WNDの最大値です。 RFC 7323の機能を使用する場合は32ビット。それ以外の場合は16ビット。
The MPTCP control block also contains a list of the TCP control blocks that are associated with the MPTCP connection.
MPTCP制御ブロックには、MPTCP接続に関連付けられているTCP制御ブロックのリストも含まれています。
Note that the TCP control block on the TCP subflows does not contain the RCV.WND and SND.WND state variables, as these are maintained at the MPTCP connection level and not at the subflow level.
TCPサブフローのTCP制御ブロックには、RCV.WNDおよびSND.WND状態変数が含まれていないことに注意してください。これらは、サブフローレベルではなくMPTCP接続レベルで維持されるためです。
Inside each TCP control block, the following state variables are defined.
各TCP制御ブロック内では、次の状態変数が定義されています。
SND.UNA (32 bits): This is the sequence number of the next byte to be acknowledged on the subflow. This variable is updated upon reception of each TCP acknowledgment on the subflow.
SND.UNA（32ビット）：これは、サブフローで確認応答される次のバイトのシーケンス番号です。この変数は、サブフローで各TCP確認応答を受信すると更新されます。
SND.NXT (32 bits): This is the sequence number of the next byte to be sent on the subflow. SND.NXT is used to set the value of SEG.SEQ upon transmission of the next segment.
SND.NXT（32ビット）：これは、サブフローで送信される次のバイトのシーケンス番号です。 SND.NXTは、次のセグメントの送信時にSEG.SEQの値を設定するために使用されます。
RCV.NXT (32 bits): This is the sequence number of the next byte that is expected on the subflow. This state variable is modified upon reception of in-order segments. The value of RCV.NXT is copied to the SEG.ACK field of the next segments transmitted on the subflow.
RCV.NXT（32ビット）：これは、サブフローで予期される次のバイトのシーケンス番号です。この状態変数は、順序正しいセグメントを受信すると変更されます。 RCV.NXTの値は、サブフローで送信される次のセグメントのSEG.ACKフィールドにコピーされます。
RCV.WND (32 bits): This is the subflow-level receive window that is updated with the window field from the segments received on this subflow. 32 bits if the features in RFC 7323 are used; 16 bits otherwise.
RCV.WND（32ビット）：これは、このサブフローで受信されたセグメントのウィンドウフィールドで更新されるサブフローレベルの受信ウィンドウです。 RFC 7323の機能を使用する場合は32ビット。それ以外の場合は16ビット。
The diagram in Figure 22 shows the Finite State Machine for connection-level closure. This illustrates how the DATA_FIN connection-level signal (indicated in the diagram as the DFIN flag on a DATA_ACK) (1) interacts with subflow-level FINs and (2) permits break-before-make handover between subflows.
図22の図は、接続レベルのクロージャのための有限状態機械を示しています。これは、DATA_FIN接続レベル信号（図ではDATA_ACKのDFINフラグとして示されています）を示しています（1）サブフローレベルのFINと相互作用し、（2）サブフロー間のブレークビフォアメイクハンドオーバーを許可します。
+---------+
| M_ESTAB |
+---------+
M_CLOSE | | rcv DATA_FIN
------- | | -------
+---------+ snd DATA_FIN / \ snd DATA_ACK[DFIN] +-------+
| M_FIN |<----------------- ------------------->|M_CLOSE|
| WAIT-1 |--------------------------- | WAIT |
+---------+ rcv DATA_FIN \ +-------+
| rcv DATA_ACK[DFIN] ------- | M_CLOSE |
| -------------- snd DATA_ACK | ------- |
| CLOSE all subflows | snd DATA_FIN |
V V V
+-----------+ +-----------+ +----------+
|M_FINWAIT-2| | M_CLOSING | |M_LAST-ACK|
+-----------+ +-----------+ +----------+
| rcv DATA_ACK[DFIN] | rcv DATA_ACK[DFIN] |
| rcv DATA_FIN -------------- | -------------- |
| ------- CLOSE all subflows | CLOSE all subflows |
| snd DATA_ACK[DFIN] V delete MPTCP PCB V
\ +-----------+ +--------+
------------------------>|M_TIME WAIT|---------------->|M_CLOSED|
+-----------+ +--------+
All subflows in CLOSED
------------
delete MPTCP PCB
Figure 22: Finite State Machine for Connection Closure
図22：接続を閉じるための有限状態マシン
This appendix lists the key technical changes between [RFC6824], which specifies MPTCP v0; and this document, which obsoletes [RFC6824] and specifies MPTCP v1. Note that this specification is not backward compatible with [RFC6824].
この付録では、MPTCP v0を指定する[RFC6824]間の主要な技術変更を示します。 [RFC6824]を廃止し、MPTCP v1を指定するこのドキュメント。この仕様は[RFC6824]との後方互換性がないことに注意してください。
* This document incorporates lessons learned from the various implementations, deployments, and experiments gathered in the documents "Use Cases and Operational Experience with Multipath TCP" [RFC8041] and the IETF Journal article "Multipath TCP Deployments" [deployments].
* このドキュメントには、「マルチパスTCPの使用例と運用経験」[RFC8041]とIETFジャーナルの記事「マルチパスTCPデプロイメント」[デプロイメント]で収集されたさまざまな実装、デプロイメント、実験から学んだ教訓が組み込まれています。
* Connection initiation, through the exchange of the MP_CAPABLE MPTCP option, is different from [RFC6824]. The SYN no longer includes the initiator's key, to allow the MP_CAPABLE option on the SYN to be shorter in length and to avoid duplicating the sending of keying material.
* MP_CAPABLE MPTCPオプションの交換による接続開始は、[RFC6824]とは異なります。 SYNにイニシエーターのキーが含まれなくなったため、SYNのMP_CAPABLEオプションの長さが短くなり、キー情報の送信の重複を回避できます。
* This also ensures reliable delivery of the key on the MP_CAPABLE option by allowing its transmission to be combined with data and thus using TCP's built-in reliability mechanism. If the initiator does not immediately have data to send, the MP_CAPABLE option with the keys will be repeated on the first data packet. If the other end is the first to send, then the presence of the DSS option implicitly confirms the receipt of the MP_CAPABLE.
* これにより、MP_CAPABLEオプションでのキーの確実な配信も保証されます。これは、その送信をデータと組み合わせて、TCPに組み込まれた信頼性メカニズムを使用することで可能になります。イニシエーターにすぐに送信するデータがない場合、キーを指定したMP_CAPABLEオプションが最初のデータパケットで繰り返されます。もう一方の端が最初に送信する場合、DSSオプションの存在により、MP_CAPABLEの受信が暗黙的に確認されます。
* In the Flags field of MP_CAPABLE, "C" is now assigned to mean that the sender of this option will not accept additional MPTCP subflows to the source address and port. This improves efficiency -- for example, in cases where the sender is behind a strict NAT.
* MP_CAPABLEのFlagsフィールドで、このオプションの送信者が送信元アドレスとポートへの追加のMPTCPサブフローを受け入れないことを意味するように「C」が割り当てられました。これにより、効率が向上します。たとえば、送信者が厳密なNATの背後にいる場合などです。
* In the Flags field of MP_CAPABLE, "H" now indicates the use of HMAC-SHA256 (rather than HMAC-SHA1).
* MP_CAPABLEのFlagsフィールドの「H」は、HMAC-SHA1ではなくHMAC-SHA256の使用を示します。
* Connection initiation also defines the procedure for version negotiation, for implementations that support both v0 [RFC6824] and v1 (this document).
* 接続開始は、v0 [RFC6824]とv1の両方をサポートする実装（このドキュメント）のバージョンネゴシエーションの手順も定義します。
* The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as it provides better security. It is used to generate the token in the MP_JOIN and ADD_ADDR messages and to set the IDSN.
* セキュリティが向上するため、HMAC-SHA256（HMAC-SHA1ではなく）アルゴリズムが使用されます。これは、MP_JOINおよびADD_ADDRメッセージでトークンを生成し、IDSNを設定するために使用されます。
* A new subflow-level option exists to signal reasons for sending a RST on a subflow (MP_TCPRST (Section 3.6)); this can help an implementation decide whether to attempt later reconnection.
* サブフローでRSTを送信する理由を通知する新しいサブフローレベルのオプションが存在します（MP_TCPRST（セクション3.6））。これは、実装が後で再接続を試みるかどうかを決定するのに役立ちます。
* The MP_PRIO option (Section 3.3.8), which is used to signal a change of priority for a subflow, no longer includes the AddrID field. Its purpose was to allow the changed priority to be applied on a subflow other than the one it was sent on. However, it was determined that this could be used by a man-in-the-middle to divert all traffic onto its own path, and MP_PRIO does not include a token or other type of security mechanism.
* サブフローの優先度の変更を通知するために使用されるMP_PRIOオプション（セクション3.3.8）には、AddrIDフィールドが含まれなくなりました。その目的は、変更された優先順位を、送信されたサブフロー以外のサブフローに適用できるようにすることでした。ただし、中間者がこれを使用してすべてのトラフィックを独自のパスに迂回できることが確認されており、MP_PRIOにはトークンやその他のタイプのセキュリティメカニズムは含まれていません。
* The ADD_ADDR option (Section 3.4.1), which is used to inform the other host about another potential address, is different in several ways. It now includes an HMAC of the added address, for enhanced security. In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned ("E") that is used as an "echo" so a host can indicate that it has received the option.
* 他のホストに別の潜在的なアドレスを通知するために使用されるADD_ADDRオプション（セクション3.4.1）は、いくつかの点で異なります。セキュリティを強化するために、追加されたアドレスのHMACが含まれるようになりました。さらに、ADD_ADDRオプションの信頼性が追加されました。IPVerフィールドがフラグフィールドに置き換えられ、1つのフラグが割り当てられ（「E」）、「エコー」として使用されるため、ホストは受信したことを示すことができます。オプション。
* This document describes an additional way of performing a Fast Close -- by sending an MP_FASTCLOSE option on a RST on all subflows. This allows the host to tear down the subflows and the connection immediately.
* このドキュメントでは、すべてのサブフローのRSTでMP_FASTCLOSEオプションを送信して、高速クローズを実行する追加の方法について説明します。これにより、ホストはサブフローと接続をすぐに切断できます。
* IANA has reserved the MPTCP option subtype of value 0xf for Private Use (Section 7.2). This document doesn't define how to use that value.
* IANAは、値0xfのMPTCPオプションサブタイプを私的使用のために予約しています（セクション7.2）。このドキュメントでは、その値の使用方法を定義していません。
* This document adds a new appendix (Appendix B), which discusses the usage of both MPTCP options and TFO options on the same packet.
* このドキュメントでは、同じパケットでのMPTCPオプションとTFOオプションの両方の使用法について説明する新しい付録（付録B）を追加しています。
Acknowledgments
謝辞
The authors gratefully acknowledge significant input into this document from Sebastien Barre and Andrew McDonald.
著者は、セバスチャン・バレとアンドリュー・マクドナルドからのこの文書への重要なインプットに感謝します。
The authors also wish to acknowledge reviews and contributions from Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal, Fabien Duchene, Xavier de Foy, Rahul Jadhav, Klemens Schragel, Mirja Kühlewind, Sheng Jiang, Alissa Cooper, Ines Robles, Roman Danyliw, Adam Roach, Eric Vyncke, and Ben Kaduk.
著者はまた、Iljitsch van Beijnum、Lars Eggert、Marcelo Bagnulo、Robert Hancock、Pasi Sarolahti、Toby Moncaster、Philip Eardley、Sergio Lembo、Lawrence Conroy、Yoshifumi Nishida、Bob Briscoe、Stein Gjesing、Andrew McGregからのレビューと貢献を認めたいジョージハンペル、アヌミタビスワス、ウェスエディ、アレクセイメルニコフ、フランシスデュポン、エイドリアンファレル、バリーレイバ、ロバートスパークス、ショーンターナー、スティーブンファレル、マーティンスティーマーリング、グレゴリーデタール、ファビアンデュシェン、ザビエルドフォワ、ラーフルジャダフ、クレメンスシュラーゲル、ミルジャKühlewind、Sheng Jiang、Alissa Cooper、Ines Robles、Roman Danyliw、Adam Roach、Eric Vyncke、Ben Kaduk。
Authors' Addresses
著者のアドレス
Alan Ford Pexip
アラン・フォード・ペキシップ
Email: alan.ford@gmail.com
Costin Raiciu University Politehnica of Bucharest Splaiul Independentei 313 Bucharest Romania
Costin Raiciu University Politehnica of Bucharest Splaiul Independentei 313ブカレストルーマニア
Email: costin.raiciu@cs.pub.ro
Mark Handley University College London Gower Street London WC1E 6BT United Kingdom
マークハンドラリーユニバーシティカレッジロンドンガワーストリートロンドンWC1E 6BTイギリス
Email: m.handley@cs.ucl.ac.uk
Olivier Bonaventure Université catholique de Louvain Pl. Ste Barbe, 2 1348 Louvain-la-Neuve Belgium
Olivier Bonaventureカトリックルーヴァン大学Pl。Ste Barbe、2 1348 Louvain-la-Neuveベルギー
Email: olivier.bonaventure@uclouvain.be
Christoph Paasch Apple, Inc. Cupertino, CA United States of America
Christoph Paasch Apple、Inc.クパチーノ、カリフォルニア州アメリカ合衆国
Email: cpaasch@apple.com