DHCP: The Auto IP Assignment Office

Why I Started Learning About DHCP

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.

What Confused Me Initially

"Dynamic Host Configuration Protocol"

Seeing these words for the first time was bewildering. I knew each word individually, but together they formed incomprehensible jargon.

• Dynamic means what's changing dynamically? Does my IP address keep changing?
• Host refers to PCs? Or servers? What's a "host" exactly?
• Configuration of what? What settings are we talking about?
• Protocol is communication rules... but who's communicating with whom?

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.

The Aha Moment: "Automated Ticket Dispenser"

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.

Why DHCP Is Essential: The Hell of Manual IP Configuration

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:

• Manually configured 10 PCs with IPs from 192.168.0.10 to 192.168.0.19
• Created an Excel spreadsheet titled "IP Management Master List" to track who uses which IP
• Thought, "This isn't so bad"

One Month Later:

• Three new employees joined → "Which IPs are available again?" Had to open the Excel file
• One employee's laptop showed an "IP conflict" error → Turns out I forgot to update the Excel sheet and assigned duplicate IPs
• Network down for 2 hours → Entire team's work paralyzed

Three Months Later:

• PC count grew to 30
• Never properly reclaimed IPs from employees who left, so the IP range became a mess
• Added conference room TVs, printers, IoT sensors → Complete chaos
• Earned the nickname "IP Manager" (not in a good way...)

I realized: If this had been a 100-device office, I would've resigned from just managing IPs. It's genuinely insane.

After Implementing DHCP

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:

• New employee? Just give them the WiFi password. Done.
• IP conflicts? Never happened again.
• Excel IP spreadsheet? Deleted.
• My time? Focused entirely on development.

I should've done this from the start. DHCP is technology that preserves network administrators' mental health.

DHCP Process: The DORA Four Steps

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.

1. Discover: "Is There a DHCP Server?"

