
DHCP: The Auto IP Assignment Office
Don't manually configure IP at cafes, right? DHCP server auto-finds and leases available IPs. Sign a 2-hour IP lease contract via DORA process.

Don't manually configure IP at cafes, right? DHCP server auto-finds and leases available IPs. Sign a 2-hour IP lease contract via DORA process.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.

Two ways to escape a maze. Spread out wide (BFS) or dig deep (DFS)? Who finds the shortest path?

Fast by name. Partitioning around a Pivot. Why is it the standard library choice despite O(N²) worst case?

Establishing TCP connection is expensive. Reuse it for multiple requests.

Two years ago, on my first day at a tech company, I was setting up my development environment. A senior engineer looked at my laptop's network settings and casually said, "Oh, you need to set this to automatic. Enable DHCP."
I stared blankly. "What's DHCP?"
He smiled. "It just automatically gets you an IP address. Don't worry about it."
But that response made me more curious. How does IP assignment happen "automatically"? What's the mechanism behind it?
A few months later, I was setting up my home router. Opening the admin panel, I saw a checkbox labeled "Enable DHCP Server." Should I check it? Leave it unchecked? I had no idea what it actually did. Just a checkbox with no understanding behind it.
The breaking point came when my startup was setting up our first office. The network vendor asked, "Where do you want the DHCP server?" I couldn't answer. That moment crystallized a painful truth: I'm a developer, but I don't understand basic networking fundamentals.
That's when I decided to study DHCP properly.
"Dynamic Host Configuration Protocol"
Seeing these words for the first time was bewildering. I knew each word individually, but together they formed incomprehensible jargon.
The biggest confusion was why manual IP assignment doesn't work. "Can't I just hardcode 192.168.0.100 into my network settings? Why this complicated automatic system?"
I didn't know yet. I hadn't experienced the hell of managing a 100-device network manually.
I truly understood DHCP when I read this analogy in a blog post. It resonated so deeply that I still remember it:
"Imagine a cafe with capacity for 100 people but only 50 seats available.
Old Method (Static IP):
- Each customer pre-assigns themselves: 'I'm seat 3'
- Even if seat 3's owner doesn't come, that seat stays empty
- New customer arrives: 'I'm seat 3' 'Wait, I'm also seat 3' → Conflict!
- When customers leave, seat reclamation doesn't happen properly
DHCP Method (Dynamic IP):
- Customer arrives → Counter staff (DHCP server) finds an empty seat → 'Use seat 12 today'
- After 2 hours, the ticket expires → Automatically return seat or extend
- Always efficiently utilizing available seats
- When customers leave, that seat immediately becomes available for the next person"
After reading this, everything clicked. That's what it was all along! DHCP is a system for efficiently managing the limited resource of IP addresses.
This actually happened when I was setting up our startup's office network.
Initially, I thought, "We only have 10 PCs. Do we really need DHCP?" Can't I just manually assign static IPs to each machine?
First Week:
One Month Later:
Three Months Later:
I realized: If this had been a 100-device office, I would've resigned from just managing IPs. It's genuinely insane.
Eventually, I bought a proper router and enabled DHCP:
DHCP Server: Enabled
IP Range: 192.168.0.100 ~ 192.168.0.200 (100 addresses)
Subnet Mask: 255.255.255.0
Gateway: 192.168.0.1
DNS: 8.8.8.8, 8.8.4.4
Lease Time: 24 hours
After that:
I should've done this from the start. DHCP is technology that preserves network administrators' mental health.
DHCP assigns IPs through a four-step process called DORA. When you capture packets with Wireshark, you can actually see these packets being exchanged in this exact sequence.
[My Laptop] "New device here! Any DHCP server, please respond!"
(Broadcast to 255.255.255.255:67 via UDP)
Source IP: 0.0.0.0 (no IP yet)
Destination IP: 255.255.255.255 (full broadcast)
Source MAC: 00:1A:2B:3C:4D:5E (my MAC address)
When my laptop first connects to the network, it shouts to every device: "Who's the DHCP server?" At this stage, there's no IP address yet, so the Source IP is 0.0.0.0.
To initiate a DHCP request on Linux:
# Start DHCP client (sends Discover packet)
sudo dhclient -v eth0
# Output:
# Listening on LPF/eth0/00:1a:2b:3c:4d:5e
# Sending on LPF/eth0/00:1a:2b:3c:4d:5e
# Sending on Socket/fallback
# DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
[DHCP Server] "I'm here! 192.168.0.155 is available. Want it?"
Offer includes:
- IP Address: 192.168.0.155
- Subnet Mask: 255.255.255.0 (same network range)
- Gateway: 192.168.0.1 (router address for external internet)
- DNS Servers: 8.8.8.8, 8.8.4.4 (Google DNS)
- Lease Time: 86400 seconds (24 hours)
- DHCP Server IP: 192.168.0.1
The DHCP server responds. If multiple DHCP servers exist on the network, each can send an Offer. The PC typically selects the first Offer that arrives.
# dhclient output continues:
# DHCPOFFER of 192.168.0.155 from 192.168.0.1
# DHCPREQUEST for 192.168.0.155 on eth0 to 255.255.255.255 port 67
[My Laptop] "Great! I'll use 192.168.0.155!"
(Broadcasting confirmation again)
Source IP: 0.0.0.0 (still pre-assignment)
Destination IP: 255.255.255.255 (broadcast)
Requested IP: 192.168.0.155
Server Identifier: 192.168.0.1
Why broadcast this instead of unicasting directly to the DHCP server?
Reason: Multiple DHCP servers might exist on the network. If I chose the first server's offer, I need to tell all other DHCP servers "I chose the first server" so they can reclaim the IPs they offered.
[DHCP Server] "Okay! 192.168.0.155 is yours for 24 hours."
Source IP: 192.168.0.1 (DHCP server)
Destination IP: 192.168.0.155 (now my confirmed IP)
Lease Time: 86400 seconds
Renewal Time (T1): 43200 seconds (50%, renew after 12 hours)
Rebinding Time (T2): 75600 seconds (87.5%, retry after 21 hours)
The DHCP server gives final approval. Now my laptop officially has an IP address and can use the internet!
# dhclient final output:
# DHCPACK of 192.168.0.155 from 192.168.0.1
# bound to 192.168.0.155 -- renewal in 43200 seconds.
Verify my IP:
ip addr show eth0
# Output:
# eth0: <BROADCAST,MULTICAST,UP,LOWER_UP>
# inet 192.168.0.155/24 brd 192.168.0.255 scope global dynamic eth0
# valid_lft 86400sec preferred_lft 86400sec
To actually watch the DHCP process, use Wireshark:
# Wireshark filter
udp.port == 67 or udp.port == 68
# Or simpler:
bootp
You'll see this in the capture:
1. DHCP Discover (Client → Broadcast)
2. DHCP Offer (Server → Client)
3. DHCP Request (Client → Broadcast)
4. DHCP Ack (Server → Client)
IPs received through DHCP are not permanently owned. They're time-limited rentals. Understanding this concept made DHCP's efficiency crystal clear to me.
Home Router: Usually 24 hours (86400 seconds)
Corporate Network: 8 hours (28800 seconds)
Cafe WiFi: 2 hours (7200 seconds)
Hotel WiFi: 1 hour (3600 seconds)
At 50% of lease time, automatic renewal is attempted. This is called the T1 timer.
Received 24-hour lease
→ After 12 hours (50% mark): "Please extend" (resend DHCP Request)
→ DHCP Server: "Okay, 24 more hours" (ACK)
→ 24-hour countdown restarts
This process happens silently in the background. Users never notice it.
# Check lease info on Linux
cat /var/lib/dhcp/dhclient.leases
# Output:
# lease {
# interface "eth0";
# fixed-address 192.168.0.155;
# option subnet-mask 255.255.255.0;
# option routers 192.168.0.1;
# option dhcp-lease-time 86400;
# option dhcp-renewal-time 43200; # T1: 50%
# option dhcp-rebinding-time 75600; # T2: 87.5%
# renew 3 2025/05/08 12:00:00;
# expire 4 2025/05/09 00:00:00;
# }
What if the original DHCP server doesn't respond at T1? (Server failure or network issue)
At 87.5% of lease time (the T2 timer), the client broadcasts again: "Original server aside, any other DHCP server please respond!"
→ After 21 hours (87.5% mark): Broadcast "Any server, please respond!"
→ Backup DHCP Server: "I'll extend it for you"
When you turn off your PC or disconnect WiFi, the IP is properly returned:
# Manually release IP
sudo dhclient -r eth0
# Output:
# Removed stale PID file
# Killed old client process
After release, the DHCP server puts that IP back into the pool for other devices.
But in reality, abnormal terminations are more common:
In these cases, the DHCP server waits until lease expiration before reclaiming the IP.
When I open my laptop at my regular cafe:
1. Discover: "DHCP server here?"
2. Offer: "Here's 192.168.1.105 for 2 hours"
3. Request: "I'll take it"
4. Ack: "Approved!"
After 2 hours:
Why WiFi sometimes disconnects for 1-2 seconds at cafes: This is the renewal process. Usually seamless, but occasionally causes brief disconnections.
Docker internally uses a mechanism similar to DHCP. When you create a docker network:
# Create Docker network
docker network create --subnet=172.20.0.0/16 mynet
# Run container
docker run -d --network mynet nginx
# Automatically gets IP like 172.20.0.2
docker inspect <container_id> | grep IPAddress
# Output:
# "IPAddress": "172.20.0.2"
Docker uses an IPAM (IP Address Management) driver to automatically assign IPs to containers. When containers stop, IPs are reclaimed and reused for new containers.
DHCP matters in cloud environments too. When you create an AWS VPC, a DHCP Options Set is automatically created:
# Check DHCP Options with AWS CLI
aws ec2 describe-dhcp-options
# Output (JSON):
{
"DhcpOptions": [{
"DhcpConfigurations": [
{
"Key": "domain-name",
"Values": [{"Value": "ap-northeast-2.compute.internal"}]
},
{
"Key": "domain-name-servers",
"Values": [{"Value": "AmazonProvidedDNS"}]
}
]
}]
}
AWS EC2 instances receive via DHCP during boot:
You can create custom DHCP Options to specify your own DNS servers:
# Create custom DHCP Options
aws ec2 create-dhcp-options \
--dhcp-configurations \
"Key=domain-name-servers,Values=10.0.0.10,10.0.0.11" \
"Key=domain-name,Values=mycompany.internal"
In college, I was curious how campus networking worked, so I visited the network admin office.
The Problem:
The Question: If a PC in the Engineering building broadcasts "DHCP server here?", how does it reach the IT center?
Broadcasts don't cross routers. They only propagate within the same subnet.
The Solution: DHCP Relay AgentEach building's router acts as a DHCP Relay Agent:
[Engineering PC] → "DHCP server here?" (broadcast)
[Engineering Router] → "Oh, DHCP request? I'll relay this to the IT center server"
[Engineering Router] → Forwards via unicast to IT center DHCP server
[IT Center DHCP] → "Here's 192.168.1.105" (responds to Engineering router)
[Engineering Router] → Forwards to Engineering PC
Cisco router configuration example:
interface GigabitEthernet0/1
description Engineering Building Network
ip address 192.168.1.1 255.255.255.0
ip helper-address 10.0.0.100 # IT center DHCP server IP
The ip helper-address command activates the DHCP Relay Agent.
As IPv4 addresses deplete, the transition to IPv6 is underway. In IPv6, DHCP has been upgraded too: DHCPv6.
IPv6 supports two autoconfiguration methods:
# Run DHCPv6 client on Linux
sudo dhclient -6 -v eth0
# Output:
# Bound to *:546
# Listening on Socket/eth0
# Sending on Socket/eth0
# PRC: Confirming active lease (INIT-REBOOT).
# XMT: Forming Rebind, 0 ms elapsed.
# RCV: Reply message on eth0 from fe80::1.
DHCPv6 addresses look like this:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
Much longer, right? IPv6 has a nearly infinite address space (2^128 addresses), so depletion isn't a concern.
DHCP is convenient, but it has security vulnerabilities. These are issues pointed out during our startup's security audit.
Scenario:
When my PC boots in the morning and shouts "DHCP server here?", what if the unauthorized router responds faster than the legitimate company server?
[My PC] → "DHCP server here?"
[Rogue Router] → "I'm here! Use 192.168.100.50!" (responds first)
[Company Server] → "I'm here too! Use 192.168.0.100!" (responds late)
→ My PC accepts the rogue router's IP
Result:
Real Experience: One employee "couldn't get WiFi near my desk" so secretly installed a personal router. No malicious intent, but 10 nearby PCs all connected to that router, losing access to internal company servers.
Attack Method: Hacker runs a Python script generating thousands of fake MAC addresses, sending DHCP Discover for each:
# Malicious script example (educational purposes only)
from scapy.all import *
for i in range(1, 255):
fake_mac = f"00:11:22:33:44:{i:02x}"
dhcp_discover = (
Ether(dst="ff:ff:ff:ff:ff:ff", src=fake_mac) /
IP(src="0.0.0.0", dst="255.255.255.255") /
UDP(sport=68, dport=67) /
BOOTP(chaddr=fake_mac) /
DHCP(options=[("message-type", "discover"), "end"])
)
sendp(dhcp_discover, iface="eth0")
The DHCP server naively assigns IPs for each request:
Result: IP pool depleted (starvation) → Real employees can't get IPs → Internet unusable → DoS attack successful
To prevent these attacks, enable DHCP Snooping on network switches.
How It Works:
Cisco switch configuration example:
# Enable DHCP Snooping
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
# Designate trusted port (connected to DHCP server)
interface GigabitEthernet0/1
description Uplink to DHCP Server
ip dhcp snooping trust
# Rate Limiting (max 10 DHCP requests per second)
interface range GigabitEthernet0/2-24
ip dhcp snooping limit rate 10
After applying this configuration in our setup, Rogue DHCP problems completely disappeared.
Servers:
Printers:
CCTV/IoT Devices:
Routers/Gateways:
"Servers need static IPs, but manually configuring each server is annoying..."
Solution: DHCP Reservation (IP reservation)
Map MAC addresses to IPs in DHCP server settings:
MAC Address: 00:1A:2B:3C:4D:5E
Reserved IP: 192.168.0.100
This way:
Advantages:
Home router configuration example:
Static IP Assignment (DHCP Reservation):
Device: Synology NAS
MAC: 00:11:32:5E:3C:1A
IP: 192.168.0.10
Device: Raspberry Pi
MAC: B8:27:EB:7A:3D:9F
IP: 192.168.0.20
One Monday morning, I arrived at the office and booted my laptop. Got an "IP Address Conflict" error.
Windows Network Error:
"Another computer on the network is using this IP address"
Internet completely down. Team-wide meeting in 30 minutes...
Root Cause:
Solution: IT team separated DHCP range from static IP range:
DHCP Range: 192.168.0.100 ~ 192.168.0.199 (100 addresses)
Static IP Range: 192.168.0.1 ~ 192.168.0.99 (for servers)
Special Purpose: 192.168.0.200 ~ 192.168.0.254 (printers, CCTV, etc.)
After that, no IP conflicts ever occurred. I learned that proper network design is essential.
When I factory reset my home router.
After reset, I rebooted my PC, but internet didn't work. Checked my IP address:
ipconfig
# Output:
# Ethernet adapter Ethernet:
# IPv4 Address: 169.254.123.45
# Subnet Mask: 255.255.0.0
169.254.x.x? What is this?
Searched and learned about APIPA (Automatic Private IP Addressing).
What's APIPA?:
Cause: After router reset, DHCP server feature was disabled.
Solution: Access router admin page (192.168.0.1) → Enable DHCP server → Reboot PC
DHCP Server: On
IP Start: 192.168.0.100
IP End: 192.168.0.200
Lease Time: 86400 seconds (24 hours)
PC rebooted and normally received 192.168.0.105.
Tried to run a home server with port forwarding, but external access didn't work.
Environment:
Problem: Configured port forwarding on personal router, but it didn't work.
Cause: Double NAT
Solution:
Lesson Learned: DHCP autoconfiguration is convenient, but without proper network architecture understanding, you'll struggle later. To summarize, DHCP is the starting point of networking, not the endpoint.
Core concepts I internalized while studying DHCP:
The "magic" of connecting to cafe WiFi and "just getting internet" is actually thanks to DHCP, a well-defined protocol. Now when I open router admin panels, I fully understand what each setting means. When designing company networks, I can confidently contribute informed opinions.
Ultimately, DHCP isn't simply "automatic IP assignment" — it's a distributed system for efficiently managing and sharing limited resources (IP addresses). That concept really resonated with me.