---
tags: Computer Network
---
# NCCUCS NET22 Lab03

## 6-1
**Select the first ICMP Echo Request message sent by your computer, and expand the Internet Protocol part of the packet in the packet details window. What is the IP address of your computer?**

:::success

192.168.0.235
:::

<br>

## 6-2
**Within the IP packet header, what is the value in the upper layer protocol field?**

:::success

Within the header, the value in the upper layer protocol field is ICMP (0x01)
:::

<br>

## 6-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.**

:::success

There are 20 bytes in the IP header, and 56 bytes total length, this gives 36 bytes in the payload of the IP datagram.
:::

<br>

## 6-4
**Has this IP datagram been fragmented? Explain how you determined whether or not the datagram has been fragmented.**

:::success

The more fragments bit = 0, so the data is not fragmented.
:::

<br>

## 6-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.**

:::success

Identification, Time to live and Header checksum always change.
:::

<br>

## 6-6
**Which fields stay constant? Which of the fields must stay constant? Which fields must change? Why?**

:::success
The fields that stay constant across the IP datagrams are:
- Version (since we are using IPv4 for all packets)
- header length (since these are ICMP packets)
- source IP (since we are sending from the same source)
- destination IP (since we are sending to the same dest)
- Differentiated Services (since all packets are ICMP they use the same
Type of Service class)
- Upper Layer Protocol (since these are ICMP packets)
<br>

The fields that must stay constant are:
- Version (since we are using IPv4 for all packets)
- header length (since these are ICMP packets)
- source IP (since we are sending from the same source)
- destination IP (since we are sending to the same dest)
- Differentiated Services (since all packets are ICMP they use the same
Type of Service class)
- Upper Layer Protocol (since these are ICMP packets)

<br>

The fields that must change are:
- Identification(IP packets must have different ids)
- Time to live (traceroute increments each subsequent packet)
- Header checksum (since header changes, so must checksum)
:::

<br>

## 6-7
**Describe the pattern you see in the values in the Identification field of the IP datagram.**

:::success
The pattern is that the IP header Identification fields increment with each ICMP Echo (ping) request.
:::

<br>

## 6-8
**What is the value in the Identification field and the TTL field?**

:::success

Identification: 0x0cb7 (3255)
TTL: 64
:::

<br>

## 6-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?**

:::success
The identification field changes for all the ICMP TTL-exceeded replies because the identification field is a unique value. When two or more IP datagrams have the same identification value, then it means that these IP datagrams are fragments of a single large IP datagram.

The TTL field remains unchanged because the TTL for the first hop router is always the same.
:::

<br>

## 6-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?**

:::success

Yes, this packet has been fragmented across more than one IP datagram.
:::

<br>

## 6-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?**

:::success

The Flags bit for more fragments is set, indicating that the datagram has been fragmented. Since the fragment offset is 0, we know that this is the first fragment. This first datagram has a total length of 1500, including the header.
:::

<br>

## 6-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 the more fragments? How can you tell?**

:::success

We can tell that this is not the first fragment, since the fragment offset is 1480. It is the last fragment, since the more fragments flag is not set.

:::

<br>

## 6-13
**What fields change in the IP header between the first and second fragment?**

:::success
The IP header fields that changed between the fragments are: total length, flags, fragment offset, and checksum.
:::

<br>

## 7-1
**What is the IP address of the client?**

:::success

192.168.1.100
:::

<br>

## 7-2
**Consider now the HTTP GET sent from the client to the Google server (whose IP address is IP address 64.233.169.104) at time 7.109267. What are the source and destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP GET?**

:::success


Source: 192.168.1.100, 4335
Destination: 64.233.169.104, 80
:::

<br>

## 7-3
**At what time is the corresponding 200 OK HTTP message received from the Google server? What are the source and destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP 200 OK message?**

:::success

Time: 7.158798
Source: 64.233.169.104, 80
Destination: 192.168.1.100, 4335
:::

<br>

## 7-4
**Recall that before a GET command can be sent to an HTTP server, TCP must first set up a connection using the three-way SYN/ACK handshake. At what time is the client-to-server TCP SYN segment sent that sets up the connection used by the GET sent at time 7.109267? What are the source and destination IP addresses and source and destination ports for the TCP SYN segment? What are the source and destination IP addresses and source and destination ports of the ACK sent in response to the SYN. At what time is this ACK received at the client? (Note: to find these segments you will need to clear the Filter expression you entered above in step 2. If you enter the filter “tcp”, only TCP segments will be displayed by Wireshark)**

