draft-ietf-tcpm-tcp-uto-04.txt   draft-ietf-tcpm-tcp-uto-05.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) NEC Extensions (tcpm) Nokia
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH Intended status: Standards Track UTN/FRH
Expires: April 25, 2007 October 22, 2006 Expires: September 6, 2007 March 5, 2007
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-04 draft-ietf-tcpm-tcp-uto-05
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 April 25, 2007. This Internet-Draft will expire on September 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a new TCP option - the TCP User Timeout The TCP user timeout controls how long transmitted data may remain
Option - that allows a TCP to advertise its current user timeout for unacknowledged before a connection is forcefully closed. It is a
a connection. Thus, the remote TCP may modify its local user timeout local, per-connection parameter. This document specifies a new TCP
based on knowledge of the peer's user timeout. The TCP user timeout option - the TCP User Timeout Option - that allows one end of a TCP
controls how long transmitted data may remain unacknowledged before a connection to advertise its current user timeout value. This
connection is forcefully closed. It is a local, per-connection information allows the other end to adapt its user timeout
parameter. Increasing the user timeouts allows established TCP accordingly. Increasing the user timeouts on both ends of a TCP
connections to survive extended periods of disconnection. Decreasing connection allows it to survive extended periods without end-to-end
the user timeouts allows busy servers to explicitly notify their connectivity. Decreasing the user timeouts allows busy servers to
clients that they will maintain the connection state only across explicitly notify their clients that they will maintain the
short periods of disconnection. 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. Reliability Considerations . . . . . . . . . . . . . . . . 8 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 14 Appendix A. Document Revision History . . . . . . . . . . . . . . 13
Appendix B. Document Revision History . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification The Transmission Control Protocol (TCP) specification [RFC0793]
[RFC0793]defines a local, per-connection "user timeout" parameter defines a local, per-connection "user timeout" parameter that
that specifies the maximum amount of time that transmitted data may specifies the maximum amount of time that transmitted data may remain
remain unacknowledged before TCP will forcefully close the unacknowledged before TCP will forcefully close the corresponding
corresponding connection. Applications can set and change this connection. Applications can set and change this parameter with OPEN
parameter with OPEN and SEND calls. If a network disconnection lasts and SEND calls. If an end-to-end connectivity disruption lasts
longer than the user timeout, no acknowledgments will be received for longer than the user timeout, no acknowledgments will be received for
any transmission attempt, including keep-alives [TCP-ILLU], and the any transmission attempt, including keep-alives, and the TCP
TCP connection will close when the user timeout occurs. In the connection will close when the user timeout occurs.
absence of an application-specified user timeout, the TCP
specification [RFC0793] defines a default user timeout of 5 minutes.
In the absence of an application-specified user timeout, the TCP
specification [RFC0793] defines a default user timeout of 5 minutes.
The Host Requirements RFC [RFC1122] refines this definition by The Host Requirements RFC [RFC1122] refines this definition by
introducing two thresholds, R1 and R2 (R2 > R1), on the number of introducing two thresholds, R1 and R2 (R2 > R1), that control the
retransmissions of a single segment. It suggests that TCP should number of retransmission attempts for a single segment. It suggests
notify applications when R1 is reached for a segment, and close the that TCP should notify applications when R1 is reached for a segment,
connection once R2 is reached. [RFC1122] also defines the and close the connection when R2 is reached. [RFC1122] also defines
recommended values for R1 (three retransmissions) and R2 (100 the recommended values for R1 (three retransmissions) and R2 (100
seconds), noting that R2 for SYN segments should be at least 3 seconds), noting that R2 for SYN segments should be at least 3
minutes. Instead of a single user timeout, some TCP implementations minutes. Instead of a single user timeout, some TCP implementations
offer finer-grained policies. For example, Solaris supports offer finer-grained policies. For example, Solaris supports
different timeouts depending on whether a TCP connection is in the different timeouts depending on whether a TCP connection is in the
SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL].
Although some TCP implementations allow applications to set their Although some TCP implementations allow applications to set their
local user timeout, there is no in-protocol mechanism to signal local user timeout, TCP has no in-protocol mechanism to signal
changes in the local user timeout to remote peers. This causes local changes to the local user timeout to the other end. This causes
changes to be ineffective, because the peer will still close the local changes to be ineffective in allowing a connection to survive
connection after its user timeout expires, even when the host has extended periods without connectivity, because the other end will
raised its local user timeout. The ability to suggest the remote still close the connection after its user timeout expires.
peer a user timeout to be used for the connection can improve TCP's
operation in scenarios that are currently not well supported. One
example of such scenarios are mobile hosts that change network
attachment points based on current location. Such hosts, maybe using
MobileIP [RFC3344], HIP [RFC4423] or transport-layer mobility
mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected
to the Internet. In between connected periods, mobile hosts may
experience periods of disconnection during which no network service
is available. Other factors that can cause transient periods of
disconnection are high levels of congestion as well as link or
routing failures inside the network.
In scenarios similar to the ones described above, a host may not know The ability to inform the other end about the local user timeout for
exactly when or for how long it will be disconnected from the the connection can improve TCP operation in scenarios that are
network, but it might expect such events due to past mobility currently not well supported. One example of such scenarios are
patterns and thus benefit from using longer user timeouts. In other mobile hosts that change network attachment points based on current
scenarios, the length and time of a network disconnection may even be location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423]
predictable. For example, an orbiting node on a non-geostationary or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are
satellite might experience disconnections due to line-of-sight only intermittently connected to the Internet. In between connected
blocking by other planetary bodies. The disconnection periods of periods, mobile hosts may experience periods without end-to-end
such a node may be easily computable from orbital mechanics. connectivity. Other factors that can cause transient connectivity
disruptions are high levels of congestion or link or routing failures
inside the network. In these scenarios, a host may not know exactly
when or for how long connectivity disruptions will occur, but it
might be able to determine an increased likelihood for such events
based on past mobility patterns and thus benefit from using longer
user timeouts. In other scenarios, the time and duration of a
connectivity disruption may even be predictable. For example, an
orbiting node on a non-geostationary satellite might experience
connectivity disruptions due to line-of-sight blocking by other
planetary bodies. The timing of these events may be computable from
orbital mechanics.
This document specifies a new TCP option - the User Timeout Option This document specifies a new TCP option - the TCP User Timeout
(UTO) - that allows a TCP to advertise its current local user timeout Option - that allows one end of a TCP connection to advertise its
parameter. Thus, based on the information advertised by the remote current user timeout value. This information allows the other end to
TCP peer, a TCP may modify its own user timeout accordingly. This adapt its user timeout accordingly. Increasing the user timeouts on
allows, for example, mobile hosts to maintain TCP connections across both ends of a TCP connection allows it to survive extended periods
disconnected periods that are longer than their peer's default user without end-to-end connectivity. Decreasing the user timeouts allows
timeout. A second use of the TCP User Timeout Option is
advertisement of shorter-than-default user timeouts. This can allow
busy servers to explicitly notify their clients that they will busy servers to explicitly notify their clients that they will
maintain the state associated with established connections only maintain the connection state only for a short time without
across short periods of disconnection. connectivity.
Use of the TCP User Timeout Option could be triggered either by an
API call or by a system-wide toggle. The API could be, for example,
a Socket option that would need to be explicitly set by the
corresponding application. This option would default to "off". A
system-wide toggle would allow a system administrator to enable the
use of the TCP User Timeout Option on a system-wide basis, and set
the option a desired value. This system-wide toggle would allow the
use of the option by application programs that have not been
explicitly coded to do so. If such a system-wide toggle were
provided, it would default to "off".
In all cases, use of the TCP User Timeout Option would depend on an
active decision, either by the application programmer (by means of an
API call), or by a system administrator (by means of a system-wide
toggle).
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
Sending a TCP User Timeout Option informs the remote peer of the Use of the TCP User Timeout Option can be enabled either on a per-
current local user timeout for the connection, and suggests the TCP application basis, e.g., through a socket option, or controlled by a
peer to adapt its user timeout accordingly. The user timeout value system-wide setting. TCP maintains three per-connection state
included in a TCP User Timeout Option specifies the requested user variables to control the operation of UTO options, two of which
timeout during the synchronized states of a connection (ESTABLISHED, (ENABLED and CHANGEABLE) are new:
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).
Connections in other states MUST the default timeout values defined
in [RFC0793] [RFC1122].
Note that an exchange of TCP User Timeout Options between peers is ENABLED (Boolean)
not a binding negotiation. Transmission of a TCP User Timeout Option Flag that controls whether UTO options are enabled for a
is an advisory suggestion that the peer consider adapting its local connection. Defaults to false.
user timeout. Hosts remain free to adopt a different user timeout,
or to forcefully close or abort connections at any time for any
reason, whether or not they use custom user timeouts or have
suggested the peer to use them.
A host that supports the TCP User Timeout Option SHOULD include one LOCAL_UTO
in each packet that carries a SYN flag. The presence of this option Local user timeout in effect for this connection. This is either
is not a negotiation of the capability, but simply an advisory the system-wide default or an application-specified value.
message specifying the currently preferred user timeout value. This Defaults to the system-wide default.
allows TCP to adopt a user timeout with knowledge of that used by the
peer TCP from the very beginning of the data transfer phase. CHANGEABLE (Boolean)
Additionally, a TCP that supports the User Timeout Option and has Flag that controls whether the local user timeout may be changed
sent a SYN segment as a result of an active OPEN SHOULD include an based on UTO options received from the other end. Defaults to
UTO in the first packet that does not have the SYN flag set. This true and becomes false when an application explicitly sets
helps to minimize the amount of state information a TCP must keep for LOCAL_UTO.
Note that an exchange of UTO options between both ends of a
connection is not a binding negotiation. Transmission of a UTO
option is a suggestion that the other end consider adapting its user
timeout. This adaptation only happens if the the other end has
explicitly enabled it (CHANGEABLE is true).
Before opening a connection, an application that wishes to use UTO
options SHOULD enable their use by setting ENABLED to true. It MAY
pick an appropriate local UTO by setting LOCAL_UTO, which is
otherwise set to the system default. Finally, the application should
determine whether it will allow the local UTO to change based on
received UTO options from the other end. The default is to allow
this for connections that do not have a specific user timeout
concerns, i.e., connections that operate with the default LOCAL_UTO.
If an application explicitly sets LOCAL_UTO, CHANGEABLE MUST become
false, to prevent UTO options from the other end to override local
application requests. Alternatively, applications MAY set or clear
CHANGEABLE directly.
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
reliable way to initially exchange and potentially adapt to UTO
values. Systems MAY provide system-wide default settings for the
ENABLED, LOCAL_UTO and CHANGEABLE connection parameters when
applications do not initialize them themselves.
In addition to exchanging UTO options in the SYN segments, a
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
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 the TCP User Timeout Option SHOULD include it in A host that supports UTO options SHOULD include it in the next
the next possible segment to its peer whenever it starts using a new possible outgoing segment whenever it starts using a new user timeout
user timeout for the connection. This allows the peer to adapt its for the connection. This allows the other end to adapt its local
local user timeout for the connection accordingly. user timeout for the connection accordingly.
When a host that supports the TCP User Timeout Option receives one,
it will use the received value to compute the local user timeout for
the connection. Generally, hosts should honor requests for changes
to the user timeout (see Section 3.1), unless security concerns,
resource constraints or external policies indicate otherwise (see
Section 5). If so, hosts may use a different user timeout for the
connection.
A TCP implementation that does not support the TCP User Timeout A TCP implementation that does not support UTO options MUST silently
Option MUST silently ignore it [RFC1122], thus ensuring ignore them [RFC1122], thus ensuring interoperability.
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. Section 3.1 discusses user timeout limits, and describes a use for a connection. Section 3.1 discusses user timeout limits and
RECOMMENDED scheme to apply them. A TCP User Timeout Option with a discusses potentially problematic effects of user timeout settings.
value of zero (i.e., "now") is nonsensical and is used for a special
purpose, see Section 3.4. Section 3.1 discusses potentially
problematic effects of other user timeout durations.
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. Application-requested user timeout values always take connection. If the CHANGEABLE flag is false, LOCAL_UTO MUST NOT be
precedence over timeout values received from the peer in a TCP User changed, regardless of the received UTO option. Without this
Timeout Option. [anchor3] Consequently, unless the application on the restriction, UTO would modify TCP semantics, because application-
local host has requested a specific user timeout for the connection, requested UTOs could be overridden by peer requests. In this case,
e.g., through the OPEN or SEND calls, hosts SHOULD adjust their local they SHOULD, however, notify the application about the user timeout
user timeout in response to receiving a TCP User Timeout Option, as value received from the other end.
described in the remainder of this section. If the local application
has requested a specific local user timeout, TCP implementations MUST
NOT change it in response to receiving a TCP User Timeout Option. In
this case, they SHOULD, however, notify the application about the
user timeout value received from the peer.
The User Timeout Option specifies the user timeout in terms of time In general, unless the application on the local host has requested a
units, rather than in terms of number of retransmissions or round- specific LOCAL_UTO for the connection, CHANGEABLE will be true and
trip times (RTTs), as in most cases the periods of disconnection have hosts SHOULD adjust the local user timeout in response to receiving a
to do with operation and mobility patterns, rather than with the UTO option, as described in the remainder of this section.
current network conditions. Thus, the TCP User Timeout Option allows
hosts to exchange user timeout values from 1 second to over 9 hours The UTO option specifies the user timeout in in seconds or minutes,
at a granularity of seconds, and from 1 minute to over 22 days at a rather than in number of retransmissions or round-trip times (RTTs).
granularity of minutes. (An option value of zero is reserved for a Thus, the UTO option allows hosts to exchange user timeout values
special purpose, see Section 3.4.) 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.
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 [TCP-ILLU]. Although the TCP to user timeout values of a few minutes. Although the UTO option
User Timeout Option allows suggestion of short timeouts, applications allows suggestion of short timeouts, applications advertising them
advertising them should consider these effects. should consider these effects.
Long user timeout values allow hosts to tolerate extended periods of Long user timeout values allow hosts to tolerate extended periods
disconnection. However, they also require hosts to maintain the TCP without end-to-end connectivity. However, they also require hosts to
state information associated with connections for long periods of maintain the TCP state information associated with connections for
time. Section 5 discusses the security implications of long timeout long periods of time. Section 5 discusses the security implications
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 user timeouts
based on upper and lower limits. Under the RECOMMENDED scheme, each based on upper and lower limits.
TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection
according to this formula:
USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
SHOULD compute LOCAL_UTO for a connection according to this formula:
Each field is to be interpreted as follows: LOCAL_UTO = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
USER_TIMEOUT Each field is to be interpreted as follows:
Resulting user timeout value to be adopted by the local TCP for a
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 L_LIMIT
Current lower limit imposed on the user timeout of a connection by Current lower limit imposed on the user timeout of a connection by
the local host. the local host.
LOCAL_UTO
Current local user timeout of this specific connection.
REMOTE_UTO REMOTE_UTO
Last "user timeout" value suggested by the remote peer by means of Last "user timeout" value received from the other end in a TCP
the TCP User Timeout Option. User Timeout Option.
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 the two announced values will be adopted for the user the maximum of current LOCAL_UTO and the last user timeout value
timeout of the connection. The rationale is that choosing the received from the other end will become the new LOCAL_UTO for the
maximum of the two values will let the connection survive longer connection. The rationale is that choosing the maximum of the two
periods of disconnection. If the TCP that announced the lower of the values will let the connection survive longer periods without end-to-
two user timeout values did so in order to reduce the amount of TCP end connectivity. If the end that announced the lower of the two
state information that must be kept on the host, it can, user timeout values did so in order to reduce the amount of TCP state
nevertheless, close or abort the connection whenever it wants. information that must be kept on the host, it can, nevertheless,
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 5discusses the details of these attacks. attacks. Section 5discusses the details of these attacks.
skipping to change at page 8, line 16 skipping to change at page 7, line 51
attack status and could be dynamically adapted. 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. retransmission timeout (RTO) for the connection. It is worth noting
that an upper limit may be imposed on the RTO, provided it is at
least 60 seconds [RFC2988].
3.2. Reliability Considerations 3.2. UTO Option Reliability
The TCP User Timeout Option is an advisory TCP option that does not The TCP User Timeout Option is an advisory TCP option that does not
change processing of subsequent segments. Unlike other TCP options, change processing of subsequent segments. Unlike other TCP options,
it need not be exchanged reliably. Consequently, the specification it need not be exchanged reliably. Consequently, the specification
in this section does not define a reliability handshake for TCP User does not define a reliability handshake for UTO option exchanges.
Timeout Option exchanges. When a segment that carries a TCP User When a segment that carries a UTO option is lost, the other end will
Timeout Option is lost, the option may never reach the intended peer. 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 the TCP User Timeout Option when reliability, such as retransmitting a UTO option when they retransmit
they retransmit the segment that originally carried it, or a segment that originally carried it, or "attaching" the option to a
"attaching" the option to a byte in the stream and retransmitting the byte in the stream and retransmitting the option whenever that byte
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 the TCP User Timeout Option, they do not transmission reliability for UTO options, they do not guarantee
guarantee delivery (a three-way handshake would be required for delivery (a three-way handshake would be required for this).
this). Consequently, implementations should not assume that a TCP Consequently, implementations MUST NOT assume that UTO options are
User Timeout Option is reliably transmitted. transmitted reliably.
3.3. Option Format 3.3. Option Format
0 1 2 3 Sending a TCP User Timeout Option informs the other end of the
current local user timeout for the connection and suggests that the
other end adapt its user timeout accordingly. The user timeout value
included in a UTO option contains the local user timeout (LOCAL_UTO)
used during the synchronized states of a connection (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).
Connections in other states MUST use the default timeout values
defined in [RFC0793] and [RFC1122].
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
Figure 1 shows the format of the TCP User Timeout Option. It Figure 1 shows the format of the TCP User Timeout Option. It
contains these fields: contains these fields:
Kind (8 bits) Kind (8 bits)
skipping to change at page 9, line 39 skipping to change at page 9, line 20
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 suggestion for this connection. It Specifies the user timeout (LOCAL_UTO) used for this connection.
MUST be interpreted as a 15-bit unsigned integer. The granularity It MUST be interpreted as a 15-bit unsigned integer. The
of the timeout (minutes or seconds) depends on the "G" field. granularity of the timeout (minutes or seconds) depends on the "G"
field.
3.4. Special Option Values
Whenever it is legal to do so according to the specification in the
previous sections, TCP implementations MAY send a zero-second TCP
User Timeout Option, i.e, with a "User Timeout" field of zero and a
"Granularity" of zero. This signals their peers that they support
the option, but do not suggest a specific user timeout value at that
time. Essentially, a zero-second TCP User Timeout Option acts as a
"don't care" value.
Thus, the sender SHOULD adapt its local user timeout according to the 3.4. Reserved Option Values
peer's UTO, and the receiver SHOULD continue using its local user
timeout. In order to achieve this, the receiver of a zero-second TCP
User Timeout Option SHOULD perform the RECOMMENDED strategy for
calculating a new local USER_TIMEOUT described in Section 3.1, with a
numeric value of zero seconds for REMOTE_UTO. The sender SHOULD
perform the same calculation as described in Section 3.1, with a
numeric value of zero seconds for LOCAL_UTO.
A zero-minute TCP User Timeout Option, i.e., with a "User Timeout" An empty TCP User Timeout Option, i.e., one with a "User Timeout"
field of zero and a "Granularity" bit of one, is reserved for future field of zero and a "Granularity" bit of either minutes (1) or
use. TCP implementations MUST NOT send it and MUST ignore it upon seconds (0), is reserved for future use. TCP implementations MUST
reception. NOT send it and MUST ignore 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
interoperability. In a study of the effects of middleboxes on interoperability. In a study of the effects of middleboxes on
transport protocols, Medina et al. have shown that unknown TCP transport protocols, Medina et al. have shown that the vast majority
options are correctly handled by the vast majority of modern TCP of modern TCP stacks correctly handle unknown TCP options [MEDINA].
stacks [MEDINA]. In this study, 3% of connections failed when an In this study, 3% of connections failed when an unknown TCP option
unknown TCP option appeared in the middle of a connection. Because appeared in the middle of a connection. Because the number of
these failures violate existing requirements to ignore unknown failures caused by unknown options is small and they are a result of
options, they do not warrant taking special measures to handle these incorrectly implemented TCP stacks that violate existing requirements
cases. In particular, we do not define a separate mechanism to to ignore unknown options, they do not warrant special measures.
negotiate support of the TCP User Timeout Option on the three-way Thus, this document does not define a mechanism to negotiate support
handshake. of the TCP User Timeout Option during the three-way handshake.
Stateful firewalls usually reset connections after a period of Stateful firewalls usually reset connections after a period of
inactivity. If such a firewall exists along the path between two inactivity. If such a firewall exists along the path, it may close
peers, it may close or abort connections regardless of the use of the or abort connections regardless of the use of the TCP User Timeout
TCP User Timeout Option. In the future, such firewalls may learn to Option. In the future, such firewalls may learn to parse the TCP
parse the TCP User Timeout Option and modify their behavior or the User Timeout Option and modify their behavior - or the option
option accordingly. contents - accordingly.
4.2. TCP Keep-Alives 4.2. TCP Keep-Alives
Some TCP implementations, such as the one 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 of disconnection. otherwise have survived the transient period without connectivity.
Therefore, if a TCP peer enables TCP keep-alives for a connection Therefore, if a connection enables keep-alives that is also using the
that is using the TCP User Timeout Option, then the keep-alive timer TCP User Timeout Option, then the keep-alive timer MUST be set to a
MUST be set to a value larger than that of the adopted USER TIMEOUT. value larger than that of the adopted USER TIMEOUT.
5. Security Considerations 5. Security Considerations
Lengthening user timeouts has obvious security implications. Lengthening user timeouts has obvious security implications.
Flooding attacks cause denial of service by forcing servers to commit Flooding attacks cause denial of service by forcing servers to commit
resources for maintaining the state of throw-away connections. resources for maintaining the state of throw-away connections.
However, TCP implementations do not become more vulnerable to simple However, TCP implementations do not become more vulnerable to simple
SYN flooding by implementing the TCP User Timeout Option, because SYN flooding by implementing the TCP User Timeout Option, because
user timeouts exchanged during the handshake only affect the user timeouts exchanged during the handshake only affect the
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK), which simple SYN floods never reach. CLOSING, LAST-ACK), which simple SYN floods never reach.
However, when an attacker completes the three-way handshakes of its However, when an attacker completes the three-way handshakes of its
throw-away connections it can amplify the effects of resource throw-away connections it can amplify the effects of resource
exhaustion attacks, because the attacked server must maintain the exhaustion attacks, because the attacked server must maintain the
connection state associated with the throw-away connections for connection state associated with the throw-away connections for
longer durations. Because connection state is kept longer, lower- longer durations. Because connection state is kept longer, lower-
frequency attack traffic, which may be more difficult to detect, can frequency attack traffic, which may be more difficult to detect, can
already cause resource exhaustion. already exacerbate resource exhaustion.
Several approaches can help mitigate this issue. First, Several approaches can help mitigate this issue. First,
implementations can require prior peer authentication, e.g., using implementations can require prior peer authentication, e.g., using
IPsec [RFC4301], before accepting long user timeouts for the peer's IPsec [RFC4301], before accepting long user timeouts for the peer's
connections. Similarly, a host can start to accept long user connections. Similarly, a host can start to accept long user
timeouts for an established connection only after in-band timeouts for an established connection only after in-band
authentication has occurred, for example, after a TLS handshake authentication has occurred, for example, after a TLS handshake
across the connection has succeeded [RFC2246]. Although these are across the connection has succeeded [RFC4346]. Although these are
arguably the most complete solutions, they depend on external arguably the most complete solutions, they depend on external
mechanisms to establish a trust relationship. mechanisms to establish a trust relationship.
A second alternative that does not depend on external mechanisms A second alternative that does not depend on external mechanisms
would introduce a per-peer limit on the number of connections that would introduce a per-peer limit on the number of connections that
may use increased user timeouts. Several variants of this approach may use increased user timeouts. Several variants of this approach
are possible, such as fixed limits or shortening accepted user are possible, such as fixed limits or shortening accepted user
timeouts with a rising number of connections. Although this timeouts with a rising number of connections. Although this
alternative does not eliminate resource exhaustion attacks from a alternative does not eliminate resource exhaustion attacks from a
single peer, it can limit their effects. Reducing the number of single peer, it can limit their effects. Reducing the number of
skipping to change at page 13, line 30 skipping to change at page 12, line 40
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-00 (work in Mitigations", draft-ietf-tcpm-syn-flood-01 (work in
progress), July 2006. progress), December 2006.
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Interactions Between Transport Protocols and Middleboxes",
Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
Internet Measurement , October 2004. Measurement , October 2004.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
RFC 2246, January 1999. 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,
August 2002. August 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(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.
[TCP-ILLU]
Stevens, W., "TCP/IP Illustrated, Volume 1: The
Protocols", Addison-Wesley , 1994.
Editorial Comments Editorial Comments
[anchor3] Without this, UTO would modify TCP semantics, because [anchor3] Lars: With the new CHANGEABLE flag, which prevents
application-requested UTOs could be overridden by peer changing of LOCAL_UTO when an application has indicated
requests. that it cares about the value, I think the formula can
become LOCAL_UTO = min(U_LIMIT, max(REMOTE_UTO, L_LIMIT)),
Appendix A. Alternative solutions i.e., we adopt whatever the other end suggests, given that
it is with in acceptable limits. I didn't want to make
The same benefits could be obtained through an application-layer this change without discussing it first, however.
mechanism, i.e., exchanging user timeout information via application
messages and having the application adjust the user timeouts through
the TCP API on both sides of a connection. This approach would not
require a new TCP option, but would require changing all application
implementations that desire to tolerate extended periods of
disconnection, and in most cases would also require a modification to
the corresponding application layer protocol. With the proposed TCP
option, application changes may not be necessary at all, or may be
restricted to sender- or receiver-side only, and there is no need to
modify the corresponding application protocol.
A different approach to tolerate longer periods of disconnection
would be to simply increase the system-wide user timeout on both
peers. This approach has the benefit of not requiring a new TCP
option or application changes. However, it can also significantly
increase the amount of connection state a busy server must maintain,
because a longer global timeout value would apply to all its
connections.
The proposed TCP User Timeout Option, on the other hand, allows hosts
to selectively manage the user timeouts of individual connections,
reducing the amount of state they must maintain across disconnected
periods.
Appendix B. Document Revision History Appendix A. Document Revision History
To be removed upon publication To be removed upon publication
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| 05 | Made behavior on when to change/not change the local |
| | UTO in response to incoming options consistent through |
| | the document. This required some reshuffling of text |
| | and also removed the need for the special "don't care" |
| | 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 | | | options. Removed text that suggested that a UTO |
| | should be sent upon receipt of an UTO from the remote | | | should be sent upon receipt of an UTO from the other |
| | peer. Required minimum value for the lower limit of | | | end. Required minimum value for the lower limit of |
| | the user timeout. Moved alternative solutions to | | | 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. |
skipping to change at page 16, line 8 skipping to change at page 14, line 39
| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the |
| | secretariat after WG adoption. Thus, permit | | | secretariat after WG adoption. Thus, permit |
| | derivative works. Updated Lars Eggert's funding | | | derivative works. Updated Lars Eggert's funding |
| | attribution. Updated several references. No | | | attribution. Updated several references. No |
| | technical changes. | | | technical changes. |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Lars Eggert Lars Eggert
NEC Network Laboratories Nokia Research Center
Kurfuerstenanlage 36 P.O. Box 407
Heidelberg 69115 Nokia Group 00045
Germany Finland
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Phone: +358 50 48 24461
Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
URI: http://www.gont.com.ar/ URI: http://www.gont.com.ar/
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 68 change blocks. 
312 lines changed or deleted 267 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/