摘要

  • RFC 1931 允许同一网段部署多个 Dynamic RARP 应答服务器来提高可用性，但要求它们都连接同一个逻辑地址权威；不同应答除服务器自身字段外若不一致，就是协议错误。
  • 地址权威维护永久绑定、临时绑定和可用池，却并不等于现场事实。RFC 建议分配前用 ARP 或 ICMP 探测，因为数据库标为“可用”的地址可能正被使用。
  • 这份文件于 1996 年 4 月以 Informational 发布，今天列入 Legacy；它记录的是部分 Sun 平台自 1988 年开始使用的历史设计，并未制定互联网标准，也不能据此声称它导致了后来的 DHCP。

沉默不是一个错误码

RARP 面向这样一台启动中的主机：它知道自己的硬件地址，却不知道协议地址。主机广播询问，由保存硬件地址到 IP 映射的一个或多个服务器作答。原协议没有否定应答，这是有意的——一台服务器不知道，并不表示其他服务器也不知道。

但对安装程序而言，沉默的含义太多了。请求可能丢失，服务器可能离线，机器可能未登记，也可能接错了网段；甚至网络里根本没有 RARP 服务器。客户端只能退避重试，却不知道等待是否仍有意义。所谓“插上线就自动安装”，也不是真的从零开始：网络号、地址结构和命名系统仍须由管理员预先准备。

RFC 1931 所记录的 Dynamic RARP，首先把这种沉默拆成了可观察的结果。它沿用 RARP 的包格式与链路封装，新增请求、应答和错误三个操作码。已有永久绑定时，服务器返回普通 REVARP_REPLY；没有永久绑定时，可以分配一个临时地址并返回 DRARP_REPLY；不能分配则必须返回 DRARP_ERROR。

错误又被细分为策略禁止、地址耗尽、权威暂时不可用、已知机器出现在错误网段，以及其他失败。分类让客户端和管理员能采取不同动作，但错误名称本身不会认证服务器，更不会证明它描述的原因真实。

这份文档的历史边界同样清楚。RFC Editor 的现行记录 将其列为 Legacy 流的 Informational 文档，并明确它没有定义互联网标准。文中说某些 Sun Microsystems 平台从 1988 年起使用 DRARP；到 1996 年 4 月发表时，这些平台已不再销售，DHCP 也已在一定程度上承担其角色。这里保存的是经验，不是为 DRARP 追认继承权。

动态分配不等于每台服务器自行决定

DRARP 最容易被误读之处，是把“多个服务器”当成“多个权威”。RFC 的规则恰好相反。同一请求得到的多个 DRARP 应答，除了发送服务器自身地址字段以外必须一致；否则就是协议错误。多个进程只是一个服务的多个出口。

每个网段放置一台服务器，可以降低网络分区造成的损失；同一网段放置多台，则能减少单机或单段故障的影响。但所有服务器都必须与同一个地址权威通信。文中实现用 NIS 和一个集中式 RPC 服务 IPalloc 保存与修改绑定，并限制管理员和 DRARP 服务器等授权主体执行分配。RFC 只是描述该机制，没有把 IPalloc 或其安全做法标准化。

地址权威维护三类状态：永久绑定、临时绑定，以及仍可用于临时分配的地址。它要支持创建、查询、删除、清理，还要处理并发请求与变更授权。“一个权威”是逻辑一致性要求，不必等于一台物理主机。RFC 也承认可以分区实现，只是实现和管理成本会显著上升。

这一区分具有现实意义。五台高可用服务器若共享同一份错误状态，只会更快、更稳定地传播错误。冗余提高的是回答能力，不会自动产生正确性，更不会把分配权去中心化。

一致的账本仍可能落后于网线

RFC 1931 并未把权威数据库神化为现场事实。它明确提醒：管理数据库认为可用的地址，实际上可能已经被某台运行中的设备占用。因此分配前应检查网络，早期实现采用 ARP 与 ICMP Echo。

ARP 可以按需发现协议地址与硬件地址之间的映射。收到响应，是“此刻、此链路上有人声称使用该地址”的证据；它不是产权证，也不能证明响应者获得授权。没有响应同样不是永久空闲的证明，分区、丢包或静默设备都可能制造假阴性。

于是出现三个不能互相替代的层次。硬件标识只是报文携带的链路层值；权威数据库表达组织当前承认的绑定；现场探测提供某一时刻的局部运行证据。把三者合并为“身份”，会同时丢失授权、唯一性与时间范围。

机器跨网段移动时，边界更明显。两个地址权威必须相同或彼此通信，硬件标识的作用域也必须足够宽，才能避免不同网段里相同数值指向不同设备。即使如此，一个硬件地址也不能认证持有者或用户。

服务器还能监听其他服务器的通告，发现似乎未协调的应答者，并在进入受限模式前上报。RFC 却没有定义服务器之间裁定“谁是冒牌者”的协议。发现异常与作出治理判断，是两件事；后者仍需通过地址权威或线下管理完成。

生命周期不是完成证明

临时地址必须活得足够久，让安装、命名和其他管理记录完成传播，并能穿过短暂的服务器或网络故障。RFC 提到早期实现使用一小时缓存已足够，但这只是经验值，不是普适租期。到期允许稀缺地址回收，却不能证明客户端已经配置成功。

这一点把地址分配与后续服务明确分开。拿到应答，不等于名称注册成功，不等于启动资源已经分配，不等于密钥或初始口令已经安全送达，也不等于应用可用。协议状态只能证明协议承诺的那一小步。

后来 DHCP 采用了不同的状态机。RFC 1541 让客户端面对多个报价作出显式选择，并以服务器标识和租约组织承诺；RFC 2131 进一步规范流程，也允许客户端在本地检查发现地址冲突后拒绝报价。这是架构上的对照，不是 DRARP 造成 DHCP 的历史因果链。

另一条路径把局部冲突处理缩到单一链路。RFC 3927 允许主机自行选择、探测、声明乃至防御 IPv4 链路本地地址，但该地址不可路由，也不承担持久身份。RFC 5227 将 IPv4 地址冲突检测整理为 ARP Probe 与 Announcement。它们提供的仍是局部、限时证据，无法消除隔离、并发与恶意响应的限制。

规则、运行与现实之间

Heng Lu 的《Running-Code Primacy》为这段历史提供了一把分析尺。数据库是符号化协调记录，真正上网的主机与报文则会反驳过时记录。运行代码的优先性不是取消规则，而是要求规则在执行前接受现场检验。

《Minimum Initial Specification》提醒我们，共同层应严格但尽量小。DRARP 真正需要共享的是：同一请求的答案必须一致，错误必须可区分，临时状态不能在依赖尚未收敛前回收。NIS 表结构、RPC 实现、缓存时长和本地授权政策可以保留为局部选择。

《On Reality Layers》所区分的现实层，也能解释这份 RFC 的持久价值。账本能协调，协议应答能配置，现场探测能否定；三者都有力量，却不是同一种力量。RFC 1931 没把多台服务器误写成多个真相，也没把一个一致账本误写成现实本身。

来源

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — RFC 1931 现行记录
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile