Networking Fundamentals

A walk through the protocols that quietly make the internet work: how one public IP gets shared across thirty devices, how your laptop bootstraps itself onto a brand-new network, and how an Ethernet frame actually finds its next hop.

Network Address Translation (NAT)

The internet was originally designed so every device could have its own IP address. The problem: there are only 2^32 IPv4 addresses, about 4.28 billion. As of 2026 there are more than 30 billion connected devices, so IPv4 just doesn't have enough room. NAT (Network Address Translation) is the hack that lets many devices share a single public IP.

NAT is everywhere. Your home router is the most familiar example: every device you own (phone, laptop, TV, smart bulbs) shares one public IP from your ISP. Offices, business networks, and public WiFi do the same thing. Anywhere there are more devices than public IPv4 addresses, there's NAT.

So why do we need IPv6 if we already have NAT?

IPv4 is like phone numbers, and the world ran out because there aren't enough to give every device. NAT is like a receptionist: the whole office has one public phone number. That works great for outbound calls — inside the office, you route your request through the receptionist — but it's broken for inbound calls.

If someone wants to call you directly, they only know the receptionist's number. For browsing websites that's fine, but for peer-to-peer traffic (video games, direct video calls, phones trying to reach each other), it falls apart. IPv6 fixes this by giving everyone their own phone number.

How NAT actually rewrites packets

Your home router is doing this right now. All your devices have a private IP (like 192.168.1.50), but to the outside world the whole network looks like one public IP. As a packet passes through the router on its way out, the router rewrites the source from your laptop's address to its own public IP, paired with a port it picks to keep things unambiguous.

The key insight: the internal device effectively borrows the router's public IP and one of its ports for the connection. The router rewrites the source IP from 192.168.1.50 to its own public IP, and it also rewrites the source port to something unique — think of it as a sticker. That "sticker" is the public port the router assigns, used later to route replies back to your specific device.

NAT naturally handles outgoing connections because the internal device initiates them, which creates a table entry. But if someone on the internet tries to connect into your network cold, the router has no entry and just drops the packet. To run a server behind NAT, you need special configuration like port forwarding.

Running a server behind NAT with a changing public IP

Say you want to host a game server at play.examplegame.com from your office, but your ISP rotates the public IP every few days. Use Dynamic DNS (DDNS). A small client runs on the office network (or on the router itself), detects when the public IP changes, and automatically pushes an update to the authoritative DNS server. This keeps the A record for play.examplegame.com synchronized with whatever IP the ISP hands out that week.

The key configuration choice is a short TTL on the DNS record — something like 60 seconds instead of the typical 24 hours. TTL tells resolvers how long they can cache the record. Since the IP is changing rapidly, you want resolvers to re-query quickly.

The tradeoff is latency and load. With shorter TTLs, resolvers must perform a full multi-step DNS lookup every few minutes, which adds overhead and often makes the queries take longer.

Then, on the NAT router, configure a port forwarding rule: incoming traffic on the public IP at port 25565 should be translated and forwarded to the internal address 192.168.1.50:25565. Combined with an A record for play.examplegame.com pointing at the public IP (kept fresh by DDNS), players can reach your server even as the IP rotates.

Dynamic Host Configuration Protocol (DHCP)

Imagine you walk into a coffee shop with your laptop. Your laptop knows nothing about this network — no IP, no gateway, no DNS. DHCP is the protocol that bootstraps a new device onto a network by handing it all the information it needs to communicate. Without DHCP, you'd have to manually configure every device for every network, which is infeasible.

DORA — the four-step handshake

Discover. Client broadcasts "is there a DHCP server out there?" — sent from 0.0.0.0 to 255.255.255.255.
Offer. DHCP server responds with a proposed IP address and config.
Request. Client formally requests that IP.
Acknowledge. Server confirms, and the client now owns a lease on that IP.

What the lease actually contains, and why

IP address. Every packet has a source and destination IP, and routers use the destination IP to decide where to forward it next. Without an IP, other hosts have no way to address a packet back to you. The constraint the DHCP server must follow: the IP it assigns must be unique within the local subnet and must fall within the subnet's address range.

DNS resolver IP. Humans and applications use hostnames (google.com), not IPs. Every time the laptop wants to connect to a named service, it needs to translate the name into an IP by querying a DNS resolver. Without a resolver's address, the laptop could still send packets to IPs it already knows, but it couldn't look anything up — no browsing, no email, nothing that depends on names.

Default gateway IP. This is the laptop's "exit door" to any network that isn't local. Your laptop keeps a small internal routing table that says: "for addresses like 192.168.1.x, those are on my local network, I can reach them directly. Everything else goes through the default gateway." When the laptop wants to send a packet, it bitwise-ANDs its own IP with the subnet mask, then bitwise-ANDs the destination IP with the same mask. If the results match, the destination is on the same subnet and can be reached directly via ARP. If they don't match, the packet goes to the default gateway, which forwards it onward — potentially through many more routers.

DHCP's security hole

DHCP messages are sent as broadcasts that any host on the local network can observe and respond to, and the protocol does not authenticate the identity of the DHCP server. Two classic attacks fall out of this:

