Summary

  • IPv4 encodes Fragment Offset in eight-octet units, so an offset value of 32 places fragment data at byte 256 of the original datagram.
  • The compressed coordinate reaches the full datagram range only because every non-final fragment carries a data length divisible by eight.

The offset that does not name a byte

Consider an IPv4 fragment whose Fragment Offset field contains 32. Reading that value as a byte position would place the fragment near the beginning of the original datagram. IPv4 instead multiplies it by eight. The fragment's data begins at byte 256.

That multiplication is not a later convention layered onto the field. RFC 791 defines the 13-bit offset in units of eight octets. A receiver combines the decoded starting position with the fragment's data length to determine which interval of the original datagram has arrived.

The choice links three parts of the header. Total Length is 16 bits and can describe a datagram approaching 65,536 octets. Fragment Offset has only 13 bits, which yields 8192 distinct values. Eight octets per value expands that coordinate scale to 65,536 octets. The field reaches the relevant size by leaving the lowest three bits implicit.

Saving three bits creates a boundary rule

An implicit multiple of eight can represent only starts aligned to eight-octet boundaries. IPv4 fragmentation therefore cannot place a following fragment at an arbitrary byte. When a datagram is split, the earlier portion must contain a multiple of eight data octets.

The final portion is different. It does not need to create a representable start for another fragment, so its data length may be a non-multiple of eight. This is why the accurate rule is not “all fragments are multiples of eight.” Every fragment with More Fragments set must satisfy the boundary; the last fragment may consume whatever data remains.

Headers do not change that calculation. Fragment Offset locates fragment data relative to the original data area, not the beginning of each fragment's IPv4 header. Each fragment carries its own header, and Total Length counts that header plus its fragment data. The eight-octet constraint applies to the data portion used to advance the next offset.

A compact coordinate across a large datagram

The arithmetic explains the design. A byte-granular offset covering the entire 16-bit length space would itself need roughly 16 bits. IPv4 allocated 13 bits because the Flags share the same 16-bit word. By expressing only multiples of eight, the offset effectively restores three low-order zeros when decoded.

This is a representational bargain rather than compression in the everyday sense. The wire does not transmit the omitted zeros, but the sender must arrange fragments so those zeros are correct. The receiver regains the byte coordinate by multiplying the field by eight.

The format also aligns with IPv4's minimum forwarding requirement. RFC 791 notes that a maximum 60-octet header plus the minimum eight-octet fragment forms a 68-octet datagram that every internet module must be able to forward without further fragmentation.

Offset and More Fragments carry different evidence

Fragment Offset says where this fragment begins. It does not say whether the fragment is last. The MF flag supplies that fact: MF=1 means more fragment data follows; MF=0 marks the last fragment.

An unfragmented datagram has offset zero and MF zero. A first fragment also has offset zero, but MF is set because later data remains. A middle fragment has a non-zero offset and MF set. A last fragment can have a non-zero offset with MF clear.

These combinations prevent a receiver from inferring too much from one field. Offset zero does not prove that a datagram was never fragmented. MF zero does not prove that the current fragment begins at zero. Reassembly needs both position and termination evidence, together with Identification and the other tuple fields that distinguish one datagram's fragments from another's.

Reassembly turns units back into intervals

RFC 815 describes reassembly through byte ranges and missing “holes.” A partially assembled datagram contains intervals already received and intervals still absent. Each arriving fragment has a first byte and a last byte. Those boundaries can fill a hole completely, trim it from one side, or split it into two smaller holes.

The Fragment Offset supplies the first byte after multiplication by eight. The fragment data length supplies the last covered byte. When MF is clear, the receiver also learns the final extent of the original data. Once no holes remain within that extent, reassembly is complete.

This interval view clarifies what the offset does not provide. It does not enumerate a fragment's ordinal position, promise that fragments arrive in order, or declare that the covered bytes are new. Duplicate and overlapping fragments can still describe intervals already present. The coordinate makes placement possible; it does not settle every reassembly policy.

Further fragmentation preserves the same coordinate system

IPv4 permits a fragment to be fragmented again if policy and header state allow it. The new pieces do not start a separate local numbering system. Their offsets remain relative to the beginning of the original unfragmented datagram.

RFC 791's fragmentation procedure adds the old fragment offset to the number of eight-octet blocks placed before a newly created later piece. Because the earlier split is itself made on an eight-octet boundary, the result remains representable in the same 13-bit units.

That composability is operationally important. Multiple routers can split traffic without requiring the destination to reconstruct a tree of fragmentation events. Every piece arrives with a coordinate in one common original-data space.

A constraint that survives because parsers depend on it

The eight-octet rule can look like an arbitrary historical limit until the bit budget and reassembly calculation are considered together. It lets a 13-bit field cover the size implied by a 16-bit length. In exchange, fragmenters must preserve the missing three low-order bits by choosing aligned boundaries.

The design does not prevent loss, duplication, overlap or malicious fragments. Nor does it say that applications operate in eight-byte records. It supplies a shared coordinate system under a constrained header format.

The enduring lesson is that compact wire representations move complexity rather than removing it. IPv4 saved three offset bits in every header. Senders paid with a fragmentation boundary rule, and receivers paid by restoring byte coordinates before updating the reassembly map.

Sources