MAC vs IP: Two Addresses, One Delivery

MAC vs IP: Two Addresses, One Delivery

What you'll learn

• Dissect a MAC address into its two halves — manufacturer OUI and device identifier — and explain why neither half names a network
• Contrast link-layer and network-layer addressing with the book's classic two-address analogy
• Find any machine's MAC address from the command line on Windows and Linux
• Explain the ARP request/reply exchange and read an ARP cache with arp -a / ip neigh
• State what changed since the book: MAC randomization on modern Wi-Fi clients, and the three things it quietly breaks

This lesson builds on two chapters of Dr. Tahseen Al-Doori's Network Essentials: Chapter 6 supplies the MAC address itself — structure, OUI, discovery commands — and Chapter 10 supplies ARP, along with the analogy this lesson retells. One update from 2026 practice, MAC randomization, gets its own section near the end.

Why one delivery needs two addresses

Module 2 planted the fact; this lesson explains it. When your machine sends a packet anywhere, the packet carries IP addresses end to end — but the frame wrapping it carries MAC addresses that change at every hop. Two complete addressing systems, running in parallel, on every single transmission. Why would networking keep both?

A classic analogy from Dr. Al-Doori's course untangles it. Think of a MAC address as a person's national ID number: it identifies exactly one person, uniquely, for life — but it tells you nothing about where they are. You cannot deliver a parcel to "ID 4471-8830-2." An IP address, by contrast, works like a postal address: the street name (the network part, from last lesson) narrows the world down to one street, and the house number (the host part) picks the building. Postal addresses are built for finding — every element carries location. ID numbers are built for identifying — no element carries location at all.

Networks need both talents. Routing needs location, so routers steer by IP's network part — that is precisely what last lesson's filter reveals. But final, physical delivery on the local network needs certain identification of one interface among the machines sharing the wire or the airwaves — and that is the MAC address's job. There is a subtlety in the analogy worth keeping: a house number alone isn't globally unique (every street has a number 12), and likewise a host part alone isn't unique across networks — only the full IP address is, and only inside its network's context. The MAC address carries its uniqueness in itself, context-free, which is what makes it the reliable endpoint for the last, local step.

Could routers steer by MAC instead, and let us keep one address system? No — and now you can say why with precision: a MAC address has no network part. Nothing in it groups devices by location; two sequential MACs may sit on opposite sides of the planet. Without a network part there is nothing to filter, nothing to summarize, no "street" for a router to aim at — a router would need a table entry for every individual device on Earth. The two-address design isn't redundancy; it is a division of labor.

Anatomy of a MAC address

A MAC address (Media Access Control address) is 48 bits — six octets — written as twelve hex digits, usually in pairs: 3C-52-82-1A-BC-0D on Windows, 3c:52:82:1a:bc:0d on Linux and in Wireshark; you'll also meet a dotted four-digit grouping on network equipment. Same 48 bits, three costumes — your binary lesson makes them all transparent.

The address splits exactly in half, and each half has an owner:

• First three octets — the OUI (Organizationally Unique Identifier): a prefix assigned to a hardware manufacturer by the IEEE, the standards body that administers the space. 3C-52-82 identifies one specific company when that company bought a full-size block (IEEE calls it MA-L). The IEEE also sells smaller blocks — MA-M and MA-S — whose first three octets belong to the IEEE itself and are shared among many assignees, with 28 or 36 bits needed to name the maker. So the first three octets usually identify a manufacturer; a vendor lookup that answers "IEEE Registration Authority" means you are looking at one of the small blocks.
• Last three octets — the device identifier: assigned by that manufacturer, uniquely within its OUI, to each interface it produces.

IEEE-assigned prefix plus manufacturer-assigned serial makes the combination globally unique — one address per network interface, set at the factory. That factory address is stored in the card's hardware, which earns it the nickname burned-in address (BIA); you will also hear physical address (Windows' label for it), Ethernet address, or hardware address — four names, one thing. Note that it identifies an interface, not a computer: a laptop with Wi-Fi and an Ethernet port has two MAC addresses.

Because the OUI is public registry data, the first half of a MAC is readable intelligence: Wireshark translates OUIs into vendor names automatically, which is why your Module 2 capture showed frames from "Intel" or "Apple" devices. It's a genuinely useful trick — identifying mystery devices on a network by manufacturer — with a modern caveat coming later in this lesson.

