IP addresses

An IP address is the number that tells the internet where to deliver a packet: 32 bits in IPv4, 128 in IPv6, attached to a network interface, not to a person or even a machine. Routers read its leading bits, the prefix, to pick the next hop; a port in the TCP or UDP header then picks the process. Most address trouble in real systems traces back to IPv4 running out: private ranges, NAT, shared carrier addresses and the habit of treating an address as an identity.

Picture it first: a flat in a housing society

You post a parcel to “Flat 1204, Tower B, Green Meadows, Bengaluru 560103”. The sorting office in Delhi reads only the start of the PIN code to send it south; the Bengaluru hub reads all of it to pick a delivery office; only the last postman cares about the flat. Nobody on the way needs to know who lives there.

Now a twist. Letters from all 900 flats leave with the society’s address on the back and a reference number from the front desk. Replies come back to the desk, which looks up the number and walks each letter to the right flat. Outsiders see one address and can’t write to flat 1204 directly.

Map it back:

• The postal address is an IP address, and the PIN code is the prefix: routers read only the leading bits they need, and the most specific match wins.
• The flat number is the port: it picks the process once the packet reaches the host.
• Your contacts list, which turns “Amma” into an address, is DNS.
• The front desk is NAT; a whole township sharing one desk is carrier-grade NAT, and the reference number is the translated port.
• The address belongs to the flat, not the resident. An IP address is a location, not an identity.

What an IP address identifies

IP, the Internet Protocol, is layer 3 in the OSI model: it moves packets between interfaces across many networks, best-effort. Every packet carries a source and a destination address, and every router on the path picks the next hop from the destination.

Three things are easy to mix up:

• A name such as api.example.com is for people and configuration. DNS turns it into addresses: A records for IPv4, AAAA for IPv6.
• An address such as 203.0.113.7 gets a packet to an interface.
• A port such as 443, in the TCP or UDP header, gets the data to one socket. A connection is the 5-tuple: source IP and port, destination IP and port, and protocol.

An address names an interface, not a device: your laptop has a loopback address, a Wi-Fi address and another whenever the VPN is up. Equally, one address can front thousands of machines, like a load balancer’s virtual IP or an anycast address announced from dozens of cities. And it describes where you are attached, so it changes when your phone moves from Wi-Fi to mobile data halfway through a UPI payment. A login session or payment intent must never be keyed on it.

IPv4: 32 bits that ran out

An IPv4 address is 32 bits, written as four octets in decimal, such as 203.0.113.7. Each octet runs from 0 to 255, so there are 2³² = 4,294,967,296 addresses, about 4.3 billion. Fewer are usable: multicast (224.0.0.0/4) and a reserved block (240.0.0.0/4) alone take 2 × 268,435,456 = 536,870,912, an eighth of the total.

IANA hands space to the five Regional Internet Registries (RIRs) in /8 blocks of 16,777,216 addresses, each 1/256 of the whole. On 3 February 2011 it gave out its last five /8s, one per RIR. The registries then rationed what they held; the RIPE NCC, serving Europe and the Middle East, made its final /22 allocation on 25 November 2019.

Three things followed, and you meet all of them in design:

• NAT everywhere, including carrier-grade NAT, so thousands of users share one public address.
• A price on addresses. Since 1 February 2024 AWS has charged $0.005 an hour per public IPv4 address: 0.005 × 730 hours = $3.65 a month, so 2,000 VMs with public addresses pay about $7,300 a month for numbers alone.
• IPv6, slowly.

CIDR: prefixes, masks and block sizes

Originally the first bits of an address fixed its class: class A held 16.7 million addresses, class B 65,536 and class C 256, so a company needing 2,000 got a class B and wasted over 63,000. CIDR, Classless Inter-Domain Routing (RFC 4632), replaced classes with an explicit prefix length.

10.0.9.5/21 means the first 21 bits are the network prefix, shared by the whole block, and the other 32 − 21 = 11 bits number hosts. The block holds 2¹¹ = 2,048 addresses, and its mask, 21 ones then 11 zeros, is 255.255.248.0.

A /n block holds 2^(32 − n) addresses, and each step of the slash halves or doubles it.

