Wireshark Lab:

IP and ICMP v8.1

Supplement to Computer Networking: A Top-Down
Approach, 8th ed., J.F. Kurose and K.W. Ross

“Tell me and I forget. Show me and I remember. Involve me

and I understand.” Chinese proverb

© 2005-2021, J.F Kurose and K.W. Ross, All Rights Reserved

Student Name:
Student ID:
In this lab, we’ll investigate the celebrated IP protocol, focusing on the IPv4 and IPv6
datagram. This lab has four parts. In the Sections 1 and 3, we’ll analyze packets in a
trace of IPv4 datagrams sent and received by the traceroute and ping programs.
We’ll study IP fragmentation in Part 2 of this lab, and take a quick look at IPv6 in Part 4
of this lab.

Before getting started, you’ll probably want to review sections 1.4.3 in the text1 and
section 3.4 of RFC 2151 to update yourself on the operation of the traceroute
program. You’ll also want to read Sections 4.3 and 5.6 in the text, and probably also
have RFC 791 on hand as well, for a discussion of the IP protocol. If you answer the
questions on IP fragmentation, you’ll definitely also want to review material on IP
fragmentation. Although we’ve removed the topic of IP fragmentation from the 8th
edition of our textbook (to make room for new material), you can find material on IP
fragmentation from the 7th edition of our textbook (and earlier) at
[Link]
RFC 8200 is the full RFC for IPv6, but reading that is a bit of overkill for this lab; you
can review IPv6 by consulting Section 4.3.4 in the textbook.

Capturing packets from an execution of traceroute

1
References to figures and sections are for the 8th edition of our text, Computer Networks, A Top-down
Approach, 8h ed., J.F. Kurose and K.W. Ross, Addison-Wesley/Pearson, 2020. Our website for this book is
[Link] You’ll find lots of interesting open material there.
In order to generate a trace of IPv4 datagrams for the first two parts of this lab, we’ll use
the traceroute program to send datagrams of two different sizes to
[Link]. Recall that traceroute operates by first sending one or more
datagrams with the time-to-live (TTL) field in the IP header set to 1; it then sends a series
of one or more datagrams towards the same destination with a TTL value of 2; it then
sends a series of datagrams towards the same destination with a TTL value of 3; and so
on. Recall that a router must decrement the TTL in each received datagram by 1
(actually, RFC 791 says that the router must decrement the TTL by at least one). If the
TTL reaches 0, the router returns an ICMP message (type 11 – TTL-exceeded) to the
sending host. As a result of this behavior, a datagram with a TTL of 1 (sent by the host
executing traceroute) will cause the router one hop away from the sender to send an
ICMP TTL-exceeded message back to the sender; the datagram sent with a TTL of 2 will
cause the router two hops away to send an ICMP message back to the sender; the
datagram sent with a TTL of 3 will cause the router three hops away to send an ICMP
message back to the sender; and so on. In this manner, the host executing traceroute
can learn the IP addresses of the routers between itself and the destination by looking at
the source IP addresses in the datagrams containing the ICMP TTL-exceeded messages.

Let’s run traceroute and have it send datagrams of two different sizes. The larger of
the two datagram lengths will require traceroute messages to be fragmented across
multiple IPv4 datagrams.

 Linux/MacOS. With the Linux/MacOS traceroute command, the size of the

UDP datagram sent towards the final destination can be explicitly set by
indicating the number of bytes in the datagram; this value is entered in the
traceroute command line immediately after the name or address of the
destination. For example, to send traceroute datagrams of 2000 bytes
towards [Link], the command would be:
%traceroute [Link] 2000
 Windows. The tracert program provided with Windows does not allow one
to change the size of the ICMP message sent by tracert. So it won’t be
possible to use a Windows machine to generate ICMP messages that are large
enough to force IP fragmentation. However, you can use tracert to generate
small, fixed length packets to perform Part 1 of this lab. At the DOS command
prompt enter:
>tracert [Link]
If you want to do the second part of this lab, you can download a packet trace file
that was captured on one of the author’s computers2.

