Summary

  • RFC 5320's experimental SEAL layer permits outer IPv4 fragmentation, asks an egress to report it, validates recent feedback with a SEAL_ID window and adjusts a per-egress maximum segment size. The feedback authorizes a bounded tuning step; it is not a verdict that the whole path or packet succeeded.
  • A useful receipt keeps probe intent, 32- or 16-bit identity mode, packet size, observed first fragment, feedback window, S_MSS generation, IPv4 and SEAL reassembly decisions, upper-layer delivery and the document's experimental-only authority as separate facts.

The packet came back as a measurement

Classical path MTU discovery makes a packet too large for one link disappear and expects an ICMP message to explain the loss. Firewalls may discard the explanation. An untrusted sender may forge it. A tunnel ingress may receive enough error traffic to make translating every complaint back to every original source impractical.

RFC 5320 proposed a different experimental bargain. The Subnetwork Encapsulation and Adaptation Layer, or SEAL, allows an outer IPv4 packet to fragment inside a virtual topology. The egress can report that fragmentation to the ingress. The ingress then reduces the size of later SEAL segments until the fragmentation subsides.

In this design, a fragment is not merely damage. It is a sample from a control loop. The sample says that one packet met a smaller boundary somewhere between the encapsulating endpoints. It does not name the link, establish the permanent path MTU, prove that all fragments arrived, or show that the inner packet reached an application.

That distinction is the operational centre of the protocol. A monitoring system that converts “fragmentation report accepted” into “path validated” grants one observation far more authority than the RFC gives it.

The identifier widens, then narrows at a NAT

For ordinary tunnel operation, SEAL constructs a 32-bit SEAL_ID. The high 16 bits occupy the ID Extension field in the SEAL header; the low 16 bits occupy the Identification field in the outer IPv4 header. The ingress initializes the value randomly for each egress's soft state and increments it modulo 2^32 for every SEAL protocol packet.

Routers may use that identity for duplicate detection. The tunnel endpoints use it to associate segments and recent feedback. The longer identifier also reduces the collision pressure that a high-rate tunnel would place on IPv4's 16-bit Identification space.

The construction changes when the encapsulation is designed to cross an IPv4 NAT. A translator may rewrite the outer IPv4 Identification value, so the ingress cannot treat the two halves as one stable end-to-end number. In that mode, SEAL_ID is only the 16-bit ID Extension. The ingress increments that value modulo 2^16 and writes a random value into the outer IPv4 Identification field.

The receipt must record which identity regime applied. Concatenating the fields after a NAT rewrite would manufacture a 32-bit identity that no endpoint actually maintained. Conversely, reducing every deployment to 16 bits discards evidence that the ordinary mode explicitly created.

Packet identity is still not packet outcome. A matching ID can bind a report or segment to recent sender state. It cannot show that the payload was correct, the egress accepted the reconstruction, or the upper layer consumed it.

S_MRU and S_MSS answer different questions

The ingress maintains two per-egress soft-state values. S_MRU, initially no larger than 2 KB, limits the size it will require the egress to reassemble. S_MSS limits the size of a SEAL segment and is initialized from the underlying IPv4 interface MTU minus outer overhead, with S_MRU/8 as a floor in the calculation.

Those variables are easy to collapse into one “tunnel MTU” field. They should not be. The virtual interface exposes an admission size to the inner IP layer. S_MRU governs the reconstruction obligation. S_MSS governs the pieces sent through the subnetwork. Header and trailer lengths reduce the space available at every boundary.

If a fragment report changes S_MSS, it has not changed the identity of the inner packet or necessarily changed the interface MTU visible to its source. If an unfragmentable inner packet is larger than the applicable reassembly or segment boundary, the ingress drops it and returns a PTB to the original source. That is a different event from allowing a mid-layer packet to be cut into SEAL segments.

The decision ledger needs the values and generations separately: interface MTU, mid-layer overhead, outer overhead, S_MRU, S_MSS, inner packet length, fragmentability, selected action and the feedback that changed the next generation.

Segmentation is not IP fragmentation in another font

SEAL can cut a mid-layer packet into no more than eight non-overlapping segments. Non-final segments have equal length, the final segment is no larger, and the ingress sends them in canonical order. The header carries a More Segments bit and a three-bit segment number.

This happens below the inner IP layer. Even an inner packet that IP considers unfragmentable may be segmented because the egress restores the original mid-layer packet before presenting it upward. Outside the subnetwork, the cutting is intended to be invisible.

Outer IPv4 fragmentation is a separate layer. SEAL normally sends outer packets with DF=0, allowing routers to fragment them. It then treats the event as evidence that its segment sizing is out of tune. Three acts therefore need three names: inner IPv4 fragmentation before encapsulation, SEAL mid-layer segmentation, and outer IPv4 fragmentation inside the subnetwork.

A counter labelled simply fragments cannot say which contract was exercised. It cannot distinguish a source-authorized IPv4 split, an endpoint-controlled SEAL segmentation, and a path router reacting to an outer packet. These events have different producers, identifiers, reassembly points and corrective actions.

R and A request different evidence

The ingress sets R=1 on segment zero when it wants the egress to report outer IPv4 fragmentation. Ordinary data can serve as an implicit probe. Once S_MSS has reached its minimum, the ingress can clear R to avoid generating reports for fragmentation it can no longer tune away.

The A=1 bit requests an acknowledgement. An explicit probe may be ordinary data or a NULL packet with No Next Header. Explicit probes maintain a window of outstanding SEAL_ID values and can test whether a larger S_MSS has become viable.

