TCP Capability OptionOrangeRennes35000Francemohamed.boucadair@orange.comOrangeRennes35000Francechristian.jacquenet@orange.comThis document defines an experimental TCP option that can be used to
negotiate a set of options that are supported by two TCP endpoints. The
main motivation for designing this option is the optimization of the
option space for SYN segments.TCP () can be extended by defining new
options. Because of the presence of NATs, firewalls, and other types of
flow-aware service functions between two TCP endpoints, means to ensure
that both endpoints support a given option, and that the paths used to
forward traffic between them do not involve nodes that strip or alter
the content of the options. This is actually achieved by negotiating the
support of a given option during the 3WHS stage.Typically, an option is included in the SYN message to inform the
remote TCP peer that the originating TCP peer is "X"-capable (that is,
it supports feature "X"). Upon receipt of the SYN message, and if no
intermediary node has stripped that option, the remote peer will echo
that option in a SYN/ACK if and only if it is also "X"-capable. Feature
"X" can then be used if the SYN/ACK message that is received by the
originating peer still carries the "X"-capable; the option must then be
included in the ACK.For example, several TCP extensions have been designed with this
design rationale in mind, e.g., SYN-EOS , EDO , SACK Permitted , MP_CAPABLE ,
etc. In the meantime, and given the limited TCP option space, it becomes
more challenging to include all options in a single SYN message.Several solutions have been proposed to solve that problem (e.g.,
) by means of
generating a companion TCP message. This document proposes a solution
that aims to optimize the required option space to facilitate the
insertion of several "X"-capable options.The option is primarily designed for network configurations where
the path between the TCP endpoints is managed (e.g., an MPTCP endpoint
embedded in the CPE and the remote MPTCP endpoint is located in the
network side; the paths between these endpoints are managed by the
same administrative entity such as in ).A flow-aware device that removes the option will disable all the
options that were included in the TCP Capability option. This is not
supposed in the target deployment context for this option.Some middleboxes may allow the TCP Capability option to pass
through, but the individual options may be blocked. This is not
supposed in the target deployment context for this option as those
flow-aware functions are managed.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.The format of the TCP Capability option is shown in . The option follows the format defined in ."Kind" is to be assigned by IANA (see ).[[Note: the format can follow ; An
ExID can be defined.]]"Kindi" carries the code point of an option that a TCP endpoint
supports and which it would like to negotiate with the remote peer. One
or multiple "Kindi" fields may be included.An endpoint that wishes to enable the capabilities associated with
one or multiple TCP options must include the corresponding "Kind" codes
in a TCP Capability option, which is included in the initial SYN. If the
remote peer supports at least one of the options carried in the TCP
Capability option, it replies with a SYN/ACK that includes the TCP
Capability option and which only carries the code points of the options
it supports. These values are then echoed in the ACK message the
originating peer sends back to the remote peer.When replying to a SYN message that includes a TCP Capability option,
the remote peer should preserve the same order of the "Kindi" fields (of
course, those that are not supported won't be included).The security considerations are to be completed.Particular thanks to xxxAuthors of this document request IANA to assign a new TCP "kind" for
the TCP Capability option.