]> Juniper Networks

Herndon Virginia USA rbonica@juniper.net

Blue Fern Consulting

Raleigh NC USA cpignata@gmail.com

Cloud Software Group Holdings, Inc.

danwing@gmail.com

ZTE Corp.

Nanjing China xiao.min2@zte.com.cn

Internet INTAREA Working Group ICMP operations 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.

Introduction The Internet Control Message Protocol (ICMP) can be used to exchange control information between hosts. ICMPv4 exchanges control information between IPv4 hosts while ICMPv6 exchanges control information between IPv6 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.

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 when, and only when, they appear in all capitals, as shown here.

ICMP Message Types and 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. refers to the unprocessed packet as the "original data datagram", while refers to the unprocessed packet as the "invoking packet". In this document, we will adopt 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 (). 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 and another registry of ICMPv6 message types . Many ICMPv4 message types have been deprecated.

Message Processing

Known ICMP Message Types According to and , 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) , 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).

Unknown ICMP Message Types According to , if an ICMPv4 message of unknown type is received, it must be silently discarded. According to , 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.

ICMP Restrictions According to , 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 , 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:

• The Packet Too Big Message can be sent to allow Path MTU discovery to work for IPv6 multicast
• The Parameter Problem Message, reporting an unrecognized IPv6 option that has the Option Type highest-order two bits set to 10 can be sent

Extensibility: Some ICMP messages are extensible . 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.

Acceptable Uses 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.

Management Applications The following management applications rely on ICMP:

• PING
• Traceroute
• Traceroute with extensions for Multiprotocol Label Switching (MPLS)
• Traceroute with extensions for Interface and Next-Hop Identification
• PROBE

General Issues

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.

Rate Limits As per and , 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.

Forgery ICMP messages are easily forged. describes how forged ICMP messages can be used to attack TCP . It also decribes mitigations against these attacks.

Message Length As per , an ICMPv4 message must not exceed 576 bytes. specifies no limit for ICMPv6 messages. However, to avoid fragmentation, ICMPv6 messages SHOULD not exceed the IPv6 minimum required MTU (i.e., 1280 bytes).

Source Address Selection 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 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.

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

Translation Considerations IPv4 hosts will often communicate with an IPv4 host through an IPv4/IPv4 translator 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 (, ) or stateful (), 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 . This requires no special handling for the IPv4 host.

IANA Considerations This document does not make any requests of IANA

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

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

References Normative References This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK] This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes. In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use. This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. [STANDARDS-TRACK] This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. [STANDARDS-TRACK] This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. This document describes a generic format for use in echo request/reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6, MPLS, Service Function Chain (SFC), and Bit Index Explicit Replication (BIER). Internet Assigned Numbers Authority (IANA) Internet Assigned Numbers Authority (IANA) A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. [STANDARDS-TRACK] This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses. The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.