Hope the following information will help to understand clear about fragmentation and re-assembly.
Fragmentation
When a router receives a packet, it examines the destination address
and determines the outgoing interface to use and that interface's MTU.
If the packet size is bigger than the MTU, and the Do not Fragment (DF)
bit in the packet's header set to 0; the router may fragment the packet.
The router divides the packet into segments. The max size of each
segment is the MTU minus the IP header size (20 bytes minimum; 60 bytes
maximum). The router puts each segment into its own packet, each
fragment packet having following changes:
- The total length field is the segment size.
- The more fragments (MF) flag is set for all segments except the last one, which is set to 0.
- The fragment offset field is set, based on the offset of the segment in the original data payload. This is measured in units of eight-byte blocks.
- The header checksum field is recomputed.
For example, for an MTU of 1,500 bytes and a header size of 20 bytes,
the fragment offsets would be multiples of (1500–20)/8 = 185. These
multiples are 0, 185, 370, 555, 740, ...
It is possible for a packet to be fragmented at one router, and for
the fragments to be fragmented at another router. For example, consider a
packet with a data size of 4,500 bytes, no options, and a header size
of 20 bytes. So the packet size is 4,520 bytes. Assume that the packet
travels over a link with an MTU of 2,500 bytes. Then it will become two
fragments:
| Fragment |
Total bytes |
Header bytes |
Data bytes |
"More fragments" flag |
Fragment offset (8-byte blocks) |
| 1 |
2500 |
20 |
2480 |
1 |
0 |
| 2 |
2040 |
20 |
2020 |
0 |
310 |
Note that the fragments preserve the data size: 2480 + 2020 = 4500.
Note how we get the offsets from the data sizes:
Assume that these fragments reach a link with an MTU of 1,500 bytes. Each fragment will become two fragments:
| Fragment |
Total bytes |
Header bytes |
Data bytes |
"More fragments" flag |
Fragment offset (8-byte blocks) |
| 1 |
1500 |
20 |
1480 |
1 |
0 |
| 2 |
1020 |
20 |
1000 |
1 |
185 |
| 3 |
1500 |
20 |
1480 |
1 |
310 |
| 4 |
560 |
20 |
540 |
0 |
495 |
Note that the fragments preserve the data size: 1480 + 1000 = 2480, and 1480 + 540 = 2020.
Note how we get the offsets from the data sizes:
- 0.
- 0 + 1480/8 = 185
- 185 + 1000/8 = 310
- 310 + 1480/8 = 495
We can use the last offset and last data size to calculate the total data size: 495*8 + 540 = 3960 + 540 = 4500.
 |
| Fragmentation & Re-assembly |
Reassembly
A receiver knows that a packet is a fragment if at least one of the following conditions is true:
- The "more fragments" flag is set. (This is true for all fragments except the last.)
- The "fragment offset" field is nonzero. (This is true for all fragments except the first.)
The receiver identifies matching fragments using the identification
field. The receiver will reassemble the data from fragments with the
same identification field using both the fragment offset and the more
fragments flag. When the receiver receives the last fragment (which has
the "more fragments" flag set to 0), it can calculate the length of the
original data payload, by multiplying the last fragment's offset by
eight, and adding the last fragment's data size. In the example above,
this calculation was 495*8 + 540 = 4500 bytes.
When the receiver has all the fragments, it can put them in the
correct order, by using their offsets. It can then pass their data up
the stack for further processing.
****Thanks to Wikipedia****
