摘要

  • DHCP 可以借用原本放服务器名和启动文件名的固定字段装载选项，但必须在普通选项区用编号 52 明确声明，不能让接收端从内容自行猜测。
  • 借用空间与拆分长选项是两件事。RFC 3396 将同一编号的分段按普通选项区、file、sname 的逻辑顺序拼接；这一顺序不同于字段在报文中的物理排列。
  • 字段重用没有取消边界，也没有证明配置可信。旧名称可以移入专用选项，编码端仍需考虑对端能力，接收端则要先还原完整数据再解释其含义。

看到文件名的位置，先别读成文件名

检查一份 DHCP 回答时，分析工具可能在 file 字段中看到不像路径的字节。最直接的解释是文件名损坏了，或者服务器没有提供启动文件。两种判断都可能过早：这一块空间也许已经被明确改作选项区。

此时，答案不在那些可疑字节是否像文字，而在普通 options 字段里有没有一项声明。只有先读懂它，接收端才知道应当把 file 当成旧式字符串，还是一系列带编号与长度的配置参数。

这是一个格式层面的可能情形，不是本篇测得的故障。它揭示的错误很具体：字段保留了原来的位置和名字，却不一定保留原来的解释方式。协议若想复用这些空间，就必须把解释权的变化写进双方都能读到的规则。

启动协议曾给名字留出固定位置

1985 年 9 月的 RFC 951 为 BOOTP 描述了固定报文布局。sname 占 64 个字节，用于可选的服务器主机名；file 占 128 个字节，用于启动文件名。两者采用以零结尾的字符串形式，另有 64 字节的 vend 区留给厂商相关信息。

这样的安排符合当时的启动问题：机器可能尚未装载完整运行环境，需要先取得地址、服务器和启动文件。固定位置让小型启动程序容易找到这些信息。名字并非后来随意塞进去的附属品，而是原始用途的一部分。

DHCP 沿用了这副报文骨架，却需要携带更丰富的配置。1997 年 3 月的 RFC 2131 将 options 变为可变长度区域，要求客户端能够接收至少 312 字节的选项字段，也允许通过最大消息长度选项处理更大的消息。

因此，不能把 DHCP 描述成从头到尾只有一个固定的小选项盒，更不能把单个选项的 255 字节数据上限当成整份报文的上限。总空间、一个字段的剩余空间和一个选项实例能声明的长度，是三个不同的约束。

借用在 1993 年已经写进规则

选项重载并不是 2002 年长选项规范才发明的办法。RFC 1533 在 1993 年 10 月便定义了 Option Overload：编号 52，数据长度为一个字节。值 1 表示 file 用来装选项，值 2 表示 sname，值 3 则表示两者都被使用。

声明作用于这份消息中被指定的字段。它不是允许程序把任何陌生内容都解释成选项的通行证，也不是从此改变后续全部报文的永久开关。没有选中的字段，不应因为旁边空间紧张就自动加入解析范围。

RFC 2131 对声明的位置作了关键规定：它必须出现在普通 options 字段中。接收端先读那里，才能知道是否还要读 file 和 sname。若把“此处改作他用”的说明藏进尚未获准解释的区域，双方就会陷入循环判断。

这个小声明把局部选择与共同规则分开。发送方可以决定是否使用额外空间，却不能自行决定对端应该怎样发现这项选择。

三块空间，各有自己的终点

普通选项区以四字节的 magic cookie 开头，随后是选项。多数选项由一个编号字节、一个长度字节和对应长度的数据组成；Pad 与 End 是只占一个字节的例外。长度记录的是数据，不包括编号和长度本身。

被重载的 file 或 sname 必须从字段的第一个字节开始放选项，不再额外放一个普通选项区的 cookie。每块被使用的区域都要有 End，剩余部分用 Pad 填满。一个编码后的选项实例必须完整留在同一字段内，不能因为后面还有空间就穿过分界。

所以，一个字段中的 End 不是“整份消息从此没有其他配置”。接收端仍须按重载声明处理后续逻辑区域。相反，某段数据内部恰好出现零字节，也不能被无条件当成整个选项区的终点；它处于哪层语法中，决定了应如何解释。

file 与 sname 合起来是 192 个原始字节的位置，但这不等于白得 192 字节配置数据。编号、长度、End、填充、声明以及需要另行表示的启动信息都会占空间。重载是有限复用，不是无限扩容，更不是把 IP 分片换了一个名字。

启动文件可以离开自己的专用栏

字段借走了，原来的信息怎么办？RFC 2132 在 1997 年的选项定义中给出两种对应表示：选项 66 用于 sname 被重载时的 TFTP 服务器名，选项 67 用于 file 被重载时的启动文件名。

