摘要

  • RFC 906 提议让无盘计算机通过 IP 上的 TFTP 获取最初的代码，以应对不同厂商各自设计启动机制、安装点不得不维护多种引导服务器的负担。
  • Ross Finlayson 报告的 Motorola 68000/Ethernet 示例里，一台服务器返回 ERROR 并不会终止等待；首个有效 DATA 包会确定后续传输对象。ROM 代码不足 4 KB，但不包括 Ethernet 驱动。这是单个实现的记录，不是普及程度证明。

一台工作站在启动之后，或许能和邻机使用同一套互联网协议；但要先到达那个时刻，它仍需要一条特殊的路径。此时操作系统尚未运行，无法替它请求文件。ROM 中的小程序必须先建立足够的网络能力，取回下一段代码。

Ross Finlayson 于 1984 年 6 月发表的 RFC 906，写下了这个启动边界带来的实际摩擦。各个计算机厂商曾采用不同方式载入最初的文件。一家机构如果要支持多种机器，就可能需要部署多个引导服务器实现；这些机器启动之后却可以自由互通。RFC 906 因此提议为第一次传输采用共同协议：通过 IP 传输 TFTP。文件明确把自己称作面向 ARPA Internet 社群的提案，并请求讨论和改进意见；它没有声称这种做法已经普及。

TFTP 的选择很克制。引导程序发送一条带文件名的读请求，之后接收 DATA 包，并发回确认或错误。RFC 906 认为，最初的传输慢一些并不妨碍启动，因为第二阶段可以改用更快的协议。客户端需要能够接收最多 524 字节的 IP 数据报，不含 IP 头部：TFTP DATA 包最长 516 字节，再加 UDP 的 8 字节头部。引导中的机器也无需响应传入的 TFTP 读或写请求。它是一个精简的代码获取客户端，不是通用文件服务器。

这份 RFC 并未标准化整个启动体验。它只规定网络协议，没有规定用户如何启动机器、在控制台输入什么命令，也没有要求网络必须使用 Ethernet。于是，网络上的共同数据交换可以与各机构本地不同的启动入口、文件命名和机器操作方式并存。

报告中的实现让方案更具体。Finlayson 描述了一台使用 Ethernet 的 Motorola 68000 工作站，其引导代码驻留在 ROM。用户输入文件名，也可以提供工作站和服务器的 IP 地址。如果未指定服务器地址，请求可能被多个 TFTP 服务器收到。问题因此不只是“有没有服务器回应”，而是“哪一份回应会改变客户端状态”。

RFC 给出的规则很明确。一台服务器返回 TFTP ERROR 后，客户端不立即放弃，因为其他服务器仍可能稍后送来所需文件。首个有效 DATA 包会确定后续 ACK 所发往的 Internet 和 Ethernet 源地址。若另一台服务器随后也发来 DATA，客户端则向它返回 ERROR。一次请求可以被多个服务器听见，但有效的首份数据会把其中一台选作本次传输的对象。

这条规则容易被误读为身份验证，其实并非如此。1981 年的 TFTP 第二版说明，协议没有提供用户认证机制。RFC 906 的规则可以选出回应者，却不能证明它就是操作人员预期的服务器，也不能单独证明引导文件的来源。现有证据没有记录攻击或部署事故；它只揭示了提案把决定放在何处：客户端如何处理回应，以及本地环境允许谁来回应。

代码大小的说法同样有明确边界。报告中的实现代码不足 4 KB，但不含 Ethernet 设备驱动。这说明一位作者把所述客户端放进了受限的 ROM 设计；它不能代表所有处理器，也不是部署数量，更不能证明厂商特有的启动方式因此消失。

后来的文件能帮助理解架构，却不足以证明直接的采用链条。1985 年 RFC 951 将 BOOTP 描述为先确定地址和引导文件，再通常通过 TFTP 传输文件的两阶段过程。1989 年 RFC 1123 也将无盘启动写成由 ROM 程序完成的两个环节：先配置 IP，再载入主机系统代码。它们把准备阶段与文件传输的分工说得更清楚，但不能把 RFC 906 报告的一个实现变成部署统计。

所以，RFC 906 的历史意义在于划出一道边界，而不是宣布胜利。ROM 中的小程序可以通过 IP 请求下一份文件；用户怎样启动机器、部分服务器选择规则仍留在本地。第一个有效 DATA 包为“选定一个传输对象”设下了清晰的时点。协议因此保持精简，运维者仍须关注谁会最先提供代码。

Heng Lu 后来的 Note 65 在这里适合作为编辑分析的尺度，而不是 Finlayson 意图的证据：提案、已报告的实现、实际部署和持续使用是不同层次的证据。现有材料证明了提案与一个实例，却没有说明有多少站点采用，也没有证明它消除了 RFC 906 所指出的支持负担。

资料来源