Understanding ICMP Packets: Types, Codes, And Fields

ICMP Packets and Their Role in Network-Layer Communication

ICMP packets do not have port numbers of either the source or the destination hosts since these are meant to communicate information pertaining to the network-layer through routers and hosts, instead of using processes of the application layer. The “Type” and “Code” sections of every ICMP packet in combination helps in identifying the particular message that is to be received (Bao et al., 2016). It does not have to rely on port numbers in directing ICMP messages to the processes of the application layer as all of these messages get interpreted through the network software itself.

Here the packet number 55 is examined as a ping request by the source host. This packet is sent by the source host after 5.25 seconds of starting the communication process. The “Type” number as well as “Code” number of this packet in the ICMP header are 8 and 0 respectively. The corresponding fields in the ICMP header of this packet are checksum, type, code, and both identifiers – identifier (BE), identifier (LE) and sequence numbers – sequence number (BE) and sequence number (LE) (Hui & Kelsey, 2016). All the fields – identifier (BE), sequence number (BE), identifier (LE), sequence number (LE) and checksum are of two bytes each.

Figure 1: Ping reply packet with ICMP field information

(Source: Created by the Author)

The corresponding reply ping for the above packet is 56 which is generated after 5.36 seconds of starting the communication process. The ICMP “Type” number and “Code” number of this packet in the ICMP header are 0 and 0 respectively. The corresponding fields in the ICMP header of this packet are checksum, type, code, and identifiers – identifier (BE), identifier (LE) and sequence numbers – sequence number (BE) and sequence number (LE). All the fields – identifier (BE), sequence number (BE), identifier (LE), sequence number (LE) and checksum are of two bytes each.

Command prompt: c:windowssystem32tracert www.inria.fr

Figure 2: Command prompt for trace route

(Source: Created by the Author)

Figure 3: Wireshark capture with packet information

(Source: Created by the Author)

Respective IP addresses for the hosts are given below:

IP address of source host – 10.10.30.186

IP address of destination host – 128.93.162.84

If instead UDP packets are sent by ICMP, the IP protocol number for probe packets is 0x11.

Figure 4: ICMP echo packet contents

(Source: Created by the Author)

An ICMP echo packet comprise of the exact fields that can be found in a ping query packet.

ICMP Packet Types and Codes

Figure 5: ICMP error packet contents

(Source: Created by the Author)

ICMP error packets are different from any of the query packets while pinging. They comprise of both the IP headers as also the beginning 8 of the total bytes of the ICMP packet for which this error occurred.

Last three packets of ICMP are of message type 0 which are echo reply instead of 11 that are TTL expired. These are separate messages as their datagrams show to have reached the host of the destination prior to the expiry of TTL.

A link exists between steps 7 and 8 having substantially long delay. This two routers are located between Asia and Europe among cities Mumbai, (India) and Marseille, (France). Here, the ping jumps from sub-50 milliseconds to over 150 milliseconds.

Figure 6: IP datagram

(Source: Created by the Author)

Figure 7: IP packet information for trace 1

(Source: Created by the Author)

The source computer’s IP address is 10.10.30.186

Value of upper layer protocol in IP header is ICMP (1)

The IP header part consists of 20 bytes while, total length of the packet is 56. Hence payload of the IP datagram is of (56 – 20) = 36 bytes

Value of more fragments – Not Set

Fragment offset – 0

This means data is not fragmented yet.

IP datagram fields which are always changing – time to live (TTL), identification and header checksum.

The fields which are staying constant in the IP datagram are:

• Version – IPV4
• Length of the header
• Upper layer Protocol number
• Source IP
• Destination IP
• Differentiated Services.

• Version – IPV4
• Header length
• Upper layer Protocol number
• Source IP
• Destination IP
• Differentiated Services

Fields which are changing always are:

• Identification
• Time to live
• Header checksum

The only noticeable pattern is that the identification field of the IP header changes with every ICMP Echo packet request.

Figure 8: IP packet information of First echo request with Packet Size 3500

(Source: Created by the Author)

The Identification field carries the value 805 and the TTL is 255.

