ICMP Protocols with Wireshark

This document provides an in-depth analysis of ICMP protocols using Wireshark. It covers topics such as the absence of port numbers in ICMP packets, examining ping requests and replies, trace routes, IP protocol numbers for UDP packets sent by ICMP, and the fields in IP datagrams that change and stay constant. The document also explores fragmentation in IP datagrams and the pattern found in different echo requests.

RUNNING HEAD: ICMP PROTOCOLS WITH WIRESHARK
ICMP Protocols with Wireshark
Name of the Student
Name of the University
Author Note

1ICMP PROTOCOLS WITH WIRESHARK
Ping request from source to destination
Command prompt: c:\windows\system32\ping –n 10 www.ece.ust.hk
Figure 1: Command Prompt for pinging destination host
(Source: Created by the Author)

2ICMP PROTOCOLS WITH WIRESHARK
Figure 2: Ping request packet with ICMP field information
(Source: Created by the Author)
IP addresses: Source IP, Destination IP
Respective IP addresses for the hosts are given below:
IP address of source host – 10.10.30.1
IP address of destination host – 10.10.30.186
Why ICMP packets don’t have port numbers
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.
Examining a ping request by the Source host
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.

3ICMP PROTOCOLS WITH WIRESHARK
Figure 3: Ping reply packet with ICMP field information
(Source: Created by the Author)
Examining corresponding reply packet
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.
Trace route
Command prompt: c:\windows\system32\tracert www.inria.fr

4ICMP PROTOCOLS WITH WIRESHARK
Figure 4: Command prompt for trace route
(Source: Created by the Author)
Figure 5: Wireshark capture with packet information
(Source: Created by the Author)

5ICMP PROTOCOLS WITH WIRESHARK
IP addresses: Source IP, Destination IP
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
IP protocol number UDP packets are sent by ICMP
If instead UDP packets are sent by ICMP, the IP protocol number for probe packets is
0x11.
Figure 6: ICMP echo packet contents
(Source: Created by the Author)
Examining of ICMP echo packet and the difference from ICMP ping packets
An ICMP echo packet comprise of the exact fields that can be found in a ping query
packet.

6ICMP PROTOCOLS WITH WIRESHARK
Figure 7: ICMP error packet contents
(Source: Created by the Author)
Examining of the ICMP error packet and its contents
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.
Examining of the last three digits of ICMP and their difference from error
packets
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.

7ICMP PROTOCOLS WITH WIRESHARK
Trace route link with longest delay and location of the two routers
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.
IP protocol and tracing IP datagrams
Figure 8: IP datagram
(Source: Created by the Author)

8ICMP PROTOCOLS WITH WIRESHARK
Figure 9: IP packet information for trace 1
(Source: Created by the Author)
IP Address – source computer
The source computer’s IP address is 10.10.30.186
Upper layer protocol (IP header) Value
Value of upper layer protocol in IP header is ICMP (1)
Bytes of IP header and IP Datagram Payload
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
Fragmentation in IP Datagram
Value of more fragments – Not Set
Fragment offset – 0
This means data is not fragmented yet.

9ICMP PROTOCOLS WITH WIRESHARK
Fields in IP Datagram that always change
IP datagram fields which are always changing – time to live (TTL), identification and
header checksum.
Fields staying constant, Fields which must be constant, Fields which must change
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.
Fields which should be staying constant are:
 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

10ICMP PROTOCOLS WITH WIRESHARK
Pattern found in different echo requests
The only noticeable pattern is that the identification field of the IP header changes
with every ICMP Echo packet request.
Figure 10: IP packet information of First echo request with Packet Size 3500
(Source: Created by the Author)
Identification and TTL values
The Identification field carries the value 805 and the TTL is 255.
Field value changes for every TTL-exceeded reply
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.

11ICMP PROTOCOLS WITH WIRESHARK
First ICMP Echo packet request following change of Packet size to 2000
Figure 11: IP packet information of First echo request with Packet Size 2000
(Source: Created by the Author)
This packet is fragmented across multiple IP datagrams.
Print of first fragment of fragmented IP datagram
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.

12ICMP PROTOCOLS WITH WIRESHARK
Figure 12: IP packet information First echo Packet Size 56
(Source: Created by the Author)
Print of Second fragment of fragmented IP datagram
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.

13ICMP PROTOCOLS WITH WIRESHARK
Figure 13: IP packet information First echo Packet Size 2000
(Source: Created by the Author)
Fields that change between the first two fragments
The first two fragments have the following common fields – Total length, more
fragments bit and fragment offset. Fields – TTL and identification don’t change.
First ICMP Echo packet request following change of Packet size to 3500
The following screenshot illustrates the fragment and earliest echo request following change
of packet size to 3500.
Figure 14: IP packet information of First echo with Packet Size 3500
(Source: Created by the Author)
Number of fragments created from original datagram
Here, a total of three full fragments are created from the original datagram

14ICMP PROTOCOLS WITH WIRESHARK
Fields that change among the fragments
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.

15ICMP PROTOCOLS WITH WIRESHARK
Bibliography
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).

16ICMP PROTOCOLS WITH WIRESHARK
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.