这让一个固定位置失去原用途时，其参数仍可作为带标签的数据存在。字段被重新解释，不等于启动文件被删除。接收端如果只在旧位置寻找字符串，就可能把“换了位置”误报为“没有提供”。

今天的 IANA BOOTP/DHCP 参数登记表 保留了 52、66、67 及其用途，也列出后来的域搜索选项 119。这些是选项编号，不是传输端口；选项 67 与 DHCP 服务器使用的 UDP 端口号恰好相同，不能因此把两者混为一谈。

登记表说明参与者可以共同识别哪类参数，却不证明哪台设备已支持，也不保证某个返回的文件名真实存在、可下载或获准执行。格式上的位置与实际启动结果仍是不同问题。

有地方放，不代表一个长度字节写得下

一个普通选项实例的长度只有八位，最多声明 255 字节数据。即使整份 DHCP 消息还有空间，一个更长的逻辑值也不能靠把这个长度随意增大来发送。

另一种情况甚至不需要长值：某个选项小于 255 字节，却放不进当前字段剩余的空隙，而另一块获准使用的字段还有空间。它同样需要分段，而不是直接越过边界。

Ted Lemon 与 Stuart Cheshire 在 2002 年 11 月的 RFC 3396 中将这两类情况放到同一套规则里。它也明确删除了 RFC 2131 中默认限制选项只出现一次的句子，整理同编号选项的拼接方式。不能把这项后续澄清说成所有早期实现从来就已一致遵循。

每一段仍是普通的带长度选项，使用相同编号，带自己的长度；各段数据长度相加，才是完整逻辑值的长度。接收端不能只保留第一次或最后一次，也不能把每段都当成一个独立参数。

读取顺序不跟着物理位置走

RFC 3396 所说的 aggregate option buffer 是逻辑集合，不是把报文里的三块区域实际搬到一起。它的顺序是普通 options、获准使用的 file、获准使用的 sname。原始布局里，sname 却在 file 前面，而两者又都在 options 前面。

这意味着，沿着捕获字节从头到尾扫描并随见随拼，并不等于按规范重组。接收端必须先知道哪些区域被重载，再按共同定义的逻辑顺序汇集同编号的数据。没有被借用的区域则完全不属于这个集合。

分段位置没有语义。RFC 3396 用一个很短的启动路径说明这一点：/diskless/foo 只有 13 字节，也可以分为七字节和六字节两段，切口落在 diskless 一词内部。两段的编号与长度不是文件名的一部分；重组后才恢复那条完整路径。

这也说明，重载与拼接并不互为同义词。被借用的字段可以装完整、无需拆开的选项；一个较长值也可以在普通 options 中重复编码成多段，不使用 file 或 sname。一个机制增加可用位置，另一个规定多个实例如何还原成一个值。

旧接收端不会因为新文档而自动改变

RFC 3396 记录，当时许多已经部署的 DHCP 程序不支持拼接。它因此要求发送方谨慎：除非别无选择，或者知道对端能够正确处理，否则不应随意拆分。

这种判断可以来自对端已经提供或请求了某种明确要求拼接能力的选项，也可以来自管理员的显式配置。它不是本篇新发明的能力位，也不是说今天所有设备都仍有同样缺陷。历史文档报告的兼容性状况，不能充当当前全球部署统计。

发送方可以选择不拆分普通选项，接收责任却不能因此消失。实现了某种要求拼接的选项，就必须能够重组收到的其他分段选项。自己采用简单的输出方式，不代表别人也只能用同样简单的表示。

先拼好，才知道指针从哪里算

同在 2002 年 11 月发布的 RFC 3397 给出一个具体用途：DHCP 域搜索选项 119。域搜索列表可能很长，也可能反复出现相同后缀，因此它使用 DNS 风格的名称压缩，并允许按 RFC 3396 分成多份选项。

这里的压缩偏移从完整拼接后的选项数据开始计算，不包括每段的编号与长度，更不是从 DHCP 报文开头计算。各段必须先在逻辑上连成完整数据，再解释其中的名称；单独解读一段，会给指针安上错误的坐标原点。

本篇不再重述 DNS 压缩的全部历史。这个例子只说明一个依赖关系：上层含义可能建立在下层重组已经完成的前提上。把分段当成独立对象，不只是显示出两个短字符串，而可能改变整个参数的解释。

正确解码也不等于可信配置。RFC 3397 提醒，域搜索列表可能让一个短名称被扩展到另一个完整域名；即使那个域名的数据有有效签名，也没有证明用户本来想去那里。借用字段和拼接字节解决的是表示问题，不会替主机决定谁有权配置它。

DHCP 没有抹掉旧报文的边界，而是用声明和确定顺序重新安排边界内的用途。真正可共享的扩展，不仅要有地方写，还要让另一端知道何时换一种读法。