From LAN to the Internet: Why MAC Addresses Alone Are Not Enough

In the previous two articles, we built a complete picture of LAN communication: devices identify themselves by MAC addresses, data is encapsulated into Ethernet frames, switches forward based on destination MAC, and ARP resolves IP to MAC. Within a Wi-Fi covered room, this mechanism works flawlessly.

But did you notice a critical detail from the ARP article? When the target is outside your local LAN, your computer queries the gateway's MAC, not the remote server's. The data packet is then handed to the router, which "takes over" the delivery.

There is a major watershed moment here: the moment a data packet leaves the LAN, the entire communication system built on MAC addresses and switches reaches its limit. The core question this chapter answers is — why? And what does the Internet use in its place?

• What defines the boundary of a LAN, and why data frames can't "walk out"
• Three fundamental limitations of MAC addresses at Internet scale
• The essential difference between switches and routers
• A layered mental model: two addressing systems, each with a distinct job
• Conceptual preparation for the next article on IP address internals

• Understanding of MAC addresses, Ethernet frames, and how switches work

• Understanding of the ARP request-reply mechanism

Imagine you're at home, your laptop connected to the router via Wi-Fi. You ping your phone:

No problem, instant reply. This is expected — your phone is on the same LAN, an ARP broadcast quickly gets its MAC, and the Ethernet frame delivers directly.

Then you type:

You get a reply. But this time, GitHub's server is across the ocean. Your ARP broadcast cannot cross the Pacific. The switch's MAC address table certainly doesn't have an entry for GitHub's server. So:

How does the data actually "get out"? Where is the boundary of the LAN? Why can't MAC addresses and switches deliver data directly to GitHub?

To understand why data can't "walk out," we first need to understand exactly where the LAN boundary lies.

In earlier articles, we mentioned that when a switch encounters an unknown destination MAC, it performs flooding — copying the frame to all ports. ARP requests also rely on broadcast frames (destination MAC FF:FF:FF:FF:FF:FF) so that all devices on the LAN can receive them. This means: as long as two devices can receive each other's broadcast frames, they are on the same LAN.

Network engineering has a precise term for this — Broadcast Domain: all devices that can receive the same broadcast frame form a broadcast domain. One broadcast domain equals one LAN.

So what "cuts off" a broadcast domain? The router.

Each router interface connects to a different network. It does not forward broadcast frames from one broadcast domain to another. The ARP broadcast frame you send from home stops at the router. The router is not a "stronger switch" — it is a boundary between two networks.

This explains a key conclusion from the ARP article: you cannot use ARP to query a remote server's MAC address, because the broadcast frame simply cannot reach the network where that remote server lives. The communication capability of a LAN stops at the router.

A Quick Aside: How Does Your Computer Know the Gateway IP?

You may have noticed that in both previous articles, we casually used the gateway IP 192.168.1.1 as if your computer just knows it. In reality, that address is obtained automatically via DHCP (Dynamic Host Configuration Protocol).

The moment your computer connects to Wi-Fi, it broadcasts a DHCP discovery message across the LAN. The router (which has a built-in DHCP server) responds with a "configuration package" containing four critical pieces of information:

1. Your own IP address (e.g. 192.168.1.10)
2. The subnet mask (e.g. 255.255.255.0, used to determine whether a destination is local or remote)
3. The default gateway IP (e.g. 192.168.1.1)
4. DNS server addresses (e.g. 8.8.8.8)

Your operating system records this configuration. From that point on, whenever it needs to send a packet:

• It uses the subnet mask to check if the destination is local or remote
• If remote, it uses the DHCP-supplied gateway IP to initiate an ARP query and obtain the gateway's MAC

In other words, the gateway IP is not hardcoded in your code or known by magic — DHCP hands it to you the moment you join the network. We'll revisit DHCP in detail in a later article. For now, just know that this value is configured automatically the instant you connect — no manual setup required.

You might be thinking: if broadcast frames can't reach remote destinations, can we "upgrade" the MAC address system to work directly on the Internet? Make every device's MAC globally reachable, with switches chaining frames hop by hop?

The answer is no. This isn't a limitation of technical details — MAC addresses are architecturally incapable of supporting Internet-scale communication. There are three reasons:

2.1 Flat Address Space: No Sense of "Direction"

MAC addresses are flat — they contain no hierarchical structure that indicates a device's geographic location or network membership.

Look at these MAC addresses:

