Request for Comments: 4614 Boeing Phantom Works
Category: Informational R. Braden
USC Information Sciences Institute
W. Eddy
Verizon Federal Network Systems
E. Blanton
Purdue University Computer Science
September 2006
A Roadmap for Transmission Control Protocol (TCP)
Specification Documents
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document contains a "roadmap" to the Requests for Comments (RFC)
documents relating to the Internet’s Transmission Control Protocol
(TCP). This roadmap provides a brief summary of the documents
defining TCP and various TCP extensions that have accumulated in the
RFC series. This serves as a guide and quick reference for both TCP
implementers and other parties who desire information contained in
the TCP-related RFCs.
Table of Contents
1. Introduction ....................................................2
2. Basic Functionality .............................................4
3. Recommended Enhancements ........................................6
3.1. Congestion Control and Loss Recovery Extensions ............7
3.2. SACK-Based Loss Recovery and Congestion Control ............8
3.3. Dealing with Forged Segments ...............................9
4. Experimental Extensions ........................................10
5. Historic Extensions ............................................13
6. Support Documents ..............................................14
6.1. Foundational Works ........................................15
6.2. Difficult Network Environments ............................16
6.3. Implementation Advice .....................................19
6.4. Management Information Bases ..............................20
6.5. Tools and Tutorials .......................................22
6.6. Case Studies ..............................................22
7. Undocumented TCP Features ......................................23
8. Security Considerations ........................................24
9. Acknowledgments ................................................24
10. Informative References ........................................25
10.1. Basic Functionality ......................................25
10.2. Recommended Enhancements .................................25
10.3. Experimental Extensions ..................................26
10.4. Historic Extensions ......................................27
10.5. Support Documents ........................................28
10.6. Informative References Outside the RFC Series ............31
1. Introduction
A correct and efficient implementation of the Transmission Control
Protocol (TCP) is a critical part of the software of most Internet
hosts. As TCP has evolved over the years, many distinct documents
have become part of the accepted standard for TCP. At the same time,
a large number of more experimental modifications to TCP have also
been published in the RFC series, along with informational notes,
case studies, and other advice.
As an introduction to newcomers and an attempt to organize the
plethora of information for old hands, this document contains a
"roadmap" to the TCP-related RFCs. It provides a brief summary of
the RFC documents that define TCP. This should provide guidance to
implementers on the relevance and significance of the standards-track
extensions, informational notes, and best current practices that
relate to TCP.
This document is not an update of RFC 1122 and is not a rigorous
standard for what needs to be implemented in TCP. This document is
merely an informational roadmap that captures, organizes, and
summarizes most of the RFC documents that a TCP implementer,
experimenter, or student should be aware of. Particular comments or
broad categorizations that this document makes about individual
mechanisms and behaviors are not to be taken as definitive, nor
should the content of this document alone influence implementation
decisions.
This roadmap includes a brief description of the contents of each
TCP-related RFC. In some cases, we simply supply the abstract or a
key summary sentence from the text as a terse description. In
addition, a letter code after an RFC number indicates its category in
the RFC series (see BCP 9 [RFC2026] for explanation of these
categories):
S - Standards Track (Proposed Standard, Draft Standard, or
Standard)
E - Experimental
B - Best Current Practice
I - Informational
Note that the category of an RFC does not necessarily reflect its
current relevance. For instance, RFC 2581 is nearly universally
deployed although it is only a Proposed Standard. Similarly, some
Informational RFCs contain significant technical proposals for
changing TCP.
This roadmap is divided into four main sections. Section 2 lists the
RFCs that describe absolutely required TCP behaviors for proper
functioning and interoperability. Further RFCs that describe
strongly encouraged, but non-essential, behaviors are listed in
Section 3. Experimental extensions that are not yet standard
practices, but that potentially could be in the future, are described
in Section 4.
The reader will probably notice that these three sections are broadly
equivalent to MUST/SHOULD/MAY specifications (per RFC 2119), and
although the authors support this intuition, this document is merely
descriptive; it does not represent a binding standards-track
position. Individual implementers still need to examine the
standards documents themselves to evaluate specific requirement
levels.
A small number of older experimental extensions that have not been
widely implemented, deployed, and used are noted in Section 5. Many
other supporting documents that are relevant to the development,
implementation, and deployment of TCP are described in Section 6.
Within each section, RFCs are listed in the chronological order of
their publication dates.
A small number of fairly ubiquitous important implementation
practices that are not currently documented in the RFC series are
listed in Section 7.
2. Basic Functionality
A small number of documents compose the core specification of TCP.
These define the required basic functionalities of TCP’s header
parsing, state machine, congestion control, and retransmission
timeout computation. These base specifications must be correctly
followed for interoperability.
RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981)
This is the fundamental TCP specification document [RFC0793].
Written by Jon Postel as part of the Internet protocol suite’s
core, it describes the TCP packet format, the TCP state machine
and event processing, and TCP’s semantics for data transmission,
reliability, flow control, multiplexing, and acknowledgment.
Section 3.6 of RFC 793, describing TCP’s handling of the IP
precedence and security compartment, is mostly irrelevant today.
RFC 2873 changed the IP precedence handling, and the security
compartment portion of the API is no longer implemented or used.
In addition, RFC 793 did not describe any congestion control
mechanism. Otherwise, however, the majority of this document
still accurately describes modern TCPs. RFC 793 is the last of a
series of developmental TCP specifications, starting in the
Internet Experimental Notes (IENs) and continuing in the RFC
series.
RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
(October 1989)
This document [RFC1122] updates and clarifies RFC 793, fixing some
specification bugs and oversights. It also explains some features
such as keep-alives and Karn’s and Jacobson’s RTO estimation
algorithms [KP87][Jac88][JK92]. ICMP interactions are mentioned,
and some tips are given for efficient implementation. RFC 1122 is
an Applicability Statement, listing the various features that
MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be present in
standards-conforming TCP implementations. Unlike a purely
informational "roadmap", this Applicability Statement is a
standards document and gives formal rules for implementation.
RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification
(December 1998)
This document [RFC2460] is of relevance to TCP because it defines
how the pseudo-header for TCP’s checksum computation is derived
when 128-bit IPv6 addresses are used instead of 32-bit IPv4
addresses. Additionally, RFC 2675 describes TCP changes required
to support IPv6 jumbograms.
RFC 2581 S: "TCP Congestion Control" (April 1999)
Although RFC 793 did not contain any congestion control
mechanisms, today congestion control is a required component of
TCP implementations. This document [RFC2581] defines the current
versions of Van Jacobson’s congestion avoidance and control
mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. RFC
2001 was a conceptual precursor that was obsoleted by RFC 2581.
A number of behaviors that together constitute what the community
refers to as "Reno TCP" are described in RFC 2581. The name
"Reno" comes from the Net/2 release of the 4.3 BSD operating
system. This is generally regarded as the least common
denominator among TCP flavors currently found running on Internet
hosts. Reno TCP includes the congestion control features of slow
start, congestion avoidance, fast retransmit, and fast recovery.
RFC 1122 mandates the implementation of a congestion control
mechanism, and RFC 2581 details the currently accepted mechanism.
RFC 2581 differs slightly from the other documents listed in this
section, as it does not affect the ability of two TCP endpoints to
communicate; however, congestion control remains a critical
component of any widely deployed TCP implementation and is
required for the avoidance of congestion collapse and to ensure
fairness among competing flows.
RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000)
This document [RFC2873] removes from the TCP specification all
processing of the precedence bits of the TOS byte of the IP
header. This resolves a conflict over the use of these bits
between RFC 793 and Differentiated Services [RFC2474].
RFC 2988 S: "Computing TCP’s Retransmission Timer" (November 2000)
Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer. It expands on the
discussion in section 4.2.3.1 of RFC 1122 and upgrades the
requirement of supporting the algorithm from a SHOULD to a MUST."
[RFC2988]
3. Recommended Enhancements
This section describes recommended TCP modifications that improve
performance and security. RFCs 1323 and 3168 represent fundamental
changes to the protocol. RFC 1323, based on RFCs 1072 and 1185,
allows better utilization of high bandwidth-delay product paths by
providing some needed mechanisms for high-rate transfers. RFC 3168
describes a change to the Internet’s architecture, whereby routers
signal end-hosts of growing congestion levels and can do so before
packet losses are forced. Section 3.1 lists improvements in the
congestion control and loss recovery mechanisms specified in RFC
2581. Section 3.2 describes further refinements that make use of
selective acknowledgments. Section 3.3 deals with the problem of
preventing forged segments.
RFC 1323 S: "TCP Extensions for High Performance" (May 1992)
This document [RFC1323] defines TCP extensions for window scaling,
timestamps, and protection against wrapped sequence numbers, for
efficient and safe operation over paths with large bandwidth-delay
products. These extensions are commonly found in currently used
systems; however, they may require manual tuning and
configuration. One issue in this specification that is still
under discussion concerns a modification to the algorithm for
estimating the mean RTT when timestamps are used.
RFC 2675 S: "IPv6 Jumbograms" (August 1999)
IPv6 supports longer datagrams than were allowed in IPv4. These
are known as Jumbograms, and use with TCP has necessitated changes
to the handling of TCP’s MSS and Urgent fields (both 16 bits).
This document [RFC2675] explains those changes. Although it
describes changes to basic header semantics, these changes should
only affect the use of very large segments, such as IPv6
jumbograms, which are currently rarely used in the general
Internet. Supporting the behavior described in this document does
not affect interoperability with other TCP implementations when
IPv4 or non-jumbogram IPv6 is used. This document states that
jumbograms are to only be used when it can be guaranteed that all
receiving nodes, including each router in the end-to-end path,
will support jumbograms. If even a single node that does not
support jumbograms is attached to a local network, then no host on
that network may use jumbograms. This explains why jumbogram use
has been rare, and why this document is considered a performance
optimization and not part of TCP over IPv6’s basic functionality.
RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
to IP" (September 2001)
This document [RFC3168] defines a means for end hosts to detect
congestion before congested routers are forced to discard packets.
Although congestion notification takes place at the IP level, ECN
requires support at the transport level (e.g., in TCP) to echo the
bits and adapt the sending rate. This document updates RFC 793 to
define two previously unused flag bits in the TCP header for ECN
support. RFC 3540 provides a supplementary (experimental) means
for more secure use of ECN, and RFC 2884 provides some sample
results from using ECN.
3.1. Congestion Control and Loss Recovery Extensions
Two of the most important aspects of TCP are its congestion control
and loss recovery features. TCP traditionally treats lost packets as
indicating congestion-related loss, and cannot distinguish between
congestion-related loss and loss due to transmission errors. Even
when ECN is in use, there is a rather intimate coupling between
congestion control and loss recovery mechanisms. There are several
extensions to both features, and more often than not, a particular
extension applies to both. In this sub-section, we group
enhancements to either congestion control, loss recovery, or both,
which can be performed unilaterally; that is, without negotiating
support between endpoints. In the next sub-section, we group the
extensions that specify or rely on the SACK option, which must be
negotiated bilaterally. TCP implementations should include the
enhancements from both sub-sections so that TCP senders can perform
well without regard to the feature sets of other hosts they connect
to. For example, if SACK use is not successfully negotiated, a host
should use the NewReno behavior as a fall back.
RFC 3042 S: "Enhancing TCP’s Loss Recovery Using Limited Transmit"
(January 2001)
Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection’s
congestion window is small, or when a large number of segments are
lost in a single transmission window." [RFC3042] Tests from 2004
showed that Limited Transmit was deployed in roughly one third of
the web servers tested [MAF04].
RFC 3390 S: "Increasing TCP’s Initial Window" (October 2002)
This document [RFC3390] updates RFC 2581 to permit an initial TCP
window of three or four segments during the slow-start phase,
depending on the segment size.
RFC 3782 S: "The NewReno Modification to TCP’s Fast Recovery
Algorithm" (April 2004)
This document [RFC3782] specifies a modification to the standard
Reno fast recovery algorithm, whereby a TCP sender can use partial
acknowledgments to make inferences determining the next segment to
send in situations where SACK would be helpful but isn’t
available. Although it is only a slight modification, the NewReno
behavior can make a significant difference in performance when
multiple segments are lost from a single window of data.
3.2. SACK-Based Loss Recovery and Congestion Control
The base TCP specification in RFC 793 provided only a simple
cumulative acknowledgment mechanism. However, a selective
acknowledgment (SACK) mechanism provides performance improvement in
the presence of multiple packet losses from the same flight, more
than outweighing the modest increase in complexity. A TCP should be
expected to implement SACK; however, SACK is a negotiated option and
is only used if support is advertised by both sides of a connection.
RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996)
This document [RFC2018] defines the basic selective acknowledgment
(SACK) mechanism for TCP.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (July 2000)
This document [RFC2883] extends RFC 2018 to cover the case of
acknowledging duplicate segments.
RFC 3517 S: "A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP" (April 2003)
This document [RFC3517] describes a relatively sophisticated
algorithm that a TCP sender can use for loss recovery when SACK
reports more than one segment lost from a single flight of data.
Although support for the exchange of SACK information is widely
implemented, not all implementations use an algorithm as
sophisticated as that described in RFC 3517.
3.3. Dealing with Forged Segments
By default, TCP lacks any cryptographic structures to differentiate
legitimate segments and those spoofed from malicious hosts. Spoofing
valid segments requires correctly guessing a number of fields. The
documents in this sub-section describe ways to make that guessing
harder, or to prevent it from being able to affect a connection
negatively.
The TCPM working group is currently in progress towards fully
understanding and defining mechanisms for preventing spoofing attacks
(including both spoofed TCP segments and ICMP datagrams). Some of
the solutions being considered rely on TCP modifications, whereas
others rely on security at lower layers (like IPsec) for protection.
RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996)
This document [RFC1948] describes the TCP vulnerability that
allows an attacker to send forged TCP packets, by guessing the
initial sequence number in the three-way handshake. Simple
defenses against exploitation are then described. Some variation
is implemented in most currently used operating systems.
RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature
Option" (August 1998)
From document: "This document describes current existing practice
for securing BGP against certain simple attacks. It is understood
to have security weaknesses against concerted attacks.
This memo describes a TCP extension to enhance security for BGP.
It defines a new TCP option for carrying an MD5 digest in a TCP
segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points.
Since BGP uses TCP as its transport, using this option in the way
described in this paper significantly reduces the danger from
certain security attacks on BGP." [RFC2385]
TCP MD5 options are currently only used in very limited contexts,
primarily for defending BGP exchanges between routers. Some
deployment notes for those using TCP MD5 are found in the later
RFC 3562, "Key Management Considerations for the TCP MD5 Signature
Option" [RFC3562]. RFC 4278 deprecates the use of TCP MD5 outside
BGP [RFC4278].
4. Experimental Extensions
The RFCs in this section are still experimental, but they may become
proposed standards in the future. At least part of the reason that
they are still experimental is to gain more wide-scale experience
with them before a standards track decision is made. By their
publication as experimental RFCs, it is hoped that the community of
TCP researchers will analyze and test the contents of these RFCs.
Although experimentation is encouraged, there is not yet formal
consensus that these are fully logical and safe behaviors. Wide-
scale deployment of implementations that use these features should be
well thought-out in terms of consequences.
RFC 2140 I: "TCP Control Block Interdependence" (April 1997)
This document [RFC2140] suggests how TCP connections between the
same endpoints might share information, such as their congestion
control state. To some degree, this is done in practice by a few
operating systems; for example, Linux currently has a destination
cache. Although this RFC is technically informational, the
concepts it describes are in experimental use, so we include it in
this section.
A related proposal, the Congestion Manager, is specified in RFC
3124 [RFC3124]. The idea behind the Congestion Manager, moving
congestion control outside of individual TCP connections,
represents a modification to the core of TCP, which supports
sharing information among TCP connections as well. Although a
Proposed Standard, some pieces of the Congestion Manager support
architecture have not been specified yet, and it has not achieved
use or implementation beyond experimental stacks, so it is not
listed among the standard TCP enhancements in this roadmap.
RFC 2861 E: "TCP Congestion Window Validation" (June 2000)
This document [RFC2861] suggests reducing the congestion window
over time when no packets are flowing. This behavior is more
aggressive than that specified in RFC 2581, which says that a TCP
sender SHOULD set its congestion window to the initial window
after an idle period of an RTO or greater.
RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
(ABC)" (February 2003)
This document [RFC3465] suggests that congestion control use the
number of bytes acknowledged instead of the number of