On a plain LAN the all-zeros host address names the network and the all-ones address is broadcast, so h host bits give 2^h − 2 usable addresses. AWS reserves five per subnet: the network address, .1 for the router, .2 for DNS, .3 for future use, and the last one. A /28 therefore gives you 16 − 5 = 11, not 14.

Longest-prefix match: how routers choose

A router’s table maps prefixes to next hops, and prefixes nest: 10.20.9.5 is inside 10.20.8.0/21, inside 10.20.0.0/16, inside 10.0.0.0/8, inside the default route 0.0.0.0/0. RFC 4632 states the rule: forwarding is on a longest-match basis, so the entry with the most matching bits wins.

Longest-prefix match keeps routing tables small: an ISP announces one /16 instead of 256 /24s, and your VPC needs one default route, not a route per address.

It has a sharp edge too: a more specific announcement attracts the traffic. RFC 4632’s example is a provider announcing 192.168.16.0/20 while someone else announces 192.168.17.0/24; traffic for 192.168.17.100 follows the /24. That is how route hijacks divert traffic for big services, and the defences are route filters between providers, not your code. Inside your own network, one overly broad route to a VPN or peered VPC quietly captures traffic meant for elsewhere.

Special ranges you should recognise

Some blocks are set aside for a purpose; IANA’s special-purpose registry lists them.

Two rows cause real incidents.

Why carrier NAT got its own block. A carrier gives subscribers’ home routers internal addresses and translates them to public ones. RFC 1918 space wouldn’t work, because the home router’s LAN side may already use 192.168.1.0/24 or 10.0.0.0/8, and the same prefix on both sides of a router breaks routing; nor could each carrier get millions of public addresses. So in 2012 RFC 6598 reserved one /10 for every carrier to reuse. If your service logs a client at 100.64.x.x, something on your own side is translating.

The metadata address. 169.254.169.254 is where a cloud VM fetches its own configuration, including, on AWS, temporary credentials for its role. Only the instance can reach it, which is exactly why attackers want your server to fetch it for them.

NAT: many devices behind one public address

Network address translation lets a private network share a few public addresses. Source NAT (SNAT) works like the society’s front desk:

1. A laptop at 192.168.1.20 connects from port 51000 to 198.51.100.10:443.
2. The NAT rewrites the source to its public address and a free port, and records the mapping.
3. The reply arrives at that address and port; the NAT looks up the mapping and rewrites the destination back to 192.168.1.20:51000.

Two consequences follow. Connections can start only from inside, since an unsolicited packet matches no entry; that is why a phone can’t run a server, why video calls need STUN and TURN servers, and why people mistake NAT for a firewall. And the mapping lives in the NAT box, so when it restarts or an idle mapping expires, long-lived connections such as WebSockets die silently unless something sends keep-alives.

Carrier-grade NAT: what your server actually sees

Mobile carriers put many subscribers behind each public IPv4 address. A phone on 4G gets an address from 100.64.0.0/10, and so may a home broadband router, so a laptop behind it is translated twice.

From your side of the internet, all those users arrive from one address, told apart only by port. That breaks several habits:

• Per-IP rate limits lump strangers together: 100 a minute shared by 500 phones leaves each 0.2, and during a Flipkart-style sale the busiest carrier gateway looks like your worst abuser. Key on the account or device as soon as you can; see rate limiting.
• Blocking one abusive address blocks every innocent user behind that gateway, sometimes a whole campus.
• Abuse tracing needs the port. A carrier can name a subscriber only from the address, source port and exact time, so log all three at your edge.
• Behind your own load balancer the app sees the balancer’s address. The client’s travels in X-Forwarded-For or the PROXY protocol, and only entries your own proxies appended can be trusted; see proxy vs reverse proxy.

SNAT port exhaustion in the cloud

Your servers sit behind NAT too: private instances reach the internet through a cloud NAT gateway, whose budget is ports.

A port is 16 bits, so an address has 65,536 TCP ports and 65,536 UDP ports; without the privileged ports 0 to 1,023, Google Cloud NAT gets 64,512 per address per protocol. Because a connection is the whole 5-tuple, one public port can be reused towards different destinations, so the real limit is per destination (IP, port and protocol):