These signals should not be merged into one successful-probe state. R asks whether fragmentation occurred. A asks for a response. When both are set and fragmentation occurs, the egress sends one Fragmentation Needed message, not two independent confirmations. A response can therefore carry more than one requested meaning, and the receiver must preserve why the packet was sent.

The absence of a report is also ambiguous. The egress may rate-limit fragmentation reports when acknowledgement was not requested. A packet or response may have been lost. The path may have avoided fragmentation. Silence is not proof of any one branch.

A nonce match limits the speaker; it does not authenticate the route

A raw ICMPv4 error contains part of the packet-in-error. The ingress can recover the 32-bit SEAL_ID and use it as a nonce indicating that the message came from the egress or a router on the path. RFC 5320 permits treating raw errors as soft hints that the path may be failing. Even Protocol Unreachable is only a hint that the egress does not implement SEAL.

A SEAL-encapsulated ICMP message creates a stronger boundary. It carries outer SEAL and IPv4 context, and the ingress compares the packet-in-error's ID with the current window of transmitted IDs for that egress. An out-of-window report is discarded. An accepted report advances the window before processing.

The stronger association remains bounded. The SEAL header travels in clear text outside IPsec/ESP and has L2, not L3, integrity protection. The identifier is not a cryptographic attestation. It helps reject stale or off-path guesses and ties feedback to recent state; it does not prove which link imposed the restriction or that every router on the route is trustworthy.

An observability record should therefore say “report matched current ETE/ID window” rather than “path authenticated.” The first is a protocol decision. The second is an unsupported institutional conclusion.

One report may change size only once

For a SEAL-encapsulated Fragmentation Needed message, the ingress calculates L from the IPv4 length of the packet-in-error minus outer header length. It updates S_MSS only under the inequalities defined by RFC 5320. A first fragment whose derived length is below the threshold based on 576 bytes signals fragmentation but does not disclose the true restricting MTU; a router may have produced a runt first fragment.

The ingress then has to search iteratively, possibly through several rounds of smaller packets and new reports. Causality matters. It must reduce S_MSS on the first applicable report and refrain from reducing it again until a report arrives for a packet sent under the new value.

Without the parameter generation, stale reports can form a downward ratchet. Three messages about one old oversized generation would appear to justify three new reductions. The correct receipt binds the report to the sent packet's ID, size and S_MSS generation, then records exactly one transition and the probe that evaluated the new state.

Increasing the value needs evidence too. Periodic explicit probes may reset or test above the current size. A successful larger probe is an observation of that probe under that path epoch. It is not a timeless guarantee that all later packets, encapsulations or routes support the same size.

Reassembly contains policy, congestion and silence

The egress must support outer IPv4 reassembly up to 2 KB and SEAL-layer reassembly up to 2 KB minus outer overhead. It maintains high- and low-water marks, may actively discard incomplete reassemblies under pressure, and uses a shortened 15-second maximum lifetime.

After IPv4 reassembly, acceptance can depend on whether the cache is congested, how strong the upper-layer integrity check is and how much corruption the application can tolerate. In the limiting case, the egress may discard every IPv4 reassembly and use only first fragments to generate SEAL feedback.

SEAL-layer reconstruction has its own admission conditions. It expects segments 0 through N-1, the correct M-bit progression and consecutive SEAL_ID values. NULL packets are silently discarded after reconstruction. Overlarge reconstructed packets that experienced fragmentation or arrived as multiple SEAL segments can also be silently discarded under the stated rule.

Only after those gates does the egress deliver the inner packet to the protocol named by Next Header. A fragmentation report may therefore be generated from the first fragment even when no complete outer packet, mid-layer packet or upper-layer delivery follows. Treating the report as a delivery acknowledgement reverses the evidence order.

The receipt needs separate outcomes for outer reassembly, SEAL reassembly, validation, silent-discard rule, inner error generation and upper-layer handoff. “Received at egress” is too imprecise to audit.

Experimental publication is part of the technical state

RFC 5320 is an Experimental Independent Submission. Its IESG note says it was not selected through IETF review for matters such as security, congestion control or interaction with deployed protocols. The RFC Editor's publication does not make it a candidate for an Internet Standard.

The protocol numbers, service port and TCP option come from experimental ranges. The document says they are not for deployment and must not be shipped in products. That constraint is not introductory decoration. It belongs beside every interoperability or implementation claim.

Later RFCs change the surrounding evidence environment. RFC 6864 updates how IPv4 Identification should be understood. RFC 8900 describes fragmentation as fragile. RFC 4821 and RFC 8899 develop packetization-layer PMTU discovery. These documents help explain why identity, probing and packet sizing continued to evolve. They do not retroactively convert SEAL into a deployed standard or prove that its feedback loop is fit for production.

A receipt for the feedback loop

A non-secret operational receipt would bind: document and implementation status; tunnel or transport mode; ITE and ETE; NAT traversal mode; interface and underlying MTUs; MHLEN, OHLEN and HLEN; S_MRU and S_MSS generations; inner packet identity, size and fragmentability; 32- or 16-bit SEAL_ID; A, R, M and SEG; outer DF; segment and fragment inventories; raw or encapsulated ICMP form; packet-in-error bytes; ID-window decision; derived L; one accepted parameter transition; outer and SEAL reassembly outcomes; cache pressure; integrity policy; inner error; upper-layer handoff; and packet observation.

That ledger preserves the useful modesty of the design. Fragmentation is evidence that a size was wrong. A recent nonce says a report plausibly belongs to recent traffic at a bounded endpoint or path position. Reassembly says named pieces were joined under named policy. None of those facts silently inherits the authority of the next.

Sources