Summary

  • draft-ietf-intarea-dhcp-rate-signaling-00 proposes 64-bit upstream and downstream service-rate values, plus a Rate Type that distinguishes informational, Layer 2 and Layer 3 meanings. The value is a policy statement carried by DHCP, not an observation of instantaneous capacity.
  • Authority changes with the message and the recipient. A client hint is optional; a DHCPACK or DHCPv6 REPLY supplies the server's answer; a relay may insert or override values; different DHCPv6 relay levels may receive different instructions.
  • Before calling the signal operational truth, retain its provenance and lifetime, read back the effective shaper or AQM state, identify the real queue, and measure packet and service outcomes. Otherwise a clean 1 Gbit/s field can coexist with the wrong byte accounting, a stale lease, an unapplied control, or a slower bottleneck elsewhere.

At 08:57, a household gateway renews its DHCPv6 lease. The REPLY contains a downstream value of 1,000,000,000 bits per second. The gateway displays “1 Gbit/s”, configures a local shaper and reports success. Five minutes later, interactive traffic still stalls behind a large upload, while a speed test peaks below the displayed tier.

None of those facts necessarily contradicts another. The advertised number may describe the subscriber profile rather than an observed path. It may be a Layer 2 value while the speed test reports Layer 3 payload. The shaper may sit on the wrong side of an encapsulation boundary. A BNG or access node may enforce a lower limit. The device may have accepted the value but failed to attach its AQM to the active interface. The physical WAN link may be faster than every one of those controls.

This is an analytical scenario, not a documented outage. It exposes the evidence boundary inside revision 00 of DHCP Explicit Rate Signaling: the protocol can distribute a useful rate claim without certifying the mechanism or outcome that the number is meant to improve.

Three quantities that should never share one field

Broadband operations often compress three different quantities into “speed”. The first is the commercial or policy rate assigned to a subscriber. The second is the effective rate actually applied by a shaper, policer or queue. The third is observed delivery for a particular flow, path, workload and time.

The proposed DHCP option primarily transports the first quantity so that devices can configure the second. Only observation can establish the third. A disciplined system therefore keeps three records:

Record Proper evidence What it does not prove
Signaled rate Raw option bytes, message type, server or relay context, transaction, lease, Rate Type That any device applied it
Effective control Configuration transaction, interface/queue identity, readback, algorithm, overhead model, timestamp That this is the path's narrowest point or that users received the intended result
Service outcome Queue telemetry, ECN/mark/drop counters, latency, loss and workload-specific delivery The contractual tier or the authority that selected it

The distinction is not semantic caution for its own sake. It determines rollback, attribution and liability. If an operator treats the signaled rate as both configuration and outcome, an incident can look healthy at the exact layer where the error was introduced.

The rate has a byte-layer constitution

The draft defines two directional sub-options, each a 64-bit unsigned integer in bits per second. It then defines Rate Type, which says what those bits count.

Type 2 is Layer 2. The draft recommends counting the Ethernet header and payload while excluding the frame check sequence and inter-packet gap. Type 3 is Layer 3: the IP header and its payload, independent of differing VLAN or tunnel overhead. If Rate Type is absent, the receiver must assume Layer 2. Type 0 is informational: the receiver must not apply the value to a physical interface, shaper, policer or AQM.

These are different contracts. A 1 Gbit/s L2 shaper and a 1 Gbit/s L3 shaper do not leave the same amount of application payload available when headers, tags and tunnels differ. A speed-test result is not a direct audit of an L2 policy number. A user interface that suppresses Rate Type silently changes the meaning of the displayed figure.

Reserved or unknown Rate Type values invalidate the entire option. Unknown sub-option codes, by contrast, are ignored while processing continues. Multiple copies of the same sub-option use the last instance. Those parsing rules are part of the evidence: a normalized database row must preserve which branch produced the effective value rather than merely retaining the last number it saw.

Zero is another overloaded-looking value whose defined meaning must be preserved. For either directional rate, zero means unrestricted/default behavior and can request removal of a previously applied rate. It does not say that the path measured zero capacity. Type zero means “information only”; a rate value zero means “remove/reset”. Conflating the two can leave an old shaper behind or erase a useful display value.

The server is authoritative only inside a bounded protocol act

A DHCPv4 client that supports the option can list it in the Parameter Request List. It may also place a proposed maximum or preferred Rate Type in DHCPREQUEST. The draft calls that a hint. How the server uses it is implementation-specific, and the client must accept the type returned in DHCPACK. A value in DHCPOFFER may help select a server, but the client must not apply it.

DHCPv6 makes the same separation. An Option Request Option declares interest. A Request can carry a hint. The applied answer comes in REPLY, not ADVERTISE. A server can later send RECONFIGURE so that a client initiates Renew or Information-request before T1.

That is protocol authority, not metaphysical truth. The server may source its answer from a local subscriber profile, RADIUS or another policy system. In DHCPv4, a relay such as a BNG may add, modify or remove the option before delivery. The value can therefore be authoritative for the client's required behavior while still being wrong, stale, malicious or inconsistent with the forwarding plane.

RFC 2131 and RFC 8415 provide the DHCPv4 and DHCPv6 state machines around that exchange. RFC 3046 supplies established relay-information context, and RFC 2865 describes RADIUS as one possible upstream policy source. None turns a received attribute into proof that the downstream action completed.

DHCPv6 can address several control surfaces at once

