Deprecation of ICMP Source Quench Messages
updates
Extracted elements (16)
ICMP Source Quench (type 4, code 0) was originally specified in RFC 792 as a congestion control mechanism, but research showed it to be ineffective and unfair. Router generation was deprecated by RFC 1812 in 1995, virtually all popular implementations had removed support by 2005, and ICMPv6 omitted Source Quench entirely — making continued transport-layer reaction both unnecessary and a security risk.
ICMPv6 (RFC 4443) does not specify a Source Quench message at all, reflecting the IETF's direction away from this mechanism. The development of Explicit Congestion Notification (ECN, RFC 3168) provides a modern, effective alternative for congestion signaling.
A survey of popular TCP/IP implementations shows that Linux (since 2004), FreeBSD, NetBSD, OpenBSD, and Solaris 10 (since 2005) have all removed or disabled support for ICMP Source Quench messages, confirming the practical obsolescence of the feature prior to formal deprecation.
This document updates RFC 792 (ICMP specification), RFC 1122 (Host Requirements), and RFC 1812 (Router Requirements) to formally deprecate both generation and reaction to ICMP Source Quench messages across all transport protocols.
A host MUST NOT send ICMP Source Quench messages. There is no known valid reason for a host to generate this message, and sending it unnecessarily consumes network and endpoint resources.
A router MUST ignore any ICMP Source Quench messages it receives. This updates RFC 1812 Section 4.3.3.3; there are no valid reasons for a router to react to these messages in the current Internet.
DCCP and SCTP endpoints MUST silently discard received ICMP Source Quench messages. Neither protocol specified support for processing these messages, and this document provides the explicit clarification.
Hosts, security gateways, and firewalls MUST silently discard received ICMP Source Quench packets and SHOULD log such drops as a security fault with at least minimal details: IP Source Address, IP Destination Address, ICMP message type, and date/time the packet was seen.
If a Source Quench message is received by any other transport-protocol instance, it MUST be silently ignored. Future applications cannot expect to receive these messages given the long-standing deprecation of their generation.
If a Source Quench message is received, the IP layer MAY silently discard it. Discarding at the IP layer rather than the transport layer is a permitted performance optimization.
TCP MUST silently discard any received ICMP Source Quench messages. This updates RFC 1122 Section 4.2.3.9, which previously required TCP to react by slowing transmission.
The experimental Source Quench Introduced Delay (SQuID) approach described in RFC 1016 MUST NOT be implemented. Although RFC 1016 was never on the IETF Standards Track, this document explicitly prohibits it for clarity and avoidance of doubt.
UDP endpoints MUST silently discard received ICMP Source Quench messages. UDP never explicitly specified support for these messages, and this document clarifies the expected behavior.
ICMP Source Quench message is type 4, code 0, originally intended as a congestion signal from routers to hosts. RFC 1122 had required hosts to react by slowing transmission and entering TCP slow-start. This document deprecates both generation and reaction.
IANA has marked ICMP type 4 (Source Quench) as 'Deprecated' in the ICMP Parameters registry, with a reference to this document. No new registry entries are created.
ICMP Source Quench messages can be leveraged for 'blind throughput-reduction' attacks against TCP and similar protocols, as documented in RFC 5927. Silently ignoring all Source Quench messages, as mandated by this document, eliminates this attack vector.