IP & Addressing (OSI, the Useful Parts)

You just spent a whole section learning what to want from a system — fast, available, scalable, consistent, cheap to own. Now we get to the wires. Because none of those qualities matter if the bytes can't get from one machine to another in the first place, and it turns out that simple-sounding trip is one of the great magic tricks of engineering.

Think about what actually happens when you load a page. Your request leaves your laptop, and in about a tenth of a second it crosses a dozen machines you've never heard of — your router, your ISP, a few backbone routers, maybe an ocean, a cloud provider's edge — and arrives, intact and in order, at one specific program on one specific server on the other side of the planet. Nobody in that chain knows you. Most of them never see your actual request. And yet it gets there, every time, in milliseconds.

How does a stranger's router, glancing at your traffic for a few microseconds, know where to send it — and how does it arrive at exactly the right program out of the billions running on the internet?

The answer is addressing and layers. Every request is wrapped in a little stack of addresses, each answering a different question — which network? which machine? which program? which next hop? — and each machine along the way reads only the part that's its job. This lesson gives you the minimum-correct mental model of that stack. We're going to be ruthless about it: there's a famous seven-layer diagram you may have seen, and most of it is trivia for a system designer. We'll teach only the parts you'll actually reason about — and by the end you'll know something genuinely useful: exactly what every networking box you'll ever design with — a switch, a router, a firewall, a load balancer — can and cannot see. Let's follow one packet.

The network is built in layers, and the reason is the single most important idea in all of networking: each layer does one job and trusts the layers below it to do theirs. The part of your computer that speaks HTTP doesn't know or care whether your packets travel over fiber, copper, or Wi-Fi. The part that drives the Wi-Fi radio doesn't know or care that it's carrying a web request. It's job specialization — like a postal system where the letter-writer, the sorter, and the truck driver each do one thing and hand off to the next, none of them needing to do anyone else's job.

There are two famous ways to draw those layers, and it's worth knowing the difference so you're never confused again:

• The OSI model (7 layers) is the textbook reference — Physical, Data Link, Network, Transport, Session, Presentation, Application. It's a teaching tool and a shared vocabulary. It is not what the internet actually runs.
• The TCP/IP model (4 layers) is what the internet actually runs — Link, Internet, Transport, Application. The middle OSI layers (Session and Presentation) mostly turned out to be vestigial: that work lives inside applications and inside encryption (TLS) today.

Here's the honest, time-saving truth most courses won't tell you: as a system designer, you need exactly four layers, and really only their numbers as shorthand.

Layer	Its one job	What people say	Example
L7 — Application	the actual request and its meaning	"layer 7"	HTTP, gRPC, DNS
L4 — Transport	which program; reliability	"layer 4"	TCP, UDP
L3 — Network	which host on which network; routing	"layer 3"	IP (v4/v6)
L2 — Link	the next hop on the local wire	"layer 2"	Ethernet, Wi-Fi

That's the whole map you need. When an engineer says "that's a layer 4 load balancer" or "it's an L7 problem," those numbers are what they mean. Forget memorizing all seven — the value isn't the list, it's knowing which layer each machine works at, because that tells you what each machine can see. Everything below builds toward that.

To send anything anywhere, the network uses three different addresses, each answering a different question. Beginners blur them together, and every serious networking confusion traces back to that blur. The cleanest way to keep them straight is the postal system, so let's use it the whole way through.

The IP address (Layer 3) — where. This is the street address of the building. It says which network (which neighborhood) and which host (which building) you're trying to reach, and it is globally meaningful — it means the same thing anywhere on the internet. Crucially, it's written on the envelope and it does not change for the entire trip. An IPv4 address is 32 bits, written as four numbers like 203.0.113.7 — which gives only about 4.3 billion of them (hold that thought; it matters later). Its successor, IPv6, is 128 bits — effectively unlimited.

The port (Layer 4) — which program. One building can hold many residents. The port is the apartment number: it tells the destination machine which program should get this traffic — the web server, the database, the SSH login. It's just a number from 0 to 65,535. Some are conventions everyone agrees on: 80 for HTTP, 443 for HTTPS, 53 for DNS, 22 for SSH. Your own browser grabs a random high number for the return address.

The MAC address (Layer 2) — the next hop. This is the sneaky one, and it's where the deepest misconception lives. The MAC address is not how your packet reaches its destination. It's the handoff between mail trucks at each local depot — it only names the very next device on the local wire. When the letter reaches the next depot, that depot puts it on a different truck to a different next depot, so the MAC address is rewritten at every hop, over and over, all the way across the world. It's local and temporary. The IP is global and permanent.

Put the transport and network addresses together and you get the 5-tuple — (source IP, source port, destination IP, destination port, protocol) — which uniquely identifies one connection. Remember this little bundle: it's what a socket keys on, what a NAT table remembers, and what a layer-4 load balancer uses to route you. Three questions — where, which program, next hop — three addresses. Now let's see how they get attached.

Those three addresses don't get bolted on all at once. They're added one layer at a time as your data travels down the stack, each layer wrapping whatever it got from above in its own little header. This is called encapsulation, and the envelope metaphor is almost exact.

Picture your request going down the sender's stack:

1. Your app produces the actual message — say, GET /home (Layer 7).
2. The transport layer wraps it in a header carrying the ports (which program to, which program from). The result is called a segment (Layer 4).
3. The network layer wraps that in a header carrying the source and destination IP addresses. Now it's a packet (Layer 3).
4. The link layer wraps that in a header carrying the next-hop MAC addresses. Now it's a frame (Layer 2), and it goes out on the wire as bits.

So your little GET /home ends up as a set of nested envelopes: your letter, inside an envelope marked with the apartment number, inside a bigger envelope marked with the street address, inside a truck manifest for the next depot. Those names — message → segment → packet → frame — aren't pedantry; when someone says "the router dropped the packet" versus "a corrupt frame," they're telling you exactly which layer they mean.

The beautiful part is what happens at each stop along the way. A depot only opens the outer manifest. A router in the middle of the internet reads the outer addressing it needs — just enough to forward the thing — and never opens your actual letter inside. When the frame finally reaches the destination machine, the process runs in reverse: the link layer strips the frame header, the network layer strips the IP header, the transport layer strips the port header, and the original GET /home pops out at the app, clean and unwrapped. That reverse process is decapsulation.

And it's cheap — a common worry is that all this wrapping must be slow, but each header is a tiny, fixed-size prefix stamped on by the operating system or the network card's hardware. The payload isn't copied and re-copied. Wrapping a letter in one more envelope doesn't rewrite the letter. Which is exactly why the whole internet can afford to do it to every packet, billions of times a second.

Reading about encapsulation is one thing; watching an address get wrapped on and then rewritten hop after hop is what makes it finally click. So below is the whole journey, live and under your control.

Fire a request and watch it descend the sender's stack, collecting a port, then an IP, then a MAC — the nested envelopes forming in front of you. Then step it across the routers and keep your eye on the two addresses at the top: the destination IP never changes, while the MAC is rewritten at every single hop. That one contrast is the heart of this entire lesson, and it's the thing static diagrams can never show you. Flip on NAT and watch your private source address get rewritten to a public one as it crosses the boundary.

Then do the thing that actually matters for design: click any box in the path — the switch, the router, the NAT, the layer-4 load balancer, the layer-7 load balancer — and it will show you exactly which address it reads, and what it's completely blind to. A switch never sees your IP. A layer-4 load balancer never sees your URL. That map of who-can-see-what is the payoff you'll carry into every networking decision for the rest of the course.

Let's trace the real journey once, end to end, because the mechanics explain a surprising amount of what you'll debug later. Your app opens a connection to some destination IP and hands a packet to the operating system. Now the OS asks the first routing question every device asks: is this destination on my own local network, or somewhere else?

If it's somewhere else — and for the internet it always is — the packet goes to your default gateway, the router that's your on-ramp. But to put the frame on the local wire, your machine needs the gateway's MAC address, and it only knows its IP. So it shouts a quick question onto the local network — "who has this IP?" — a protocol called ARP, and the gateway answers with its MAC. Now the frame can be addressed to the gateway and sent.

From there it's hop by hop, and each router repeats the same three steps:

1. Look at the destination IP and consult its routing table to decide the best next hop. (It uses longest-prefix match — the most specific matching route wins.)
2. Decrement the TTL — a "time to live" counter that drops by one at every hop. If it ever hits zero, the packet is discarded. That's the safety valve that stops packets from looping forever — and, cleverly, it's exactly how the traceroute tool maps the path: send packets with TTL 1, 2, 3… and see which router complains at each distance.
3. Rewrite the Layer-2 frame with a fresh source and destination MAC for the next hop, and forward it.

Watch what's constant and what changes across all those hops, because this is the insight that separates people who get networking from people who don't: the destination IP in the packet never changes — it's the fixed goal the whole way — while the MAC addresses are rewritten at every single hop, because each hop is only ever about reaching the next machine on the local wire. The IP is the destination on the envelope; the MAC is just which truck carries it on this one leg. Global goal, local handoffs, over and over, until the frame lands on the destination's network card and rides the stack up to the right program — chosen, of course, by that 5-tuple.

