DHCP Explicit Rate Signaling
draft-giese-dhcp-rate-signaling-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Christian Giese , Richard Patterson | ||
| Last updated | 2026-05-27 (Latest revision 2026-05-26) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-giese-dhcp-rate-signaling-00
Network Working Group C. Giese
Internet-Draft RtBrick
Intended status: Informational R. Patterson
Expires: 27 November 2026 Sky UK
26 May 2026
DHCP Explicit Rate Signaling
draft-giese-dhcp-rate-signaling-00
Abstract
This document defines new Dynamic Host Configuration Protocol (DHCP)
options for both DHCPv4 and DHCPv6 to explicitly signal available
upstream and downstream data rates. In many broadband access
networks, Customer Premises Equipment (CPE) and intermediate nodes
lack visibility into the subscriber's provisioned service tier. By
communicating these capacities natively via DHCP, clients, relay
agents, and snooping switches can dynamically configure localized
traffic shaping and queuing. This explicit signaling improves
overall network performance by reducing the reliance on
indiscriminate packet dropping and policing at the service edge.
Additionally, it provides the necessary capacity awareness to enable
effective Active Queue Management (AQM) and the Low Latency, Low
Loss, and Scalable Throughput (L4S) architecture.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-giese-dhcp-rate-signaling/.
Source for this draft and an issue tracker can be found at
https://github.com/GIC-de/draft-dhcp-rate-signaling.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Giese & Patterson Expires 27 November 2026 [Page 1]
Internet-Draft DHCP Explicit Rate Signaling May 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Architectural Context . . . . . . . . . . . . . . . . . . 3
1.3. Applicability and Benefits . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. DHCP Rate Option . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Sub-Options Format . . . . . . . . . . . . . . . . . . . 6
3.2. Sub-Options . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Available Rate Upstream . . . . . . . . . . . . . . . 6
3.2.2. Available Rate Downstream . . . . . . . . . . . . . . 7
3.2.3. Rate Type . . . . . . . . . . . . . . . . . . . . . . 7
4. DHCPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. DHCPv4 Rate Option . . . . . . . . . . . . . . . . . . . 8
4.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 9
4.3. DHCPv4 Server Behavior . . . . . . . . . . . . . . . . . 9
4.4. DHCPv4 Relay Agent Behavior . . . . . . . . . . . . . . . 10
5. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. DHCPv6 Rate Option . . . . . . . . . . . . . . . . . . . 10
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 10
5.3. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 11
5.4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 12
6. DHCP Snooping . . . . . . . . . . . . . . . . . . . . . . . . 12
7. PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Interaction with AQM and L4S . . . . . . . . . . . . . . . . 13
9. Errors and Conflicts . . . . . . . . . . . . . . . . . . . . 14
Giese & Patterson Expires 27 November 2026 [Page 2]
Internet-Draft DHCP Explicit Rate Signaling May 2026
10. Operational or Manageability Considerations . . . . . . . . . 14
11. Customer-Owned and Open Source CPE . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13.1. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . 16
13.2. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . 16
13.3. DHCP Rate Sub-Options Registry . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1.1. Problem Statement
In typical broadband access networks, the Customer Premises Equipment
(CPE) is often unaware of the actual available data rates. This lack
of visibility often occurs when an external modem or Optical Network
Terminal (ONT) [G.984.1] connects to the CPE at a physical link speed
that significantly exceeds the subscriber's provisioned service rate.
Furthermore, operators commonly deploy unified access profiles where
the available rate is artificially limited at the service edge, such
as the Broadband Network Gateway (BNG) [TR101], to match the
subscriber's purchased service tier.
When the network bottleneck resides between the BNG and the CPE,
intermediate devices are typically not well equipped to provide deep
buffering, priority scheduling, or Active Queue Management (AQM)
[RFC7567]. Relying on indiscriminate packet dropping or policing at
the service edge severely degrades the user experience. Conversely,
network performance improves significantly by performing intelligent
shaping and prioritization. When combined with AQM and the Low
Latency, Low Loss, and Scalable Throughput (L4S) architecture
[RFC9330], these localized traffic management benefits are further
amplified.
1.2. Architectural Context
In many IP over Ethernet (IPoE) [TR101] architectures, the Broadband
Network Gateway (BNG) operates strictly as a DHCP relay agent. While
per-subscriber traffic management policies, such as queues, shapers,
and policers, are typically provisioned out-of-band via
Authentication, Authorization, and Accounting (AAA) protocols like
RADIUS [RFC2865], deployments lacking direct AAA integration at the
service edge require an in-band signaling alternative.
Giese & Patterson Expires 27 November 2026 [Page 3]
Internet-Draft DHCP Explicit Rate Signaling May 2026
Transporting available data rates natively within DHCP options
addresses this architectural constraint. This mechanism allows the
BNG to dynamically instantiate downstream shapers and upstream
policers based on the DHCP payload, while concurrently equipping the
Customer Premises Equipment (CPE) with the parameters required to
manage upstream traffic locally.
Furthermore, intermediate Layer 2 access nodes performing DHCP
snooping can passively extract these explicitly signaled rate
parameters to optimize their local queues and shapers. By
distributing capacity awareness across the entire forwarding path,
this in-band signaling mitigates buffer congestion within the access
segment and significantly improves end-to-end transport performance.
1.3. Applicability and Benefits
While auto-configuration protocols such as TR-069 [TR069] can
provision rate information, they are not universally deployed by all
service providers. Furthermore, the increasing prevalence of
customer-owned, unmanaged CPE devices, including devices running
open-source firmware or custom projects, limits the effectiveness of
operator-managed configuration servers. A standardized DHCP option
addresses this gap by providing a universal mechanism to explicitly
signal available data rates directly from the DHCP server, across
BNGs and access nodes, down to the CPE. This localized approach is
particularly advantageous because it serves the entire path, whereas
auto-configuration servers exclusively target the end device. This
method also integrates seamlessly with architectures where RADIUS
servers inject DHCP options.
Although primarily designed for IPoE deployments, this mechanism is
equally applicable to Point-to-Point Protocol over Ethernet (PPPoE)
[RFC2516] environments. Since DHCP is frequently utilized over
PPPoE, most notably for IPv6 Prefix Delegation, this option provides
a standardized method for rate signaling. Consequently, this
approach can supersede the fragmented, proprietary methods currently
in use, such as embedding rate limits within PPP [RFC1661]
authentication reply messages.
Conveying rates via DHCP natively supports dynamic updates through
regular lease renewals or triggered reconfiguration requests. As an
auxiliary benefit, this explicit rate information can be exposed in
the CPE user interface to satisfy customer expectations regarding
bandwidth visibility. Ultimately, introducing a DHCP option to
signal available data rates represents a simple, standardized
enhancement that yields widespread improvements in internet service
delivery.
Giese & Patterson Expires 27 November 2026 [Page 4]
Internet-Draft DHCP Explicit Rate Signaling May 2026
Operational requirements necessitate the definition of this option
for both DHCPv4 and DHCPv6. This ensures coverage for networks
lacking IPv6 support and prevents configuration gaps in dual-stack
scenarios where DHCPv4 is established prior to DHCPv6.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document makes use of the terms defined in [RFC2131] and
[RFC8415]. The following additional terms are used:
DHCP The abbreviation DHCP is used throughout this document to refer
to both DHCPv4 and DHCPv6 protocols.
DHCPv4 Dynamic Host Configuration Protocol [RFC2131]
DHCPv6 Dynamic Host Configuration Protocol for IPv6 [RFC8415]
Subscriber
The individual, organization, or entity that maintains a
contractual relationship with a Broadband Service Provider for
network access services. Within the network infrastructure, a
subscriber is typically represented by an authenticated logical
session (e.g., IPoE or PPPoE) and an associated policy profile
that dictates service attributes, including provisioned
upstream and downstream data rates.
3. DHCP Rate Option
The DHCP Rate Option specified in this document employs a unified
sub-option structure for both DHCPv4 and DHCPv6, utilizing the format
explicitly known from DHCPv4 Option 82 (the Relay Agent Information
Option) [RFC3046]. The top-level option encapsulation strictly
conforms to the requirements of each base protocol. To simplify
cross-protocol implementation, this document proposes the uniform
assignment of OPTION_RATE with the option code TBD1 (value to be
assigned by IANA) for both IP versions. Specifically, DHCPv4
utilizes an 8-bit option code set to TBD1 alongside an 8-bit length
field, whereas DHCPv6 utilizes a 16-bit option code set to TBD1
alongside a 16-bit length field. Despite these differences in outer
header sizing, the internal payload remains completely identical.
The encapsulated sub-options maintain consistent 8-bit sub-option
code and 8-bit length fields across both protocol versions, ensuring
Giese & Patterson Expires 27 November 2026 [Page 5]
Internet-Draft DHCP Explicit Rate Signaling May 2026
common parsing and processing logic regardless of the underlying IP
version.
3.1. Sub-Options Format
The rate information field consists of a sequence of SubOpt/Length/
Value tuples for each sub-option, encoded in the following manner:
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
No "pad" sub-option is defined, and the rate information field SHALL
NOT be terminated with a 255 sub-option. The length of OPTION_RATE
MUST include all bytes of the sub-option code/length/value tuples.
The length N of the sub-options MUST be the number of octets in only
that sub-option's value field. A sub-option length MAY be zero. The
sub-options need not appear in sub-option code order.
The initial assignment of DHCP Rate Sub-options is as follows:
+=================+========+===========================+
| Sub-option Code | Length | Description |
+=================+========+===========================+
| 1 | 8 | Available Rate Upstream |
| | | in bits per second (bps) |
+-----------------+--------+---------------------------+
| 2 | 8 | Available Rate Downstream |
| | | in bits per second (bps) |
+-----------------+--------+---------------------------+
| 3 | 1 | Rate Type (L2 or L3) |
+-----------------+--------+---------------------------+
Table 1
3.2. Sub-Options
3.2.1. Available Rate Upstream
The sub-option Available Rate Upstream defines the rate in bits per
second (bps) available from the DHCP client towards the DHCP server
direction. The rate format is a 64-bit unsigned integer in network
byte order.
Giese & Patterson Expires 27 November 2026 [Page 6]
Internet-Draft DHCP Explicit Rate Signaling May 2026
SubOpt Len Available Rate Upstream
+------+------+------+------+------+------+------+------+--
| 1 | 8 | 64 Bit bps
+------+------+------+------+------+------+------+------+--
A value of 0 in this context signifies an unrestricted rate. It can
be interpreted as a request to remove a previously set rate, thereby
resetting to the device default configuration.
3.2.2. Available Rate Downstream
The available rate downstream defines the rate in bits per second
(bps) available from the DHCP server towards the DHCP client
direction. The rate format is a 64-bit unsigned integer in network
byte order.
SubOpt Len Available Rate Downstream
+------+------+------+------+------+------+------+------+--
| 2 | 8 | 64 Bit bps
+------+------+------+------+------+------+------+------+--
A value of 0 in this context signifies an unrestricted rate. It can
be interpreted as a request to remove a previously set rate, thereby
resetting to the device default configuration.
3.2.3. Rate Type
The rate type defines the networking layer to which the stated rates
apply. The default value of 2 is defined as the Layer 2 rate, which
signifies that the rate encompasses the entire Ethernet frame.
Implementations SHOULD calculate this rate using the Ethernet header
and all payload, excluding the Ethernet Frame Check Sequence (FCS)
and Inter-Packet Gap (IPG).
SubOpt Len Rate Type
+------+------+------+
| 3 | 1 | i |
+------+------+------+
If the rate type is set to 0, the explicitly signaled rates are
informational only. Devices receiving this rate type MUST NOT apply
the specified rate limits to their physical interfaces, traffic
shapers, policers, or Active Queue Management (AQM) parameters. This
value accommodates deployments where the network exposes the
provisioned service tier to the Customer Premises Equipment (CPE)
solely to populate user interfaces or for telemetry purposes, without
altering the device's localized forwarding behavior.
Giese & Patterson Expires 27 November 2026 [Page 7]
Internet-Draft DHCP Explicit Rate Signaling May 2026
If the rate type is set to 3, the rate applies to Layer 3,
encompassing only the IP header and its payload. This rate
calculation is frequently utilized by end-user speed test
applications and is often regarded as the marketable "product
bandwidth". Its primary advantage is its independence from the
variable overhead introduced by differing numbers of VLAN tags or
tunnel encapsulations.
In the absence of the Rate Type sub-option, the client MUST assume
that the signaled values are defined as the Layer 2 rate.
The values 1 and 4-255 are currently unassigned and reserved for
future use. If a client, server, or relay agent receives a Rate Type
sub-option containing an unrecognized or reserved value, it MUST
ignore the entire OPTION_RATE. Applying explicitly signaled rate
limits without understanding the intended networking layer could
result in incorrect localized traffic management. Therefore, to fail
safely, the receiving device MUST discard the option entirely and
rely on its default rate configuration.
A client MAY include the Rate Type sub-option within its initial
requests to serve as a hint to the server regarding its preferred
calculation method (e.g., requesting a Layer 3 rate instead of a
Layer 2 rate). Sending this hint is OPTIONAL for the client, and
honoring the hint is OPTIONAL for the server.
4. DHCPv4
4.1. DHCPv4 Rate Option
The DHCPv4 OPTION_RATE code is TBD1.
Code Len Rate Information Field
+------+------+------+------+------+------+--...-+------+
| TBD1 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
The length (N) gives the total number of octets in the Rate
Information Field, which is either zero or longer than 2 bytes, which
is the sub-options header length.
Giese & Patterson Expires 27 November 2026 [Page 8]
Internet-Draft DHCP Explicit Rate Signaling May 2026
4.2. DHCPv4 Client Behavior
DHCPv4 clients that support the DHCP Rate Option SHOULD include the
corresponding OPTION_RATE code in the Parameter Request List (PRL).
This inclusion explicitly signals client support, enabling the DHCP
server to determine whether to include the rate parameters in its
response. Furthermore, this signaling provides network operators
with visibility into client capabilities, which aids in
troubleshooting and resolving customer service quality complaints.
A client MAY include the DHCP Rate Option directly within its
DHCPREQUEST messages to serve as a hint to the server proposing their
maximum data rates or preferred rate type (L2 or L3 rates). For
example, when a CPE device is connected via a 1 Gbps WAN interface to
an external Optical Network Terminal (ONT) or modem capable of
exceeding 1 Gbps on the WAN side, the CPE can explicitly signal this
physical limitation to the service provider. This enables the
network to align its shaping parameters directly with the device's
actual capacity, ensuring traffic does not exceed the physical limit.
However, providing this hint is OPTIONAL. The manner in which a DHCP
server processes or utilizes these client-provided hints is
implementation-specific and outside the scope of this document.
Because the server remains authoritative, the client MUST accept and
apply the rate type ultimately provided by the server in the DHCPACK
message, regardless of the hint it originally sent.
Clients MUST ignore the OPTION_RATE when received within a message
other than DHCPACK. If the OPTION_RATE is present in a DHCPOFFER
message, the client MUST NOT apply the specified rate limits to its
interfaces. However, a client MAY evaluate the rate information
provided in a DHCPOFFER as a selection criterion to prefer one
server's offer over another.
4.3. DHCPv4 Server Behavior
When a DHCPv4 server is configured to support the DHCP Rate Option
and receives a client request (e.g., DHCPDISCOVER or DHCPREQUEST)
that includes the OPTION_RATE within the Parameter Request List
(PRL), the server MUST include the OPTION_RATE in the resulting
DHCPOFFER and DHCPACK messages.
The server MAY derive the specific upstream and downstream rates and
rate type from local configuration profiles, centralized
Authentication, Authorization, and Accounting (AAA) systems such as
RADIUS, or external policy servers. If no non-zero values are
configured or signaled to be used, the server MAY return rate values
of 0.
Giese & Patterson Expires 27 November 2026 [Page 9]
Internet-Draft DHCP Explicit Rate Signaling May 2026
A server MAY include the OPTION_RATE in its responses even if the
client did not explicitly request it via the Parameter Request List
(PRL), provided the operator has explicitly configured the server to
forcefully inject the option to provision intermediate nodes, such as
DHCP relay agents or Layer 2 snooping switches, which MAY drop these
options before forwarding the message to the client.
4.4. DHCPv4 Relay Agent Behavior
DHCPv4 Relay Agents, including L2 DHCPv4 Relay Agents [TR101], MAY
extract the OPTION_RATE from DHCPACK messages traversing the network.
Relay agents that perform localized traffic management MAY utilize
these extracted values to dynamically instantiate shapers and
policers on their subscriber-facing interfaces.
Furthermore, a relay agent MAY add, modify, or remove the OPTION_RATE
before forwarding the DHCP message to the client. This accommodates
deployments where the relay agent (e.g., a BNG) is responsible for
policy enforcement and populates or overrides the OPTION_RATE based
on subscriber attributes retrieved directly from an external
Authentication, Authorization, and Accounting (AAA) server, such as
RADIUS.
5. DHCPv6
5.1. DHCPv6 Rate Option
The DHCPv6 OPTION_RATE code is TBD1.
Code Len Rate Information Field
+------+------+------+------+------+------+------+--...-+------+
| TBD1 | N | i1 | i2 | i3 | | iN |
+------+------+------+------+------+------+------+--...-+------+
The length (N) gives the total number of octets in the Rate
Information Field, which is either zero or longer than 2 bytes, which
is the sub-options header length.
5.2. DHCPv6 Client Behavior
DHCPv6 clients that support the DHCP Rate Option SHOULD include the
corresponding OPTION_RATE code in the Option Request Option (ORO)
[RFC8415]. This inclusion explicitly signals client support,
enabling the DHCPv6 server to determine whether to include the rate
parameters in its response. Furthermore, this signaling provides
network operators with visibility into client capabilities, which
aids in troubleshooting and resolving customer service quality
complaints.
Giese & Patterson Expires 27 November 2026 [Page 10]
Internet-Draft DHCP Explicit Rate Signaling May 2026
A client MAY include the OPTION_RATE with any or all sub-options
within its DHCPv6 Request messages to serve as a hint to the server
proposing their maximum data rates or preferred rate type (L2 or L3
rates).
Providing this hint is OPTIONAL. The manner in which a DHCPv6 server
processes these client-provided hints is implementation-specific.
Because the server remains authoritative, the client MUST accept and
apply the rate type ultimately provided by the server in the REPLY
message, regardless of the hint it originally sent.
Clients MUST ignore the OPTION_RATE when received within a message
other than REPLY. If the OPTION_RATE is present in an ADVERTISE
message, the client MUST NOT apply the specified rate limits to its
interfaces. However, the client MAY evaluate this early rate
visibility as a selection criterion to prefer one server's
advertisement over another.
5.3. DHCPv6 Server Behavior
A DHCPv6 server MAY embed the OPTION_RATE directly within a REPLY
message encapsulated inside RELAY-REPL messages to explicitly
provision the end client. The server MAY include the option within
the RELAY-REPL message to target the corresponding relay agent,
instructing it to apply rate limits locally. The nested relay header
architecture of DHCPv6 empowers the server to explicitly address each
relay agent in the path, in addition to the end client, ensuring
precise targeting of signaling parameters.
If network policy dictates localized traffic management at both the
Customer Premises Equipment (CPE) and the relay node, the server MAY
include the OPTION_RATE at all encapsulation levels simultaneously.
When provisioning multiple levels, the server MAY supply different
rate values to each respective node. For example, an operator might
configure a relay agent's upstream policer with a slightly higher
rate limit than the CPE's upstream shaper. This operational delta
accommodates minor traffic burstiness from the CPE and prevents
premature packet drops at the intermediate access node. This
capability to independently target different nodes along the
forwarding path is unique to the nested relay header architecture of
DHCPv6, as DHCPv4 lacks a comparable mechanism for addressing
multiple relay agents distinctly.
Giese & Patterson Expires 27 November 2026 [Page 11]
Internet-Draft DHCP Explicit Rate Signaling May 2026
Furthermore, to dynamically update a client's rate limits mid-lease,
the server MAY utilize RECONFIGURE messages to apply updates before
the T1 timer expires. By triggering the client to initiate a Renew
or Information-request transaction, this mechanism allows the server
to push newly modified rate parameters without waiting for timer
expiration.
5.4. DHCPv6 Relay Agent Behavior
DHCPv6 Relay Agents, including Lightweight DHCPv6 Relay Agents (LDRA)
[RFC6221], MUST extract and consume the OPTION_RATE from their
corresponding Relay-Reply header. Because the DHCPv6 architecture
provides a dedicated signaling channel for intermediate nodes, relay
agents MUST NOT passively inspect the encapsulated client-facing
REPLY payload to extract rate information. Relay agents that perform
localized traffic management MAY utilize these explicitly targeted
values to dynamically instantiate shapers, policers, or Active Queue
Management (AQM) disciplines on their subscriber-facing interfaces.
In many architectures, the Broadband Network Gateway (BNG) or similar
intermediary device serves as the authoritative policy enforcement
point rather than a transparent relay. In such deployments, the
intermediary device MAY populate, modify, or remove the OPTION_RATE
destined for the client. This allows the network edge to inject
dynamic rate parameters based on subscriber attributes retrieved
directly from an external Authentication, Authorization, and
Accounting (AAA) server, such as RADIUS, before the message reaches
the downstream client.
6. DHCP Snooping
DHCP snooping switches are typically deployed as intermediate Layer 2
devices that passively monitor DHCP message exchanges to enforce
security policies and build binding databases, all without modifying
the DHCP payloads. These devices MAY passively inspect the DHCP Rate
Option within messages destined for clients. By extracting these
explicit rate parameters, snooping devices can dynamically provision
appropriate traffic shapers, policers, or hardware queues on the
corresponding downstream, client-facing ports.
7. PPPoE
In Point-to-Point Protocol over Ethernet (PPPoE) [RFC2516]
architectures, the Customer Premises Equipment (CPE) typically
employs DHCPv6 over the PPP [RFC1661] link to request an IPv6
Delegated Prefix (IA_PD) [RFC8415]. This encapsulated DHCPv6
exchange provides a standardized transport mechanism for the explicit
DHCP Rate Option. While less prevalent in modern deployments, DHCPv4
Giese & Patterson Expires 27 November 2026 [Page 12]
Internet-Draft DHCP Explicit Rate Signaling May 2026
transactions operating within a PPPoE session MAY similarly convey
these rate options.
The foundational processing rules and client behavior for rate
options received over PPPoE are identical to those defined for IP
over Ethernet (IPoE) environments.
If a client receives rate limits embedded within the PPP
authentication reply message and concurrently receives the DHCP
OPTION_RATE, the explicitly signaled DHCP OPTION_RATE MUST take
priority. This precedence ensures that the standardized, dynamic
DHCP signaling supersedes fragmented or proprietary rate limits
previously negotiated during the PPP authentication phase.
Because the PPP session dictates the primary logical link state, the
applied rate MUST revert to the device's default configuration under
two specific conditions. First, the client MUST reset the applied
limits if it receives a valid DHCP message explicitly signaling rate
removal with a sub-option containing a rate value of zero. Second,
the rate MUST be implicitly revoked if the underlying PPPoE session
itself is terminated.
8. Interaction with AQM and L4S
Active Queue Management (AQM) mechanisms, as recommended in
[RFC7567], are most effective when they operate at or near the true
bottleneck rate for a given service. In many broadband deployments
today, Customer Premises Equipment (CPE) and intermediate access
nodes configure shaping and AQM parameters against the physical port
speed rather than the subscriber's provisioned rate, which can lead
either to persistent queues and excess latency when configured too
high, or to underutilization when configured too low.
By explicitly signaling per-subscriber upstream and downstream rates
via the DHCP Rate Option, this document enables CPE devices, relay
agents, and snooping switches to instantiate shapers and AQM
instances that closely track the actual bottleneck capacity for each
subscriber. Placing the bottleneck queue under control of an AQM
that follows the recommendations in [RFC7567] allows operators to
limit queue growth and reduce queuing delay while still efficiently
utilizing the contracted bandwidth. The Low Latency, Low Loss, and
Scalable Throughput (L4S) architecture [RFC9330] relies on shallow
queues under an L4S-compatible AQM and on congestion controllers that
react promptly to Explicit Congestion Notification (ECN) signals.
Providing accurate rate information to devices at or near the
bottleneck link allows those devices to configure L4S-capable AQMs at
the appropriate shaping rate, so that L4S flows can achieve
consistently low queuing delay while still fully utilizing the
Giese & Patterson Expires 27 November 2026 [Page 13]
Internet-Draft DHCP Explicit Rate Signaling May 2026
subscriber's provisioned service tier. The DHCP Rate Option defined
in this document is therefore an enabler for deploying L4S and other
modern AQM schemes in access networks, even though the detailed
design of AQM and congestion control algorithms remains outside the
scope of this specification.
9. Errors and Conflicts
Clients receiving conflicting rate information across DHCPv4 and
DHCPv6 protocols SHOULD apply the most recently received value.
To ensure forward compatibility, clients, servers, and relay agents
MUST ignore unrecognized sub-option codes and continue processing the
remainder of the Rate Option.
Conversely, if a device receives a recognized sub-option containing
an unrecognized or reserved value that dictates the fundamental
interpretation of the rate parameters (such as an unassigned Rate
Type), it MUST discard the entire OPTION_RATE. Applying explicitly
signaled rates without understanding the intended networking layer
could result in incorrect localized traffic management. In such
cases, the device MUST rely on its default rate configuration.
If multiple instances of the same sub-option code are present, the
last instance MUST be processed.
A client may receive an OPTION_RATE indicating an Available Rate that
exceeds the maximum physical link speed of its upstream or downstream
interfaces (e.g., signaling 2 Gbps to a CPE with a 1 Gbps WAN port).
In such scenarios, the client SHOULD cap the applied traffic shaping,
policing, or Active Queue Management (AQM) parameters to the maximum
capacity of the physical link.
10. Operational or Manageability Considerations
Deploying explicit rate signaling via DHCP introduces several
operational benefits and deployment considerations for network
management. When combined with appropriately configured AQM and,
where deployed, L4S-compatible queue management, these per-subscriber
rate parameters help to concentrate congestion control at a well-
defined bottleneck and minimize queuing delay in the access segment.
Giese & Patterson Expires 27 November 2026 [Page 14]
Internet-Draft DHCP Explicit Rate Signaling May 2026
Implementations SHOULD expose the explicitly signaled, DHCP-learned
rate parameters within Customer Premises Equipment (CPE) management
interfaces, such as the local Web User Interface (UI) or remote
management protocols. Providing end-users and operators with
immediate visibility into the locally provisioned service tier
significantly reduces support inquiries related to perceived
bandwidth issues and improves overall user satisfaction.
As noted in Errors and Conflicts, a client may receive an OPTION_RATE
indicating an available rate that exceeds the maximum physical link
speed of its interfaces. In such scenarios, management interfaces
SHOULD expose both the originally signaled rate value and the
effective, capped rate value applied by the device. Additionally,
implementations SHOULD log this discrepancy if logging facilities are
enabled. Capturing and exposing these specific events provides
critical telemetry for network operators, as they frequently indicate
a mismatch between the subscriber's provisioned service tier and
their installed physical equipment.
11. Customer-Owned and Open Source CPE
A key motivation for this option is to support customer-owned or
subscriber-managed CPE, including retail routers and devices running
open-source firmware (for example, OpenWrt) that are not integrated
with operator auto-configuration systems such as TR-069. In these
environments, the access network can expose the provisioned upstream
and downstream rates via DHCP, and CPE implementations that
understand this option MAY use the learned values to configure local
shaping, policing, queue management, or simple rate indicators in
their user interfaces.
Because the option format is intentionally simple and identical for
DHCPv4 and DHCPv6, it is straightforward for open-source projects and
custom CPE implementations to add support without requiring coupling
to any specific vendor management system. Even if no advanced AQM
features are present, aligning any local rate limits with the
signaled values helps avoid misconfiguration and reduces the
likelihood of bufferbloat in the customer-owned equipment.
12. Security Considerations
DHCP messages are typically transmitted as plaintext and are
unauthenticated. Consequently, the DHCP Rate Options defined in this
document are vulnerable to interception, modification, or spoofing by
on-path attackers. A malicious actor or a successfully deployed
rogue DHCP server could inject artificially low rate limits to
severely throttle a client's connection, resulting in a localized
Denial of Service (DoS).
Giese & Patterson Expires 27 November 2026 [Page 15]
Internet-Draft DHCP Explicit Rate Signaling May 2026
The severity of this specific risk is generally no greater than
standard DHCP threat vectors, such as rogue default gateway
assignment, DNS hijacking, or IP pool exhaustion, which typically
yield a much more critical and immediate loss of service.
To mitigate the impact of malicious or malformed options, clients MAY
implement basic sanity checks and threshold validations before
applying rate parameters. For example, clients MAY ignore downstream
or upstream rates that fall below a basic operational minimum (e.g.,
1000 bps) to prevent complete session starvation. Furthermore, as
mandated in the client behavior specification, if a maliciously
injected rate is impractically high, the client implicitly mitigates
this by capping the applied rate to the physical link capacity.
13. IANA Considerations
This document requests that IANA assign the same numeric value in
both registries for DHCPv4 and DHCPv6, if feasible.
13.1. DHCPv4 Option
IANA is requested to assign a new DHCP Option Code (TBD1) in the
"BOOTP Vendor Extensions and DHCP Options" registry for OPTION_RATE.
13.2. DHCPv6 Option
IANA is requested to assign a new DHCPv6 Option Code (TBD1) in the
"Option Codes" registry for OPTION_RATE.
13.3. DHCP Rate Sub-Options Registry
IANA is requested to create a new registry titled "DHCP Rate Sub-
Options".
Giese & Patterson Expires 27 November 2026 [Page 16]
Internet-Draft DHCP Explicit Rate Signaling May 2026
+=======+===========================+===========+
| Value | Description | Reference |
+=======+===========================+===========+
| 0 | Unassigned | |
+-------+---------------------------+-----------+
| 1 | Available Rate Upstream | RFC TBD2 |
| | in bits per second (bps) | |
+-------+---------------------------+-----------+
| 2 | Available Rate Downstream | RFC TBD2 |
| | in bits per second (bps) | |
+-------+---------------------------+-----------+
| 3 | Rate Type (L2, L3 or | RFC TBD2 |
| | informational) | |
+-------+---------------------------+-----------+
| 4-255 | Unassigned | |
+-------+---------------------------+-----------+
Table 2
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, DOI 10.17487/RFC3046, January 2001,
<https://www.rfc-editor.org/rfc/rfc3046>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/rfc/rfc8415>.
14.2. Informative References
Giese & Patterson Expires 27 November 2026 [Page 17]
Internet-Draft DHCP Explicit Rate Signaling May 2026
[G.984.1] ITU-T, "Gigabit-capable passive optical networks (GPON):
General characteristics", ITU-T Recommendation G.984.1,
March 2008.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<https://www.rfc-editor.org/rfc/rfc1661>.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <https://www.rfc-editor.org/rfc/rfc2516>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/rfc/rfc6221>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/rfc/rfc7567>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/rfc/rfc9330>.
[TR069] Broadband Forum, "CPE WAN Management Protocol", TR 069
Issue 6, June 2020.
[TR101] Broadband Forum, "Migration to Ethernet-Based Broadband
Aggregation", TR 101 Issue 2, July 2011.
Acknowledgments
The authors would like to thank Glenn Deen and Jason Livingood for
their valuable review comments and discussion, which helped to
significantly improve the clarity, applicability, and operational
guidance of this document.
Giese & Patterson Expires 27 November 2026 [Page 18]
Internet-Draft DHCP Explicit Rate Signaling May 2026
Authors' Addresses
Christian Giese
RtBrick
Email: christian@rtbrick.com
Richard Patterson
Sky UK
Email: Richard.Patterson@sky.uk
Giese & Patterson Expires 27 November 2026 [Page 19]