Summary

  • RFC 7112 requires the fragment whose IPv6 Fragment Offset is zero to contain the entire header chain through the first upper-layer header. A stateless filter can then see enough protocol context to apply a bounded rule instead of guessing while the decisive header waits in another fragment.
  • Completeness of the first fragment is not completeness of the datagram. Operators still need separate evidence for the source that created it, the path MTU, the device and rule that treated it, later fragment offsets, overlap and timeout, destination reassembly, ICMPv6 Parameter Problem Code 3 and the final service outcome.

A packet that arrived before its explanation

Imagine an edge firewall with a simple rule: accept traffic to one TCP port and reject traffic to another. An ordinary unfragmented IPv6 packet gives the device the IPv6 header, any extension headers and eventually the TCP header. The port is visible. The device can apply its rule to this packet without storing a reassembly queue.

Fragmentation can disturb that clean sequence. IPv6 extension headers have variable length, and more than one may appear between the base header and the transport protocol. If the chain is long enough—or the first piece small enough—the fragment with offset zero can end before the TCP or UDP header appears. The packet has presented its network addresses but withheld the field on which the filter's decision depends.

RFC 7112 describes the resulting bind. If a stateless firewall forwards the incomplete first fragment, it may have admitted traffic whose eventual transport header would have failed the rule. If it discards the fragment, it may reject traffic that would have passed. Either action can fail to enforce the intended policy because the first piece does not contain the evidence the policy requires.

The repair was not to make every firewall reassemble every packet. It was to constrain what a conforming source may put in the first fragment. When a host fragments an IPv6 datagram, RFC 7112 says it must include the entire IPv6 header chain in the first fragment. The fragment has to introduce the packet before asking an intermediate device or receiver to decide what to do with it.

“Entire” stops at a precise boundary

The phrase “entire header chain” sounds expansive. The RFC gives it a narrow end point.

The chain begins with the initial IPv6 header. It continues through zero or more IPv6 extension headers. It ends at the first upper-layer header, or at the No Next Header value when no such header exists. In the ordinary case, TCP, UDP or ICMPv6 is the upper layer. A second IPv6 header in a tunnel, or an ESP header, is treated as the upper-layer terminator for this definition.

The upper-layer payload is not part of the chain. A TCP header must appear; the TCP application data does not. That is why RFC 7112 does not ban large payloads and does not require a first fragment to contain a whole transaction. It moves one parsing boundary forward far enough to expose the selector a packet filter may need.

That distinction disciplines the evidence claim. A complete first fragment can show that the Next Header sequence reaches TCP and that a visible destination-port field has a certain value. It cannot show what a later application record says. Even deep packet inspection may remain unable to interpret fragmented content after the header chain is complete; RFC 7112 states that limitation explicitly.

The minimum common rule is therefore smaller than “make fragmentation safe.” It is: do not split the packet's protocol introduction across fragments. Everything beyond that remains a different question.

Offset zero is a position, not an identity

RFC 7112 defines the first fragment mechanically: its Fragment Offset equals zero. The definition is useful because a device can read it locally. It is also easy to overread.

Offset zero does not prove which person, program or organization originated the datagram. A visible IPv6 source address is not a cryptographic identity. A valid header order is not an authorization token. An attacker can construct a syntactically complete first fragment just as a legitimate implementation can.

The rule supplies sufficient evidence for a rule that depends on header fields; it does not supply the policy that interprets those fields. One network may permit the visible port. Another may reject it. One intermediate device may be configured to discard a nonconforming first fragment; another may pass it for compatibility. A destination host still applies its own receiving behavior.

This is why first-fragment completeness fits a thin coordination layer. The shared specification defines an inspectable packet condition. It does not appoint an institution, author or middlebox to choose every network's policy. Participants read the same structure and retain local treatment authority.

Six ledgers around one fragment

An incident report that says only “the first fragment was accepted” loses the evidence needed to explain what happened. At least six ledgers should remain separate.

The first is source construction. Which implementation emitted the packet? What extension-header sequence did it create? Where did it place the Fragment header, and did offset zero actually extend through the upper-layer header? A capture near the source is stronger evidence than a later observation after tunnelling or encapsulation changed the packet.

The second is path-MTU state. Requiring the whole chain in the first fragment constrains the chain to the path MTU. RFC 7112 says that a host without path-MTU discovery must limit the chain to 1280 bytes. An incomplete first fragment may therefore reveal a header construction error, stale MTU belief or pathological extension chain—not merely a firewall disagreement.

The third is intermediate treatment. Which device, interface and software version saw the packet? Which rule version was active? Was incomplete-chain handling enabled, disabled or operating in a compatibility mode? A fleet-level statement that a vendor “supports RFC 7112” does not answer those per-hop questions.

The fourth is destination treatment. RFC 7112 says a receiving host should discard a first fragment that violates the requirement and should send an ICMPv6 error, subject to the ordinary ICMPv6 rules. A host may nevertheless expose a backward-compatibility option. The state reached at the destination cannot be inferred from the intention of an upstream firewall.

The fifth is diagnostic delivery. If a host or intermediate system discards the fragment and sends an error for this reason, the RFC specifies ICMPv6 Parameter Problem Type 4, Code 3, with Pointer zero. Whether the error was generated, rate-limited, filtered on the return path or observed by the source is another chain of facts.

The sixth is the completed service result. Did the transport exchange succeed? Did retransmission choose a different packetization? Did an application time out? Passing the first-fragment check proves none of those outcomes.

These ledgers turn a standards claim into a running-code receipt. Without them, “compliant” and “blocked” are labels searching for an event.