Here's a number to sit with: IPv4 has only about 4.3 billion addresses, and there are far more than 4.3 billion phones, laptops, servers, and smart toasters. We ran out. The global pool was formally exhausted when IANA handed out its last blocks on 3 February 2011, and the Asia-Pacific registry was the first to hit empty just two months later. That scarcity quietly shaped almost everything about how modern networks are addressed — so it's worth understanding the two workarounds that saved us.

Private addresses + NAT. Certain IP ranges — 10.x.x.x, 172.16–31.x.x, 192.168.x.x — are reserved as private: anyone can reuse them inside their own network. Your laptop's 192.168.1.5 isn't unique on the internet; millions of homes use that exact address behind their routers. The trick that makes it work is NAT (Network Address Translation): your router rewrites the private source address into its one shared public address on the way out, remembers the mapping, and rewrites the replies back on the way in. A whole household — or a whole company — hides behind a single public IP.

NAT is why your home devices can freely reach out but can't easily be reached in: from the internet's side there's just one address and a NAT box that only knows about connections you started. That's a rough firewall for free, but it also breaks direct machine-to-machine connections — which is why peer-to-peer apps (video calls, games) need clever "hole-punching" helpers, and why a server that needs to receive connections must have a real public address or sit behind a load balancer. (Notice, too, that NAT is a deliberate cheat — a box that rewrites Layer-3 and Layer-4 addresses, quietly violating the clean layering. The layers are a wonderfully useful lie.)

The real fix is IPv6. With 128-bit addresses — about 340 undecillion of them, enough to give every grain of sand its own — scarcity simply disappears. Adoption is finally past the tipping point: in March 2026, IPv6 crossed 50% of Google's traffic for the first time, eighteen years after launch. But the transition has been glacial precisely because NAT worked well enough — and in the meantime, IPv4 addresses became a traded commodity, bought and sold for roughly $35–55 apiece. Addresses went from free and infinite to literal inventory on a balance sheet. That's the kind of second-order consequence good system designers learn to see coming.

Now the payoff, the thing that makes all of this pay rent in real design work. Because every packet is a stack of nested envelopes, each piece of infrastructure is built to open only down to a certain layer — and that determines, precisely, what it can and cannot do. Learn this table and you've extracted the entire practical value of the OSI model:

Box	Reads down to	So it can…	…but is blind to
Switch	L2 (MAC)	move frames around a local network	anything about IP or content
Router	L3 (IP)	forward packets between networks	ports and content
NAT / firewall	L3–L4 (IP + port)	rewrite addresses, allow/deny by port	the actual request
L4 load balancer	L4 (the 5-tuple)	split traffic blazingly fast	URLs, headers, cookies
L7 load balancer / proxy	L7 (HTTP)	route by path/host, terminate TLS	nothing — it reads it all