2
You can download the zip file [Link] and
extract the trace file [Link]. This trace file can be used to answer these Wireshark
Do the following:
 Start up Wireshark and begin packet capture. (Capture->Start or click on the blue
shark fin button in the top left of the Wireshark window).
 Enter two traceroute commands, using [Link] as the destination,
the first with a length of 56 bytes. Once that command has finished executing,
enter a second traceroute command for the same destination, but with a
length of 3000 bytes. (Windows may not support this option.)
 Stop Wireshark tracing.

If you’re unable to run Wireshark on a live network connection, you can use the packet
trace file, [Link], referenced in footnote 2. You may well find it
valuable to download this trace even if you’ve captured your own trace and use it, as well
as your own trace, as you explore the questions below.

Part 1: Basic IPv4

In your trace, you should be able to see the series of UDP segments (in the case of
MacOS/Linux) or ICMP Echo Request messages (Windows) sent by traceroute on
your computer, and the ICMP TTL-exceeded messages returned to your computer by the
intermediate routers. In the questions below, we’ll assume you’re using a MacOS/Linux
computer; the corresponding questions for the case of a Windows machine should be
clear. Your screen should look similar to the screenshot in Figure 2, where we have used
the display filter “udp||icmp” (see the light-green-filled display-filter field in Figure 2) so
that only UDP and/or ICMP protocol packets are displayed.

lab questions without actually capturing packets on your own. The trace was made using Wireshark
running on one of the author’s computers, while performing the steps in this Wireshark lab. Once you’ve
downloaded a trace file, you can load it into Wireshark and view the trace using the File pull down menu,
choosing Open, and then selecting the trace file name.
 Figure 2: Wireshark screenshot, showing UDP and ICMP packets in the tracefile ip-
[Link]

Answer the following questions3. If you’re doing this lab as part of class, your teacher
will provide details about how to hand in assignments, whether written or in an LMS.

3
For the author’s class, when answering the following questions with hand-in assignments, students
sometimes need to print out specific packets (see the introductory Wireshark lab for an explanation of how
to do this) and indicate where in the packet they’ve found the information that answers a question. They do
this by marking paper copies with a pen or annotating electronic copies with text in a colored font. There
are also learning management system (LMS) modules for teachers that allow students to answer these
questions online and have answers auto-graded for these Wireshark labs at
[Link]
1. Select the first UDP segment sent by your computer via the traceroute
command to [Link]. (Hint: this is 44th packet in the trace file in the ip-
[Link] file in footnote 2). Expand the Internet Protocol part
of the packet in the packet details window. What is the IP address of your
computer?
- The IP address of my computer is [Link]

2. What is the value in the time-to-live (TTL) field in this IPv4 datagram’s header?
- The value in the time-to-live (TTL) is 1

3. What is the value in the upper layer protocol field in this IPv4 datagram’s header?
[Note: the answers for Linux/MacOS differ from Windows here].
- The value in the upper layer protocol field is 17

4. How many bytes are in the IP header?

- There are 20 bytes in the IP header

5. How many bytes are in the payload of the IP datagram? Explain how you
determined the number of payload bytes.
- Total length of the IP datagram: 56 bytes
- IP header size: 20 bytes
- IP datagram payload: Total length - IP header size
- 56 - 20 = 36 bytes
- This 36 bytes includes:
- UDP header: 8 bytes
 - UDP payload: 28 bytes
Therefore:
- The IP datagram payload (everything after the IP header) is 36 bytes.
- The UDP payload alone (the actual data being carried) is 28 bytes.

6. Has this IP datagram been fragmented? Explain how you determined whether or
not the datagram has been fragmented.
- Fragment offset: 0, the datagram has not been fragmented.
- The Fragment Offset field indicates the position of this fragment in the original
unfragmented datagram. A Fragment Offset of 0 means that this is the first
fragment (or the only fragment if no fragmentation occurred)

Next, let’s look at the sequence of UDP segments being sent from your computer via
traceroute, destined to [Link]. The display filter that you can enter to do
this is “[Link]==[Link] and [Link]==[Link] and udp and !icmp”. This
will allow you to easily move sequentially through just the datagrams containing just
these segments. Your screen should look similar to Figure 3.

Figure 3: Wireshark screen shot, showing up segments in the tracefile ip-wireshark-trace1-

[Link] using the display filter [Link]==[Link] and [Link]==[Link]
and udp and !icmp

7. Which fields in the IP datagram always change from one datagram to the next
within this series of UDP segments sent by your computer destined to
[Link], via traceroute? Why?
 - Time-to-live field: each increase by 1. This allows traceroute to detect each router
along the path to the destination, as routers decrement the TTL by 1, and packets
with a TTL of 0 are discarded.
- Identification field: This field changes for each datagram sent, providing a unique
identifier for each IP packet, which helps with packet reassembly if fragmentation
occurs.
- UDP Destination Port: Traceroute changes the destination port for each packet to
differentiate them. This helps in identifying responses from intermediate routers
or the final destination, as each response can be matched to a specific destination
port.

8. Which fields in this sequence of IP datagrams (containing UDP segments) stay

constant? Why?
- Source IP Address: Your computer’s IP address.
- Destination IP Address: The IP of the destination
- Protocol Field: Should remain set to UDP (17) if all packets are UDP.
- Differentiated Services Field: This is generally unchanged unless altered for
specific QoS settings.

9. Describe the pattern you see in the values in the Identification field of the IP
datagrams being sent by your computer.
- The Identification field typically increments sequentially for each new packet
sent. This is common in IP datagrams as each packet is given a unique ID,
allowing them to be individually tracked and helping with reassembly if
fragmentation occurs.

Now let’s take a look at the ICMP packets being returned to your computer by the
intervening routers where the TTL value was decremented to zero (and hence caused the
ICMP error message to be returned to your computer). The display filter that you can use
to show just these packets is “[Link]==[Link] and icmp”.
10. What is the upper layer protocol specified in the IP datagrams returned from the
routers? [Note: the answers for Linux/MacOS differ from Windows here].
- The upper layer protocol specified in the IP datagrams returned by the routers
is ICMP (Internet Control Message Protocol).
- On macOS, traceroute sends UDP packets with increasing TTL values. When a
router receives a packet with a TTL that expires (reaches 0), it responds with an
ICMP Time-to-Live Exceeded message to inform the sender that the packet was
dropped.

11. Are the values in the Identification fields (across the sequence of all of ICMP
packets from all of the routers) similar in behavior to your answer to question 9
above?
- No, the Identification fields in the ICMP packets from the routers don’t follow the
same sequential pattern as my outgoing packets. Each router independently sets
its own Identification value, so they don’t form a sequence across different
routers.
12. Are the values of the TTL fields similar, across all of ICMP packets from all of
the routers?
- The TTL values are consistent within each router’s ICMP responses, but they
differ between routers. Each router has its own starting TTL value, which stays
the same within that router’s packets but varies from other routers.
Part 2: Fragmentation

In this section, we’ll look at a large (3000-byte) UDP segment sent by the traceroute
program that is fragmented into multiple IP datagrams. We recommend that you first
consult the material on IP fragmentation from the 7th edition of our textbook (and earlier)
at [Link]

Sort the packet listing from Part 1, with any display filters cleared, according to time, by
clicking on the Time column.

13. Find the first IP datagram containing the first part of the segment sent to
[Link] sent by your computer via the traceroute command to
[Link], after you specified that the traceroute packet length
should be 3000. (Hint: This is packet 179 in the [Link] trace
file in footnote 2. Packets 179, 180, and 181 are three IP datagrams created by
fragmenting the first single 3000-byte UDP segment sent to [Link]).
Has that segment been fragmented across more than one IP datagram? (Hint: the
answer is yes4!)
- Yes, the 3000-byte UDP segment was fragmented. Packets 179, 180, and
181 represent fragments.

