DHCP Does More Than Assign IP Addresses
DHCP is commonly explained in one sentence:
DHCP gives your computer an IP address.
That is true, but it is incomplete.
When your computer joins a network, an IP address alone is not enough. The computer also needs to determine which destinations are local, where to send traffic destined for other networks, which DNS servers to use, and how long it may continue using the assigned address.
DHCP can provide all of that information.
A better introductory definition is:
DHCP supplies a client with the configuration it needs to participate in an IP network.
The IP address is merely the most visible part.
Before You Continue
You do not need a deep networking background for this article, but you should be able to answer these questions at a basic level:
- What is the difference between a local network and the internet?
- Why does a device need an IP address?
- What does a router do?
- What does DNS do?
- Why can some destinations be reached directly while others must
be reached through a router?
You do not need to know how subnet masks, routing tables, NAT, DNS recursion, or packet formats work internally. We will define the relevant pieces as they appear.
If these questions are unfamiliar, try asking ChatGPT:
Explain the minimum networking concepts I need before learning DHCP.
Use one home-network example and explain:
- local networks versus the internet
- IP addresses
- routers
- DNS
- why some destinations are local and others require a router
Do not explain DHCP yet.
A Computer Joins a Network
Imagine that you connect a laptop to Wi-Fi.
The wireless interface may now have a link to the access point, but the laptop still needs IP configuration before it can communicate normally.
On Linux, you can inspect your network interfaces with:
ip link
You might see something like:
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
link/ether 34:13:e8:7c:91:20 brd ff:ff:ff:ff:ff:ff
The interface is up, and it has a link-layer address. That does not yet tell us what IPv4 address it should use.
The laptop cannot safely invent an arbitrary address:
192.168.1.42
Another device might already be using it. The address might not belong to the network the laptop has joined. Even if the address happens to be valid and unused, the laptop still needs more information.
It needs answers to questions such as:
What is my IP address?
Which destination addresses are on my local network?
Which router should I use to reach other networks?
Which DNS server should I query?
How long may I keep this configuration?
DHCP is one common way for the laptop to obtain those answers automatically.
Inspecting Your Current Network Configuration
Before examining the DHCP protocol, look at the configuration currently installed on your machine.
Your IP address
Run:
ip -4 address
An abbreviated result might look like:
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
inet 192.168.1.42/24 brd 192.168.1.255 scope global dynamic wlan0
The important portion is:
192.168.1.42/24
192.168.1.42 is the interface's IPv4 address.
/24 is the network prefix length. It describes which part of the address identifies the local network.
You may also see:
dynamic
That tells you that the address was configured dynamically rather than permanently attached to the interface. On an ordinary home network, DHCP was probably involved, although this single word does not reveal the entire configuration process.
Your routes
Now run:
ip route
You might see:
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.42 metric 600
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.42
The local route says that addresses within 192.168.1.0/24 are reachable through wlan0.
The default route says:
default via 192.168.1.1
When the kernel has no more specific route for a destination, it sends the packet toward 192.168.1.1.
That address is the default gateway—usually the local router on a home network.
Notice that the route may contain:
proto dhcp
On this system, the route was installed from information obtained through DHCP.
DHCP did not merely supply 192.168.1.42. It also told the client where to send traffic for other networks.
Your DNS configuration
If your system uses systemd-resolved, run:
resolvectl status
You might see:
Link 2 (wlan0)
Current Scopes: DNS
DNS Servers: 192.168.1.1
DNS Domain: lan
Or request only the DNS servers associated with an interface:
resolvectl dns wlan0
Link 2 (wlan0): 192.168.1.1
The address 192.168.1.1 appears again, this time as a DNS server.
The router may be performing several different jobs, but these are separate pieces of configuration:
Default gateway: 192.168.1.1
DNS server: 192.168.1.1
They happen to contain the same address because the same device is providing both services.
resolvectl displays the current DNS configuration managed by systemd-resolved; it does not necessarily show the original DHCP message that supplied it. See the resolvectl documentation for its complete behavior.
DHCP Supplies a Configuration Bundle
A typical DHCP result might be summarized as:
IP address: 192.168.1.42
Subnet mask: 255.255.255.0
Prefix length: /24
Default gateway: 192.168.1.1
DNS server: 192.168.1.1
Lease duration: 24 hours
Domain name: lan
Each value answers a different question.
IP address
192.168.1.42
# The address assigned to this interface on this network.
This allows other devices to address IP packets to the interface and allows the interface to identify itself as the source of outgoing packets.
Subnet mask
255.255.255.0
# Helps the client determine which destination addresses are local.
A subnet mask of 255.255.255.0 is equivalent to a /24 prefix in this example.
The client combines the address and mask:
Address: 192.168.1.42
Mask: 255.255.255.0
Network: 192.168.1.0/24
That tells the client that addresses in the corresponding local prefix can be treated as directly reachable through the local interface.
A complete explanation of subnet arithmetic deserves its own article. For understanding DHCP, the important point is that the client needs this information to distinguish local destinations from destinations reached through a router.
Default gateway
192.168.1.1
# The router used when no more specific route matches a destination.
Suppose the client wants to reach:
192.168.1.80
That address belongs to its local /24 network, so the client can attempt to reach it directly.
Now suppose it wants to reach:
1.1.1.1
That address is not within 192.168.1.0/24, so the client uses its routing table and sends the packet toward the default gateway.
DHCP can provide the address from which the operating system constructs that default route.
DNS server
192.168.1.1
# The resolver the client should ask to translate names into addresses.
Applications commonly begin with a name:
example.com
Before connecting, the system normally needs to resolve that name to one or more IP addresses.
DHCP can tell the client which DNS resolver to query.
It might advertise the router:
DNS server: 192.168.1.1
Or it might advertise external resolvers directly:
DNS servers:
1.1.1.1
1.0.0.1
What the router does with DNS queries, and what changes when clients bypass the router's DNS forwarder, are separate subjects. The important point here is that the DNS server address can be part of the configuration distributed through DHCP.
Lease duration
86400 seconds
# The period for which the client may use the assigned address.
A DHCP address is generally not granted permanently. It is leased.
The client can use the address for a defined period and normally attempts to renew the lease before that period ends.
Other information
DHCP can distribute much more, including:
Local domain or search domain
NTP servers
Static routes
Host name information
Boot server information
Vendor-specific configuration
Support depends on the DHCP server, the client, and the network.
The complete list is much larger than anything worth reproducing in an introductory article. The authoritative IANA BOOTP and DHCP Parameters registry lists assigned DHCP option numbers and their defining documents.
Viewing the Bundle with NetworkManager
If your Linux system uses NetworkManager, nmcli can display much of the resulting configuration together:
nmcli device show
To limit the output to IPv4 information for one interface:
nmcli -f IP4 device show wlan0
You might see:
IP4.ADDRESS[1]: 192.168.1.42/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1
IP4.DNS[1]: 192.168.1.1
IP4.DOMAIN[1]: lan
This gives a much better picture than the phrase “DHCP gave me an IP address.”
The resulting configuration includes:
an address
a local network prefix
a default route
a DNS resolver
a domain
The exact fields and formatting vary among NetworkManager versions and distributions.
DHCP Options
How can DHCP carry all these different values?
It uses options.
DHCP has a base message format inherited from BOOTP, followed by a flexible options area. Each option has a numerical code identifying the kind of information it contains.
Some commonly encountered DHCPv4 options are:
Option 1 Subnet Mask
Option 3 Router
Option 6 Domain Name Server
Option 15 Domain Name
Option 42 Network Time Protocol Servers
Option 50 Requested IP Address
Option 51 IP Address Lease Time
Option 53 DHCP Message Type
Option 54 Server Identifier
Option 55 Parameter Request List
You do not need to memorize these numbers.
The important idea is:
DHCP is an extensible configuration protocol. An IP address is only one component of the information exchanged.
The original DHCP options are described in RFC 2132: DHCP Options and BOOTP Vendor Extensions. Newer options have been defined in additional RFCs and recorded by IANA.
How Can DHCP Work Before the Client Has an Address?
This raises an apparent problem.
The client needs DHCP because it does not have an IP address. But DHCP itself runs over IP and UDP.
How can the client send an IP packet before it has an ordinary IP address?
During initial configuration, the client can use:
Source IPv4 address: 0.0.0.0
Destination IPv4 address: 255.255.255.255
Source UDP port: 68
Destination UDP port: 67
0.0.0.0 represents the not-yet-configured client in this context.
255.255.255.255 is the limited broadcast address. The packet is delivered on the local network rather than routed across the internet.
DHCP commonly uses:
UDP 67 DHCP server
UDP 68 DHCP client
At the link layer, the client can also transmit an Ethernet broadcast. It does not need a normal IPv4 address to place a broadcast frame onto the local network.
You can watch DHCP traffic with tcpdump:
sudo tcpdump -ni any -vvv 'udp port 67 or udp port 68'
The -n option prevents name resolution, -i any listens on all interfaces, and -vvv requests more protocol detail.
To include Ethernet headers when capturing from a specific Ethernet-like interface:
sudo tcpdump -ni wlan0 -e -vvv 'udp port 67 or udp port 68'
Capturing Wi-Fi traffic can behave differently depending on the interface, driver, capture mode, and operating system, but you should ordinarily be able to observe your own DHCP exchange.
The Initial DHCP Exchange
The common initial address-allocation sequence is often remembered as DORA:
Client DHCP server
DHCPDISCOVER ---------------------->
<-------------------- DHCPOFFER
DHCPREQUEST ---------------------->
<-------------------- DHCPACK
These four messages perform different jobs.
1. DHCPDISCOVER
The client begins by searching for available DHCP servers.
Conceptually, it announces:
I need network configuration.
Are there any DHCP servers available?
A decoded packet may include information resembling:
DHCP Message Type: Discover
Parameter Request List:
Subnet Mask
Router
Domain Name Server
Domain Name
The parameter request list, option 55, tells servers which configuration options the client is interested in receiving.
It does not mean the server must supply every requested option. It tells the server what the client knows how to use and would like to receive.
2. DHCPOFFER
A server can respond with an offer:
I can offer you 192.168.1.42,
along with this network configuration.
A simplified decoded offer might contain:
Offered address: 192.168.1.42
Server Identifier: 192.168.1.1
Subnet Mask: 255.255.255.0
Router: 192.168.1.1
Domain Name Server: 192.168.1.1
IP Address Lease Time: 86400 seconds
The server is not merely proposing an address. It is proposing a configuration bundle.
There may also be more than one DHCP server capable of answering.
For example:
Server A offers 192.168.1.42
Server B offers 192.168.1.97
That is one reason the offer is not the final step.
3. DHCPREQUEST
The client selects an offer and requests it.
The message may identify:
Requested IP Address: 192.168.1.42
Server Identifier: 192.168.1.1
During initial allocation, this request is commonly broadcast. That allows the selected server to see the acceptance and allows other responding servers to see that their offers were not selected.
Conceptually:
I am selecting the offer from 192.168.1.1,
and I am requesting 192.168.1.42.
4. DHCPACK
The selected server acknowledges the request:
You may use 192.168.1.42 under these lease terms.
The acknowledgment can carry the final configuration options:
Address: 192.168.1.42
Subnet mask: 255.255.255.0
Router: 192.168.1.1
DNS server: 192.168.1.1
Lease time: 86400 seconds
After processing the acknowledgment, the client can install the address, routes, resolver configuration, and other accepted settings.
The full protocol behavior, including state transitions and cases beyond the initial DORA sequence, is defined in RFC 2131: Dynamic Host Configuration Protocol. DHCP is described there as a framework for passing configuration information to hosts, with reusable network-address allocation as one of its capabilities.
Watching the Exchange Yourself
Start a capture:
sudo tcpdump -ni any -vvv 'udp port 67 or udp port 68'
Then reconnect an interface from another terminal.
With NetworkManager, that might be:
nmcli device disconnect wlan0
nmcli device connect wlan0
Be careful when doing this over SSH: disconnecting the interface carrying your SSH session will disconnect you.
Also, do not assume that every reconnection will produce a fresh four-message DORA exchange. A client that remembers a previous lease may try to reclaim or renew it instead of beginning with a new discovery.
That is itself useful to observe. DHCP includes more behavior than DORA.
Depending on the implementation and state, the capture might show:
DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
or only something closer to:
DHCPREQUEST
DHCPACK
What a Lease Actually Means
A DHCP lease is temporary permission to use an address.
It is not permanent ownership of that address.
A server may retain state connecting information such as:
Assigned address
Client identifier
Hardware address
Lease start time
Lease expiration time
Supplied configuration
The precise identification and storage behavior varies among implementations.
A useful conceptual summary is:
You may use 192.168.1.42
on this network
with this configuration
for this amount of time.
The configuration options and address allocation are closely associated, although not every option is inherently a property of the leased address itself.
For example, the DNS resolver and default gateway may be shared by nearly every client on the network.
Renewal and Expiration
DHCP is not finished once the initial address has been assigned.
The client normally attempts to extend the lease before it expires.
A simplified timeline looks like:
Lease begins T1 T2 Expiration
|---------------------|-----------------|---------------|
renewal rebinding
Renewal
At the first renewal time, commonly called T1, the client normally attempts to renew with the server that granted the lease.
Conceptually:
May I continue using this address?
If the server acknowledges the renewal, the client receives a new lease duration.
The visible network configuration may remain exactly the same:
Address: 192.168.1.42
Router: 192.168.1.1
DNS: 192.168.1.1
Only the lease's timing may have changed.
Rebinding
If the original server does not answer, the client eventually enters a broader rebinding phase at T2.
Instead of relying solely on the original server, the client attempts to obtain an answer from an available DHCP server.
This matters when:
the original server is unavailable
the server has been replaced
the client moved within a managed network
the network's DHCP architecture changed
Expiration
If the lease expires without successful renewal or rebinding, the client can no longer assume that it may safely use the address.
The server may assign that address to another client.
Continuing to use it could create an address conflict.
The exact default timing rules and permitted server-supplied values are described in RFC 2131 rather than being universal constants.
Why DHCP Changes May Not Appear Immediately
Suppose you change the DNS servers advertised by your DHCP server:
Old DNS: 192.168.1.1
New DNS: 1.1.1.1
Existing clients may continue using the old DNS configuration.
Why?
Because they already hold leases containing the previous options. They may not request or receive the new configuration until they:
renew the lease
rebind
reconnect
restart their network service
or obtain an entirely new lease
Changing a DHCP server setting changes what the server will provide during subsequent protocol exchanges. It does not necessarily push the new value instantly into every connected client.
Inspecting DHCP Activity in Logs
NetworkManager activity may be visible through:
journalctl -u NetworkManager
To view recent DHCP-related lines:
journalctl -u NetworkManager --since today | grep -i dhcp
On a machine using systemd-networkd:
journalctl -u systemd-networkd --since today | grep -i dhcp
The exact output varies substantially by version and logging configuration, but you may find events relating to:
lease acquisition
address assignment
renewal
expiration
timeouts
failed offers
These logs show the DHCP client's behavior over time, while commands such as ip address and ip route show the configuration currently installed in the kernel.
Those are related views, but they are not identical.
Inspecting systemd-networkd Lease Data
A system using systemd-networkd may expose lease state beneath:
ls /run/systemd/netif/leases/
You can inspect the files with:
sudo cat /run/systemd/netif/leases/*
A lease file may contain values resembling:
ADDRESS=192.168.1.42
NETMASK=255.255.255.0
ROUTER=192.168.1.1
DNS=192.168.1.1
SERVER_ADDRESS=192.168.1.1
LIFETIME=86400
Do not expect this location on every Linux system.
DHCP may be managed by:
NetworkManager
systemd-networkd
dhclient
dhcpcd
a distribution-specific service
a container or network namespace manager
Each implementation may store and expose its lease information differently.
The Router Is Wearing Several Hats
On a home network, the address 192.168.1.1 may appear repeatedly.
For example:
ip route | grep default
default via 192.168.1.1 dev wlan0
Then:
resolvectl dns wlan0
Link 2 (wlan0): 192.168.1.1
A DHCP capture may also show:
Server Identifier: 192.168.1.1
The same address is acting as:
Default gateway: 192.168.1.1
DNS server: 192.168.1.1
DHCP server: 192.168.1.1
This can make it seem as though “the router,” “the gateway,” “DHCP,” and “DNS” are all the same concept.
They are not.
A typical home router may simultaneously act as:
an Ethernet switch
a Wi-Fi access point
an IP router
a NAT gateway
a firewall
a DHCP server
a DNS forwarder
These are different roles bundled into one device.
DHCP is not inherently a feature that must run on the router. A DHCP server could run on a dedicated server, firewall, domain controller, network appliance, or cloud networking platform.
Dynamic Leases, Reservations, and Static Addresses
Three arrangements are commonly confused.
Dynamic DHCP lease
The server selects an available address from a pool:
Pool: 192.168.1.100 through 192.168.1.200
A client might receive:
192.168.1.137
The address may change in the future, although clients often receive the same address repeatedly when circumstances permit it.
DHCP reservation
The server is configured to offer a particular address to a particular client:
Client A -> 192.168.1.20
The client still uses DHCP.
It still requests configuration, receives an offer, accepts a lease, and may receive the gateway, DNS servers, and other options.
The server has simply been instructed to choose a predictable address for that client.
Static client configuration
The address is configured directly on the client:
Address: 192.168.1.20/24
Gateway: 192.168.1.1
DNS: 192.168.1.1
The client may not contact DHCP at all.
Therefore:
A device that always receives the same IP address does not necessarily have a statically configured address.
It may have a DHCP reservation or may simply be receiving the same dynamic lease repeatedly.
DHCP Beyond a Home Network
Initial DHCP messages normally rely on local broadcasts.
Routers generally do not forward ordinary link-local broadcasts between IP networks. If a centralized DHCP server had to be physically present on every client subnet, managing a large network would become cumbersome.
Larger networks commonly use a DHCP relay agent:
Client
|
| local DHCP broadcast
v
DHCP relay
|
| relayed request
v
Central DHCP server
The relay receives the client's local broadcast and forwards the relevant information to a DHCP server on another network.
It also gives the server enough context to determine which client network originated the request. The server can then select an address from the correct pool.
The response returns through the relay to the client.
Relay agents are part of DHCP's broader architecture, but their complete behavior deserves separate treatment. For now, the important point is that the DHCP server does not have to be located directly on every client subnet.
DHCP Does Not Guarantee That the Configuration Works
A DHCP server distributes configuration. It does not prove that the supplied configuration is correct, reachable, safe, or useful.
A server can advertise:
a gateway that is down
a DNS server that is unreachable
an incorrect subnet mask
an invalid domain
a route that leads nowhere
The client may successfully obtain a DHCP lease and still lack working internet access.
Different pieces can also succeed or fail independently.
For example, a client could have:
a valid IP address
a valid subnet mask
a working default gateway
an incorrect DNS server
It might successfully reach a remote IP address while failing to resolve domain names.
That does not mean DHCP completely failed. It means one part of the distributed configuration is missing, incorrect, or unusable.
DHCP also does not inherently authenticate every server. A rogue or misconfigured server on a network may be able to provide clients with harmful configuration. DHCP security and protections such as DHCP snooping are substantial topics of their own.
Reconstructing Your Own Configuration
Try gathering the pieces from your current Linux system:
ip -4 address show
ip route
resolvectl status
nmcli device show
Then fill in what you can:
Interface:
IPv4 address:
Prefix length or subnet mask:
Local network:
Default gateway:
DNS server or servers:
DNS search domain:
DHCP server:
Lease duration:
You may not be able to find every value through these commands.
That reveals an important distinction:
ip address
# Shows addresses currently installed on interfaces.
ip route
# Shows routes currently installed in the kernel.
resolvectl
# Shows resolver configuration known to systemd-resolved.
nmcli
# Shows NetworkManager's view of device configuration.
tcpdump
# Shows the DHCP messages transmitted over the network.
DHCP lease files or logs
# Show DHCP-client state retained by a particular implementation.
No single command necessarily displays the entire story.
A Better Mental Model of DHCP
The sentence:
DHCP gives your computer an IP address.
is useful as an initial approximation.
But it encourages an incomplete mental model. It makes DHCP sound like a service that chooses one unused number and hands it to a device.
DHCP actually provides a framework for automatically distributing network configuration.
Through DHCP, a client may learn:
which address to use
which destinations are local
which router reaches other networks
which DNS resolvers to query
which additional network services are available
how long the configuration remains valid
when the lease must be renewed
A more complete definition is:
DHCP allows a client to obtain an IP address and other network configuration, use that configuration for a defined period, and renew or replace it as network conditions change.
The address is important.
It is not the whole lease, and it is not the whole protocol.
Further Reading
Comments
No comments yet. Be the first!