Summary

  • draft-ietf-intarea-dhcp-rate-signaling-00 would let DHCP carry upstream and downstream rate values to clients, relays and snooping switches, but one number can have different authority, target and effective meaning at each point.
  • Operators need a receipt chain that keeps the original signal, relay mutations, lease source, semantic type, physical cap and applied queue state separate; a valid DHCP value is not measured throughput, contractual entitlement or proof of better latency.

The proposed DHCP Rate Option appears modest. It carries an upstream rate, a downstream rate and a rate type. A customer-premises device that does not know the subscriber's provisioned tier could use those values to place a shaper and active queue management near the access bottleneck. Relay agents and Layer 2 snooping switches could use the same signal to configure their own queues. In a network where the physical Ethernet link is much faster than the purchased service, that knowledge can be operationally valuable.

The important word is can. Revision 00 is an active Informational INTAREA Working Group Internet-Draft dated 27 August 2026. It expires on 28 February 2027. Its option codes and registries remain requested assignments. It is not an RFC, an implementation requirement already binding the Internet, a deployment census or a result from a named operator.

More importantly, the draft does not create one universal rate fact. It creates a chain of rate-bearing decisions.

Three numbers where the dashboard wants one

Consider a customer router with a one-gigabit WAN port. During its DHCP exchange it proposes that physical limit as a client hint. The server, drawing from a subscriber profile, places 2 Gbit/s in its reply. The router accepts the server's rate type because the server is authoritative for the value the client must apply, then caps the effective shaping value at its one-gigabit physical maximum as the draft recommends.

There are now at least three truthful records.

The client hinted at 1 Gbit/s. The server signaled 2 Gbit/s. The device applied 1 Gbit/s. None can replace the other.

The hint describes a claimed local constraint. The signal describes a selected policy value from an authority in the DHCP transaction. The applied value describes running configuration after local bounds. A fourth record—a speed test or traffic counter—might describe observed performance. A fifth—the subscriber agreement—might describe commercial entitlement. Their units may all be bits per second, but common units do not give them common authority.

This distinction becomes sharper because the option also carries rate type. A Layer 2 rate and a Layer 3 rate can differ even when both are correct. Applying a number without understanding which layer it counts can misconfigure the queue. Revision 00 therefore says that an understood sub-option carrying an unknown or reserved value essential to interpretation, such as rate type, invalidates the entire Rate Option. It does not invite a device to salvage the attractive numbers and guess their meaning.

An offer may choose an authority without authorising a change

DHCP already has message states. The draft preserves their importance.

A client may see the rate option in a DHCPv4 DHCPOFFER or a DHCPv6 ADVERTISE and use it when choosing between servers. It must not apply that value to the interface. Application waits for DHCPACK or REPLY. The early value can influence which server the client selects, but it is not yet authority to change the running queue.

That separation matters for audit. “The device saw 500 Mbit/s” is incomplete. Was it an offer used in selection, or an acknowledgment used for configuration? Did the selected server repeat the value? Did a relay alter it afterward? A trace that stores only the last number destroys the state transition that made the number actionable.

The client may also propose rates or a preferred Layer 2 or Layer 3 interpretation. The server may accept, reject or transform the hint. Server processing is outside the draft's fixed semantics. The server remains authoritative for the value and type eventually returned for client application. Therefore a client-originated number in a request is evidence of a proposal, not evidence of a purchased tier or of what the network subsequently enforced.

The relay is allowed to stop being transparent

DHCPv4 relay agents may read the option from a DHCPACK and instantiate local shapers or policers. A relay may also add, modify or remove the option before forwarding the message, for example after obtaining subscriber attributes from RADIUS or another AAA source.

This is useful in architectures where the broadband network gateway is the policy-enforcement point. It also means a client receipt cannot, by itself, prove the value originally selected by the central server. “Server output” and “client input” are separate evidence objects when an authorised intermediary may mutate the field.

DHCPv6 makes target scope even more explicit. A server can put an option in the client-facing REPLY and different options in nested RELAY-REPL layers. A relay can receive a rate slightly above the CPE shaper, allowing burst tolerance without moving the actual bottleneck back to the network edge. Those two rates are not a conflict merely because they differ. They are instructions for different actors.

A DHCPv6 relay must consume the option addressed to its own relay header. It must not mine the encapsulated client-facing payload for a convenient local value. That is a valuable control boundary: possession of the enclosing packet is not authority over every instruction inside it.

A watcher can become an actuator

The draft also allows a DHCP snooping switch to inspect the rate option and turn the observation into a local hardware queue, shaper or policer. The word snooping can obscure the transition. The switch is not merely producing telemetry. Once it changes forwarding treatment, it is an actuator.