4
Note: if you find your packet has not been fragmented, you should download the zip file in footnote 2 and
extract the trace file [Link] . If your computer has an Ethernet or WiFi interface, a
packet size of 3000 should cause fragmentation.
 14. What information in the IP header indicates that this datagram been fragmented?
- The More Fragments (MF) flag in the IP header is set to 1 for packets 179 and
180, indicating there are more fragments.

15. What information in the IP header for this packet indicates whether this is the first
fragment versus a latter fragment?
- The "Fragment Offset" field in the first fragment is set to 0, indicating it is the
start of the fragmented datagram. Later fragments will have a non-zero offset
value.

16. How many bytes are there in is this IP datagram (header plus payload)?
- The Total Length field in packet 179 shows 1500 bytes, which includes the IP
header and payload.

17. Now inspect the datagram containing the second fragment of the fragmented UDP
segment. What information in the IP header indicates that this is not the first
datagram fragment?
- In packet 180, the Fragment Offset is non-zero, showing it’s a subsequent
fragment, and the MF flag is still 1.

18. What fields change in the IP header between the first and second fragment?
- The Fragment Offset and Identification fields differ between packets 179 and 180.

19. Now find the IP datagram containing the third fragment of the original UDP
segment. What information in the IP header indicates that this is the last fragment
of that segment?
- In the middle pane of packet 181 (the third and last fragment), the More
Fragments flag is set to 0, indicating it’s the final fragment of the 3000-byte
segment.

Part 3: ICMP
Let’s begin our ICMP adventure by capturing the packets generated by the Ping program.
You may recall that the Ping program is simple tool that allows anyone (for example, a
network administrator) to verify if a host is live or not. The Ping program in the source
host sends a packet to the target IP address; if the target is live, the Ping program in the
target host responds by sending a packet back to the source host. As you might have
guessed (given that this lab is about ICMP), both of these Ping packets are ICMP packets.

Do the following5:

5
If you are unable to run Wireshark live on a computer, you can download the zip file
[Link] and extract the file ICMP-ethereal-trace-1.
The traces in this zip file were collected by Wireshark running on one of the author’s computers, while
performing the steps indicated in the Wireshark lab. Once you have downloaded the trace, you can load it
into Wireshark and view the trace using the File pull down menu, choosing Open, and then selecting the
ICMP-ethereal-trace-1 trace file. You can then use this trace file to answer the questions below.
  Let’s begin this adventure by opening the Windows Command Prompt application
(which can be found in your Accessories folder).
 Start up the Wireshark packet sniffer, and begin Wireshark packet capture.
 The ping command is in c:\windows\system32, so type either “ping –n 10
hostname” or “c:\windows\system32\ping –n 10 hostname” in the MS-DOS
command line (without quotation marks), where hostname is a host on another
continent. If you’re outside of Asia, you may want to enter [Link] for the
Web server at Hong Kong University of Science and Technology. The argument
“-n 10” indicates that 10 ping messages should be sent. Then run the Ping
program by typing return.
 When the Ping program terminates, stop the packet capture in Wireshark.

At the end of the experiment, your Command Prompt Window should look something
like Figure 3. In this example, the source ping program is in Massachusetts and the
destination Ping program is in Hong Kong. From this window we see that the source ping
program sent 10 query packets and received 10 responses. Note also that for each
response, the source calculates the round-trip time (RTT), which for the 10 packets is on
average 375 msec.

Figure 3 Command Prompt window after entering Ping command.

Figure 4 provides a screenshot of the Wireshark output, after “icmp” has been entered
into the filter display window. Note that the packet listing shows 20 packets: the 10 Ping
queries sent by the source and the 10 Ping responses received by the source. Also note
that the source’s IP address is a private address (behind a NAT) of the form 192.168/12;
the destination’s IP address is that of the Web server at HKUST. Now let’s zoom in on
the first packet (sent by the client); in the figure below, the packet contents area provides
information about this packet. We see that the IP datagram within this packet has
protocol number 01, which is the protocol number for ICMP. This means that the payload
of the IP datagram is an ICMP packet.

Figure 4 Wireshark output for Ping program with Internet Protocol expanded.