• An AWS NAT gateway supports 55,000 simultaneous connections per public IPv4 address to each unique destination, with up to 8 addresses.
• Google Cloud NAT, with default static allocation, gives each VM 64 ports, so 64 simultaneous connections to any one destination, and one address serves 64,512 ÷ 64 = 1,008 VMs.

The failure looks odd from inside: CPU is idle and the partner is healthy, yet new connections time out at peak, towards the one dependency everybody calls. Closed connections make it worse, because Cloud NAT holds a port through TCP’s TIME_WAIT (see TCP vs UDP). Fixes, cheapest first: reuse connections with keep-alive or HTTP/2, size pools to real need, add NAT addresses (another 55,000 each on AWS), and reach cloud services over private endpoints that skip the NAT.

IPv6: 128 bits and no scarcity

IPv6 (RFC 8200) raises the address size from 32 to 128 bits: 2¹²⁸, about 3.4 × 10³⁸ addresses. What matters is what that allows: every device can have a globally unique address again, and every LAN gets more addresses than it will ever use.

Reading an address

An IPv6 address is eight 16-bit groups in hexadecimal, separated by colons. RFC 4291 allows shortcuts, and RFC 5952 fixes one canonical form so logs and allowlists compare cleanly: drop leading zeros in each group, replace the longest run of zero groups with :: (once only, and never for a single group), and write hex in lower case. So 2001:0db8:0000:0000:0000:0000:0000:0001 becomes 2001:db8::1. In a URL, brackets stop the colons being read as a port: https://[2001:db8::1]:8443/.

The /64 rule

For almost all unicast addresses, RFC 4291 makes the last 64 bits the interface ID, so an ordinary subnet is a /64. A site typically gets between a /48 and a /56 from its provider (RFC 6177 dropped the old one-size /48 default) and numbers its subnets with the bits in between.

A /48 holds 2¹⁶ = 65,536 /64 subnets, and each /64 holds 2⁶⁴, about 1.8 × 10¹⁹ addresses. AWS lets you size IPv6 subnets from /44 to /64 in steps of 4, again reserving five addresses in each.

Hosts usually pick their own interface ID, and phones and laptops rotate it for privacy, so one device shows up from many addresses in its /64 and a determined client can use as many as it likes. That is why abuse controls key IPv6 clients on the /64, which maps to one LAN, household or phone connection.

Address types you will see

• Global unicast: public, routable addresses.
• Link-local, fe80::/10: every interface has one, valid only on its link, like 169.254.0.0/16.
• Unique local, fc00::/7 (in practice fd00::/8 plus a random 40-bit ID): private space that, thanks to the random ID, rarely collides when two networks merge.
• Multicast, ff00::/8. IPv6 has no broadcast.
• Loopback ::1 and the unspecified address ::.

No NAT is needed, which removes the port budget and the shared addresses. It doesn’t remove the firewall: a stateful firewall allowing outbound connections and their replies gives the “nothing can call in” property people credited to NAT, this time on purpose.

Dual stack and Happy Eyeballs

Most networks run dual stack: hosts have both families and names publish A and AAAA records. Trying IPv6 and waiting out a timeout on a broken path would hang for seconds, so clients race the families. Happy Eyeballs v2 (RFC 8305) recommends:

1. Send the AAAA and A queries together.
2. If the A answer arrives first, wait up to 50 ms for AAAA, to give IPv6 a fair chance.
3. Connect to the first address, preferring IPv6. If it hasn’t connected within 250 ms (with recommended bounds of 100 ms and 2 seconds), start the next one, alternating families, without cancelling the first.
4. Keep whichever connects first.

So a broken IPv6 path costs a user about a quarter of a second, which also means it hides: your IPv6 front door can be broken for days while dashboards look fine. Monitor both families. IPv6-only hosts reach IPv4-only services through NAT64 with DNS64, which AWS NAT gateways support.

On 25 October 2026, about 49.6% of users reached Google over IPv6, per Google’s IPv6 statistics; over the previous four weeks it sat near 46% on weekdays and 50 to 52% on Saturdays. Its country map put India near 70% and the United States near 55%. If your CDN publishes AAAA records, half your users may arrive over IPv6, and every IP-keyed system, from rate limits and allowlists to logs and database columns, must handle 128-bit addresses.

Unicast, anycast, multicast and broadcast

RFC 4291 sorts addresses by who receives the packet. Unicast goes to one interface: almost all your traffic. Anycast is one address announced from many places, and the network delivers each packet to the nearest by routing distance. Multicast delivers a copy to every member of a group, as in IPTV and market data feeds. Broadcast reaches everyone on the local link; it exists only in IPv4, where DHCP uses 255.255.255.255 to find a server.

Anycast is the one that shapes designs. DNS root servers, public resolvers and CDNs announce one prefix from many sites with BGP, so users in Chennai and Frankfurt connect to the same address and land on different machines. You gain nearest-site routing with no client logic, failover by withdrawing a route, and attack traffic spread across every site. You pay with coarse control and the occasional route change that moves a live TCP connection to a site that has never seen it. See DNS and CDNs.

Addresses in the cloud

Who assigns an address

On a LAN, DHCP leases each host an address and renews it; if DHCP fails, the host self-assigns a 169.254.x.x address, a sure sign DHCP is broken. In a cloud, a VM’s private address lasts as long as its network interface. An auto-assigned public IP on AWS is released when the instance stops and replaced on start; an Elastic IP, or a reserved static IP on Google Cloud, stays until you release it, and belongs in partners’ allowlists.

Plan VPC ranges as a shared resource

An AWS VPC block must be between a /16 (65,536 addresses) and a /28 (16). The trap is not size but overlap. Tutorials suggest 10.0.0.0/16 and every account’s default VPC is 172.31.0.0/16, so teams end up with identical ranges, which works until two networks must talk:

• AWS refuses to peer VPCs whose blocks match or overlap.
• Over a VPN or transit gateway, 10.0.3.7 matches a local route on both sides, so the remote copy is unreachable.
• After an acquisition, joining networks means renumbering one or putting NAT between them.

So allocate centrally. Carve 10.0.0.0/8 into its 256 /16s and hand one to each account and region from a registry (a spreadsheet works; cloud IPAM tools do better). Inside each /16, use a /20 per availability zone per tier, 4,091 usable addresses on AWS, as AWS’s own default VPC does, and leave room to grow.

Kubernetes eats addresses

Every pod gets its own IP, and the pod range is often the first thing to run out. On GKE the default of 110 pods per node gives each node a /24, more than twice the pod count so addresses aren’t reused at once. A /21 pod range holds 2^(24 − 21) = 8 of those, so the cluster stops at 8 nodes whatever your quota, and the range is fixed at creation. On EKS the default VPC CNI gives every pod a VPC address, so a busy cluster can drain its subnets until new pods can’t start. Size pod and service ranges for the cluster you’ll have in two years.

Going deeper: addresses in design decisions

Fixed egress IPs for partners

Banks, payment networks and enterprise customers often accept calls only from allowlisted addresses, but your pods change address on every deploy. Send partner traffic through NAT gateways or egress proxies with static IPs, usually one per availability zone, and register them all. You gain a stable network identity partners insist on. You pay with a choke point carrying the port budget above, weeks of notice whenever an address changes, and the temptation to treat the allowlist as authentication; keep mTLS or signed requests too. In reverse, publish the ranges your webhooks come from.

Use names, not hard-coded addresses

Cloud addresses change as instances are replaced, load balancers scale and failover moves regions. A name adds indirection, so DNS or service discovery can repoint it without a deploy, and TLS certificates are issued for names, so a bare IP usually means switching off hostname checks. The exceptions are bootstrap pieces such as resolver addresses, and allowlists.

An IP is a weak identity

NAT merges users, IPv6 spreads one user across many addresses, VPNs move users anywhere, and phones change address as they roam. Geolocation is a best guess: a carrier-NAT or VPN user is placed where the gateway is, perhaps another city or country. Use addresses for decisions that tolerate mistakes: edge rate limits, abuse heuristics, one fraud signal among several, a guess at the nearest region. Use tokens for users and mTLS between services for anything that matters.

Cheat sheet

How to say it in the interview

