draft-ietf-tsvwg-source-quench-06.txt   rfc6633.txt 
Transport Area Working Group (tsvwg) F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft UTN-FRH / SI6 Networks Request for Comments: 6633 UTN-FRH / SI6 Networks
Updates: 792, 1122, 1812 February 25, 2012 Updates: 792, 1122, 1812 May 2012
(if approved) Category: Standards Track
Intended status: Standards Track ISSN: 2070-1721
Expires: August 28, 2012
Deprecation of ICMP Source Quench messages Deprecation of ICMP Source Quench Messages
draft-ietf-tsvwg-source-quench-06.txt
Abstract Abstract
This document formally deprecates the use of ICMP Source Quench This document formally deprecates the use of ICMP Source Quench
messages by transport protocols, formally updating RFC 792, RFC 1122, messages by transport protocols, formally updating RFC 792, RFC 1122,
and RFC 1812. and RFC 1812.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 28, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6633.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3 2. ICMP Source Quench Messages .....................................3
3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 1122 ...............................................3
4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4 4. Updating RFC 1812 ...............................................4
5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5 5. Clarification for UDP, SCTP, and DCCP ...........................4
6. General Advice to Transport Protocols . . . . . . . . . . . . . 5 6. General Advice to Transport Protocols ...........................4
7. Recommendation Regarding RFC 1016 . . . . . . . . . . . . . . . 5 7. Recommendation Regarding RFC 1016 ...............................5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations .........................................5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations .............................................5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements ...............................................5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References .....................................................6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References ......................................6
11.2. Informative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References ....................................7
Appendix A. Survey of support of ICMP Source Quench in some Appendix A. Survey of Support of ICMP Source Quench in Some
popular TCP/IP implementations . . . . . . . . . . . . 8 Popular TCP/IP Implementations ........................8
Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . . 8
B.1. Changes from draft-ietf-tsvwg-source-quench-05 . . . . . . 8
B.2. Changes from draft-ietf-tsvwg-source-quench-04 . . . . . . 8
B.3. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8
B.4. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 9
B.5. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 9
B.6. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 9
B.7. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 9
B.8. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The ICMP specification [RFC0792] defined the ICMP Source Quench The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant as a mechanism for message (type 4, code 0), which was meant as a mechanism for
congestion control. ICMP Source Quench has been known to be an congestion control. ICMP Source Quench has been known to be an
ineffective (and unfair) antidote for congestion, and generation of ineffective (and unfair) antidote for congestion, and generation of
ICMP Source Quench messages by routers has been formally deprecated ICMP Source Quench messages by routers has been formally deprecated
by [RFC1812] since 1995. However, reaction to ICMP Source Quench by [RFC1812] since 1995. However, reaction to ICMP Source Quench
messages in transport protocols has never been formally deprecated. messages in transport protocols has never been formally deprecated.
This document formally deprecates reaction to ICMP Source Quench This document formally deprecates reaction to ICMP Source Quench
messages by transport protocols such as TCP, formally updating messages by transport protocols such as TCP [RFC0793], formally
[RFC0792], [RFC1122], and [RFC1812]. Additionally, it provides updating [RFC0792], [RFC1122], and [RFC1812]. Additionally, it
recommendation against the implementation of [RFC1016]. The provides a recommendation against the implementation of [RFC1016].
rationale for these specification updates is: The rationale for these specification updates is as follows:
o Processing of ICMP Source Quench messages by routers has been o Processing of ICMP Source Quench messages by routers has been
deprecated for more than 20 years [RFC1812]. deprecated for nearly 17 years [RFC1812].
o Virtually all popular host implementations have removed support o Virtually all popular host implementations have removed support
for ICMP Source Quench messages since (at least) 2005 [RFC5927]. for ICMP Source Quench messages since (at least) 2005 [RFC5927].
o Widespread deployment of ICMP filtering makes it impossible to o Widespread deployment of ICMP filtering makes it impossible to
rely on ICMP Source Quench messages for congestion control. rely on ICMP Source Quench messages for congestion control.
o The IETF has moved away from ICMP Source Quench messages for o The IETF has moved away from ICMP Source Quench messages for
congestion control (note e.g. the development of ECN [RFC3168], congestion control (e.g., note the development of Explicit
and the fact that ICMPv6 [RFC4443] does not even specify a Source Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6
Quench message). [RFC4443] does not even specify a Source Quench message).
ICMP Source Quench messages are not normally seen in the ICMP Source Quench messages are not normally seen in the
deployed Internet and were considered rare at least as far back deployed Internet and were considered rare at least as far back
as 1994. [Floyd1994] as 1994 [Floyd1994].
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 RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
2. ICMP Source Quench messages 2. ICMP Source Quench Messages
The ICMP specification [RFC0792] defined the ICMP Source Quench The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant to provide a mechanism for message (type 4, code 0), which was meant to provide a mechanism for
congestion control. The Host Requirements RFC [RFC1122] stated in congestion control. The Host Requirements RFC [RFC1122] stated in
Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages
by slowing transmission on the connection, and further added that the by slowing transmission on the connection, and further added that the
RECOMMENDED procedure was to put the corresponding connection in the RECOMMENDED procedure was to put the corresponding connection in the
slow-start phase of TCP's congestion control algorithm [RFC5681]. slow-start phase of TCP's congestion control algorithm [RFC5681].
[RFC1812] noted that research suggested that ICMP Source Quench was [RFC1812] noted that research suggested that ICMP Source Quench was
an ineffective (and unfair) antidote for congestion, and formally an ineffective (and unfair) antidote for congestion, and formally
deprecated the generation of ICMP Source Quench messages by routers, deprecated the generation of ICMP Source Quench messages by routers,
stating that routers SHOULD NOT send ICMP Source Quench messages in stating that routers SHOULD NOT send ICMP Source Quench messages in
response to congestion. response to congestion.
[RFC5927] discussed the use of ICMP Source Quench messages for [RFC5927] discussed the use of ICMP Source Quench messages for
performing "blind throughput-reduction" attacks, and noted that most performing "blind throughput-reduction" attacks, and noted that most
TCP implementations silently ignore ICMP Source Quench messages. TCP implementations silently ignore ICMP Source Quench messages.
We note that TCP implements its own congestion control mechanisms We note that TCP implements its own congestion control mechanisms
[RFC5681] [RFC3168], that do not depend on ICMP Source Quench [RFC5681] [RFC3168], which do not depend on ICMP Source Quench
messages. messages.
It is interesting to note that ICMPv6 [RFC4443] does not specify a It is interesting to note that ICMPv6 [RFC4443] does not specify a
"Source Quench" message. Source Quench message.
3. Updating RFC 1122 3. Updating RFC 1122
This document hereby updates Section 3.2.2.3 of [RFC1122] as follows: This document hereby updates Section 3.2.2.3 of [RFC1122] as follows:
A host MUST NOT send ICMP Source Quench messages. A host MUST NOT send ICMP Source Quench messages.
If a Source Quench message is received, the IP layer MAY silently If a Source Quench message is received, the IP layer MAY silently
discard it. discard it.
skipping to change at page 4, line 43 skipping to change at page 4, line 12
TCP MUST silently discard any received ICMP Source Quench TCP MUST silently discard any received ICMP Source Quench
messages. messages.
The consensus of the TSV WG was that there are no valid reasons for a The consensus of the TSV WG was that there are no valid reasons for a
host to generate or react to an ICMP Source Quench message in the host to generate or react to an ICMP Source Quench message in the
current Internet. The recommendation that a sender "MUST NOT" send current Internet. The recommendation that a sender "MUST NOT" send
an ICMP Source Quench message is because there is no known valid an ICMP Source Quench message is because there is no known valid
reason for a host to generate this message. The only known impact of reason for a host to generate this message. The only known impact of
a sender ignoring this requirement is that it may necessarily consume a sender ignoring this requirement is that it may necessarily consume
network and endpoint resources. Discarding ICMP Source Quench network and endpoint resources. Discarding ICMP Source Quench
messages at the internet-layer (rather than at the transport layer) messages at the Internet layer (rather than at the transport layer)
is a performance optimization that is permitted by this update. is a performance optimization that is permitted by this update.
4. Updating RFC 1812 4. Updating RFC 1812
This document hereby updates Section 4.3.3.3 of [RFC1812] as follows: This document hereby updates Section 4.3.3.3 of [RFC1812] as follows:
A router MUST ignore any ICMP Source Quench messages it receives. A router MUST ignore any ICMP Source Quench messages it receives.
The consensus of the TSV WG was that there are no valid reasons for a The consensus of the TSV WG was that there are no valid reasons for a
router to react to ICMP Source Quench messages in the current router to react to ICMP Source Quench messages in the current
Internet. Internet.
5. Clarification for UDP, SCTP, and DCCP 5. Clarification for UDP, SCTP, and DCCP
UDP did not explicitly specify support for ICMP Source Quench UDP [RFC0768] did not explicitly specify support for ICMP Source
messages. Hereby we clarify that UDP end-points MUST silently Quench messages. Hereby, we clarify that UDP endpoints MUST silently
discard received ICMP Source Quench messages. discard received ICMP Source Quench messages.
It is understood that SCTP and DCCP did not specify support for It is understood that SCTP [RFC4960] and DCCP [RFC4340] did not
processing received ICMP Source Quench messages. Hereby we clarify specify support for processing received ICMP Source Quench messages.
that DCCP and SCTP end-points MUST silently discard received ICMP Hereby, we clarify that DCCP and SCTP endpoints MUST silently discard
Source Quench messages. received ICMP Source Quench messages.
6. General Advice to Transport Protocols 6. General Advice to Transport Protocols
If a Source Quench message is received by any other transport- If a Source Quench message is received by any other transport-
protocol instance, it MUST be silently ignored. protocol instance, it MUST be silently ignored.
The TSV WG is not aware of any use that requires processing of these The TSV WG is not aware of any mechanism that requires processing of
messages, and therefore expects other transports to follow the these messages and therefore expects other transports to follow the
recommendations in Section 3. Note that for IETF-specified recommendations in Section 3. Note that since generation of ICMP
transports, this document formally deprecates reaction to ICMP Source Source Quench messages has been deprecated for many years, and since
Quench messages, and that generation of ICMP Source Quench messages this document additionally deprecates reaction to ICMP Source Quench
has been deprecated for both hosts and routers. Therefore, future messages by IETF-specified transports, future applications cannot
applications can not expect to receive these messages. expect to receive these messages.
7. Recommendation Regarding RFC 1016 7. Recommendation Regarding RFC 1016
RFC 1016 [RFC1016] described an experimental approach to ICMP Source [RFC1016] describes an experimental approach to the handling of ICMP
Quench message handling in hosts that was being thought about in Source Quench messages in hosts that was considered in 1987. Even
1987. The IETF notes that RFC 1016 has never been on the IETF though RFC 1016 has never been on the IETF Standards Track, for
standards-track, but for clarity and avoidance of doubt, we note that clarity and avoidance of doubt we note that the approach described in
the approach described in RFC 1016 [RFC1016] MUST NOT be implemented. [RFC1016] MUST NOT be implemented.
8. Security Considerations 8. Security Considerations
ICMP Source Quench messages could be leveraged for performing blind ICMP Source Quench messages could be leveraged for performing blind
throughput-reduction attacks against TCP and similar protocols. This throughput-reduction attacks against TCP and similar protocols. This
attack vector, along with possible countermeasures, has been attack vector, along with possible countermeasures, has been
discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently
ignoring ICMP Source Quench messages, as specified in this document, ignoring ICMP Source Quench messages, as specified in this document,
eliminates the aforementioned attack vector. eliminates the aforementioned attack vector.
skipping to change at page 6, line 20 skipping to change at page 5, line 35
TCP implementations already silently ignore ICMP Source Quench TCP implementations already silently ignore ICMP Source Quench
messages. This is also the case for SCTP and DCCP implementations. messages. This is also the case for SCTP and DCCP implementations.
Hosts, security gateways, and firewalls MUST silently discard Hosts, security gateways, and firewalls MUST silently discard
received ICMP Source Quench packets and SHOULD log such drops as a received ICMP Source Quench packets and SHOULD log such drops as a
security fault with at least minimal details (IP Source Address, IP security fault with at least minimal details (IP Source Address, IP
Destination Address, ICMP message type, and date/time the packet was Destination Address, ICMP message type, and date/time the packet was
seen). seen).
We note that security devices such as the Snort Network Intrusion We note that security devices such as the Snort Network Intrusion
Detection System (NIDS) has logged ICMP Source Quench messages as Detection System (NIDS) have logged ICMP Source Quench messages as
such for more than ten years. [Anderson2002]. such for more than ten years [Anderson2002].
9. IANA Considerations 9. IANA Considerations
IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated" IANA has marked ICMP type 4 (Source Quench) as "Deprecated" in the
in de ICMP Parameters registry [ICMPPARREG] with a reference to this ICMP Parameters registry [ICMPPARREG] with a reference to this
document. document.
10. Acknowledgements 10. Acknowledgements
The author of this document would like to thank Ran Atkinson, who The author of this document would like to thank Ran Atkinson, who
contributed text that was incorporated into this document and also contributed text that was incorporated into this document and also
provided valuable feedback on earlier versions of this document. provided valuable feedback on earlier versions of this document.
The author of this document would like to thank (in alphabetical The author of this document would like to thank (in alphabetical
order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio
De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh
Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk, Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk,
Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko, Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko,
for providing valuable feedback on earlier versions of this document. for providing valuable feedback on earlier versions of this document.
This document has also benefited from discussions within the TCPM
Working Group while working on [RFC5927].
This document has benefited from discussions within the TCPM Working Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and
Group while working on [RFC5927]. Guillermo Gont for their love and support.
Fernando Gont's attendance to IETF meetings was supported by ISOC's
"Fellowship to the IETF" program.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
RFC 792, September 1981. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0792] Postel, J., "Internet Control Message Protocol",
RFC 793, September 1981. STD 5, RFC 792, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Communication Layers", STD 3, RFC 1122, October 1989. RFC 793, September 1981.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1122] Braden, R., "Requirements for Internet Hosts -
RFC 1812, June 1995. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 1812, June 1995.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Control", RFC 5681, September 2009. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP
Congestion Control", RFC 5681, September 2009.
11.2. Informative References 11.2. Informative References
[Anderson2002] [Anderson2002] Anderson, D., Fong, M., and A. Valdes, "Heterogeneous
Anderson, D., Fong, M., and A. Valdes, "Heterogeneous Sensor Correlation: A Case Study of Live Traffic
Sensor Correlation: A Case Study of Live Traffic Analysis", Proceedings of the 3rd Annual IEEE
Analysis", Proceedings of the 3rd Annual IEEE Information Information Assurance Workshop New York, NY, USA,
Assurance Workshop New York, NY, USA, 2002. 2002.
[CPNI-TCP] [CPNI-TCP] CPNI, "Security Assessment of the Transmission
CPNI, "Security Assessment of the Transmission Control Control Protocol (TCP)", 2009,
Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ <http://www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf>. tn-03-09-security-assessment-TCP.pdf>.
[Floyd1994] [Floyd1994] Floyd, S., "TCP and Explicit Congestion
Floyd, S., "TCP and Explicit Congestion Notification", ACM Notification", ACM CCR New York, NY, Volume 24,
CCR Volume 24, Issue 5, 1994. Issue 5, October 1994.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, <http://www.freebsd.org>.
[ICMPPARREG] [ICMPPARREG] IANA, "Internet Control Message Protocol (ICMP)
Internet Control Message Protocol (ICMP) Parameters, Parameters",
"http://www.iana.org/assignments/icmp-parameters". <http://www.iana.org/assignments/icmp-parameters>.
[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>.
[OpenSolaris] [OpenSolaris] OpenSolaris, <http://www.opensolaris.org>.
OpenSolaris, "http://www.opensolaris.org".
[RFC1016] Prue, W. and J. Postel, "Something a host could do with [RFC1016] Prue, W. and J. Postel, "Something a host could do
source quench: The Source Quench Introduced Delay with source quench: The Source Quench Introduced
(SQuID)", RFC 1016, July 1987. Delay (SQuID)", RFC 1016, July 1987.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
of Explicit Congestion Notification (ECN) to IP", Addition of Explicit Congestion Notification (ECN) to
RFC 3168, September 2001. IP", RFC 3168, September 2001.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet
Message Protocol (ICMPv6) for the Internet Protocol Control Message Protocol (ICMPv6) for the Internet
Version 6 (IPv6) Specification", RFC 4443, March 2006. Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
July 2010.
Appendix A. Survey of support of ICMP Source Quench in some popular Appendix A. Survey of Support of ICMP Source Quench in Some Popular
TCP/IP implementations TCP/IP Implementations
A large number of implementations completely ignore ICMP Source A large number of implementations completely ignore ICMP Source
Quench messages meant for TCP connections. This behavior has been Quench messages meant for TCP connections. This behavior has been
implemented in, at least, Linux [Linux] since 2004, and in FreeBSD implemented in, at least, Linux [Linux] since 2004, and in FreeBSD
[FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since
2005. Additionally, OpenSolaris [OpenSolaris] has always shipped 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped
with support for ICMP Source Quench messages disabled. with support for ICMP Source Quench messages disabled.
Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an
RFC)
B.1. Changes from draft-ietf-tsvwg-source-quench-05
o Fixes minor writeo in Section 7.
B.2. Changes from draft-ietf-tsvwg-source-quench-04
o Removes request to move RFC 1016 to "Historic" status.
o Updates the Security Considerations section.
B.3. Changes from draft-ietf-tsvwg-source-quench-03
o Added 'Obsoletes' metadata, and moved the reference to [RFC1016]
from the 'Normative References' to the 'Informative References'.
B.4. Changes from draft-ietf-tsvwg-source-quench-02
o Clarifies the requirements language.
B.5. Changes from draft-ietf-tsvwg-source-quench-01
o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in
response of feedback from Scott Bradner and the TSV WG.
B.6. Changes from draft-ietf-tsvwg-source-quench-00
o Discusses the motivation for deprecating ICMP Source Quench
messages (as suggested by Anantha Ramaiah).
o Incorporates IANA considerations such that ICMP Source Quench
messages are deprecated in the corresponding registry.
B.7. Changes from draft-gont-tsvwg-source-quench-01
o Addresses nits and editorial changes suggested by Gorry Fairhurst.
o Added the status of Solaris and OpenSolaris to Appendix A.
o Document resubmitted as draft-ietf.
B.8. Changes from draft-gont-tsvwg-source-quench-00
o This revision reflects the recent discussion about ICMP Source
Quench messages on the tsvwg mailing-list. A detailed list of the
changes is available at:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html
Author's Address Author's Address
Fernando Gont Fernando Gont
UTN-FRH / SI6 Networks UTN-FRH / SI6 Networks
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: fgont@si6networks.com EMail: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
 End of changes. 47 change blocks. 
183 lines changed or deleted 132 lines changed or added

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