摘要

  • RFC 3361 让 DHCPv4 选项 120 在两种互斥编码之间选择：优先使用的 DNS 名称清单，或指向本地 SIP 出站代理的有序 IPv4 地址清单。
  • 名称形式可把传输、端口、实例与故障转移交给 DNS 服务记录；地址形式固定主机顺序。合法租约只能证明配置送达，不能证明 SIP 事务或呼叫路径成功。

一个参数越早出现，越容易被误当成完整答案。客户端刚取得 DHCP 租约，地址、网关、解析器都已就位；如果选项 120 还给出本地 SIP 代理，系统看起来已经知道该往哪里走。然而“收到起点”与“抵达终点”之间，仍隔着解析、传输、事务状态、后续代理、会话协商和媒体。

2002 年 8 月以 Standards Track 发布的 RFC 3361，为 DHCPv4 定义了选项 120。它让 SIP 客户端发现用于所有出站 SIP 请求的本地代理。在某些网络里，客户端可以直接联系 SIP URI 指向的目标；在存在防火墙等情形时，本地出站代理可能不可缺少。DHCP 只是多种发现方法之一，手工配置仍是另一条路。

选项代码与长度之后，是一个很小却影响深远的编码字节。值为零，后面是一串 DNS 域名；值为一，后面是一个或多个二进制 IPv4 地址。所有实现都必须支持两种形式，尽管 RFC 更推荐名称。

这不是同一事实的两种写法。域名会把客户端带入 RFC 3263 定义的 SIP 服务器定位过程。NAPTR 记录可以暴露可用传输，SRV 记录可以提供实例、端口、优先级与权重，A 或 AAAA 则在后面给出地址或作为回退。客户端还要把域提供的能力同自身支持的传输和本地政策求交集。名称实际上把下一步控制权交给一张可变化的服务图。

IPv4 清单携带的信息更窄。地址按偏好排序，但选项本身不包含 NAPTR 服务、SRV 端口、优先级、权重或传输元数据。它像一条已经冻结在租约里的候选主机序列。要改变这条序列，通常需要改变 DHCP 配置并等待重新分发。

于是，两种编码把变更权放在不同位置。使用名称时，DNS 管理者无需重发租约，就可以移动实例、调整顺序或改变服务记录；使用字面地址时，DHCP 管理者直接掌握更多主机选择。但客户端版本、缓存、传输能力、政策以及代理当时的状态，都可能让配置意图落空。

RFC 3361 还限定了多个域名的含义。它们应当代表不同的 NAPTR 域，例如不同服务提供者，而不是用多个域名去替代同一域的多个 A 记录。客户端按照清单顺序尝试。只有第一域无法联系、双方没有共同传输，或本地政策禁止该域时，才继续解析后面的域。

因此，顺序存在于好几个层次。DHCP 对提供者域排序；NAPTR 对传输服务排序；SRV 用优先级和权重安排实例；地址解析产生主机候选；客户端能力与政策继续过滤。最终看到的一个代理地址，是多位控制者连续决策的压缩结果。

RFC 3263 还划出事务边界。一旦某台 SIP 服务器已为一个事务成功接触，该事务的重传、CANCEL，以及非 2xx 最终响应对应的 ACK，都必须回到同一台服务器。发现阶段可以在候选之间选择；状态形成后，不能让 DNS 的下一次变化随意拆散事务。

编码字节也暴露了语法与语义之间的危险。服务器不得在同一 DHCP 消息中混合两种编码，即使把它们放在两个独立的选项 120 实例里也不行。DHCP 先拼接同类选项的多次出现，再解释整体。如果两个各自看似正确的片段采用不同首字节语法，接收端会得到一个语义上无法成立的对象。

同年稍后的 RFC 3396 进一步规定了重复 DHCPv4 选项的拼接顺序，让长值可以跨越多个实例和过载字段。它同时承认，当时许多已经部署的 DHCP 代理并不支持选项拼接。发送者完全符合长选项规则，接收者仍可能无法重建。

RFC 3361 规定，域名清单超过单个选项的容量时必须使用这套机制。因此，在发出任何 DNS 查询之前，长清单已经依赖片段顺序、字段过载和客户端实现。服务器“确实发送了完整值”，并不证明客户端解析出了同一个值。

2003 年的 RFC 3319 为 DHCPv6 采用了不同设计：域名与 IPv6 地址各用一个独立选项代码。文件明确说明 DHCPv6 不缺选项代码，因此不必沿用 IPv4 的编码字节。分开后，选项更短、解析更简单、数值地址的字对齐更自然，而且客户端可以明确请求自己需要的形式。一个登记空间里的稀缺，曾经转化成每个 IPv4 消息里的复杂度。

名称编码也承载了当时对未来的安排。RFC 3361 沿用 RFC 1035 的标签格式，并要求客户端支持 DNS 压缩，其中一个考虑是兼容未来的国际化域名机制。名称之下，RFC 2782 的 SRV 模型和 RFC 3403 所代表的 NAPTR 体系，负责更丰富的服务选择。选项 120 之所以小，是因为它能指向更大的独立基础设施。

间接性同时扩大灵活性与信任面。RFC 3361 的安全章节警告：能够修改或插入 DHCP 响应的攻击者，可以把 SIP 用户代理引向恶意代理，从而截获请求或拒绝服务；还可以删去本会解析到基于 TLS 的 SIP 服务器的名称，使截获更容易。DHCP 消息不传递通话内容，却能决定信令首先敲哪扇门，也能在选择发生前让某些安全路径消失。

今天的 IANA BOOTP 与 DHCP 参数登记册仍把代码 120 记录为 SIP Servers DHCP Option。这是编号协调持续存在的凭据。它不能证明某个网络正在发送该选项、客户端会请求或理解两种编码，更不能证明所列代理正在运行。

观察到一份租约也只能得出有限结论。抓包可以证明选项 120 的确抵达以及其中有哪些字节；解码器可以证明这些字节构成名称或地址。它不能证明 DNS 返回记录、传输能力相交、连接打开、代理接受事务、下游找到目标、会话完成协商或媒体实际流动。

每个层次都需要独立凭据。DHCP 层保存服务器、relay、原始字节、编码、顺序和租期。名称路径保存 NAPTR、SRV、A/AAAA、TTL 以及客户端过滤后的选择。地址路径保存尝试顺序、端口和传输。随后另行记录代理联系、事务响应、后续路由、会话描述与媒体。

本文明确把 Lu Heng 的两篇文章作为分析镜片。“Minimum Initial Specification”帮助解释：一个狭窄的共同选项能够产生价值，同时把提供者运营、DNS 政策和部署选择留在本地。“Reality Layers”则防止把登记代码、送达配置、解析服务、运行实现和呼叫结果合并为一项事实。这是编辑分析，不是对 RFC 3361 作者身份或标准意图的主张。

选项 120 建立的是会合点，不是完成证明。编码字节可以把后续选择交给活的命名系统，也可以把部分选择冻结成地址次序。租约写明了信令从哪里开始；路径是否继续，仍要由下一层证据回答。

来源