Supplying DHCP options is a smart way to configure network clients during the early phase of network access deployment. In addition to providing the IP address, the DHCP protocol is able to set a large bunch of options that are very useful for device configuration.
DHCP is an evolution of the BOOTP protocol (see RFC951) designed at first to bootstrap a diskless client. When starting such a device, BOOTP provides sufficient configuration parameters for obtaining network access, firmware and software locations for images to be downloaded from a network file repository.
X11 diskless display screen no longer exists, but many devices can take advantage of being configured at their network access time – for example IoT devices. BOOTP, which brings additional option configuration to the historical RARP protocol (see RFC903) which provides only IP address, has itself evolved in the DHCP protocol. With pool management and device mobility DHCP is also able to handle a wide list of options to configure a lot of various devices.
Each option has a name and a numerical identifier to be transported in the protocol frames. DHCP server configuration can handle providing options to all devices asking for an IP address and also bound to a specific client identifier or mac address family.
Any client entering the network can ask for specific DHCP options in addition to its IP address (eg vendor class, hostname or authentication credentials). The list of options requested is generally used to fingerprint the DHCP clients on the network. Finally, DHCP options can be inserted by a relay agent that is forwarding a broadcasted request from the local network to a central DHCP server.
Here is the list of the most common DHCP options exchanged with clients:
- DHCP option 1: subnet mask to be applied on the interface asking for an IP address
- DHCP option 3: default router or last resort gateway for this interface
- DHCP option 6: which DNS (Domain Name Server) to include in the IP configuration for name resolution
- DHCP option 51: lease time for this IP address
Below is the list of other interesting options that can be provided to clients to ease their initial configuration:
- DHCP option 2: time offset in seconds from UTC to be applied on the current time (note: deprecated by RFC4833 – options 100 and 101)
- DHCP option 4: list of time server as stated in the RFC868 (Time Protocol)
- DHCP option 12: host name of the client, very useful for IoT and any device without user
- DHCP option 15: specifies the domain name that client should use as suffix when resolving hostnames via the Domain Name System
- DHCP option 42: list of the NTP Servers by order of preference, used for time synchronization of the client
- DHCP option 58 and 59: Renewal Time Value (T1) and Rebinding Time Value (T2). See the chapter “DHCP Lease Time Management” on What is DHCP?
- DHCP options 69 and 70: respectively for SMTP and POP3 servers for sending and receiving email. We do see these options often on printers and scanners
- DHCP option 81: Client Fully Qualified Domain Name – this option allows to perform automatic update of the DNS records associated to the client, mainly the A and PTR. In the option we can specify whether the client or the server will update the records and the FQDN associated to the client. It is defined in the RFC4702
- DHCP option 100: time zone POSIX string as in IEEE 1003.1
- DHCP option 101: time zone as a string like in the TZ database (eg: Europe/Paris)
- DHCP option 119: DNS domain search list that will be used to perform DNS requests based on short name using the suffixes provided in this list.
- DHCP option 121: classless static route table composed of multiple network and subnet mask, this option replaces the original one numbered 33 (see RFC3442)
Some options are used by the client to provide the server with enough information to answer more specifically. For example, an IP phone may need some additional information about the registration server, or a graphical passive terminal may require the location of the font server.
Two main options are used in this case: the vendor class identifier (option 60) and the client identifier (option 61). Client identifier is unique and helps the DHCP server to manage its clients and leases, it is generally set to the MAC address of the network interface on a local network. The vendor class identifier is more interesting, as it identifies the vendor type and configuration of a DHCP client in a simple character string. The format is open and can be interpreted by the server in order to adjust the answer options and content.
By analyzing client identifier, class identifier and asked option list in the first phase of the DHCP request helps profiling the client and provide him with appropriate answer.
On a laptop running Windows 10, the options pushed in the initial DHCP Discover frame can look like:
- option 61: Client Identifier = 00:e0:4c:36:0a:ac
- option 12: The laptop name
- option 60: Vendor Class Identifier, here set to MSFT 5.0 (for Microsoft Windows 10)
- option 55: Parameter Request List set to:
- 1: Subnet Mask
- 3: Router
- 6: Domain Name Server
- 15: Domain Name
- 31: Perform Router Discovery
- 33: Static Route
- 43: Vendor Specific Information
- 44: NetBIOS over TCP/IP Name Server
- 46: NetBIOS over TCP/IP Node Type
- 47: NetBIOS over TCP/IP Scope
- 119: Domain Search
- 121: Classless Static Route
- 249: Private/Classless Static Route Microsoft
- 252: Private/Proxy autodiscovery
For information, this specific Parameter Request List is identified as “Operating System/Windows OS/Microsoft Windows Kernel 10.0” by the Fingerbank API.