draft-ietf-tcpm-tcp-uto-05.txt   draft-ietf-tcpm-tcp-uto-06.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) Nokia Extensions (tcpm) Nokia
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH Intended status: Standards Track UTN/FRH
Expires: September 6, 2007 March 5, 2007 Expires: December 13, 2007 June 11, 2007
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-05 draft-ietf-tcpm-tcp-uto-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007. This Internet-Draft will expire on December 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The TCP user timeout controls how long transmitted data may remain The TCP user timeout controls how long transmitted data may remain
unacknowledged before a connection is forcefully closed. It is a unacknowledged before a connection is forcefully closed. It is a
local, per-connection parameter. This document specifies a new TCP local, per-connection parameter. This document specifies a new TCP
option - the TCP User Timeout Option - that allows one end of a TCP option - the TCP User Timeout Option - that allows one end of a TCP
connection to advertise its current user timeout value. This connection to advertise its current user timeout value. This
information allows the other end to adapt its user timeout information provides advice to the other end to adapt its user
accordingly. Increasing the user timeouts on both ends of a TCP timeout accordingly. Increasing the user timeouts on both ends of a
connection allows it to survive extended periods without end-to-end TCP connection allows it to survive extended periods without end-to-
connectivity. Decreasing the user timeouts allows busy servers to end connectivity. Decreasing the user timeouts allows busy servers
explicitly notify their clients that they will maintain the to explicitly notify their clients that they will maintain the
connection state only for a short time without connectivity. connection state only for a short time without connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Document Revision History . . . . . . . . . . . . . . 13 Appendix A. Document Revision History . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification [RFC0793] The Transmission Control Protocol (TCP) specification [RFC0793]
defines a local, per-connection "user timeout" parameter that defines a local, per-connection "user timeout" parameter that
specifies the maximum amount of time that transmitted data may remain specifies the maximum amount of time that transmitted data may remain
unacknowledged before TCP will forcefully close the corresponding unacknowledged before TCP will forcefully close the corresponding
connection. Applications can set and change this parameter with OPEN connection. Applications can set and change this parameter with OPEN
and SEND calls. If an end-to-end connectivity disruption lasts and SEND calls. If an end-to-end connectivity disruption lasts
skipping to change at page 4, line 12 skipping to change at page 4, line 12
based on past mobility patterns and thus benefit from using longer based on past mobility patterns and thus benefit from using longer
user timeouts. In other scenarios, the time and duration of a user timeouts. In other scenarios, the time and duration of a
connectivity disruption may even be predictable. For example, an connectivity disruption may even be predictable. For example, an
orbiting node on a non-geostationary satellite might experience orbiting node on a non-geostationary satellite might experience
connectivity disruptions due to line-of-sight blocking by other connectivity disruptions due to line-of-sight blocking by other
planetary bodies. The timing of these events may be computable from planetary bodies. The timing of these events may be computable from
orbital mechanics. orbital mechanics.
This document specifies a new TCP option - the TCP User Timeout This document specifies a new TCP option - the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its Option - that allows one end of a TCP connection to advertise its
current user timeout value. This information allows the other end to current user timeout value. This information provides advice to the
adapt its user timeout accordingly. Increasing the user timeouts on other end of the connection to adapt its user timeout accordingly.
both ends of a TCP connection allows it to survive extended periods That is, TCP remains free to disregard the advice provided by the UTO
without end-to-end connectivity. Decreasing the user timeouts allows option if local policies suggest it to be appropriate.
busy servers to explicitly notify their clients that they will
maintain the connection state only for a short time without Increasing the user timeouts on both ends of a TCP connection allows
connectivity. it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify
their clients that they will maintain the connection state only for a
short time without connectivity.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
Use of the TCP User Timeout Option can be enabled either on a per- Use of the TCP User Timeout Option can be enabled either on a per-
application basis, e.g., through a socket option, or controlled by a application basis, e.g., through a socket option, or controlled by a
system-wide setting. TCP maintains three per-connection state system-wide setting. TCP maintains four per-connection state
variables to control the operation of UTO options, two of which variables to control the operation of the UTO option, three of which
(ENABLED and CHANGEABLE) are new: (LOCAL_UTO, ENABLED and CHANGEABLE) are new:
ENABLED (Boolean) USER_TIMEOUT
Flag that controls whether UTO options are enabled for a TCP's USER TIMEOUT parameter, as specified in [RFC0793].
connection. Defaults to false.
LOCAL_UTO LOCAL_UTO
Local user timeout in effect for this connection. This is either UTO option advertised to the remote TCP peer. This is an
the system-wide default or an application-specified value. application-specified value, and may be specified on a system-wide
Defaults to the system-wide default. basis. If unspecified, it default to the default system-wide USER
TIMEOUT.
ENABLED (Boolean)
Flag that controls whether the UTO option is enabled for a
connection. Defaults to false.
CHANGEABLE (Boolean) CHANGEABLE (Boolean)
Flag that controls whether the local user timeout may be changed Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT
based on UTO options received from the other end. Defaults to parameter) may be changed based on an UTO option received from the
true and becomes false when an application explicitly sets other end. Defaults to true and becomes false when an application
LOCAL_UTO. explicitly sets USER_TIMEOUT.
Note that an exchange of UTO options between both ends of a Note that an exchange of UTO options between both ends of a
connection is not a binding negotiation. Transmission of a UTO connection is not a binding negotiation. Transmission of a UTO
option is a suggestion that the other end consider adapting its user option is a suggestion that the other end consider adapting its user
timeout. This adaptation only happens if the the other end has timeout. This adaptation only happens if the the other end has
explicitly enabled it (CHANGEABLE is true). explicitly allowed it (both ENABLED and CHANGEABLE are true).
Before opening a connection, an application that wishes to use UTO Before opening a connection, an application that wishes to use the
options SHOULD enable their use by setting ENABLED to true. It MAY UTO option SHOULD enable its use by setting ENABLED to true. It MAY
pick an appropriate local UTO by setting LOCAL_UTO, which is pick an appropriate local UTO by setting LOCAL_UTO, which is
otherwise set to the system default. Finally, the application should otherwise set to the default USER TIMEOUT value. Finally, the
determine whether it will allow the local UTO to change based on application should determine whether it will allow the local USER
received UTO options from the other end. The default is to allow TIMEOUT to change based on received UTO options from the other end.
this for connections that do not have a specific user timeout The default is to allow this for connections that do not have a
concerns, i.e., connections that operate with the default LOCAL_UTO. specific user timeout concerns. If an application explicitly sets
If an application explicitly sets LOCAL_UTO, CHANGEABLE MUST become the USER TIMEOUT, CHANGEABLE MUST become false, to prevent UTO
false, to prevent UTO options from the other end to override local options from the other end to override local application requests.
application requests. Alternatively, applications MAY set or clear Alternatively, applications MAY set or clear CHANGEABLE directly.
CHANGEABLE directly.
Performing these steps before an active or passive open causes UTO Performing these steps before an active or passive open causes UTO
options to be exchanged in the SYN and SYN-ACK packets and is a options to be exchanged in the SYN and SYN-ACK packets and is a
reliable way to initially exchange and potentially adapt to UTO reliable way to initially exchange and potentially adapt to UTO
values. Systems MAY provide system-wide default settings for the values. Systems MAY provide system-wide default settings for the
ENABLED, LOCAL_UTO and CHANGEABLE connection parameters when ENABLED, LOCAL_UTO and CHANGEABLE connection parameters.
applications do not initialize them themselves.
In addition to exchanging UTO options in the SYN segments, a In addition to exchanging UTO options in the SYN segments, a
connection that has enabled UTO options SHOULD include a UTO option connection that has enabled UTO options SHOULD include a UTO option
in the first packet that does not have the SYN flag set. This helps in the first packet that does not have the SYN flag set. This helps
to minimize the amount of state information TCP must keep for to minimize the amount of state information TCP must keep for
connections in non-synchronized states, and is particularly useful connections in non-synchronized states, and is particularly useful
when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are
implemented, allowing a newly-established TCP connection to benefit implemented, allowing a newly-established TCP connection to benefit
from the information advertised by the UTO option, even if the UTO from the information advertised by the UTO option, even if the UTO
contained in the initial SYN segment was not recorded. contained in the initial SYN segment was not recorded.
A host that supports UTO options SHOULD include it in the next A host that supports the UTO option SHOULD include one in the next
possible outgoing segment whenever it starts using a new user timeout possible outgoing segment whenever it starts using a new user timeout
for the connection. This allows the other end to adapt its local for the connection. This allows the other end to adapt its local
user timeout for the connection accordingly. user timeout for the connection accordingly. A TCP implementation
that does not support the UTO option MUST silently ignore it
A TCP implementation that does not support UTO options MUST silently [RFC1122], thus ensuring interoperability.
ignore them [RFC1122], thus ensuring interoperability.
Hosts MUST impose upper and lower limits on the user timeouts they Hosts MUST impose upper and lower limits on the user timeouts they
use for a connection. Section 3.1 discusses user timeout limits and use for a connection. Section 3.1 discusses user timeout limits and
discusses potentially problematic effects of user timeout settings. discusses potentially problematic effects of some user timeout
settings.
Finally, it is worth noting that TCP's option space is limited to 40
bytes. As a result, if other TCP options are in use, they may
already consume all the available TCP option space, thus preventing
the use of the UTO option specified in this document. Therefore, TCP
option space issues should be considered before enabling the UTO
option.
3.1. Changing the Local User Timeout 3.1. Changing the Local User Timeout
When a host receives a TCP User Timeout Option, it must decide When a host receives a TCP User Timeout Option, it must decide
whether to change the local user timeout of the corresponding whether to change the local user timeout of the corresponding
connection. If the CHANGEABLE flag is false, LOCAL_UTO MUST NOT be connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT
changed, regardless of the received UTO option. Without this be changed, regardless of the received UTO option. Without this
restriction, UTO would modify TCP semantics, because application- restriction, the UTO option would modify TCP semantics, because an
requested UTOs could be overridden by peer requests. In this case, application-requested USER TIMEOUT could be overridden by peer
they SHOULD, however, notify the application about the user timeout requests. In this case, they SHOULD, however, notify the application
value received from the other end. about the user timeout value received from the other end.
In general, unless the application on the local host has requested a In general, unless the application on the local host has requested a
specific LOCAL_UTO for the connection, CHANGEABLE will be true and specific USER TIMEOUT for the connection, CHANGEABLE will be true and
hosts SHOULD adjust the local user timeout in response to receiving a hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in
UTO option, as described in the remainder of this section. response to receiving a UTO option, as described in the remainder of
this section.
The UTO option specifies the user timeout in in seconds or minutes, The UTO option specifies the user timeout in seconds or minutes,
rather than in number of retransmissions or round-trip times (RTTs). rather than in number of retransmissions or round-trip times (RTTs).
Thus, the UTO option allows hosts to exchange user timeout values Thus, the UTO option allows hosts to exchange user timeout values
from 1 second to over 9 hours at a granularity of seconds, and from 1 from 1 second to over 9 hours at a granularity of seconds, and from 1
minute to over 22 days at a granularity of minutes. minute to over 22 days at a granularity of minutes.
Very short user timeout values can affect TCP transmissions over Very short USER TIMEOUT values can affect TCP transmissions over
high-delay paths. If the user timeout occurs before an high-delay paths. If the user timeout occurs before an
acknowledgment for an outstanding segment arrives, possibly due to acknowledgment for an outstanding segment arrives, possibly due to
packet loss, the connection closes. Many TCP implementations default packet loss, the connection closes. Many TCP implementations default
to user timeout values of a few minutes. Although the UTO option to USER TIMEOUT values of a few minutes. Although the UTO option
allows suggestion of short timeouts, applications advertising them allows suggestion of short timeouts, applications advertising them
should consider these effects. should consider these effects.
Long user timeout values allow hosts to tolerate extended periods Long USER TIMEOUT values allow hosts to tolerate extended periods
without end-to-end connectivity. However, they also require hosts to without end-to-end connectivity. However, they also require hosts to
maintain the TCP state information associated with connections for maintain the TCP state information associated with connections for
long periods of time. Section 5 discusses the security implications long periods of time. Section 5 discusses the security implications
of long timeout values. of long timeout values.
To protect against these effects, implementations MUST impose limits To protect against these effects, implementations MUST impose limits
on the user timeout values they accept and use. The remainder of on the user timeout values they accept and use. The remainder of
this section describes a RECOMMENDED scheme to limit user timeouts this section describes a RECOMMENDED scheme to limit TCP's USER
based on upper and lower limits. TIMEOUT based on upper and lower limits.
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
SHOULD compute LOCAL_UTO for a connection according to this formula: SHOULD compute the local USER TIMEOUT for a connection according to
this formula:
LOCAL_UTO = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
Each field is to be interpreted as follows: Each field is to be interpreted as follows:
USER_TIMEOUT
USER TIMEOUT value to be adopted by the local TCP for this
connection.
U_LIMIT U_LIMIT
Current upper limit imposed on the user timeout of a connection by Current upper limit imposed on the user timeout of a connection by
the local host. the local host.
L_LIMIT LOCAL_UTO
Current lower limit imposed on the user timeout of a connection by User timeout advertised to the remote TCP peer in a TCP User
the local host. Timeout Option.
REMOTE_UTO REMOTE_UTO
Last "user timeout" value received from the other end in a TCP Last "user timeout" value received from the other end in a TCP
User Timeout Option. User Timeout Option.
L_LIMIT
Current lower limit imposed on the user timeout of a connection by
the local host.
This means that, provided they are within the upper and lower limits, This means that, provided they are within the upper and lower limits,
the maximum of current LOCAL_UTO and the last user timeout value the maximum of the two advertised values will be adopted for the user
received from the other end will become the new LOCAL_UTO for the timeout of the connection. The rationale is that choosing the
connection. The rationale is that choosing the maximum of the two maximum of the two values will let the connection survive longer
values will let the connection survive longer periods without end-to- periods without end-to-end connectivity. If the end that announced
end connectivity. If the end that announced the lower of the two the lower of the two user timeout values did so in order to reduce
user timeout values did so in order to reduce the amount of TCP state the amount of TCP state information that must be kept on the host, it
information that must be kept on the host, it can, nevertheless, can, nevertheless, close or abort the connection whenever it wants.
close or abort the connection whenever it wants. [anchor3]
It must be noted that the two endpoints of the connection will not It must be noted that the two endpoints of the connection will not
necessarily adopt the same user timeout. necessarily adopt the same user timeout.
Enforcing a lower limit (L_LIMIT) prevents connections from closing Enforcing a lower limit (L_LIMIT) prevents connections from closing
due to transient network conditions, including temporary congestion, due to transient network conditions, including temporary congestion,
mobility hand-offs and routing instabilities. mobility hand-offs and routing instabilities.
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
attacks. Section 5 discusses the details of these attacks. attacks. Section 5 discusses the details of these attacks.
Note that these limits MAY be specified as system-wide constants or Note that these limits MAY be specified as system-wide constants or
at other granularities, such as on per-host, per-user or even per- at other granularities, such as on per-host, per-user, per-outgoing-
connection basis. Furthermore, these limits need not be static. For interface or even per-connection basis. Furthermore, these limits
example, they MAY be a function of system resource utilization or need not be static. For example, they MAY be a function of system
attack status and could be dynamically adapted. resource utilization or attack status and could be dynamically
adapted.
The Host Requirements RFC [RFC1122] does not impose any limits on the The Host Requirements RFC [RFC1122] does not impose any limits on the
length of the user timeout. However, a time interval of at least 100 length of the user timeout. However, a time interval of at least 100
seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT)
SHOULD be set to at least 100 seconds when following the RECOMMENDED SHOULD be set to at least 100 seconds when following the RECOMMENDED
scheme described in this section. Adopting a user timeout smaller scheme described in this section. Adopting a user timeout smaller
than the current retransmission timeout (RTO) for the connection than the current retransmission timeout (RTO) for the connection
would likely cause the connection to be aborted unnecessarily. would likely cause the connection to be aborted unnecessarily.
Therefore, the lower limit (L_LIMIT) MUST be larger than the current Therefore, the lower limit (L_LIMIT) MUST be larger than the current
retransmission timeout (RTO) for the connection. It is worth noting retransmission timeout (RTO) for the connection. It is worth noting
skipping to change at page 8, line 22 skipping to change at page 8, line 43
When a segment that carries a UTO option is lost, the other end will When a segment that carries a UTO option is lost, the other end will
simply not have the opportunity to update its local UTO. simply not have the opportunity to update its local UTO.
Implementations MAY implement local mechanisms to improve delivery Implementations MAY implement local mechanisms to improve delivery
reliability, such as retransmitting a UTO option when they retransmit reliability, such as retransmitting a UTO option when they retransmit
a segment that originally carried it, or "attaching" the option to a a segment that originally carried it, or "attaching" the option to a
byte in the stream and retransmitting the option whenever that byte byte in the stream and retransmitting the option whenever that byte
or its ACK are retransmitted. or its ACK are retransmitted.
It is important to note that although these mechanisms can improve It is important to note that although these mechanisms can improve
transmission reliability for UTO options, they do not guarantee transmission reliability for the UTO option, they do not guarantee
delivery (a three-way handshake would be required for this). delivery (a three-way handshake would be required for this).
Consequently, implementations MUST NOT assume that UTO options are Consequently, implementations MUST NOT assume that UTO options are
transmitted reliably. transmitted reliably.
3.3. Option Format 3.3. Option Format
Sending a TCP User Timeout Option informs the other end of the Sending a TCP User Timeout Option informs the other end of the
current local user timeout for the connection and suggests that the current local user timeout for the connection and suggests that the
other end adapt its user timeout accordingly. The user timeout value other end adapt its user timeout accordingly. The user timeout value
included in a UTO option contains the local user timeout (LOCAL_UTO) included in a UTO option contains the LOCAL_UTO value, that is
used during the synchronized states of a connection (ESTABLISHED, expected to be adopted for the TCP's USER TIMEOUT parameter during
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1,
Connections in other states MUST use the default timeout values FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other
defined in [RFC0793] and [RFC1122]. states MUST use the default timeout values defined in [RFC0793] and
[RFC1122].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = X | Length = 4 |G| User Timeout | | Kind = X | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.) (One tick mark represents one bit.)
Figure 1: Format of the TCP User Timeout Option Figure 1: Format of the TCP User Timeout Option
skipping to change at page 9, line 20 skipping to change at page 9, line 39
Length of the TCP option in octets [RFC0793]; its value MUST be 4. Length of the TCP option in octets [RFC0793]; its value MUST be 4.
Granularity (1 bit) Granularity (1 bit)
Granularity bit, indicating the granularity of the "User Timeout" Granularity bit, indicating the granularity of the "User Timeout"
field. When set (G = 1), the time interval in the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout"
field MUST be interpreted as minutes. Otherwise (G = 0), the time field MUST be interpreted as minutes. Otherwise (G = 0), the time
interval in the "User Timeout" field MUST be interpreted as interval in the "User Timeout" field MUST be interpreted as
seconds. seconds.
User Timeout (15 bits) User Timeout (15 bits)
Specifies the user timeout (LOCAL_UTO) used for this connection. Specifies the user timeout suggestion for this connection.. It
It MUST be interpreted as a 15-bit unsigned integer. The MUST be interpreted as a 15-bit unsigned integer. The granularity
granularity of the timeout (minutes or seconds) depends on the "G" of the timeout (minutes or seconds) depends on the "G" field.
field.
3.4. Reserved Option Values 3.4. Reserved Option Values
An empty TCP User Timeout Option, i.e., one with a "User Timeout" An TCP User Timeout Option with a "User Timeout" field of zero and a
field of zero and a "Granularity" bit of either minutes (1) or "Granularity" bit of either minutes (1) or seconds (0) is reserved
seconds (0), is reserved for future use. TCP implementations MUST for future use. TCP implementations MUST NOT send it and MUST ignore
NOT send it and MUST ignore it upon reception. it upon reception.
4. Interoperability Issues 4. Interoperability Issues
This section discusses interoperability issues related to introducing This section discusses interoperability issues related to introducing
the TCP User Timeout Option. the TCP User Timeout Option.
4.1. Middleboxes 4.1. Middleboxes
A TCP implementation that does not support the TCP User Timeout A TCP implementation that does not support the TCP User Timeout
Option MUST silently ignore it [RFC1122], thus ensuring Option MUST silently ignore it [RFC1122], thus ensuring
skipping to change at page 10, line 5 skipping to change at page 10, line 25
transport protocols, Medina et al. have shown that the vast majority transport protocols, Medina et al. have shown that the vast majority
of modern TCP stacks correctly handle unknown TCP options [MEDINA]. of modern TCP stacks correctly handle unknown TCP options [MEDINA].
In this study, 3% of connections failed when an unknown TCP option In this study, 3% of connections failed when an unknown TCP option
appeared in the middle of a connection. Because the number of appeared in the middle of a connection. Because the number of
failures caused by unknown options is small and they are a result of failures caused by unknown options is small and they are a result of
incorrectly implemented TCP stacks that violate existing requirements incorrectly implemented TCP stacks that violate existing requirements
to ignore unknown options, they do not warrant special measures. to ignore unknown options, they do not warrant special measures.
Thus, this document does not define a mechanism to negotiate support Thus, this document does not define a mechanism to negotiate support
of the TCP User Timeout Option during the three-way handshake. of the TCP User Timeout Option during the three-way handshake.
Stateful firewalls usually reset connections after a period of Stateful firewalls usually time out connection state after a period
inactivity. If such a firewall exists along the path, it may close of inactivity. If such a firewall exists along the path, it may
or abort connections regardless of the use of the TCP User Timeout close or abort connections regardless of the use of the TCP User
Option. In the future, such firewalls may learn to parse the TCP Timeout Option. In the future, such firewalls may learn to parse the
User Timeout Option and modify their behavior - or the option TCP User Timeout Option and adapt connection state management
contents - accordingly. accordingly.
4.2. TCP Keep-Alives 4.2. TCP Keep-Alives
Some TCP implementations, such as those in BSD systems, use a Some TCP implementations, such as those in BSD systems, use a
different abort policy for TCP keep-alives than for user data. Thus, different abort policy for TCP keep-alives than for user data. Thus,
the TCP keep-alive mechanism might abort a connection that would the TCP keep-alive mechanism might abort a connection that would
otherwise have survived the transient period without connectivity. otherwise have survived the transient period without connectivity.
Therefore, if a connection enables keep-alives that is also using the Therefore, if a connection enables keep-alives that is also using the
TCP User Timeout Option, then the keep-alive timer MUST be set to a TCP User Timeout Option, then the keep-alive timer MUST be set to a
value larger than that of the adopted USER TIMEOUT. value larger than that of the adopted USER TIMEOUT.
skipping to change at page 12, line 4 skipping to change at page 12, line 21
This document does not define any new namespaces. It uses an 8-bit This document does not define any new namespaces. It uses an 8-bit
TCP option number maintained by IANA at TCP option number maintained by IANA at
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
7. Acknowledgments 7. Acknowledgments
The following people have improved this document through thoughtful The following people have improved this document through thoughtful
suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted
Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,
Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid
Pentikousis, Juergen Quittek, Joe Touch, Stefan Schmid, Simon Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe
Schuetz, Tim Shepard and Martin Stiemerling. Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and Martin
Stiemerling.
Lars Eggert is partly funded by Ambient Networks, a research project Lars Eggert has been partly funded by Ambient Networks, a research
supported by the European Commission under its Sixth Framework project supported by the European Commission under its Sixth
Program. The views and conclusions contained herein are those of the Framework Program.
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the Ambient Networks project or the European Commission.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
skipping to change at page 12, line 40 skipping to change at page 13, line 13
October 1998. October 1998.
8.2. Informative References 8.2. Informative References
[I-D.eddy-tcp-mobility] [I-D.eddy-tcp-mobility]
Eddy, W., "Mobility Support For TCP", Eddy, W., "Mobility Support For TCP",
draft-eddy-tcp-mobility-00 (work in progress), April 2004. draft-eddy-tcp-mobility-00 (work in progress), April 2004.
[I-D.ietf-tcpm-syn-flood] [I-D.ietf-tcpm-syn-flood]
Eddy, W., "TCP SYN Flooding Attacks and Common Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", draft-ietf-tcpm-syn-flood-01 (work in Mitigations", draft-ietf-tcpm-syn-flood-05 (work in
progress), December 2006. progress), May 2007.
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes", Interactions Between Transport Protocols and Middleboxes",
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
Measurement , October 2004. Measurement , October 2004.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
skipping to change at page 13, line 21 skipping to change at page 13, line 40
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[SOLARIS-MANUAL] [SOLARIS-MANUAL]
Sun Microsystems, "Solaris Tunable Parameters Reference Sun Microsystems, "Solaris Tunable Parameters Reference
Manual", Part No. 806-7009-10, 2002. Manual", Part No. 806-7009-10, 2002.
Editorial Comments
[anchor3] Lars: With the new CHANGEABLE flag, which prevents
changing of LOCAL_UTO when an application has indicated
that it cares about the value, I think the formula can
become LOCAL_UTO = min(U_LIMIT, max(REMOTE_UTO, L_LIMIT)),
i.e., we adopt whatever the other end suggests, given that
it is with in acceptable limits. I didn't want to make
this change without discussing it first, however.
Appendix A. Document Revision History Appendix A. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| 06 | Includes a note on the limited space for TCP options |
| | and miscelaneous editorial changes(suggested by |
| | Anantha Ramaiah). Includes possible enforcement of |
| | per-outgoing-interface limits for the UTO, and |
| | miscellaneous editorial changes (suggested by Alfred |
| | Hoenes). Includes relevant changes to reflect WG |
| | consesus how the local user timeout should be selected |
| | (i.e., record both the current user timeout, and the |
| | advertised UTO). |
| 05 | Made behavior on when to change/not change the local | | 05 | Made behavior on when to change/not change the local |
| | UTO in response to incoming options consistent through | | | UTO in response to incoming options consistent through |
| | the document. This required some reshuffling of text | | | the document. This required some reshuffling of text |
| | and also removed the need for the special "don't care" | | | and also removed the need for the special "don't care" |
| | option value. | | | option value. |
| 04 | Clarified the results obtained by Medina et al. Added | | 04 | Clarified the results obtained by Medina et al. Added |
| | text to suggest inclusion of the UTO in the first | | | text to suggest inclusion of the UTO in the first |
| | non-SYN segment by the TCP that sent a SYN in response | | | non-SYN segment by the TCP that sent a SYN in response |
| | to an active OPEN. | | | to an active OPEN. |
| 03 | Corrected use of RFC2119 terminology. Clarified how | | 03 | Corrected use of RFC2119 terminology. Clarified how |
| | use of the TCP UTO is triggered. Clarified reason for | | | use of the TCP UTO is triggered. Clarified reason for |
| | sending a UTO in the SYN and SYN/ACK segments. | | | sending a UTO in the SYN and SYN/ACK segments. |
| | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO | | | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO |
| | options. Removed text that suggested that a UTO | | | socket options. Removed text that suggested that a |
| | should be sent upon receipt of an UTO from the other | | | UTO should be sent upon receipt of an UTO from the |
| | end. Required minimum value for the lower limit of | | | other end. Required minimum value for the lower limit |
| | the user timeout. Moved alternative solutions to | | | of the user timeout. Moved alternative solutions to |
| | appendix. Miscellaneous editorial changes. | | | appendix. Miscellaneous editorial changes. |
| 02 | Corrected terminology by replacing terms like | | 02 | Corrected terminology by replacing terms like |
| | "negotiate", "coordinate", etc. that were left from | | | "negotiate", "coordinate", etc. that were left from |
| | pre-WG-document times when the UTO was a more | | | pre-WG-document times when the UTO was a more |
| | formalized exchange instead of the advisory one it is | | | formalized exchange instead of the advisory one it is |
| | now. Application-requested UTOs take precedence over | | | now. Application-requested UTOs take precedence over |
| | ones received from the peer (pointed out by Ted | | | ones received from the peer (pointed out by Ted |
| | Faber). Added a brief mention of SO_SNDTIMEO and a | | | Faber). Added a brief mention of SO_SNDTIMEO and a |
| | slightly longer discussion of SO_RCVTIMEO. | | | slightly longer discussion of SO_RCVTIMEO. |
| 01 | Clarified and corrected the description of the | | 01 | Clarified and corrected the description of the |
 End of changes. 46 change blocks. 
133 lines changed or deleted 150 lines changed or added

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