摘要

  • RFC 903 处理的是一个具体的冷启动问题：无盘主机知道自己的硬件地址，却要先取得协议地址才能使用 IP。
  • RARP 在数据链路层进行查询。服务器根据维护的硬件地址与协议地址映射表作答；回复既不验证设备身份，也不证明启动流程已经完成。
  • 协议没有明确的“未找到”回复。客户端收不到响应时只能等待超时，无法判断是映射不存在、报文丢失，还是没有服务器作答。
  • RFC 950 和 BOOTP 说明，一个地址并不足以配置主机：它还可能需要网关、名称服务器、子网掩码和启动文件。

IP 之前的第一个问题

设想一台没有本地磁盘的工作站。启动代码能够读取以太网接口的硬件地址，但没有保存互联网地址。此时发送 IP 请求并不能解决问题：主机还不知道该使用哪个源地址。

Ross Finlayson、Timothy Mann、Jeffrey Mogul 和 Marvin Theimer 在 1984 年 6 月发布的 RFC 903 中提出了 RARP。备忘录设想主机在以太网这样的广播介质上，向外部来源查询自己的协议地址。ARP 解决的是相反方向：已知协议地址时，查找硬件地址。RARP 则从硬件地址出发，询问与之对应的协议地址。

这并不是一项通用身份服务。RARP 不询问谁拥有这台工作站，也不判断某个人是否有权使用某个地址。它只是让尚未配置的主机，在能够正常进行 IP 通信之前，申请一条具体的映射。

本地服务器保存答案

RFC 903 有意将 RARP 定义为独立的数据链路协议。它复用了 ARP 的报文格式，但为反向请求和回复分配了不同操作码。如果主机要查询自己的地址，就会在发送方和目标硬件地址字段中填入同一个值。认识该地址的服务器可以在回复中填入对应的协议地址。

答案取决于服务器状态。RFC 903 说明，一个或多个 RARP 服务器需要维护硬件地址到协议地址的映射数据库。这与普通 ARP 不同：主机把其他主机的映射积累在缓存中，并没有客户端与服务器的角色区分。因此，RARP 带来一项运行依赖：客户端可以提问，但本地管理者必须让服务器的映射表保持可用。

回复是映射结果，不是凭证。RFC 没有定义任何认证机制来证明硬件地址属于某个人、某个所有者或获准接入的设备。回复也不能证明主机正确安装了地址、连通了网关，或已经载入操作系统；这些都发生在后续环节。

沉默不等于“查无此项”

RFC 903 定义了反向请求和回复，却没有“未找到”或错误报文。作者说明，多个服务器都可能获准回复。因此，规范没有设计单独的拒绝消息，而是要求请求方在合理时间内没有收到回复时自行超时。

这种取舍让交换保持简单，却留下含糊的观测结果。超时可能表示没有服务器拥有这条映射；也可能是请求或回复丢失、链路故障，或者根本没有可用服务器。沉默不能区分这些情况。启动日志若只写“RARP 超时”，就无法据此确定原因。

重建故障时，这个边界很重要。没有响应只能证明客户端收到了什么——它什么也没收到；这不能证明地址没有被分配。原始备忘录划清了这一点，但并未规定一种能逐一识别所有原因的诊断系统。

一个地址无法配置整台主机

更大的启动问题很快显现出来。RFC 950 把 RARP 列为新启动主机发现互联网地址的一种方式，随后指出主机还可能需要网关的硬件地址、名称服务器的 IP 地址和子网掩码。它认为，若可能，最好在一次请求中取得这些参数，而不是连续发出多次广播。

次年制定的 BOOTP 保留了硬件地址到 IP 地址的查询，同时可以携带更多启动信息，包括可选的文件名。它的设计还支持经由网关启动。RFC 951 明确比较了两种做法：BOOTP 使用 IP/UDP，而 RARP 属于硬件链路层报文，需要对内核或驱动做专门修改才能访问。RFC 1542 后来澄清了 BOOTP 中继行为；RFC 2131 则描述 DHCP 如何建立在 BOOTP 之上，增加可复用地址的自动分配和配置选项。

这段演进史并不能证明所有网络都在某个固定日期停止使用 RARP。它反映的是问题定义的变化：发现一个预先分配的地址很有用，但若要跨越路由网络完成主机启动，就需要更完整的交换与中继路径。

记录并不是设备本身

Heng Lu 的第 72 篇笔记提供了一个后来的分析视角，而非关于 1984 年的史料：登记记录描述现实，却不会创造现实。RARP 不是全球登记系统，但这个区别仍适用。服务器表可以协调一项本地映射，却不会把返回地址变成设备所有权、用户身份或运行成功的证明。

这个协议的历史贡献范围更窄，却很实际：主机可以向自己已经能够触及的链路询问开始 IP 通信所需的那个地址。边界也正是代价所在：本地映射必须有人维护，沉默不会解释原因，回复也不是完整配置。

来源

RFC 903 — A Reverse Address Resolution Protocol；RFC 826 — An Ethernet Address Resolution Protocol；RFC 950 — Internet Standard Subnetting Procedure；RFC 951 — Bootstrap Protocol；RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol；RFC 2131 — Dynamic Host Configuration Protocol。第 72 篇笔记是后来的编辑分析视角，不是历史来源。