摘要

  • RFC 9928 允许 4o6RA 代替不知情的旧式 IPv4 客户端，把 DHCPv4 请求封装进 DHCPv6，并在返回时解封装。
  • 4o6 功能移到中间节点后，原有二层接入段可能从 DHCPv6 拓扑路径中消失。RFC 建议把 4o6RA 与 LDRA 背靠背组合，但没有规定两者内部如何交换接口信息。
  • 成功租约证明服务器作出分配并把结果送回客户端；它不单独证明入口端口、Interface-ID 的本地映射、服务器命中的规则，也不证明没有直接 DHCPv4 旁路。
  • 可复核回执应分别连接入口观察、封装、LDRA Interface-ID、嵌套中继顺序、地址池决定、返回配置、原端口交付、旁路检测以及到期或纠正。

地址已经可用，位置证据却可能断开

设想一台只会 IPv4 的旧式无线单元接入交换网络。它发出普通 DHCPDISCOVER，随后收到可用地址、网关和 DNS。监控系统把这次配置标成成功，设备也能建立基础连接。可是在同一网络里，端口位置可能决定它应该进入哪个地址池、得到哪组配置，甚至由哪个业务系统接管。

RFC 7341 定义了 DHCP 4o6：让 DHCPv4 消息借助 DHCPv6 穿过只提供 IPv6 的网络。原始模型要求客户端自己理解并执行这种封装。不能升级的旧设备做不到这一点。

RFC 9928 在 2026 年 3 月成为 IETF Standards Track RFC，它把这项工作交给 DHCPv4-over-DHCPv6 Relay Agent。4o6RA 收到 DHCPv4 请求后创建 DHCPV4-QUERY，向上游发送；收到格式正确的 DHCPV4-RESPONSE 后，再抽出 DHCPv4 响应交给原客户端。

旧设备仍以为自己完成了一次普通 DHCPv4 交换。规范明确说它不知道 4o6RA 的存在。这正是兼容性的价值，却也划定了证据边界：客户端无法证明封装发生过、预定中继被使用，或者中继提供的拓扑信息准确描述了自己的接入口。

拓扑不是装饰，而可能是分配输入

RFC 7969 讨论依据网络拓扑定制 DHCP 配置。中继知道原始请求从哪里进入，可以帮助服务器选择合适的地址池和参数。对接入网而言，地址并非总是从一个无差别池中随机取出。

DHCPv4 与 DHCPv6 保存路径的方式不同。IPv4 场景通常由第一个中继填写 giaddr，多级路径只能留下部分拓扑。DHCPv6 则能用多层 Relay-forward 保存中继顺序，每层还可带 link-address 与 Interface-ID。服务器因此可能看到从客户端到服务端的嵌套链。

问题出在转换位置。RFC 9928 指出，如果 DHCP 4o6 在 IPv6 网络边缘的中间节点执行，4o6RA 会把此前的二层网络藏在 DHCPv6 中继之后。只用 4o6RA 时，封装消息中没有接口信息，拓扑传播因而中断。

这不意味着报文一定无效。服务器仍可使用默认池，返回看似正常的配置；客户端也可能在有限范围内正常工作。绿色租约只说明“对收到的输入完成了决定”，不说明“收到的输入包含政策需要的物理位置”。

LDRA 带回的是不透明凭据

RFC 9928 推荐在 4o6RA 旁背靠背实现 Lightweight DHCPv6 Relay Agent。LDRA 获取客户侧接口信息，并把 Interface-ID 加进上行 DHCPV4-QUERY。这样，丢失的二层观察可以进入 DHCPv6 的嵌套路径。

RFC 6221 要求 LDRA 在所有 Relay-forward 中包含 Interface-ID。该值用于标识接收客户端消息的接口，并应在设备重启后仍对同一接口保持稳定，因为服务器可能按精确匹配执行参数分配。

