摘要

  • draft-ietf-intarea-dhcp-rate-signaling-00 拟通过 DHCP 携带上下行速率和计数层级，让 CPE、中继与监听交换机配置整形或队列；但 DHCP 常以明文且未经认证的方式运行。
  • 运营者必须把“字段有效”“来源可信”“目标正确”“配置已提交”和“服务确有改善”拆成不同证据，不能让一个看似正常的数字同时代表全部事实。

设想一台家庭路由器收到服务器返回的 8 Mbit/s。选项编码正确，速率类型可识别，租约也顺利完成。设备按规则安装限速器，用户仍能拿到地址、解析域名、打开网页，却发现视频和远程会议几乎无法使用。攻击不需要让控制面报错；一条过低但语法合法的速率就足以制造局部拒绝服务。

这正是 DHCP Explicit Rate Signaling 草案暴露的治理问题。它的目标并不荒谬：当物理以太网口远快于订购接入速率时，客户设备并不知道真正瓶颈在哪里。服务器若能告知上下行速率，设备便可在瓶颈附近放置整形与主动队列管理。中继和进行 DHCP snooping 的二层交换机也可使用相同信号。

但“可用”从来不等于“天然可信”。第 00 版是 INTAREA 工作组在 2026 年 8 月 27 日发布的 Informational Internet-Draft，2027 年 2 月 28 日到期。它不是 RFC，也不是任何运营商已经部署的证明；所申请的选项代码与注册项仍处于标准化过程。

语法正确，只证明了解析器能读

选项可以包含上行、下行和速率类型。类型决定数字按二层还是三层计算；相同的比特每秒若计数边界不同，实际队列配置就可能不同。设备理解选项代码却不理解关键的类型值时，草案要求丢弃整个 Rate Option，回到本地默认配置，而不是留下数字再猜含义。

这条规则很重要。未知子选项代码可以忽略，以便未来扩展；已知关键字段中的未知值却不能被当作无关噪声。前者保护兼容性，后者保护语义完整性。

重复字段还有顺序：处理最后一个实例。日志平台若把包内字段归并为无序集合，就无法复现设备为何采取某个数值。“报文通过解析”也不是“速率策略被接受”；DHCP 租约可以成功，而速率选项单独失败。

看见 OFFER，不等于获得执行权

客户端可以在 DHCPv4 的 DHCPOFFER 或 DHCPv6 的 ADVERTISE 中看到速率，并据此选择服务器，但不能立即把数值应用到接口。真正的配置动作要等 DHCPACK 或 REPLY。

因此，“设备见过 100 Mbit/s”是一句证据不足的话。它是在候选报价里见到，还是在最终确认里收到？被选中的服务器是否重复了同一个值？中继随后有没有修改？租约是否还有效？同一串数字随着协议状态变化，会从选择信息变成配置授权，再随着租约失效而失去授权。

客户端也可以提出本地物理上限或偏好的二层、三层类型。服务器可以接受、拒绝或变换。客户端发出的建议只证明它声称了什么，不证明用户购买了什么，更不证明网络最后执行了什么。

中继不是永远透明的管道

在 DHCPv4 中，中继可以从 DHCPACK 读取速率，给自己的接口安装整形或 policer；也可在咨询 RADIUS 或其他 AAA 来源后，添加、修改或删除选项。

这意味着服务器发出的记录与客户端收到的记录必须分别保存。一条合法的中继变更仍然是变更。若只保留最后的数字，支持人员无法回答它是中央策略、接入节点修正，还是末端设备的本地上限。

变更收据至少要含中继身份、会话绑定、AAA 记录版本、变更前后值、速率类型、方向、目标、时间与有效期。RFC 3046 说明中继代理信息的既有语境，RFC 2865 提供 RADIUS 的框架；它们都不会自动证明某次具体改写有权发生。

DHCPv6 的套娃也在划分权力

服务器可在面向客户端的 REPLY 中放一个速率，同时在嵌套的 RELAY-REPL 层中给不同中继放置不同速率。CPE 可能收到 480 Mbit/s，接入中继收到 520 Mbit/s，以便让瓶颈保持在用户侧又留出短时突发空间。

这两个数不同，并不构成冲突，因为目标不同。中继必须使用写给自己那一层的选项，不应进入客户端载荷挑一个方便的数字。能看到整个封装，不等于拥有其中所有指令的执行权。

所以证据必须保留封装层级和目标，而不能只有“此用户的速率”。错误目标上的正确数字，仍然是错误授权。

监听一旦改队列，就成了执行者

DHCP snooping 交换机原本像观察者；一旦把观察到的字段转换成硬件队列、整形器或 policer，它就成为政策执行者。名称中的“监听”不能削弱这一事实。

原始报文只证明字段经过观察点。要证明队列有权存在，还需连接入口信任域、端口与用户会话、报文状态、封装层级、目标、接口能力、本地安全阈值、配置提交以及读回的硬件状态。

如果交换机从一条冒牌服务器报文安装了低速队列，控制动作甚至可能完全成功。运行状态越“正常”，越需要来源证据，而不是用成功回执替代授权判断。

阈值和物理上限都不是认证

草案建议设备对过低数值设合理阈值，并把过高数值限制到物理接口能力。前者可挡住某些显眼的恶意值，后者避免要求一千兆端口执行两千兆整形。但两者都回答不了谁发了指令。

RFC 3118 描述了 DHCP 认证机制。引用这份 RFC 不等于生产网络已部署它。实际审计要核实可信端口、服务器白名单、中继链校验、snooping 防护、会话绑定、认证启用状态以及 AAA 来源的权限。

草案指出，冒牌网关、DNS 篡改和地址耗尽等 DHCP 攻击可能更严重。这不是把速率注入判为无害；它只是说明该字段进入了一个本来就需要严密信任边界的控制面。

数字没变，来源仍可能换了

双栈设备遇到冲突时应优先使用 DHCPv6，并把来源协议与已应用速率一同保存。如果 v4 与 v6 都给出 500 Mbit/s，v6 租约失效后，屏幕数字可保持不变，权威来源却已变成 v4。

来源变化会带来不同服务器、中继路径和生命周期。若 v4 也无有效租约，设备要回到默认配置。PPPoE 环境中，DHCP 速率优先于 PPP 认证回复的速率，但会话终止也会撤销它。

零值尤其容易被误读。在这些子选项中，零表示不限速或删除旧限制并恢复默认，不是“线路实测速率为零”。把控制语义塞进性能图表，就会制造虚假的断网告警。

一条控制收据，不是延迟结论

瓶颈速率准确时，整形和 AQM 可能改善体验。RFC 7567 解释长期排队的危害，RFC 9330 描述 L4S 对浅队列与响应式拥塞控制的使用。但收到速率选项并不能证明延迟下降。

政策可能过期，目标可能错位，物理接口可能截断，其他瓶颈仍可能主导结果。动作之后还要观察有效配置、队列占用、标记、丢包、延迟分布、吞吐、错误与回滚。

Heng Lu 关于 running code primacy 的核心可在这里具体化：真正拥有现实权力的，是最终运行的状态，不是文档里的机构描述。薄的共同规范可以定义方向、类型、目标、消息状态、冲突和失效规则；它不能凭编码让用户档案变真，也不能让队列自动有效。

不确定性

草案仍可能修改、被替代或到期。本文没有确认任何指定运营商、固件、CPE、中继或交换机已经实现它。有关支持效率与性能的收益是提案动机，生产采用前仍需在真实威胁模型和设备行为中验证。

来源