The first three bytes (A4:5E:60) are the Organizationally Unique Identifier (OUI); the last three are the serial number. The first and third addresses come from the same manufacturer, but this says absolutely nothing about whether they're physically near each other. A network card assembled in Beijing could be running on a server in New York.

Think of it like birth certificate numbers. Knowing the number 110105199003077734 tells you nothing about where the person currently lives. If a package delivery system relied solely on ID numbers, a courier at an intersection would have no idea whether to turn left or right.

Now contrast this with how postal addresses are designed:

Each level gets more specific, progressively narrowing the scope. Any intermediate sorting center only needs to look at the first few levels of an address to decide which direction to forward the package. This is the power of hierarchy: it allows intermediate nodes to make forwarding decisions without knowing the precise location of every endpoint on the globe.

MAC addresses lack this hierarchy, so when an intermediate device faces an unfamiliar MAC address, it has no option except flooding — asking everyone. That's manageable in a home network of 20 devices. It's catastrophic on an Internet of billions.

2.2 Table Explosion: Switches Can't Handle It

A switch builds its MAC address table by self-learning: when it sees a frame arrive from port 3, it records "source MAC X is on port 3." In an office LAN, this table might have a few hundred entries — perfectly fine.

But how many connected devices are on the Internet? Conservative estimates put it at over 15 billion. If you wanted to forward by MAC address directly, every forwarding device along the path would need to maintain a table mapping tens of billions of entries — each mapping one MAC address to one egress port.

This is physically impossible. A switch's MAC address table is stored in high-speed TCAM (Ternary Content-Addressable Memory) chips. These chips are expensive and capacity-limited: a typical home switch supports thousands to tens of thousands of entries, and an enterprise switch tops out at a few hundred thousand. That's five orders of magnitude short of the billions needed.

IP addresses, by contrast, allow address aggregation thanks to their hierarchical structure. A router doesn't need to remember every individual device in the destination network — it only needs one rule like "everything starting with 140.82.x.x goes that way." That single routing entry covers thousands or millions of devices. The Internet's core routing table holds only about 1 million entries — four orders of magnitude fewer than the 15-billion-device MAC table would require.

2.3 No Path Selection Capability

A switch's forwarding logic is extremely simple: look up MAC address in the table, find the port, forward. If not found, flood. It has no ability to "choose a path."

But the Internet's topology is complex. Between your home and GitHub's servers, there may be dozens of possible paths — through different ISPs, different undersea fiber cables, different data centers. Intermediate forwarding devices need to dynamically choose which path to take based on network congestion, link availability, and path priority.

A switch cannot do this. It simply "forwards by table" — no concept of path selection. Routers, on the other hand, run routing protocols (like BGP, OSPF) that can perceive changes in network topology, compute optimal paths, and dynamically adjust forwarding decisions.

Summary of the three fundamental limitations:

Now that we understand the boundaries of what switches can do, it's time to properly introduce the router.

Switches and routers are often conflated in everyday life — that "router" box at home is actually a switch + router + AP combo.

We discussed this in detail in the first article:

Now let's properly compare their fundamental responsibilities:

The most distinctive feature of a router: it has multiple network interfaces, each connected to a different network, each with its own IP address and MAC address.

When your computer sends a packet destined for GitHub's server:

1. Your computer builds an Ethernet frame: destination MAC is the router's LAN port MAC (obtained via ARP), the IP packet's destination IP is GitHub's IP
2. The frame reaches the router's LAN port; the router strips off the Ethernet frame header and extracts the IP packet
3. The router looks at the destination IP, checks its routing table, and decides "this destination should be forwarded to the ISP via the WAN port"
4. The router builds a brand new Ethernet frame on the WAN port (new source MAC and destination MAC) and sends it to the ISP network
5. The ISP's router receives it and repeats the same process: strip frame, check routing table, rebuild frame, forward

This process repeats until the packet finally reaches the LAN where GitHub's server lives.

Note the critical pattern here:

Every time a packet passes through a router, the Ethernet frame is torn down and rebuilt. The MAC addresses in the frame header change at every hop, but the source IP and destination IP inside the IP packet remain unchanged the entire journey.

This is why the Internet needs two addressing systems working in parallel: one for end-to-end navigation (IP), one for the actual delivery at each segment (MAC).

To cement this layered model in your intuition, let's trace the full process through a concrete analogy.

Imagine you're in Beijing, and you need to send a package to a friend's home in New York City.

You drop the package at your neighborhood courier station. The station doesn't fly it directly to New York — it loads the package onto a truck and attaches a shipping manifest:

At the Beijing sorting center, the manifest is torn off. The staff reads the recipient address (New York), puts the package on a different truck, and attaches a new manifest:

At the airport, the manifest is replaced again. The package flies across the Pacific, arrives at a New York sorting center, and is relayed step by step until it reaches John's doorstep.

Throughout this entire process:

• The address on the package never changes (123 Broadway, NY) — this is the IP address
• The shipping manifest changes at every leg (Haidian Station → Sorting Center → Airport → ...) — these are the MAC addresses
• Each intermediate station only cares about "who receives this next" — this is the router's hop-by-hop forwarding
• The neighborhood courier station doesn't need to know the specific streets of New York — this is the power of layering

Two addressing systems, each with a distinct role — this is the essence of layered network design.

By now, we know the Internet needs a hierarchical, logical addressing system to compensate for MAC's shortcomings. That system is the IP address.

But we haven't yet explored its internal structure. Questions like:

• How exactly does an IP address divide into a "network portion" and a "host portion"?
• What is a subnet mask? What does CIDR notation mean?
• How can a single IP address indicate both "which network" and "which host in that network"?
• What's the difference between public and private IPs? What is NAT?
• Why did IPv4 addresses run out, and how does IPv6 solve this?

These questions will be answered in the next article. Until then, carry this core understanding with you:

MAC addresses answer "on this link, who receives the frame?" IP addresses answer "across the entire Internet, where does the packet go?" The former is the shipping manifest in a courier's hand; the latter is the address on the package. Routers are the sorting centers along the way — at each stop they tear off the old manifest, apply a new one, but never touch the address on the package.

1. Trace the hop count of a data packet

   Use the traceroute (macOS/Linux) or tracert (Windows) command to see how many routers a packet passes through from your computer to a remote server:

   bash

   traceroute github.com

   Each line in the output represents one "hop" — one router. The first hop is usually your home router (192.168.1.1 or similar). Observe: how many hops total? Are any unusually high?

2. Examine your routing table

   Your computer also maintains its own routing table, which the operating system uses to decide where to send packets:

   bash

   # macOS netstat -rn # Linux ip route show # Windows route print

   Find the line labeled default or 0.0.0.0 — that's your default gateway. All packets that "don't know where to go" are handed to it. This perfectly matches the behavior from the ARP article where "accessing the internet means querying the gateway's MAC."

1. Compare ARP behavior for LAN ping vs. Internet ping

   Start a packet capture tool (tcpdump or Wireshark), then ping a local device and a remote address separately. Compare the ARP requests in both cases:

   bash

   # Terminal 1: capture ARP packets sudo tcpdump -i en0 arp -n # Terminal 2: ping a LAN device ping 192.168.1.20 # Terminal 2: then ping an external host ping github.com

   You should observe: when pinging an external host, the ARP request targets the gateway's IP (e.g. 192.168.1.1), not github.com's IP. This is precisely the core behavior reinforced throughout this article and the ARP article.

• The broadcast domain defines the boundary of a LAN: devices within the same broadcast domain can receive each other's broadcast frames; the router is the dividing line between broadcast domains.
• MAC addresses have three fundamental limitations: flat and non-hierarchical (can't infer direction), forwarding tables can't scale to Internet size, and no path selection capability.
• Switch vs. Router: a switch forwards frames by MAC within a single network; a router forwards packets by IP across different networks and is the core forwarding device of the Internet.
• Hop-by-hop forwarding model: at each router along the path, the link-layer frame is torn down and rebuilt (MAC addresses change), but the source and destination IP addresses in the IP packet remain unchanged.
• Two addresses, two roles: IP is the "recipient address on the package" (end-to-end), MAC is the "shipping manifest for each leg" (hop-by-hop). Together they enable data delivery across the Internet.

Next:

This chapter answered "why MAC addresses aren't enough" and "what kind of addressing the Internet needs." The next question is: what does an IP address actually look like, and how does its hierarchical structure work?

In the next article, we'll dive into the internal structure of IP addresses: IPv4's 32-bit format, the division between network and host portions, subnet masks and CIDR, public vs. private addresses, the role of NAT, and — after IPv4 exhaustion — how IPv6 takes over. Once you understand these, you'll truly see how a router "knows which way to forward."