The address space ran out and nobody noticed

In September 1981, RFC 791 gave the internet 32 bits of address space — 4,294,967,296 addresses, for a network that then had a few hundred hosts. It looked like more than anyone could ever need. The last of them left the free pool in 2011, they now trade on an open market at about twenty dollars each, and as of this spring more than half of Google's traffic does not use them at all.

Most of that happened without anyone outside networking noticing, because the workarounds were very good. Here is the actual shape of it, what genuinely differs between the two protocols, and the part people get wrong about sizing a subnet.

Four billion seemed like a lot

The original scheme was classful. The first bits of an address told you how big its network was: a class A took the first octet and left you 16.7 million hosts, a class B took two octets and left 65,534, a class C took three and left 254. Three sizes. That was the menu.

If you had 300 machines you were too big for a class C and got a class B — and quietly wasted 65,000 addresses. Multiply that by every university and corporation on the early internet and the arithmetic gets ugly fast. The space was not being consumed so much as spilled.

Classless Inter-Domain Routing fixed it in 1993. RFC 1519 threw away the fixed classes and let the boundary fall anywhere, which is where the slash notation comes from: the number after the slash is simply how many leading bits identify the network. Your 300 machines get a /23 — 512 addresses — instead of a /16. Every allocation since has worked this way, and "class C" has been a historical term for thirty years even though people still say it.

Two more changes bought the real time. RFC 1918 in 1996 set aside three blocks — 10/8, 172.16/12 and 192.168/16 — that anyone may use privately because no one routes them. And NAT let an entire building hide behind one public address. Together they turned an address shortage into an address abstraction, which is why your home network has thirty devices and one public address, and why nothing broke.

Running out, slowly and then all at once

The free pool drained on a schedule that was predicted years in advance and still felt abrupt when it arrived:

IANA free pool        31 Jan 2011
APNIC   (Asia-Pacific) 15 Apr 2011
LACNIC  (Latin America)10 Jun 2014
ARIN    (North America)24 Sep 2015
AFRINIC (Africa)       21 Apr 2017
RIPE NCC(Europe)       25 Nov 2019

What replaced allocation was a market. In the first half of 2026 roughly 29.7 million addresses changed hands at an average of $20.04 each — large blocks nearer $13–16, small ones $18–24. That is a long way down from the late-2021 peak of about $60, and 35.7% below the first half of 2025. The biggest single cause is unglamorous: AWS began charging for public IPv4 addresses in 2024, which turned hoarded space from free inventory into a line item, and a lot of it came back to market.

Meanwhile ARIN still runs a waiting list, and in 2026 the wait is still measured in more than a year for a maximum of a /22.

IPv6 and the eighteen-year wait

IPv6 was specified in 1998 (RFC 2460, since replaced by RFC 8200) with 128 bits instead of 32. That is not four times the space, it is 2^96 times: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. Enough to give every grain of sand on earth its own internet, several times over.

Adoption then took its time. World IPv6 Launch was 2012. And on 28 March 2026, eighteen years after Google started measuring, IPv6 finally crossed half of Google's users at 50.10% — having come within a rounding error the previous June at 49.56%.

Treat that number carefully. Google measures its own users; APNIC Labs puts global capability nearer 42% and Internet Society Pulse at 43%, because they weight differently — and none of them see China clearly. The national spread is enormous: France 73%, India 72%, Saudi Arabia 65%, against Italy 17%, Spain 10% and Egypt 4%. Whether IPv6 is "the majority" depends entirely on who you are asking about.

What actually differs

More than the address length, and less than people expect.

