One hop is not a journey
In the last rung you learned how the link layer gets a frame across one single wire, from this box to the next box on the same cable or radio. But the box across the room is not the Internet. To reach a server on another continent, your data has to cross dozens of separate links, owned by different companies, made of different stuff, joined end to end. Each link only knows how to hand a frame to its immediate neighbour. Who decides which neighbour, hop after hop, so the data actually arrives? That is the job of the network layer.
The network layer sits one floor above the link layer in the TCP/IP model, and it has exactly one ambition: end-to-end delivery across many links. It does this by giving every interface on the planet a global address and stamping that destination address onto every chunk of data, so that any box along the way can read it and shove the chunk one step closer. Think of the link layer as a single courier van driving one leg of a route; the network layer is the addressing scheme on the parcel that lets a chain of vans, none of which knows the whole route, still get it to the door.
Forwarding versus routing: the two clocks
The network layer secretly does two very different jobs, and keeping them apart is the single most clarifying idea in this whole rung. The split is called forwarding versus routing. Forwarding is the local, split-second reflex: a packet lands on one of a router's input ports, the router glances at the destination address, looks it up in a table, and pushes the packet out the correct output port. That is it. It happens millions of times a second and must finish in nanoseconds.
Routing is the slow, global, thinking job: how does that table get filled in the first place? Routers must talk to each other, share what they can reach, and compute good paths across the whole network. That conversation runs in the background over seconds and minutes, and updates the table that forwarding then consults. The two live on completely different clocks. Engineers name these the data plane (forwarding, the fast per-packet machinery) and the control plane (routing, the slow path-deciding brain).
The datagram model: every packet travels alone
How should the network layer move data? History offers two grand designs. One, the virtual-circuit model, sets up a fixed path before sending anything, like the old telephone network reserving a line for your whole call. The Internet chose the other: the datagram model. There is no setup and no reserved path. Each packet, called a datagram, carries the full destination address and is launched into the network on its own, and every router decides its next hop independently, fresh, on the spot.
The everyday analogy is the postcard. You drop a postcard in the box with just an address on it. No phone call ahead, no reserved truck. Each post office that touches it makes one local decision (forward it roughly toward that address) and lets it go. Two postcards you mail one after the other might take different routes and even arrive out of order. That is exactly the deal the Internet makes: simple, robust, and gloriously stateless in the middle. Routers hold no per-conversation memory, which is why the core can survive a link failing mid-flight, the next packet simply gets steered around the gap.
There is an honest catch, and it is worth saying out loud. Because routers keep no state and make no promises, the datagram service is best-effort: a packet may be lost, duplicated, delayed, or delivered out of order, and the network layer will not notice or apologise. That sounds alarming until you remember the design philosophy: keep the network core dumb and fast, and push cleverness to the edges. If you need every byte delivered in order, that reliability is built on top at the transport layer (this is what TCP does), not down here. The network layer's modest, deliberate job is just to get datagrams roughly where they are going.
Opening the envelope: the IP datagram
The protocol that runs this whole show is the Internet Protocol, IP, and the packet format it defines is the IP datagram. This one format is the great unifier: the famous narrow waist of the Internet. Below it, a wild zoo of link technologies (Ethernet, Wi-Fi, fibre, cellular) all look the same once their frames carry IP inside; above it, every transport and application protocol rides on IP. Almost every device on Earth disagrees about nearly everything except this: they all agree to speak IP.
Like every packet you have met, a datagram is a header followed by a payload. Recall encapsulation: the payload is a whole transport-layer segment (a TCP or UDP chunk) handed down from above, and the header is the network layer's own set of control fields wrapped around it. The header is where all the network-layer machinery lives. Let us read the fields that matter most, in the version that still carries most of today's traffic, IPv4.
An IPv4 datagram (the header, then the cargo) +-----------------------------------------------------+ | version | header len | total length (bytes) | +-----------------------------------------------------+ | identification | flags | fragment offset | <- fragmentation +-----------------------------------------------------+ | TTL | protocol | header checksum | +-----------------------------------------------------+ | source IP address (32 bits) | +-----------------------------------------------------+ | destination IP address (32 bits) | <- forwarding uses this +-----------------------------------------------------+ | payload: the transport-layer segment (TCP / UDP) | +-----------------------------------------------------+
Four fields earn special attention. The destination IP address is the star: it is what every router reads to decide the next hop, and the next two guides are all about how those addresses are structured. The TTL (time-to-live) is a small counter that each router decrements by one; if it ever hits zero the packet is thrown away. This is the safety valve that stops a misrouted packet from circling the Internet forever, like a parcel stamped 'discard after 64 transfers'. The protocol field is a label saying what sits in the payload (for example, the number for TCP or for UDP), so the receiver knows which upstairs door to knock on. And the identification field plus flags exist for one specific headache we meet next: fragmentation.
When a datagram is too fat: MTU and fragmentation
Here is a problem IP cannot wish away. Every link has a maximum frame size it will carry, called the MTU, the maximum transmission unit. Ethernet's is famously 1500 bytes; other links are smaller. A datagram has to fit inside the link-layer frame of every hop it crosses. So what happens when a datagram that fit comfortably on a fat link arrives at a router whose next link has a smaller MTU and the packet is simply too big to send?
IP's answer is fragmentation: the oversized datagram is sliced into several smaller datagrams, each a complete little packet with its own header, that all fit. The clever part is reassembly. Every fragment carries the same identification number (so the destination knows they belong together), a fragment offset (saying where this slice goes in the original), and a flag bit meaning 'more fragments follow'. Crucially, reassembly happens only at the final destination, never at routers in between, because a stateless core has no place to hold half a datagram. The receiver collects all the pieces with the same id and stitches them back into the original.
When something goes wrong: ICMP, and the road ahead
IP is best-effort, so things do go wrong, and the network needs a way to report it. That is the job of ICMP, the Internet Control Message Protocol: IP's own small messenger for errors and diagnostics. When a router throws away a packet because its TTL hit zero, or because the destination is unreachable, or because a datagram needed fragmenting but was forbidden to, it sends an ICMP message back toward the source explaining what happened. ICMP is not for carrying your data; it is the network talking about itself.
You have almost certainly used ICMP without knowing it. The ping command sends ICMP echo requests and times the replies to ask 'are you there, and how long does the round trip take?'. The traceroute tool is a beautiful hack on TTL: it sends packets with TTL set to 1, then 2, then 3, and so on, so each dies one hop further along and the router that kills it announces itself via ICMP, revealing the path hop by hop. These are the first tools you will reach for when a network misbehaves.
That is the network layer's data plane in one piece: a best-effort, stateless datagram service, built on one universal packet format, where each router forwards on the destination address while routing quietly fills the table behind the scenes. The rest of this rung zooms into the parts that matter most. Guide 2 takes apart IP addresses and the CIDR slash notation; guide 3 covers NAT and why we ran short of addresses; guide 4 is the long story of IPv6; and guide 5 goes inside a router to watch longest-prefix match pick the output port in nanoseconds. You now have the map; let us fill in the territory.