摘要

  • RFC 9564 是 2024 年 4 月 1 日发布的 Independent Stream Informational 文档，不是 IETF Standards Track 规范，也不证明实现或部署。
  • FLIP 设想接收端用 LLM 预判未来数据包；本地生成的预测不是发送、到达、认证来源、新鲜消息、授权动作或应用结果。
  • 模型哈希能识别一组字节，比较能证明两段字节相等；若要得出更强结论，仍必须连接训练来源、运行时期、网络观察、身份与应用收据。

这份文本有一个真实的 RFC 编号、一套规整的章节和看似标准的头部字段。若只截取这些外观，它很容易被误读成“某项由 IETF 标准化的 AI 网络协议”。但状态栏把权威边界写得很清楚：Informational、Independent Stream、不是 Internet Standards Track，也不对实现和部署价值作背书。

RFC 9564 的内容则故意越过物理与协议边界。FLIP 声称接收端可以在数据包到达前预测其字节，包括加密流量；模型自己识别可变长度头部的终点；所谓 futureplay 攻击让攻击者把未来包提前发来。它还建议一个超出八位范围的协议号和一个超出 65535 的端口。矛盾是设计，不是疏忽。

RFC 是出版体系，不是单一权威等级

RFC 7841 规定不同 stream 的头部和 boilerplate，RFC 8729 说明 RFC Series 包含多条出版流，RFC 9280 描述编辑模型。编号可以权威地证明某个确定版本被收录，却不能抹去产生它的 stream、category 与 status。

因此，“有 RFC”与“是 IETF 标准”是两种不同陈述。“引用 RFC”与“产品实现并互操作”又是不同陈述。合同、采购或安全报告若只保留编号，便丢掉了判断权威所需的上下文。幽默文档只是把这种借权行为放大到无法忽视。

哈希证明身份，不证明能力

FLIP 把训练模型的 SHA-256 放进 Version 字段。哈希可以证明当前文件与某个已知字节序列一致，但不说明训练数据来自哪里、是否合法或具有代表性，也不说明分词器、预处理、推理引擎和配置是否一致，更不证明模型能预测某类流量。

文本又讽刺性地要求基于隐私、安全与法律理由不披露模型和数据。于是系统拥有一个稳定的黑箱标识，却缺少能力和来源证明。这并非只存在于玩笑里：签名镜像、批准模型或登记哈希经常被误称为“已经验证”。完整验证还需要输入边界、配置、评测集、错误分布与生效时期。

预测字节没有跨越网络

预测在接收端本地发生。即使后来收到的字节与它完全一致，也只能证明指定比较范围内相等，不能证明是谁发出、何时发出、是否重放、是否完整、是否获授权。

攻击者可以发送模型正期待的内容；旧消息也可以逐字匹配；应用可能因状态不符而拒绝相同载荷。把“命中预测”直接升级为“可信交付”，就跳过了发送、传输、到达、身份、新鲜度、授权和应用处理整条链。

可审计系统必须分别保存：文档的 stream 与 status；模型和运行环境身份；训练与输入来源；预测值与时间；实际网络观察；对端认证；重放与授权检查；最终应用结果。

按照 Heng Lu 的现实分层，出版记录、哈希、本地计算与数据包观察都是真实对象，但它们的权力不同。纪律不是否认任何一层，而是不让一层冒充另一层。