Summary

  • 1985 年的 BOOTP 让无盘客户端在尚不能向服务器发送普通 IP 请求时，先索取地址与启动文件信息；中继可以把这次交互带出本地网络。
  • giaddr 描述的是 BOOTP 自己的中继路径。RFC 1542 后来明确，它不是客户端通用的 IP 路由器，也不是默认路由。

主机还不能开口时，网络得先替它搭桥

一台刚启动的无盘工作站遇到一个循环难题：要使用 IP，它先得有 Internet 地址；但要知道该用哪个地址，又必须向网络询问。它还需要找到继续启动所需的服务器和文件。如果服务器位于另一张网络，本地广播不会自行穿过普通路由器。

1985 年 9 月发布的 RFC 951 把 BOOTP 描述为启动过程的第一阶段：确定客户端地址并选出启动文件。客户端发送 BOOTREQUEST，其中带有硬件地址，以及在已知时填写的 IP 地址。如果 ciaddr 为零，服务器可以用硬件地址查询自己的数据库，再把客户端地址写入 yiaddr。其他字段标出服务器地址和文件名。请求与应答通过 UDP 的 67、68 端口传送。

这条应答本身并不会加载操作系统。RFC 951 明确区分地址与文件的选择，以及后续的文件传输；后者通常使用 TFTP。早在 1984 年，RFC 906 已讨论网络启动时用 TFTP 加载文件。因此，BOOTP 应答写明服务器和文件，并不能证明客户端已经连上服务器、收齐文件或完成启动。

本地广播，随后由中继访问远端服务

BOOTP 不要求尚未配置的客户端先通过 DNS 找到远端服务器，也不要求它预先知道远端路由。客户端可以在本地电缆上广播请求。若服务器不在这条链路上，网关或转发代理可把 BOOTP 请求送过去，再把应答带回来。RFC 951 将跨网转发列为可选能力：网关与服务器需要增加相应代码，客户端却无需执行特别步骤。

数据包里有 giaddr，1985 年的说明称它为网关 IP 地址。在转发流程中，第一台网关可以在该字段仍为零时填入自己的地址，并递增 hops。若 giaddr 非零，服务器可以通过 BOOTP 服务器端口把应答发往该地址，再由中继把它送到客户端所在网络。这个字段帮助的是启动事务跨网找到返回路径。

它并不等于主机启动后会采用的路由。RFC 951 的早期措辞留有歧义：其中一段把经 giaddr 转发的目的描述成“到达服务器”。但启动文件的传输与客户端日常 IP 路由是两项不同工作。字段名字里出现“网关”，不足以把两者合并。

1993 年的澄清划清了边界

RFC 1542 直接处理了这种歧义。它指出，早期规范没有充分界定转发代理的行为，于是采用“中继代理”一词，把这项职责与普通 IP 转发区分开来。BOOTP 中继是这条消息的接收者：它收到一条消息，再生成一条 BOOTP 消息，而不是原样放行一个普通 IP 数据报。中继可以运行在互联两张网络的路由器上，也可以由直接连接客户端网络的主机提供。

RFC 1542 对 giaddr 的解释是关键。这个字段用来让 BOOTREQUEST 经中继抵达其他网络上的服务器，并让 BOOTREPLY 经中继返回。RFC 明确说，它不是客户端通用的 IP 路由器，客户端不得把它如此解读。若客户端要连接不在本地的 TFTP 服务器，仍需通过另一种配置项或发现机制取得第一跳路由器地址。

这项澄清没有推翻 1985 年的设计，而是说明它的职责止于何处：在客户端的 IP 配置尚未完成时，为启动服务提供一条跨网消息路径。后续的数据流量仍需另外配置。

集中启动带来了什么，也留下了什么

有了中继，启动服务器、硬件地址与 IP 地址的对应记录、以及启动文件都可以放在本地电缆之外。这种架构可能减少每个网段都部署一台启动服务器的需要，也让运维者可以集中维护映射和文件。这是从 RFC 描述的机制推导出的架构含义，并非对实际部署比例或成本的测量。

启动链条仍依赖多个环节：本地链路、可用的中继、正确配置的服务器目的地、服务器中的客户端记录、文件、客户端自己的路由，以及后续 TFTP 传输。看到 BOOTP 应答，不能证明之后的任何一步已经完成。中继地址也不代表用户身份、授权，或客户端的默认路由。

后来 DHCP 沿用了中继代理行为，并增加了不同的地址分配方式，包括有期限的租约。但这段延续不应混淆 BOOTP 启动交换、DHCP 租约周期、TFTP 文件传输和普通 IP 路由。一次主机启动可能需要全部四者，每个机制却有独立状态和可核对记录。

这个历史问题藏在四个字符里。giaddr 帮一条消息跨越网络边界，当时主机还在学习如何接入 IP。名字叫“网关”，并不会让它变成主机自己的网关。在 Internet 基础设施里，控制消息的返回路径、客户端的下一跳、文件服务器地址和服务成功，是相互关联但不可互换的事实。

来源