摘要

  • RFC 1365 提议用 Class F 前缀提示接收方：地址的另一段藏在 IP 头部选项中，原来的源地址和目的地址字段仍在原位。
  • 提案的互通性一节写得干脆：不支持 Class F 的旧主机会忽略数据报。头部外形没改，不等于旧软件看得懂。

一个地址写不下，就把余下部分放到选项里。这听起来像 1992 年网络工程师能接受的节俭办法：不用另造一种 IP 头部，仍借用现成的字段和长度限制。Karanjit Siyan 在当年 9 月发表的 RFC 1365 中提出此法。文件的身份是 Informational，目的是征求讨论；它不是一项已经实施的标准。

空间从哪里来？IP 头部长度字段只有四位，最多表示十五个四字节字。没有选项的基本头部占五个字，还剩十个。Siyan 的预算是：常规选项留六个字，扩展地址的新选项用四个字。这个办法没有凭空创造容量，而是在已有上限内重新分配位置。

提案把固定地址字段中的高位 111110 指定为新的 Class F，并建议把原先的 Class E 缩窄为 11110。Class F 字段除地址首段外还带一个以字为单位的偏移量，让接收端直接跳到选项里的第二段，不必逐个搜索。第二段采用类型、长度、取值结构。文件给出 F-4 和 F-8 两种形式，分别讨论四字节和八字节的地址扩展形态。

真正的账单在接收端。旧主机按旧规则解释固定字段，不会因为选项中多出一段地址就突然懂得把两段拼起来。RFC 第三节明确说：不支持新 Class F 的主机会忽略该数据报，因此无法与现有主机通信。作者还画出接收端需要增加的处理代码。他认为这种改动比全面更换 IP 头部或协议小；“改得较少”与“无需改动”是两回事。

另一个易混淆点是名称。另一份 1992 年的 RFC 1375 也用了 Class F 一词，但讨论的是为小型网络划出更合身的地址类别。RFC 1365 的 Class F 是“固定字段加选项”的延长地址。字母相同，设计问题不同。

这份原始文件没有列出部署范围，也没有说明后来为何没有成为标准。它留下的硬事实更有用：旧收件端会丢掉新格式的数据报。协议作者可以保留封套的形状，但不能替旧程序决定封套里的新标记是什么意思。