Summary

  • draft-ietf-intarea-dhcp-rate-signaling-00 proposes DHCPv4 and DHCPv6 options for provisioned upstream and downstream rates, yet the value can come from policy systems and can be modified by relays before it reaches a device.
  • Operators and customer interfaces need a rate-authority record that separates the contracted tier, signalled value, accounting layer, applied control, physical ceiling and separately observed performance.

A number arrives before its meaning

Imagine a home router displaying “1 Gbps” moments after it receives a DHCP reply. The value looks precise. It arrived from the network rather than from a user-entered field, and the router may even use it to configure a shaper. The easy conclusion is that the access line has been tested and found capable of one gigabit per second.

Nothing in that sequence requires a test.

The Internet Area Working Group draft called DHCP Explicit Rate Signaling proposes a way to carry upstream and downstream rates in DHCPv4 and DHCPv6. Its operating problem is real: the physical Ethernet link between a customer router and an optical terminal or modem may run faster than the subscriber’s provisioned tier. A device that cannot see the lower bottleneck may put its queue in the wrong place. Supplying a rate can help a customer-premises device, relay or snooping switch shape traffic nearer to that bottleneck and configure Active Queue Management.

That usefulness makes the epistemic boundary more important, not less. The option transports a value selected by an authority. It does not discover the rate by sending traffic, observing congestion or measuring the path. It is a control-plane statement about how a subscriber session should be treated.

The draft is also still work in progress. Revision 00 became an INTAREA working-group document on 27 August 2026 after the chairs recorded consensus to adopt its individual predecessor. Datatracker records no intended RFC status on the document page, and the requested IANA codes remain placeholders. Working-group adoption gives the proposal a home and review process. It is not an assigned option code, deployment census or performance warranty.

Three rate types, not one speed

The proposed container has suboptions for upstream rate, downstream rate and rate type. Each direction is a 64-bit bits-per-second value. The type determines what the number is meant to count.

Type 0 is informational. A receiver must not use it to configure interfaces, shapers, policers or AQM. Type 2 describes a Layer-2 rate, including the Ethernet frame but excluding the frame check sequence and inter-packet gap. It is the default when the type is omitted. Type 3 describes a Layer-3 rate, counting the IP header and payload. The draft notes that Layer-3 accounting is often closer to a marketable product rate and the basis used by speed-test applications.

This is precisely why the label “speed” is too weak. A Layer-2 shaper and a Layer-3 test can report different numbers without either being faulty. Encapsulation overhead, VLAN tags and other link treatment sit between the two definitions. An informational value may be correct for display yet forbidden as a forwarding control. If a receiver does not understand a fundamental rate type, it is expected to discard the entire option and fall back to defaults.

Zero has another special meaning. It signifies an unrestricted rate and can remove a previously installed limit or restore device defaults. An observer therefore needs to distinguish an explicit zero from an absent option, a malformed option and a reply that was never seen. Flattening those states into a dashboard cell marked “0 Mbps” would turn a reset instruction into a false outage report.

The authority moves along the path

The server is authoritative for the value in its DHCPACK or DHCPv6 REPLY, but the word “authoritative” is local to the protocol exchange. It does not say how the server chose the number. The draft allows a DHCP server to derive rates from local configuration, RADIUS or another external policy system. The commercial service tier might sit in an ordering platform; the operational profile might sit in AAA; the reply is only the last visible projection.

Nor is the server necessarily the last editor. A DHCPv4 relay, including a Broadband Network Gateway, may add, modify or remove the option. A Layer-2 node that snoops DHCP may extract the value and create a queue or policer. In DHCPv6, nested relay-reply headers can target one value to the client and different values to intermediate relay nodes. Each relay is meant to use the option addressed to its layer rather than inspect the client-facing payload.

There can therefore be several valid values in one delivery path. The customer router may receive one rate, an access relay may act on another, and the BNG may have supplied or rewritten both. That is not automatically inconsistency; the nodes may control different directions or bottlenecks. It does mean that a screenshot from the router cannot stand in for the network’s full policy state.

