draft-ietf-tcpm-tcp-rfc4614bis-05.txt   draft-ietf-tcpm-tcp-rfc4614bis-06.txt 
TCP Maintenance and Minor Extensions M. Duke TCP Maintenance and Minor Extensions M. Duke
(TCPM) WG F5 (TCPM) WG F5
Internet-Draft R. Braden Internet-Draft R. Braden
Obsoletes: 4614 (if approved) ISI Obsoletes: 4614 (if approved) ISI
Intended status: Informational W. Eddy Intended status: Informational W. Eddy
Expires: October 30, 2014 MTI Systems Expires: January 4, 2015 MTI Systems
E. Blanton E. Blanton
A. Zimmermann A. Zimmermann
NetApp, Inc. NetApp, Inc.
April 28, 2014 July 3, 2014
A Roadmap for Transmission Control Protocol (TCP) Specification A Roadmap for Transmission Control Protocol (TCP) Specification
Documents Documents
draft-ietf-tcpm-tcp-rfc4614bis-05 draft-ietf-tcpm-tcp-rfc4614bis-06
Abstract Abstract
This document contains a "roadmap" to the Requests for Comments (RFC) This document contains a "roadmap" to the Requests for Comments (RFC)
documents relating to the Internet's Transmission Control Protocol documents relating to the Internet's Transmission Control Protocol
(TCP). This roadmap provides a brief summary of the documents (TCP). This roadmap provides a brief summary of the documents
defining TCP and various TCP extensions that have accumulated in the defining TCP and various TCP extensions that have accumulated in the
RFC series. This serves as a guide and quick reference for both TCP RFC series. This serves as a guide and quick reference for both TCP
implementers and other parties who desire information contained in implementers and other parties who desire information contained in
the TCP-related RFCs. the TCP-related RFCs.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2014. This Internet-Draft will expire on January 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5 2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5
3. Strong Encouraged Enhancements . . . . . . . . . . . . . . . . 8 3. Strongly Encouraged Enhancements . . . . . . . . . . . . . . . 8
3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8 3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8
3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9 3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9
3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 10 3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 10
3.4. Detection and Prevention of Spurious Retransmissions . . . 12 3.4. Detection and Prevention of Spurious Retransmissions . . . 12
3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13
3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 14 3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 14
3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 15 3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 15
4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 16 4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 16
4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17 4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17
4.2. Fundamental Changes . . . . . . . . . . . . . . . . . . . 18 4.2. Fundamental Changes . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 34 skipping to change at page 3, line 34
4.7. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21
5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 22 5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 22
6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 23 6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 23
7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 26 7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Foundational Works . . . . . . . . . . . . . . . . . . . . 26 7.1. Foundational Works . . . . . . . . . . . . . . . . . . . . 26
7.2. Architectural Guidelines . . . . . . . . . . . . . . . . . 28 7.2. Architectural Guidelines . . . . . . . . . . . . . . . . . 28
7.3. Difficult Network Environments . . . . . . . . . . . . . . 29 7.3. Difficult Network Environments . . . . . . . . . . . . . . 29
7.4. Guidance for Developing, Analyzing, and Evaluating TCP . . 32 7.4. Guidance for Developing, Analyzing, and Evaluating TCP . . 32
7.5. Implementation Advice . . . . . . . . . . . . . . . . . . 33 7.5. Implementation Advice . . . . . . . . . . . . . . . . . . 33
7.6. Tools and Tutorials . . . . . . . . . . . . . . . . . . . 35 7.6. Tools and Tutorials . . . . . . . . . . . . . . . . . . . 35
7.7. Management Information Bases . . . . . . . . . . . . . . . 36 7.7. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 36
7.8. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 37 7.8. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 37
8. Undocumented TCP Features . . . . . . . . . . . . . . . . . . 38 8. Undocumented TCP Features . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
12.1. Normative References . . . . . . . . . . . . . . . . . . . 40 12.1. Normative References . . . . . . . . . . . . . . . . . . . 40
12.2. Informative References . . . . . . . . . . . . . . . . . . 50 12.2. Informative References . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
skipping to change at page 8, line 33 skipping to change at page 8, line 33
upgrades the requirement of supporting the algorithm from a SHOULD upgrades the requirement of supporting the algorithm from a SHOULD
to a MUST." [RFC6298]. RFC 6298 updates RFC 2988 by changing the to a MUST." [RFC6298]. RFC 6298 updates RFC 2988 by changing the
initial RTO from 3s to 1s initial RTO from 3s to 1s
RFC 6691 I: "TCP Options and Maximum Segment Size (MSS)" (July 2012) RFC 6691 I: "TCP Options and Maximum Segment Size (MSS)" (July 2012)
This document [RFC6691] clarifies what value to use with the TCP This document [RFC6691] clarifies what value to use with the TCP
Maximum Segment Size (MSS) option when IP and TCP options are in Maximum Segment Size (MSS) option when IP and TCP options are in
use. use.
3. Strong Encouraged Enhancements 3. Strongly Encouraged Enhancements
This section describes recommended TCP modifications that improve This section describes recommended TCP modifications that improve
performance and security. Section 3.1 represents fundamental changes performance and security. Section 3.1 represents fundamental changes
to the protocol. Section 3.2 and Section 3.3 list improvements over to the protocol. Section 3.2 and Section 3.3 list improvements over
the congestion control and loss recovery mechanisms as specified in the congestion control and loss recovery mechanisms as specified in
RFC 5681 (see Section 2). Section 3.4 describes algorithms that RFC 5681 (see Section 2). Section 3.4 describes algorithms that
allow a TCP sender to detect whether it has entered loss recovery allow a TCP sender to detect whether it has entered loss recovery
spuriously. Section 3.5 comprises Path MTU Discovery mechanisms. spuriously. Section 3.5 comprises Path MTU Discovery mechanisms.
Schemes for TCP/IP header compression are listed in Section 3.6. Schemes for TCP/IP header compression are listed in Section 3.6.
Finally, Section 3.7 deals with the problem of preventing preventing Finally, Section 3.7 deals with the problem of preventing preventing
acceptance of forged segments and flooding attacks. acceptance of forged segments and flooding attacks.
3.1. Fundamental Changes 3.1. Fundamental Changes
RFCs 2675 and XXXX represent fundamental changes to TCP by redefining RFCs 2675 and 7323 represent fundamental changes to TCP by redefining
how parts of the basic TCP header and options are interpreted. RFC how parts of the basic TCP header and options are interpreted. RFC
XXXX defines the Window Scale Option, which re-interprets the 7323 defines the Window Scale Option, which re-interprets the
advertised receive window. RFC 2675 specifies that MSS option and advertised receive window. RFC 2675 specifies that MSS option and
urgent pointer fields with a value of 65,535 are to be treated urgent pointer fields with a value of 65,535 are to be treated
specially. specially.
RFC 2675 S: "IPv6 Jumbograms" (August 1999) (Errata) RFC 2675 S: "IPv6 Jumbograms" (August 1999) (Errata)
IPv6 supports longer datagrams than were allowed in IPv4. These IPv6 supports longer datagrams than were allowed in IPv4. These
are known as jumbograms, and use with TCP has necessitated changes are known as jumbograms, and use with TCP has necessitated changes
to the handling of TCP's MSS and Urgent fields (both 16 bits). to the handling of TCP's MSS and Urgent fields (both 16 bits).
This document [RFC2675] explains those changes. Although it This document [RFC2675] explains those changes. Although it
skipping to change at page 9, line 29 skipping to change at page 9, line 29
interoperability with other TCP implementations when IPv4 or non- interoperability with other TCP implementations when IPv4 or non-
jumbogram IPv6 is used. This document states that jumbograms are jumbogram IPv6 is used. This document states that jumbograms are
to only be used when it can be guaranteed that all receiving to only be used when it can be guaranteed that all receiving
nodes, including each router in the end-to-end path, will support nodes, including each router in the end-to-end path, will support
jumbograms. If even a single node that does not support jumbograms. If even a single node that does not support
jumbograms is attached to a local network, then no host on that jumbograms is attached to a local network, then no host on that
network may use jumbograms. This explains why jumbogram use has network may use jumbograms. This explains why jumbogram use has
been rare, and why this document is considered a performance been rare, and why this document is considered a performance
optimization and not part of TCP over IPv6's basic functionality. optimization and not part of TCP over IPv6's basic functionality.
RFC XXXX S: "TCP Extensions for High Performance" (XXX 2014) RFC 7323 S: "TCP Extensions for High Performance" (July 2014)
This document [I-D.ietf-tcpm-1323bis] defines TCP extensions for This document [I-D.ietf-tcpm-1323bis] defines TCP extensions for
window scaling, timestamps, and protection against wrapped window scaling, timestamps, and protection against wrapped
sequence numbers, for efficient and safe operation over paths with sequence numbers, for efficient and safe operation over paths with
large bandwidth-delay products. These extensions are commonly large bandwidth-delay products. These extensions are commonly
found in currently used systems. The predecessor of this found in currently used systems. The predecessor of this
document, RFC 1323, was published in 1992, and is deployed in most document, RFC 1323, was published in 1992, and is deployed in most
TCP implementations. This document includes fixes and TCP implementations. This document includes fixes and
clarifications based on the gained deployment experience. One clarifications based on the gained deployment experience. One
specific issued addressed in this specification is a specific issued addressed in this specification is a
recommendation how to modify the algorithm for estimating the mean recommendation how to modify the algorithm for estimating the mean
RTT when timestamps are used. RFC 1072, RFC 1185, and RFC 1323 RTT when timestamps are used. RFC 1072, RFC 1185, and RFC 1323
are the conceptual precursors of RFC XXXX. are the conceptual precursors of RFC 7323.
3.2. Congestion Control Extensions 3.2. Congestion Control Extensions
Two of the most important aspects of TCP are its congestion control Two of the most important aspects of TCP are its congestion control
and loss recovery features. TCP treats lost packets as indicating and loss recovery features. TCP treats lost packets as indicating
congestion-related loss, and cannot distinguish between congestion- congestion-related loss, and cannot distinguish between congestion-
related loss and loss due to transmission errors. Even when ECN is related loss and loss due to transmission errors. Even when ECN is
in use, there is a rather intimate coupling between congestion in use, there is a rather intimate coupling between congestion
control and loss recovery mechanisms. There are several extensions control and loss recovery mechanisms. There are several extensions
to both features, and more often than not, a particular extension to both features, and more often than not, a particular extension
skipping to change at page 16, line 48 skipping to change at page 16, line 48
Abstract: "This document [RFC6528] specifies an algorithm for the Abstract: "This document [RFC6528] specifies an algorithm for the
generation of TCP Initial Sequence Numbers (ISNs), such that the generation of TCP Initial Sequence Numbers (ISNs), such that the
chances of an off-path attacker guessing the sequence numbers in chances of an off-path attacker guessing the sequence numbers in
use by a target connection are reduced. This document revises use by a target connection are reduced. This document revises
(and formally obsoletes) RFC 1948, and takes the ISN generation (and formally obsoletes) RFC 1948, and takes the ISN generation
algorithm originally proposed in that document to Standards Track, algorithm originally proposed in that document to Standards Track,
formally updating RFC 793 (see Section 2). formally updating RFC 793 (see Section 2).
4. Experimental Extensions 4. Experimental Extensions
The RFCs in this section are still experimental, but they may become The RFCs in this section are either experimental and may become
proposed standards in the future. At least part of the reason that proposed standards in the future or are already be proposed standard
they are still experimental is to gain more wide-scale experience (or informational), but considered as experimental due to lack of
with them before a standards track decision is made. wide deployment. 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.
At this point is worth mentioning that if the experimental RFC is a At this point is worth mentioning that if the experimental RFC is a
proposal for a new protocol capability or service, i.e., it requires proposal for a new protocol capability or service, i.e., it requires
a new TCP option code point, the implementation and experimentation a new TCP option code point, the implementation and experimentation
should follows [RFC6994] (see Section 5), which describes how the should follows [RFC6994] (see Section 5), which describes how the
experimental TCP option code points can concurrently support multiple experimental TCP option code points can concurrently support multiple
TCP extensions. TCP extensions.
By their publication as experimental RFCs, it is hoped that the By their publication as experimental RFCs, it is hoped that the
community of TCP researchers will analyze and test the contents of community of TCP researchers will analyze and test the contents of
skipping to change at page 34, line 48 skipping to change at page 34, line 48
This document [RFC6056] describes a number of simple and efficient This document [RFC6056] describes a number of simple and efficient
methods for the selection of the client port number. It reduces methods for the selection of the client port number. It reduces
the possibility of an attacker guessing the correct five-tuple the possibility of an attacker guessing the correct five-tuple
(Protocol, Source/Destination Address, Source/Destination Port). (Protocol, Source/Destination Address, Source/Destination Port).
RFC 6191 B: "Reducing the TIME-WAIT State Using TCP timestamps" RFC 6191 B: "Reducing the TIME-WAIT State Using TCP timestamps"
(April 2011) (April 2011)
This document [RFC6191] describes the usage of the TCP Timestamps This document [RFC6191] describes the usage of the TCP Timestamps
option (RFC XXXX, see Section 3.1) to perform heuristics to option (RFC 7323, see Section 3.1) to perform heuristics to
determine whether or not to allow the creation of a new determine whether or not to allow the creation of a new
incarnation of a connection that is in the TIME-WAIT state. incarnation of a connection that is in the TIME-WAIT state.
RFC 6429 I: "TCP Sender Clarification for Persist Condition" RFC 6429 I: "TCP Sender Clarification for Persist Condition"
(December 2011) (December 2011)
This document [RFC6429] clarifies the actions that a TCP can take This document [RFC6429] clarifies the actions that a TCP can take
on connections that are experiencing the Zero Window Probe (ZWP) on connections that are experiencing the Zero Window Probe (ZWP)
condition. condition.
skipping to change at page 36, line 5 skipping to change at page 36, line 5
generation and analysis tools. Although some of these tools are generation and analysis tools. Although some of these tools are
no longer readily available or widely used, for the most part they no longer readily available or widely used, for the most part they
are still relevant and usable. are still relevant and usable.
RFC 5783 I: "Congestion Control in the RFC Series" (February 2010) RFC 5783 I: "Congestion Control in the RFC Series" (February 2010)
This document [RFC5783] provides an overview of RFCs related to This document [RFC5783] provides an overview of RFCs related to
congestion control that have been published so far. The focus of congestion control that have been published so far. The focus of
the document is on end-host-based congestion control. the document is on end-host-based congestion control.
7.7. Management Information Bases 7.7. MIB Modules
The first MIB module defined for use with Simple Network Management The first MIB module defined for use with Simple Network Management
Protocol (SNMP) was a single monolithic MIB module, called MIB-I, Protocol (SNMP) was a single monolithic MIB module, called MIB-I,
defined in RFC 1156. This evolved over time to the MIB-II defined in RFC 1156. This evolved over time to the MIB-II
specification in RFC 1213, which obsoletes RFC 1156. It then became specification in RFC 1213, which obsoletes RFC 1156. It then became
apparent that having a single monolithic MIB module was not scalable, apparent that having a single monolithic MIB module was not scalable,
given the number and breadth of MIB data definitions that needed to given the number and breadth of MIB data definitions that needed to
be included. Thus, additional MIB modules were defined, and those be included. Thus, additional MIB modules were defined, and those
parts of MIB-II that needed to evolve were split off. Eventually, parts of MIB-II that needed to evolve were split off. Eventually,
the remaining parts of MIB-II were also split off, the TCP-specific the remaining parts of MIB-II were also split off, the TCP-specific
 End of changes. 14 change blocks. 
17 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/