MITS4004 Research Study 1 Topics 1. ICMP 2. IP 2 Instructions 1. Form a group of 2 students in the same session. It is your choice which student you want to team but your group mate should be fixed...

wireshark_E43F92CF-851A-4704-898E-03B5423FCC82_20181020060559_a07524.pdf
C \Use s\ ads a \ pp ata\ oca \ e p\ es a _ 3 9 C 85 0 898 03 5 3 C C 8 _ 0 8 0 0060559_a0 5 pcap g 5 tota pac ets, 0 s o
No. Time Source Destination Protocol Length Info
218 32.489450 192.168.43.186 172.217.161.4 ICMP 74 Echo (ping) request id=0x0001, seq=4/1024,
ttl=128 (reply in 219)
Frame 218: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Interface id: 0 (\Device\NPF_{E43F92CF-851A-4704-898E-03B5423FCC82})
Interface name: \Device\NPF_{E43F92CF-851A-4704-898E-03B5423FCC82}
Encapsulation type: Ethernet (1)
Arrival Time: Oct 20, 2018 06:06:32.534686000 Eastern Daylight Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1540029992.534686000 seconds
[Time delta from previous captured frame: 0.379072000 seconds]
[Time delta from previous displayed frame: 0.953204000 seconds]
[Time since reference or first frame: 32.489450000 seconds]
Frame Number: 218
Frame Length: 74 bytes (592 bits)
Capture Length: 74 bytes (592 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Universa_57:a2:8d (cc:52:af:57:a2:8d), Dst: Motorola_1d:f2:6d (a8:96:75:1d:f2:6d)
Destination: Motorola_1d:f2:6d (a8:96:75:1d:f2:6d)
Address: Motorola_1d:f2:6d (a8:96:75:1d:f2:6d)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: Universa_57:a2:8d (cc:52:af:57:a2:8d)
Address: Universa_57:a2:8d (cc:52:af:57:a2:8d)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.43.186, Dst: 172.217.161.4
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 60
Identification: 0x7f2b (32555)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
...0 0000 0000 0000 = Fragment offset: 0
Time to live: 128
Protocol: ICMP (1)
Header checksum: 0x8155 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.43.186
Destination: 172.217.161.4
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4d57 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 4 (0x0004)
Sequence number (LE): 1024 (0x0400)
[Response frame: 219]
Data (32 bytes)
0000 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 abcdefghijklmnop
0010 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 qrstuvwabcdefghi
Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
[Length: 32]
first fragment packet.pdf
C \Use s\ ads a \ pp ata\ oca \ e p\ es a _ 3 9 C 85 0 898 03 5 3 C C 8 _ 0 8 0 330 _a05 60 pcap g 3 0 tota pac ets, 39 s o
No. Time Source Destination Protocol Length Info
415 43.227822 192.168.1.2 128.119.245.12 ICMP 534 Echo (ping) request id=0x0001, seq=474/55809,
ttl=255 (reply in 435)
Frame 415: 534 bytes on wire (4272 bits), 534 bytes captured (4272 bits) on interface 0
Ethernet II, Src: Universa_57:a2:8d (cc:52:af:57:a2:8d), Dst: HuaweiTe_2c:65:95 (8c:15:c7:2c:65:95)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 128.119.245.12
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 520
Identification: 0x0543 (1347)
Flags: 0x00b9
Time to live: 255
Protocol: ICMP (1)
Header checksum: 0x7cca [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.1.2
Destination: 128.119.245.12
[2 IPv4 Fragments (1980 bytes): #414(1480), #415(500)]
[Frame: 414, payload: 0-1479 (1480 bytes)]
[Frame: 415, payload: 1480-1979 (500 bytes)]
[Fragment count: 2]
[Reassembled IPv4 length: 1980]
[Reassembled IPv4 data: 08003a69000101da20202020202020202020202020202020...]
Internet Control Message Protocol
qfile_636755272831417657_122687_1.docx
MITS4004
Research Study
1
1. ICMP and Ping
1. What is the IP address of your host? What is the IP address of the destination host?
Internet Protocol Version 4
Source Host: 192.168.43.186
Destination Host: 172.217.161.4
2. Why is it that an ICMP packet does not have source and destination port numbers?
Port number are a feature of application layer interface. ICMP protocol doesn’t deal with any application layer process. All ICMP packet information is consumed and replied at the network level itself.
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?
ICMP is of type 8 having code number 0.
ICMP packet also comprises of Checksum (2 bytes), identifiers (2 bytes), sequence numbers(2 bytes), and data.
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?
The ICMP reply packet is of type 0 and code number 0. Other fields of the packet are checksum (2 bytes), identifiers (2 Bytes), sequence numbers (2 bytes) and data bytes.
2. ICMP and Traceroute
Answer the following questions:
5. What is the IP address of your host? What is the IP address of the target destination host?
Host IP: 192.93.122.19
Destination IP: 128.93.162.84
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?
IP protocol number would change. ICMP Packet number would be 0x11 in place of 01.
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?
ICMP echo packet is same as the ICMP ping query packet.
8. Examine the ICMP error packet in your screenshot. It has more fields than the ICMP echo packet. What is included in those fields?
ICMP Error packet contains more information than ICMP echo packet in its reply. The fields contain the original IP header in the ICMP request and some data bytes of the packet sent.
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?
In normal echo reply packets received by the host, the message type is 0 in place of 11. The message type changed because data could reach the destination host and solicit a response from it.
10. Within the tracert measurements, is there a link whose delay is significantly longer than others? Refer to the screenshot in Figure 4, is there a link whose delay is significantly longer than others? On the basis of the router names, can you guess the location of the two routers on the end of this link?
The longest time it took was at hop number 19 to 20 from Germany to Spain. In figure 4
from the lab, the link is from New York to Pastourelle, France.
1. A look at the captured trace
In your trace, you should be able to see the series of ICMP Echo Request (in the case of Windows machine) or the UDP segment (in the case of Unix) sent by your computer and the ICMP TTL-exceeded messages returned to your computer by the intermediate routers. In the questions below, we’ll assume you are using a Windows machine; the corresponding questions for the case of a Unix machine should be clear. 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. When you hand in your assignment, annotate the output so that it’s clear where in the output you’re getting the information for your answer (e.g., for our classes, we ask that students markup paper copies with a pen, or annotate electronic copies with text in a colored font).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.
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?
Source IP: 192.168.1.2
Destination IP: 128.119.245.12
2. Within the IP packet header, what is the value in the upper layer protocol field?
The value in the upper layer protocol field of IP header is ICMP (0x01)
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.
IP Header consumes 20 bytes, Total length is 56 bytes, this leaves space for only 36 bytes for the data in the payload of the IP datagram.
4. Has this IP datagram been fragmented? Explain how you determined whether or not the datagram has been fragmented.
Bit indicating the fragmentation of data is not set. It is set to 0.
Next, sort the traced packets according to IP source address by clicking on the Source column header; a small downward pointing arrow should appear next to the word Source. If the arrow points up, click on the Source column header again. Select the first ICMP Echo Request message sent by your computer, and expand the Internet Protocol portion in the “details of selected packet header” window. In the “listing of captured packets” window, you should see all of the subsequent ICMP messages (perhaps with additional interspersed packets sent by other protocols running on your computer) below this first ICMP. Use the down arrow to move through the ICMP messages sent by your computer.
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?
Three fields change from one datagram to next, they are Identification, Time to live and Header checksum.
.
6. Which fields stay constant? Which of the fields must stay constant? Which fields must change? Why?
The fields that stay constant and must remain constant across the IP datagrams are:
• Version of the IP should remain fixed at IPv4
• Header length because all of these are ICMP packets
• Source IP as all packets originate from same source
• Destination IP as all packets are trying to ping the same destination
• Differentiated Services as they all are ICMP packets and use the same Type of Service class
• Upper Layer Protocol as all packets are ICMP packets
The fields that must change are:
• Identification as each IP packet must have different ids for unique identification
• Time to live value changes for each packet as traceroute increments TTL for each subsequent packet
• Header checksum changes as some of the values in the header field has changed
7. Describe the pattern you see in the values in the Identification field of the IP datagram
The identification field of the datagram increments with each ICMP echo request packet.
Next (with the packets still sorted by source address) find the series of ICMP TTL- exceeded replies sent to your computer by the nearest (first hop) router.
8. What is the value in the Identification field and the TTL field?
Identification: 58618
TTL: 64
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?
No the values change for all ICMP packets as the identification field must remain unique for each packet. The only case when Identification values remain same is when the packets are fragments of same larger datagram. But the TTL value remains the same as that is dependent upon hop distance that is fixed for the first hop router from the source.
Fragmentation
Sort the packet listing according to time again by clicking on the Time column.
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?
The packet has been fragmented across more than one IP datagram as data bytes size is 1972 bytes which is more than maximum size possible of 1480 bytes.
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?
The Flags bit in the header signifies if there are more packets for the same datagram. Since the bit is set we can say the datagram is fragmented. The fragment offset number can help identify the packet being the initial part or the latter part of the whole datagram.
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?
The fragment offset field of the packet is 1480 and not 0. This indicates that this not the initial segment. Further the more fragments bit in the header flags is not set indicating this is the last fragment of the original datagram.
13. What fields change in the IP header between the first and second fragment?
Fields that reflect the fragmentation information changed from packet 1 to packet 2. They are total length of the packet, flag bits for more fragmentation and fragmentation offset values.
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.
14. How many fragments were created from the original datagram?
Total of 3 fragments were created from the original datagram
15. What fields change in the IP header among the fragments?
Fields that reflect the fragmentation information changed in the IP header of the packets. They are fragmentation offset values and checksum. Packet 1 and 2 have same total length and flags but the values changed for packet 3 as first two packets have length of 1500 bytes each but third one is only 540 bytes. The fragementation bit also changes its value from set to clear as third packet is the last fragemented packet of the original datagram.
second fragment packet.pdf
C \Use s\ ads a \ pp ata\ oca \ e p\ es a _ 3 9 C 85 0 898 03 5 3 C C 8 _ 0 8 0 330 _a05 60 pcap g 3 0 tota pac ets, 39 s o
No. Time Source Destination Protocol Length Info
415 43.227822 192.168.1.2 128.119.245.12 ICMP 534 Echo (ping) request id=0x0001, seq=474/55809,
ttl=255 (reply in 435)
Frame 415: 534 bytes on wire (4272 bits), 534 bytes captured (4272 bits) on interface 0
Ethernet II, Src: Universa_57:a2:8d (cc:52:af:57:a2:8d), Dst: HuaweiTe_2c:65:95 (8c:15:c7:2c:65:95)
Internet Protocol Version 4, Src: 192.168.1.2, Dst: 128.119.245.12
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 520
Identification: 0x0543 (1347)
Flags: 0x00b9
Time to live: 255
Protocol: ICMP (1)
Header checksum: 0x7cca [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.1.2
Destination: 128.119.245.12
[2 IPv4 Fragments (1980 bytes): #414(1480), #415(500)]
[Frame: 414, payload: 0-1479 (1480 bytes)]
[Frame: 415, payload: 1480-1979 (500 bytes)]
[Fragment count: 2]
[Reassembled IPv4 length: 1980]
[Reassembled IPv4 data: 08003a69000101da20202020202020202020202020202020...]
Internet Control Message Protocol