摘要

  • RFC 917 不是标准；它记载斯坦福从 1982 年初运行 IP 子网，到 1984 年约有 330 台主机、18 个子网及数量相近的网关。
  • 斯坦福把 IP 子网号映射到既有 Pup 网络号；RFC 917 随后提议由各网络自行选定子网字段宽度，RFC 950 于 1985 年规范了主机侧程序。

RFC 917 写下的不是一场标准发布后的启动仪式，而是一段更早的运行记录。杰弗里·莫古尔在 1984 年 10 月提交这份《Internet Subnets》提案，邀请 ARPA Internet 社群讨论和改进；文中却说斯坦福的 IP 子网从 1982 年初已经投入使用。到提案撰写时，那里约有 330 台主机、18 个子网，以及数量相近的子网网关。

斯坦福没有从空白网络开始设计。自 1979 年起，多个实验性以太网上运行着 Pup 协议。IP 引入后，斯坦福采用 8 位子网号，让每个 IP 子网号与相应以太网的 Pup 网络号一致；Pup 的 8 位主机号则沿用为 IP 主机字段。IP 地址因此承载了已有网络的内部划分，而不是要求现场先把 Pup 的全部秩序撤掉。

网关也展示了这种接续。只理解 Pup 的网关根据 Pup 路由表转发 IP 数据报，却不调整 IP 首部中的 TTL。多宿主、同时充当网关的 Internet 主机会调整它。莫古尔记录说，斯坦福当时没有出现由转发环路造成的故障。这只是特定部署的经验，并不证明忽略 TTL 在其他网络也安全。

斯坦福以同一个流程维护 Pup 与 Internet 路由表，只需把 Pup 网络号转换成 IP 子网号。后来加入 10 Mbit/s 以太网时，网关使用基于 ARP 的方案，让未修改的主机也能加入。这个细节把扩容的问题从“地址格式该怎样写”推进到“怎样让旧主机和新链路共同工作”。

麻省理工学院的约束不同。在网络号尚未按类别划分时，为每条本地链路申请独立 IP 网络号会耗掉很大一部分地址空间。MIT 于是保留一个网络号，把 24 位“其余部分”切成三个 8 位字段：子网、必须为零的保留字段、主机。子网字节与 CHAOS 的子网号对齐。网关间动态路由交换原本在计划内，后来没有实现，静态路由表继续使用；ICMP Host Redirect 则有助于少改主机软件。

RFC 917 比较了四种编码方式：可变宽度、固定宽度，以及两种自描述编码。它选择每个网络内部宽度固定、不同网络之间可以不同的子网字段。自描述方式虽然便于只看地址判断是否使用子网，却可能限制既有主机号，并至少压缩本地地址空间。组织可以按自身规模，在子网号与主机号之间分配稀缺的本地地址位。

主机怎样知道这段字段有多宽？RFC 917 提议增加 ICMP Address Format Request 和 Address Format Reply，尤其照顾从局域网启动的无盘工作站；保存在本地的配置仍是可行方案。如果网关没有响应，主机可以先按零宽度处理，之后再根据网关通告修正。不要把这组提案消息和 RFC 950 后来的 Address Mask 消息混为一谈。

1985 年 4 月的 RFC 940 把问题表述为不同厂商主机之间的兼容风险：若各自使用不同子网算法，客户可能无法混用设备。同年 8 月的 RFC 950 明确以 RFC 917 为基础，并建议采用共同的主机程序，但对网关之间的程序描述并不完整。这里的时间顺序是先有地方性网络实践，再有把它变得可互通的提案和标准。

恒卢 Note 64 在本文中只是分析视角：共同层可以保持最小，同时让组织决定内部结构。它不是关于莫古尔、斯坦福、MIT 或 Postel 动机的历史证据。