[tcpm] TCP options - tcp-parameters IANA registry
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[tcpm] TCP options - tcp-parameters IANA registry
Hello all,
there are currently several proposals for new TCP options.
It has turned out onerous to get an overview of the TCP options
defined in the past, because the IANA 'tcp-parameters' registry
had not seen any additions until recently, for more than a decade,
and has not been maintained as carefully as might be desirable,
and because there are some apparently very obscure entries.
I have perceived the desire to build a more sound foundation
for my understanding of the issues related with those old and
proposed TCP options. To this end, I have tried to perform a
survey of the non-RFC IANA-registered TCP options, by sending
out a questionnary to personal registrants last January, and I
have tried to collect and condense information contained in RFCs,
and from the distributed wisdom of the net.
I'd like to acknowledge the efforts of those individuals who have
assisted my attempts to get in contact with the owners of legacy
registrations, and who have taken the time to fill in the
questionnary and to supply additional information.
Due to lack of spare time and a rather small rate of feedback
I eventually arrived at for the survey, it took me until now to
prepare an updated, corrected, amended, and annotated version of
the latest IANA 'tcp-parameters' file.
I hope that sharing this information with the list will help to
o complete the information, and
o serve as a solid base of additional information for ongoing
and starting discussions on various issues related to
(existing and) newly proposed TCP options.
Furthermore, I'm interested to hear whether it might make sense
to start an 'authorized' effort to improve and update the
'tcp-parameters' IANA registry, incorporating some of the
changes I have performed on my local copy.
Currently, an update to the IANA Considerations for the 'protocols'
registry is submitted (from within and) to the IESG for publication
as an RFC, and a similar effort is being discussed for the
'port-numbers' registry as well.
This therefore might be a good opportunity for a cleanup of the
'tcp-parameters' registry as well, closing the gaps and facelifting
the file.
I have enclosed as an attachment my current working copy of that
registry file, including `==>` tagged lines pointing to specific
solicitations for additional information.
For informational purposes, I have also left therein a few traces
of the history of the file, as recovered from local backup media.
Please send comments to the list or in private communication,
as deemed useful.
I will honor requests for non-disclosure of information sources
and/or details received in personal communication, and will try
to update the working copy based on feedback received, in a neutral
and abstract way -- following the style you'll already find there
currently.
( see attached file: annotated_tcp-parameters.20070216 )
Kind regards,
Alfred.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah at TR-Sys.de |
+------------------------+--------------------------------------------+
Transmission Control Protocol (TCP) Parameters -- per [RFC793] and [RFC2780]
==============================================
-- draft amended and annotated edition, based on 2007-02-15 IANA version --
Contents:
· TCP Option Kind Numbers
· TCP Alternate Checksum Numbers
Related registries:
· <port-numbers> - for TCP (server) port numbers,
per section 9.1 of [RFC2780]
· <tcp-header-flags> - for flag bits (in the 4th word of the TCP header),
per section 9.2 of [RFC2780]
TCP Option Kind Numbers -- per section 9.3 of [RFC2780]
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
The Transmission Control Protocol (TCP) [RFC793] has provision for optional
header fields identified by a one-octet Option Kind field.
Options 0 and 1 are exactly one octet which is their Kind field.
All other options have their one-octet Kind field, followed by a
one-octet Length field, followed by <Length>-2 octets of option data.
There are no alignment requirements for TCP options.
Optionally, alignment may be achieved by inserting instances of Option 1.
The maximum cumulative size of all options in one TCP header is 40 octets.
If the cumulative size of all options supplied is not an integer multiple of
4, Option 0 has to be appended, followed by zero or more zero-valued padding
octets, up to the TCP header size implied by the Data Offset TCP header field.
Assignment policy:
Standards Action or IESG Approval.
Registry:
Kind Length Meaning References (r) Notes
---- ------ ---------------------------------- --------------- ---------------
0 - End of Option List [RFC793] FS ANY fix
1 - No-Operation [RFC793] FS ANY fix
2 4 Maximum Segment Size [RFC793] FS SYY fix
3 3 WSOPT - Window Scale [RFC1072,RFC1323] PS SYZ fix
4 2 SACK Permitted [RFC1072,RFC2018] PS SYY fix
5 2+8*n SACK [RFC1072,RFC2018] PS EST fix (n)
6 6 Echo (obsoleted by option 8) [RFC1072] H SY+ fix (e)
7 6 Echo Reply (obsoleted by option 8) [RFC1072] H SY+ fix (e)
8 10 TSOPT - Time Stamp Option [RFC1323] PS SY+ fix (s)
9 2 Partial Order Connection Permitted [RFC1693] EX SYY fix (x)
10 3 Partial Order Service Profile [RFC1693] EX EST fix (x)
11 6 CC [RFC1644] EX H ANY fix (t)
12 6 CC.NEW [RFC1644] EX H SYN fix (t)
13 6 CC.ECHO [RFC1644] EX H SYA fix (t)
14 3 TCP Alternate Checksum Request [RFC1146] EX H SYY fix (x)
15 2+c TCP Alternate Checksum Data [RFC1146] EX H EST fix (cx)
16 ? Skeeter [Knowles] EX H (y)
17 ? Bubba [Knowles] EX H (y)
18 3 Trailer Checksum Option [Subbu+Bridges] EX H (y)
19 18 MD5 Signature Option [RFC2385] PS ANY fix
20 4 SCPS-TP Capabilities [Scott+SCPSTP] XS SYY fix
20 5+ SCPS-TP Extended Capabilities [Scott+SCPSTP] XS SYY fix
21 6+ Selective Negative Acknowledgements [Scott+SCPSTP] XS EST fix
22 2 Record Boundaries [Scott+SCPSTP] XS DTA fix
23 2 Corruption experienced [Scott+SCPSTP] XS EST fix
24 ? SNAP [Sukonnik] EX H (y)
25 - unassigned - (released 12/18/00) -
26 ? TCP Compression Filter [Bellovin] EX H fix (y)
27 8 Quick-Start Response [RFC4782] EX SYA/EST fix
28 - unassigned - -
:: ::
252 - unassigned - -
253 N RFC3692-style Experiment 1 (*) [RFC4727] PS (p)
254 N RFC3692-style Experiment 2 (*) [RFC4727] PS (p)
255 - unassigned - / - reserved - ? [???] (z)
(*) It is only appropriate to use these values in explicitly-configured
experiments; they MUST NOT be shipped as defaults in implementations.
See [RFC3692] for details.
Legend and additional notes:
XS ... eXternal (non-IETF) Standard
PS ... IETF Proposed Internet Standard \ classification
DS ... IETF Draft Internet Standard > based on rfcxx00.txt
FS ... IETF Full Internet Standard /
EX ... Experimental Protocol ... " " (in case of RFCs)
H ... now Historic
SYN ... Option only used in the initial SYN segment.
SYA ... Option only used in the initial SYN-ACK segment.
SYY ... Option only used in the initial SYN and SYN-ACK segments;
sending on SYN-ACK admitted only if received on SYN.
SYZ ... Option only effective in the initial (SYN and SYN-ACK) segments;
it may be sent thereafter, but then must be ignored on receipt.
SY+ ... Option used in the initial SYN segment, and in any subsequent
segment, provided it has been received in the initial SYN or
SYN-ACK segment of the connection.
EST ... Option only used after connection establishment
(non-SYN segments -- data or pure ACK).
There may be additional restrictions on use.
DTA ... Option only used in data segments.
ANY ... Option usable in any segment.
fix ... Option is invariate (MUST NOT be changed in transit),
i.e. this is an end-to-end option.
Note that ALGs in NAT/Firewall boxes might want/need to change some
of such options "in transit", but this scenario is better described
as the termination of two 'half-connections' on the ALG, anyway.
(c) One usage with c = 2, i.e. Length = 4, has been defined and registered.
(e) Publication predates Standards Track. Considered EXPERIMENTAL.
RFC index says current status is UNKNOWN, but also document obsoleted
by RFC 1323 + RFC 2018; in particular, RFC 1323 has updated option #3
and replaced options #6 and #7 by option #8; RFC 2018 has update option
#4 and #5.
(n) 1 <= n <= 4 , i.e. Length is in {10,18,26,34}.
(p) Properties and requirements vary (specific to the particular experiment).
(r) Obsoleted references are included leftmost, separated with a comma;
multiple, equally applicable references are separated by plus signs.
(s) RFC 1323 is ambiguous on the preconditions for sending TSopt;
the explanation above for SY+ is offered as a reasonable interpretation.
(t) Declared Historic by RFC 4614, but included by reference in SCPS-TP ;
also known to be implemented in some major OS's TCP/IP stack.
==> Feedback regarding implementation and deployment is solicited.
(x) It is believed that the experiment has been concluded, and that the option
is neither implemented nor deployed currently; hence it is considered as
Historic -- see RFC 4614 for the detailed rationale of the demotion.
==> Feedback regarding implementation and deployment is solicited, anyway.
(y) No public documentation available.
(Thus, for most of these options, the additional information given here is
necessarily based on vague secondary or tertiary sources.)
Option used in a (concluded) experiment, never deployed in the Internet;
considered as Historic, allocation retained for archival purpose only.
==> Feedback on all kind of additional information is solicited.
(z) Option Kind 255 does not appear in the original IANA registry file;
apparently, Option Kind 255 should be considered as -reserved-,
But neither of RFC 793, RFC 1122, RFC 2780, RFC 4614, RFC 4727
contains any explicit statement to this end.
==> Are there other specifications stating IANA policy for Option Kind 255 ?
TCP Alternate Checksum Numbers -- per [RFC1146]
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
RFC 1146 defines the TCP Alternate Checksum Option (Kind=14, see above).
This option carries the one-octet <chksum> field.
Assignment policy:
none so far -- RFC 1146 predates the formalization of IANA assignment policy,
and RFC 2780 does not contain directions for this field.
Registry:
Number Description Reference
------ ------------------------------- ---------
0 TCP Checksum [RFC1146]
1 8-bit Fletchers's algorithm [RFC1146]
2 16-bit Fletchers's algorithm [RFC1146]
3 Redundant Checksum Avoidance [KAY]
REFERENCES
----------
[RFC793] J. Postel, "Transmission Control Protocol - DARPA Internet Program
Protocol Specification", STD 7, RFC 793, September 1981.
[RFC1323] V. Jacobson, R. Braden, and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[RFC1072] V. Jacobson and R. Braden, "TCP Extensions for Long-Delay Paths",
RFC 1072, October 1988.
[RFC1644] R. Braden, "T/TCP -- TCP Extensions for Transactions - Functional
Specification", RFC 1644, July 1994.
[RFC1693] T. Connolly et al., "An Extension to TCP : Partial Order Service",
RFC 1693, November 1994.
[RFC1146] J. Zweig and C. Partridge, "TCP Alternate Checksum Options",
RFC 1146, March 1990.
[RFC2018] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective
Acknowledgement Options", RFC 2018, April 1996.
[RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature
Option", RFC 2385, August 1998.
[RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines for Values
in the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC3692] T. Narten, "Assigning Experimental and Testing Numbers Considered
Useful", BCP 82, RFC 3692, January 2004.
[RFC4413] M. West and S. McCann, "TCP/IP Field Behavior", RFC 4413, March 2006.
[RFC4614] M. Duke, R. Braden, W. Eddy, and E. Blanton, "A Roadmap for
Transmission Control Protocol (TCP) Specification Documents",
RFC 4614, September 2006.
[RFC4727] B. Fenner, "Experimental values In IPv4, IPv6, ICMPv4, ICMPv6, UDP
and TCP Headers", RFC 4727, November 2006.
[RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, "Quick-Start for TCP
and IP", RFC 4782, January 2007.
[KAY] J. Kay, and J. Pasquale, "Measurement, Analysis, and Improvement of
UDP/IP Throughput for the DECstation 5000", Proceedings of the Winter
1993 Usenix Conference, January 1993 (available for anonymous FTP in
ucsd.edu:/pub/csl/fastnet/fastnet.tar.Z). <jkay at ucsd.edu>
[SCPSTP] "Space Communications Protocol Specification (SCPS) -- Transport
Protocol". Blue Book. Issue 2. October 2006.
<http://public.ccsds.org/publications/archive/714x0b2.pdf>
PEOPLE
------
[Bellovin] Steve Bellovin, <smb at cs.columbia.edu>, March 2000. (+)
[Braden] Bob Braden, <braden at isi.edu>, March 1995. (-)
[Bridges] Monroe Bridges, <monroe at cup.hp.com>, September 1994. (*)
[Knowles] Stev Knowles, <stev at ftp.com>, March 1995. (*)
[Kay] J. Kay, <jkay at ucsd.edu>, Septermber 1994. (*)
[Scott] Keith Scott, <kscott at mitre.org>, February 1999.
[Subbu] Subbu Subramaniam, <subbu at cup.hp.com>, September 1994. (*)
[Sukonnik] Vladimir Sukonnik, <vladimir at sitaranetworks.com>, February 1999. (*)
Notes:
(*) - email address outdated / unreachable (Jan. 2007)
(+) - email address updated
(-) - redundant entry (not used)
(.... updated 2001-05-01)
(.... updated 2006-12-14)
(last updated 2007-02-15)
(updated and annotated ... 2007-11-14 ah (at) TR-Sys.de)
[]
_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