[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

2. Offer: "Want This IP?"

[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

3. Request: "Yes, I'll Take It!"

[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.

4. Acknowledge: "Approved!"

[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

Seeing It With Wireshark

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)

IP Lease Concept: Rental, Not Ownership

IPs received through DHCP are not permanently owned. They're time-limited rentals. Understanding this concept made DHCP's efficiency crystal clear to me.

Lease Time Duration

Home Router: Usually 24 hours (86400 seconds)

• Reason: PCs and smartphones stay home all day, so set it long
• After reboot, high probability of getting the same IP

Corporate Network: 8 hours (28800 seconds)

• Reason: Employees leave work → IP returned for efficient reuse
• Morning arrival might result in a different IP

Cafe WiFi: 2 hours (7200 seconds)

• Reason: High customer turnover rate
• Like table seats, need to free them quickly for next customers

Hotel WiFi: 1 hour (3600 seconds)

• Reason: Frequent check-ins/check-outs, short lease for security
• Long-term guests auto-renew continuously

Renewal: The T1 Timer

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;
# }

Rebinding: The T2 Timer

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"

Release: Returning the IP

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:

• Laptop battery dies suddenly
• Walk out of WiFi range
• Force shutdown

In these cases, the DHCP server waits until lease expiration before reclaiming the IP.

Real-World Cases

Case 1: The Secret of Cafe WiFi

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:

• Still working: Background auto-renewal (at 1-hour mark)
• Leave cafe: IP returned → Next customer gets that IP

Why WiFi sometimes disconnects for 1-2 seconds at cafes: This is the renewal process. Usually seamless, but occasionally causes brief disconnections.

Case 2: Docker Container Networking

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.

Case 3: AWS VPC DHCP Options Sets

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:

• Private IP address (e.g., 10.0.1.25)
• VPC DNS server address
• Domain name (ap-northeast-2.compute.internal)

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"

Case 4: University Campus DHCP Relay

In college, I was curious how campus networking worked, so I visited the network admin office.

The Problem:

• Campus has 10 buildings
• Each building uses a different subnet (e.g., Engineering 192.168.1.x, Humanities 192.168.2.x...)
• DHCP server is in the IT center, just 1 server

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 Agent

Each 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.

DHCPv6: What About IPv6?

As IPv4 addresses deplete, the transition to IPv6 is underway. In IPv6, DHCP has been upgraded too: DHCPv6.

IPv6 Address Autoconfiguration Methods

IPv6 supports two autoconfiguration methods:

1. SLAAC (Stateless Address Autoconfiguration): Receives RA (Router Advertisement) messages from router and self-generates IP
2. DHCPv6: Similar to DHCPv4, receives IP from server

# 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.

Security Issues: DHCP Can Be Hacked

DHCP is convenient, but it has security vulnerabilities. These are issues pointed out during our startup's security audit.

1. Rogue DHCP Server (Unauthorized DHCP Server)

Scenario:

• Someone brings their personal router to the office
• Plugs it into the wall
• That router has DHCP server enabled by default

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:

• My PC's gateway is set to the rogue router
• All my internet traffic goes through the rogue router
• Hacker can perform Man-in-the-Middle attacks, eavesdropping on packets
• Can even redirect to fake websites

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.

2. DHCP Starvation (IP Exhaustion Attack)

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:

• 00:11:22:33:44:01 → 192.168.0.100
• 00:11:22:33:44:02 → 192.168.0.101
• ...
• 00:11:22:33:44:64 → 192.168.0.200

Result: IP pool depleted (starvation) → Real employees can't get IPs → Internet unusable → DoS attack successful

3. DHCP Snooping (Defense Technique)

To prevent these attacks, enable DHCP Snooping on network switches.

How It Works:

1. Switch monitors all DHCP packets
2. Designate "Trusted Ports" → Ports connected to legitimate DHCP servers
3. DHCP Offer/Ack packets from other ports? → Immediately blocked
4. Excessive DHCP Discover requests also blocked via Rate Limiting

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.

Static IP vs DHCP: When to Use What?

When Static IP Is Needed

Servers:

• Web servers, DB servers can't have changing IPs
• Clients connect via IP
• Example: Company internal DB server 192.168.0.10

Printers:

• 30 office PCs configured to print to "192.168.0.50"
• If IP changes, need to reconfigure all 30 PCs (hell)

CCTV/IoT Devices:

• Management software needs to know the IP
• Can't locate devices if IP keeps changing

Routers/Gateways:

• Gateway address must be static
• Usually 192.168.0.1 or 192.168.1.1

DHCP Reservation (Semi-Static IP)

"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:

• Server automatically receives IP via DHCP
• But always gets 192.168.0.100 (based on MAC address)
• Server uses DHCP settings, only router needs reservation configuration

Advantages:

• Centralized IP management (don't need to configure each server individually)
• If IP change needed, just modify router settings

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

My DHCP Struggles: Real Problems I Faced

Struggle 1: IP Conflict Morning Commute Hell

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:

• Company network uses DHCP by default
• But some servers use static IPs
• IT team set server to static IP 192.168.0.150
• But DHCP range was configured as 192.168.0.100-200
• My laptop booted and unluckily received 192.168.0.150
• Conflict!

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.

Struggle 2: No DHCP Server → APIPA Address

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?:

• When Windows/Linux PC can't find DHCP server
• "But I still need network functionality"
• Self-generates random IP from 169.254.0.1~169.254.255.254 range
• Can communicate with other PCs on same network
• But no external internet (no gateway)

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.

Struggle 3: Double NAT Causing Port Forwarding Failure

Tried to run a home server with port forwarding, but external access didn't work.

Environment:

• KT Internet → KT Router (192.168.219.1)
• My personal router connected (192.168.0.1)
• Home server: 192.168.0.10

Problem: Configured port forwarding on personal router, but it didn't work.

Cause: Double NAT

• KT router assigned 192.168.219.100 to my router via DHCP
• My router assigned 192.168.0.10 to home server
• External traffic → Reaches KT router
• KT router doesn't know to forward to 192.168.219.100 (not configured)

Solution:

1. Configure port forwarding on both routers (KT router → My router, My router → Home server)
2. Or cleaner: Set KT router to bridge mode, let my router handle NAT alone

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.

Key Takeaways

Core concepts I internalized while studying DHCP:

1. Convenience of Auto IP Assignment - No manual configuration needed
2. DORA Four Steps - Discover, Offer, Request, Acknowledge for reliable IP assignment
3. Lease Concept - IPs are time-limited rentals, not permanent ownership, enabling efficient reuse
4. DHCP Relay - Solves broadcast limitation across routers using relay agents
5. Security Vulnerabilities - Attacks like Rogue DHCP and DHCP Starvation exist, defended by DHCP Snooping
6. Importance of Network Design - Separating DHCP range from static IP range prevents conflicts

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.