We have spent this series looking at the grand machinery of the internet: addresses that span the globe, names that resolve across continents, connections that cross oceans, routing that stitches the whole world together. But we have skipped past something, and it is the something that happens first, every single time, right under your nose.
Think about what actually occurs in the two seconds after you connect to a cafe's Wi-Fi. Your device arrives on the network knowing nothing. It has no address. It does not know where the router is. It does not know how to reach anything. And yet, within a moment, it is fully configured and loading pages. How? Three quiet protocols did the groundwork, invisibly, before you noticed a thing.
The first, DHCP, walked up and handed your device an address and the basic settings it needs to function. The second, ARP, translated that logical address into the physical hardware address of the actual machine next door, because on a local network, the IP address alone is not enough to deliver anything. And the third, ICMP, is the quiet messenger running underneath it all, carrying the errors, the diagnostics, and the humble ping that tells you whether something is even reachable.
These are the plumbing beneath the plumbing. They are rarely explained to beginners, yet they are foundational, and understanding them is a genuine step up in how clearly you see a network working. They are also, every one of them, a small lesson in the theme this series keeps returning to: each was designed for a trusting world, and each can be turned against you on a local network. Let us meet them.
DHCP: The Protocol That Gives Your Device Its Identity
When your device joins a network, it faces an immediate problem. To communicate using IP, as we learned back in Post 4 IP Addressing and Subnetting: Every Device Needs an Address, it needs an IP address. But it does not have one yet, and it cannot just invent one, because it might collide with another device, and it would not know the correct settings for this particular network anyway. It needs to be told. That telling is the job of DHCP, the Dynamic Host Configuration Protocol.
DHCP is what automatically assigns your device its IP address, along with the other essentials it needs to work: the subnet mask (which tells it the shape of the local network), the default gateway (the router that leads out to the wider internet), and the DNS server addresses (the phone book from Post 5 DNS: The Internet's Phone Book, and Its Biggest Weakness). Without DHCP, every device on every network would have to be configured by hand, a task that is tedious on a home network and utterly impossible at the scale of a company or a city. DHCP makes joining a network effortless and automatic, which is exactly why you have never had to think about it.
The way a device and a DHCP server negotiate is a four-step exchange with a memorable name: DORA, for Discover, Offer, Request, Acknowledge. It is worth walking through, because it is a small, elegant conversation.
Discover. Your device has just joined and has no address, so it cannot send a message to any specific destination. Instead, it shouts to the entire local network with a broadcast, a message addressed to everyone at once, essentially asking: "Is there a DHCP server out there? I need an address." Because it has no address of its own yet, it sends this from a blank source, and because it does not know where any server is, it addresses it to everyone.
Offer. Any DHCP server on the network hears the shout and responds with an offer. The offer proposes an available IP address for the device to use, along with the subnet mask, gateway, DNS servers, and how long the address may be kept. In effect: "I can give you this address, with these settings, for this long."
Request. The device may receive offers from more than one server, so it picks one, usually the first, and broadcasts a request formally accepting that specific offer. It broadcasts rather than replies privately so that any other servers that made offers can see their offer was declined and reclaim the address they had set aside.
Acknowledge. The chosen server confirms with an acknowledgement, finalising the assignment. The device may now use the address. It is configured, and it is on the network.
Notice one more thing: the address is not given forever. It is a lease, granted for a limited time, and the device must renew it periodically to keep it. This lets a network recycle addresses as devices come and go, which is essential somewhere like a cafe where hundreds of devices connect and leave every day.
The Security Shadow: Rogue DHCP Servers
Here is the catch, and it is the familiar one. When your device broadcasts "I need an address, who can help," it simply trusts whoever answers first. It has no way to verify that the responding server is legitimate. There is nothing in the basic protocol that authenticates the answer.
This opens the door to a rogue DHCP server attack. An attacker on the same network can run their own DHCP server and race to answer your device's request before the real one does. If their malicious offer wins, they get to set your device's configuration, and here is the dangerous part: they can set the gateway and the DNS server to addresses they control. Now every packet your device sends toward the internet goes through the attacker's machine first, and every name your device looks up can be answered with a lie. They have quietly placed themselves in the middle of your entire connection, before you have loaded a single page, simply by answering a trusting question faster than the honest server did. Attackers sometimes pair this with DHCP starvation, flooding the real server with bogus requests to exhaust its pool of addresses, so that theirs is the only one left able to answer.
The main defence, in managed networks, is a switch feature called DHCP snooping. The switch is told which of its ports the legitimate DHCP server lives on, and it simply refuses to allow DHCP offers from any other port. An attacker plugged into an ordinary port can shout all they like; the switch drops their offers before they ever reach a victim. It is trust, re-established by having the network infrastructure itself vouch for where the real server is.
ARP: The Translator Between Two Kinds of Address
Now your device has an IP address. But there is a subtlety that trips up almost everyone learning networking, and resolving it is the entire reason ARP exists.
An IP address is a logical address. It is not built into the hardware; it was just assigned by DHCP moments ago, and it could change tomorrow. But to actually deliver a chunk of data across the physical local network, the wires and the Wi-Fi, you need the physical address of the destination machine: its MAC address, a permanent identifier burned into its network hardware. On the local network, data is delivered to MAC addresses, not IP addresses. The IP address says who you ultimately want; the MAC address is how the local network physically hands the data over.
So there is a gap. Your device knows the IP address of the machine it wants to talk to next, often the gateway router, but it does not know that machine's MAC address. Something has to translate one into the other. That something is ARP, the Address Resolution Protocol.
ARP works with beautiful simplicity. When your device needs the MAC address for a particular IP on the local network, it broadcasts a question to everyone on the segment: "Who has this IP address? Please tell me your MAC address." Every device hears it, but only the one that actually holds that IP address answers, replying: "That is me, and here is my MAC address." Your device stores this answer in a short-term memory called the ARP cache, so it does not have to ask again for a while, and now it can finally address its data to the correct physical machine. Every local conversation your device has begins, at some point, with this little "who has this address" exchange.
The Security Shadow: ARP Poisoning
You can already see the weakness coming, because it is the same shape as all the others. When a device broadcasts "who has this IP address," it believes whatever reply comes back. ARP has no mechanism to verify that the answer is truthful. Any machine on the local network can respond, including a lying one.
This is ARP poisoning, also called ARP spoofing, and it is the classic local man-in-the-middle attack. An attacker on your network sends forged ARP replies, claiming that their MAC address corresponds to the IP address of, say, the gateway router. Your device believes it, updates its ARP cache with the poisoned entry, and now sends all its internet-bound traffic to the attacker's machine instead of the real router. The attacker typically forwards it on to the genuine gateway afterwards, so nothing appears broken, while quietly reading or altering everything that passes through. It is the postcard problem from Post 2 and the man-in-the-middle threat from Post 7, made real on the local network, and it works because ARP, like everything else in this series, was built to trust what it is told.
The defence in managed networks is Dynamic ARP Inspection. The switch inspects ARP replies and checks them against a trusted table of which MAC address genuinely holds which IP, a table it builds by watching the DHCP snooping process from earlier. If an ARP reply does not match the record, claiming a MAC-to-IP binding that was never actually assigned, the switch discards it. The two defences work together: DHCP snooping learns the truth about who has which address, and Dynamic ARP Inspection uses that truth to catch ARP liars.
ICMP: The Network's Messenger and Diagnostician
The third quiet protocol does something different from the other two. DHCP and ARP help set up communication. ICMP, the Internet Control Message Protocol, is the network's own system for reporting on communication: carrying error messages, diagnostics, and status information about how delivery is going. It is the internet's nervous system, the channel through which the network tells you when something is wrong or answers when you check whether something is reachable.
You have almost certainly used ICMP directly, perhaps without knowing it, through two famous tools.
Ping is the simplest. When you ping a server, your device sends an ICMP "echo request" message, essentially asking "are you there?" If the destination is reachable and willing to answer, it sends back an ICMP "echo reply," meaning "yes, I am here." The round trip also measures how long the exchange took, which is why ping tells you both whether a host is up and how fast your connection to it is. It is the single most basic question one machine can ask another, and it runs entirely on ICMP.
Traceroute is cleverer, and it beautifully uses ICMP together with something we learned in the routing post. Recall that every IP packet carries a time-to-live counter that each router decrements, and when it hits zero, the packet is discarded to prevent it looping forever. When a router discards a packet this way, it sends back an ICMP "time exceeded" message to the sender. Traceroute exploits this deliberately: it sends packets with a time-to-live of 1, which expires at the very first router, which then reports back via ICMP, revealing itself. Then it sends packets with a time-to-live of 2, revealing the second router, and so on. Step by step, it maps out every hop along the path to a destination, which is exactly the hop-by-hop journey we described in Post 9, made visible. Traceroute is, in effect, ICMP error messages turned into a mapping tool.
Beyond these, ICMP carries genuinely important error signalling. When a destination is unreachable, or a network problem prevents delivery, ICMP is how that failure is reported back. One especially important role is in a process called Path MTU Discovery, which lets machines work out the largest packet size a path can carry, and which relies on specific ICMP messages to function correctly.
The Security Shadow: Reconnaissance and Abuse
ICMP's security story is a little different from the other two, and more nuanced. Its danger is less about impersonation and more about information and misuse.
Because ICMP so readily tells you what is reachable and how the network is shaped, it is a gift to attackers doing reconnaissance, the scouting phase before an attack. By pinging across a range of addresses, an attacker can map out which machines on a network are alive. By using traceroute, they can learn the topology, the routers and paths that make up your network, information that helps them plan a later attack. ICMP was built to be helpful, and that helpfulness extends to helping attackers understand your network.
ICMP has also been abused to carry attacks directly. In classic denial-of-service techniques, attackers flood a target with ICMP traffic to overwhelm it, and in an older amplification attack known as the Smurf attack, they sent ping requests with the victim's address forged as the source to a whole network at once, so that every machine replied to the victim simultaneously, burying it, the same spoofing-and-amplification pattern we saw with UDP back in Post 6 TCP vs UDP: Reliability or Speed, the Choice Every Connection Makes.
Now, the honest and important nuance, because this is where a lot of well-meaning advice goes wrong. Because ICMP can be abused, some people conclude the safe move is to block all ICMP entirely. This is usually a mistake. ICMP carries messages that are essential to the network working correctly, and the Path MTU Discovery mentioned earlier is the clearest example: block the wrong ICMP messages and you break connections in strange, hard-to-diagnose ways. The correct approach, the one this series keeps arriving at, is not blunt blocking but proportionate control: rate-limiting ICMP so it cannot be used to flood, filtering it thoughtfully at the network edge to limit outside reconnaissance, while still allowing the types the network needs to function. Nuance beats the sledgehammer. Blocking all ICMP is the network equivalent of unplugging the smoke alarms because you dislike the noise.
Commands to See It Yourself
All three protocols are easy to observe on your own machine, and doing so makes them concrete.
See your DHCP-assigned configuration:
ip address (Linux: shows your assigned IP addresses)
ipconfig /all (Windows: shows IP, gateway, DNS, and DHCP lease details)
Look for your IP address, your default gateway, and your DNS servers. Every one of those was handed to you by DHCP through the DORA exchange.
See your ARP cache, the IP-to-MAC translations your device has learned:
ip neigh (Linux: the modern command)
arp -a (Windows and macOS)
Each line pairs an IP address with the MAC address ARP resolved for it. You are looking at the little translation table that makes local delivery possible. The entry for your gateway is the one an ARP-poisoning attacker would try to corrupt.
Use ICMP directly:
ping example.com (send echo requests, watch the replies and timing)
traceroute example.com (Linux/macOS: map the hops to a destination)
tracert example.com (Windows)
With ping, you are sending the echo requests described above and watching the replies come back. With traceroute, you are watching the ICMP time-exceeded trick reveal each router on the path, one hop at a time.
What You Now Understand
You started with a simple, overlooked question, what actually happens in the moment you join a network, and you now know the three quiet protocols that do the groundwork.
You understand DHCP, which hands a newly joined device its IP address and essential settings through the four-step DORA exchange of Discover, Offer, Request, and Acknowledge, granting it as a lease that must be renewed. You understand ARP, which bridges the gap between the logical IP address and the physical MAC address that local delivery actually requires, by broadcasting "who has this address" and trusting the reply. And you understand ICMP, the network's messenger, carrying the errors and diagnostics and powering the everyday tools of ping and traceroute, the latter cleverly turning the time-to-live mechanism from the routing post into a map of the path.
And you understand, once again, the theme this series will not stop finding, because it is genuinely everywhere: each of these protocols trusts what it is told. DHCP trusts whoever answers first, so a rogue server can hand you a poisoned configuration. ARP trusts any reply, so a poisoned cache can route your traffic through an attacker. ICMP is so helpful it aids reconnaissance and can be turned to flooding, though the wise response is proportionate control rather than blunt blocking. The defences, DHCP snooping and Dynamic ARP Inspection working hand in hand, and thoughtful ICMP rate-limiting, all share one idea: since the protocols themselves cannot verify truth, the network infrastructure must vouch for it on their behalf.
These three are the plumbing beneath the plumbing, and you can now see them working every time you connect to anything.
In the next post, we turn to a protocol you have probably heard of but likely misunderstood, and one that promises to protect you: the VPN. We will look at what a VPN actually is beneath all the marketing, what tunnelling really means, what a VPN genuinely protects, and, just as honestly, what it does not. That is Post 11.
This is Post 10 of the Networking Foundations series. If DHCP, ARP, and ICMP have gone from mysterious acronyms to protocols you can picture working, share it with someone who has always wondered what really happens when they join a network. New here? Start with Post 1, and Post 9 on routing and BGP leads into this one. Subscribe to our newsletter to get each new post as it publishes.
Comments