Summary

  • RFC 9564 is an Informational Independent Stream publication dated 1 April 2024, not an IETF Standards Track specification or evidence of implementation and deployment.
  • Its FLIP model predicts future packet bytes, but a model output is not a transmission, arrival, authenticated origin, fresh message, authorized action or application result.
  • The satire works because each formal-looking artifact—a model hash, shim header, command and suggested codepoint—can be real while the operational claim assembled from them remains false.

The proposed transport port is 68534. A port number has sixteen bits; 65535 is the ceiling. The suggested IP protocol number is 345, beyond an eight-bit protocol field. These are not subtle deployment defects. They are signposts.

RFC 9564, the Faster Than Light Speed Protocol, was published on 1 April 2024. It imagines two peers training large language models so that the receiver can predict packets before they arrive. Encryption is dismissed as merely more bytes to predict. Header lengths need not be encoded because a neural network will supposedly discover where the header ends. The security section invents a “futureplay attack”. The acknowledgements turn the joke back on standards institutions by suggesting LLMs could replace human reviewers and leaders.

The piece is funny because its document form is disciplined while its causal chain is impossible. That contrast is also operationally useful.

An RFC number identifies a publication, not one level of authority

RFC 9564’s status block is unambiguous. It is Informational, published through the Independent Stream, not an Internet Standards Track specification, not a candidate for any Internet Standard level, and accompanied by no RFC Editor judgment about implementation or deployment value.

The RFC Series contains several streams. RFC 7841 defines stream-specific headers and boilerplate; RFC 8729 explains that the Series is not one undifferentiated source of IETF consensus; RFC 9280 describes its editorial model. The identifier is authoritative evidence that this particular document was published in the Series. It is not a universal certification mark.

That distinction matters outside satire. Procurement text, security questionnaires and product pages often cite an RFC number as if the number alone proved standards status, conformance or operational maturity. A defensible claim must preserve the stream, category, status, updates and errata—not merely the integer.

A model hash names bytes, not behaviour

FLIP places a SHA-256 hash of the trained model in a variable-length Version field. A cryptographic digest can strongly identify a particular byte sequence. It does not prove what data trained the model, whether the data was lawful or representative, which tokenizer and runtime were used, whether surrounding configuration matched, or whether two peers produce the same inference.

The satire sharpens the contradiction by saying the model and training data should not be disclosed for privacy, security and legal reasons. With provenance withheld, the hash becomes a stable handle for an opaque artifact. Stability is useful, but it cannot substitute for fitness, reproducibility or governance.

The same limit applies to ordinary automation. A model version, signed container or approved registry entry may establish which artifact ran. To establish why its output should be trusted, an operator still needs the input boundary, runtime configuration, evaluation record and observed error distribution for the relevant epoch.

Predicted bytes are not received bytes

FLIP’s Data command says the following data can be predicted. Even perfect prediction would occur locally at the receiver. It would not show that the sender emitted those bytes, that the network carried them, that they arrived at a particular time, or that the peer authorized their effect.

Suppose the predicted sequence later matches a packet. Equality proves a comparison result under a chosen boundary. It does not prove origin: an adversary can send the expected bytes. It does not prove freshness: a replay can match. It does not prove completeness: missing context may change the message. It does not prove application acceptance or useful outcome.

The correct evidence chain keeps separate receipts for publication provenance; model identity and training provenance; input and inference epoch; predicted output; observed transmission and arrival; peer authentication; freshness and authorization; and application result. Collapsing those stages is how a plausible forecast becomes a fictitious delivery receipt.

Heng Lu’s reality-layer discipline explains why the joke travels so well. The RFC record is a real symbolic artifact. The model hash can be a real identity. The prediction can be a real computation. Running code and packet capture may provide real observations. None receives permission to impersonate the others.