That raises a practical question. Which receipt explains why the switch installed its queue? A DHCP packet proves that a field crossed an observation point. It does not automatically prove the field's source, whether a relay had changed it, whether the value targeted the client or the switch, or whether the subscriber profile remained current.

The correct record needs the observed bytes, message state, encapsulation level, ingress trust domain, subscriber/session binding, selected rate type, enforcement target and the configuration transaction produced from them. Without those links, a support engineer can see a queue and a packet but cannot prove the authority edge between them.

A value can keep its digits and lose its provenance

Dual-stack operation introduces another trap. Revision 00 says a client receiving conflicting DHCPv4 and DHCPv6 values should prefer DHCPv6 and must retain the applied rate with its source protocol.

Suppose both protocols eventually carry 500 Mbit/s. While the DHCPv6 lease is valid, the applied value is DHCPv6-derived. If that lease expires while the DHCPv4 lease remains valid, the same numeric value becomes DHCPv4-derived for later updates. Nothing visible on a one-number dashboard changes. The provenance does.

If no valid DHCPv4 lease remains, the device must return to its default configuration. In PPPoE environments, the DHCP rate takes precedence over a rate received in the PPP authentication reply; an explicit zero can remove the applied limiter, and termination of the PPPoE session also revokes it. Lifetime is part of authority. A value that was valid ten minutes ago is not a permanent grant.

Zero is especially easy to misread. In these rate sub-options, zero means unrestricted or remove the prior rate and return to default. It does not report an access line carrying no traffic. A monitoring system that treats it as measured capacity can turn a safe removal instruction into a false outage.

Parsing rules are part of the decision

Forward compatibility requires devices to ignore unknown sub-option codes and continue processing known ones. That does not mean every unknown value can be skipped. When a recognized field contains an unknown value that controls the meaning of the rest, the entire option must be discarded. The fallback is local default configuration.

Repeated fields also have order: the last instance is processed. A log pipeline that normalizes repeated codes into an unordered set can no longer reconstruct the applied result. The parsing receipt must preserve position.

These rules show why “packet accepted” is too weak a statement. An implementation can receive a well-formed DHCP reply, accept the lease, reject only the Rate Option and continue with default queue settings. Lease success and rate-policy success are different outcomes.

Plaintext control has a small field and a large consequence

The draft is direct about the security boundary: DHCP is commonly plaintext and unauthenticated. An on-path attacker or rogue server could inject an artificially low rate and throttle the subscriber. Sanity thresholds can reject implausibly small values, and a physical cap limits an implausibly high one. Neither check authenticates the source.

RFC 3118 documents DHCP authentication mechanisms. Its existence does not prove that the network carrying this option deploys them. An operator must record the actual trust controls: server allow-listing, relay-chain validation, snooping protections, port binding, authentication if used and the authority of the AAA record from which the number was derived.

The draft observes that rogue gateways, DNS manipulation and address exhaustion can be even more severe DHCP attacks. That comparison is not a licence to treat rate manipulation as harmless. A syntactically valid low-rate instruction can create a localized denial of service while leaving IP connectivity apparently healthy. The control plane succeeds; the customer's useful service fails.

A queue receipt is not a latency verdict

Accurate knowledge of a bottleneck rate can help place shaping and AQM. RFC 7567 explains why unmanaged queues are harmful; RFC 9330 describes L4S's use of shallow queues and responsive congestion controls. Revision 00 connects its rate signal to those mechanisms.

But installing a queue at the signaled rate does not prove lower latency. The policy value may be stale. A relay may target a different enforcement point. The physical interface may cap it. Traffic mix, scheduler, AQM implementation and downstream bottlenecks still shape the result.

The outcome chain therefore needs observation after action: actual effective configuration, queue occupancy, marks and drops, latency distribution, throughput, error state and rollback. “OPTION_RATE received” is a control receipt. “Customer performance improved” is a later claim requiring later evidence.

The narrow claim worth standardising

The Heng Lu doctrine in the disclosed packet argues for a thin common layer: specify only what interoperability requires, leave future choices close to the operator and judge authority against running state rather than institutional description. Applied here, the draft's durable contribution is an interoperable vocabulary and message-state rule for rate signals.

That vocabulary should remain narrow. It can say which direction a number covers, which layer it counts, which message can activate it, how conflicts and expiry behave, and when a device must fall back. It cannot make a subscriber profile true, a relay transparent, a queue effective or an outcome good merely by encoding the number in DHCP.

The leadership test is therefore not whether the network has deployed the option. It is whether every actor can answer: who selected this value; for which target; from which source; at which message state; after what mutation; for what lifetime; under which cap; and with what observed result?

Uncertainty

Revision 00 may change, be replaced or expire. No named operator, CPE, relay, switch, firmware or open-source project has been independently verified here as implementing it. Its performance and support benefits remain proposed rationale. Any production decision must validate the actual implementation, threat model and subscriber-policy provenance.

Sources