摘要

  • draft-ietf-intarea-dhcp-rate-signaling-00 提议用两个 64 位数表示上下行速率，再用 Rate Type 区分“仅供信息”、二层与三层口径。它携带的是一项服务策略，不是瞬时容量测量。
  • 权威随报文和接收者变化：客户端可以提示，服务器给出回答，中继可以插入或改写，DHCPv6 还可在不同中继封装层向不同设备下达不同数值。
  • 若要把信号升级成运营事实，必须保留来源与租约，读取最终生效值，确认队列确实挂在活动路径上，并观察标记、丢包、时延和吞吐。任何前一环都不能替后一环作证。

清晨，一台家庭路由器续租 DHCPv6。REPLY 里写着下行 1,000,000,000 bit/s。管理页显示“可用速率 1 Gbit/s”，自动任务也报告整形配置成功。可是一旦云备份跑满上行，视频通话仍然明显卡顿。

这几件事完全可能同时为真。服务器发来的数字也许是套餐档位，而非路径探测；它也许按二层字节计数，而测速工具展示三层负载；队列可能挂在错误的逻辑接口；运营商的 BNG 或接入节点也可能存在更低的 policer；本地 2.5G 物理口则比上述控制都快。

这只是分析场景，不是已知事故。工作组草案 00 版真正建立的是“让设备知道运营商希望采用哪个速率”的通道。它没有为执行与结果签发回执。

一个“速率”常被迫扮演三种事实

宽带运营里，至少有三本不应合并的账。第一本是商业或策略账：用户被分配了什么档位。第二本是执行账：某个 shaper、policer 或队列实际采用了什么参数。第三本是结果账：某条流在某个路径和时间里拿到了多少吞吐、时延、丢包与 ECN 标记。

记录 应保存的证据 单独不能证明
DHCP 信号 原始选项、方向、Rate Type、报文类型、事务、租约、服务器或中继上下文 任何设备已经应用
有效控制 设备、接口、队列、算法、开销模型、写入事务、回读值与时间 这里就是真实瓶颈，或用户结果达标
服务结果 队列计数、ECN、丢包、驻留时延以及定义清楚的负载测量 套餐授权与策略来源

草案把第一本账送到多个设备，帮助它们写第二本账；第三本账只能来自运行中的网络。若数据库只有一个 bandwidth 字段，故障发生后就无法判断是策略错了、执行错了，还是瓶颈根本不在这里。

数字的计数层就是它的宪法

上下行子选项都是 64 位无符号整数，单位 bit/s。Rate Type 决定这些比特究竟计算什么。

类型 2 是二层速率：草案建议包含以太网头与载荷，不包含 FCS 和帧间隙。类型 3 是三层速率：计算 IP 头和载荷，因此不受 VLAN 标签或隧道封装数量变化影响。没有 Rate Type 时，客户端必须按二层理解。类型 0 仅供信息；设备不得据此修改物理接口、整形器、policer 或 AQM。

于是“1 Gbit/s”并不是完整陈述。1 Gbit/s 的二层整形与 1 Gbit/s 的三层整形给应用数据留下的空间不同。测速结果低于二层信号，不必然说明违约；同样，面板显示套餐数字，也不代表底层按同一口径执行。面向用户和运营人员的界面必须显示计数层与实际采用值。

保留值或无法识别的 Rate Type 会令整个 OPTION_RATE 失效，因为设备不应在不知道计数含义时改动转发。未知子选项代码则被忽略，其余部分继续处理；同一子选项重复出现时采用最后一个。审计记录应保留这些解析分支，而不是只留下归一化后的数字。

零值也有两套语义。方向速率为零表示不受限或恢复设备默认，可用于撤销先前设置；它不是“测得容量为零”。Rate Type 为零则表示速率只用于展示或遥测。混淆两者，可能把信息误当命令，或者在撤销后仍留下旧限速。

“服务器权威”只存在于一个有边界的协议动作里

DHCPv4 客户端可在 Parameter Request List 中表明支持，也可在 DHCPREQUEST 中建议最高速率或希望采用的计数层。草案把它称为 hint：服务器是否采纳属于实现选择，客户端最终服从 DHCPACK。DHCPOFFER 中的速率可以帮助客户端挑选服务器，但不能立即改接口。

DHCPv6 的结构相同：ORO 表示请求，Request 可以建议，真正可应用的答案在 REPLY 中；ADVERTISE 不得触发应用。服务器还可发 RECONFIGURE，让客户端在 T1 前执行 Renew 或 Information-request。

服务器的数字可能来自本地用户档案、RADIUS/AAA 或外部策略系统。DHCPv4 中继（例如 BNG）还可以在向客户端转发前添加、修改或移除 OPTION_RATE。因此，“对客户端行为具有权威”与“描述物理路径真实状态”是两件事。权威服务器照样可能读取过期档案，中继也可能写入另一个值。