:::success

(1) 7.075657
(2) Source: 192.168.1.100, 4335 Destination: 64.233.169.104,80
(3) Source: 64.233.169.104, 80 Destination: 192.168.1.100, 4335
(4) 7.108986
:::

<br>

## 7-5
**In the NAT_ISP_side trace file, find the HTTP GET message was sent from the client to the Google server at time 7.109267 (where t=7.109267 is time at which this was sent as recorded in the NAT_home_side trace file). At what time does this message appear in the NAT_ISP_side trace file? What are the source and destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP GET (as recording in the NAT_ISP_side trace file)? Which of these fields are the same, and which are different, than in your answer to question 7-2 above?**

:::success

(1) 6.069168
(2) Source: 71.192.34.104, 4335 Destination: 64.233.169.104, 80
(3) only the source IP address has changed
:::

<br>

## 7-6
**Are any fields in the HTTP GET message changed? Which of the following fields in the IP datagram carrying the HTTP GET are changed: Version, Header Length, Flags, Checksum. If any of these fields have changed, give a reason (in one sentence) stating why this field needed to change.**

:::success
(1) No fields in HTTP GET message changed.
(2) Version, Header Length, Flags : No. Checksum: Yes
(3) Since the IP source address has changed, and the checksum includes the value of the source IP address, the checksum has changed.
:::

<br>

## 7-7
**In the NAT_ISP_side trace file, at what time is the first 200 OK HTTP message received from the Google server? What are the source and destination IP addresses and TCP source and destination ports on the IP datagram carrying this HTTP 200 OK message? Which of these fields are the same, and which are different than your answer to question 7-3 above?**

:::success

(1) 6.117570
(2) Source: 64.233.169.104, 80 Destination: 71.192.34.104, 4335
(3) only the destination IP address has changed
:::

<br>

## 7-8
**In the NAT_ISP_side trace file, at what time were the client-to-server TCP SYN segment and the server-to-client TCP ACK segment corresponding to the segments in question 7-4 above captured? What are the source and destination IP addresses and source and destination ports for these two segments? Which of these fields are the same, and which are different than your answer to question 7-4 above?**

:::success
(1) client-to-server TCP SYN segment : 6.035475 (Identification: 0xa2aa)
(2) server-to-client TCP ACK segment : 6.067775
(Identification: 0xf61a)
(3) For the SYN: Source: 71.192.34.104, 4335 Destination: 64.233.169.104, 80.
(4) For the ACK: Source: 64.233.169.104, 80 Destination: 71.192.34.104, 4335
(5) For the SYN, the source IP address has changed, for the ACK, the destination IP address has changed. The port numbers are unchanged)
:::

<br>

## 7-9
**Using your answers to 1-8 above, fill in the NAT translation table entries for HTTP connection considered in questions 1-8 above.**

:::success
<img src="https://cdn.mathpix.com/snip/images/Wb2esaXIMHMO1g4if_V8AsT_2Jtqy1_FSACHv7G7kGU.original.fullsize.png" />
:::

<br>

## 8-1
**What is the IP address of your host? What is the IP address of the destination host?**

:::success

The IP address of my host is 192.168.1.101.
The IP address of the destination host is 143.89.14.34.
:::

<br>

## 8-2
**Why is it that an ICMP packet does not have source and destination port numbers?**

:::success
It's because ICMP is designed for Network Layer.
:::

<br>

## 8-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?**

:::success

The ICMP type is 8, and the code number is 0.
The ICMP packet also has checksum, identifier, sequence number, and data fields.
The checksum, sequence number and identifier fields are two bytes each.
:::

<br>

## 8-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?**

:::success

The ICMP type is 0, and the code number is 0.
The ICMP packet also has checksum, identifier, sequence number, and data fields.
The checksum, sequence number and identifier fields are two bytes each.
:::

<br>

## 8-5
**What is the IP address of your host? What is the IP address of the target destination host?**

:::success

The IP address of my host is 192.168.1.101.
The IP address of the destination host is 138.96.146.2.
:::

<br>

## 8-6
**If ICMP sent UDP packets instead (as in Unix/Linux), would the IP protocol number still be 01 for the probe packets? If not, what would it be?**

:::success

No. If ICMP sent UDP packets instead, the IP protocol number should be 0x11.
:::

<br>

## 8-7
**Examine the ICMP echo packet in your screenshot. Is this different from the ICMP ping query packets in the first half of this lab? If yes, how so?**

