| Internet-Draft | ICMP Operational Experience | June 2024 |
| Bonica, et al. | Expires 21 December 2024 | [Page] |
The Internet Control Message Protocol (ICMP) can be used to exchange control information between hosts. This document summarizes ICMP standards and operational experience. The purpose of this document is to be used as a reference. A document that mentions ICMP can reference this document rather than repeating portions of its content.¶
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 Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 December 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Internet Control Message Protocol (ICMP) can be used to exchange control information between hosts. ICMPv4 [RFC0792] exchanges control information between IPv4 [RFC0791] hosts while ICMPv6 [RFC4443] exchanges control information between IPv6 [RFC8200] hosts.¶
This document summarizes ICMP standards and operational experience. The purpose of this document is to be used as a reference. A document that mentions ICMP can reference this document rather than repeating portions of its content.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
[RFC1122] and [RFC4443] make a distintion between ICMP error messages and ICMP information messages. An ICMP error messages indicates that a downstream node recieved a packet that it could not process. [RFC0792] refers to the unprocessed packet as the "original data datagram", while [RFC4443] refers to the unprocessed packet as the "invoking packet". In this document, we will adopt [RFC4443] terminology and call the unprocessed packet the "invoking packet".¶
Having received an invoking packet, the downstream node can send an ICMP error message to its originator. The ICMP error message indicates why the packet could not be processed. It also includes as much of the invoking packet as possible, without violating the ICMP message length limitations mentioned in (Section 8.4).¶
In ICMPv6, error messages are identified as such by a zero in the high-order bit of their message Type field values. Thus, ICMPv6 error messages have message types from 0 to 127. ICMPv6 informational messages have message types from 128 to 255.¶
In ICMPv4, error messages cannot be identified as such by a zero in the high-order bit of their message Type field values.¶
The Internet Assigned Numbers Authority (IANA) maintains one registy of ICMPv4 message types [V4MSG] and another registry of ICMPv6 message types [V6MSG]. Many ICMPv4 message types have been deprecated.¶
According to [RFC1122] and [RFC4443], when a node receives an ICMP error message, it must examine the message to determine:¶
whether the invoking packet originated on the local node¶
which local application or transport-layer protocol originated the invoking packet¶
If the invoking packet originated on the local node, the ICMP error message must be delivered to the application or transport-layer prototcol that originated it (if possible). If the originating transport-layer protocol was the User Datagram Protocol (UDP) [RFC0768], UDP must, in turn, deliver the ICMP error message to the application that caused the invoking packet to be sent.¶
When a node receives an ICMP information message, the message must be delivered to the application that caused it to be sent (if possible).¶
According to [RFC1122], if an ICMPv4 message of unknown type is received, it must be silently discarded.¶
According to [RFC4443], if an ICMPv6 error message of unknown type is received, it must be passed to the upper-layer process that originated the invoking packet (if possible). However, if an ICMP informatonal message of unknown type is received, it must be silently discarded.¶
According to [RFC1122], an ICMPv4 error message must not be sent as the result of receiving:¶
an ICMP error message¶
a datagram destined to an IP broadcast or IP multicast address¶
a datagram sent as a link-layer broadcast¶
a non-initial fragment¶
a datagram whose source address does not define a single host (e.g., a zero address, a broadcast address, a multicast address)¶
According to [RFC4443], an ICMPv4 error message must not be sent as the result of receiving:¶
An ICMPv6 error message¶
An ICMPv6 redirect message¶
A packet destined to an IPv6 multicast address.¶
A packet sent as a link-layer multicast¶
A packet sent as a link-layer broadcast¶
A packet whose source address does not uniquely identify a single node e.g., the IPv6 Unspecified Address, an IPv6 multicast address, or an address known by the ICMP message originator to be an IPv6 anycast address)¶
The following are exceptions to the IPv6 multicast, link-layer multicast, and link_layer broadcast rules above:¶
Some ICMP messages are extensible [RFC4884]. However, the extension header MUST not cause the ICMP message to violate the length restrictions mentioned below. IANA maintains a registry of ICMP Extension Object Classes and Class Sub-types.¶
[RFC7279] defines accpetable uses for ICMP. The following are acceptable uses:¶
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 the second catagory, above.¶
The following management applications rely on ICMP:¶
ICMP messages can be lost in transport. Therefore, the originator of an ICMP message cannot rely on the message arriving at its intended destination.¶
As per [RFC1812] and [RFC4443], nodes must rate limit ICMP messages that they originate. Neither RFC specifies how strict that rate limit must be. However, the rate limit MUST be strict enough to prevent a node from congesting one of its own interfaces with outbound ICMP messages.¶
ICMP messages are easily forged. [RFC5927] describes how forged ICMP messages can be used to attack TCP [RFC0793]. It also decribes mitigations against these attacks.¶
As per [RFC1812], an ICMPv4 message must not exceed 576 bytes. [RFC4443] specifies no limit for ICMPv6 messages. However, to avoid fragmentation, ICMPv6 messages SHOULD not exceed the IPv6 minimum required MTU [RFC8200] (i.e., 1280 bytes).¶
[RFC1812] offers the following guidance regarding ICMPv4 source address selection:¶
Except where this document specifies otherwise, the IP source address in an ICMP message originated by the router MUST be one of the IP addresses associated with the physical interface over which the ICMP message is transmitted. If the interface has no IP addresses associated with it, the router's router-id is used instead.¶
However [RFC4443] offer different guidance regarding ICMPv6 source address selection:¶
If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address.¶
If the message is a response to a message sent to any other address, the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. The address SHOULD be chosen according to the rules that would be used to select the source address for any other packet originated by the node, given the destination address of the packet. However, it MAY be selected in an alternative way if this would lead to a more informative choice of address reachable from the destination of the ICMPv6 packet.¶
ICMP messages are typically path independent. This means that the IP layer determines the first-hop through which the ICMP message is forwarded. ICMP does not influence the IP layer's first hop selection.¶
In at least one case, ICMP messages are not path independent. [RFC9359] describes a situation in which an ICMP message must be forwarded through a specific interface. That is, the ICMP message must be forwarded through the interface upon which the packet that caused it to be sent arrived.¶
IPv4 hosts will often communicate with an IPv4 host through an IPv4/IPv4 translator [RFC5508] which may be located at the customer premise, ISP, or the server's datacenter.¶
IPv6-only hosts may communicate with IPv4-only hosts through an IPv6/IPv4 translator which might be stateless ([RFC7915], [RFC6791]) or stateful ([RFC6146]), and may be located at the customer premise or ISP (as a NAT64 service). Because of this translation, a received ICMP message will refer to the IPv4 host.¶
IPv4 traffic may communicate with IPv6-only hosts through an IPv6/IPv4 translator located at the datacenter [RFC7755]. This requires no special handling for the IPv4 host.¶
This document does not make any requests of IANA¶
As this document does not introduce any new protocols or operational procedures, it does not introduce any new security considerations¶
The authors wish to acknowledge Joe Touch for his review and hekpful comments.¶