RFC 7805

Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status

📅 published April 2016, from ietf

Okay bestie, this is RFC 7805, and it's giving housekeeping for the old TCP docs 🧹💅. It came from the IETF, written by A. Zimmermann, W. Eddy (MTI Systems), and L. Eggert (NetApp), and it was published in April 2016 🗓️. It's Informational, not Standards Track, with ISSN 2070-1721. It obsoletes 675 721 761 813 816 879 896 1078 6013 and updates RFC 7414 🎀.

Abstract 💖

This doc reclassifies several TCP extensions and TCP-related documents that are superseded, never really caught on, or are no longer recommended for use. They're moving to "Historic" status 🦋. The affected docs are RFCs 675, 721, 761, 813, 816, 879, 896, 1078, and 6013. It also moves RFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status 🌸.

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes 🧠.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7805 🔗.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc 📖. Any Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚖️.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Status Changes  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Moving to "Historic" Status . . . . . . . . . . . . . .   3
     2.2.  Moving to "Informational" Status  . . . . . . . . . . . .   4
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction ✨

TCP has been around forever 🕰️, and over the years a whole pile of RFCs built up describing parts of the protocol, its implementations, and its extensions. Some got superseded, some aren't recommended anymore, and some just never really took off 💀. A glow-up was honestly overdue.

Sections 6 and 7.1 of the TCP roadmap document [RFC7414] already reclassified a bunch of TCP extensions as "Historic" and explained why 📚. The roadmap didn't tell the RFC Editor to actually change those statuses in the RFC database, though 😤. That's the job this document takes on 🫶.

This doc also reclassifies every other document in the TCP roadmap that's currently marked "Unknown" as either "Historic" or "Informational" 🎀.

2. Status Changes 🦋

The next two sections are mini justifications for why each TCP extension or TCP-related doc is getting moved to "Historic" or "Informational" 🧐. The letter after each RFC number tells you its original status, and you can check BCP 9 [RFC2026] for the full breakdown of those categories:

  • S - Standards Track (Proposed Standard, Draft Standard, or Internet Standard)
  • E - Experimental
  • I - Informational
  • H - Historic
  • B - Best Current Practice
  • U - Unknown (not formally defined)

For the actual content of these docs, go read the RFC itself, or peek at the TCP roadmap document [RFC7414] for a quick summary 📖.

2.1. Moving to "Historic" Status