RFC 2131 与 RFC 8415给出 DHCPv4/v6 的状态机；RFC 3046说明中继信息的既有背景；RFC 2865描述 RADIUS。它们都能解释策略如何抵达，却不能替接收设备证明执行成功。

一次 DHCPv6 交换里可以有多个局部命令

DHCPv6 的嵌套中继头允许服务器分别向客户端与每级中继放入 OPTION_RATE。草案举例：CPE 上行 shaper 可以略低，而中继上行 policer 稍高，以容纳少量突发。中继应消费专门指向自己的那一层，不能被动挖取客户端内部 REPLY 的值。

这说明系统里不一定存在唯一“DHCP 速率”。正确的主键至少包含方向、封装层、接收者、策略来源、计数层、租约和有效区间。RFC 6221提供草案引用的轻量 DHCPv6 中继背景，却不能证明某台中继已理解新选项或把它写进硬件。

双栈让一个数字变成时间序列

同一客户端可能从 DHCPv4 和 DHCPv6 获得冲突值。草案建议优先采用 v6，并要求保存当前值来自哪个协议。若 v6 租约过期而 v4 租约仍有效，保留值随后按 v4 来源处理；若没有有效 v4，则恢复设备默认。

单个“当前速率”无法重演这项判断。需要租约标识、获取与过期时刻、优先级分支、后继事务和重置原因。速率不是用户身上的永恒属性，而是状态机在一个时刻的输出。

PPPoE 又加了一层寿命约束。若 PPP 认证回复中已有速率，而 DHCP 也带来 OPTION_RATE，后者优先。但 PPP 会话仍是主要逻辑链路：收到有效零值要撤销，PPPoE 会话终止也会隐式撤销。RFC 2516描述会话背景。会话消失后还保留限速，不再是“DHCP 优先”，而是失去上下文的旧命令。

物理口上限只是一道护栏

若服务器给 1G WAN 口发来 2 Gbit/s，草案建议把实际整形、policer 或 AQM 参数限制在物理接口上限，并在管理界面同时展示原始值与上限后的值，记录差异。

这项行为只证明本机没有把控制设到已知物理上限之上。它没有证明 1 Gbit/s 真能到达，更没有定位更慢的 PON 段、接入上联、BNG、对等链路或远端服务器。回读值应叫“本地有效速率”，不应叫“可用容量”。

AQM 需要真实队列，而不是一个漂亮整数

草案的动机值得重视。当 CPE 物理口远快于用户档位时，队列可能堆在上游设备，那里只有粗糙丢包或深缓冲。若 CPE 能在略低于上游限速处整形，就可能把可控瓶颈移到本地，让 AQM 管理排队时延。

RFC 7567解释为何应主动管理持续队列；RFC 9330、RFC 9331与 RFC 9332分别给出 L4S 架构、ECN 协议与一种耦合 DualQ AQM。要获得结果，仍需正确的队列位置、算法、分类、ECN 语义和能响应信号的拥塞控制。

草案准确地把 OPTION_RATE 称为“促成条件”，并明确把 AQM 与拥塞控制算法细节留在范围之外。一个整数不会自动选择 qdisc，不会把它挂到活动 egress，不会证明预留余量足以压住上游 policer，也不会证明时延下降而吞吐未被浪费。

完整的执行回执至少应连起：原始选项、解释后的方向与层、本地计算的有效值、目标接口和队列、配置事务、写后回读、算法及版本、ECN 与分类状态、包/字节/标记/丢包计数，以及前后时延和吞吐观测。

身份认证最多先证明“谁说的”

草案指出 DHCP 通常明文且未经认证。路径上的攻击者或伪造服务器可以注入极低速率，造成局部拒绝服务。客户端可用合理性阈值拒绝极小值，也可用物理口上限抵御过高值。这些是损害控制，不是来源证明。

即使将来加入认证，它也只能先证明某个已知主体发出了消息。它不能证明用户档案最新、中继没有改写、接收者确实写入、队列产生了预期效果。身份、授权、执行与结果仍是四张凭证。

运行代码优先要求把实际行为置于标签之上；最小初始规范主张先标准化窄而可互操作的核心，把未来实现与本地决策保留给可替换的参与者；现实层次则迫使审计者发问：眼前是符号、配置、物理队列，还是已观察到的服务？

草案发布不等于部署完成

Datatracker 页面将 00 版列为 Internet Area 工作组的活跃互联网草案，拟定状态为 Informational，发布日期为 2026 年 8 月 27 日，失效日为 2027 年 2 月 28 日。历史记录显示它取代了个人草案。工作组 XML、前身页面与个人 01 版让这条沿革可以核查。

它还不是 RFC，选项代码仍为 TBD，文本也会变化。现有材料不证明厂商支持、现场部署、互操作、性能改进或真实用户事故。

来源