Introduction to ICMP – Part 2

Our last blog provided an overview into the Internet Protocol Suite, as well as the ICMP.  In this blog, we do a deeper dive into the ICMP, and provide a high-level view of the error messages that are reported with it.

A Technical Review of the ICMP

From a historical perspective, there have been different versions of the IMCP.  It was created and established by Jon Postel, who has been credited with playing a fundamental role in the implementation of the Internet as we know it today.  The first ICMP standard was formulated in April of 1981 and was originally published in the RFC 777.

After that, the ICMP has been through several iterations, and the one that is being used today has made its appearance in RFC 792, and that can be seen here by clicking on this link.  This version of the ICMP has also been published by the Internet Engineering Task Force in September 1981 as well.

Because the ICMP technically resides at the Internet Layer, it is carried by the IP Packets, and not the Data Packets that transmit the information and data from the source to the destination.   The ICMP messages are sent via the use of what are known as “Datagrams”, and more information about what that specifically is can be seen here at this link.

The Datagram contains an IP Header that entirely covers or encapsulates the error message that resides in the ICMP.  It is important to note that the error messages contained in the ICMP also contains the IP Header from the Data Packet that was unable to reach its final destination.  Going to back to our previous example, because of this functionality, the PDC will thus know the Data Packet that could not be delivered.

When the ICMP is used in IPv4 or IPv6, the ICMP shows up after the IP Packet Headers of these two protocols.  The ICMP is specifically identified as “Protocol Number 1”, and is broken down in the following order:

1)     The IPv4/IPv6 Packet Header;

2)     A three field ICMP Header which consists of the following:

  • The code that identifies the specific error message;
  • A “minor code” that contains more information about the error message;
  • A checksum that allows for the Network Administrator to check for the integrity of the ICMP.  A checksum is simply a sequence of alphanumeric characters.  The Network Administrator uses this functionality in order to make sure that there are no intentional or unintentional alterations made to the ICMP.

3)     The original Data Packet Header which failed delivery; typically, this is about 8 bytes worth of information/data payload.

This is illustrated in the diagram below:

Ethernet Packet
Ethernet Packet

The following matrix examines the codes and their corresponding messages and other pieces of information/data that are generated by the ICMP:

Error Codes and Messages

It is important to note at this point that one of the events that launches an ICMP is known as the “Time to Live”, (also known as “TTL” for short).  This metric represents the maximum number of Routers that a Data Packet can be sent through and is numerically decreased by a value of 1 each time the Data Packet is processed by a specific Router.  If for some reason the TTL value falls down to zero, the Data Packet is then dropped from the network flow and is reported back to the PDC.

Just because a Data Packet was dropped from the network flow because of a TTL, this does not mean that the Data Packet by itself is malformed in any way, or that there are any problems with Router(s) that is (are) being used.  The TTL was created in an effort to reduce backlog in network traffic, and to make sure that the network flow remains consistent and efficient.


Our next blog will examine these error messages in greater detail, and why it is important for the Network Administrator to thoroughly understand them.


1)     https://erg.abdn.ac.uk/users/gorry/eg3567/inet-pages/icmp.html