摘要

  • draft-ietf-intarea-dhcp-rate-signaling-00 提议通过 DHCPv4 和 DHCPv6 下发用户接入的上下行配置速率；服务器决定最终值，中继、BNG 和窥探 DHCP 的二层节点还可能分别修改或执行它。
  • 运营侧需要一份“速率权威记录”，把签约档位、服务器通告、中继改写、L2/L3 口径、本地整形、物理上限与另行取得的测速数据逐项分开。

数字先到了，证据还没到

家庭路由器刚拿到 DHCP 回复，管理页面便出现“1 Gbps”。这个数字来自运营商网络，看起来比用户手填的参数可靠；设备如果又据此设置了 shaper，它就更像线路能力的正式结论。然而在此之前，设备不必发送一组探测流量，也不必观察拥塞，更没有验证互联网另一端能否持续交付同样吞吐量。

《DHCP Explicit Rate Signaling》要解决的是另一个问题。许多宽带接入中，CPE 与外置调制解调器或 ONT 之间的以太网口，速度高于用户实际购买的档位。CPE 只看见物理端口，就可能在错误的位置积压数据包。把已配置的上下行速率随 DHCP 送到 CPE、relay 或进行 DHCP snooping 的交换机，可以让它们在更接近瓶颈的地方设置队列、整形、限速或 Active Queue Management；对 L4S 这类依赖浅队列和及时拥塞信号的机制，也可能更有用。

这是一项有明确用途的控制面设计，却不是测量协议。草案允许 DHCP 服务器从本地配置、RADIUS/AAA 或外部策略系统取得数值。换句话说，数字的上游可能是商业产品档位、用户策略或设备配置。DHCP 负责把这个决定运过去，并不负责证明决定与实时物理能力一致。

文档状态也不能被“工作组草案”四个字抬高。个人草案 draft-giese-dhcp-rate-signaling-01 在 2026 年 7 月 31 日进入 INTAREA 采纳征求意见，工作组主席在 8 月 27 日记录了采纳共识，并要求作者以相同内容提交工作组 00 版。当前文本仍是会更新、替换或失效的 Internet-Draft；Datatracker 页面没有填写目标 RFC 状态，IANA 代码仍为 TBD。采纳说明工作组愿意审议，不等于已经形成 RFC、分配了正式代码或出现了广泛部署。

同样写着 bit/s，口径可以不同

草案的容器选项包含上行、下行和速率类型三个子选项。两个方向的数值都是 64 位无符号 bit/s。最容易被界面藏掉的，正是第三项。

类型 0 是“仅供参考”。接收方可以把它用于显示或遥测，却不得据此修改接口、shaper、policer 或 AQM。类型 2 是二层口径，计算包含以太网帧但不含 FCS 和包间隙；没有类型字段时，默认按它处理。类型 3 是三层口径，只计算 IP 头和载荷。草案指出，三层口径更常被用作可销售的产品带宽，也更接近测速应用的计数基础。

这意味着，二层整形值与三层测速值即使都正确，也不必相等。VLAN 标签和封装开销会改变两者关系。一个仅供参考的值即使准确反映套餐，也不能自动变成队列参数。如果接收方遇到不认识的基础速率类型，规则要求丢弃整个选项并回到默认值，而不是猜测。

零值也不是“没有网”。草案把 0 定义为不限速，可用于移除此前设置的限制、恢复设备默认配置。明确收到 0、完全没有收到选项、选项格式错误以及没有观察到回复，是四种不同状态。若监控系统都显示成“0 Mbps”，故障发生前，关键证据已经被抹平。

“服务器权威”只回答了一小部分问题

客户端可以在请求里表明支持该选项，也可以提出最大速率或偏好的 L2/L3 类型。但在最终 DHCPACK 或 DHCPv6 REPLY 中，服务器给出的值才是该次协议交换的权威值。这里的“权威”并不证明服务器上游的用户档案正确，也不证明它读取的是最新商业合同。

服务器还未必是最后一个编辑者。DHCPv4 relay，包括 BNG，可以在转发之前添加、修改或移除选项。二层节点可以通过 DHCP snooping 取出数值，为自己的用户侧端口建立 shaper 或 policer。DHCPv6 的嵌套 relay-reply 头还能把一个值发给客户端，把不同的值定向给中间 relay；每个 relay 应处理发给自己那一层的选项，而不是窥探客户端载荷。