• The header got simpler. IPv4's is 20 to 60 bytes with variable options; IPv6's is a fixed 40 bytes, with anything optional pushed into extension headers. Fixed-size headers are cheaper to process in hardware.
• There is no broadcast. IPv6 dropped it entirely in favour of multicast and anycast. This is why a v6 subnet has no broadcast address to lose.
• ARP is gone. Neighbour Discovery runs over ICMPv6 instead — which means filtering ICMPv6 the way people reflexively filter ICMP will break your network rather than harden it.
• Routers no longer fragment. In IPv4 any router may fragment a packet; in IPv6 only the sender may, so path MTU discovery stops being optional.
• The header checksum went away. The link layer below and the transport layer above both already checksum, so IPv6 stopped paying for it a third time.
• Autoconfiguration is built in. SLAAC lets a host build its own address from a router advertisement and its interface identifier, with no DHCP server at all.
• NAT is largely unnecessary. Which is the actual culture shock: every device can hold a globally routable address again, the way the internet was originally designed.

Subnet sizing, the part that trips people

The whole of subnetting is one idea: the prefix says how many leading bits identify the network, and everything left over identifies hosts. A /24 leaves 8 host bits, so 2^8 = 256 addresses. Every bit you take for the network halves the block; every bit you give back doubles it.

The wrinkle is that IPv4 spends two of those addresses on the network and broadcast addresses, so usable hosts is two fewer than total:

prefix   addresses   usable   typical use
/30          4         2     point-to-point (the old way)
/31          2         2     point-to-point (RFC 3021)
/29          8         6     a handful of servers
/28         16        14     small VLAN
/27         32        30
/26         64        62
/25        128       126
/24        256       254     the default office LAN
/23        512       510
/22      1,024     1,022     the smallest block ARIN will issue

Two exceptions are worth knowing. A /32 is a single host — a loopback, a route, one address. And a /31 has both of its addresses usable, because RFC 3021 recognised that a point-to-point link has exactly two ends and needs neither a network nor a broadcast address. That halves the waste on every router-to-router link you own, and every piece of equipment made this century supports it.

If you need two hosts, you need a /31. If you need three, you need a /29 — because a /30 only has two usable addresses.

That jump surprises people every time. There is no size between them: /30 gives you 2 usable and /29 gives you 6, so the moment a link needs a third address you are buying eight.

IPv6 sizing is a different question

In IPv6 you almost never size a subnet by host count, because every LAN gets a /64 — SLAAC requires 64 bits of interface identifier, so going smaller breaks autoconfiguration. A /64 holds 18,446,744,073,709,551,616 addresses for the fifteen devices on your desk, and that is fine. The space is not scarce.

So the planning question changes from "how many hosts fit" to "how many /64s do I get". A site typically receives a /48 (65,536 subnets) or a /56 (256 subnets), and you spend those on VLANs, sites and floors rather than counting machines. Subnetting IPv6 is an exercise in organisation, not conservation.

So I built the calculator

All of the above is arithmetic I have done on the back of an envelope too many times, so it is now a page: NetCalc.

It reports the address your request actually arrived from — read from the connection, not from a third-party lookup service, so nothing about you goes anywhere else. It does CIDR maths for both families, including the binary and hex views and the reverse-DNS zone. It splits a block into equal subnets, plans VLSM from a list of host counts, and summarises an arbitrary start-and-end range into the fewest CIDR blocks that cover it exactly — the operation firewall rules and BGP filters actually want. It converts IPv6 text forms, derives EUI-64 identifiers from a MAC, and classifies any address against the special-purpose registries, so it will tell you that 100.64.0.1 is carrier-grade NAT rather than leaving you to remember.

Every calculation runs server-side, which means the query string is the whole state of the page: /tools/netcalc?cidr=10.0.0.0/22&hosts=50,20,10,2 is a link you can send someone. It also means the maths is unit-tested rather than trusted, which after the week I have had feels like the right instinct.

The page also carries the commands worth remembering on Windows, Linux and macOS, and the applications worth installing. If your habit is still ifconfig and netstat on Linux, both have been superseded by ip and ss for years, and the newer tools report things the old ones simply cannot.

If you find a number it gets wrong, tell me — that is exactly the sort of bug worth hearing about.