draft-ietf-tcpm-urgent-data-04.txt | draft-ietf-tcpm-urgent-data-05.txt | |||
---|---|---|---|---|
TCP Maintenance and Minor F. Gont | TCP Maintenance and Minor F. Gont | |||
Extensions (tcpm) UTN/FRH | Extensions (tcpm) UTN/FRH | |||
Internet-Draft A. Yourtchenko | Internet-Draft A. Yourtchenko | |||
Updates: 793, 1011, 1122 Cisco | Updates: 793, 1011, 1122 Cisco | |||
(if approved) March 3, 2010 | (if approved) March 4, 2010 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: September 4, 2010 | Expires: September 5, 2010 | |||
On the implementation of the TCP urgent mechanism | On the implementation of the TCP urgent mechanism | |||
draft-ietf-tcpm-urgent-data-04.txt | draft-ietf-tcpm-urgent-data-05.txt | |||
Abstract | Abstract | |||
This document analyzes how current TCP implementations process TCP | This document analyzes how current TCP implementations process TCP | |||
urgent indications, and how the behavior of some widely-deployed | urgent indications, and how the behavior of some widely-deployed | |||
middle-boxes affect how urgent indications are processed by end | middle-boxes affect how urgent indications are processed by end | |||
systems. This document updates the relevant specifications such that | systems. This document updates the relevant specifications such that | |||
they accommodate current practice in processing TCP urgent | they accommodate current practice in processing TCP urgent | |||
indications, provides advice to applications that make use of the | indications, provides advice to applications that make use of the | |||
urgent mechanism, and raises awareness about the reliability of TCP | urgent mechanism, and raises awareness about the reliability of TCP | |||
skipping to change at page 1, line 46 | skipping to change at page 1, line 46 | |||
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 4, 2010. | This Internet-Draft will expire on September 5, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
skipping to change at page 3, line 40 | skipping to change at page 3, line 40 | |||
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 11 | A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
A.5. Cisco IOS software . . . . . . . . . . . . . . . . . . . . 11 | A.5. Cisco IOS software . . . . . . . . . . . . . . . . . . . . 11 | |||
A.6. Microsoft Windows 2000, Service Pack 4 . . . . . . . . . . 11 | A.6. Microsoft Windows 2000, Service Pack 4 . . . . . . . . . . 11 | |||
A.7. Microsoft Windows 2008 . . . . . . . . . . . . . . . . . . 11 | A.7. Microsoft Windows 2008 . . . . . . . . . . . . . . . . . . 11 | |||
A.8. Microsoft Windows 95 . . . . . . . . . . . . . . . . . . . 12 | A.8. Microsoft Windows 95 . . . . . . . . . . . . . . . . . . . 12 | |||
Appendix B. Changes from previous versions of the draft (to | Appendix B. Changes from previous versions of the draft (to | |||
be removed by the RFC Editor before publishing | be removed by the RFC Editor before publishing | |||
this document as an RFC) . . . . . . . . . . . . . . 12 | this document as an RFC) . . . . . . . . . . . . . . 12 | |||
B.1. Changes from draft-ietf-tcpm-urgent-data-03 . . . . . . . 12 | B.1. Changes from draft-ietf-tcpm-urgent-data-04 . . . . . . . 12 | |||
B.2. Changes from draft-ietf-tcpm-urgent-data-02 . . . . . . . 12 | B.2. Changes from draft-ietf-tcpm-urgent-data-03 . . . . . . . 12 | |||
B.3. Changes from draft-ietf-tcpm-urgent-data-01 . . . . . . . 12 | B.3. Changes from draft-ietf-tcpm-urgent-data-02 . . . . . . . 12 | |||
B.4. Changes from draft-ietf-tcpm-urgent-data-00 . . . . . . . 12 | B.4. Changes from draft-ietf-tcpm-urgent-data-01 . . . . . . . 12 | |||
B.5. Changes from draft-gont-tcpm-urgent-data-01 . . . . . . . 12 | B.5. Changes from draft-ietf-tcpm-urgent-data-00 . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | B.6. Changes from draft-gont-tcpm-urgent-data-01 . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
1. Introduction | 1. Introduction | |||
This document analyzes how some current TCP implementations process | This document analyzes how some current TCP implementations process | |||
TCP urgent indications, and how the behavior of some widely-deployed | TCP urgent indications, and how the behavior of some widely-deployed | |||
middle-boxes affect the processing of urgent indications by hosts. | middle-boxes affect the processing of urgent indications by hosts. | |||
This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC | This document updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC | |||
1122 [RFC1122] such that they accommodate current practice in | 1122 [RFC1122] such that they accommodate current practice in | |||
processing TCP urgent indications, provides advice to applications | processing TCP urgent indications, provides advice to applications | |||
using the urgent mechanism, and raises awareness about the | using the urgent mechanism, and raises awareness about the | |||
skipping to change at page 4, line 45 | skipping to change at page 4, line 45 | |||
to stimulate the receiving user to accept some "urgent data" and to | to stimulate the receiving user to accept some "urgent data" and to | |||
permit the receiving TCP to indicate to the receiving user when all | permit the receiving TCP to indicate to the receiving user when all | |||
the currently known urgent data have been received by the user. | the currently known urgent data have been received by the user. | |||
The TCP urgent mechanism permits a point in the data stream to be | The TCP urgent mechanism permits a point in the data stream to be | |||
designated as the end of urgent information. Whenever this point is | designated as the end of urgent information. Whenever this point is | |||
in advance of the receive sequence number (RCV.NXT) at the receiving | in advance of the receive sequence number (RCV.NXT) at the receiving | |||
TCP, that TCP must tell the user to go into "urgent mode"; when the | TCP, that TCP must tell the user to go into "urgent mode"; when the | |||
receive sequence number catches up to the urgent pointer, the TCP | receive sequence number catches up to the urgent pointer, the TCP | |||
must tell user to go into "normal mode" [RFC0793]. This means, for | must tell user to go into "normal mode" [RFC0793]. This means, for | |||
example, that data that were received as "normal data" might become | example, that data that was received as "normal data" might become | |||
"urgent data" if an urgent indication is received in some successive | "urgent data" if an urgent indication is received in some successive | |||
TCP segment before those data are consumed by the TCP user. | TCP segment before that data is consumed by the TCP user. | |||
The URG control flag indicates that the "Urgent Pointer" field is | The URG control flag indicates that the "Urgent Pointer" field is | |||
meaningful and must be added to the segment sequence number to yield | meaningful and must be added to the segment sequence number to yield | |||
the urgent pointer. The absence of this flag indicates that there is | the urgent pointer. The absence of this flag indicates that there is | |||
no urgent data outstanding [RFC0793]. | no urgent data outstanding [RFC0793]. | |||
The TCP urgent mechanism is NOT a mechanism for sending "out-of-band" | The TCP urgent mechanism is NOT a mechanism for sending "out-of-band" | |||
data: the so-called "urgent data" should be delivered "in-line" to | data: the so-called "urgent data" should be delivered "in-line" to | |||
the TCP user. | the TCP user. | |||
skipping to change at page 6, line 10 | skipping to change at page 6, line 10 | |||
Unfortunately, virtually all TCP implementations process TCP urgent | Unfortunately, virtually all TCP implementations process TCP urgent | |||
data differently. By default, the last byte of "urgent data" is | data differently. By default, the last byte of "urgent data" is | |||
delivered "out of band" to the application. That is, it is not | delivered "out of band" to the application. That is, it is not | |||
delivered as part of the normal data stream. For example, the "out | delivered as part of the normal data stream. For example, the "out | |||
of band" byte is read by an application when a recv(2) system call | of band" byte is read by an application when a recv(2) system call | |||
with the MSG_OOB flag set is issued. | with the MSG_OOB flag set is issued. | |||
Most implementations provide a socket option (SO_OOBINLINE) that | Most implementations provide a socket option (SO_OOBINLINE) that | |||
allows an application to override the (broken) default processing of | allows an application to override the (broken) default processing of | |||
urgent data, so that they are delivered "in band" to the application, | urgent data, so that it is delivered "in band" to the application, | |||
thus providing the semantics intended by the IETF specifications. | thus providing the semantics intended by the IETF specifications. | |||
3.2. Semantics of the Urgent Pointer | 3.2. Semantics of the Urgent Pointer | |||
All the popular implementations that the authors of this document | All the popular implementations that the authors of this document | |||
have been able to test interpret the semantics of the TCP Urgent | have been able to test interpret the semantics of the TCP Urgent | |||
Pointer as specified in Section 3.1 of RFC 793. This means that even | Pointer as specified in Section 3.1 of RFC 793. This means that even | |||
when RFC 1122 officially updated RFC 793 to clarify the ambiguity in | when RFC 1122 officially updated RFC 793 to clarify the ambiguity in | |||
the semantics of the Urgent Pointer, this clarification was never | the semantics of the Urgent Pointer, this clarification was never | |||
reflected into actual implementations (i.e., virtually all | reflected into actual implementations (i.e., virtually all | |||
skipping to change at page 8, line 9 | skipping to change at page 8, line 9 | |||
As a result of the issues discussed in Section 3.2 and Section 3.4, | As a result of the issues discussed in Section 3.2 and Section 3.4, | |||
new applications SHOULD NOT employ the TCP urgent mechanism. | new applications SHOULD NOT employ the TCP urgent mechanism. | |||
However, TCP implementations MUST still include support for the | However, TCP implementations MUST still include support for the | |||
urgent mechanism such that existing applications can still use it. | urgent mechanism such that existing applications can still use it. | |||
6. Advice to applications that make use of the urgent mechanism | 6. Advice to applications that make use of the urgent mechanism | |||
Even though applications SHOULD NOT employ the urgent mechanism, | Even though applications SHOULD NOT employ the urgent mechanism, | |||
applications that still decide to employ it MUST set the SO_OOBINLINE | applications that still decide to employ it MUST set the SO_OOBINLINE | |||
socket option, such that "urgent data" are delivered inline, as | socket option, such that "urgent data" is delivered inline, as | |||
intended by the IETF specifications. | intended by the IETF specifications. | |||
7. Security Considerations | 7. Security Considerations | |||
Given that there are two different interpretations of the semantics | Given that there are two different interpretations of the semantics | |||
of the Urgent Pointer in current implementations (e.g., depending on | of the Urgent Pointer in current implementations (e.g., depending on | |||
the value of the tcp_stdurg sysctl), and that middle-boxes (such as | the value of the tcp_stdurg sysctl), and that middle-boxes (such as | |||
packet scrubbers) or the end-systems themselves could cause the | packet scrubbers) or the end-systems themselves could cause the | |||
urgent data to be processed "in band", there exists ambiguity in how | urgent data to be processed "in band", there exists ambiguity in how | |||
"urgent data" sent by a TCP will be processed by the intended | "urgent data" sent by a TCP will be processed by the intended | |||
skipping to change at page 11, line 4 | skipping to change at page 11, line 4 | |||
Linux supports only one byte of urgent data. That is, only the byte | Linux supports only one byte of urgent data. That is, only the byte | |||
preceding the Urgent Pointer is considered as "urgent data". | preceding the Urgent Pointer is considered as "urgent data". | |||
A.3. NetBSD | A.3. NetBSD | |||
NetBSD 5.0.1 [NetBSD] interprets the semantics of the urgent pointer | NetBSD 5.0.1 [NetBSD] interprets the semantics of the urgent pointer | |||
as specified in Section 4 of this document. It does not provide any | as specified in Section 4 of this document. It does not provide any | |||
sysctl to override this behavior. | sysctl to override this behavior. | |||
NetBSD provides the SO_OOBINLINE socket option that, when set, causes | NetBSD provides the SO_OOBINLINE socket option that, when set, causes | |||
TCP "urgent data" to remain "in band". That is, they will be | TCP "urgent data" to remain "in band". That is, it will be | |||
accessible by the read(2) call or the recv(2) call without the | accessible by the read(2) call or the recv(2) call without the | |||
MSG_OOB flag. | MSG_OOB flag. | |||
NetBSD supports only one byte of urgent data. That is, only the byte | NetBSD supports only one byte of urgent data. That is, only the byte | |||
preceding the Urgent Pointer is considered as "urgent data". | preceding the Urgent Pointer is considered as "urgent data". | |||
A.4. OpenBSD | A.4. OpenBSD | |||
OpenBSD 4.2 [OpenBSD] interprets the semantics of the urgent pointer | OpenBSD 4.2 [OpenBSD] interprets the semantics of the urgent pointer | |||
as specified in Section 4 of this document. It does not provide any | as specified in Section 4 of this document. It does not provide any | |||
sysctl to override this behavior. | sysctl to override this behavior. | |||
OpenBSD provides the SO_OOBINLINE socket option that, when set, | OpenBSD provides the SO_OOBINLINE socket option that, when set, | |||
causes TCP urgent data to remain "in band". That is, they will be | causes TCP urgent data to remain "in band". That is, it will be | |||
accessible by the read(2) or recv(2) calls without the MSG_OOB flag. | accessible by the read(2) or recv(2) calls without the MSG_OOB flag. | |||
OpenBSD supports only one byte of urgent data. That is, only the | OpenBSD supports only one byte of urgent data. That is, only the | |||
byte preceding the Urgent Pointer is considered as "urgent data". | byte preceding the Urgent Pointer is considered as "urgent data". | |||
A.5. Cisco IOS software | A.5. Cisco IOS software | |||
Cisco IOS Software Releases 12.2(18)SXF7, 12.4(15)T7 interpret the | Cisco IOS Software Releases 12.2(18)SXF7, 12.4(15)T7 interpret the | |||
semantics of the urgent pointer as specified in Section 4 of this | semantics of the urgent pointer as specified in Section 4 of this | |||
document. | document. | |||
skipping to change at page 12, line 19 | skipping to change at page 12, line 19 | |||
BSDUrgent system-wide variable to override this behavior, | BSDUrgent system-wide variable to override this behavior, | |||
interpreting the Urgent Pointer as specified in RFC 1122 [RFC1122]. | interpreting the Urgent Pointer as specified in RFC 1122 [RFC1122]. | |||
Windows 95 supports only one byte of urgent data. That is, only the | Windows 95 supports only one byte of urgent data. That is, only the | |||
byte preceding the Urgent Pointer is considered as "urgent data". | byte preceding the Urgent Pointer is considered as "urgent data". | |||
[Windows95] | [Windows95] | |||
Appendix B. Changes from previous versions of the draft (to be removed | Appendix B. Changes from previous versions of the draft (to be removed | |||
by the RFC Editor before publishing this document as an | by the RFC Editor before publishing this document as an | |||
RFC) | RFC) | |||
B.1. Changes from draft-ietf-tcpm-urgent-data-03 | B.1. Changes from draft-ietf-tcpm-urgent-data-04 | |||
o Fixes grammar errors wrt the term "data" (thanks to David Borman, | ||||
once again ;-) ) | ||||
B.2. Changes from draft-ietf-tcpm-urgent-data-03 | ||||
o Addresses feedback sent by David Borman, and nit pointed out by | o Addresses feedback sent by David Borman, and nit pointed out by | |||
John Heffner. | John Heffner. | |||
B.2. Changes from draft-ietf-tcpm-urgent-data-02 | B.3. Changes from draft-ietf-tcpm-urgent-data-02 | |||
o Addresses WGLC feedback submitted by Michael Welzl, Anantha | o Addresses WGLC feedback submitted by Michael Welzl, Anantha | |||
Ramaiah, and Wesley Eddy. | Ramaiah, and Wesley Eddy. | |||
B.3. Changes from draft-ietf-tcpm-urgent-data-01 | B.4. Changes from draft-ietf-tcpm-urgent-data-01 | |||
o Fixes reference to Cisco IOS Software (layer 8+ stuff ;-) ). | o Fixes reference to Cisco IOS Software (layer 8+ stuff ;-) ). | |||
o Cleaned-up Appendix A.5. | o Cleaned-up Appendix A.5. | |||
B.4. Changes from draft-ietf-tcpm-urgent-data-00 | B.5. Changes from draft-ietf-tcpm-urgent-data-00 | |||
o Minor editorial changes. | o Minor editorial changes. | |||
o Incorporated the specific changes/advice stated in | o Incorporated the specific changes/advice stated in | |||
http://www.ietf.org/mail-archive/web/tcpm/current/msg04548.html in | http://www.ietf.org/mail-archive/web/tcpm/current/msg04548.html in | |||
different sections (Section 4, Section 5, Section 6). | different sections (Section 4, Section 5, Section 6). | |||
B.5. Changes from draft-gont-tcpm-urgent-data-01 | B.6. Changes from draft-gont-tcpm-urgent-data-01 | |||
o Draft resubmitted as draft-ietf, as a result of wg consensus on | o Draft resubmitted as draft-ietf, as a result of wg consensus on | |||
adopting the document as a tcpm wg item. | adopting the document as a tcpm wg item. | |||
Authors' Addresses | Authors' Addresses | |||
Fernando Gont | Fernando Gont | |||
Universidad Tecnologica Nacional / Facultad Regional Haedo | Universidad Tecnologica Nacional / Facultad Regional Haedo | |||
Evaristo Carriego 2644 | Evaristo Carriego 2644 | |||
Haedo, Provincia de Buenos Aires 1706 | Haedo, Provincia de Buenos Aires 1706 | |||
End of changes. 16 change blocks. | ||||
21 lines changed or deleted | 27 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |