IP Fragmentation
In one of my previous posts (https://rtodto.net/2011/08/18/path-mtu-ip-fragmentation-and-mss/) , I wrote about IP fragmentation. This time I would like to show some wireshark screen shots showing a single IP packet consisting of 3 fragmentations to see the IP header fields used in fragmentation process. This IP packet is carrying an HTTP response:
List of packets in Wireshark
Fragmented IP packet #17: (first fragment)
This is the first fragment of our IP packet fields of which are:
Identification: It is 0x3382 and the same in three fragments. It helps to associate fragments belonging to the same whole packet.
More Fragments: It is 1 and means that there will be more fragments coming in.
Fragment Offset: It is 0 and it specifies the offset of the current fragment to the beginning. as this is the first fragment it is 0.
It is worth to mention that you can’t see any TCP layer here. The packet hasn’t been reassembled yet.
Fragmented IP Packet #18: (second fragment)
Fragmentation related fields are the same except the offset field which is now 552. You can see Total length is 572 and 572 – IPHL(20) = 552. You get this value once you subtract header length from the total length.
 Fragmented IP packet #19: (third and last fragment)
This the last piece of the fragments which completes the puzzle. More fragments field is 0 which means there is no more fragment. You can also see that TCP header has also been formed.
Thanks a lot man!
Fragmentation is so clear to me now 🙂
I am glad to hear this Ben!
Nice document. Clearly understood fragmentation today.
good i understood the process………
but according to theory FRAGMENT OFFSET should be equal to DATA/8 example: in 2 packet FRAGMENT OFFSET should be = 96 ( 552/8 )!!
y is it showing 552 ??
http://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly
FRAGMENT OFFSET should be = 69
( 552/8 )!!
Mahesh,
Fragment offset denotes how far (offset) the current fragment is relative to the beginning of the entire packet i.e packet before the fragmentation.
First packet has zero value as it is the beginning. Second packet’s data is 552 bytes because of which offset is 552. RFC says offset must be multiple of 8 which is fine according to 552/8 = 69. It is multiple of 8 bytes but offset cannot be 69.
Superb
This explanation was the real deal. Thank you
You’re welcome supratik!