Earlier this week, someone asked me a simple question about the “Fragment Offset” in an IP Packet Header. I have to admit that my understanding this field was slightly incorrect. Before I come clean with my misinterpretation, I wanted to throw out a challenge. Review the image below, then answer the question that follows.
An administrator on RTR A enters the command “ping 192.168.2.3 size 1500 repeat 1”. The IP address 192.168.2.3 exists on RTR C. How many fragments will be received by RTR C?
- One (Packet will not be fragmented)
- Zero (ICMP Echo will be dropped prior to reaching C)
Prior to experimenting, I would have chosen “three”. The logic is that RTR A would internally produce an IP Packet that is 1500 bytes. As it leaves RTR A, it would be fragmented in two packets. One would have an overall length of 1498 bytes and the other one would be 2 bytes (plus the IP Header). As this 1498 byte packet left RTR B, it would be fragmented again. This would have RTR C receiving a 1492 byte packet, a packet that is 6 bytes (plus the 20 byte IP header, and a packet that is 2 bytes (plus the 20 byte IP header).
This answer would have been incorrect. The “fragment offset field”, used for reassembling fragmented packets by the receiver, is clearly identified in RFC 791. This field does not represent a single octet, but multiples of 8 octets. It also represents only the data portion of an IP Packet. The data portion is 20 bytes less than the overall packet lenght. In my example, 1498 – 20 (1478) is not divisible by eight.
If we create a packet that is 1500 bytes and send it out an interface with an MTU of 1492, it will be fragmented to the largest packet whose data field is divisible by eight and less the 1498. In this case, it happens to be 1492 (1492 – 20 or 1472 is divisible by eight). If we wanted to create a scenario that produces three fragments at RTR C, we would need to have MTU’s that are a little further apart (or produce IP Data fields that fall into ranges that are in a different multiple of eight). For example, decreasing the MTU on RTR B to 1491 would produce three fragments at RTR C. Of course this is assuming that the same 1500 byte packet is sourced from RTR A.