“An IP address identifies a network interface so packets can be routed to it; DNS maps names to addresses and the port picks the process. Addresses come in CIDR blocks and routers use the longest matching prefix. Since IPv4 ran out, most clients reach us through NAT, often carrier-grade, so one source address can be thousands of users, while on IPv6 one user can have many. So I use client IPs only for coarse edge limits, per /64 on IPv6, and authenticate with tokens. Inside, each VPC gets a non-overlapping /16 from a central plan, partner traffic leaves through NAT gateways with fixed IPs, I budget NAT ports for hot dependencies, and we publish both A and AAAA records.”

How many hosts in a /20? 2^(32 − 20) = 2¹² = 4,096 addresses: 4,094 usable on a plain LAN, 4,091 in an AWS subnet.

Why rate-limit IPv6 per /64? A /64 is one subnet, usually one household or phone, and the host picks and rotates its own 64-bit interface ID. Per address, one client gets 2⁶⁴ fresh counters; per /64, just one.

What breaks if two VPCs both use 10.0.0.0/16? AWS won’t peer them, and over a VPN each side’s local route wins, so the other side is unreachable. The cure is renumbering or NAT between them; prevention is a central address plan.

A user on mobile data calls your API. Which source IP do you see? The phone has a 100.64.x.x address; the carrier’s NAT rewrites it to a public address and port shared with many subscribers. Your load balancer sees that address and passes it in X-Forwarded-For, where the app reads the entry your proxy appended. To identify the user, use the token.

Pods time out calling one partner API at peak, but CPU is fine. Why? Likely NAT port exhaustion: AWS allows 55,000 connections per NAT IP to one destination, and 600 pods with 100-connection pools need 60,000. Reuse connections, shrink pools or add NAT addresses.

Where to go next

• Domain Name System (DNS): how names become these addresses, and anycast in depth.
• The OSI model: where IP sits between links and transports.
• TCP vs UDP: ports, the 5-tuple and TIME_WAIT.
• Load balancing: L4 vs L7: virtual IPs and what each layer sees of the client.
• Proxy vs reverse proxy: X-Forwarded-For, the PROXY protocol and egress proxies.
• Rate limiting: choosing keys when addresses are shared or plentiful.
• Content delivery network (CDN): anycast front doors at the edge.
• Multi-tenancy and isolation: network boundaries between customers.

References and further reading

1. RFC 4632 — Classless Inter-domain Routing (CIDR)rfc-editor.orgPrefix notation, the block-size table from /32 to /0, longest-match forwarding, and how a more specific announcement can hijack traffic.
2. RFC 1918 — Address Allocation for Private Internetsrfc-editor.orgThe three private blocks, 10/8, 172.16/12 and 192.168/16, and why they must never be routed between enterprises.
3. RFC 6598 — IANA-Reserved IPv4 Prefix for Shared Address Spacerfc-editor.orgWhy carriers needed 100.64.0.0/10 for carrier-grade NAT instead of reusing RFC 1918 space.
4. IANA IPv4 Special-Purpose Address Registryiana.orgLoopback, link-local, shared, documentation, reserved and broadcast blocks, each flagged as globally reachable or not.
5. RFC 4291 — IP Version 6 Addressing Architecturerfc-editor.org128-bit addresses, text forms with ::, 64-bit interface IDs, link-local fe80::/10, and unicast, anycast and multicast with no broadcast.
6. RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrencyrfc-editor.orgRacing IPv6 and IPv4: a 50 ms resolution delay and a 250 ms connection attempt delay, bounded by 100 ms and 2 seconds.
7. Amazon VPC User Guide — Subnet CIDR blocksdocs.aws.amazon.comIPv4 subnets from /16 to /28, the five reserved addresses in every subnet, and IPv6 subnets from /44 to /64.
8. Google Cloud NAT — IP addresses and portscloud.google.com64,512 source ports per NAT address, the default of 64 ports per VM, per-destination connection limits and the 1,008-VMs-per-address arithmetic.
9. Google IPv6 statisticsgoogle.comShare of users reaching Google over IPv6 (about 49.6% on 25 October 2026) and the per-country adoption map.
10. NRO — Free pool of IPv4 address space depleted (3 February 2011)nro.netIANA’s last five /8 blocks, each 1/256 of the IPv4 space, went one to each Regional Internet Registry.