Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) allows hosts on a TCP/IP network to configure one or more network interfaces based on information collected from a DHCP server. DHCP is often used, for example, by cable modem and DSL network providers to automate network configuration for their customers.
Information typically provided via DHCP includes address and subnet mask for the interface, default route, and domain name server.
To have OpenBSD configure an interface
using DHCP (or its predecessor, BOOTP) the
utility is used.
dhclient is run on the command line
with the name of the interface to be configured.
dhclient can also be run at boot time from
hostname.if(5), in which case
netstart(8) reads the hostname files and runs
dhclient for each interface that is to be configured
The options are as follows:
- Specify an alternate location to /etc/dhclient.conf for the configuration file.
- Do not daemonize. If this option is specified,
dhclientwill run in the foreground and log to stderr.
dhclientwill ignore any values provided by leases for the options specified. This list will override any ignore statements in dhclient.conf(5). options must be a comma separated list of valid option names. Invalid option names will cause the entire list to be discarded.
- Specify a file to write the option data to. This
dhclientto write two pseudo-leases, “offered” and “effective”, to the specified file. “offered” will be the lease offered by the DHCP server; “effective” will be the modified lease bound to the interface.
- Specify an alternate location to /var/db/dhclient.leases.⟨IFNAME⟩ for the leases file.
- Configtest mode. Only check the configuration file for validity.
- Release the current lease back to the server it came from.
dhclientexits after removing the active lease from /var/db/dhclient.leases.⟨IFNAME⟩, deleting the address the lease caused to be added to the interface, truncating any option file specified by
-Land sending a DHCPRELEASE packet to the server that supplied the lease.
If there is no
dhclientcontrolling the specified interface, or
dhclienthas no active lease configured, no action is performed.
dhclientto log more information.
-vis implied if either
The DHCP protocol allows a host to contact a central server which maintains a list of IP addresses which may be assigned on one or more subnets. A DHCP client may request an address from this pool, and then use it on a temporary basis for communication on the network. The DHCP protocol also provides a mechanism whereby a client can learn important details about the network to which it is attached, such as the location of a default router, the location of a name server, and so on.
/etc/dhclient.conf for configuration instructions.
It then attempts to configure the network interface
interface with DHCP. The special value
“egress” may be used instead of a network interface name. In
dhclient will look for the network
interface currently in the interface group “egress” and
configure it with DHCP. If there is more than one network interface in the
dhclient will exit with an error.
When configuring the interface,
attempts to remove any existing addresses, gateway routes that use the
interface, and non-permanent
dhclient automatically exits
whenever a new
dhclient is run on the same
Once the interface is configured,
resolv.conf(5) file. It does this only when one or both of
domain-name-servers are present (note that these
options may be offered by the DHCP server but suppressed by
dhclient.conf(5)). If a resolv.conf is constructed,
dhclient appends any contents of the
resolv.conf.tail(5) file, which are read once at start up.
The constructed resolv.conf is copied into
/etc/resolv.conf whenever the default route goes out
dhclient is running on.
dhclient monitors the system for changes to the
default route and re-checks whether it should write its resolv.conf when
possible changes are detected.
In order to keep track of leases across system reboots and server
dhclient keeps a list of leases it has
been assigned in the
file. IFNAME represents the network interface of the
DHCP client (e.g. em0), one for each interface. On startup, after reading
the leases file to refresh its memory about what leases it has been
Old leases are kept around in case the DHCP server is unavailable
dhclient is first invoked (generally during the
initial system boot process). In that event, old leases from the
file which have not yet expired are tested, and if they are determined to be
valid, they are used until either they expire or the DHCP server becomes
A mobile host which may sometimes need to access a network on
which no DHCP server exists may be preloaded with a lease for a fixed
address on that network. When all attempts to contact a DHCP server have
dhclient will try to validate the static
lease, and if it succeeds, it will use that lease until it is restarted.
A mobile host may also travel to some networks on which DHCP is not available but BOOTP is. In that case, it may be advantageous to arrange with the network administrator for an entry on the BOOTP database, so that the host can boot quickly on that network rather than cycling through the list of old leases.
- On receiving
dhclientwill restart itself, reading dhclient.conf(5) and obtaining a new lease.
- DHCP client configuration file
- interface-specific configuration files
- database of acquired leases
dhclient.conf(5), dhclient.leases(5), hostname.if(5), dhcpd(8), dhcrelay(8)
R. Droms, Interoperation Between DHCP and BOOTP, RFC 1534, October 1993.
R. Droms, Dynamic Host Configuration Protocol, RFC 2131, March 1997.
S. Alexander and R. Droms, DHCP Options and BOOTP Vendor Extensions, RFC 2132, March 1997.
T. Lemon and S. Cheshire, Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4), RFC 3396, November 2002.
T. Lemon, S. Cheshire, and B. Volz, The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4, RFC 3442, December 2002.
N. Swamy, G. Halwasia, and P. Jhingram, Client Identifier Option in DHCP Server Replies, RFC 6842, January 2013.
dhclient was written by
and Elliot Poger
The current implementation was reworked by Henning Brauer <firstname.lastname@example.org>.