Formally Deprecating Some ICMPv4 Message Types
Extracted elements (20)
ICMPv4 Information Request/Reply (Types 15/16) and Address Mask Request/Reply (Types 17/18) are deprecated because DHCP has fully superseded their host-configuration role. Maintaining these types in active registries creates unnecessary ambiguity without providing any functional benefit.
Many of the deprecated ICMPv4 types (32–36, 39) were experimental or early-stage proposals that were never widely implemented or deployed. Their formal deprecation cleans up the IANA registry and reduces the surface area that firewall and filtering rules must consider.
RFC 1788 (ICMP Domain Name Messages, Types 37/38) is obsoleted by this document and its status is changed to Historic. RFC 792 and RFC 950 are updated but not obsoleted, as other portions of those documents remain current.
Address Mask Reply (ICMPv4 Type 18), specified in RFC 950, was meant to provide a means to obtain the subnet mask. It is formally deprecated as DHCP has superseded it for host configuration.
Address Mask Request (ICMPv4 Type 17), specified in RFC 950, was meant to provide a means to obtain the subnet mask. It is formally deprecated as DHCP has superseded it for host configuration.
Alternate Host Address (ICMPv4 Type 6) is formally deprecated. No publicly available information about this message type exists, and it has no known deployment.
Datagram Conversion Error (ICMPv4 Type 31) was originally meant to report conversion errors in the TP/IX (RFC 1475) protocol. Since TP/IX was never widely implemented and RFC 1475 is Historic, this type is deprecated.
Domain Name Reply (ICMPv4 Type 38), specified in RFC 1788, was used for learning the Fully Qualified Domain Name associated with an IP address. It was never widely deployed or implemented and is deprecated.
Domain Name Request (ICMPv4 Type 37), specified in RFC 1788, was used for learning the Fully Qualified Domain Name associated with an IP address. It was never widely deployed or implemented and is deprecated.
Information Reply (ICMPv4 Type 16), specified in RFC 792, is formally deprecated. Other mechanisms such as DHCP (RFC 2131) have superseded this message type for the purpose of host configuration.
Information Request (ICMPv4 Type 15), specified in RFC 792, is formally deprecated. Other mechanisms such as DHCP (RFC 2131) have superseded this message type for the purpose of host configuration.
IPv6 I-Am-Here (ICMPv4 Type 34) was originally specified for identification of adjacent IPv6 nodes. It was never widely deployed or implemented and is deprecated.
IPv6 Where-Are-You (ICMPv4 Type 33) was originally specified for the purpose of identification of adjacent IPv6 nodes. It was never widely deployed or implemented and is deprecated.
Mobile Host Redirect (ICMPv4 Type 32) was originally specified as part of an experimental protocol for IP Mobile Hosts. It was never widely implemented or deployed.
Mobile Registration Reply (ICMPv4 Type 36) was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes. It was never widely deployed or implemented and is deprecated.
Mobile Registration Request (ICMPv4 Type 35) was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes. It was never widely deployed or implemented and is deprecated.
SKIP (ICMPv4 Type 39) was originally specified for informing supported capabilities in the SKIP protocol. It was never widely deployed or implemented and is deprecated.
Traceroute (ICMPv4 Type 30), specified in RFC 1393, was meant to provide an alternative means to discover the path to a destination system. It was never widely deployed; RFC 1393 has been changed to Historic by RFC 6814.
This document formally deprecates 15 ICMPv4 message types in the IANA 'Internet Control Message Protocol (ICMP) Parameters' registry, requesting they be marked as deprecated: Types 6, 15, 16, 17, 18, 30, 31, 32, 33, 34, 35, 36, 37, 38, and 39.
This document does not modify the security properties of the deprecated ICMPv4 message types, but formally deprecating them provides a normative basis for filtering these packets at network boundaries.