摘要

  • RFC 3319 定义了两种 DHCPv6 选项，用于发现本地 SIP 出站代理：有序域名列表和有序 IPv6 地址列表。
  • 两种列表都收到时，客户端应优先使用域名并遵循 SIP 定位规则；这些选项提供候选目的地，却不证明代理可信或通话已经接通。

租约能回答的问题，比电话呼叫窄得多

RFC 3319 处理的问题很容易被说错。SIP 客户端即使知道 SIP URI 中写着哪个地址，也可能仍需要本地出站代理。防火墙、拨号计划、紧急服务或其他本地服务，都可能使这个中间节点有用。手工配置当然可行；RFC 提供另一条路径：由 DHCPv6 告知客户端有哪些代理候选可供发现。

关键在于代理的职责范围。RFC 3261 区分用户代理、代理服务器、重定向服务器和注册服务器；RFC 3319 所说的“SIP 服务器”特指运行出站代理的主机。DHCP 回复列出这类主机，不足以说明用户已注册、目的地获准、SIP 对话已完成、媒体已协商，或通话可用。

两种编码，一套偏好次序

选项 21 OPTION_SIP_SERVER_D 携带域名列表；选项 22 OPTION_SIP_SERVER_A 携带 IPv6 地址列表。两者均按偏好排序，符合规范的实现必须支持二者。客户端可以在 DHCPv6 的 Option Request Option 中请求一种或两种；服务器回复取决于配置及客户端请求。即使请求两种，服务器也可能只返回一种，并且应优先选择域名选项。

如果两种列表都到达，客户端应先用域名。数字地址是有条件的后备方案：只有第一组中的域名都无法解析或无法到达时，客户端才可以尝试地址列表。这不等于“把所有地址都试一遍”。客户端也不会立即解析所有后续域名，而是依序尝试；前一项失败、没有双方可用的传输方式，或被本地策略禁止时，才继续下一项。

域名是 SIP 定位的输入，不是替代品

域名列表接入 RFC 3263 所述的 SIP 服务器定位流程。RFC 3319 建议列表中的名字指向不同的 NAPTR 记录，而非仅指向不同的 A 记录；这样一个 DHCP 服务器就能指出由不同提供方运营的代理候选。但该选项并不取代 NAPTR 或 SRV：它给出起点，后续仍需 SIP 定位机制与传输规则。

因此，“后备”有严格含义。某个名字排在列表后面，不代表它一出现就自动成为备份；只有前序尝试满足规定的失败条件后，客户端才转向它。若同时提供域名和数字地址，IPv6 地址列表还处在更后的位置。DHCP 列表携带目的地候选与顺序，解析、传输和是否允许使用，则仍由客户端判断。

这是有用的控制面分工：网络可分发本地服务选择，而不必把同一个代理硬编码进每台客户端。不过，回复并未证明被列出的主机正在响应、支持共同的传输方式、接受当前用户请求，或能承载后续会话。“配置为优先”与“成功使用”是不同事实。

配置入口也可能成为改道入口

安全章节点明了风险：如果攻击者修改或插入 DHCP 回复，用户代理可能被引向恶意 SIP 服务器。对方可能拦截呼叫请求或拒绝服务。被篡改的回复也可能删掉本来会指向支持 TLS 的服务器的主机名，从而使拦截更容易。

这是 RFC 描述的威胁模型，不是某起攻击的记录。它没有声称任意收到的地址都经过认证，也没有说每个名字必然解析到 TLS 服务。DHCP 答复处在信任链中，因为它会影响应用把信令发往哪里；更广泛系统中的身份校验、策略和保护措施仍须各自成立。发现服务器不等于验证服务器身份。

旧选项仍出现在较新的 DHCPv6 记录中

DHCPv6 通用规范已经更新：RFC 9915 取代 RFC 8415。与此同时，IANA 的 DHCPv6 选项代码注册表仍把代码 21、22 关联到 RFC 3319；较后的 RFC 9243 也为这两类 SIP 服务器选项提供 YANG 配置分组。这些记录说明它们仍有登记和数据模型引用，但不能衡量运营商实际使用、客户端支持程度、后备是否成功，或通话完成率。

RFC 3319 的贡献比“DHCP 找到电话服务器”更窄，却也更值得准确描述：它规范了一种有序发现本地出站代理的方法，先考虑域名，满足条件后才退到地址列表。通话仍在选项之外；发现机制可以把信令指向某处，却无法认证后续发生了什么。

来源