Figure 5 focuses on the same ICMP but has expanded the ICMP protocol information in
the packet contents window. Observe that this ICMP packet is of Type 8 and Code 0 - a
so-called ICMP “echo request” packet. (See Figure 5.19 of text.) Also note that this
ICMP packet contains a checksum, an identifier, and a sequence number.
 Figure 5 Wireshark capture of ping packet with ICMP packet expanded.

What to Hand In:

You should hand in a screen shot of the Command Prompt window similar to Figure 1
above. Whenever possible, when answering a question below, you should hand in a
printout of the packet(s) within the trace that you used to answer the question asked.
Annotate the printout6 to explain your answer. To print a packet, use File->Print, choose
Selected packet only, choose Packet summary line, and select the minimum amount of
packet detail that you need to answer the question.

You should answer the following questions:

6
What do we mean by “annotate”? If you hand in a paper copy, please highlight where in the printout
you’ve found the answer and add some text (preferably with a colored pen) noting what you found in what
you ‘ve highlight. If you hand in an electronic copy, it would be great if you could also highlight and
annotate.
 1. What is the IP address of your host? What is the IP address of the destination
host?
2. Why is it that an ICMP packet does not have source and destination port
numbers?
3. Examine one of the ping request packets sent by your host. What are the ICMP
type and code numbers? What other fields does this ICMP packet have? How
many bytes are the checksum, sequence number and identifier fields?
4. Examine the corresponding ping reply packet. What are the ICMP type and code
numbers? What other fields does this ICMP packet have? How many bytes are the
checksum, sequence number and identifier fields?

Part 4: IPv6

In this final section we’ll take a quick look at the IPv6 datagram using Wireshark. You’ll
probably want to review section 4.3.4 in the text. Because the Internet is still primarily at
IPv4 network (see section 4.3.4), and your own computer or your ISP may not be
configured for IPv6, let’s look at a trace of already captured packets that contain some
IPv6 packets. To generate this trace, our web browser opened the [Link]
homepage. Youtube (and Google) provide fairly widespread support for IPv6.

Open the file [Link] in the .zip file of traces given in footnote 2. Your
Wireshark display should look similar to Figure 6.

Figure 6: Wireshark screenshot, showing the first set of captured packets in ip-wireshark-trace2-
[Link]. If you look at the Source column, you’ll see some IPv6 addresses!

Let’s start by taking a closer look at the 20th packet in this trace, sent at t=3.814489. This
is a DNS request (contained in an IPv6 datagram) to an IPv6 DNS server for the IPv6
address of [Link]. The DNS AAAA request type is used to resolve names to IPv6
IP addresses.

Answer the following questions:

20. What is the IPv6 address of the computer making the DNS AAAA request? This
is the source address of the 20th packet in the trace. Give the IPv6 source address
for this datagram in the exact same form as displayed in the Wireshark window7.
21. What is the IPv6 destination address for this datagram? Give this IPv6 address in
the exact same form as displayed in the Wireshark window.
22. What is the value of the flow label for this datagram?
23. How much payload data is carried in this datagram?
24. What is the upper layer protocol to which this datagram’s payload will be
delivered at the destination?

Lastly, find the IPv6 DNS response to the IPv6 DNS AAAA request made in the 20th
packet in this trace. This DNS response contains IPv6 addresses for [Link].
25. How many IPv6 addresses are returned in the response to this AAAA request?
26. What is the first of the IPv6 addresses returned by the DNS for [Link] (in
the [Link] trace file, this is also the address that is
numerically the smallest)? Give this IPv6 address in the exact same shorthand
form as displayed in the Wireshark window.

7
Recall that an IPv6 address is shown as 8 sets of 4 hexadecimal digits, with each set separated by colons,
and with leading zeros omitted. If an IPv6 address has two colons in a row (‘::’), this is shorthand meaning
that all of the intervening bytes between the two colons are zero. Thus, for example,
fe80::1085:6434:583:e79 is shorthand for
[Link]. Make sure you understand this example.