Client hints do not reverse the authority. A capable client may request the option and may propose maximum rates or a preferred Layer-2 or Layer-3 type. The server decides what appears in the final reply. In DHCPv4, clients ignore the option outside DHCPACK, although a rate in DHCPOFFER may help a client choose between offers. In DHCPv6, renewal or Reconfigure can alter the value during a session. Time and message type are part of the evidence.

Announced, applied and possible

The draft anticipates the clearest mismatch. A network might announce 2 Gbps to equipment whose physical port supports only 1 Gbps. The client should cap shaping, policing or AQM parameters to the physical interface capacity. Its interface should expose both the originally signalled value and the effective capped value and log the discrepancy.

That recommendation creates three separate facts: what the network announced, what the device applied and what the physical link can carry. A fourth fact—what an application measures—depends on still more conditions: the path beyond the access segment, server capacity, congestion, transport behaviour, Wi-Fi, endpoint load and the measurement method. None can safely overwrite the others.

Protocol conflicts add more provenance. If both DHCPv4 and DHCPv6 supply rates, the proposal prefers DHCPv6 and expects the applied setting to retain its source protocol. If the same suboption appears more than once, the last processed value wins. PPPoE deployments introduce another source: when proprietary rate information arrives through PPP authentication as well as DHCP, the draft gives DHCP priority. A zero value or session termination restores defaults.

These rules are operationally useful only if the losing values remain inspectable. A final “configured rate” cannot explain whether DHCPv6 defeated DHCPv4, a relay rewrote the server value, a port cap reduced it, or a PPP session reset it. Troubleshooting requires the decision path, not just its output.

A rate-authority record

A responsible implementation should expose a compact rate-authority record. This is an editorial governance proposal, not a requirement of the Internet-Draft.

The record should begin with identity and time: subscriber session or lease, device and interface, DHCP version, message type, transaction evidence, receipt time and expiry. Then it should preserve the commercial tier when available, the server-announced upstream and downstream values, the type—informational, Layer 2 or Layer 3—and the system that supplied the server policy.

Every modifying hop should have its own entry. Record which relay or BNG added, changed or removed the option, which value it received, which value it forwarded and which local queue it configured. For DHCPv6, identify the relay-reply layer that addressed the instruction. For a snooping switch, distinguish observation from enforcement.

The outcome belongs in separate fields: effective shaper, policer and AQM rates; physical interface ceiling; reason for any cap; winning protocol when values conflict; and the reset or expiry condition. Measurements belong in a linked series with their own method, endpoints and timestamps. They must never be written back as though they were the signalled value.

The record also needs verbs. “Announced” describes a received DHCP value. “Applied” describes a device control. “Supported” describes a physical ceiling. “Contracted” belongs to the commercial agreement. “Measured” describes an observation. A customer interface that uses only “speed” discards the most important difference among them.

Security does not disappear behind a sane number

DHCP commonly operates without message authentication. The draft observes that a forged reply could inject an artificially low rate and create denial of service; it suggests configured sanity thresholds as one response. That is the proposal’s threat analysis, not evidence of a documented incident.

A threshold can reject an absurd value, but it cannot establish provenance. A plausible malicious value may pass. A legitimate policy downgrade may look suspicious. The rate-authority record therefore needs both technical origin and administrative ownership: which system was allowed to select the tier, which relay was allowed to override it, and who can investigate a mismatch.

The current IANA BOOTP/DHCP Parameters registry does not list the proposed option or its requested suboption and rate-type registries. That absence is ordinary for a draft using TBD code points. It should be shown as a lifecycle state, not interpreted as rejection and not hidden by early private assignments presented as permanent.

The evidence boundary

RFC 7567 explains why managing the queue near a bottleneck matters, and RFC 9330 describes the architecture in which L4S depends on shallow queues and responsive congestion signals. A well-chosen provisioned rate can help place those controls. It can even improve a later speed test.

It still does not become that test. The DHCP value proves only that a particular authoritative path supplied a particular instruction for a particular transaction or lease. To make a broader claim, an operator must join it with policy provenance, relay behaviour, applied state, physical limits and independent observations. Precision in bits per second is not precision about truth.

Sources