This document moves the following RFCs to "Historic" [RFC2026]:

  • [RFC675] U, "Specification of Internet Transmission Control Program": replaced by the final TCP specification [RFC793] 💀
  • [RFC721] U, "Out-of-Band Control Signals in a Host-to-Host Protocol": was a proposal that never made it into the final TCP specification [RFC793] 🙈
  • [RFC761] U, "DoD Standard Transmission Control Protocol": replaced by the final TCP specification [RFC793] 💅
  • [RFC813] U, "Window and Acknowledgement Strategy in TCP": got incorporated into [RFC1122] ✨
  • [RFC816] U, "Fault Isolation and Recovery": got incorporated into [RFC1122] and [RFC5461] 🫶
  • [RFC879] U, "The TCP Maximum Segment Size and Related Topics": got incorporated into [RFC1122] and [RFC6691] 🌸
  • [RFC896] U, "Congestion Control in IP/TCP Internetworks": got incorporated into [RFC1122] and [RFC6633] 🌈
  • [RFC1078] U, "TCP Port Service Multiplexer (TCPMUX)" should be deprecated, because:
    • It modifies the TCP connection establishment semantics by also completing the three-way handshake when a service is not available.
    • It requires all new connections to be received on a single port, which limits the number of connections between two machines.
    • It complicates firewall implementation and management because all services share the same port number.
    • There are very limited deployments, and these are not used in an Internet context. (The only reported use is for SGI's Data Migration Facility in private networks.) 🙃
  • [RFC6013] E, "TCP Cookie Transactions (TCPCT)" should be deprecated (although only published in 2011) because:
    • It uses the experimental TCP option codepoints, which prohibit a large-scale deployment.
    • [RFC7413] and [TCP-EDO] are alternatives that have more "rough consensus and running code" behind them.
    • There are no known wide-scale deployments.

2.2. Moving to "Informational" Status

This document moves the following RFCs to "Informational" [RFC2026]:

  • [RFC700] U, "A Protocol Experiment": a field report about deploying a very early version of TCP 🧪
  • [RFC794] U, "Pre-emption": recommends that operating systems manage their limited resources, which may include TCP connection state 🖥️
  • [RFC814] U, "Name, Addresses, Ports, and Routes": gives guidance on designing tables and algorithms to track the various identifiers inside a TCP/IP implementation 🗺️
  • [RFC817] U, "Modularity and Efficiency in Protocol Implementation": contains general implementation suggestions 🧩
  • [RFC872] U, "TCP-on-a-LAN": concludes that the fear of using TCP on a local network is unfounded 😌
  • [RFC889] U, "Internet Delay Experiments": describes experiments with the TCP retransmission timeout calculation ⏱️
  • [RFC964] U, "Some Problems with the Specification of the Military Standard Transmission Control Protocol": points out several specification bugs in the US Military's MIL-STD-1778 document, which was meant as a successor to [RFC793] 🎖️
  • [RFC1071] U, "Computing the Internet Checksum": lists a bunch of implementation techniques for computing the Internet checksum efficiently 🧮

3. Security Considerations 🔒

This doc introduces no new security considerations 🙅‍♀️. Every RFC listed here makes its own attempt to address the security considerations of the specification it contains, so go read those seriously before you do anything with them.

4.2. Informative References ✨

Okay bestie, here's the extra reading shelf 📚💅 These are the docs the RFC points to for background, and they're all TCP-flavoured 🦋

[RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
           RFC 793, DOI 10.17487/RFC0793, September 1981,
           <http://www.rfc-editor.org/info/rfc793>.

[RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
           Communication Layers", STD 3, RFC 1122,
           DOI 10.17487/RFC1122, October 1989,
           <http://www.rfc-editor.org/info/rfc1122>.

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
           <http://www.rfc-editor.org/info/rfc2026>.

[RFC5461]  Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
           DOI 10.17487/RFC5461, February 2009,
           <http://www.rfc-editor.org/info/rfc5461>.

[RFC6633]  Gont, F., "Deprecation of ICMP Source Quench Messages",
           RFC 6633, DOI 10.17487/RFC6633, May 2012,
           <http://www.rfc-editor.org/info/rfc6633>.

[RFC6691]  Borman, D., "TCP Options and Maximum Segment Size (MSS)",
           RFC 6691, DOI 10.17487/RFC6691, July 2012,
           <http://www.rfc-editor.org/info/rfc6691>.

[RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
           Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
           <http://www.rfc-editor.org/info/rfc7413>.

[RFC7414]  Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
           Zimmermann, "A Roadmap for Transmission Control Protocol
           (TCP) Specification Documents", RFC 7414,
           DOI 10.17487/RFC7414, February 2015,
           <http://www.rfc-editor.org/info/rfc7414>.

[TCP-EDO]  Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
           Work in Progress, draft-ietf-tcpm-tcp-edo-04, November
           2015.

Acknowledgments 🫶

Huge thanks to John Leslie, Pasi Sarolahti, Richard Scheffenegger, Martin Stiemerling, Joe Touch, Valdis Kletnieks, and Greg Skinner for their contributions 💖

Lars Eggert got funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866 (SSICLOPS). Just to be clear, this document reflects only the authors' views, and the European Commission is not responsible for any use that may be made of the information it contains. 🇪🇺

Authors' Addresses 🧚

Here are the brilliant minds behind this one 👑

Alexander Zimmermann

Email: alexander@zimmermann.eu.com


Wesley M. Eddy
MTI Systems
Suite 170, 18013 Cleveland Parkway
Cleveland, OH  44135
United States

Phone: +1-216-433-6682
Email: wes@mti-systems.com


Lars Eggert
NetApp
Sonnenallee 1
Kirchheim  85551
Germany

Phone: +49 151 12055791
Email: lars@netapp.com

That's the whole RFC, bestie! 🌈✨

📦 where this page comes from