%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
participant C as Client<br/>0.0.0.0
participant S as DHCP Server<br/>192.168.1.1
Note over C: Step 1: DISCOVER
C->>S: DHCPDISCOVER (broadcast)<br/>"I need an IP address!"
Note over S: Step 2: OFFER
S->>C: DHCPOFFER<br/>"Here's 192.168.1.100"
Note over C: Step 3: REQUEST
C->>S: DHCPREQUEST (broadcast)<br/>"I accept 192.168.1.100"
Note over S: Step 4: ACKNOWLEDGE
S->>C: DHCPACK<br/>"192.168.1.100 is yours for 24 hours"
Note over C: Client configured:<br/>IP: 192.168.1.100<br/>Mask: 255.255.255.0<br/>Gateway: 192.168.1.1<br/>DNS: 8.8.8.8
607 DHCP and Address Resolution
607.1 Learning Objectives
By the end of this chapter, you will be able to:
- Configure DHCP: Set up automatic IP assignment for IoT devices
- Choose lease times: Select appropriate durations for different device types
- Understand ARP: Explain how IPv4 addresses resolve to MAC addresses
- Apply Neighbor Discovery: Use IPv6’s improved address resolution mechanism
- Troubleshoot addressing issues: Diagnose IP conflicts and ARP problems
TipMVU: Minimum Viable Understanding
Core concept: DHCP automatically assigns IP addresses to devices, while ARP (IPv4) and Neighbor Discovery (IPv6) resolve IP addresses to physical MAC addresses for local delivery.
Why it matters: Manual IP assignment for 500 sensors would take 40+ hours - DHCP does it in seconds. ARP problems cause mysterious connectivity failures.
Key takeaway: Use DHCP with long leases (7-30 days) for fixed IoT sensors, DHCP reservations for infrastructure devices, and watch for ARP flapping as a sign of IP conflicts.
607.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- IPv4 Addressing Fundamentals: Understanding of IP address structure
- Subnetting and CIDR: Knowledge of subnet boundaries
TipFor Beginners: DHCP and ARP
DHCP (Dynamic Host Configuration Protocol) automatically assigns IP addresses to devices when they connect to a network. When your IoT sensor powers on, it broadcasts “I need an IP address!” and a DHCP server responds with one.
Why DHCP is essential: - 1,000 sensors × 5 minutes manual config = 83 hours - DHCP: automatic, instant, error-free
ARP (Address Resolution Protocol) solves a different problem: your device knows the IP address it wants to reach (192.168.1.100), but the network hardware needs the physical MAC address. ARP broadcasts “Who has 192.168.1.100?” and the target device responds with its MAC address.
Common problems: - IP conflict: Two devices claiming the same IP → ARP flapping - DHCP failure: Device gets no IP → link-local address (169.254.x.x)
607.3 DHCP (Dynamic Host Configuration Protocol)
607.3.1 Why DHCP for IoT?
Manual IP Assignment Problems: - 1,000 sensors × 5 minutes each = 83 hours of configuration - Human error (duplicate IPs, typos) - No visibility into which addresses are used - Difficult to reconfigure (moving sensors, network changes)
DHCP Solution: - Automatic IP assignment - Centralized management - Lease tracking - Easy reconfiguration
607.3.2 DHCP Operation (DORA Process)
{fig-alt=“DHCP DORA process showing four-step handshake: Discover (client broadcasts request), Offer (server proposes IP), Request (client accepts), Acknowledge (server confirms with IP address and network configuration)”}
DHCP Ports: - Server listens on UDP port 67 - Client listens on UDP port 68
607.3.3 DHCP Lease Management
Lease Time: Duration for which IP is assigned (e.g., 24 hours, 7 days)
Lease Renewal Process: 1. At 50% of lease time (T1), client tries to renew with original server 2. At 87.5% of lease time (T2), client broadcasts renewal to any server 3. If lease expires, client must restart DORA process
IoT Lease Considerations:
| Device Type | Recommended Lease | Reasoning |
|---|---|---|
| Fixed sensors | 7-30 days | Rarely move, long leases reduce DHCP traffic |
| Mobile devices | 1-4 hours | Frequent movement, need quick IP changes |
| Temporary devices | 30 minutes | Testing, commissioning |
| Critical infrastructure | Static assignment | Guaranteed address, no DHCP dependency |
607.3.4 DHCP Options for IoT
Beyond IP address, DHCP provides additional configuration via options:
| Option | Purpose | Example | IoT Relevance |
|---|---|---|---|
| 3 | Default Gateway | 192.168.1.1 | Routes to internet/cloud |
| 6 | DNS Servers | 8.8.8.8, 1.1.1.1 | Resolve cloud hostnames |
| 15 | Domain Name | sensors.example.com | Device FQDN |
| 42 | NTP Servers | time.google.com | Clock synchronization |
| 66 | TFTP Server | 192.168.1.50 | Firmware updates |
| 150 | TFTP Server (Cisco) | 192.168.1.50 | Cisco-specific firmware |
607.3.5 DHCP Reservations (Static DHCP)
Best of both worlds: Combine DHCP convenience with static IP predictability
How it works: - DHCP server maps MAC address to specific IP - Device always gets the same IP via DHCP - Example: Camera with MAC 00:11:22:33:44:55 always gets 192.168.1.100
Benefits: - Centralized management (all IPs configured in DHCP server) - Predictable addressing (gateways, cameras always at known IPs) - Easy to change (update DHCP server, not each device)
IoT Best Practice: - Static DHCP for critical infrastructure (gateways, access points, NVRs) - Dynamic DHCP for sensors, actuators - Static manual for network infrastructure (routers, switches, DHCP server itself)
607.4 Address Resolution (ARP and Neighbor Discovery)
607.4.1 ARP (Address Resolution Protocol) for IPv4
Problem: IP addresses are logical, but Ethernet requires physical MAC addresses. How does a device find the MAC address for an IP?
Solution: ARP broadcasts “Who has IP 192.168.1.100?” and the device responds with its MAC address.
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
participant S as Sender<br/>192.168.1.50<br/>MAC: AA:BB:CC:DD:EE:FF
participant Net as Network (Broadcast)
participant T as Target<br/>192.168.1.100<br/>MAC: 11:22:33:44:55:66
Note over S: Need to send to<br/>192.168.1.100<br/>but don't know MAC
S->>Net: ARP Request (broadcast)<br/>"Who has 192.168.1.100?<br/>Tell AA:BB:CC:DD:EE:FF"
Net->>T: Broadcast to all devices
Note over T: That's me!
T->>S: ARP Reply (unicast)<br/>"192.168.1.100 is at<br/>11:22:33:44:55:66"
Note over S: Cache mapping:<br/>192.168.1.100 → 11:22:33:44:55:66
S->>T: Send data using MAC address
{fig-alt=“ARP process showing sender broadcasting ‘Who has 192.168.1.100?’, target responding with MAC address 11:22:33:44:55:66, and sender caching the IP-to-MAC mapping for future use”}
ARP Cache: - Devices store IP→MAC mappings in ARP cache - Reduces broadcast traffic - Typical cache timeout: 5-20 minutes
Check ARP cache:
# Linux/macOS
arp -a
# Windows
arp -a
# Example output:
# 192.168.1.1 11:22:33:44:55:66 dynamic
# 192.168.1.100 aa:bb:cc:dd:ee:ff dynamicARP Limitations: - Broadcasts consume bandwidth (problematic in large networks) - Security vulnerabilities (ARP spoofing attacks) - No authentication (any device can claim any IP)
607.4.2 Neighbor Discovery (ND) for IPv6
IPv6 Neighbor Discovery replaces ARP with a more efficient, secure protocol using ICMPv6 messages.
Key ND Messages:
| Message Type | Purpose | IPv4 Equivalent |
|---|---|---|
| Router Solicitation (RS) | “Are there any routers?” | None |
| Router Advertisement (RA) | “I’m a router, here’s network config” | DHCP (partially) |
| Neighbor Solicitation (NS) | “What’s your MAC address?” | ARP Request |
| Neighbor Advertisement (NA) | “My MAC is X” | ARP Reply |
| Redirect | “Use this router instead” | ICMP Redirect |
Advantages over ARP:
- Uses multicast instead of broadcast: Only interested devices process packets
- Duplicate Address Detection (DAD): Prevents IP conflicts automatically
- Router Discovery: Devices auto-discover gateways (no DHCP needed for basic config)
- Stateless Address Autoconfiguration (SLAAC): Devices self-assign IPs based on network prefix
- Integrated security: IPsec can secure ND messages (prevents spoofing)
SLAAC (Stateless Address Autoconfiguration):
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
participant D as IoT Device<br/>(just powered on)
participant Net as Network
participant R as Router
Note over D: Step 1: Create link-local
D->>D: Generate fe80::MAC-based address
Note over D: Step 2: Request prefix
D->>Net: Router Solicitation (RS)<br/>"Any routers here?"
R->>Net: Router Advertisement (RA)<br/>"Use prefix 2001:db8::/64"
Note over D: Step 3: Auto-configure
D->>D: Create global address:<br/>2001:db8::MAC-based<br/>(no DHCP needed!)
Note over D: Step 4: Duplicate check
D->>Net: Neighbor Solicitation<br/>"Anyone using my address?"
Note over D: No response = address is unique
Note over D: Fully configured:<br/>Link-local: fe80::...<br/>Global: 2001:db8::...
{fig-alt=“IPv6 SLAAC process showing IoT device self-configuring: creates link-local address, requests network prefix via Router Solicitation, receives Router Advertisement with prefix, generates global address, and performs Duplicate Address Detection”}
IoT Implications: - IPv6 sensors can self-configure without DHCP server - Reduced infrastructure requirements - Faster deployment (plug-and-play)
607.5 Practical Exercise: DHCP Configuration Planning
Scenario: Configure DHCP for a smart building with: - 200 IoT sensors (fixed locations, rarely change) - 50 employee smartphones (frequent connects/disconnects) - 10 security cameras (critical, need predictable IPs) - 5 network infrastructure devices (gateways, access points)
Design the DHCP configuration:
Solution:
| Device Type | Assignment Method | IP Range | Lease Time | Rationale |
|---|---|---|---|---|
| Infrastructure | Static (manual) | 192.168.1.1-10 | N/A | Must be reachable even if DHCP fails |
| Cameras | DHCP Reservation | 192.168.1.11-20 | 30 days | Predictable IPs for NVR, long lease |
| IoT Sensors | Dynamic DHCP | 192.168.1.50-249 | 7 days | Fixed locations, long lease reduces traffic |
| Smartphones | Dynamic DHCP | 192.168.1.50-249 | 2 hours | Shared pool with sensors, short lease for mobility |
DHCP Server Configuration (example):
# Subnet declaration
subnet 192.168.1.0 netmask 255.255.255.0 {
# Dynamic pool (sensors and phones share)
range 192.168.1.50 192.168.1.249;
# DHCP options
option routers 192.168.1.1;
option domain-name-servers 8.8.8.8, 1.1.1.1;
option ntp-servers 192.168.1.1;
option domain-name "smartbuilding.local";
# Default lease time: 7 days (sensors)
default-lease-time 604800;
max-lease-time 2592000;
}
# Camera reservations (predictable IPs)
host camera-lobby {
hardware ethernet aa:bb:cc:dd:ee:01;
fixed-address 192.168.1.11;
default-lease-time 2592000; # 30 days
}
host camera-entrance {
hardware ethernet aa:bb:cc:dd:ee:02;
fixed-address 192.168.1.12;
default-lease-time 2592000;
}Key Design Decisions: - Infrastructure devices get static IPs (DHCP server must know their address) - Cameras use DHCP reservations (centralized management + predictability) - Sensors and phones share dynamic pool (efficient address utilization) - Lease times match device mobility (fixed devices = long leases)
607.6 Worked Example: Troubleshooting IP Address Conflict
Scenario: Your smart factory suddenly experiences intermittent connectivity issues. Two temperature sensors are reporting sporadically, and network monitoring shows MAC address flapping alerts.
Given: - Sensor A: MAC 24:0A:C4:12:34:56, assigned DHCP IP 192.168.10.45 - Sensor B: MAC 24:0A:C4:78:9A:BC, assigned DHCP IP 192.168.10.67 - Symptom: Both sensors show as 192.168.10.45 in ARP table intermittently
Steps:
Verify the ARP table on the gateway:
$ arp -a 192.168.10.45 24:0A:C4:12:34:56 dynamic (Sensor A - correct) 192.168.10.45 24:0A:C4:78:9A:BC dynamic (Sensor B - CONFLICT!) 192.168.10.67 (incomplete)Analyze the root cause:
Sensor B's ARP entry shows 192.168.10.45, but DHCP assigned .67 Diagnosis: Sensor B has a statically configured IP that conflicts with Sensor A's DHCP-assigned address.Verify by pinging and checking ARP changes:
$ ping 192.168.10.45 Reply from 192.168.10.45: bytes=32 time<1ms (MAC: 24:0A:C4:12:34:56) Reply from 192.168.10.45: bytes=32 time<1ms (MAC: 24:0A:C4:78:9A:BC) ARP table alternates between two MACs - confirmed IP conflict!Resolve the conflict:
- Option A: Reconfigure Sensor B to use DHCP
- Option B: Create DHCP reservation for both sensors
- Option C: Assign static IPs outside DHCP range
Result: After reconfiguring Sensor B to use DHCP and creating MAC-based reservations, both sensors receive unique IP addresses and connectivity is restored.
Key Insight: IP address conflicts cause “ARP flapping” where the switch’s MAC address table constantly updates, randomly delivering packets to either device. Always segment your address space into static and dynamic ranges.
607.7 Common Pitfalls
CautionPitfall: Misconfiguring Subnet Masks Causing Silent Routing Failures
The Mistake: Developers assign IP addresses with incorrect subnet masks (e.g., using /24 when the network is /16), causing devices to incorrectly determine whether destinations are local or remote.
Why It Happens: Many IoT tutorials use “255.255.255.0” as a universal subnet mask without explaining its meaning. When copying configurations between networks, the subnet mask is often left unchanged.
The Fix: Understand and verify the subnet calculation:
Scenario: Device A (192.168.1.50/24) tries to reach Device B (192.168.2.100)
Device A's subnet calculation:
- My IP: 192.168.1.50
- My mask: 255.255.255.0 (/24)
- My network: 192.168.1.0
- Target: 192.168.2.100
- Target AND mask: 192.168.2.0
- Result: 192.168.1.0 ≠ 192.168.2.0 → "Different network, send to gateway"Problem case: Device A configured with wrong mask /16:
Device A's (incorrect) subnet calculation:
- My IP: 192.168.1.50
- My mask: 255.255.0.0 (/16) ← WRONG
- My network: 192.168.0.0
- Target: 192.168.2.100
- Target AND mask: 192.168.0.0
- Result: 192.168.0.0 = 192.168.0.0 → "Same network, send directly via ARP"With the wrong /16 mask, Device A tries to ARP for 192.168.2.100 directly instead of sending through the gateway. Communication silently fails.
Diagnostic commands:
# Linux: Verify route decision
ip route get 192.168.2.100
# Should show "via <gateway>" if correctly configuredPrevention: Always verify subnet masks match the actual network topology. Use DHCP for automatic configuration.
607.8 Summary
- DHCP automates IP assignment using the DORA process (Discover, Offer, Request, Acknowledge), saving hours of manual configuration
- Lease times should match device mobility: 7-30 days for fixed sensors, hours for mobile devices
- DHCP options provide additional configuration: gateway (option 3), DNS (option 6), NTP (option 42)
- DHCP reservations combine automatic management with predictable addresses by mapping MAC addresses to specific IPs
- ARP resolves IPv4 addresses to MAC addresses via broadcast queries, with results cached to reduce traffic
- IPv6 Neighbor Discovery improves on ARP with multicast, automatic duplicate detection (DAD), and SLAAC
- IP conflicts cause ARP flapping - alternating MAC addresses in ARP cache indicates two devices claiming the same IP
- Subnet mask misconfigurations cause silent routing failures when devices incorrectly determine local vs remote destinations
607.9 What’s Next
Now that you understand DHCP and address resolution, continue with:
- Networking Addressing Index: Return to the main addressing overview
- Network Labs and Quiz: Hands-on exercises configuring networks
- Routing Fundamentals: How routers use addressing information to forward packets