The 4-byte ICMP header contains an 8-bit type field, which defines the ICMP type. The type determines what the ICMP packet is used for. Depending on the type, the 8-bit code field may also be used, which contains additional information. If the type does not have any codes defined, the code field is set to zero.

For more general information on ICMP, see ICMP for IPv4.

Below is a table of all currently defined ICMP types. Note that some of these are IPv4 or IPv6 specific.

There are many types which have been deprecated, or are reserved for some reason. The ones that are still active are outlined here.

ICMP echo and echo-reply are commonly use in the ping application. This sends an ICMP echo to a host, which returns an ICMP echo-reply. If unsuccessful, the request will either time out, or a device along the path will reply with some type of ICMP error message.

An echo packet has type 8 set in the ICMP header, and the reply uses type zero. Neither have any codes defined, so the code field in the header is always set to zero.

The second four bytes of the header includes two 16-bit fields; The Identifier and the Sequence. These are used to match a particular echo with the echo-reply. These fields are used differently depending on implementation. For example, Linux sets a unique identifier for each process, while Windows uses a single identifier for all processes (the value is selected at boot time). Both Linux and Windows use an incrementing sequence value for each echo.

The data area of the packet is used for padding out to a particular size. The padding is usually made up of ASCII characters. When a host receives an echo packet, its echo-reply packet must use the same data payload as the original echo.

The size of the data area will vary, based on the MTU of the LAN, or based on manually specified sizes. By default, the packet has to fit into the MTU of the LAN that the source host is part of. However, keep in mind that this does not mean that the packet will definitley fit into the MTU size of all network segments along the path from source to destination. If it is too large, the packet will need to be fragmented.
Below is an excerpt from a packet capture that was run during a successful ping. Notice that the type is set to zero, which is the echo-reply.

Destination Unreachable messages are used to inform a sender that a packet could not be delivered to an endpoint. This message is sent unsollicited from the end host or an interim device, such as a router. In this context, unsolicited means that the source didn’t send an ICMP query and expect a response (such as with echo and echo-reply), another device simply informs the sender of the problem.

When this error is raised, a code is included (as shown in the table below), to give the sender a clue as to what is wrong. Additionally, the data field (after the full 8-byte header) includes a part of the original packet that failed. This is included so the sender can match the error to the process that generated the original packet.

Generally, codes 0-5 seem to be the most common. Code 2 (protocol unreachable) and code 3 (port unreachable) are sent by the end host, and indicates that there is a problem on the host itself, such as port not open, process not running and so on.

Code 0 (Net Unreachable), code 1 (Host Unreachable), and code 5 (Source Route Failed) are sent by an interim router, and usually suggest that there is a routing or firewall problem.

Code 4 (Fragmentation needed and DF bit set) is also sent by an interim router. This happens if a packet is larger than the MTU for the interim network, however fragmentation into smaller packets is not allowed as the Dont Fragment bit in the IP header is set.

Below is a packet capture of an unreachable message. Notice that the type is set to 3 (Destination Unreachable), and in this case the code is 1 (Host Unreachable). Notice that the original packet (an ICMP Echo in this case) has been included in the data area of the ICMP message.

This error was generated when a host send a ping, but an interim router didn’t have a route to that host. Remember that the ICMP message will only be received if the interim router also has a route back to the source.

An ICMP redirect message assists in making routing more efficient. In a case where a host has a default gateway, and the default gateway knows that a different local router if better for the network that the host is trying to reach, the gateway will send a redirect to the host, telling the host to use that router from now on. This may apply to all traffic to the particular destination network, or only traffic for the specific destination host.

It is important to understand that this helps with routing efficiency, but is not used to populate routing tables.

As shown in the packet capture below, the IP address of the ‘better’ router is included in the second 4 bytes of the header. The data section is populated with the first 8 bytes of the original packet, so the sender can match the message to the originating process.

The Router Solicitation and Router Advertisement messages are used as part of the Internet Router Discovery Protocol (IRDP), which is defined in RFC1256. This is a method for hosts to discover neighbouring routers without any manual configuring or DHCP support.

The Solicitation (type 10) message is sent by a host to multicast address 224.0.0.2, to request any routers on the local segment to identify themselves. Any routers that receive this message (and support IRDP) will reply with the Advertisement (type 9) message to announce their IP address as available for routing. Routers may also send the Advertisement message unsolicited on occasion (as more of an advertisement than a response).

If more than one router on the local segment responds, the host will pick the first response. If the host makes a poor choice, ICMP redirects will be used to make routing more efficient.

The time exceeded message can be generated for two different errors; One is that the TTL (Time To Live) field value in the IP header has decremented to zero, and the packet had to be dropped. The other is that a device could not reassemble a fragmented packed in the allocated time, and the packet was dropped. The code field is used to determine which one of these errors has been raised.

When a packet is sent from a source host, the TTL value in the IP header is set. Each layer-3 hop in the network will decrement this value by 1, and eventually the packet will either be delivered, or the TTL will drop to zero, and the packet will be discarded. This is done for loop prevention, so a packet will be dropped if it loops around for too long. When a router decrements the TTL to zero, it creates the Time Exceeded message, and sends it to the source host. Of course, this can be caused if the TTL is set too low in the first place.

This feature can be useful for security in some cases. For example, the BGP TTL Security feature will set the TTL so only routers within a maximum distance can be reached.

Be aware that some security devices, even though they are layer-3, do not decrement the TTL of packets passing through them.

The packet capture below shows an example of the Time Exceeded message, due to the TTL expiring.

There are times that a packet has to be fragmented into smaller pieces. When the fragments arrive at the destination, they need to be reassembled into the original packet. The occasional problem here is that one of the fragments may go missing, resulting in the entire packet being discarded.

To handle this, the IP stack starts a timer when the first fragment arrives. If the timer expires before all the fragments are reassembled, the packet is discarded, and the Time Exceeded message is created and sent to the source.

The Parameter Problem message is a generic ‘catch-all’ message. that is used if no more specific error applies. This will also be used if there is a corruption or missing data in the IP header.

When the Parameter Problem message is sent, a pointer is included in the high 8-bits of the second part of the header. This pointer contains the location of the problem in the original packet.

In some cases, the pointer is not included. For example, if there is data missing (codes 1 and 2), there will be no pointer. After all, it’s difficult to point to data that is not there.

Timestamps can be used to synchronise time between devices. To achieve this, a device sends a Type 13 Timestamp-Request to another device. In the request, it includes the time that the packet was sent, measured in milliseconds past midnight in Universal time. The second four bytes of the header include an identifier and sequence number which are used to match requests and replies.

In response, the recipient generates a type 14 Timestamp-Reply. The header format is the same as the request, but the payload includes the original timestamp, the timestamp when the packet was received, and the timestamp for when the reply packet was sent.

Photuris is an application-layer session-key management protocol (RFC2522). It is used to generate session keys and establish IPSec SA’s. It uses ICMP to report on negotiation failures.