摘要

  • 选项 60 是服务器解释的类别提示；61 是地址绑定数据库的键；55 列出客户端所求参数；43 容纳厂商自己解释的不透明信息。
  • 抓到报文，只能证明观察点看到这些字段或回复，不能据此确认制造商、稳定的实体身份、客户端实际安装的配置或业务连通性。

假设运维人员只有一帧 DHCP 请求。他看到一个像品牌名称的字符串、一串看起来很稳定的客户端标识，以及按顺序列出的配置项目。如果把这三项都塞进同一个“设备身份”栏，档案会显得完整，却把三种行为误写成同一项证明。1997 年的 RFC 2132 恰恰给出了拆开它们的语法与语义。

Steve Alexander 和 Ralph Droms 编写的规范继承 BOOTP 厂商扩展格式。外层选项通常由标签、长度和相应字节组成；Pad 与 End 是例外。BOOTP 厂商字段开头的四字节 magic cookie 决定后续数据如何解释。RFC 1048 曾奠定这套格式。解析器因而能找到字段边界，但格式正确并不说明字段值来自真正的设备厂商，更不等于完成认证。

选项 60 的厂商类别标识是客户端可选发送的一段字节串，供服务器解释。厂商可以用它描述客户端类型或配置。服务器若不懂这种类别信息，就必须忽略，虽然可以报告它；若按该类别回复厂商专属信息，规范建议使用选项 43。类别因此可能触发服务器的配置分支，但发送者自报的字符串不能独立证明硬件出处，也不能命令服务器采用某项策略。

选项 43 则是另一个解释空间。它携带不透明的厂商专属信息；若需要放入多个项目，规范建议在其中再封装代码、长度和值。内层代码可在厂商命名空间重新定义，不应冒充外层全球 DHCP 选项代码。内层 End 只结束这个封装区，不结束整个外层选项字段；若无内层 End，外层长度规定终点。抓包看见这些回复字节，只说明服务器发出了相应数据，尚不能证明客户端读懂、接受或应用。

选项 61 与“类别”又不同。服务器用客户端标识作为地址绑定数据库的索引，并应把它当作不透明对象。它可以包含硬件类型和地址，也可以采用其他标识；规范要求它在客户端所连子网上使用的标识中保持唯一，由厂商或管理员负责选取。数据库键的唯一性要求不是身份认证协议。相同字节再次出现，也不足以证明背后始终是同一个人或同一台物理机器。

选项 55 是参数请求列表：每个字节指向一个希望取得的选项代码。客户端可以按偏好排序；服务器不必按同一顺序返回，但必须尝试按请求顺序插入所求选项。请求不保证全部返回，更不保证主机已安装。选项 57 还让客户端声明愿意接收的 DHCP 消息最大长度，合法值至少为 576 字节。愿望清单和容量边界都是协商条件，不是运行状态的测量。

要判断后续实际发生了什么，还得看 RFC 2131 的发现、提供、请求、确认以及客户端检查这些独立阶段。合理的证据链需要完整相关交换、服务器策略和绑定记录、客户端接受并安装的状态，以及对目标服务的操作验证。这里的 RFC 没有提供任何具名网络的实测案例。RFC 2132 的安全章节也明确说，它没有讨论安全问题。不能把这句话倒读成“字段已经安全”。

历史意义在于，异构设备能在一套可扩展的报文语法中讨论不同类型的配置，同时让这些类型保持区分。类别提示、绑定键、请求偏好与私有负载同处一帧，却没有合并成权威身份。借用恒路关于运行代码优先的编辑视角，协议文本描述可检查的规则，运行中的网络仍需另外举证；这不是 RFC 另加的一条安全规定。

来源：RFC 2132、RFC 2131、RFC 1048；恒路的《运行代码优先》仅作为分析视角。