An Acceptable Use Policy for New ICMP Types and Codes

There has been some recent concern expressed about a lack of clarity around when new message types and codes should be added to ICMP (including ICMPv4 and ICMPv6). We lay out a description of when (and when not) to move functionality into ICMP. This document is the result of discussions among ICMP experts within the Operations and Management (OPS) area's IP Diagnostics Technical Interest Group and concerns expressed by the OPS area leadership. Note that this document does not supercede the "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" , which specifies best practices and processes for the allocation of values in the IANA registries but does not describe the policies to be applied in the standards process. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

In this document, we describe an acceptable use policy for new ICMP message types and codes, and provide some background about the policy. In summary, any future message types added to ICMP should be limited to two broad categories: to inform a datagram's originator that a forwarding plane anomaly has been encountered downstream. The datagram originator must be able to determine whether or not the datagram was discarded by examining the ICMP message. to discover and convey dynamic information about a node (other than information usually carried in routing protocols), to discover and convey network-specific parameters, and to discover on-link routers and hosts. Normally, ICMP SHOULD NOT be used to implement a general-purpose routing or network management protocol. However, ICMP does have a role to play in conveying dynamic information about a network, which would belong in category 2 above.

This section provides a rough breakdown of existing message types according to the taxonomy described in at the time of publication. IPv4 forwarding plane anomaly reporting: Destination Unreachable Source Quench (Deprecated) Alternate Host Address (Deprecated) Time Exceeded Parameter Problem Datagram Conversion Error (Deprecated) ICMP messages utilized by experimental mobility protocols such as Seamoby IPv4 router or host discovery: Echo Reply Redirect Echo Router Advertisement Router Solicitation Timestamp Timestamp Reply Information Request (Deprecated) Information Reply (Deprecated) Address Mask Request (Deprecated) Address Mask Reply (Deprecated) Traceroute (Deprecated) Mobile Host Redirect (Deprecated) IPv6 Where-Are-You (Deprecated) IPv6 I-Am-Here (Deprecated) Mobile Registration Request (Deprecated) Mobile Registration Reply (Deprecated) Domain Name Request (Deprecated) Domain Name Reply (Deprecated) SKIP (Deprecated) Photuris ICMP messages utilized by experimental mobility protocols such as Seamoby Please note that some ICMP message types were formally deprecated by . IPv6 forwarding plane anomaly reporting: Destination Unreachable Packet Too Big Time Exceeded Parameter Problem ICMP messages utilized by experimental mobility protocols such as Seamoby IPv6 router or host discovery: Echo Request Echo Reply Multicast Listener Query Multicast Listener Report Multicast Listener Done Router Solicitation Router Advertisement Neighbor Solicitation Neighbor Advertisement Redirect Message Router Renumbering ICMP Node Information Query ICMP Node Information Response Inverse Neighbor Discovery Solicitation Message Inverse Neighbor Discovery Advertisement Message Version 2 Multicast Listener Report Home Agent Address Discovery Request Message Home Agent Address Discovery Reply Message Mobile Prefix Solicitation Mobile Prefix Advertisement Certification Path Solicitation Message Certification Path Advertisement Message ICMP messages utilized by experimental mobility protocols such as Seamoby Multicast Router Advertisement Multicast Router Solicitation Multicast Router Termination FMIPv6 Messages RPL Control Message

As mentioned in , using ICMP as a general-purpose routing or network management protocol is not advisable and SHOULD NOT be used that way. ICMP has a role in the Internet as an integral part of the IP layer; it is not as a routing protocol or as a transport protocol for other layers including routing information. From a more pragmatic perspective, some of the key characteristics of ICMP make it a less-than-ideal choice for a routing protocol. Those include that ICMP is frequently filtered, is not authenticated, is easily spoofed, and that specialist hardware processing of ICMP would disrupt the deployment of an ICMP-based routing or management protocol.

RPL, the IPv6 routing protocol for low-power and lossy networks (see ) uses ICMP as a transport. In this regard, it is an exception among the ICMP message types. Note that, although RPL is an IP routing protocol, it is not deployed on the general Internet; it is limited to specific, contained networks. This should be considered anomalous and is not a model for future ICMP message types. That is, ICMP is not intended as a transport for other protocols and SHOULD NOT be used in that way in future specifications. In particular, while it is adequate to use ICMP as a discovery protocol, it does not extend to full routing capabilities.

Some applications make use of ICMP error notifications, or even deliberately create anomalous conditions in order to elicit ICMP messages. These ICMP messages are then used to generate feedback to the higher layer. Some of these applications include some of the most widespread examples, such as PING, TRACEROUTE, and Path MTU Discovery (PMTUD). These uses are considered acceptable because they use existing ICMP message types and do not change ICMP functionality.

ICMP multi-part messages are specified in by defining an extension mechanism for selected ICMP messages. This mechanism addresses a fundamental problem in ICMP extensibility. An ICMP multi-part message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Some currently defined ICMP extensions include ICMP extensions for Multiprotocol Label Switching and ICMP extensions for interface and next-hop identification . Extensions to ICMP SHOULD follow .

Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 routers, IPv6-capable security gateways, and IPv6-capable firewalls normally support administrator configuration of how specific ICMPv6 message types are handled. By contrast, deployed IPv4 routers, IPv4-capable security gateways, and IPv4-capable firewalls are less likely to allow an administrator to configure how specific ICMPv4 message types are handled. So, at present, ICMPv6 messages usually have a higher probability of travelling end-to-end than ICMPv4 messages.

ICMP was originally intended to be a mechanism for gateways or destination hosts to report error conditions back to source hosts in ICMPv4; ICMPv6 is modeled after it. ICMP is also used to perform IP-layer functions, such as diagnostics (e.g., PING). ICMP is defined to be an integral part of IP and must be implemented by every IP module. This is true for ICMPv4 as an integral part of IPv4 (see the Introduction of ), and for ICMPv6 as an integral part of IPv6 (see Section 2 of ). When first defined, ICMP messages were thought of as IP messages that didn't carry any higher-layer data. It could be conjectured that the term "control" was used because ICMP messages were not "data" messages. The word "control" in the protocol name did not describe ICMP's function (i.e., it did not "control" the Internet); rather, it was used to communicate about the control functions in the Internet. For example, even though ICMP included a redirect message type that affects routing behavior in the context of a LAN segment, it was not and is not used as a generic routing protocol.

This document describes a high-level policy for adding ICMP types and codes. While special attention must be paid to the security implications of any particular new ICMP type or code, this recommendation presents no new security considerations. From a security perspective, ICMP plays a part in the Photuris protocol. But more generally, ICMP is not a secure protocol and does not include features to be used to discover network security parameters or to report on network security anomalies in the forwarding plane. Additionally, new ICMP functionality (e.g., ICMP extensions, or new ICMP types or codes) needs to consider potential ways that ICMP can be abused (e.g., Smurf IP DoS).

This document was originally proposed by, and received substantial review and suggestions from, Ron Bonica. Discussions with Pascal Thubert helped clarify the history of RPL's use of ICMP. We are very grateful for the review, feedback, and comments from Ran Atkinson, Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much improved document.