IP Fragmentation and Reassembly


Got from this post.

“Ans 1: Regarding the lengths of the packet: The original Packet contains 4000 Bytes. This packet is a fully IP packet and hence contains the IP header as well . Thus the payload length is actually 4000 – ( IP Header Length i. e. 20 ).

Actual Payload Length = 4000 – 20 = 3980

Now the packet is fragmented owing to the fact that the length is greater than the MTU ( 1500 Bytes).

Thus the 1st packet contains 1500 Bytes which includes IP header + Payload Fraction.

1500 = 20 ( IP header ) + 1480 ( Data Payload )

Similarly for the other packet.

The third packet shall contain remaining left over data ( 3980 – 1480 -1480 ) = 1020

Thus length of the packet is 20 ( IP Header ) + 1020 ( payload ) = 1040


Ans 2: The offset is the address or the locator from where the data starts with reference to the original data payload. For IP the data payload comprises all the data thats after the IP header and Options header. Thus the system/router takes the payload and divides it into smaller parts and keeps the track of the offset with reference to the original packet so that reassembly can be done.

As given in the RFC Page 12.

The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams.

The fragment offset is measured in Units of 8 bytes each. It has 13 bit field in the IP header. As said in the RFC page 17

This field indicates where in the datagram this fragment belongs.The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero.

Thus as you asked in the question where did this 8 come from, its the standard thats been defined for IP protocol specification, where 8 octets are taken as one value. This also helps us to transmit large packets via this.

Page 28 of the RFC writes: *Fragments are counted in units of 8 octets. The fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information (MF = 0, fragment offset = 0). If an internet datagram is fragmented, its data portion must be broken on 8 octet boundaries. This format allows 2**13 = 8192 fragments of 8 octets each for a total of 65,536 octets. Note that this is consistent with the the datagram total length field (of course, the header is counted in the total length and not in the fragments).*


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s