The identification field value changes for every single ICMP TTL-exceeded reply as identification field always holds unique values. IP datagrams having exact identification values represent datagrams that are separate fragments of a bigger IP datagram.

TTL field is always the same value for first Echo packet because, the values of the first routers are always the same.

Figure 9: IP packet information of First echo request with Packet Size 2000

(Source: Created by the Author)

This packet is fragmented across multiple IP datagrams.

The first fragment is known from looking at value of fragment offset which is 0. First datagram comes at a total length of 56 which includes the header.

ICMP Packet Fields

Figure 10: IP packet information First echo Packet Size 56

(Source: Created by the Author)

This can never be first fragment of the datagram as fragment offset value is 185. Total length of this fragment including the header becomes 520.

Figure 11: IP packet information First echo Packet Size 2000

(Source: Created by the Author)

The first two fragments have the following common fields – Total length, more fragments bit and fragment offset. Fields – TTL and identification don’t change.

The following screenshot illustrates the fragment and earliest echo request following change of packet size to 3500.

Figure 12: IP packet information of First echo with Packet Size 3500

(Source: Created by the Author)

Here, a total of three full fragments are created from the original datagram

By comparing fragments 1 and 2 it can be seen that the fragment offset changes. The comparison of fragments 2 and 3 shows the fields – total length, fragment offset and more fragments bit changes.

References

Alhady, M. N., & Elsid, A. G. (2015). Improve the QoS by Applying Differentiated Service over MPLS Network.

Alqahtani, A. H., & Iftikhar, M. (2013). TCP/IP attacks, defenses and security tools. International Journal of Science and Modern Engineering (IJISME), 1(10).

Anbar, M., Ramadass, S., Manickam, S., & Al-Wardi, A. (2014). Connection failure message-based approach for detecting sequential and random TCP scanning. Indian Journal of Science and Technology, 7(5), 628.

Anderson, T., & Popper, A. L. (2016). Explicit Address Mappings for Stateless IP/ICMP Translation (No. RFC 7757).

Aust, S., Prasad, V., & Niemegeers, I. G. (2013, August). Analysis of the Performance Boundaries of Sub-1 GHz WLANs in the 920MHz ISM-Band. In ISWCS 2013; The Tenth International Symposium on Wireless Communication Systems (pp. 1-5). VDE.

Bao, C., Li, X., Baker, F., Anderson, T., & Gont, F. (2016). IP/ICMP translation algorithm (No. RFC 7915).

Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., & Farrer, I. (2015). Lightweight 4over6: An extension to the dual-stack lite architecture (No. RFC 7596).

Deering, S., & Hinden, R. (2017). Internet protocol, version 6 (IPv6) specification (No. RFC 8200).

Flajslik, M., & Rosenblum, M. (2013). Network interface design for low latency request-response protocols. In Presented as part of the 2013 {USENIX} Annual Technical Conference ({USENIX}{ATC} 13) (pp. 333-346).

Gandhi, D. C., Suri, G., Golyan, R. P., Saxena, P., & Saxena, B. K. (2014). Packet sniffer–a comparative study. International Journal of Computer Networks and Communications Security, 2(5), 179-187.

Hui, J., & Kelsey, R. (2016). Multicast protocol for low-power and lossy networks (MPL) (No. RFC 7731).

Issac, B. (2014). Secure ARP and secure DHCP protocols to mitigate security attacks. arXiv preprint arXiv:1410.4398.

Kumar, D. M. A., & Karthikeyan, S. (2013). An Enhanced Security for TCP/IP Protocol Suite. International. Journal of Computer Science and Mobile Computing, 2(11), 331-338.

Kumar, S., & Sudarsan, S. D. (2014). An innovative UDP port scanning technique. International Journal of Future Computer and Communication, 3(6), 381.

Shang, W., Yu, Y., Droms, R., & Zhang, L. (2016). Challenges in IoT networking via TCP/IP architecture. NDN Project, NDN-0038 (Tech. Rep.).

Turup, M. N., & Patil, B. M. (2015). network forensics system for ICMP attacks using real time approach. International Journal of Advances in Engineering & Technology, 8(1), 2023.