A technical introduction to how the internet routes data
Every device that communicates on a network needs an identifier — something that distinguishes it from every other device. An IP address (Internet Protocol address) serves this purpose. Think of it like a postal address: without one, nobody knows where to deliver your mail.
IP addresses come in two versions: IPv4 and IPv6. Both identify a specific network interface, but they differ substantially in format, capacity, and features.
IPv4 addresses are 32 bits long, written as four decimal numbers separated by dots — for example, 192.168.1.1. Each of those four numbers represents 8 bits (called an octet), so each can range from 0 to 255. That gives a theoretical total of about 4.3 billion unique addresses.
When the internet was designed in the 1970s and 80s, 4.3 billion addresses seemed inexhaustible. It wasn't. The explosion of personal computers, smartphones, and connected devices consumed the IPv4 address space faster than anyone anticipated. Today, IPv4 addresses are formally exhausted at the regional allocation level, and network engineers use various workarounds (most notably NAT, described below) to stretch the remaining supply.
IPv6 addresses are 128 bits long, written as eight groups of four hexadecimal digits, separated by colons:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
Consecutive groups of all zeros can be compressed with ::, so the above might appear as 2001:db8:85a3::8a2e:370:7334.
128 bits yields approximately 3.4 × 1038 addresses — enough to give every grain of sand on Earth its own address, many times over. IPv6 was designed not just to solve the exhaustion problem but to build in features that had to be bolted onto IPv4 as afterthoughts, including better security and simplified routing.
Not every IPv4 address is reachable from the open internet. Certain ranges are reserved for private use — networks inside homes, offices, and data centres:
| Range | Common use |
|---|---|
10.0.0.0 – 10.255.255.255 | Large private networks |
172.16.0.0 – 172.31.255.255 | Medium private networks |
192.168.0.0 – 192.168.255.255 | Home and small office networks |
Devices using private addresses cannot communicate directly with the public internet; they require a router performing Network Address Translation (NAT), which maps many private addresses onto one (or a few) public addresses. This is why multiple devices in your home share a single public IP.
An IP address on its own doesn't tell you which part of it identifies the network and which part identifies the specific host within that network. This is handled by a subnet mask.
A subnet mask is another 32-bit number, written either in dotted notation (255.255.255.0) or in CIDR notation as a suffix on the address (192.168.1.0/24). The /24 means the first 24 bits identify the network, leaving 8 bits for hosts — up to 254 usable host addresses (256 minus the network address and broadcast address).
Subnetting lets network administrators divide a large address space into smaller, manageable segments, each acting as its own network. This improves security, reduces broadcast traffic, and gives administrators control over which devices can communicate directly.
127.0.0.1 is the loopback address — traffic sent here never leaves the machine. Developers use it to test network software locally. Its IPv6 equivalent is ::1.
0.0.0.0 typically means "any address on this host" and is used when a server wants to listen on all available network interfaces.
The highest address in any subnet (e.g., 192.168.1.255 in a /24) is the broadcast address — packets sent here are delivered to every host on that subnet.
IP itself is deliberately minimal. It routes packets from source to destination — and that's essentially all it promises. A rich ecosystem of protocols has been built on top of IP to provide the reliability, ordering, error-checking, and application-level behaviour that raw IP doesn't offer.
These protocols sit at different layers of the TCP/IP model, a practical layered framework describing how network communication works:
| Layer | Responsibility | Examples |
|---|---|---|
| Application | What data means and how apps exchange it | HTTP, DNS, SMTP, SSH |
| Transport | End-to-end delivery between processes | TCP, UDP |
| Internet | Logical addressing and routing across networks | IP, ICMP, IGMP |
| Link | Physical transmission on a single network segment | Ethernet, Wi-Fi |
TCP is the workhorse of reliable internet communication. Before any data is exchanged, TCP performs a three-way handshake:
Client → Server : SYN (I want to connect) Server → Client : SYN-ACK (Acknowledged, ready) Client → Server : ACK (Starting now)
After the connection is established, TCP guarantees:
Ordered delivery. Data is broken into segments and numbered. The receiver reassembles them in the correct order even if they arrive out of sequence.
Reliability. Every segment must be acknowledged. If an acknowledgement doesn't arrive within a timeout window, the sender retransmits. Data cannot be silently lost.
Flow control. The receiver tells the sender how much data it can handle at once (the receive window), preventing a fast sender from overwhelming a slow receiver.
Congestion control. TCP monitors for signs of network congestion — dropped packets, increased latency — and backs off its sending rate accordingly. This is why a single TCP download doesn't generally saturate a shared network to the point of complete collapse.
TCP is ideal for anything where accuracy matters more than speed: web pages (HTTP/1.1 and HTTP/2 run over TCP), email, file transfers, and database queries.
UDP strips TCP down to its essentials. There's no handshake, no acknowledgement, no ordering guarantee, and no retransmission. A UDP datagram is sent and the sender immediately forgets it.
That sounds like a flaw, but it's a deliberate trade-off. UDP's overhead is tiny compared to TCP, and for many applications the latency cost of retransmission is worse than occasionally losing a packet:
Video calls and VoIP. A retransmitted audio frame arriving 200ms late is useless. It's better to let it drop and keep the stream moving.
Online gaming. Player position updates are sent many times per second. An old position arriving late is irrelevant; the current one is all that matters.
DNS lookups. A query and response each fit in a single small packet. The application layer handles retries if nothing comes back.
Streaming media. Minor video artefacts are more acceptable than a stream that pauses to retransmit.
UDP is also the foundation for newer transport protocols like QUIC (which powers HTTP/3), which implement their own reliability mechanisms at the application layer with more flexibility than TCP allows.
ICMP is the diagnostic and error-reporting protocol of the internet. It operates at the IP layer and is used by network devices to communicate operational information — not user data.
When a router can't forward a packet (because the destination is unreachable, or a packet's time-to-live has expired), it sends an ICMP message back to the source explaining what happened.
The two most familiar network tools you've likely used both rely on ICMP:
ping sends ICMP Echo Request messages to a host and waits for Echo Reply responses. The round-trip time tells you whether the host is reachable and how long the path takes.
traceroute (or tracert on Windows) exploits the TTL field in IP packets. It sends packets with incrementally increasing TTL values. Each router that receives a packet with TTL=0 drops it and sends back an ICMP Time Exceeded message, revealing that router's address. By collecting these responses, traceroute maps the path a packet takes across the internet.
DNS is what lets you type example.com rather than 93.184.216.34. It's a distributed, hierarchical database that maps human-readable domain names to IP addresses.
When you request a website, your device queries a DNS resolver (usually provided by your ISP or a service like 8.8.8.8). If the resolver doesn't have the answer cached, it works up the hierarchy — querying root name servers, then top-level domain servers (for .com, .org, etc.), then the authoritative name server for the specific domain — until it retrieves the IP address and returns it to you. This whole process typically completes in milliseconds.
DNS runs over UDP (port 53) for standard queries, and falls back to TCP for larger responses or zone transfers between DNS servers.
When a device joins a network, it needs an IP address, a subnet mask, a default gateway, and DNS server addresses. DHCP automates this. The device broadcasts a request; a DHCP server on the network responds with a configuration lease. The device accepts and is configured — all without any manual input.
The DHCP exchange is sometimes called DORA: Discover, Offer, Request, Acknowledge.
As mentioned earlier, NAT allows multiple devices sharing a single public IP address to communicate with the internet. The router maintains a translation table: when a device on the private network initiates a connection, the router records which internal device sent it and rewrites the source IP in outgoing packets to its own public address. When a response arrives, the router looks up the original sender and forwards the packet inward.
NAT has been critical in extending the lifespan of IPv4, but it breaks the original end-to-end model of the internet (where every host could communicate directly with any other). Protocols like peer-to-peer file sharing and VoIP have historically had to work around NAT with techniques like STUN and hole-punching.
At the core of everything IP does is the packet. Rather than establishing a dedicated circuit between two endpoints (the way old telephone networks worked), IP chops data into discrete packets and routes each one independently across whatever path is available. This is called packet switching.
Each packet carries enough information to get itself from source to destination — it's self-contained. Different packets in the same communication might take different paths through the network and arrive out of order. Higher-layer protocols (like TCP) handle reassembly.
Every IPv4 packet begins with a header of at least 20 bytes. Here are the key fields:
| Field | Size | Purpose |
|---|---|---|
| Version | 4 bits | IP version (4 for IPv4) |
| IHL | 4 bits | Header length in 32-bit words |
| DSCP / ECN | 8 bits | Quality of service marking; congestion notification |
| Total Length | 16 bits | Total size of the packet including header and data (max 65,535 bytes) |
| Identification | 16 bits | Identifies fragments belonging to the same original datagram |
| Flags | 3 bits | Controls fragmentation (e.g., Don't Fragment bit) |
| Fragment Offset | 13 bits | Position of this fragment within the original datagram |
| TTL | 8 bits | Decremented by each router; packet discarded when it reaches 0 |
| Protocol | 8 bits | Identifies the encapsulated protocol (6 = TCP, 17 = UDP, 1 = ICMP) |
| Header Checksum | 16 bits | Error detection for the header only |
| Source Address | 32 bits | Sender's IP address |
| Destination Address | 32 bits | Recipient's IP address |
After the header comes the payload — the data being carried, which is itself another protocol's packet (a TCP segment, a UDP datagram, etc.). This nesting of protocols within each other is called encapsulation.
The Time-to-Live field is a simple but important safety mechanism. Every router that handles a packet decrements the TTL by one. If TTL reaches zero before the packet arrives at its destination, the router discards it and sends an ICMP Time Exceeded message back to the source.
Without TTL, a misconfigured routing loop could cause packets to circulate forever, consuming bandwidth indefinitely. TTL caps the damage. Operating systems typically set an initial TTL of 64 or 128; you can often infer the OS of a remote host by counting how many hops away it is and working backwards from common starting values.
Different network links have different Maximum Transmission Units (MTU) — the largest packet they can carry. Ethernet's standard MTU is 1500 bytes. If a packet needs to cross a link with a smaller MTU, the router must break it into smaller fragments.
The Identification, Flags, and Fragment Offset fields in the header coordinate this. All fragments carry the same Identification value, and the Fragment Offset tells the receiving end how to reassemble them. Only the final destination reassembles the fragments; routers in the middle don't.
Fragmentation is generally avoided in modern networks for performance reasons. Path MTU Discovery (PMTUD) uses the Don't Fragment flag to probe the smallest MTU along a path, allowing the sender to size packets appropriately from the start.
IPv6 deliberately simplified the header compared to IPv4, removing fields that had become unnecessary and moving optional information into extension headers that only appear when needed.
| Field | Size | Purpose |
|---|---|---|
| Version | 4 bits | Always 6 |
| Traffic Class | 8 bits | QoS, equivalent to IPv4 DSCP/ECN |
| Flow Label | 20 bits | Labels packets belonging to the same flow for consistent handling |
| Payload Length | 16 bits | Length of everything after the header |
| Next Header | 8 bits | Type of the next header (extension header or upper-layer protocol) |
| Hop Limit | 8 bits | TTL equivalent |
| Source Address | 128 bits | Sender's IPv6 address |
| Destination Address | 128 bits | Recipient's IPv6 address |
Notably absent: the header checksum (redundant — link-layer and transport-layer protocols handle error detection), and fragmentation fields (IPv6 routers never fragment; if a packet is too large, it's dropped and an ICMPv6 message is returned to the source). This simplification allows routers to process IPv6 packets faster.
Trace a packet's journey from your laptop to a web server on another continent:
1. Your laptop creates a TCP segment containing an HTTP request. This is wrapped in an IP packet with your laptop's source address and the web server's destination address. The packet is handed to your Wi-Fi adapter.
2. Your home router receives the packet. It checks its routing table — a list of known networks and which interface to send traffic toward. The destination is outside your local network, so the router forwards the packet to your ISP via your broadband connection. If NAT is in use, the source address is rewritten to the router's public IP.
3. Your ISP's routers examine the destination address and forward the packet toward the destination. Each router makes an independent forwarding decision based on its own routing table. Routers use protocols like BGP (between ISPs) and OSPF (within a network) to learn about available paths and their costs.
4. Transit routers across the internet repeat this process, each decrementing the TTL by one. The packet hops across potentially dozens of routers in different countries.
5. The web server's router receives the packet and delivers it to the server. The server's TCP layer acknowledges receipt, and the reply packet begins its own journey back.
At no point does any single router need to know the entire topology of the internet. Each one only needs to know enough to make the next hop decision. This is what makes the internet robust and scalable: routing is decentralised and adaptive.
It's worth stepping back to see how all these layers fit together. When you load a webpage, the data is wrapped layer by layer:
[ Ethernet Frame ]
[ IP Packet ]
[ TCP Segment ]
[ HTTP Request ]
GET / HTTP/1.1
Host: example.com
Each layer adds its own header (and sometimes trailer) containing the information that layer needs to do its job. At the receiving end, each layer strips its header and passes the payload up to the next layer. This separation of concerns is what allows the internet to be so modular — a new application protocol doesn't need to care how IP works, and IP doesn't need to know anything about the applications using it.
Further reading: RFC 791 (IPv4), RFC 8200 (IPv6), RFC 793 (TCP), RFC 768 (UDP), RFC 792 (ICMP).