# IP fragmentation: GATE CS question with solution

From the GATE Daily set of 27 October 2026, question 10 of 10 (https://gatedaily.in/q/2026-10-27-udp-fragments-last-offset/). Difficulty: standard.

### Q.10 · Computer Networks · IP fragmentation · MCQ, 1 mark (choose one option)

A host sends one UDP datagram carrying 2928 bytes of application data over IPv4. The UDP header is 8 bytes and every IPv4 header is 20 bytes (no options). The datagram must cross a link whose MTU is 1000 bytes, including the IP header. The DF bit is not set. Assume the router fragments greedily: while the remaining data does not fit in one fragment, it emits the largest fragment allowed and repeats on the rest; once the remaining data fits within the MTU, it sends it as the last fragment.

Which ONE of the following gives the number of IP fragments and the fragment offset field value of the last fragment?

(A) 3 fragments, offset 244
(B) 3 fragments, offset 245
(C) 4 fragments, offset 366
(D) 4 fragments, offset 2928

**Answer:** (C) 4 fragments, offset 366

**Solution.** **Method.**

1. Data that IP must carry: UDP header + application data $= 8 + 2928 = 2936$ bytes.
2. Room in one fragment: $1000 - 20 = 980$ data bytes. A **non-final** fragment must carry a multiple of 8 data bytes (the offset field counts 8-byte units), so a non-final fragment carries at most $\lfloor 980/8 \rfloor \times 8 = 976$. The **last** fragment has no such restriction and may carry up to 980.
3. Split greedily: after two fragments of 976, $2936 - 1952 = 984$ bytes remain. That is more than 980, so it cannot go as the last fragment; send another 976-byte fragment, leaving $8$ bytes for a fourth, final fragment. Fragments carry $976, 976, 976, 8$ bytes: **4 fragments**.
4. The last fragment starts at data byte $3 \times 976 = 2928$; the offset field is $2928/8 = 366$.

**The trap.** Each slip lands on a different option. Forgetting that the UDP header is data to IP leaves 2928 bytes, and after two 976-byte fragments the remaining 976 fit in a final fragment (3 fragments, offset 244). Allowing 980 bytes in non-final fragments gives $980, 980, 976$ (3 fragments, offset 245). Reporting the start position in bytes gives 2928 instead of 366. Note the asymmetry in step 2: only non-final fragments are rounded down to a multiple of 8, so always check whether the remainder fits in the full $\text{MTU} - 20$ before adding one more fragment.

**What was tested.** The fixed rules of IPv4 fragmentation: the transport header is data to IP, non-final fragments carry a multiple of 8 data bytes, the final fragment may use the full room, and the offset field counts 8-byte blocks.

**Remember:** IPv4 non-final fragments carry (MTU - IP header) rounded down to a multiple of 8 data bytes; the last fragment may use the full MTU - IP header. The transport header counts as data, and the offset field is the starting data byte divided by 8.

**Why each option:**
- (A) Forgets the 8-byte UDP header: IP must carry 2936 bytes, and after two 976-byte fragments 984 bytes remain, which no longer fit in one fragment.
- (B) Uses 980 data bytes for non-final fragments; their data must be a multiple of 8, so the limit is 976 and three fragments are not enough.
- (C) 2936 bytes split as 976, 976, 976, 8; the last fragment starts at data byte 2928, so its offset field is 2928/8 = 366.
- (D) Gives the byte position of the last fragment; the offset field counts 8-byte units, so it is 2928/8 = 366.