draft-ietf-tcpm-urgent-data-06.txt | draft-ietf-tcpm-urgent-data-07.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) August 23, 2010 | (if approved) October 16, 2010 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: February 24, 2011 | Expires: April 19, 2011 | |||
On the implementation of the TCP urgent mechanism | On the implementation of the TCP urgent mechanism | |||
draft-ietf-tcpm-urgent-data-06.txt | draft-ietf-tcpm-urgent-data-07.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, raises awareness about the reliability of TCP urgent | |||
urgent mechanism, and raises awareness about the reliability of TCP | indications in the Internet and recommends against the use of the | |||
urgent indications in the current Internet. | urgent indications (but provides advice to applications in case that | |||
they do). | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on February 24, 2011. | This Internet-Draft will expire on April 19, 2011. | |||
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 | |||
skipping to change at page 2, line 18 | skipping to change at page 2, line 19 | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Specification of the TCP urgent mechanism . . . . . . . . . . 4 | 2. Specification of the TCP urgent mechanism . . . . . . . . . . 4 | |||
2.1. Semantics of urgent indications . . . . . . . . . . . . . 4 | 2.1. Semantics of urgent indications . . . . . . . . . . . . . 4 | |||
2.2. Semantics of the Urgent Pointer . . . . . . . . . . . . . 5 | 2.2. Semantics of the Urgent Pointer . . . . . . . . . . . . . 5 | |||
2.3. Allowed length of urgent data . . . . . . . . . . . . . . 5 | 2.3. Allowed length of urgent data . . . . . . . . . . . . . . 5 | |||
3. Current implementation practice of TCP urgent data . . . . . . 5 | 3. Current implementation practice of TCP urgent data . . . . . . 6 | |||
3.1. Semantics of urgent indications . . . . . . . . . . . . . 5 | 3.1. Semantics of urgent indications . . . . . . . . . . . . . 6 | |||
3.2. Semantics of the Urgent Pointer . . . . . . . . . . . . . 6 | 3.2. Semantics of the Urgent Pointer . . . . . . . . . . . . . 6 | |||
3.3. Allowed length of urgent data . . . . . . . . . . . . . . 6 | 3.3. Allowed length of urgent data . . . . . . . . . . . . . . 7 | |||
3.4. Interaction of middle-boxes with TCP urgent indications . 7 | 3.4. Interaction of middle-boxes with TCP urgent indications . 7 | |||
4. Updating RFC 793, RFC 1011, and RFC 1122 . . . . . . . . . . . 7 | 4. Updating RFC 793, RFC 1011, and RFC 1122 . . . . . . . . . . . 7 | |||
5. Advice to new applications employing TCP . . . . . . . . . . . 7 | 5. Advice to new applications employing TCP . . . . . . . . . . . 8 | |||
6. Advice to applications that make use of the urgent | 6. Advice to applications that make use of the urgent | |||
mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 | |||
Appendix A. Survey of the processing of TCP urgent | Appendix A. Survey of the processing of TCP urgent | |||
indications by some popular TCP implementations . . . 10 | indications by some popular TCP implementations . . . 10 | |||
A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 10 | A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 10 | A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 11 | A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
A.5. Cisco IOS software . . . . . . . . . . . . . . . . . . . . 11 | A.5. Cisco IOS software . . . . . . . . . . . . . . . . . . . . 12 | |||
A.6. Microsoft Windows 2000, Service Pack 4 . . . . . . . . . . 11 | A.6. Microsoft Windows 2000, Service Pack 4 . . . . . . . . . . 12 | |||
A.7. Microsoft Windows 2008 . . . . . . . . . . . . . . . . . . 11 | A.7. Microsoft Windows 2008 . . . . . . . . . . . . . . . . . . 12 | |||
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-05 . . . . . . . 12 | B.1. Changes from draft-ietf-tcpm-urgent-data-06 . . . . . . . 12 | |||
B.2. Changes from draft-ietf-tcpm-urgent-data-04 . . . . . . . 12 | B.2. Changes from draft-ietf-tcpm-urgent-data-05 . . . . . . . 13 | |||
B.3. Changes from draft-ietf-tcpm-urgent-data-03 . . . . . . . 12 | B.3. Changes from draft-ietf-tcpm-urgent-data-04 . . . . . . . 13 | |||
B.4. Changes from draft-ietf-tcpm-urgent-data-02 . . . . . . . 12 | B.4. Changes from draft-ietf-tcpm-urgent-data-03 . . . . . . . 13 | |||
B.5. Changes from draft-ietf-tcpm-urgent-data-01 . . . . . . . 12 | B.5. Changes from draft-ietf-tcpm-urgent-data-02 . . . . . . . 13 | |||
B.6. Changes from draft-ietf-tcpm-urgent-data-00 . . . . . . . 12 | B.6. Changes from draft-ietf-tcpm-urgent-data-01 . . . . . . . 13 | |||
B.7. Changes from draft-gont-tcpm-urgent-data-01 . . . . . . . 13 | B.7. Changes from draft-ietf-tcpm-urgent-data-00 . . . . . . . 13 | |||
B.8. Changes from draft-gont-tcpm-urgent-data-01 . . . . . . . 13 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 | |||
reliability of TCP urgent indications in the current Internet. | reliability of TCP urgent indications in the current Internet. | |||
Given the above issues and potential interoperability issues with | ||||
respect to the currently common default mode operation, it is | ||||
strongly recommended that applications do not employ urgent | ||||
indications. Nevertheless, urgent indications are still retained as | ||||
a mandatory part of the TCP protocol to support the few legacy | ||||
applications that employ them. However, it is expected that even | ||||
these applications will have difficulties in environments with | ||||
middle-boxes. | ||||
Section 2 describes what the current IETF specifications state with | Section 2 describes what the current IETF specifications state with | |||
respect to TCP urgent indications. Section 3 describes how some | respect to TCP urgent indications. Section 3 describes how some | |||
current TCP implementations actually process TCP urgent indications. | current TCP implementations actually process TCP urgent indications. | |||
Section 4 updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 | Section 4 updates RFC 793 [RFC0793], RFC 1011 [RFC1011], and RFC 1122 | |||
[RFC1122], such that they accommodate current practice in processing | [RFC1122], such that they accommodate current practice in processing | |||
TCP urgent indications. Section 5 provides advice to to new | TCP urgent indications. Section 5 provides advice to to new | |||
applications employing TCP, with respect to the TCP urgent mechanism. | applications employing TCP, with respect to the TCP urgent mechanism. | |||
Section 6 provides advice to existing applications that use or rely | Section 6 provides advice to existing applications that use or rely | |||
on the TCP urgent mechanism. | on the TCP urgent mechanism. | |||
skipping to change at page 4, line 37 | skipping to change at page 4, line 46 | |||
"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 RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
2. Specification of the TCP urgent mechanism | 2. Specification of the TCP urgent mechanism | |||
2.1. Semantics of urgent indications | 2.1. Semantics of urgent indications | |||
TCP incorporates an "urgent mechanism" that allows the sending user | TCP incorporates an "urgent mechanism" that allows the sending user | |||
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 receiving | |||
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 was 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 that data is consumed by the TCP user. | TCP segment before that data is consumed by the TCP user. | |||
skipping to change at page 6, line 28 | skipping to change at page 6, line 41 | |||
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 | |||
implementations default to the semantics of the urgent pointer | implementations default to the semantics of the urgent pointer | |||
specified in Section 3.1 of RFC 793). | specified in Section 3.1 of RFC 793). | |||
Some operating systems provide a system-wide toggle to override this | Some operating systems provide a system-wide toggle to override this | |||
behavior, and interpret the semantics of the Urgent Pointer as | behavior, and interpret the semantics of the Urgent Pointer as | |||
clarified in RFC 1122. However, this system-wide toggle has been | clarified in RFC 1122. However, this system-wide toggle has been | |||
found to be inconsistent. For example, Linux provides the sysctl | found to be inconsistent. For example, Linux provides the sysctl | |||
"tcp_stdurg" (i.e., net.ivp4.tcp_stdurg) that, when set, supposedly | "tcp_stdurg" (i.e., net.ipv4.tcp_stdurg) that, when set, supposedly | |||
changes the system behavior to interpret the semantics of the TCP | changes the system behavior to interpret the semantics of the TCP | |||
Urgent Pointer as specified in RFC 1122. However, this sysctl | Urgent Pointer as specified in RFC 1122. However, this sysctl | |||
changes the semantics of the Urgent Pointer only for incoming | changes the semantics of the Urgent Pointer only for incoming | |||
segments, but not for outgoing segments. This means that if this | segments, but not for outgoing segments. This means that if this | |||
sysctl is set, an application might be unable to interoperate with | sysctl is set, an application might be unable to interoperate with | |||
itself if both the TCP sender and the TCP receiver are running on the | itself if both the TCP sender and the TCP receiver are running on the | |||
same host. | same host. | |||
3.3. Allowed length of urgent data | 3.3. Allowed length of urgent data | |||
skipping to change at page 7, line 25 | skipping to change at page 7, line 41 | |||
As a result of the publication of Network Intrusion Detection (NIDs) | As a result of the publication of Network Intrusion Detection (NIDs) | |||
evasion techniques based on TCP urgent indications [phrack], some | evasion techniques based on TCP urgent indications [phrack], some | |||
middle-boxes clear the urgent indications by clearing the URG flag | middle-boxes clear the urgent indications by clearing the URG flag | |||
and setting the Urgent Pointer to zero. This causes the "urgent | and setting the Urgent Pointer to zero. This causes the "urgent | |||
data" to become "in line" (that is, accessible by the read(2) call or | data" to become "in line" (that is, accessible by the read(2) call or | |||
the recv(2) call without the MSG_OOB flag) in the case of those TCP | the recv(2) call without the MSG_OOB flag) in the case of those TCP | |||
implementations that implement the urgent mechanism as out-of-band | implementations that implement the urgent mechanism as out-of-band | |||
data (as described in Section 3.1). An example of such a middle-box | data (as described in Section 3.1). An example of such a middle-box | |||
is the Cisco PIX firewall [Cisco-PIX]. This should discourage | is the Cisco PIX firewall [Cisco-PIX]. This should discourage | |||
applications from depending on urgent indications for their correct | applications from depending on urgent indications for their correct | |||
operation, as urgent indications may not be not reliable in the | operation, as urgent indications may not be reliable in the current | |||
current Internet. | Internet. | |||
4. Updating RFC 793, RFC 1011, and RFC 1122 | 4. Updating RFC 793, RFC 1011, and RFC 1122 | |||
Considering that as long as both the TCP sender and the TCP receiver | Considering that as long as both the TCP sender and the TCP receiver | |||
implement the same semantics for the Urgent Pointer there is no | implement the same semantics for the Urgent Pointer there is no | |||
functional difference in having the Urgent Pointer point to "the | functional difference in having the Urgent Pointer point to "the | |||
sequence number of the octet following the urgent data" vs. "the last | sequence number of the octet following the urgent data" vs. "the last | |||
octet of urgent data", and since all known implementations interpret | octet of urgent data", and since all known implementations interpret | |||
the semantics of the Urgent Pointer as pointing to "the sequence | the semantics of the Urgent Pointer as pointing to "the sequence | |||
number of the octet following the urgent data", we hereby update RFC | number of the octet following the urgent data", we hereby update RFC | |||
skipping to change at page 8, line 12 | skipping to change at page 8, line 24 | |||
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" is delivered inline, as | socket option, such that "urgent data" is delivered inline, as | |||
intended by the IETF specifications. | intended by the IETF specifications. | |||
Additionally, applications that still decide to use the urgent | ||||
mechanism need to be designed for correct operation even when the URG | ||||
flag is cleared by middleboxes. | ||||
7. Security Considerations | 7. Security Considerations | |||
Given that there are two different interpretations of the semantics | Multiple factors can affect the data flow that is actually delivered | |||
of the Urgent Pointer in current implementations (e.g., depending on | to an application when the TCP urgent mechanism is employed; namely, | |||
the value of the tcp_stdurg sysctl), and that middle-boxes (such as | the two possible interpretations of the semantics of the Urgent | |||
packet scrubbers) or the end-systems themselves could cause the | Pointer in current implementations (e.g., depending on the value of | |||
urgent data to be processed "in band", there exists ambiguity in how | the tcp_stdurg sysctl), the possible implementation of the urgent | |||
"urgent data" sent by a TCP will be processed by the intended | mechanism as an Out-Of-Band (OOB) facility (vs. in-band as intenteded | |||
recipient. This might make it difficult for a Network Intrusion | by the IETF specifications), and middle-boxes (such as packet | |||
Detection System (NIDS) to track the application-layer data | scrubbers) or the end-systems themselves that could cause the "urgent | |||
transferred to the destination system, and thus lead to false | data" to be processed "in band". This might make it difficult for a | |||
negatives or false positives in the NIDS [CPNI-TCP]. | Network Intrusion Detection System (NIDS) to track the application- | |||
layer data transferred to the destination system, and thus lead to | ||||
false negatives or false positives in the NIDS [CPNI-TCP] [phrack]. | ||||
Probably the best way to avoid the security implications of TCP | Probably the best way to avoid the security implications of TCP | |||
urgent data is to avoid having applications use the TCP urgent | urgent data is to avoid having applications use the TCP urgent | |||
mechanism altogether. Packet scrubbers could probably be configured | mechanism altogether. Packet scrubbers could probably be configured | |||
to clear the URG bit, and set the Urgent Pointer to zero. This would | to clear the URG bit, and set the Urgent Pointer to zero. This would | |||
basically cause the urgent data to be put "in band". However, this | basically cause the urgent data to be put "in band". However, this | |||
might cause interoperability problems or undesired behavior in the | might cause interoperability problems or undesired behavior in those | |||
applications running on top of TCP. | applications that rely on the TCP urgent mechanism, such as Telner | |||
[RFC0854] and FTP [RFC0959]. | ||||
8. IANA Considerations | 8. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
9. Acknowledgements | 9. Acknowledgements | |||
The authors of this document would like to thank (in alphabetical | The authors of this document would like to thank (in alphabetical | |||
order) David Borman, Wesley Eddy, John Heffner, Alfred Hoenes, Carlos | order) Jari Arkko, Ron Bonica, David Borman, Dave Cridland, Ralph | |||
Pignataro, Anantha Ramaiah, Joe Touch, Michael Welzl, Dan Wing, and | Droms, Wesley Eddy, John Heffner, Alfred Hoenes, Alexey Melnikov, | |||
Alexander Zimmermann for providing valuable feedback on earlier | Keith Moore, Carlos Pignataro, Tim Polk, Anantha Ramaiah, Joe Touch, | |||
versions of this document. | Michael Welzl, Dan Wing, and Alexander Zimmermann for providing | |||
valuable feedback on earlier versions of this document. | ||||
Additionally, Fernando would like to thank David Borman and Joe Touch | Additionally, Fernando would like to thank David Borman and Joe Touch | |||
for a fruitful discussion about TCP urgent mode at IETF 73 | for a fruitful discussion about TCP urgent mode at IETF 73 | |||
(Minneapolis). | (Minneapolis). | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
skipping to change at page 9, line 40 | skipping to change at page 10, line 14 | |||
asa70/command/reference/tz.html#wp1288756". | asa70/command/reference/tz.html#wp1288756". | |||
[FreeBSD] The FreeBSD project, "http://www.freebsd.org". | [FreeBSD] The FreeBSD project, "http://www.freebsd.org". | |||
[Linux] The Linux Project, "http://www.kernel.org". | [Linux] The Linux Project, "http://www.kernel.org". | |||
[NetBSD] The NetBSD project, "http://www.netbsd.org". | [NetBSD] The NetBSD project, "http://www.netbsd.org". | |||
[OpenBSD] The OpenBSD project, "http://www.openbsd.org". | [OpenBSD] The OpenBSD project, "http://www.openbsd.org". | |||
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol | ||||
Specification", STD 8, RFC 854, May 1983. | ||||
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", | ||||
STD 9, RFC 959, October 1985. | ||||
[UNPv1] Stevens, W., "UNIX Network Programming, Volume 1. | [UNPv1] Stevens, W., "UNIX Network Programming, Volume 1. | |||
Networking APIs: Sockets and XTI", Prentice Hall PTR , | Networking APIs: Sockets and XTI", Prentice Hall PTR , | |||
1997. | 1997. | |||
[Windows2000] | [Windows2000] | |||
Microsoft Windows 2000, "http://technet.microsoft.com/ | Microsoft Windows 2000, "http://technet.microsoft.com/ | |||
en-us/library/bb726981(printer).aspx". | en-us/library/bb726981(printer).aspx". | |||
[Windows95] | [Windows95] | |||
Microsoft Windows 95, | Microsoft Windows 95, | |||
skipping to change at page 12, line 19 | skipping to change at page 12, line 45 | |||
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-05 | B.1. Changes from draft-ietf-tcpm-urgent-data-06 | |||
o Addresses Jari Arkko's and Tim Polk's DISCUSSes, and various | ||||
COMMENTs by members of the IESG. | ||||
o Addresses IETF LC comments. | ||||
B.2. Changes from draft-ietf-tcpm-urgent-data-05 | ||||
o Draft resubmitted (with no changes) because it was close to the | o Draft resubmitted (with no changes) because it was close to the | |||
expiration day. | expiration day. | |||
B.2. Changes from draft-ietf-tcpm-urgent-data-04 | B.3. Changes from draft-ietf-tcpm-urgent-data-04 | |||
o Fixes grammar errors wrt the term "data" (thanks to David Borman, | o Fixes grammar errors wrt the term "data" (thanks to David Borman, | |||
once again ;-) ) | once again ;-) ) | |||
B.3. Changes from draft-ietf-tcpm-urgent-data-03 | B.4. 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.4. Changes from draft-ietf-tcpm-urgent-data-02 | B.5. 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.5. Changes from draft-ietf-tcpm-urgent-data-01 | B.6. 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.6. Changes from draft-ietf-tcpm-urgent-data-00 | B.7. 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.7. Changes from draft-gont-tcpm-urgent-data-01 | B.8. 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. 28 change blocks. | ||||
52 lines changed or deleted | 85 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |