JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

ARP and DHCP: How a Device Joins a Network

You plug in a laptop and, within a second, it just works — it has an address, it can reach the gateway, it can browse. No human typed anything. Two quiet helper protocols pulled that off: DHCP hands the newcomer its settings, and ARP finds the hardware address behind an IP. Here is exactly how a stranger becomes a full member of the LAN.

Two addresses, two different jobs

By now this rung has built you a working LAN: an Ethernet frame carries data hop by hop, a switch learns where everyone sits and forwards frames only to the right port, and a VLAN can carve one switch into several logical LANs. But a quiet puzzle has been hiding under all of it. Every device has two completely different addresses, living at two different layers, and nothing we have seen yet explains how they connect.

The first is the MAC address, a 48-bit number like a0:b1:c2:d3:e4:f5 burned into the network card at the factory. It belongs to the link layer, and it is what a switch reads to deliver a frame on the local wire. Think of it as a permanent serial number stamped on the back of the device — globally unique, but it tells you nothing about where the device is in the world. The second is the IP address like 192.168.1.42, which belongs to the network layer and is handed out based on which network you are plugged into. The IP is the postal address; the MAC is the name engraved on the mailbox.

Here is the crunch. When your laptop wants to send a packet to 192.168.1.1, the software knows the destination IP, but the switch on the wire does not care about IP at all — it only forwards frames addressed to a MAC. So to actually put the packet on the LAN, your laptop must first answer one question: which MAC address belongs to 192.168.1.1? That single translation, from a network-layer address down to a link-layer address, is the entire job of ARP. And the prior question — how did your laptop get a usable IP and learn that 192.168.1.1 even exists — is the job of DHCP.

DHCP: getting handed your settings on arrival

A brand-new device on the LAN knows nothing: no IP address, no idea what range of addresses is local, no idea where the way out is. It is like a guest arriving at a big hotel with no room key and no map. DHCP, the Dynamic Host Configuration Protocol, is the front desk that hands the guest everything they need in one short exchange — typically an IP address to use, the subnet mask that says which addresses count as local, the gateway address that is the door to the rest of the world, and the address of a DNS server.

But there is a chicken-and-egg problem the front-desk analogy hides. The newcomer cannot send a normal message to the DHCP server, because it does not yet have an IP address to send from, and it does not know the server's address either. The trick is to shout to everyone at once. The device sends its first message as a link-layer broadcast — a frame addressed to ff:ff:ff:ff:ff:ff, the special MAC that means everyone on this LAN. Because the request is a broadcast, it reaches every device in the broadcast domain, and the DHCP server, sitting somewhere in that domain, is the one that answers.

  1. DISCOVER — the new device broadcasts "is there a DHCP server out there? I have nothing." The frame goes to everyone because the device has no idea who to ask.
  2. OFFER — one or more DHCP servers reply, each proposing an address it could lend, plus the mask, gateway, and DNS server that go with it.
  3. REQUEST — the device picks one offer and broadcasts "I'll take that one," which also tells any other servers their offers were declined.
  4. ACK — the chosen server confirms with the final settings and a lease — a time limit, after which the address must be renewed or it returns to the pool.

ARP: finding the MAC behind an IP

Now your laptop is configured: it has the IP 192.168.1.42, the mask 255.255.255.0 (a /24, so the local network is 192.168.1.0/24), and a gateway at 192.168.1.1. Say you open a web page. The software builds an IP packet aimed at some distant server, but the first physical step is to send that packet to the gateway, 192.168.1.1, because the destination is not on the local network. To put a frame on the wire, the laptop needs the gateway's MAC address — and it does not have it. This is the exact moment ARP fires.

ARP uses the same shout-to-everyone trick as DHCP. The laptop broadcasts an ARP request: a frame to ff:ff:ff:ff:ff:ff that effectively asks, "Whoever has 192.168.1.1, please tell me your MAC address." Every device in the broadcast domain hears it, but only the one that actually owns 192.168.1.1 — the gateway — replies, and crucially it replies directly, as a normal unicast frame straight back to the laptop, not a broadcast. The reply carries the answer: "192.168.1.1 is at MAC a0:b1:c2:d3:e4:f5."

Laptop wants to reach the gateway 192.168.1.1 but has no MAC for it.

  Request  (broadcast to ff:ff:ff:ff:ff:ff):
      "Who has 192.168.1.1? Tell 192.168.1.42"

  Reply    (unicast straight back to the laptop):
      "192.168.1.1 is at a0:b1:c2:d3:e4:f5"

  Laptop's ARP cache now holds:
      192.168.1.1  ->  a0:b1:c2:d3:e4:f5   (expires in a few minutes)

Next packets to the gateway skip ARP entirely -- the answer is cached.
An ARP exchange: one broadcast question, one unicast answer, then the IP-to-MAC mapping is cached so the question is asked rarely, not on every packet.

The laptop stores that mapping in its ARP cache, a small table of recently learned IP-to-MAC pairs, each with a short timeout. With the gateway's MAC now in hand, the laptop wraps its IP packet in an Ethernet frame addressed to a0:b1:c2:d3:e4:f5 and hands it to the switch, which forwards it using exactly the MAC-learning table you met two guides ago. From here on, packets to the gateway reuse the cached MAC and skip ARP — until the cache entry expires and the question gets asked afresh.

Local or remote? The one decision that drives everything

There is a small but vital decision your laptop makes before every send, and it is what ties the IP and the mask together. Given a destination IP, the laptop uses its subnet mask to ask one local-or-remote question: is this address on my own local network, or out beyond it? With a /24 mask, the first 24 bits are the network part. The laptop compares the network part of the destination against its own. If they match, the destination is a neighbour on the same LAN; if they differ, it is remote and must go via the gateway.

Walk it through with the laptop at 192.168.1.42 on a /24. A packet to 192.168.1.99 shares the same first three octets (192.168.1), so it is local — the laptop ARPs directly for 192.168.1.99 and frames the packet to that neighbour's own MAC. A packet to 8.8.8.8 does not match 192.168.1 at all, so it is remote — the laptop ARPs for the gateway and frames the packet to the gateway's MAC, even though the IP inside the packet still says 8.8.8.8. That is the key subtlety: the IP destination stays the final server, but the frame's MAC destination is only the next hop.

Why broadcast helpers are powerful — and where they bite

Step back and notice the shared pattern. Both DHCP and ARP solve a bootstrapping problem — needing to talk to someone whose address you do not yet know — by the same elegant move: broadcast to everyone, and let the one device that can answer do so. This is exactly why the broadcast domain from guide 3 matters so much here. ARP and DHCP only reach as far as a broadcast travels, and a plain switch passes broadcasts along, so one big flat LAN is one big pool where these helpers work. That is also why splitting a LAN with VLANs splits the broadcast domain: each VLAN needs its own DHCP reach and confines its own ARP chatter.

The same power is also the weakness, and this is the honest part. ARP was designed in a trusting era and has no authentication whatsoever. When that unicast reply comes back saying "192.168.1.1 is at this MAC," nothing checks that the replier actually owns 192.168.1.1. An attacker on the same LAN can simply send forged replies claiming the gateway's IP belongs to the attacker's MAC, and victims will dutifully send their traffic to the wrong machine. This is ARP spoofing, and it is the basis of many on-path attacks. The lesson is the recurring one of this whole subject: a mechanism that proves reachability does not prove identity.

Two more honest caveats. First, ARP belongs to IPv4; IPv6 retires it and uses a related but separate Neighbor Discovery mechanism instead, so do not assume ARP is universal. Second, DHCP is convenience, not security either — a rogue DHCP server on your LAN can hand out a poisoned gateway or DNS address and quietly route you through itself. Both protocols are the unglamorous plumbing that makes plug-and-play networking feel like magic, and both remind us that early Internet protocols optimised for getting things working among trusted peers, leaving security to be bolted on later, higher up the stack.