所以，同一条接入路径上出现多个有效值并不反常。CPE 可能负责上行排队，接入 relay 管理另一段链路，BNG 又掌握下行限制。它们面对的方向、开销口径和瓶颈位置不同。问题不在于“为什么只有一个真值”，而在于每个值的作者、目标和生效位置是否还能被还原。

时间同样属于含义。DHCPv6 Reconfigure 或租约续期可以在会话中途更新速率。DHCPv4 客户端可以参考 DHCPOFFER 中的值选择报价，却只能执行 DHCPACK 里的选项。只保存最终数字、不保存消息类型、事务、租约起止时间，就无法判断一个队列为何仍在使用旧配置。

通告 2 Gbps，端口只能跑 1 Gbps

草案主动写进了这种矛盾：如果通告速率超过设备物理接口能力，客户端应把实际整形、限速或 AQM 参数限制在端口上限。用户界面应同时展示原始通告值和限幅后的有效值，并记录差异。

一条规则已经拆出了三个事实：网络通告了什么，设备实际应用了什么，物理端口最多支持什么。测速结果是第四个事实。它还取决于测试服务器、接入网之外的路径、当时拥塞、传输协议、Wi‑Fi 和终端负载。它们可以互相校验，却不能相互覆盖。

双栈冲突也需要留下判决过程。DHCPv4 与 DHCPv6 给出不同速率时，草案优先采用 DHCPv6，并要求保留当前设置来自哪种协议。同一子选项重复出现时，最后处理的值胜出。PPPoE 环境若同时从 PPP 认证和 DHCP 得到速率，草案让 DHCP 优先；收到 0 或 PPP 会话结束时，限制回到默认状态。

“当前配置速率”一栏解释不了这些结果。它不会告诉排障人员，是 IPv6 覆盖了 IPv4，是 relay 改写了服务器，还是物理端口降低了可执行值。一个决策的落选项和理由，同样是运行事实。

给速率建立一份权威记录

可审计的实现应为每次有效决策生成一份简明的“速率权威记录”。这是本文的治理建议，不是 IETF 草案要求。

记录首先要固定对象与时间：用户会话或租约、设备与接口、DHCP 版本、消息类型、事务证据、接收时间和到期时间。若运营商可以安全关联，还应分开写入签约档位、服务器使用的策略来源、服务器通告的上下行值以及信息型、L2 或 L3 口径。

每个可能改写的跳点单列一行：relay 或 BNG 收到了什么，添加、删除还是替换了什么，向谁转发了什么，以及本地据此建立了哪条队列。DHCPv6 要标明对应的 relay-reply 层。只观察没有执行的交换机，不应被记成策略执行者。

最后才是结果：shaper、policer 和 AQM 的有效参数，物理接口上限，限幅理由，冲突中胜出的协议，以及清除或到期条件。测速数据放在关联的观察序列中，带上方法、两端、时长与时间戳；绝不能倒写进“DHCP 通告值”。

界面用词本身是一道控制。“通告”表示从消息中收到；“已应用”表示设备采取了动作；“物理支持”表示硬件边界；“签约”表示商业关系；“实测”必须有观察过程。单独写“速度”，就是把五种权限揉成一个看似自然的结论。

看起来合理的值，也可能来路不明

DHCP 经常在没有消息认证的环境中运行。草案分析认为，伪造的低速率可能被注入并造成拒绝服务，因此提出由运营商设置合理性阈值。这里应严格表述为草案的威胁判断和缓解建议，不能写成已经观测到的攻击事件。

阈值只能挡住离谱数字。足够像真的恶意值仍可能通过，合法降档也可能被误拦。技术来源之外还要记录管理权限：哪个系统有权选择套餐，哪个 relay 有权覆盖，谁负责解释偏差并执行回滚。

当前 IANA BOOTP/DHCP 参数注册表尚未出现该选项，也没有草案请求创建的子选项与速率类型注册表。这只说明它仍处于 TBD 生命周期状态，既不表示拒绝，也不能预告将来一定分配。早期实验尤其要保留草案版本和临时代码，避免把私有用法包装成正式标准。

证据边界在哪里

RFC 7567 说明了为什么瓶颈附近的主动队列管理重要；RFC 9330 则给出 L4S 对浅队列和及时拥塞信号的架构依赖。准确的配置速率可以帮助设备把这些控制放对地方，甚至让后续测速体验更好。

但 DHCP 回复所证明的，仍然只是：某条权威链在某次事务或租约中下发了某项指令。要把它扩展成性能判断，还需连接策略来源、中继动作、实际生效状态、物理限制和独立测量。数字越精确，越不能放任它跨越事实边界。

来源