摘要

  • RFC 3925 让 DHCPv4 能在一条消息中承载多个厂商的数据，并为每项数据明确划界。
  • 它登记了外层选项编号，却把内层子选项代码及含义留给各厂商；PEN 标识一个命名空间，不是经过认证的声明。

在 RFC 3925 出现前，DHCPv4 交换厂商信息的常见路径很窄。RFC 2132 的选项 60 允许客户端发送厂商类别字符串，选项 43 则承载一个由厂商定义、内容不透明的数据对象。服务器根据选项 60 所指的厂商来解释选项 43。只有一个厂商的词汇时，这种安排可行；当设备或行业方案需要同时容纳多个厂商分别定义的信息时，解释就会变得含混。RFC 3925 把问题界定为封装歧义，而不是 DHCP 地址分配失效。

它增加了另一组选项：124“Vendor-Identifying Vendor Class”和 125“Vendor-Identifying Vendor-Specific Information”。每个厂商的数据旁都带有 IANA 私有企业编号（PEN）。选项 125 可以包含多个条目，每个条目依次给出企业编号、数据长度和厂商数据。长度划出数据边界，编号指出应采用哪个厂商的解释。RFC 3925 明确保留原有的选项 60 和 43，因此实现可能在同一交互中遇到新旧两种形式。

这正是设计上的分层：IANA 分配外层 DHCP 选项代码；IANA 的 Enterprise Numbers 登记表分配标识厂商空间的编号。两个登记表都不定义数据内容的语义。内层子选项采用代码、长度、值结构，但 RFC 3925 明言，子选项代码由厂商定义、不由 IANA 管理。标准提供了让多个方言并存的容器，而不是一本能翻译所有方言的共同词典。

报文长度也有限制。聚合后的数据可能超过单个选项的长度上限，因此 RFC 3925 要求选项 124 和 125 按 RFC 3396 进行拼接。接收方应先把重复出现的片段合并成一个逻辑选项，再解析其中条目；不能把每个片段误当作一条新的厂商记录。标准建议一个企业编号在所有实例中只出现一次；若重复，行为没有定义。容器允许多个厂商共存，却没有为所有重复或格式错误的组合赋予意义。

RFC 3925 借用了 RFC 3315 先前为 DHCPv6 定义的厂商类别和厂商专属信息选项模式。这是文档记录下来的设计复用，并不能证明两种协议的负载语义或部署情况相同。它也没有认证厂商：RFC 3925 本身不提供安全性；RFC 3118 则另行定义了可在需要真实性时使用的 DHCP 认证机制。报文里携带一个编号，只是在选择命名空间，不是签名。

因此，RFC 3925 的历史意义在于：它把边界写清，以便各方共存，同时不把局部语义收归一个中心。外层登记表能帮助实现解析容器并识别命名空间；它不能告诉客户端某个厂商字节会触发什么、设备是否真属于那个厂商，或实现是否支持该选项。这些问题需要另一类证据。RFC 和 IANA 登记表证明设计与代码分配存在，却不测量采用率、互操作性或实际运行结果。

来源