draft-ietf-mptcp-rfc6824bis-06.txt   draft-ietf-mptcp-rfc6824bis-07.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Pexip Internet-Draft Pexip
Obsoletes: 6824 (if approved) C. Raiciu Obsoletes: 6824 (if approved) C. Raiciu
Intended status: Experimental U. Politechnica of Bucharest Intended status: Experimental U. Politechnica of Bucharest
Expires: January 7, 2017 M. Handley Expires: May 1, 2017 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
C. Paasch C. Paasch
Apple, Inc. Apple, Inc.
July 6, 2016 October 28, 2016
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-06 draft-ietf-mptcp-rfc6824bis-07
Abstract Abstract
TCP/IP communication is currently restricted to a single path per TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network and, thus, improve user improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to experience through higher throughput and improved resilience to
network failure. network failure.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . . 4 1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . 4
1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5 1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 7 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8
2. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8
2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . . 9 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 8
2.2. Associating a New Subflow with an Existing MPTCP 2.2. Associating a New Subflow with an Existing MPTCP
Connection . . . . . . . . . . . . . . . . . . . . . . . . 9 Connection . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Informing the Other Host about Another Potential 2.3. Informing the Other Host about Another Potential Address 9
Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 10
2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 11 2.5. Requesting a Change in a Path's Priority . . . . . . . . 11
2.5. Requesting a Change in a Path's Priority . . . . . . . . . 11 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 11
2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 12 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 12
2.7. Notable Features . . . . . . . . . . . . . . . . . . . . . 12 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 12
3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13
3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 14 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 19
3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 19 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 24 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 26
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 26 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30
3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . . 29 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 30 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 31 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 33 3.3.7. Congestion Control Considerations . . . . . . . . . . 35
3.3.7. Congestion Control Considerations . . . . . . . . . . 35 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 35 3.4. Address Knowledge Exchange (Path Management) . . . . . . 37
3.4. Address Knowledge Exchange (Path Management) . . . . . . . 37 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 41 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43
3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44
3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 43 3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46
3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 45 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51
3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . . 50 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 51
3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 50 3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 51
3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 51 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52
3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . . 51 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53
3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . . 52 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 54
4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 55
5. Security Considerations . . . . . . . . . . . . . . . . . . . 54 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 57
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 57 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 62
8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 61 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 63
8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . . 62 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 63
8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . . 62 8.4. Experimental option registry . . . . . . . . . . . . . . 64
8.4. Experimental option registry . . . . . . . . . . . . . . . 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 64
9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 9.2. Informative References . . . . . . . . . . . . . . . . . 65
9.2. Informative References . . . . . . . . . . . . . . . . . . 64 Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 68
Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . . 66 Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 69
Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 68 B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 70
B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 68 B.1.1. Authentication and Metadata . . . . . . . . . . . . . 70
B.1.1. Authentication and Metadata . . . . . . . . . . . . . 68 B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 70
B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 69 B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 70
B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 69 B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 71
B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 69 B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 71
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 69 B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 71
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 70 Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 71
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72
1. Introduction 1. Introduction
Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793] Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793]
to provide a Multipath TCP [RFC6182] service, which enables a to provide a Multipath TCP [RFC6182] service, which enables a
transport connection to operate across multiple paths simultaneously. transport connection to operate across multiple paths simultaneously.
This document presents the protocol changes required to add multipath This document presents the protocol changes required to add multipath
capability to TCP; specifically, those for signaling and setting up capability to TCP; specifically, those for signaling and setting up
multiple paths ("subflows"), managing these subflows, reassembly of multiple paths ("subflows"), managing these subflows, reassembly of
data, and termination of sessions. This is not the only information data, and termination of sessions. This is not the only information
skipping to change at page 11, line 46 skipping to change at page 11, line 25
[Data Sequence Mapping] [Data Sequence Mapping]
[Data ACK] [Data ACK]
[Checksum] [Checksum]
2.5. Requesting a Change in a Path's Priority 2.5. Requesting a Change in a Path's Priority
Hosts can indicate at initial subflow setup whether they wish the 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 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 being used if there are no regular paths available. During a
connection, Host A can request a change in the priority of a subflow connection, Host A can request a change in the priority of a subflow
through the MP_PRIO signal to Host B. Further details are in through the MP_PRIO signal to Host B. Further details are in
Section 3.3.8. Section 3.3.8.
Host A Host B Host A Host B
------ ------ ------ ------
MP_PRIO -> MP_PRIO ->
2.6. Closing an MPTCP Connection 2.6. Closing an MPTCP Connection
When Host A wants to inform Host B that it has no more data to send, 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 Data Sequence Signal (see it signals this "Data FIN" as part of the Data Sequence Signal (see
skipping to change at page 17, line 42 skipping to change at page 17, line 32
B: The second bit, labeled "B", is an extensibility flag, and MUST be B: The second bit, labeled "B", is an extensibility flag, and MUST be
set to 0 for current implementations. This will be used for an set to 0 for current implementations. This will be used for an
extensibility mechanism in a future specification, and the impact extensibility mechanism in a future specification, and the impact
of this flag will be defined at a later date. If receiving a of this flag will be defined at a later date. If receiving a
message with the 'B' flag set to 1, and this is not understood, message with the 'B' flag set to 1, and this is not understood,
then this SYN MUST be silently ignored; the sender is expected to then this SYN MUST be silently ignored; the sender is expected to
retry with a format compatible with this legacy specification. retry with a format compatible with this legacy specification.
Note that the length of the MP_CAPABLE option, and the meanings of Note that the length of the MP_CAPABLE option, and the meanings of
bits "C" through "H", may be altered by setting B=1. bits "C" through "H", may be altered by setting B=1.
C through H: The remaining bits, labeled "C" through "H", are used 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 towards this address and port.
This is an efficiency improvement for 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.
D through H: The remaining bits, labeled "C" through "H", are used
for crypto algorithm negotiation. Currently only the rightmost for crypto algorithm negotiation. Currently only the rightmost
bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC- bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC-
SHA1 (as defined in Section 3.2). An implementation that only SHA1 (as defined in Section 3.2). An implementation that only
supports this method MUST set bit "H" to 1, and bits "C" through supports this method MUST set bit "H" to 1, and bits "C" through
"G" to 0. "G" to 0.
A crypto algorithm MUST be specified. If flag bits C through H are A crypto algorithm MUST be specified. If flag bits C through H are
all 0, the MP_CAPABLE option MUST be treated as invalid and ignored all 0, the MP_CAPABLE option MUST be treated as invalid and ignored
(that is, it must be treated as a regular TCP handshake). (that is, it must be treated as a regular TCP handshake).
skipping to change at page 39, line 31 skipping to change at page 40, line 13
ADD_ADDR option. If the port is not present in the ADD_ADDR option, ADD_ADDR option. If the port is not present in the ADD_ADDR option,
the HMAC message will nevertheless include two octets of value zero. the HMAC message will nevertheless include two octets of value zero.
The rationale for the HMAC is to prevent unauthorized entities from The rationale for the HMAC is to prevent unauthorized entities from
injecting ADD_ADDR signals in an attempt to hijack a connection. injecting ADD_ADDR signals in an attempt to hijack a connection.
Note that additionally the presence of this HMAC prevents the address Note that additionally the presence of this HMAC prevents the address
being changed in flight unless the key is known by an intermediary. 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 If a host receives an ADD_ADDR option for which it cannot validate
the HMAC, it SHOULD silently ignore the option. the HMAC, it SHOULD silently ignore the option.
A set of four flags are present after the subtype and before the A set of four flags are present after the subtype and before the
Address ID. These are currently unassigned and MUST be set to zero Address ID. Only the rightmost bit - labelled 'E' - is assinged
by a sender and MUST be ignored by the receiver. today. The other bits are currently unassigned and MUST be set to
zero by a sender and MUST be ignored by the receiver.
The 'E' bit 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. The lack of this echo can be used
by the initial ADD_ADDR sender to retransmit the ADD_ADDR according
to local policy.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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|(resvd)| Address ID | | Kind | Length |Subtype|(rsv)|E| Address ID |
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) | | Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Port (2 octets, optional) | | | Port (2 octets, optional) | |
+-------------------------------+ | +-------------------------------+ |
| Truncated HMAC (8 octets) | | Truncated HMAC (8 octets, if length > 10 octets) |
| +-------------------------------+ | +-------------------------------+
| | | |
+-------------------------------+ +-------------------------------+
Figure 12: Add Address (ADD_ADDR) Option Figure 12: Add Address (ADD_ADDR) Option
Due to the proliferation of NATs, it is reasonably likely that one Due to the proliferation of NATs, it is reasonably likely that one
host may attempt to advertise private addresses [RFC1918]. It is not host may attempt to advertise private addresses [RFC1918]. It is not
desirable to prohibit this, since there may be cases where both hosts desirable to prohibit this, since there may be cases where both hosts
have additional interfaces on the same private network, and a host have additional interfaces on the same private network, and a host
skipping to change at page 60, line 33 skipping to change at page 61, line 33
The authors gratefully acknowledge significant input into this The authors gratefully acknowledge significant input into this
document from Sebastien Barre and Andrew McDonald. document from Sebastien Barre and Andrew McDonald.
The authors also wish to acknowledge reviews and contributions from The authors also wish to acknowledge reviews and contributions from
Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock,
Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo,
Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing,
Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey
Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks,
Sean Turner, Stephen Farrell, Martin Stiemerling, and Gregory Detal. Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal, and
Fabien Duchene.
8. IANA Considerations 8. IANA Considerations
This document updates [RFC6824] and as such IANA is requested to This document updates [RFC6824] and as such IANA is requested to
update the TCP option space registry to point to this document for update the TCP option space registry to point to this document for
Multipath TCP, as follows: Multipath TCP, as follows:
+------+--------+-----------------------+---------------+ +------+--------+-----------------------+---------------+
| Kind | Length | Meaning | Reference | | Kind | Length | Meaning | Reference |
+------+--------+-----------------------+---------------+ +------+--------+-----------------------+---------------+
| 30 | N | Multipath TCP (MPTCP) | This document | | 30 | N | Multipath TCP (MPTCP) | This document |
+------+--------+-----------------------+---------------+ +------+--------+-----------------------+---------------+
Table 1: TCP Option Kind Numbers Table 1: TCP Option Kind Numbers
8.1. MPTCP Option Subtypes 8.1. MPTCP Option Subtypes
The 4-bit MPTCP subtype sub-registry ("MPTCP Option Subtypes" under The 4-bit MPTCP subtype sub-registry ("MPTCP Option Subtypes" under
the "Transmission Control Protocol (TCP) Parameters" registry) was the "Transmission Control Protocol (TCP) Parameters" registry) was
defined in [RFC6824]. This document defines one additional subtype defined in [RFC6824]. This document defines one additional subtype
(ADD_ADDR) and updates the references to this document for all sub- (ADD_ADDR) and updates the references to this document for all sub-
skipping to change at page 62, line 13 skipping to change at page 63, line 13
Values 0x9 through 0xe are currently unassigned. Values 0x9 through 0xe are currently unassigned.
8.2. MPTCP Handshake Algorithms 8.2. MPTCP Handshake Algorithms
IANA has created another sub-registry, "MPTCP Handshake Algorithms" IANA has created another sub-registry, "MPTCP Handshake Algorithms"
under the "Transmission Control Protocol (TCP) Parameters" registry, under the "Transmission Control Protocol (TCP) Parameters" registry,
based on the flags in MP_CAPABLE (Section 3.1). IANA is requested to based on the flags in MP_CAPABLE (Section 3.1). IANA is requested to
update the references of this table to this document, as follows: update the references of this table to this document, as follows:
+----------+-------------------+----------------------------+ +----------+-------------------+----------------------------+
| Flag Bit | Meaning | Reference | | Flag Bit | Meaning | Reference |
+----------+-------------------+----------------------------+ +----------+-------------------+----------------------------+
| A | Checksum required | This document, Section 3.1 | | A | Checksum required | This document, Section 3.1 |
| B | Extensibility | This document, Section 3.1 | | B | Extensibility | This document, Section 3.1 |
| C-G | Unassigned | | | C-G | Unassigned | |
| H | HMAC-SHA1 | This document, Section 3.2 | | H | HMAC-SHA1 | This document, Section 3.2 |
+----------+-------------------+----------------------------+ +----------+-------------------+----------------------------+
Table 3: MPTCP Handshake Algorithms Table 3: MPTCP Handshake Algorithms
Note that the meanings of bits C through H can be dependent upon bit Note that the meanings of bits C through H can be dependent upon bit
B, depending on how Extensibility is defined in future B, depending on how Extensibility is defined in future
specifications; see Section 3.1 for more information. specifications; see Section 3.1 for more information.
Future assignments in this registry are also to be defined by Future assignments in this registry are also to be defined by
Standards Action as defined by [RFC5226]. Assignments consist of the Standards Action as defined by [RFC5226]. Assignments consist of the
skipping to change at page 62, line 40 skipping to change at page 63, line 40
reference to its specification. reference to its specification.
8.3. MP_TCPRST Reason Codes 8.3. MP_TCPRST Reason Codes
IANA is requested to create a further sub-registry, "MP_TCPRST Reason IANA is requested to create a further sub-registry, "MP_TCPRST Reason
Codes" under the "Transmission Control Protocol (TCP) Parameters" Codes" under the "Transmission Control Protocol (TCP) Parameters"
registry, based on the reason code in MP_TCPRST (Section 3.6). The registry, based on the reason code in MP_TCPRST (Section 3.6). The
contents of this sub-registry are to to this document, as follows: contents of this sub-registry are to to this document, as follows:
+------+-----------------------------+----------------------------+ +------+-----------------------------+----------------------------+
| Code | Meaning | Reference | | Code | Meaning | Reference |
+------+-----------------------------+----------------------------+ +------+-----------------------------+----------------------------+
| 0x00 | Unspecified TCP error | This document, Section 3.6 | | 0x00 | Unspecified TCP error | This document, Section 3.6 |
| 0x01 | MPTCP specific error | This document, Section 3.6 | | 0x01 | MPTCP specific error | This document, Section 3.6 |
| 0x02 | Lack of resources | This document, Section 3.6 | | 0x02 | Lack of resources | This document, Section 3.6 |
| 0x03 | Administratively prohibited | This document, Section 3.6 | | 0x03 | Administratively prohibited | This document, Section 3.6 |
| 0x04 | Too much outstanding data | This document, Section 3.6 | | 0x04 | Too much outstanding data | This document, Section 3.6 |
| 0x05 | Unacceptable performance | This document, Section 3.6 | | 0x05 | Unacceptable performance | This document, Section 3.6 |
| 0x06 | Middlebox interference | This document, Section 3.6 | | 0x06 | Middlebox interference | This document, Section 3.6 |
+------+-----------------------------+----------------------------+ +------+-----------------------------+----------------------------+
skipping to change at page 63, line 37 skipping to change at page 64, line 37
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<http://www.rfc-editor.org/info/rfc6182>. <http://www.rfc-editor.org/info/rfc6182>.
[sha1] National Institute of Science and Technology, "Secure Hash [sha1] National Institute of Science and Technology, "Secure Hash
Standard", Federal Information Processing Standard Standard", Federal Information Processing Standard
(FIPS) 180-3, October 2008, <http://csrc.nist.gov/ (FIPS) 180-3, October 2008,
publications/fips/fips180-3/fips180-3_final.pdf>. <http://csrc.nist.gov/publications/fips/fips180-3/
fips180-3_final.pdf>.
9.2. Informative References 9.2. Informative References
[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, 2012,
<https://www.usenix.org/conference/nsdi12/how-hard-can-it-
be-designing-and-implementing-deployable-multipath-tcp>.
[norm] Handley, M., Paxson, V., and C. Kreibich, "Network
Intrusion Detection: Evasion, Traffic Normalization, and
End-to-End Protocol Semantics", Usenix Security 2001,
2001,
<http://www.usenix.org/events/sec01/full_papers/handley/
handley.pdf>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, DOI 10.17487/ Communication Layers", STD 3, RFC 1122,
RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <http://www.rfc-editor.org/info/rfc1122>.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, DOI 10.17487/RFC1323, for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
May 1992, <http://www.rfc-editor.org/info/rfc1323>. 1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, DOI 10.17487/ Selective Acknowledgment Options", RFC 2018,
RFC2018, October 1996, DOI 10.17487/RFC2018, October 1996,
<http://www.rfc-editor.org/info/rfc2018>. <http://www.rfc-editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet [RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
<http://www.rfc-editor.org/info/rfc2979>. <http://www.rfc-editor.org/info/rfc2979>.
skipping to change at page 65, line 45 skipping to change at page 67, line 11
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc6234>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols", Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011, RFC 6356, DOI 10.17487/RFC6356, October 2011,
<http://www.rfc-editor.org/info/rfc6356>. <http://www.rfc-editor.org/info/rfc6356>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
February 2012, <http://www.rfc-editor.org/info/rfc6528>. 2012, <http://www.rfc-editor.org/info/rfc6528>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>. <http://www.rfc-editor.org/info/rfc6824>.
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, Interface Considerations", RFC 6897, DOI 10.17487/RFC6897,
March 2013, <http://www.rfc-editor.org/info/rfc6897>. March 2013, <http://www.rfc-editor.org/info/rfc6897>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", [RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013, RFC 6994, DOI 10.17487/RFC6994, August 2013,
<http://www.rfc-editor.org/info/rfc6994>. <http://www.rfc-editor.org/info/rfc6994>.
[TCPLO] Ramaiah, A., "TCP option space extension", Work [TCPLO] Ramaiah, A., "TCP option space extension", Work
in Progress, March 2012. in Progress, March 2012.
[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, <https://www.usenix.org/
conference/nsdi12/
how-hard-can-it-be-designing-and-implementing-deployable-
multipath-tcp>.
[norm] Handley, M., Paxson, V., and C. Kreibich, "Network
Intrusion Detection: Evasion, Traffic Normalization, and
End-to-End Protocol Semantics", Usenix Security 2001,
2001, <http://www.usenix.org/events/sec01/full_papers/
handley/handley.pdf>.
Appendix A. Notes on Use of TCP Options Appendix A. Notes on Use of TCP Options
The TCP option space is limited due to the length of the Data Offset 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 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 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 leaves a maximum of 40 bytes for options, and many of these may
already be used by options such as timestamp and SACK. already be used by options such as timestamp and SACK.
We have performed a brief study on the commonly used TCP options in We have performed a brief study on the commonly used TCP options in
SYN, data, and pure ACK packets, and found that there is enough room SYN, data, and pure ACK packets, and found that there is enough room
 End of changes. 24 change blocks. 
106 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/