Jumbo TCP Options
Abstract
TCP options are currently limited to a total of 40 bytes. In common
implementations, half of those bytes are already taken. This
specification defines a protocol to allow greater than 65KB of option
data when both endpoints support it.
Table of Contents
1.
Notation and Conventions
2.
Rational
3.
Advertising support
4.
Jumbo option spaces
5.
Expected behaviour
6.
References
§
Author's Address
1.
Notation and Conventions
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 [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .).
2.
Rational
[RFC793] (Postel, J., “Transmission Control Protocol,” .) defines a 4-bit field in the TCP header which encodes the size of
the header in 4-byte words. Thus the maximum header size is 15*4=60
bytes. Of this, 20 bytes are taken up by non-options fields of the TCP
header, leaving 20 bytes for options.
Over time TCP has developed and many options are now used as standard in
common implementations. It's now common for 20 bytes of options to be
included in SYN packets. This restricts the scope of experimentation
with the TCP protocol since applications, like cryptography, often need
to deal with payloads greater than 20 bytes in length.
3.
Advertising support
We define a TCP option number 43, of length 2. Peers can include this
option in any TCP packet to advertise their support for this
specification for any future packet in either half-connection. (This
option number has not been assigned by IANA, rather we have picked a
number which we believe to be currently unused.)
4.
Jumbo option spaces
This specification additionally defines a TCP option number 42, of
length 4, which carries a 16-bit, unsigned, big-endian length. (This
option number has not been assigned by IANA, rather we have picked a
number which we believe to be currently unused.)
This length redefines the length, in bytes, of the TCP header and,
when found, overrides the length defined in [RFC793] (Postel, J., “Transmission Control Protocol,” .). It MUST NOT define
a length which is shorter than the [RFC793] (Postel, J., “Transmission Control Protocol,” .) length. It MUST be included
within the [RFC793] (Postel, J., “Transmission Control Protocol,” .) options space. It MUST NOT be sent to a peer unless
the sender knows that the peer supports this specification.
Knowlegde about the peer's support of this specification might come
from out-of-band means, but it's expected that peers will discover this
by the presence of either a type 42 or type 43 option in a previous
packet. A host MUST NOT assume that a peer supports this specification
because a previous TCP connection to the same IP address did.
5.
Expected behaviour
It's expected that option 43 will be included in initial SYN packet of
a conection. Because the sending host cannot have received knowledge
about the peer's support of this specification at that point, it
cannot include a type 42 packet.
If the peer supports this specification, it will include either a type
42 or type 43 option in the SYN+ACK reply. From this point on, either
host may include a type 42 option to extend the size of the options
payload in a future packet.
6. References
Author's Address