The proposal uses DHCPv6 relay encapsulation to target a client and individual relays separately. A server may place one rate inside the client-facing REPLY and a different rate at a relay level—for example, a slightly higher upstream policer at an intermediate node than the CPE's upstream shaper. A relay is supposed to consume its own targeted copy, not passively extract the client's copy.

This is powerful because it can coordinate the intended queue along the access path. It is also why “the DHCP rate” is an inadequate record. There may be several rates, recipients and enforcement roles in one exchange. The evidence key needs at least direction, encapsulation level, recipient, source principal, byte layer, lease and effective interval.

RFC 6221 provides the Lightweight DHCPv6 Relay Agent context referenced by the draft. It does not certify that a particular relay consumed the proposed option or successfully installed a queue. A relay-targeted value and a relay readback remain separate receipts.

Dual stack turns one number into a state machine

A dual-stack client can receive conflicting values. The draft says it should prefer DHCPv6 over DHCPv4 and must remember the source protocol with the applied rate. If the v6 lease expires while a valid v4 lease remains, the retained rate becomes v4-derived for future updates. If no v4 lease remains, the device resets to its default.

That rule cannot be represented faithfully by one timeless bandwidth column. The operational object includes protocol, lease identifiers, acquisition and expiry times, precedence decision, superseding transaction and reset reason. A dashboard that shows only the current number cannot distinguish a fresh v6 instruction from a retained value that has crossed into the v4 lifecycle.

PPPoE adds another boundary. The DHCP value takes priority over a rate embedded in the PPP authentication reply. Yet the PPP session remains the primary logical-link state: a valid zero removes the applied limit, and termination of the PPPoE session implicitly revokes it. RFC 2516 supplies the PPPoE session context. Persisting the DHCP-derived shaper after the session that gave it meaning has ended would turn precedence into stale authority.

A physical-link cap is a guardrail, not discovery

The draft anticipates a server advertising 2 Gbit/s to a CPE with a 1 Gbit/s WAN interface. The client should cap the effective shaping, policing or AQM value to the physical maximum and expose both the original and capped figures. That is good defensive behavior.

It proves one local inequality: the device will not configure this control above a physical interface limit it knows. It does not prove that 1 Gbit/s is available, that the physical speed was negotiated correctly, or that no slower queue exists elsewhere. It does not locate a PON bottleneck, an access uplink, a BNG policer, a congested peer or the server at the other end of a speed test.

The safest name for the readback is therefore effective_local_rate, not available_capacity. Preserve the signaled value beside it. Log the cap and its reason. Then keep measuring.

AQM needs the right queue, not merely the right integer

The draft's operational motivation is compelling. If a CPE's Ethernet port runs faster than the purchased tier enforced upstream, queues can build at a device with poor buffering or crude dropping. A local shaper slightly below the provider limit can move the controllable queue into the CPE, where an AQM can manage delay.

RFC 7567 explains why AQM should manage persistent queues rather than waiting for buffers to overflow. RFC 9330, RFC 9331 and RFC 9332 define the L4S architecture, its ECN protocol and one DualQ coupled AQM design. They introduce more necessary conditions: appropriate queue placement, ECN semantics, classification, coupling and responsive congestion controls.

The DHCP draft accurately calls its option an enabler and leaves detailed AQM and congestion-control design out of scope. That boundary should survive product marketing. A rate value does not select an algorithm, attach a qdisc, prove the active egress interface, classify L4S traffic, calibrate headroom, or show that latency fell without starving throughput.

A complete implementation receipt might contain: the received option; the interpreted layer and direction; the derived effective rate; the exact interface and queue identity; the configuration transaction; post-write readback; algorithm/version; ECN and classification state; packet, byte, mark and drop counters; and latency/throughput observations before and after. Anything shorter should be named for the stage it actually proves.

Authentication still stops at authorship

The proposal notes that DHCP is typically plaintext and unauthenticated. An on-path actor or rogue server could inject a very low rate and throttle a client. Implementations may reject implausibly small values, while the physical-link cap limits implausibly high application. Those bounds reduce some damage; they do not establish a trusted source.

Nor would message authentication alone prove the policy correct. It could show that a recognized principal originated an instruction. It could not show that the subscriber profile was current, that a relay preserved it, that the intended device consumed it, or that the queue produced the desired service result. Identity, authorization, execution and outcome remain four records.

This is the practical lesson of Running-Code Primacy: a label and an instruction cannot substitute for the behavior of the system that actually moves packets. Minimum Initial Specification supplies the design discipline: standardize the thin interoperable signal, then leave implementation evolution and local policy choices visible rather than converting them into central authority. Reality Layers supplies the audit question: which layer does this fact inhabit—symbol, configuration, physical queue or observed service?

Publication is not deployment

The Datatracker record identifies revision 00 as an active Internet Area Working Group draft with intended status Informational, published on 27 August 2026 and expiring on 28 February 2027. Its history records that it replaced the individual draft. The WG XML source, the predecessor record and individual revision 01 make that lineage inspectable.

The document is not an RFC. Its option codes remain TBD, and its text can change. This evidence establishes neither vendor support nor field deployment, interoperability, performance improvement or a subscriber incident.

The bounded conclusion is still important. DHCP can become a practical carrier for a subscriber-rate policy across devices that otherwise lack a shared management system. But the field should remain what it is: an instruction with provenance and a lifetime. The bottleneck becomes known only when the intended control exists at the relevant queue and observation confirms its effect.

Sources