Admission and reassembly are different machines

RFC 8200 makes the separation visible in its packet diagrams. Some headers are repeated in every fragment because nodes along the path may need them. The Fragment header then marks the fragmented construction. Extension headers that follow it and the upper-layer header must be in the first fragment. Later fragment packets carry their own offset and data. At the destination, reassembly uses the source address, destination address and Fragment Identification, along with offsets and lengths, to reconstruct the original packet.

The first-fragment rule governs the entrance to that process. It does not settle the process.

Later fragments may never arrive. A fragment may have an invalid length. Reassembly may exceed the size limit. Two pieces may overlap, in which case RFC 8200 requires the entire datagram to be abandoned. Exact duplicates may be detected and dropped while other pieces remain. A reassembly timer may expire after 60 seconds. Each condition has its own evidence and treatment.

That is also why forwarding later fragments after dropping the first one is not necessarily a policy bypass. Without the offset-zero fragment, the destination cannot reconstruct the original packet. RFC 7112 uses this fact in its stateless-firewall example: discarding the first fragment can enforce the policy even if later pieces continue along the path. But their forwarding should not be misrecorded as acceptance of a complete datagram.

The useful operational vocabulary is therefore specific. “First fragment passed header-chain validation” is one statement. “All fragments formed a valid datagram” is another. “The transport conversation succeeded” is a third. Combining them hides both failures and false alarms.

Code 3 is a receipt, not a guarantee

RFC 7112 gave the violation a dedicated diagnostic: ICMPv6 Parameter Problem Code 3, “IPv6 First Fragment has incomplete IPv6 Header Chain.” The Pointer field is zero. The code turns a silent ambiguity into something a source can, in principle, observe.

But the normative verbs matter. A receiving host should discard and should send the error. An intermediate system may discard and may send it; a capable intermediate system should offer configuration for its drop behavior. ICMPv6 generation remains subject to the rules that already govern error messages. Source-address forgery, rate limits and filtering can also change what reaches the sender.

An absent Code 3 is therefore not proof that every hop accepted the packet. A present Code 3 is not proof that the device named in an inventory generated it. The receipt becomes useful when paired with capture point, timestamp, quoted packet, interface, counter and configuration version.

At scale, operators should treat the code as a sensor. A sudden rise after a software rollout can identify a source constructing illegal fragments. A fall after a firewall change can mean the source was repaired—or that the diagnostic disappeared. The difference is visible only if drop counters, sampled packets and return-path telemetry remain separate.

The atomic fragment is a different exception

Fernando Gont's RFC 6946 addresses a related but different ambiguity. An IPv6 atomic fragment contains a Fragment header while both its Fragment Offset and M flag are zero. The packet is not waiting for other pieces. Earlier implementations sometimes mixed it into a reassembly queue with fragments sharing the same source, destination and identification tuple, creating an attack surface.

RFC 6946 says atomic fragments are processed independently of other fragments. RFC 8200 incorporates that behavior. This is not the RFC 7112 rule in another form.

The distinction matters during investigation. An incomplete first fragment has offset zero but usually indicates a genuinely fragmented datagram whose header chain was split incorrectly. An atomic fragment is a complete datagram carrying a Fragment header. An overlapping fragment is yet another condition. The same parser may encounter all three, but they imply different state transitions and different remedies.

If telemetry labels every packet with a Fragment header simply “fragmented”, it destroys that separation. Keep the M flag, offset, identification, observed chain termination, fragment count and reassembly key. The packet format already supplies the columns; the operator has to resist throwing them away.

From a patch to the base specification

RFC 7112 updated RFC 2460 in 2014. RFC 8200 replaced RFC 2460 in 2017 and incorporated the first-fragment requirement into the IPv6 specification itself. Its fragmentation procedure says that any extension headers after the Fragment header and the upper-layer header must be in the first fragment. Its error conditions say a first fragment missing all headers through an upper-layer header should be discarded and should elicit Parameter Problem Code 3.

RFC 9099 later translated the rule into operational security advice. Firewalls and security devices should drop first fragments that omit the entire chain, including the transport header; destination nodes should do the same. Without that visibility, a hostile party may bypass stateless filtering.

This publication history is evidence of a specification change, not evidence that every deployed implementation changed on the same day. Appliances may retain compatibility switches. Hosts may differ in error generation. Encapsulation may move the relevant observation point. Hardware parsers may have finite extension-header depth even when the packet is formally valid.

The only defensible claim about a particular network comes from its running path: crafted tests, packet capture, counters, error messages, versioned configuration and service outcomes. The RFC defines what to test. It does not fill in the result.

Fernando Gont's documented role

RFC 7112 names Fernando Gont, Vishwas Manral and Ron Bonica as authors. Its Standards Track status reflects IETF review and consensus. Gont is not the sole inventor of a community document, and authorship does not give him authority over the implementation or filtering policy of any network.

His wider record makes the person lens meaningful without inflating it. RFC 6946 names him as author of the atomic-fragment processing change. The current IETF Datatracker profile lists 40 RFCs and describes work in protocol security and open-source implementation. The continuity is a method: locate an ambiguity in a packet state, separate states that implementations had collapsed, and give operators a condition they can test.

That method is more durable than biography. It gives the first fragment a modest burden of proof. The packet must disclose the protocol boundary needed for a local decision. The firewall may decide. The destination may reassemble. The application may succeed or fail. None of those functions becomes the other.

The fragment does not have to tell its whole story at once. It only has to introduce the story honestly enough for the next machine to know which question it is answering.

Sources