:::success

The ICMP echo packet has the same fields as the ping query packets.
:::

<br>

## 8-8
**Examine the ICMP error packet in your screenshot. It has more fields than the ICMP echo packet. What is included in those fields?**

:::success
The ICMP error packet is not the same as the ping query packets.
It contains both the IP header and the first 8 bytes of the original ICMP packet that the error is for.
:::

<br>

## 8-9
**Examine the last three ICMP packets received by the source host. How are these packets different from the ICMP error packets? Why are they different?**

:::success


The last three ICMP packets are message type 0 (echo reply) rather than 11(TTL expired).
They are different because the datagrams have made it all the way to the destination host before the TTL expired.
:::

<br>

## 9-1
**What is the 48-bit Ethernet address of your computer?**

:::success

00:d0:59:a9:3d:68
:::

<br>

## 9-2
**What is the 48-bit destination address in the Ethernet frame? Is this the Ethernet address of gaia.cs.umass.edu? What device has this as its Ethernet address?**

:::success

The destination address 00:06:25:da:af:73 is not
the Ethernet address of gaia.cs.umass.edu.
It is the address of my Linksys router, which is the link used to get off the subnet.
:::

<br>

## 9-3
**Give the hexadecimal value for the two-byte Frame type field. What upper layer protocol does this correspond to?**

:::success

Hex Value: 0x0800, upper layer protocal is IP.
:::

<br>

## 9-4
**How many bytes from the very start of the Ethernet frame does the ASCII “G” in “GET” appear in the Ethernet frame?**

:::success


The ASCII “G” appears 52 bytes from the
start of the Ethernet frame.
There are 14 B Ethernet frame, and then 20 bytes of IP header followed by 20 bytes of TCP header before the HTTP data is encountered.
:::

<br>

## 9-5
**What is the value of the Ethernet source address? Is this the address of your computer, or of gaia.cs.umass.edu?**

:::success

The source address 00:06:25:da:af:73 is neither the
Ethernet address of gaia.cs.umass.edu nor the address of my computer.
It is the address of my Linksys router, which is the link used to get onto my subnet.
:::

<br>

## 9-6
**What is the destination address in the Ethernet frame? Is this the Ethernet address of your computer?**

:::success

The destination address 00:d0:59:a9:3d:68 is the MAC address of my computer.
:::

<br>

## 9-7
**Give the hexadecimal value for the two-byte Frame type field. What upper layer protocol does this correspond to?**

:::success

Hex Value: 0x0800, upper layer protocal is IP.
:::

<br>

## 9-8
**How many bytes from the very start of the Ethernet frame does the ASCII “O” in “OK” (i.e., the HTTP response code) appear in the Ethernet frame?**

:::success

14+20+20+13 = 67 (bytes)
:::

<br>

## 9-9
**Write down the contents of your computer’s ARP cache. What is the meaning of each column value?**

:::success

The Internet Address column contains the IP address, the
Physical Address column contains the MAC address, and the type indicates the protocol type.
:::

<br>

## 9-10
**What are the hexadecimal values for the source and destination addresses in the Ethernet frame containing the ARP request message?**

:::success

The hex value for the source address is 00:d0:59:a9:3d:68.
The hex value for the destination address is ff:ff:ff:ff:ff:ff, the broadcast address.
:::

<br>

## 9-11
**Give the hexadecimal value for the two-byte Ethernet Frame type field. What upper layer protocol does this correspond to? What are the hexadecimal values for the source and destination addresses in the Ethernet frame containing the ARP reply message?**

:::success

The hex value for the Ethernet Frame type field is 0x0806, for ARP.
:::

<br>

## 9-12
**Download the ARP specification from ftp://ftp.rfc-editor.org/in-notes/std/std37.txt. A readable, detailed discussion of ARP is also at http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html. How many bytes from the very beginning of the Ethernet frame does the ARP opcode field begin? What is the value of the opcode field within the ARP-payload part of the Ethernet frame in which an ARP request is made? Does the ARP message contain the IP address of the sender? Where in the ARP request does the “question” appear – the Ethernet address of the machine whose corresponding IP address is being queried?**

:::success
(a.)The ARP opcode field begins 20 bytes from the very beginning of the Ethernet frame.
(b.)The hex value for opcode field withing the ARP-payload of the request is 0x0001, for request.
(c.)Yes, the ARP message containing the IP address 192.168.1.105 for the sender.
(d.)The field “Target MAC address” is set to 00:00:00:00:00:00 to question the machine whose corresponding IP address (192.168.1.1) is being queried.
:::

