When the Cloudflare One Appliance is configured as the DHCP server for a LAN, you can attach custom DHCP options to the leases it issues. This is commonly used for:
- PXE / iPXE boot of workstations or kiosks (options 66, 67, 60, 43, 175, 209–211).
- VoIP phone provisioning (option 66 — TFTP server).
- Vendor-specific client configuration (option 43 with vendor sub-options).
DHCP options can only be configured when the appliance is acting as the DHCP server. They have no effect when the appliance is in DHCP relay mode.
DHCP options are configured via the API and Terraform.
Each option is defined by three fields:
| Field | Description | Example |
|---|---|---|
option_number |
The DHCP option code (1–254). | 67 |
type |
The value encoding: text, integer, hex, ip. |
text |
value |
The option value, encoded per type. |
boot/x64/pxelinux.0 |
| Type | Format | Example value |
|---|---|---|
ip |
A dotted-quad IPv4 address. | 10.20.30.40 |
integer |
A decimal integer. | 0 |
text |
A UTF-8 string. | boot/x64/pxelinux.0 |
hex |
A colon-separated sequence of bytes, used for sub-options. | 01:04:aa:bb:cc |
The most frequently used options for PXE / iPXE boot are:
| Option | Type | Purpose |
|---|---|---|
| 60 | text |
Vendor class identifier (typically PXEClient). |
| 66 | ip or text |
TFTP server name or IP address (boot server). |
| 67 | text |
Bootfile name to load (for example ipxe.pxe or undionly.kpxe). |
| 43 | hex |
Vendor-specific information; sub-option layout is vendor-defined. |
| 175 | hex |
iPXE-specific encapsulated options (HTTP/HTTPS boot, iSCSI, DNS, and more). |
| 209 | text |
iPXE configuration file URI. |
| 210 | text |
iPXE configuration file path prefix. |
| 211 | text |
iPXE configuration file path. |
For a complete list of standard DHCP option codes, refer to the IANA BOOTP/DHCP parameters registry ↗.
Before applying a new DHCP options configuration, the appliance:
- Stages the change to a temporary configuration file.
- Validates the syntax with the underlying DHCP server.
- On success, atomically swaps the staged configuration into place and reloads the DHCP server with no service interruption.
- On failure, discards the change and returns the underlying validation error to the API caller. The live DHCP service is never restarted with an unverified configuration.
This means a malformed option will be rejected at apply-time rather than disrupting DHCP service for clients on the LAN.