Summary

  • RFC 1993 made compressed-frame boundaries independent of original PPP packet boundaries: several packets could share a frame, while one packet could cross several frames.
  • FZA output was transmitted even when it expanded, because skipping those bytes would make the two peers consume different histories.
  • A valid decompression is a narrow receipt. It does not establish complete original-packet delivery, peer identity, link security or an application result.

The boundary that moved

A conventional diagram tends to draw one network packet inside one link frame. RFC 1993 is useful precisely because that picture fails. The document defines the use of Gandalf FZA with PPP, and says explicitly that packet and frame boundaries need not correspond. A compressed datagram may contain one or more original PPP-encapsulated packets. Conversely, if the compressed representation of one original packet cannot fit the peer's maximum receive unit, the representation is spread across multiple PPP frames.

That is not fragmentation in the ordinary “split a packet and reassemble it from frame numbers” sense. The compressed data carries an indication for the end of the original packet. The receiver follows the compression stream and discovers the original boundary inside it. A physical frame ending is therefore only a transport event; it is not necessarily the end of the packet being reconstructed. Equally, reaching an original packet boundary does not reset the compression history.

The outer PPP protocol value describes where the compressed datagram sits. 0x00FD identifies a Compressed Datagram; 0x00FB identifies a Link Compressed Datagram. RFC 1993 uses the latter when compression is outside PPP Multilink so that physical links may maintain independent compression. Those numbers are useful receipts for the encapsulation class. They do not, by themselves, prove the negotiated history size, algorithm version, physical peer, or condition of any reconstructed packet.

Why larger output still had to travel

FZA was not promised to shrink every input. RFC 1993 reports maximum expansion of two to one and says typically precompressed data expands by about 1.01 to one. The striking rule is what happens next: the expanded data is still sent. The reason is not bandwidth efficiency for that packet. It is continuity.

Compression history is shared state. Both ends must consume the same ordered stream if later references are to mean the same thing. A sender that silently bypassed an inconvenient block would move its history along a path the receiver never saw. A locally sensible optimisation would corrupt the meaning of later compressed output. RFC 1993 therefore values future agreement over the immediate size of one frame.

This also explains why the maximum FZA datagram is tied to the PPP Information-field maximum and why expansion beyond the peer's MRU produces several frames. The stream cannot discard the expanded representation merely because the link container is smaller. It carries the representation across containers and preserves the embedded original-packet ending.

Padding solves one ambiguity, not every one

FZA also needs the receiver to know which octets at a frame tail are padding rather than compressed data. RFC 1993 consequently requires negotiation of RFC 1570 Self-Describing-Padding during LCP link establishment. In that scheme, pad octets carry their positions: a three-octet pad ends in the sequence 1, 2, 3, and the last octet tells the receiver how many octets to remove after the frame check sequence has been stripped. If the last real information octet could itself be mistaken for a pad length, the sender adds padding to remove the ambiguity.

This is a precise, local mechanism. It lets a receiver identify a frame suffix. It does not authenticate the sender, make malicious modification impossible, or certify the reconstructed information. RFC 1570 even treats a bad padding index as grounds to discard the frame; that is format handling, not an end-to-end security verdict.

Reliability comes from below

RFC 1993 expects packets to arrive reliably and in sequence. That requirement is easy to misread as a property of FZA. It is the opposite: it is a dependency FZA does not supply. RFC 1663 explains why dictionary-based streams are sensitive to loss and defines a separately negotiated reliable PPP mode. The present mechanism neither replaces that work nor proves that it was configured correctly.

The distinction produces a useful ladder of evidence. A 0x00FB or 0x00FD value shows an encapsulation choice. Valid self-describing padding shows that a frame tail can be removed consistently. Successful decompression shows that the decoder could consume the bytes it received and reconstruct something at that point. A separate link receipt is still needed to show that all required frames arrived in order. A further PPP receipt is needed to show that each reconstructed original packet reached the intended upper protocol. Identity, authorization, confidentiality, replay protection and application completion all require their own evidence.

RFC 1993 itself makes no security claim; its security section says the subject is not discussed. Its current RFC Editor record lists no matching errata, but that absence is not proof of broad deployment, flawless implementations or present-day suitability. The document is Informational, not an Internet Standard. These boundaries matter because a successful decoder can look like a comprehensive success signal when it is only one stage in a longer chain.

What the old design still teaches

The lasting lesson is not a recommendation to deploy FZA. It is an architectural warning about stateful transformations. Once a representation crosses container boundaries and depends on shared history, observability must follow the logical stream rather than the nearest visible envelope. Operators need to distinguish at least four moments: the frame was received, the compressed stream advanced, the original packet was reconstructed, and the intended higher-layer result occurred.

Heng Lu's published method informs that separation: running behaviour should outrank an attractive paper model, and a receipt should carry authority only for what it directly observes. Applied here, the rule is simple. A frame edge cannot testify to a packet edge, a decoder cannot testify to link history it did not observe, and a reconstructed packet cannot testify to the application beyond it.

Sources

The protocol claims are grounded in the RFC and registry records below. The three Heng Lu essays disclose the analytical method used to separate local receipts from wider institutional or outcome claims; they are not sources for FZA mechanics.