Summary

  • The high bit of an IPv4 option type says whether that option is copied into every fragment.
  • A zero leaves the option with the first fragment; a one makes it accompany all fragments, without guaranteeing that a device will process or accept it.

One datagram, unequal headers

Fragmentation divides a datagram's data, but it also creates several new IPv4 headers. Those headers do not have to be byte-for-byte copies. RFC 791 says that when fragmentation occurs, some options are copied while others remain with the first fragment only.

The rule lives inside the option itself. RFC 791 divides the option-type octet into three fields: one copied bit, two class bits and a five-bit option number. The high bit has a narrow answer. Zero means not copied on fragmentation. One means copied into all fragments.

That makes the difference between fragments explicit on the wire. A later fragment can lack an option that appeared in the original header without being malformed for that reason alone. Conversely, an option whose type has the copied bit set is not merely a first-header annotation; the fragmentation procedure carries it forward.

Propagation is not classification

The remaining seven bits answer different questions. The two-bit class historically distinguishes control options from debugging and measurement, with other values reserved. The five-bit number identifies the option and therefore the syntax that follows. Neither field decides whether fragmentation reproduces the option.

This separation matters because superficially similar options can have different propagation needs. RFC 791 marks source-routing and Security options as copied. Record Route and Timestamp are not copied on fragmentation and go only in the first fragment. The bit does not rank those options or declare one class more important. It records the propagation rule for each option type.

The first fragment is special because it contains the beginning of the original data. Keeping a non-copied option there preserves a single instance rather than cloning it into every new header. A copied option, by contrast, declares that its control state belongs with fragments that may be forwarded and handled separately.

Header length belongs to each fragment

Different option sets produce different header lengths. A fragment that loses non-copied options can have a smaller Internet Header Length than the first fragment. Its Total Length must cover its own header and data, while its IPv4 header checksum covers only that fragment's header; neither value can simply repeat the original.

RFC 791's fragmentation procedure therefore rebuilds each fragment's option field, IHL, Total Length and header checksum as needed. The copy decision explains why constructing a fragment header is more than cutting the payload: the option type determines which header state survives the split.

A rule that survived its era

RFC 7126 restated the same type layout in 2014: copied flag, class and number. By then, its operational focus was how routers, firewalls and security gateways handle packets containing IPv4 options. Implementations might drop such packets, ignore options while forwarding, or process selected options in specialized or general-purpose paths.

That later history clarifies the boundary of the copied flag. Copying an option does not promise that every router will interpret it. It does not certify safety, performance or deployability. It says what fragmentation must place in each resulting header before local processing and filtering policy take effect.

Sources