That bottom pair is the single most common design decision you'll meet in this whole course, so let's make it concrete. A Layer-4 load balancer (like AWS's Network Load Balancer) only reads the 5-tuple. It has no idea whether you asked for /login or /images/cat.jpg — it just sees a connection and forwards the raw packets. Because it never parses anything, it's ferociously fast: sub-millisecond, near wire-speed, millions of requests a second. A Layer-7 load balancer (like an Application Load Balancer, or nginx) actually reads the HTTP request — so it can send /api to one pool and /images to another, do sticky sessions, and terminate TLS. That power costs CPU and a little latency on every request.

So the trade writes itself: L4 is dumb and fast; L7 is smart and costs more. You cannot ask an L4 load balancer to route by URL — it physically cannot see the URL. You now understand why, down to the envelope. When we reach the load-balancing section, this won't be a rule to memorize; it'll be an obvious consequence of which envelope each box is allowed to open. That is what the layers are for.

Step back and notice that the layering itself — the very thing that makes all of this comprehensible — is a deliberate engineering trade-off, not a free lunch.

What layering buys you is modularity, and it's enormous. Because each layer only talks to its neighbors through a clean interface, you can replace an entire layer without touching the others. Your laptop switches from Wi-Fi to Ethernet to 5G — three completely different Layer-1/Layer-2 technologies — and your web app never notices, because HTTP at Layer 7 doesn't know or care what's underneath. TCP got faster and smarter over decades without a single application being rewritten. New physical media, new routing hardware, new protocols all slot in independently. That independence is why the internet could grow from a few university computers to the entire planet without anyone stopping to redesign it. It's the same modularity dividend you saw with statelessness and clean interfaces earlier in the course.

What it costs you is overhead and honesty. Every packet carries tens of bytes of headers it wouldn't need if the layers were fused — a small tax, paid on every packet, forever. And the clean separation is a useful fiction that leaks in practice: NAT reaches across Layer 3 and Layer 4 and rewrites addresses; a Layer-4 load balancer's performance depends on the physical path's MTU; TCP's behavior is coupled to the IP layer's packet loss. The tidy stack in the diagram is never quite as independent as it looks.

But — and this is the judgment call embedded in the design of the internet itself — the modularity is worth the leaks, overwhelmingly. A few bytes of overhead and some abstraction seams are a trivial price for being able to evolve every part of the network independently. The layered model is a slightly leaky abstraction that has scaled to connect billions of devices for fifty years. That's about the highest praise an engineering trade-off can earn.

"An IP address identifies a device." No — it identifies a location (a network interface), not an identity. Your phone changes IPs as it moves between Wi-Fi and cellular; DHCP hands your laptop a different one tomorrow; and behind NAT, thousands of devices share one public IP. IP is where you are right now, not who you are.

"The MAC address gets the packet to its destination." No — the MAC only reaches the next hop, and it's rewritten at every router. The IP is the end-to-end address; the MAC is a local, throwaway handoff. This is the single most common networking misunderstanding.

"Ports are physical doors, or a security feature." No — a port is just a number that says which program should get the traffic (Layer-4 demultiplexing). An "open port" simply means a program is listening, not that a hole was drilled in a wall.

"OSI is what the internet runs on." No — OSI is a teaching reference. The internet runs TCP/IP (four layers); OSI's Session and Presentation layers are largely folded into apps and TLS.

"I need to memorize all seven layers." For system design you need L3, L4, and L7 (and a little L2). The value isn't reciting the list — it's knowing which layer each box operates at.

"All that wrapping must make encapsulation slow." No — each header is a tiny fixed prefix added by the OS or the network card's hardware; the payload isn't recopied per layer. It's cheap enough to do billions of times a second.

"Bigger packets are always faster." No — the link's MTU (~1500 bytes) caps packet size. Exceed it and the packet must be fragmented (slower and more fragile) or gets silently dropped. More isn't free.

"localhost / 127.0.0.1 traffic goes out to the network." No — the loopback address is handled inside the machine and never touches a wire.

Twenty minutes at your own terminal will cement this more than any diagram — you'll literally see the hops and the two kinds of address. Predict first: how many router hops do you think separate your laptop from a big website — three? ten? thirty?

1. Trace the path. Run traceroute example.com (macOS/Linux) or tracert example.com (Windows). Each line is one router hop — a real machine that rewrote the Layer-2 frame and passed your packet along. Watch the response times climb as the hops get physically farther away. You're watching TTL do its job, live.
2. Find your two addresses. Run ipconfig (Windows) or ifconfig / ip addr (macOS/Linux) and look at your local IP — it'll almost certainly start with 192.168. or 10., a private address. Now search "what is my IP" in a browser: that's the public address your NAT router shows the world. One machine, two addresses — you just found the NAT boundary from both sides.
3. Spot the layer of your infra. Look at something you run or use — a load balancer, a CDN, a firewall rule. Ask the one question that now unlocks everything: which layer does it operate at, and therefore what can it see? Is that load balancer routing by URL (so it must be L7) or just by IP-and-port (L4)? Is that firewall rule about ports (L4) or about request content (L7)?

That third habit — instantly asking "what layer, so what can it see?" about every box in a design — is the reflex this lesson exists to build. Do it a few times and it becomes automatic, and the rest of the networking section will feel like it's just filling in a map you already understand.

The minimum-correct model of how bytes cross the planet:

• The network is built in layers — and for design you use four: L2 link (next hop), L3 network / IP (which host), L4 transport (which program), L7 application (the request). OSI's seven layers are a reference; the internet runs the four-layer TCP/IP model.
• Three addresses, three questions: IP = where (network + host, unchanged end-to-end), port = which program, MAC = the next hop only (rewritten at every hop). The 5-tuple identifies one connection.
• Encapsulation wraps your message in nested headers going down the stack (message → segment → packet → frame) and decapsulation strips them going up — each box opening only the envelope it needs.
• A packet crosses the internet hop by hop: the destination IP stays fixed while the MAC is rewritten every hop. NAT lets many private addresses share one public IP — a workaround born from IPv4 running out (2011), now being retired by IPv6.
• The payoff: each box sees only down to its layer — a switch sees MAC, a router sees IP, an L4 load balancer sees the 5-tuple (fast, blind to content), an L7 load balancer reads the HTTP (smart, costs more). That single fact will drive design decisions for the rest of the course.

So now you know that a packet reaches the right machine and the right program. But reaching it isn't the same as reaching it reliably. Packets get lost, arrive out of order, or show up twice — the network makes no promises. So who guarantees your bytes arrive complete and in order… and what does that guarantee cost? That's the choice at the heart of the next lesson: TCP versus UDP — the two transport protocols, and the round-trips you pay for a promise.