IPv4 Fragmentation

Every link has a maximum transmission unit (MTU): the largest IP datagram, header included, that one link-layer frame can carry. Ethernet's is 1500 bytes; other links have larger or smaller ones. A datagram crossing several links may meet one whose MTU is smaller than the datagram. IPv4 then lets the router fragment it: split the data into pieces, give each piece its own IP header, and send the pieces as separate datagrams. They travel independently and are reassembled only at the destination host.

Three header fields make this work: identification (which datagram a fragment belongs to), the MF flag (more fragments follow) and the fragment offset (where this fragment's data starts, in 8-byte units). The DF flag forbids fragmentation; a router that would need to fragment a DF datagram drops it and reports back. The tasks are to find the number of fragments, each fragment's length, offset and MF bit, and the reverse: what a given fragment says about the original datagram.

So the largest data per fragment is

with $H = 20$ bytes for a header without options. The last fragment is exempt from rule 2, so it may carry up to $\text{MTU} - H$ bytes, which exceeds $d_{\max}$ when $\text{MTU} - H$ is not a multiple of 8. Only the data is split; the original header is not part of any fragment's data.

The destination collects fragments with the same (source, destination, protocol, identification), places each fragment's data at byte $8 \times \text{offset}$, knows the total size once it has the fragment with MF = 0, and delivers the datagram when every byte is present. If any fragment is lost, a reassembly timer expires and the whole datagram is discarded: IP never retransmits a single fragment.

If DF = 1 and the datagram exceeds the next link's MTU, the router discards it and returns ICMP Destination Unreachable with code 4, "fragmentation needed and DF set". Path MTU discovery (RFC 1191) uses this: the source sends with DF set and lowers its datagram size whenever such a message comes back, so that it never needs fragmentation.

A datagram of total length 5140 bytes (20-byte header, 5120 data bytes, identification 777) meets a link with MTU 1420. Then $d_{\max} = 8 \lfloor 1400 / 8 \rfloor = 1400$.

Number of fragments $\lceil 5120 / 1400 \rceil = 4$. The four fragments put $4 \times 20 = 80$ header bytes on the link instead of 20, so 60 extra bytes.

For $D$ data bytes, header $H$ and MTU $M$:

The first $k - 1$ fragments carry $d_{\max}$ each and the last carries the rest, which may be up to $M - H$. The shortcut $\lceil D / d_{\max} \rceil$ gives the same count except when $D > d_{\max}$ and $D$ exceeds a multiple of $d_{\max}$ by 1 to $s = (M - H) - d_{\max}$ bytes (the 0 to 7 bytes of slack the last fragment may use), where it counts one fragment too many; so the two always agree when $M - H$ is a multiple of 8 ($s = 0$, as for MTU 1500 or 1420), and Example 1 shows a case where they differ.

Extra header bytes $= (k - 1) H$.

Reading a fragment backwards. A fragment with offset $f$, total length $T$ and header $4 \times \text{IHL}$ holds data bytes $8f$ to $8f + (T - 4\,\text{IHL}) - 1$. It is the first fragment exactly when $f = 0$ and MF = 1, the last when MF = 0 and $f > 0$, and a middle one when $f > 0$ and MF = 1. From the last fragment, the original data length is $8f + (T - 4\,\text{IHL})$.

Loss. If each fragment is lost independently with probability $p$, the datagram survives with probability $(1 - p)^k$: fragmentation multiplies the loss rate roughly by $k$ for small $p$.

3000 data bytes, MTU 1006. $1006 - 20 = 986$, and $d_{\max} = 8 \lfloor 986 / 8 \rfloor = 984$, not 986.

Using 986 would give offsets of 123.25, which cannot be written.

With 2954 data bytes instead, the fragments are 984, 984 and 986 (RFC 791 cuts off $d_{\max}$ bytes only while the rest does not fit): the last may use all 986 bytes the MTU allows, so $k = 1 + \lceil (2954 - 986)/984 \rceil = 3$. The shortcut $\lceil 2954 / 984 \rceil = 4$ is wrong here.

Fragment 1 of the main example (1400 data bytes, offset 0, MF 1) and fragment 4 (920 data bytes, offset 525, MF 0) meet a link with MTU 620, so $d_{\max} = 600$.

Offsets stay relative to the original datagram. Every piece of fragment 1 has MF = 1, including its last, because more of the original follows; only the last piece of fragment 4 has MF = 0.

A fragment arrives with IHL 5, total length 420, offset 300 and MF 0. Its data is 400 bytes, bytes 2400 to 2799. It is the last fragment, so the original carried 2800 data bytes and had total length 2820 (with a 20-byte header).

With $p = 0.01$ per fragment and $k = 4$ fragments, the datagram is lost with probability $1 - 0.99^4 \approx 0.0394$, almost four times the per-fragment rate.

A datagram with IHL 6 (a 24-byte header) carries 3000 data bytes to a link with MTU 1500. If every fragment carries the 24-byte header, $d_{\max} = 8 \lfloor 1476 / 8 \rfloor = 1472$: data 1472, 1472 and 56 bytes, offsets 0, 184 and 368, MF 1, 1 and 0, total lengths 1496, 1496 and 80. RFC 791 copies an option into every fragment only if the option's copied flag is set. If it is not set, only the first fragment has the 24-byte header and the later ones have 20 bytes, which gives data 1472, 1480 and 48 with offsets 0, 184 and 369. A question with options must say which case applies.

A datagram of total length 4000 bytes (20-byte header) meets MTU 1500. Its data is 3980 bytes: fragments of 1480, 1480 and 1020 data bytes, total lengths 1500, 1500 and 1040, offsets 0, 185 and 370. Treating 4000 as the data length gives a wrong last fragment of 1040 data bytes.

Common misconceptions.

Related material. IPv6 routers never fragment; only the source may, using a fragment extension header, after path MTU discovery.