One special value completes the picture, an old friend from Module 2: ff:ff:ff:ff:ff:ff, all 48 bits on, is the broadcast address — a frame addressed to it is delivered to every interface on the local network. Hold that thought; it's about to star in ARP.

Finding your MAC address

Chapter 6 makes discovery a skill of its own, and it remains one — you'll need a machine's MAC when registering devices, chasing DHCP issues, or matching a capture to a computer. The modern command set:

• Windows: ipconfig /all — the Physical Address line under each adapter (you recorded this in the last lab). Quicker and script-friendlier: getmac /v, which lists each adapter's MAC in one table.
• Linux: ip link — each interface's link/ether line. (Older texts, our book included, teach ifconfig -a; it still exists on many systems but is legacy — the ip suite replaced it.)
• Anything with a screen: phones, printers and TVs show their MAC under network or "about" settings — worth knowing, since most devices on a modern network have no command line at all.

Run one of these now on your machine and dissect what you see: first six hex digits OUI, last six the device id. If curiosity strikes, an OUI lookup site will name your hardware's manufacturer from those first digits.

ARP: the introduction service

Now assemble the pieces into the problem every sender faces. Your machine wants to deliver a packet to 192.168.1.7 — a printer on its own network (the filter test from last lesson says: local, deliver directly). Delivery means building a frame, and a frame needs a destination MAC. Your machine knows the printer's IP. It does not know its MAC. Nothing in 192.168.1.7 reveals it — the two address systems are unrelated by design.

The bridge is the Address Resolution Protocol (ARP) — one of TCP/IP's oldest members (RFC 826, from 1982) and among its simplest. It is a two-line conversation:

1. Request, shouted: your machine sends a frame to the broadcast address ff:ff:ff:ff:ff:ff, carrying the question: Who has 192.168.1.7? Tell 192.168.1.23. Every device on the local network receives it — broadcast is the only option, since the whole point is that the target's MAC is unknown.
2. Reply, whispered: every device checks the asked-for IP against its own; all but one stay silent. The printer answers with a unicast frame straight back to your MAC: 192.168.1.7 is at a4:77:33:9b:12
   .

Your machine can now address frames to the printer, and the delivery proceeds. Total cost: one broadcast, one reply, a few milliseconds — but paying it before every frame would be absurd. So your machine memorizes the answer in its ARP cache: a small in-memory table of recent IP-to-MAC resolutions. Next packet for the printer, the cache answers instantly; no broadcast. Entries expire after a few minutes without use — deliberately, because IP-to-MAC pairings change (a device gets a new DHCP lease; a NIC is replaced), and a stale answer would misdeliver frames. Forgetting is a feature.

You can read the cache yourself — this lesson's lab does exactly that:

• Windows: arp -a — the current mappings, listed per interface as Internet Address / Physical Address, marked dynamic (learned by ARP, will expire) or static.
• Linux: ip neigh — same content, with liveliness states like REACHABLE and STALE. (arp -a also works where the legacy toolset is installed.)

Two refinements complete the picture. First, the case you'll see most: the destination is remote — some server across the world. Module 2 told you the frame goes to your default gateway; now you know the mechanism behind it. Your machine runs last lesson's filter test, concludes "not my network," and therefore ARPs for the gateway's IP — the far server's MAC is never needed, never asked for, and never appears in your cache. The busiest entry in any ARP cache is the gateway's, which is also why it's almost always already there: you use it constantly. Second, a note to file for Module 7: ARP has no security whatsoever — any device may answer any request, and machines believe what they hear. Lying in ARP replies (ARP spoofing) is a classic attack for intercepting a neighbor's traffic, and it works precisely because the protocol was designed for a friendlier decade. Module 7 returns to it.

How IPv6 does it: a forward pointer

File one paragraph for this module's final lesson. IPv6 abolishes broadcast entirely — no more shouting to every device — so ARP could not survive the transition. Its replacement is the Neighbor Discovery Protocol (NDP), which performs the same introduction service with better manners: a Neighbor Solicitation is sent not to everyone but to a narrow multicast group (remember 224–239 from last lesson? IPv6 leans on multicast heavily) that mathematically must include the target, and the target's Neighbor Advertisement completes the exchange. Same question, same caching idea, quieter network. When you meet NDP in the IPv6 lesson, recognize it as ARP's polite successor.

From the textbook to 2026: when MAC addresses started lying

Chapter 6 states, correctly for its era, that a MAC address is a globally unique, factory-assigned, persistent identifier of a device on the network. For wired Ethernet that remains true today: your desktop's NIC still presents its burned-in address (current). For Wi-Fi client devices, it quietly stopped being true — and a technician who doesn't know this will chase ghosts.

What changed. Precisely because MACs were unique and persistent, they became tracking beacons: a phone probing for Wi-Fi announces its MAC, so shops, airports — anyone with a sensor — could log a device's comings and goings across locations, no login required. The platform vendors responded in the OS: iOS 14 (2020) and Android 10 (2019) made MAC randomization the default for Wi-Fi (modern replacement for the always-burned-in world). The phone generates a random "private" MAC per Wi-Fi network and presents that instead of the hardware address. Since iOS 18, iPadOS 18 and macOS Sequoia, Apple exposes three per-network settings — Off, Fixed and Rotating — defaulting to Fixed on WPA2-or-stronger networks and to Rotating (a fresh private address roughly every two weeks) on open or weakly secured ones. Android 12+ can also re-randomize per connection when an app or an open-network policy asks for it, and Windows offers randomization as an opt-in toggle. Billions of client devices now introduce themselves with software-invented addresses. You can even spot them: randomized MACs flag themselves in the address's marker bit for "locally administered," which surfaces as a second hex digit of 2, 6, A or E — and their "OUI" matches no manufacturer, which is why phone entries in Wireshark increasingly show no vendor name.

What it breaks. Every practice built on "the MAC persistently identifies the device":

• MAC filtering — allow-lists of approved MACs on a Wi-Fi router. Already weak security (an attacker can copy an approved address), it now also fails operationally: a phone that changes its private MAC looks like a stranger and gets locked out. Be precise about when that happens, because it is rarer than the headline suggests — on a WPA2-or-stronger network Android derives its private address from the network profile and keeps it until a factory reset, and Apple defaults to Fixed. The breakage clusters around specific events: a rule keyed to the hardware MAC, a network-settings reset or a forced "forget this network", Apple's Rotating setting on open networks, and Android's opt-in per-connection mode.
• DHCP reservations — "always give this MAC address 192.168.1.50." Key one to a hardware MAC a wireless client no longer presents, or to a private MAC the device later regenerates, and the device drifts to a different address while everything pointing at the old one breaks. (Enrol the private MAC on a secured network and the reservation holds — which is the practical fix.)
• Device recognition in general — captive portals that "remember" paid devices, parental controls keyed to a child's tablet, network inventory tools, and the vendor-name trick from earlier: all now see a device that changes its face per network or per connection.

What to do about it. Know that every mainstream OS allows the randomization to be turned off per network (Apple calls the feature Private Wi-Fi Address; Android offers "use device MAC" per network). The professional pattern in 2026: leave randomization on for public networks — it is genuinely good privacy — and switch a device to its hardware MAC on your own network when a DHCP reservation or device recognition depends on it. The deeper lesson for your engineering instincts: the book's claim didn't become false because the book erred — it became false because the world moved, trading identification convenience for privacy. Networking is full of such trades; this is your first, not your last.

Lab: Watch ARP work

Objective. Read your ARP cache, force a fresh ARP exchange, capture the request and reply in Wireshark, and confirm the cache learned the answer — the full life of one resolution, observed end to end.

Setup.

• Your machine on its normal network, Wireshark installed (Module 2 lab). You'll need your default gateway's IP address (previous lesson's lab) and your own IP and MAC.
• Have two terminal windows open: one for commands, plus Wireshark.

Steps.

1. Display the cache: Windows arp -a, Linux ip neigh. Find your gateway's IP in the list and note its MAC — as just discussed, it is almost certainly present.
2. Force the next step to need ARP, choosing one path:
   • Path A (flush the cache — needs admin rights): Windows, in an elevated prompt: arp -d *. Linux: sudo ip neigh flush all. The table empties; your machine has amnesia.
   • Path B (no admin needed): pick a device on your network not in the cache — a phone or printer's IP from its settings screen — and use that instead of the gateway in step 5.
3. Start a Wireshark capture on your active interface. In the display filter bar, type arp and press Enter — the flood from Module 2 reduces to only ARP frames.
4. Wait a few seconds so startup chatter passes.
5. In the terminal, ping <gateway-ip> (or your Path B target).
6. Stop the capture after the ping completes. You should see a pair of ARP frames (more pairs are normal — other devices ARP constantly; find yours by your IP).
7. Click the request: Info column reads like Who has 192.168.1.1? Tell 192.168.1.23. In the detail pane, expand Ethernet II: destination ff:ff:ff:ff:ff:ff — a broadcast, exactly as taught. Expand the ARP block: sender and target IP and MAC fields — note the target MAC is all zeros, the blank the reply will fill.
8. Click the reply: Info reads like 192.168.1.1 is at a4:77:33:9b:12:e5. In Ethernet II, the destination is now your MAC — a unicast whisper, not a shout.
9. Display the cache again (arp -a / ip neigh): the target's entry is present (again), and its MAC matches the reply you captured, digit for digit.

Expected result. One broadcast request, one unicast reply, and a cache entry born (or reborn) from them — the two-line conversation plus its memory, all on your screen.

Verify. You can point at: the broadcast destination in the request frame; the question and answer in the two Info lines; the matching MAC in your cache listing. Bonus check: the reply's answering MAC begins with an OUI — does Wireshark name the vendor of your gateway (usually the router maker)? If it shows no vendor and a second hex digit of 2, 6, A or E, you've caught a randomized address in the wild.

Questions.

1. Why must the request be a broadcast, while the reply can be unicast?
2. Ping the same target a second time and capture again: no new ARP appears. Why not?
3. Your capture probably also shows ARP requests from other devices for addresses that aren't yours. Why does your machine receive these at all — and what does it do with them? (Think back to Module 2: which frames does a switch send to everyone?)
4. If you ping a website instead of the gateway, whose MAC ends up in the ARP conversation — and whose never appears anywhere?

(Answers: 1 — the asker doesn't know the target's MAC yet — that's the whole question — so only the everyone-address can reach it; the replier learned the asker's MAC from the request, so it can answer directly. 2 — the cache answers instantly; ARP runs only on a miss. 3 — requests are broadcast frames, and switches deliver broadcasts out every port; your machine reads the question, sees the IP isn't its own, and stays silent. 4 — only your default gateway's: the destination is off-network, so the frame's first hop is the gateway; the web server's MAC never crosses your network at all.)

If it goes wrong.

• No ARP frames in the capture. The cache already held the target (Path B target was cached, or the flush didn't run — check for admin rights). Flush again or pick a device you've never contacted, and keep the capture running before you ping.
• ip neigh prints nothing on Linux. An empty or expired table — not an error. Ping the gateway and rerun; the entry appears.
• The ping itself fails but ARP worked. Perfectly informative: resolution succeeded (the cache has the MAC) but the target doesn't answer pings — many phones and printers don't. For this lab, the ARP exchange is the result; the ping was only bait.
• Wireshark shows nothing at all. Revisit the Module 2 lab's fixes (wrong interface, missing capture driver/permissions); the setup here is identical.

Reset/cleanup. Nothing persistent changed. A flushed ARP cache refills itself within moments of normal use — forgetting and relearning is the cache's daily life. Delete the capture file unless you want to keep it; as always, treat captures as private documents.

Check yourself

1. Dissect 3C-52-82-1A-BC-0D: which octets did the IEEE assign, which did the manufacturer assign, and which part — if either — names the network the device sits on?
2. A help-desk colleague runs arp -a on a healthy machine and finds the default gateway listed with a MAC address. Ten minutes of screen-lock later, the entry is gone. Explain both observations in one sentence each.
3. An office pins a DHCP reservation to an employee's phone so it always gets 10.0.0.50. It works for months, then the phone starts receiving random addresses after a software update. Diagnose the likely cause and name two possible fixes.
4. Interviewer special: "Why can't routers just forward by MAC address and skip IP entirely?" Answer in two sentences using this lesson's vocabulary.
5. In a capture you find an ARP reply claiming 192.168.1.1 is at 66:20:9b:41:07:c2, but your gateway's real MAC (printed on the router) is different. Give an innocent explanation and a hostile one, and say which module handles the hostile case.
6. True or false, with the 2026 nuance: "The MAC address uniquely and persistently identifies a device on the network."

Answers

1. 3C-52-82 (first three octets) is the OUI, assigned to the manufacturer by the IEEE; 1A-BC-0D (last three) is the device identifier the manufacturer assigned. Neither part names a network — a MAC carries identity only, which is exactly why it cannot be routed and why IP exists alongside it.
2. The entry existed because the machine had recently resolved the gateway (its most-used ARP target); it vanished because cache entries expire after a few minutes without traffic — forgetting is deliberate, keeping the cache honest against changed pairings.
3. The phone's OS is presenting a randomized Wi-Fi MAC (default on iOS 14+/Android 10+; the update likely re-enabled or re-randomized it), so it no longer matches the MAC the reservation is keyed to. Fixes: set the phone to use its device MAC for that network (Private Wi-Fi Address off / "use device MAC"), or re-key the reservation to the address the phone now presents (accepting it may change again on Android's re-randomization).
4. A MAC address contains no network part — its two halves are manufacturer and serial, neither carrying location — so there is nothing to aggregate and a MAC-based router would need an entry per device on Earth. IP's network/host split gives routers a summarizable "street" to steer by; MAC then covers the final local hop.
5. Innocent: the router was replaced or its Wi-Fi interface uses a different MAC than the label (labels often show one of several interfaces). Hostile: another device is answering ARP requests with lies — ARP spoofing — to pull your traffic through itself; ARP believes anyone. Module 7 (network security) handles the hostile case.
6. True for wired interfaces (burned-in addresses remain the default), false for modern Wi-Fi clients: iOS 14+/Android 10+ randomize per network by default (Android 12+ can rotate further), so the presented MAC is neither persistent nor tied to hardware. Any design leaning on MAC permanence must now say which kind of device it means.

Key terms

• MAC address — the 48-bit link-layer identifier of a network interface, written as twelve hex digits; delivers frames on the local network.
• OUI (Organizationally Unique Identifier) — the IEEE-assigned first three octets of a MAC, naming the manufacturer.
• Device identifier — the manufacturer-assigned last three octets, unique within the OUI.
• Burned-in address (BIA) — the factory MAC stored in the card's hardware; also called physical/hardware/Ethernet address.
• Broadcast MAC (ff:ff:ff:ff:ff:ff) — the all-ones destination delivered to every local interface; ARP's megaphone.
• ARP (Address Resolution Protocol) — the request/reply protocol resolving an IPv4 address to a MAC on the local network (RFC 826).
• ARP cache — the short-lived table of learned IP-to-MAC pairs; read with arp -a (Windows) or ip neigh (Linux).
• ARP spoofing — answering ARP requests with lies to intercept traffic; possible because ARP trusts any reply (Module 7).
• NDP (Neighbor Discovery Protocol) — IPv6's multicast-based replacement for ARP (this module's IPv6 lesson).
• MAC randomization — modern client OSes presenting software-generated Wi-Fi MACs per network (default since iOS 14/Android 10); breaks MAC-keyed filters, reservations and tracking.
• Locally administered address — a MAC set by software rather than the factory; randomized addresses are marked as such (second hex digit 2, 6, A or E).