稳定并不等于公开语义。Interface-ID 是不透明字节串，服务器不应拆解它来猜机框、槽位、端口或用户。要把它作为审计证据，运营方必须另外保存“当时哪个本地端口产生了这个值”的映射版本。

RFC 9915 又要求服务器在 Relay-reply 中复制 Interface-ID；中继依靠返回值选择面向客户端的接口。于是同一个不透明值贯穿两个动作：服务器可能用它选择参数，中继再用它选择交付端口。任何一边的成功都不能自动证明另一边的本地映射正确。

规范有意把内部接缝留给实现

4o6RA 与 LDRA 如何在内部交换接口信息，交换格式是什么，以及数据里是否表明 4o6RA 参与过，RFC 9928 全部留在范围外。规范只统一网络上的行为，不假装不同厂商、芯片或软件栈拥有相同内部结构。

因此，合规并不会自动产生 provenance。某个设备可能在一个进程里完成两项功能；另一个设备可能由交换芯片观察端口，再由控制面服务生成 Interface-ID。两者都能互操作，但复核证据完全不同。

正确的补充不是创造私有 wire 字段，而是明确本地 custody：谁观察了请求，哪个版本的映射把端口变成不透明值，4o6RA 把什么交给 LDRA，数据缺失或过期时系统如何失败。

规范同时保留一个简单例外：若 4o6RA 与 DHCP 4o6 服务器在同一节点，单独使用 4o6RA 也可能足够。判断标准不是图上是否出现两只方框，而是服务器的分配规则是否得到了所需拓扑，并且这条来源链能否复核。

旁路会制造第二套“正确”状态

因为客户端对 4o6 不知情，部署必须确保其 DHCPv4 广播和单播都经过 4o6RA。如果同一二层范围内还有可直接到达的 DHCPv4 服务器，请求可能完全绕开 4o6RA。RFC 9928 将其描述为部署错误：它可在客户端和服务器形成错误状态，甚至影响可达性，但不属于规范新增的安全问题。

对运行控制而言，“不是新安全问题”不等于“不需要证据”。预定的 4o6 路径和直接 DHCPv4 路径都可能返回形式正常的租约。客户端只看见获胜的一份配置，无法解释哪个控制面作出了决定。

因此回执必须包含否定性观察：广播是否被截获，更新时的单播是否仍经过 4o6RA，直接服务器路径是否不存在或已被证实阻断。客户端上的地址记录无法替代这些网络侧事实。

十段 custody 回执

这份回执是编辑性运营建议，不是 RFC 9928 的新消息，也不是 IETF 合规证书。

第一段保存被观察到的 DHCPv4 请求、事务证据、时间与接入设备。第二段记录物理客户侧接口及其映射 generation。第三段记录 4o6RA、所选上游接口和封装事件。第四段单独记录 4o6RA 向 LDRA 的内部交接、实现版本以及是否本地标注了 4o6 参与。

第五段保存 LDRA 生成的不透明 Interface-ID、稳定性 generation 与它所在的 Relay-forward 层。第六段保存服务器政策实际使用的其他 link-address、Interface-ID 与中继顺序。第七段记录服务器身份、命中的拓扑规则、地址池和返回参数。

第八段把 Relay-reply 嵌套顺序、解封装和向原客户侧端口的交付连起来。第九段记录直接 DHCPv4 旁路测试及结果。第十段用续租、端口移动、纠正、到期或回滚关闭整条记录，并定义证据何时可以到期。

回执的价值不是生成一个更大的“正常”结论，而是阻止语义越级。服务器日志不能单独证明物理入口；交换机日志不能单独证明地址池决定；返回的 Interface-ID 不能解释一张已经轮换掉的映射表；客户端租约也不能证明嵌套顺序。

责任同样要分开。IETF 负责互操作规范；接入运营方控制端口映射；中继运营方控制封装与流量引导；DHCP 服务拥有分配规则。旧式客户端接收结果，却不是一项不可见机制的知情授权者。

来源