Skip to content

DHCP server options

Last updated View as MarkdownAgent setup

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:

  • Network boot of workstations or kiosks with PXE, PXELINUX, or iPXE (options 43, 60, 66, 67, 175, 209, and 210).
  • 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.

Configure DHCP options

  1. Go to the Connectors page.
Go to Connectors ↗
  1. Go to the Appliances tab > Profiles.
  2. Select your Cloudflare One Appliance > Edit.
  3. Select Network Configuration.
  4. In LAN configuration, select Add LAN to create a new LAN, or select an existing LAN > Edit.
  5. Make sure This is a DHCP server is selected.
  6. In DHCP server options, select Add DHCP option.
  7. Choose one of the listed common options, or select Add custom option to enter your own option code, type, and value.
  8. Select Save.

You can also configure DHCP options via the API and Terraform using the dhcp_options field on the LAN's dhcp_server configuration. Create a PUT request to update the LAN where you want to configure DHCP options:

Required API token permissions

At least one of the following token permissions is required:
  • Magic WAN Write
  • Magic Transit Write
Update Site LANbash
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/magic/sites/$SITE_ID/lans/$LAN_ID" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"lan": {
				"static_addressing": {
						"dhcp_server": {
								"dhcp_options": [
										{
												"code": 67,
												"type": "text",
												"value": "boot/x64/pxelinux.0"
										}
								]
						}
				}
		}
	}'

Option format

Each option is defined by three fields:

Field Description Example
code The DHCP option code (1–254). 67
type The value encoding: text, hex, ip, byte, short, integer. text
value The option value, encoded per type. boot/x64/pxelinux.0

Value type encoding

Type Format Example value
text A UTF-8 string (max 255 bytes). boot/x64/pxelinux.0
hex A colon-separated sequence of hex bytes, used for sub-options (max 255 bytes). 01:04:aa:bb:cc
ip A dotted-quad IPv4 address. 10.20.30.40
byte An unsigned 8-bit integer (0–255). 1
short An unsigned 16-bit integer (0–65535). 512
integer An unsigned 32-bit integer (0–4294967295). 0

Restricted option codes

  • Options 0 and 255 are reserved by RFC 2132 ↗ and cannot be configured.
  • Options 3, 6, and 51 are managed by the Cloudflare One Appliance and cannot be configured, since they conflict with connector-managed configuration (default gateway, DNS servers, and lease time).
  • Each option code can only be used once per LAN. Duplicate option codes are rejected.

Common network boot options

The most frequently used network boot options are:

Option Type Purpose
43 hex Vendor-specific information. The vendor defines the sub-option layout.
60 text Vendor class identifier, typically PXEClient.
66 text TFTP server name.
67 text Boot file name, for example ipxe.pxe or undionly.kpxe. iPXE also accepts a URI, such as an HTTP URL for an iPXE script.
175 hex Client-specific encapsulated options used by Etherboot and iPXE. IANA lists this option as tentatively assigned and does not define its payload.
209 text PXELINUX configuration filename or path, loaded through TFTP.
210 text PXELINUX TFTP path prefix, prepended to option 209.

For a complete list of standard DHCP option codes, refer to the IANA BOOTP/DHCP parameters registry ↗.

Validation and apply behavior

Before applying a new DHCP options configuration, the appliance:

  1. Stages the change to a temporary configuration file.
  2. Validates the syntax with the underlying DHCP server.
  3. On success, atomically swaps the staged configuration into place and reloads the DHCP server with no service interruption.
  4. On failure, discards the change and returns the underlying validation error to the caller — shown as a field error in the dashboard, or in the API response for API and Terraform callers. 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.

Was this helpful?