Shared Use of Experimental TCP Options
Extracted elements (23)
ExIDs combine properties of IANA FCFS-registered values with magic numbers to be robust to squatters who either fail to register or deliberately use others' codepoints. A purely conventional IANA FCFS registry was deemed insufficient given the observed reality of unauthorized codepoint reuse.
IANA Private Enterprise Numbers (PENs) were considered as ExIDs but rejected because their bit-width was undefined at the time (only recently proposed as 32 bits), they are assigned to organizations not individuals, and at 32 bits they would be larger than needed in many cases.
IEEE OUIs were considered as ExIDs but rejected because they are 24 bits (already larger than a 16-bit ExID), cost $1,885 each, and extending them for multiple experiments would require complex organizational coordination or a separate IANA registry.
The optional 32-bit ExID provides byte alignment in the TCP header that matches what a future conventionally-assigned TCP option codepoint would have, reducing implementation errors (especially word-alignment padding) when software is later migrated to an assigned codepoint.
For backward compatibility when migrating from experimental to assigned codepoints, implementers should send multiple SYNs with alternates rather than including both the experimental and assigned codepoint in the same segment.
The ExID field is considered part of the TCP option content, not the option header; its presence increases the effective Length field by the size of the ExID and is transparent to implementations that do not support TCP options.
A TCP ExID, if used in any TCP segment of a connection, MUST be present in the TCP SYN segments of that connection.
A TCP segment MUST NOT contain both an assigned TCP option codepoint and a TCP experimental option codepoint for the same protocol, to avoid wasteful consumption of limited TCP option space.
All ExIDs MUST be either 16 bits or 32 bits long.
All ExIDs MUST be unique based on their first 16 bits. IANA registers on an FCFS basis using the first two bytes, so those two bytes alone are sufficient to identify which experiment the option belongs to.
All protocols using ExIDs as described in this document MUST register those ExIDs with IANA.
All protocols using the TCP experimental option codepoints (253, 254) that are deployed outside controlled environments, such as in the public Internet, MUST use ExIDs as described in this document.
Experimental options with ExIDs that do not match any implemented protocol MUST be ignored.
Experiments that are not robust to ExID false positives SHOULD implement other detection measures, such as checksums or minimal digital signatures over the experimental options they support.
Once a TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use an ExID as part of that assigned codepoint, since the ExID would represent unnecessary overhead.
Options implementing the ExID mechanism SHOULD use 16-bit ExIDs, except where explicitly motivating the need for 32-bit ExIDs (e.g., to avoid false positives or maintain alignment with an expected future assigned codepoint).
Protocols requiring new TCP option codepoints that are not eligible for assigned values SHOULD use the existing TCP experimental option codepoints (253, 254) with ExIDs as described in this document.
TCP experimental option ExIDs, if used in any TCP segment of a connection, SHOULD be used in all TCP segments of that connection in which any experimental option is present.
TCP experimental option codepoints 253 and 254 (allocated by RFC 4727) are extended with an Experiment Identifier (ExID) field placed immediately after the Kind and Length bytes. The ExID is either 16 or 32 bits and differentiates concurrent experiments sharing the same codepoint.
IANA created the 'TCP Experimental Option Experiment Identifiers (TCP ExIDs)' registry. It records 16-bit and 32-bit ExIDs with a reference for each entry. Registration is FCFS based on the first two bytes of the ExID. IANA records known duplicate uses to assist debugging.
The ExID sharing mechanism is not intended to enhance, nor does it weaken, the existing state of security for TCP option processing. Security properties of individual experimental options remain unchanged.
TCP experimental option with a 16-bit ExID: Kind (1 byte), Length (1 byte), ExID (2 bytes), followed by option-specific contents. The ExID is stored in network-standard (big-endian) byte order.
TCP experimental option with a 32-bit ExID: Kind (1 byte), Length (1 byte), ExID (4 bytes), followed by option-specific contents. The ExID is stored in network-standard (big-endian) byte order.