Summary

• One delivery, two addresses: IP carries location (network + host) for routing end to end; MAC carries pure identity for the final local hop — the book's national-ID versus postal-address contrast.
• A MAC is six octets: IEEE-assigned OUI plus manufacturer-assigned device id — globally unique at the factory, and containing no network part, which is why MACs cannot be routed.
• Discovery commands: ipconfig /all / getmac /v on Windows; ip link on Linux (ifconfig is legacy).
• ARP turns a known IP into a needed MAC: broadcast question, unicast answer, cached result — and caches expire on purpose.
• For off-network destinations, machines ARP for the default gateway; the remote host's MAC never appears on your network.
• ARP trusts anyone, which Module 7 will exploit and defend; IPv6 replaces ARP with the multicast-based NDP.
• Since the book: Wi-Fi clients randomize MACs by default (iOS 14+/Android 10+), breaking MAC filters, DHCP reservations and device tracking — persistent MACs now hold only for wired interfaces and opted-out devices.

Next lesson

Addressing is now complete: bits, addresses, masks, and the two-address delivery team. Time to put the mask to work as a design tool — slicing one network into many. Subnetting begins, and with it the arithmetic this module has been training you for.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 6 and 10 — MAC structure and discovery; ARP, the cache, and the two-address analogy retold above.
• RFC 826, "An Ethernet Address Resolution Protocol" — https://www.rfc-editor.org/info/rfc826/ — ARP's original, remarkably readable specification.
• Apple Platform Security, "Privacy features when connecting to wireless networks" — https://support.apple.com/guide/security/privacy-features-connecting-wireless-networks-secb9cb3140c/web — first-party documentation of Private Wi-Fi Address behavior.
• Wireshark Wiki, "SampleCaptures" — https://wiki.wireshark.org/SampleCaptures — practice captures (including ARP exchanges) if you want more traffic to dissect than your own network offers.
• Microsoft Learn, "ipconfig" — https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig — reference for the discovery commands used here.