Internet Control Message Protocol

The Internet Control Message Protocol (ICMP) is a special set of rules used in computer networks. It helps devices like routers talk to each other when something goes wrong. For example, if a computer tries to reach another one that is not there, ICMP can send a message saying, “I can’t find that computer!” This helps network devices know if a message was able to get to its destination or if there was a problem along the way.

ICMP is different from other types of communication protocols such as TCP and UDP, because it does not move data from one place to another. Instead, it is mostly used by network tools to check how well things are working. Two common tools are ping, which checks if a computer is online, and traceroute, which shows the path a message takes across the internet.

There is also a version of ICMP called ICMPv6 that is used with a newer kind of internet addressing system known as IPv6. This helps modern networks work in the same way older ones did.

Technical details

ICMP is part of the set of rules that help computers talk to each other on the internet. It helps send messages when something goes wrong, like when a computer can't reach another one.

For example, when a message travels between computers, each stop along the way counts down a number called "time to live." If this number reaches zero, the message stops, and a message goes back to the sender saying it couldn't continue. Tools like ping and traceroute use these messages to check how far and how fast messages travel across the internet.

Datagram structure

The ICMP packet is wrapped inside an IPv4 packet. It has two main parts: a header and a data section.

The ICMP header comes right after the IPv4 header and is marked by its protocol number, which is 1. Every ICMP packet has an 8-byte header and a data section that can change in size. The first four bytes of the header always look the same, but the last four bytes can change depending on the type and code of the ICMP packet.

The data section in ICMP error messages includes a copy of the IPv4 header and the first eight bytes of the data from the IPv4 packet that caused the error. The whole ICMP error message should not be longer than 576 bytes. This helps the receiving device figure out which process the message belongs to.

Sometimes, the changing size of the ICMP data section has been used in harmful ways. For example, very large or broken-up ICMP packets have been used to disrupt services. ICMP data can also be used to create hidden ways to send messages between devices.

Control messages

Control messages are identified by the value in the type field. The code field gives additional context information for the message. Some control messages have been deprecated since the protocol was first introduced.

Source quench

Source Quench asks the sender to slow down the rate of messages sent to a router or host. This happens if a router or host does not have enough space to process the request or if its space is almost full.

Data can be sent very quickly from a host or from several hosts to a router on a network. Routers have limited space to hold data. If this space fills up, incoming data is discarded until there is space. Since there is no way to know if data reached its destination, some steps are needed to prevent this. In a source quench, the router tells clients to slow down or wait before sending more data. When a client receives this message, it slows down or waits, allowing the router to clear its space.

Since research showed that ICMP Source Quench was not effective, routers stopped creating these messages in 1995. Forwarding and reacting to these messages was also stopped in 2012.

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 asks data packets to be sent on a different route. This message tells a host to update its routing information to send packets through a better route. If a host sends data through a router (R1), and R1 sends it to another router (R2) while a direct path exists, R1 will send a redirect message. The host should then send packets directly to R2. The router will still send the original datagram, but if the datagram has routing information, no redirect will be sent even if a better route exists. RFC 1122 states that redirects should only come from gateways, not from Internet hosts.

Where:

• Type must be set to 5.
• Code specifies the reason for the redirection.
• IP address is the address of the gateway to send the redirection to.
• IP header and additional data is included to match the reply with the request.

Time exceeded

Time Exceeded is sent by a gateway to tell the source that a datagram was discarded because the time to live field reached zero. It can also be sent by a host if it cannot put together a fragmented datagram in time.

Time exceeded messages are used by the traceroute tool to find gateways between two hosts.

Where:

• Type must be set to 11
• Code specifies the reason for the Time Exceeded message.
• IP header and first 64 bits of the original payload help the source match the message to the discarded datagram. For UDP and TCP, this includes the source and destination ports.

Timestamp

Timestamp is used for time matching. The originating timestamp is set to when the sender last touched the packet. The receive and transmit timestamps are not used.

Where:

• Type must be set to 13
• Code must be set to 0
• Identifier and Sequence Number help the client match the timestamp reply with the request.
• Originate timestamp is the time since midnight Universal Time (UT). If UT is not available, a special bit can be set.

Timestamp reply

Timestamp Reply answers a Timestamp message. It includes the timestamps from the sender, when it was received, and when the reply was sent.

Where:

• Type must be set to 14
• Code must be set to 0
• Identifier and Sequence number help match the reply with the request.
• Originate timestamp is when the sender last touched the message.
• Receive timestamp is when it was first received.
• Transmit timestamp is when the reply was sent.

All timestamps are in milliseconds since midnight UT. If not available, any time can be used with a special bit set.

Timestamp and Timestamp Reply messages for clock synchronization are now mostly replaced by Network Time Protocol and the Precision Time Protocol.

Address mask request

Address mask request is usually sent by a host to a router to get a proper subnet mask.

Recipients should answer with an Address mask reply message.

Where:

• Type must be set to 17
• Code must be set to 0
• Address mask can be set to 0

Address mask reply

Address mask reply answers an address mask request with the right subnet mask.

Where:

• Type must be set to 18
• Code must be set to 0
• Address mask should be the subnet mask

Destination unreachable

Destination unreachable is sent by a host or gateway to tell the client the destination cannot be reached. Reasons include no physical connection, an inactive protocol or port, or data that needs to be split into pieces but cannot be. Unreachable TCP ports respond with TCP RST instead of this message. Destination unreachable is not used for IP multicast.

With the following field contents:

Type: 8 bits; Type == 3

A value of 3 means 'Destination unreachable'.

Code: 8 bits

This shows the type of error and can be one of several options.

Unused: 8 - 32 bits; Unused == 0

Unused and must be set to zero. If Length or Next-hop MTU are not used, they are part of this field.

Length: 8 bits

Optional. This shows the length of the original datagram data in 32-bit words. If used, the data is padded with zeroes to the nearest 32-bit boundary.

Next-hop MTU: 16 bits

Optional. Shows the MTU of the next-hop network if a code 4 error happens.

IP header and data: 20 - 568 bytes

The IP header and up to 548 bytes of the original datagram are included. If the message is extended, at least 128 bytes of the original data are included, padded with zeroes if needed. This helps the client match the reply with the request.

Extensions

ICMP messages can include extra information using special parts called Extension Objects. These objects start with an ICMP Extension Header.

The header has a few important pieces of information:

• Version: This tells us which version of the extension is being used (version 2 in this case).
• Reserved: This space is kept empty for future use.
• Checksum: This helps make sure the information is correct and unchanged.

Each Extension Object also has its own structure:

• Length: How long the object is, including its header.
• Class-Num: This identifies what kind of object it is.
• C-Type: This tells us the specific type within that kind.
• Object payload: Optional extra data, which comes in chunks of 32 bits.