<br>

## 10-1
**Are DHCP messages sent over UDP or TCP?**

:::success

They're sent over UDP.
:::

<br>

## 10-2
**Draw a timing datagram illustrating the sequence of the first four-packet Discover/Offer/Request/ACK DHCP exchange between the client and server. For each packet, indicated the source and destination port numbers. Are the port numbers the same as in the example given in this lab assignment?**

:::success

:::

<br>

## 10-3
**What is the link-layer (e.g., Ethernet) address of your host?**

:::success

00:06:25:da:af:73
:::

<br>

## 10-4
**What values in the DHCP discover message differentiate this message from the DHCP request message?**

:::success


The values which differentiate the Discover message from the Request message are in “Option: (t=53,l=1) DHCP Message Type”
:::

<br>

## 10-5
**What is the value of the Transaction-ID in each of the first four (Discover/Offer/Request/ACK) DHCP messages? What are the values of the Transaction-ID in the second set (Request/ACK) set of DHCP messages? What is the purpose of the Transaction-ID field?**

:::success

Discover - Transaction ID 0x3e5e0ce3
Offer - Transaction ID 0x3e5e0ce3
Request - Transaction ID 0x3e5e0ce3
ACK - Transaction ID 0x3e5e0ce3
Next - Transaction ID 0x257e55a3

A Transaction ID is used so that the DHCP server can differentiate between client requests during the request process.
:::

<br>

## 10-6
**A host uses DHCP to obtain an IP address, among other things. But a host’s IP address is not confirmed until the end of the four-message exchange! If the IP address is not set until the end of the four-message exchange, then what values are used in the IP datagrams in the four-message exchange? For each of the four DHCP messages (Discover/Offer/Request/ACK DHCP), indicate the source and destination IP addresses that are carried in the encapsulating IP datagram.**

:::success

The DCHP client and server both use 255.255.255.255 as the destination address. The client uses source IP address 0.0.0.0, while the server uses its actual IP address as the source.
:::

<br>

## 10-7
**What is the IP address of your DHCP server?**

:::success

192.168.1.1
:::

<br>

## 10-8
**What IP address is the DHCP server offering to your host in the DHCP Offer message? Indicate which DHCP message contains the offered DHCP address.**

:::success

The DHCP server offered the IP address 192.168.1.101 to my client machine. The DHCP message with “DHCP Message Type = DHCP Offer” contained the offered IP.

:::

<br>

## 10-9
**What values in the trace indicate the absence of a relay agent? Is there a relay agent in your experiment? If so what is the IP address of the agent?**

:::success

The "Relay agent IP address" is 0.0.0.0, which indicates that there is no DHCP Relay used. There was no Relay Agent used in my experiment.
:::

<br>

## 10-10
**Explain the purpose of the router and subnet mask lines in the DHCP offer message.**

:::success
The router line indicates to the client what its default gateway should be. The subnet mask line tells the client which subnet mask it should use.
:::

<br>

## 10-11
**In the DHCP trace file noted in footnote 2, the DHCP server offers a specific IP address to the client (see also question 8. above). In the client’s response to the first server OFFER message, does the client accept this IP address? Where in the client’s RESPONSE is the client’s requested address?**

:::success

In my experiment, the host requests the offered IP address in the DHCP Request message.
:::

<br>

## 10-12
**Explain the purpose of the lease time. How long is the lease time in your experiment?**

:::success

The lease time in my experiment is 1 day. The purpose of this is the amount of time the DHCP server assigns an IP address to a client.
:::

<br>

## 10-13
**What is the purpose of the DHCP release message? Does the DHCP server issue an acknowledgment of receipt of the client’s DHCP request? What would happen if the client’s DHCP release message is lost?**

:::success

The client sends a DHCP Release message to cancel its lease on the IP address given to it by the DHCP server. The DHCP server does not send a message back to the client acknowledging the DHCP Release message. If the DHCP Release message from the client is lost, the DHCP server would have to wait until the lease period is over for that IP address until it could reuse it for another client.
:::

<br>

## 10-14
**Clear the bootp filter from your Wireshark window. Were any ARP packets sent or received during the DHCP packet-exchange period? If so, explain the purpose of those ARP packets.**

:::success

Yes, there are ARP requests made by the DHCP server. Before offering an IP address to a client, the DHCP server issues an ARP request for the offered IP to make sure the IP address is not already in use by another workstation.
:::

<br>