The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications (with the exception of some diagnostic tools like ping and traceroute).
A separate Internet Control Message Protocol (called ICMPv6) is used with IPv6.
Technical details
ICMP is part of the Internet protocol suite as defined in RFC 792. ICMP messages are typically used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). ICMP errors are directed to the source IP address of the originating packet.
Datagram structure
The ICMP packet is encapsulated in an IPv4 packet. All ICMP packets have an eight-byte header and variable-sized data section. The first four bytes of the header have fixed format, while the last four bytes depend on the type and code of the ICMP packet.
! Type !! Code !! Status !! Description
|-
||0 – Echo Reply
| 0 || || Echo reply (used to ping)
|-
||1 and 2
| || || Reserved
|-
|rowspan=16|3 – Destination Unreachable However, if the datagram contains routing information, this message will not be sent even if a better route is available. RFC 1122 states that redirects should only be sent by gateways and should not be sent by Internet hosts.
{| class="wikitable"
|+ Redirect message
|-
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
| colspan="8"| Type = 5
| colspan="8"| Code
| colspan="16"| Checksum
|-
| colspan="32" style="text-align:center;"| IP address
|-
| colspan="32" style="text-align:center;"| IP header and first 8 bytes of original datagram's data
|}
Where:
- Type must be set to 5.
- Code specifies the reason for the redirection, and may be one of the following:
- IP address is the 32-bit address of the gateway to which the redirection should be sent.
- IP header and additional data is included to allow the host to match the reply with the request that caused the redirection reply.
Time exceeded
Time Exceeded is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit.
Time exceeded messages are used by the traceroute utility to identify gateways on the path between two hosts.
{| class="wikitable"
|+Time exceeded message
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
| colspan="8"| Type = 11
| colspan="8"| Code
| colspan="16"| Checksum
|-
| colspan="32" style="text-align:center;"| unused
|-
| colspan="32" style="text-align:center;"| IP header and first 8 bytes of original datagram's data
|}
Where:
- Type must be set to 11
- Code specifies the reason for the time exceeded message, include the following:
- IP header and first 64 bits of the original payload are used by the source host to match the time exceeded message to the discarded datagram. For higher-level protocols such as UDP and TCP the 64-bit payload will include the source and destination ports of the discarded packet.
Timestamp
Timestamp is used for time synchronization. The originating timestamp is set to the time (in milliseconds since midnight) the sender last touched the packet. The receive and transmit timestamps are not used.
{| class="wikitable"
|+Timestamp message
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
| colspan="8"| Type = 13
| colspan="8"| Code = 0
| colspan="16"| Checksum
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| Sequence number
|-
| colspan="32" style="text-align:center;"| Originate timestamp
|-
| colspan="32" style="text-align:center;"| Receive timestamp
|-
| colspan="32" style="text-align:center;"| Transmit timestamp
|}
Where:
- Type must be set to 13
- Code must be set to 0
- Identifier and Sequence Number can be used by the client to match the timestamp reply with the timestamp request.
- Originate timestamp is the number of milliseconds since midnight Universal Time (UT). If a UT reference is not available, the most-significant bit can be set to indicate a non-standard time value.
Timestamp reply
Timestamp Reply replies to a Timestamp message. It consists of the originating timestamp sent by the sender of the Timestamp as well as a receive timestamp indicating when the Timestamp was received and a transmit timestamp indicating when the Timestamp reply was sent.
{| class="wikitable"
|+Timestamp reply message
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
| colspan="8"| Type = 14
| colspan="8"| Code = 0
| colspan="16"| Checksum
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| Sequence number
|-
| colspan="32" style="text-align:center;"| Originate timestamp
|-
| colspan="32" style="text-align:center;"| Receive timestamp
|-
| colspan="32" style="text-align:center;"| Transmit timestamp
|}
Where:
- Type must be set to 14
- Code must be set to 0
- Identifier and Sequence number can be used by the client to match the reply with the request that caused the reply.
- Originate timestamp is the time the sender last touched the message before sending it.
- Receive timestamp is the time the echoer first touched it on receipt.
- Transmit timestamp is the time the echoer last touched the message on sending it.
:All timestamps are in units of milliseconds since midnight UT. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp, provided the high-order bit of the timestamp is also set to indicate this non-standard value.
The use of Timestamp and Timestamp Reply messages to synchronize the clocks of Internet nodes has largely been replaced by the UDP-based Network Time Protocol and the Precision Time Protocol.
Address mask request
Address mask request is normally sent by a host to a router in order to obtain an appropriate subnet mask.
Recipients should reply to this message with an Address mask reply message.
{| class="wikitable"
|+Address mask request
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
| colspan="8"| Type = 17
| colspan="8"| Code = 0
| colspan="16"| Checksum
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| Sequence number
|-
| colspan="32" style="text-align:center;"| Address mask
|}
Where:
- Type must be set to 17
- Code must be set to 0
- Address mask can be set to 0
ICMP Address Mask Request may be used as a part of reconnaissance attack to gather information on the target network, therefore ICMP Address Mask Reply is disabled by default on Cisco IOS.
Address mask reply
Address mask reply is used to reply to an address mask request message with an appropriate subnet mask.
{| class="wikitable"
|+Address mask reply
! 00 || 01 || 02 || 03 || 04 || 05 || 06 || 07
! 08 || 09 || 10 || 11 || 12 || 13 || 14 || 15
! 16 || 17 || 18 || 19 || 20 || 21 || 22 || 23
! 24 || 25 || 26 || 27 || 28 || 29 || 30 || 31
|- style="text-align:center;"
| colspan="8"| Type = 18
| colspan="8"| Code = 0
| colspan="16"| Checksum
|- style="text-align:center;"
| colspan="16"| Identifier
| colspan="16"| Sequence number
|-
| colspan="32" style="text-align:center;"| Address mask
|}
Where:
- Type must be set to 18
- Code must be set to 0
- Address mask should be set to the subnet mask
Destination unreachable
Destination unreachable is generated by the host or its inbound gateway to inform the client that the destination is unreachable for some reason. Reasons for this message may include: the physical connection to the host does not exist (distance is infinite); the indicated protocol or port is not active; the data must be fragmented but the 'don't fragment' flag is on. Unreachable TCP ports notably respond with TCP RST rather than a destination unreachable type 3 as might be expected. Destination unreachable is never reported for IP multicast transmissions.
With the following field contents:
;
;