The
Internet Control Message Protocol (
ICMP) is one of the core protocols of the
Internet Protocol Suite. It is chiefly used by the
operating systems
of networked computers to send error messages indicating, for example,
that a requested service is not available or that a host or router could
not be reached. ICMP can also be used to relay query messages.
[1] It is assigned protocol number 1.
[2]
ICMP
[3] 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).
ICMP for
Internet Protocol version 4 (IPv4) is also known as ICMPv4.
IPv6 has a similar protocol,
ICMPv6.
Technical details
The Internet Control Message Protocol 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.
[1]
For example, every device (such as an intermediate
router) forwarding an IP datagram first decrements the
time to live (TTL) field in the IP header by one. If the resulting TTL is 0, the packet is discarded and an ICMP
Time To Live exceeded in transit message is sent to the datagram's source address.
Although ICMP messages are contained within standard IP datagrams,
ICMP messages are usually processed as a special case, distinguished
from normal IP processing, rather than processed as a normal
sub-protocol of IP. In many cases, it is necessary to inspect the
contents of the ICMP message and deliver the appropriate error message
to the application that generated the original IP packet, the one that
prompted the sending of the ICMP message.
Many commonly used network utilities are based on ICMP messages. The
tracert (
traceroute),
Pathping commands are implemented by transmitting UDP datagrams with specially set IP TTL header fields, and looking for ICMP
Time to live exceeded in transit (above) and "Destination unreachable" messages generated in response. The related
ping utility is implemented using the ICMP "Echo request" and "Echo reply" messages.
ICMP segment structure
The ICMP header starts after the
IPv4 header and is identified by
protocol number
'1'. All ICMP packets will have an 8-byte header and variable-sized
data section. The first 4 bytes of the header will be consistent. The
first byte is for the ICMP type. The second byte is for the ICMP code.
The third and fourth bytes are a checksum of the entire ICMP message.
The contents of the remaining 4 bytes of the header will vary based on
the ICMP type and code.
[1]
ICMP error messages contain a data section that includes the entire IP
header
plus the first 8 bytes of data from the IP datagram that caused the
error message. The ICMP datagram is then encapsulated in a new IP
datagram.
[1]
Bits |
0–7 |
8–15 |
16–23 |
24–31 |
0 |
Type |
Code |
Checksum |
32 |
Rest of Header |
- Type – ICMP type as specified below.
- Code – Subtype to the given type.
- Checksum – Error checking data. Calculated from the ICMP
header+data, with value 0 for this field. The checksum algorithm is
specified in RFC 1071.
- Rest of Header – Four byte field. Will vary based on the ICMP type and code.
Control messages
Notable control messages[4][5]
Type |
Code |
Description |
0 – Echo Reply[3]:14 |
0 |
Echo reply (used to ping) |
1 and 2 |
|
Reserved |
3 – Destination Unreachable[3]:4 |
0 |
Destination network unreachable |
1 |
Destination host unreachable |
2 |
Destination protocol unreachable |
3 |
Destination port unreachable |
4 |
Fragmentation required, and DF flag set |
5 |
Source route failed |
6 |
Destination network unknown |
7 |
Destination host unknown |
8 |
Source host isolated |
9 |
Network administratively prohibited |
10 |
Host administratively prohibited |
11 |
Network unreachable for TOS |
12 |
Host unreachable for TOS |
13 |
Communication administratively prohibited |
14 |
Host Precedence Violation |
15 |
Precedence cutoff in effect |
4 – Source Quench |
0 |
Source quench (congestion control) |
5 – Redirect Message |
0 |
Redirect Datagram for the Network |
1 |
Redirect Datagram for the Host |
2 |
Redirect Datagram for the TOS & network |
3 |
Redirect Datagram for the TOS & host |
6 |
|
Alternate Host Address |
7 |
|
Reserved |
8 – Echo Request |
0 |
Echo request (used to ping) |
9 – Router Advertisement |
0 |
Router Advertisement |
10 – Router Solicitation |
0 |
Router discovery/selection/solicitation |
11 – Time Exceeded[3]:6 |
0 |
TTL expired in transit |
1 |
Fragment reassembly time exceeded |
12 – Parameter Problem: Bad IP header |
0 |
Pointer indicates the error |
1 |
Missing a required option |
2 |
Bad length |
13 – Timestamp |
0 |
Timestamp |
14 – Timestamp Reply |
0 |
Timestamp reply |
15 – Information Request |
0 |
Information Request |
16 – Information Reply |
0 |
Information Reply |
17 – Address Mask Request |
0 |
Address Mask Request |
18 – Address Mask Reply |
0 |
Address Mask Reply |
19 |
|
Reserved for security |
20 through 29 |
|
Reserved for robustness experiment |
30 – Traceroute |
0 |
Information Request |
31 |
|
Datagram Conversion Error |
32 |
|
Mobile Host Redirect |
33 |
|
Where-Are-You (originally meant for IPv6) |
34 |
|
Here-I-Am (originally meant for IPv6) |
35 |
|
Mobile Registration Request |
36 |
|
Mobile Registration Reply |
37 |
|
Domain Name Request |
38 |
|
Domain Name Reply |
39 |
|
SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol |
40 |
|
Photuris, Security failures |
41 |
|
ICMP for experimental mobility protocols such as Seamoby [RFC4065] |
42 through 255 |
|
Reserved |
Source quench
Source Quench requests that the sender decrease the rate of
messages sent to a router or host. This message may be generated if a
router or host does not have sufficient buffer space to process the
request, or may occur if the router or host buffer is approaching its
limit.
Data is sent at a very high speed from a host or from several hosts
at the same time to a particular router on a network. Although a router
has buffering capabilities, the buffering is limited to within a
specified range. The router cannot queue any more data than the capacity
of the limited buffering space. Thus if the queue gets filled up,
incoming data is discarded until the queue is no longer full. But as no
acknowledgement mechanism is present in the network layer, the client
does not know whether the data has reached the destination successfully.
Hence some remedial measures should be taken by the network layer to
avoid these kind of situations. These measures are referred to as source
quench. In a source quench mechanism, the router sees that the incoming
data rate is much faster than the outgoing data rate, and sends an ICMP
message to the clients, informing them that they should slow down their
data transfer speeds or wait for a certain amount of time before
attempting to send more data. When a client receives this message, it
will automatically slow down the outgoing data rate or wait for a
sufficient amount of time, which enables the router to empty the queue.
Thus the source quench ICMP message acts as flow control in the network
layer.
Source quench message[3]:9
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 |
Type = 4 |
Code = 0 |
Header checksum |
unused |
IP header and first 8 bytes of original datagram's data |
Where:
- Type must be set to 4
- Code must be set to 0
- IP header and additional data is used by the sender to match the reply with the associated request
Redirect
Redirect requests data packets be sent on an alternative
route. ICMP Redirect is a mechanism for routers to convey routing
information to hosts. The message informs a host to update its routing
information (to send packets on an alternate route). If a host tries to
send data through a
router
(R1) and R1 sends the data on another router (R2) and a direct path
from the host to R2 is available (that is, the host and R2 are on the
same Ethernet segment), then R1 will send a redirect message to inform
the host that the best route for the destination is via R2. The host
should then send packets for the destination directly to R2. The router
will still send the original
datagram
to the intended destination. However, if the datagram contains routing
information, this message will not be sent even if a better route is
available. RFC1122 states that redirects should only be sent by
gateways and should not be sent by Internet hosts.
Redirect message[3]:11
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 |
Type = 5 |
Code |
Header checksum |
IP address |
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, may be one of the following:
-
-
Code |
Description |
0 |
Redirect for Network |
1 |
Redirect for Host |
2 |
Redirect for Type of Service and Network |
3 |
Redirect for Type of Service and Host |
- 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.
Time exceeded message[3]:5
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 |
Type = 11 |
Code |
Header checksum |
unused |
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:
-
-
Code |
Description |
0 |
Time-to-live exceeded in transit. |
1 |
Fragment reassembly time exceeded. |
- 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. It consists of the originating
timestamp.
Timestamp message[3]:15
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 |
Type = 13 |
Code = 0 |
Header checksum |
Identifier |
Sequence number |
Originate 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 and a transmit timestamp.
Timestamp reply message[3]:15
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 |
Type = 14 |
Code = 0 |
Header checksum |
Identifier |
Sequence number |
Originate timestamp |
Receive timestamp |
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.
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.
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 |
Type = 17 |
Code = 0 |
Header checksum |
Identifier |
Sequence number |
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.
[6]
Address mask reply
Address mask reply is used to reply to an address mask request message with an appropriate subnet mask.
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 |
Type = 18 |
Code = 0 |
Header checksum |
Identifier |
Sequence number |
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]
[3]
to inform the client that the destination is unreachable for some
reason. A Destination Unreachable message may be generated as a result
of a
TCP,
UDP or another ICMP transmission. Unreachable TCP ports notably respond with
TCP RST rather than a Destination Unreachable type 3 as might be expected.
The error will not be generated if the original datagram has a
multicast
destination address. 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.
Destination unreachable message[3]:3
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 |
Type = 3 |
Code |
Header checksum |
unused |
Next-hop MTU |
IP header and first 8 bytes of original datagram's data |
Where:
- Type field (bits 0-7) must be set to 3
- Code field (bits 8-15) is used to specify the type of error, and can be any of the following:
-
-
Code |
Description |
0 |
Network unreachable error. |
1 |
Host unreachable error. |
2 |
Protocol unreachable error (the designated transport protocol is not supported). |
3 |
Port unreachable error (the designated protocol is unable to inform the host of the incoming message). |
4 |
The datagram is too big. Packet fragmentation is required but the 'don't fragment' (DF) flag is on. |
5 |
Source route failed error. |
6 |
Destination network unknown error. |
7 |
Destination host unknown error. |
8 |
Source host isolated error. |
9 |
The destination network is administratively prohibited. |
10 |
The destination host is administratively prohibited. |
11 |
The network is unreachable for Type Of Service. |
12 |
The host is unreachable for Type Of Service. |
13 |
Communication administratively prohibited (administrative filtering prevents packet from being forwarded). |
14 |
Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port). |
15 |
Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators). |
- Next-hop MTU field (bits 48-63) contains the MTU of the next-hop network if a code 4 error occurs.
- IP header and additional data is included to allow the client
to match the reply with the request that caused the destination
unreachable reply.