Internet-Draft ICMP Operational Experience June 2024
Bonica, et al. Expires 21 December 2024 [Page]
Workgroup:
INTAREA Working Group
Internet-Draft:
draft-bonica-intarea-icmp-op-exp-00
Published:
Intended Status:
Informational
Expires:
Authors:
R. Bonica
Juniper Networks
C. Pignataro
Blue Fern Consulting
D. Wing
Cloud Software Group
X. Min
ZTE Corp.

Internet Control Message Protocol (ICMP): Standards and Operational Experience

Abstract

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.

Status of This Memo

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.

Table of Contents

1. Introduction

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.

2. Conventions and Definitions

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.

3. ICMP Message Types

[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.

3.1. Message Processing

3.1.1. Known ICMP Message Types

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).

3.1.2. Unknown ICMP Message Types

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.

4. ICMP Restrictions

According to [RFC1122], an ICMPv4 error message must not be sent as the result of receiving:

According to [RFC4443], an ICMPv4 error message must not be sent as the result of receiving:

The following are exceptions to the IPv6 multicast, link-layer multicast, and link_layer broadcast rules above:

5. Extensibility:

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.

6. Acceptable Uses

[RFC7279] defines accpetable uses for ICMP. The following are acceptable uses:

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.

7. Management Applications

The following management applications rely on ICMP:

8. General Issues

8.1. Transport

ICMP messages can be lost in transport. Therefore, the originator of an ICMP message cannot rely on the message arriving at its intended destination.

8.2. Rate Limits

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.

8.3. Forgery

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.

8.4. Message Length

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).

8.5. Source Address Selection

[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.

8.6. Path Selection

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.

9. Translation Considerations

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.

10. IANA Considerations

This document does not make any requests of IANA

11. Security Considerations

As this document does not introduce any new protocols or operational procedures, it does not introduce any new security considerations

12. Acknowledgements

The authors wish to acknowledge Joe Touch for his review and hekpful comments.

13. References

13.1. Normative References

[RFC0768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/rfc/rfc768>.
[RFC0791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <https://www.rfc-editor.org/rfc/rfc791>.
[RFC0792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, , <https://www.rfc-editor.org/rfc/rfc792>.
[RFC0793]
Postel, J., "Transmission Control Protocol", RFC 793, DOI 10.17487/RFC0793, , <https://www.rfc-editor.org/rfc/rfc793>.
[RFC1122]
Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, , <https://www.rfc-editor.org/rfc/rfc1122>.
[RFC1812]
Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, , <https://www.rfc-editor.org/rfc/rfc1812>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4443]
Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, , <https://www.rfc-editor.org/rfc/rfc4443>.
[RFC4884]
Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, , <https://www.rfc-editor.org/rfc/rfc4884>.
[RFC5927]
Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, , <https://www.rfc-editor.org/rfc/rfc5927>.
[RFC7279]
Shore, M. and C. Pignataro, "An Acceptable Use Policy for New ICMP Types and Codes", BCP 189, RFC 7279, DOI 10.17487/RFC7279, , <https://www.rfc-editor.org/rfc/rfc7279>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/rfc/rfc8200>.

13.2. Informative References

[RFC2151]
Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, , <https://www.rfc-editor.org/rfc/rfc2151>.
[RFC4950]
Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, DOI 10.17487/RFC4950, , <https://www.rfc-editor.org/rfc/rfc4950>.
[RFC5508]
Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, DOI 10.17487/RFC5508, , <https://www.rfc-editor.org/rfc/rfc5508>.
[RFC5837]
Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, , <https://www.rfc-editor.org/rfc/rfc5837>.
[RFC6146]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, , <https://www.rfc-editor.org/rfc/rfc6146>.
[RFC6791]
Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, , <https://www.rfc-editor.org/rfc/rfc6791>.
[RFC7755]
Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments", RFC 7755, DOI 10.17487/RFC7755, , <https://www.rfc-editor.org/rfc/rfc7755>.
[RFC7915]
Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, , <https://www.rfc-editor.org/rfc/rfc7915>.
[RFC8335]
Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. Boucadair, "PROBE: A Utility for Probing Interfaces", RFC 8335, DOI 10.17487/RFC8335, , <https://www.rfc-editor.org/rfc/rfc8335>.
[RFC9359]
Min, X., Mirsky, G., and L. Bo, "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", RFC 9359, DOI 10.17487/RFC9359, , <https://www.rfc-editor.org/rfc/rfc9359>.
[V4MSG]
Internet Assigned Numbers Authority (IANA), "Internet Control Message Protocol (ICMP) Parameters", Web https://www.iana.org/assignments/icmp-parameters.
[V6MSG]
Internet Assigned Numbers Authority (IANA), "Internet Control Message Protocol version 6 (ICMPv6) Parameters", Web https://www.iana.org/assignments/icmpv6-parameters.

Authors' Addresses

Ron Bonica
Juniper Networks
Herndon, Virginia
United States of America
Carlos Pignataro
Blue Fern Consulting
Raleigh, NC
United States of America
Dan Wing
Cloud Software Group Holdings, Inc.
Xiao Min
ZTE Corp.
Nanjing
China