Malicious DNS resolver. The attacker forges a DHCP response where the DNS resolver field points to a server they control. The victim now sends every DNS query to the attacker, who can return whatever IPs they want. When the victim visits bank.com, the attacker returns the IP of a phishing site instead of the real bank.
Man-in-the-middle. The attacker forges a DHCP response where the default gateway field points to their own machine. Every packet the victim sends to the outside world now goes through the attacker first. They forward traffic onward (so the victim doesn't notice anything broken) but inspect, log, or modify every packet in transit.

Address Resolution Protocol (ARP)

IP addresses work at layer 3 (network), but actually sending bits over a physical link requires a MAC address at layer 2 (data link). When your laptop wants to send a packet to 192.168.1.1, it knows the IP — but the Ethernet frame needs a destination MAC address. ARP is the protocol that answers: "what MAC address corresponds to this IP on my local network?" It's a local lookup mechanism.

ARP works by broadcasting: "hey everyone, whoever has IP X, please tell me your MAC." The owner of that IP replies directly, and the asker caches the result.

Three flavors of ARP you'll actually see

ARP Probe. The sender's IP is 0.0.0.0, the target is a specific IP (say 172.16.5.83), and the hardware address is broadcast (FF:FF:FF:FF:FF:FF). The sender has no IP yet, which means this host is still being configured — likely during or right after DHCP. Before accepting a DHCP-offered IP, the host broadcasts a probe to check whether anyone else on the network is already using 172.16.5.83. If someone replies, there's a conflict and the host shouldn't take that address.

Gratuitous ARP. The sender's IP and target IP are identical. The host isn't asking anyone a question — it's announcing to the entire network, "I am 172.16.5.83, and my MAC is a3:1f:4b:d8:22:e5." This happens right after a host finishes DHCP and wants to claim its new address. It serves two purposes: it updates everyone else's ARP caches so they immediately know the mapping, and it acts as a final conflict check.

Standard ARP request. The sender has a configured IP (172.16.5.83) and is trying to find the MAC of another address, like the gateway (172.16.5.1). The sender wants to send traffic off the local network, and the subnet mask calculation tells it the packet must go through the gateway. But to actually frame that packet on the wire, the sender needs the gateway's MAC address. So it broadcasts "who has 172.16.5.1?" and caches the reply for future use.

The Protocol Stack

The protocol stack is about separation of concerns. Each layer solves one problem and trusts the layers below it to solve theirs.

From top to bottom in the TCP/IP model: Application (HTTP), Transport (TCP/UDP), Network (IP), Link (Ethernet/WiFi), Physical. When you send data, it's encapsulated — the application hands data to transport, which wraps it in a TCP segment, which gets wrapped in an IP packet, which gets wrapped in an Ethernet frame. Each layer adds its own header.

Application layer. Handles things like HTTP. Its job is to define the semantics of what client and server are actually communicating about — methods (GET, POST), headers, status codes, the structure of requests and responses. It doesn't care how bytes get from here to there. HTTP is one of hundreds of application-layer protocols (SMTP, DNS, SSH, etc.).

Network layer. Gets packets from the source network to the destination network, potentially across many intermediate routers. It uses IP addresses as its addressing scheme, which are globally meaningful and hierarchical. Routers examine the destination IP and consult their routing tables to decide which outgoing interface to forward the packet on.

Data link layer. Handles transmission across a single physical link between two directly-connected devices. It uses MAC addresses as its addressing scheme. At each hop, the packet is rewrapped in a new link-layer frame with new source/destination MACs corresponding to the two ends of that specific link. The key insight: IP addresses usually stay the same end-to-end, but MAC addresses change at every single hop.

MAC addresses are necessary because when your laptop hands a frame to your home router, the Ethernet/WiFi link between laptop and router needs a destination MAC — specifically, the router's MAC. Without MAC addressing, there would be no way to say "give this to the machine physically next to me on this link."

The OSI Model

The OSI (Open Systems Interconnection) model is a conceptual framework developed by ISO that standardizes the functions of a telecommunication system into seven abstract layers. Its purpose is to provide a common vocabulary and architectural reference for thinking about network protocols, so different vendors' systems can interoperate and engineers can reason about network behavior without conflating concerns.

That brings us to how the seven layers work together:

Physical. Transmits raw bits over a physical medium. Concerns: voltages, cable types, radio signals, pin layouts. Example: the electrical signaling on an Ethernet cable, or the radio modulation in WiFi.
Data Link. Delivers frames between two directly-connected nodes on a single link. Concerns: MAC addressing, framing, error detection on the link, media access control. Example: Ethernet, WiFi (802.11).
Network. Delivers packets between hosts across multiple networks. Concerns: logical addressing, routing, fragmentation. Example: IP (IPv4/IPv6).
Transport. Delivers data between processes on hosts, optionally with reliability and ordering. Concerns: port-based multiplexing, reliability, flow control, congestion control. Example: TCP, UDP.
Session. Manages sessions between applications — open, maintain, close. In practice, this layer is mostly absorbed into application-layer protocols today.
Presentation. Handles data representation, encoding, encryption. Concerns: character encoding, serialization, TLS (sometimes placed here). Also largely absorbed into applications today.
Application. Protocols that applications use directly. Example: HTTP, SMTP, DNS, SSH.