Every device connected to the internet needs a unique way to be identified. Without a clear addressing system, data would have no reliable way to reach its destination. This is where IP (Internet Protocol) addresses come in.

An IP address is a unique numerical identifier assigned to a device on a network. It allows routers and networking infrastructure to determine where data should be sent and how it should be routed across the internet.

In this chapter, we will explore what IP addresses are, how they work, and why they are fundamental to internet communication.

An IP (Internet Protocol) address is a unique numerical label assigned to every device on a network. Think of it as a postal address for machines: it tells the network where to deliver data.

Without IP addresses, there's no way for your laptop to tell a router "send this packet to that web server." Every device that sends or receives data needs one.

There are two versions in use today.:

IP addresses operate at Layer 3 (Network layer) of the OSI model. This is the layer responsible for routing, for getting packets from one network to another across the internet. Layer 2 (Data Link) handles local delivery using MAC addresses, but once a packet needs to leave your local network, IP takes over.

Every IP packet carries two addresses: the source IP (where it came from) and the destination IP (where it's going). Routers read the destination IP and forward the packet one hop closer to its target. Simple concept, but it scales to billions of devices.

So how are these addresses structured? Let's start with IPv4.

IPv4 (Internet Protocol version 4) is the workhorse that has powered the internet for over 40 years. Despite its age and well-known limitations, the vast majority of internet traffic still uses IPv4.

Address Format

An IPv4 address is 32 bits long, written as four decimal numbers separated by dots. Each number is called an octet because it represents 8 bits.

Take the address 192.168.1.25:

Each octet can range from 0 to 255 (since 8 bits can represent 2^8 = 256 values). That gives a total of 2^32 = roughly 4.3 billion possible addresses.

Address Classes (Historical)

In the early internet, addresses were divided into classes based on the first few bits. This determined how the 32 bits were split between the network portion (which network?) and the host portion (which device on that network?).

The problem was obvious. A company that needed 300 addresses had to get a Class B with 65,000 addresses, wasting over 99% of them. A company that needed 500 addresses couldn't use a Class C (only 254 hosts) and had to jump to a Class B. This rigid system burned through the IPv4 address space fast.

Classful addressing was replaced in the 1990s by something much more flexible: CIDR.

The Problem with Classful Addressing

Under classful addressing, you could only split addresses along fixed boundaries: /8, /16, or /24. If you needed 1,000 addresses, you had to allocate a /16 block with 65,536 addresses. That's a 98.5% waste.

By the early 1990s, the internet was growing rapidly and this waste was unsustainable. The solution was CIDR (Classless Inter-Domain Routing), introduced in 1993.

Subnet Masks and CIDR Notation

Every IP address is divided into two parts: a network portion (which network is this device on?) and a host portion (which device on that network?). The subnet mask determines where this split happens.

In CIDR notation, the split is written as a suffix. 192.168.1.0/24 means the first 24 bits are the network portion and the remaining 8 bits are for hosts. That gives you 2^8 = 256 addresses (254 usable, since the first is the network address and the last is the broadcast address).

What makes CIDR flexible is that the split can happen at any bit position, not just on octet boundaries. Need 1,000 addresses? Use a /22 block (1,024 addresses). Need 16? Use a /28. No more waste.

Practical CIDR Calculation

Let's work through 10.0.0.0/20:

Here's a reference table of common CIDR blocks:

Cloud Relevance

Cloud platforms like AWS, GCP, and Azure use CIDR blocks everywhere. When you create a VPC (Virtual Private Cloud), you define its IP range using CIDR. A VPC with 10.0.0.0/16 gives you 65,536 addresses. You then carve it into subnets: 10.0.1.0/24 for web servers, 10.0.2.0/24 for databases, 10.0.3.0/24 for internal services.

Choosing the right CIDR block size upfront matters. Too small, and you run out of addresses. Too large, and you waste address space that could conflict with other VPCs if you ever need to peer them.

But not all of these addresses work the same way. Some can reach the internet, and some can't.

The difference comes down to who can see the address. Some IPs are routable on the public internet. Others only work within a private network.

Public IP Addresses

A public IP address is globally unique and reachable from anywhere on the internet. When you visit a website, your request goes to a public IP. When someone pings your home network, they're hitting your public IP.

Public addresses are assigned by Regional Internet Registries (RIRs) and are a scarce resource. ISPs get blocks of public IPs and assign them to customers (usually dynamically, so your home IP changes periodically).

Private IP Addresses

Private IP addresses are reserved ranges defined in RFC 1918 that can be used freely within any private network. They are not routable on the public internet, which means a router on the internet will simply drop a packet destined for a private IP.

Your laptop right now probably has an IP like 192.168.1.x. Your neighbor's laptop might also be 192.168.1.x. That's fine because private addresses only need to be unique within their own network.

NAT: Bridging Private and Public

If private addresses can't reach the internet, how does your laptop browse the web?

Through NAT (Network Address Translation). Your home router has one public IP assigned by your ISP. When your laptop (say, 192.168.1.10) sends a request to 142.250.80.46 (Google), the router rewrites the source IP from 192.168.1.10 to its own public IP (say, 203.0.113.5). It keeps a translation table so it knows which internal device to forward the response back to.

NAT is what allowed the internet to keep growing long after IPv4 addresses should have run out. Billions of devices share a much smaller pool of public IPs.

Cloud Context

In cloud environments, the same public/private split applies. Your EC2 instances, Kubernetes pods, and RDS databases all get private IPs within the VPC. Only load balancers and NAT gateways get public IPs that face the internet. This is both a cost optimization (public IPs are limited and sometimes charged) and a security measure (internal services are unreachable from outside).

Still, NAT is a workaround, not a real solution. The actual fix for address exhaustion is IPv6.

IPv4's 4.3 billion addresses seemed massive in 1981. Today, there are over 15 billion connected devices, and that number keeps growing with IoT. Phones, laptops, smart thermostats, security cameras, cars, and industrial sensors all need IP addresses. NAT has stretched IPv4's lifespan, but it adds complexity, breaks certain protocols, and makes end-to-end connectivity harder.

IPv6 was designed to solve this permanently. With 128-bit addresses, it provides 2^128, or roughly 340 undecillion (3.4 x 10^38) addresses. That's enough to assign a unique IP to every atom on Earth's surface and still have addresses left over.

Address Format

An IPv6 address is written as eight groups of four hexadecimal digits, separated by colons:

That's long, so there are shortening rules:

So the address above becomes: 2001:db8:85a3::8a2e:370:7334

Adoption

IPv6 adoption has been gradual but steady. As of 2025, roughly 45-50% of Google's traffic comes over IPv6. Major ISPs and mobile networks have adopted it widely since mobile carriers were among the first to feel the pain of IPv4 exhaustion (every phone needs an IP).

The transition strategy most networks use is dual-stack: running IPv4 and IPv6 simultaneously. Devices prefer IPv6 when available but fall back to IPv4. This avoids a hard cutover and lets the transition happen gradually.

Address space aside, there are some reserved addresses you'll run into constantly as a developer.

Some addresses have special meaning. You'll see these regularly in development, debugging, and configuration.

A few of these deserve more context.

Loopback (127.0.0.1): The entire 127.0.0.0/8 range is reserved for loopback, but 127.0.0.1 is what everyone uses. When you run a web server locally and visit localhost:3000, your traffic never leaves your machine. It goes down the network stack, hits the loopback interface, and comes right back up. Useful for development and testing, and also for inter-process communication on the same host.

0.0.0.0: This means different things depending on context. In a server's bind address, 0.0.0.0:8080 means "listen on port 8080 on all network interfaces." In a routing table, 0.0.0.0/0 is the default route, the catch-all that matches any destination address.

Link-local (169.254.x.x): If your computer can't reach a DHCP server, it assigns itself an address in this range. Seeing 169.254.x.x on a device almost always means DHCP is broken or the network is misconfigured. In cloud environments though, 169.254.169.254 is a special metadata endpoint that instances use to query information about themselves.

Knowing what these addresses mean helps you debug faster. Seeing 169.254.x.x immediately tells you DHCP is the problem. Seeing 0.0.0.0 in a bind configuration tells you the service is listening everywhere.

All of this raises a question: once a packet has a destination IP, how does it get there?

When your computer sends a packet to 142.250.80.46, that packet doesn't take a direct path. It hops through a series of routers, each one making a forwarding decision based on its routing table.

Routing Tables and Longest Prefix Match

Every router maintains a routing table: a list of network prefixes and which next hop to forward matching packets to. When a packet arrives, the router compares the destination IP against all entries in the table and picks the most specific match. This is called longest prefix match.

For example, if a routing table has entries for 10.0.0.0/8 and 10.0.1.0/24, a packet destined for 10.0.1.15 matches both. The router picks /24 because it's more specific (longer prefix).

Hop-by-Hop Forwarding

No single router knows the complete path to the destination. Each router only knows the next hop. The packet gets forwarded one router at a time until it arrives.

A typical internet request passes through 10 to 15 routers. You can see the path yourself using traceroute:

TTL: Preventing Infinite Loops

What if routers have a misconfiguration and a packet ends up going in circles? The TTL (Time to Live) field prevents this. Every IP packet starts with a TTL value (usually 64 or 128). Each router decrements it by 1. When TTL hits 0, the router drops the packet and sends an ICMP "Time Exceeded" message back to the sender.

This is exactly how traceroute works: it sends packets with TTL=1, then TTL=2, then TTL=3, and so on. Each router along the path reports back when TTL expires, revealing the route.

BGP: The Glue of the Internet

At the large scale, the internet is a collection of Autonomous Systems (AS), each operated by a different organization (ISPs, cloud providers, large enterprises). BGP (Border Gateway Protocol) is how these systems exchange routing information and decide how to reach each other. BGP is what makes the internet work as a whole. It's also what breaks the internet when things go wrong.

In October 2021, Facebook accidentally withdrew all its BGP routes during a maintenance operation. Every router on the internet removed Facebook's network from their routing tables. Facebook, Instagram, and WhatsApp became completely unreachable for about six hours. Even Facebook's internal tools for fixing the problem relied on the same network that was down, turning a configuration mistake into a major incident.