0% found this document useful (0 votes)
68 views8 pages

Lab 5 Sol

This document summarizes the results of analyzing ICMP echo request packets with different payload sizes sent from a computer to a router. It was found that: 1. Packets with payloads of 56 and 2000 bytes were not fragmented, while a 3500 byte payload was fragmented into 3 packets. 2. The identification and TTL fields remained constant across fragments, while the fragment offset and more fragments bit changed to indicate the fragment number. 3. Examining the fragment values confirmed the first fragment, and whether it was the only fragment or if more followed.

Uploaded by

Sujal Prakash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
68 views8 pages

Lab 5 Sol

This document summarizes the results of analyzing ICMP echo request packets with different payload sizes sent from a computer to a router. It was found that: 1. Packets with payloads of 56 and 2000 bytes were not fragmented, while a 3500 byte payload was fragmented into 3 packets. 2. The identification and TTL fields remained constant across fragments, while the fragment offset and more fragments bit changed to indicate the fragment number. 3. Examining the fragment values confirmed the first fragment, and whether it was the only fragment or if more followed.

Uploaded by

Sujal Prakash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

1.

Select the first ICMP Echo Request message sent by your computer, expand the Internet
Protocol part of the packet in the packet details window, and print this.

2. Within the IP packet header, what is the value in the upper layer protocol field?
ICMP (1)
3. How many bytes are in the IP header? How many bytes are in the payload of the IP datagram?
Explain how you determined the number of payload bytes.

1
Header bytes: 20 (as seen in screenshot)
Payload bytes: 36 (total length 56 minus the 20 header bytes = 36)

4. Has this IP datagram been fragmented? Explain how you determined whether or not the
datagram has been fragmented.
From the previous screenshot, we do not see any IPv4 fragments. We will see these later when
we transmit longer ICMP echo requests.

5. Which fields in the IP datagram always change from one datagram to the next within this
series of ICMP messages sent by your computer?
Identification field is incrementing.
Time to live is also incrementing.

6. Which of the fields must stay constant? Which fields must change? Why?
The following fields remain constant:

• version (IPv4 always used)


• header length (doesn’t change since we are always using IPv4)
• source IP (my computer’s IP address doesn’t change)
• destination IP (usc.edu’s IP address doesn’t change)
• differentiated services (same protocol every time)
• upper layer protocol (same protocol every time)
• header checksum (verification disabled in my tests)

The following fields change:

• Identification field is incrementing (each IP datagram has a different ID)


• Time to live is also incrementing (this is how trace route works, as discussed in the
assignment)

7. Describe the pattern you see in the values in the Identification field of the IP datagram.
They are incrementing with each datagram.

8. What is the value in the Identification field and the TTL field?
My nearest hop router was 130.215.16.32. From the screenshot below, we see that

• 56 byte pings: Identification = 0 and TTL = 255


• 2000 byte pings: Identification = 0 and TTL = 255
• 3500 byte pings: Identification = 0 and TTL = 255

See three screenshots below.

2
3
9. Do these values remain unchanged for all of the ICMP TTL-exceeded replies sent to your
computer by the nearest (first hop) router? Why?
In my test, these fields do not change.

10. Find the first ICMP Echo Request message that was sent by your computer after you changed
the Packet Size in pingplotter to be 2000. Has that message been fragmented across more
than one IP datagram?
See screenshot below. Note the presence of the IPv4 fragments. I had the setting “Reassemble
fragmented IPv4 Datagrams” on for this part, so Wireshark shows the fragments together.

4
11. Print out the first fragment of the fragmented IP datagram. What information in the IP
header indicates that the datagram been fragmented? What information in the IP header
indicates whether this is the first fragment versus a latter fragment? How long is this IP
datagram?
I had to turn off the setting “Reassemble fragmented IPv4 Datagrams” to get this to work. See
screenshot below. The “more fragments” bit is set, indicating the datagram been fragmented
and there are more fragments coming. The “Fragment offset” is zero, indicating this is the
first fragment. The total length of this IP datagram is 1500 bytes.

5
12. Print out the second fragment of the fragmented IP datagram. What information in the IP
header indicates that this is not the first datagram fragment? Are there more fragments?
How can you tell?
See screenshot below. The ”Fragment offset” is 1480, indicating this is the second fragment.
The “more fragments” bit is clear, indicating this is the last fragment.

6
13. What fields change in the IP header between the first and second fragment?
Total length, the more fragments bit, fragment offset. Note that identification and time to
live don’t change.

14. Now find the first ICMP Echo Request message that was sent by your computer after you
changed the Packet Size in pingplotter to be 3500. How many fragments were created from
the original datagram? What fields change in the IP header among the fragments?

7
See screenshot below. Three fragments were created from the original datagram in this case.
The fields that change are:

• Between fragments 1 and 2: fragment offset changes


• Between fragments 2 and 3: total length, the more fragments bit, fragment offset.

You might also like