Question

1. a. In Wireshark, for packet 92, what information in the IP header indicates that the datagram has been fragmented?

b. What information in the IP header indicates whether this is the first fragment versus a latter fragment? How long is this IP datagram?

2. a. For packet 93, what information in the IP header indicates that this is not the first data fragment? Are there more fragments? If so, how can you tell?

- 0 X IP_traceFile File Edit View Go Capture Analyse Statistics Telephony Wireless Tools Help Polyadplayer... Time 83 16.413273 84 16.418267 85 16.438258 86 16.443319 87 15,463382 88 16.468603 89 16.4999:19 90 22.928093 91 22.952738 92 28.441511 93 28.442195 94 20.462264 95 28.470668 96 29.471338 97 20.498563 98 28.491323 99 28.520729 100 28.521393 191 28.538213 Source 192.168.1.192 216.148.10.32 67.99.58.194 192.168.1.192 192.168.1.102 128.59.1.41 129.59.23.182 192.168.1.102 128.119.245.12 192.168.1.102 102 160 1182 10.216.228.1 192.168.1.182 192.168.1.192 192.168.1.182 192.168.1.102 192.168.1.182 192.168.1.102 24.218.0.153 Destination 128.59.23.100 192.168.1.102 192.168.1.102 128.59.23.100 128.59.23.100 192.168.1.102 192.168.1.102 128.119.245.12 192.168.1.102 128.50.23.100 128.59.23.189 192.168.1.102 128.59.23.100 129.59.73.100 129.50.23.109 128.59.23.100 128.59.23.100 128.59.23.100 192.168.1.102 Protocol ICMP ICMP ICMP ICMP ICMP ICMP ICMP 5SH TCP IPv4 ICMP ICMP IPvd TCMP IPv4 ICMP IPv4 ICHP ICMP Length Info 98 Echo (ping) request id=0x0300, seq=29699/884, ttl=11 (no response found!) 78 Time to live exceeded (Time to live exceeded in transit) 70 Time-to-live exceeded (Time to live exceeded in transit) 98 Echo (ping) request id-8x0308, seq-29955/885, tt1-12 (no response found!) 98 Echo (pine) request id=0x0300, seq30211/886. ttl=13 (reply in 89) 70 Time to live exceeded (Tinr to live exceeded in transit) 98 Echo (pink) reply id-Ox2300, seq-30211/886, tt1-242 (request in 87) 74 Client: Encrypted packet (len=20) 60 22 1170 [ACK] Seq=1 Ack21 Win=35840 Len=0 1514 Fragmented TP protocol (proto-TCMP 1, off-e, TD-3219) [Reassembled in #93] 562 Echo (ping) requesLid-Ox0390. Seg-32467/987. lll-1 (no response found!) 78 Time-to-live exceeded (Tine to live exceeded in transit) 1514 Fraenented IP protocol (proto-ICMP 1. orr- ID=321a) [Reassembled in #961 562 Echo (pink) request id-2x308, seg-32723/888, tt1-2 (no response found!) 1514 Fragmented IP protocol (proto-ICMP i, off-, ID-32fb) (Reassembled in 198) 562 Echo (ping) request id=8x0300, seq=30979/889, ttl=3 (no response found!) 1514 Fraenented IP protocol (proto-ICMP 1, off-e, ID-32fc) [Reassembled in #100] 562 Echo (ping) request id-Ox300, seq-31235/990, tt1-4 (no response tound!) 78 Time-to-live exceeded (Time to live exceeded in transit) > Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) > Ethernet II, Sre: CnetTech_73: Bd.ce (08:Bo:ad:73:8d:ce), Dst: Broadcast (ff:ff:ff:ff:ff:ff) > Address Resolution Protocol (request) . .... ..... 8990 Ff ff ff ff ff ++ AA SAA 73 Adres 06 AA 01 0918 60 90 66 24 09 00 3e ad 73 3d ce ce a3 81 68 20 00 00 00 00 09 og coa8 /5 00 00 09 do 20 00 8030 09 00 00 00 00 AA de ce oa ee 92

Answer 1

The IP header format has the following fields below:

• Protocol Version(4 bits) : This is the first field in the protocol header. This field occupies 4 bits. This signifies the current IP protocol version being used. Most common version of IP protocol being used is version 4 while version 6 is out in market and fast gaining popularity.
• Header Length(4 bits) : This field provides the length of the IP header. The length of the header is represented in 32 bit words. This length also includes IP options (if any). Since this field is of 4 bits so the maximum header length allowed is 60 bytes. Usually when no options are present then the value of this field is 5. Here 5 means five 32 bit words ie 5 *4 = 20 bytes.
• Type of service(8 bits) : The first three bits of this field are known as precedence bits and are ignored as of today. The next 4 bits represent type of service and the last bit is left unused. The 4 bits that represent TOS are : minimize delay, maximize throughput, maximize reliability and minimize monetary cost.
• Total length(16 bits): This represents the total IP datagram length in bytes. Since the header length (described above) gives the length of header and this field gives total length so the length of data and its starting point can easily be calculated using these two fields. Since this is a 16 bit field and it represents length of IP datagram so the maximum size of IP datagram can be 65535 bytes. When IP fragmentation takes place over the network then value of this field also changes. There are cases when IP datagrams are very small in length but some data links like ethernet pad these small frames to be of a minimum length ie 46 bytes. So to know the exact length of IP header in case of ethernet padding this field comes in handy.
• Identification(16 bits): This field is used for uniquely identifying the IP datagrams. This value is incremented every-time an IP datagram is sent from source to the destination. This field comes in handy while reassembly of fragmented IP data grams.
• Flags(3 bits): This field comprises of three bits. While the first bit is kept reserved as of now, the next two bits have their own importance. The second bit represents the ‘Don’t Fragment’ bit. When this bit is set then IP datagram is never fragmented, rather its thrown away if a requirement for fragment arises. The third bit represents the ‘More Fragment’ bit. If this bit is set then it represents a fragmented IP datagram that has more fragments after it. In case of last fragment of an IP datagram this bit is not set signifying that this is the last fragment of a particular IP datagram.
• Fragment offset(13 bits): In case of fragmented IP data grams, this field contains the offset( in terms of 8 bytes units) from the start of IP datagram. So again, this field is used in reassembly of fragmented IP datagrams.
• Time to live(8 bits) : This value represents number of hops that the IP datagram will go through before being discarded. The value of this field in the beginning is set to be around 32 or 64 (lets say) but at every hop over the network this field is decremented by one. When this field becomes zero, the data gram is discarded. So, we see that this field literally means the effective lifetime for a datagram on network.
• Protocol(8 bits) : This field represents the transport layer protocol that handed over data to IP layer. This field comes in handy when the data is demultiplex-ed at the destination as in that case IP would need to know which protocol to hand over the data to.
• Header Checksum(16 bits) : This fields represents a value that is calculated using an algorithm covering all the fields in header (assuming this very field to be zero). This value is calculated and stored in header when IP data gram is sent from source to destination and at the destination side this checksum is again calculated and verified against the checksum present in header. If the value is same then the datagram was not corrupted else its assumed that data gram was received corrupted. So this field is used to check the integrity of an IP datagram.
• Source and destination IP(32 bits each) : These fields store the source and destination address respectively. Since size of these fields is 32 bits each so an IP address os maximum length of 32 bits can be used. So we see that this limits the number of IP addresses that can be used. To counter this problem, IP V6 has been introduced which increases this capacity.
• Options(Variable length) : This field represents a list of options that are active for a particular IP datagram. This is an optional field that could be or could not be present.
• In the description above, the ‘copy flag’ means that copy this option to all the fragments in case this IP datagram gets fragmented. The ‘option class’ represents the following values : 0 -> control, 1-> reserved, 2 -> debugging and measurement, and 3 -> reserved. Some of the options are given below :
• Data: This field contains the data from the protocol layer that has handed over the data to IP layer. Generally this data field contains the header and data of the transport layer protocols. Please note that each TCP/IP layer protocol attaches its own header at the beginning of the data it receives from other layers in case of source host and in case of destination host each protocol strips its own header and sends the rest of the data to the next layer.

When a packet is fragmented, we need to look at two things - Fragmentation offset and MF flag.

For the first fragment - Offset is 0 and MF is set to 1 to indicate that there are more fragments

For intermediate fragments - Offset is non zero and MF is set to 1 to indicate that there are more fragmetns

For last fragment - Offset is non zero and MF is set to 0 to indicate this is the last fragment.

For non fragmented packet - Offset is set to 0 and MF is also set to 0.

With these information, the answers are:

1) The Fragmentation offset field is 0 but MF will be set to 1 to indicate this is the first fragment

2) As explained above, since the fragmentation offset field is set to 0, this indicates it is the first fragment. Total packet size is 1514. If we subtract the Ethernet header size of 14 bytes, the IP datagram size is 1500 bytes

3) Since the wirehark capture has not been expanded to show the fields, I will explain the concept here. If fragmentation offset is non-zero, this indicates that it is not the first fragment. If the MF flag bit is set, it indicates that there are more fragments coming.