Formally Deprecating Some ICMPv4 Message Types

A number of ICMPv4 message types have been specified over the years. A number of these message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, "cleaning up" the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic. discusses each of the obsoleted ICMPv4 messages. requests the RFC Editor to change the status of RFC 1788 to Historic.

The following subsections discuss the details of those ICMPv4 message types being deprecated, based on publicly available information and/or information provided by the requester of the corresponding assignment.

There is no publicly available information about this message type.

This message type is specified in . However, other mechanisms (such as DHCP ) have superseded this message type for the purpose of host configuration.

This message type is specified in and was meant to provide a means to obtain the subnet mask. However, other mechanisms (such as DHCP ) have superseded this message type for the purpose of host configuration.

This message type is specified in and was meant to provide an alternative means to discover the path to a destination system. This message type has never been widely deployed. The status of has been changed to Historic by , and the corresponding option this message type relies on (Traceroute, Type 82) has been formally obsoleted by .

This message type was originally meant to report conversion errors in the TP/IX protocol. However, TP/IX was never widely implemented or deployed, and the status of is Historic.

This message type was originally specified as part of an experimental protocol for IP Mobile Hosts . However, it was never widely implemented or deployed.

This message type was originally specified in for the purpose of identification of adjacent IPv6 nodes. It was never widely deployed or implemented.

This message type was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes . It was never widely deployed or implemented.

This message type was originally specified in for the purpose of learning the Fully Qualified Domain Name associated with an IP address. This message type was never widely deployed or implemented.

This message type was originally specified in for informing supported capabilities in the SKIP protocol. This message type was never widely deployed or implemented.

The "Internet Control Message Protocol (ICMP) Parameters" registry contains the list of the currently assigned ICMP message Types. This document formally deprecates the following ICMP message Types and requests IANA to mark them as such in the corresponding registry : Alternate Host Address (Type 6) Information Request (Type 15) Information Reply (Type 16) Address Mask Request (Type 17) Address Mask Reply (Type 18) Traceroute (Type 30) Datagram Conversion Error (Type 31) Mobile Host Redirect (Type 32) IPv6 Where-Are-You (Type 33) IPv6 I-Am-Here (Type 34) Mobile Registration Request (Type 35) Mobile Registration Reply (Type 36) Domain Name Request (Type 37) Domain Name Reply (Type 38) SKIP (Type 39) The ICMPv4 Source Quench Message (Type 4) has already been deprecated by .

This document requests the RFC Editor to change the status of to Historic. Both and already have a status of Historic. The status of other RFCs (such as and ) is not changed since other parts of these documents are still current.

This document does not modify the security properties of the ICMPv4 message types being deprecated. However, formally deprecating these message types serves as a basis for, e.g., filtering these packets.

The authors would like to thank Ron Bonica and Joel Halpern for their guidance.