Subnet and CIDR Basics for IP Range Lookups

CIDR notation writes a block of addresses as a starting address and a prefix length: 203.0.113.0/24. The number after the slash is how many leading bits of the 32-bit IPv4 address are fixed; the remaining bits vary across the block. With 24 bits fixed, 8 bits vary, so 203.0.113.0/24 covers the 256 addresses from 203.0.113.0 to 203.0.113.255. A smaller prefix length means fewer fixed bits and a larger block, which is why a single /16 rule can cover 65,536 addresses.

The notation comes from Classless Inter-domain Routing (RFC 4632), which replaced the old class A, B and C boundaries with prefixes of any length so that address space could be assigned and routed in blocks that fit real needs; a /24 is still called a class C in conversation, but the registry, the routing table and your firewall all speak in prefixes. A subnet mask is the same boundary written as an address: 255.255.255.0 is the mask form of /24, with the same 24 leading bits set.

The 203.0.113.0/24 block used throughout this guide, along with 192.0.2.0/24 and 198.51.100.0/24, is reserved by RFC 5737 for documentation, so none of these examples point at a real network.

The size of a block is two to the power of the number of varying bits: 2 to the power of (32 minus the prefix length) for IPv4. The table below lists the sizes you will meet most often in lookups, firewall rules and provider range lists.

Two footnotes apply to the host counts. Inside a routed subnet, the all-zeros address names the network and the all-ones address is the broadcast address (RFC 950), so a /24 used as a LAN has 254 assignable hosts rather than 256; point-to-point links are the exception, where RFC 3021 lets a /31 use both of its addresses. For a lookup or a blocking rule none of this matters: a rule for a /24 matches all 256 addresses.

For prefixes between /25 and /32 the block size shows up in the last octet, and blocks always start at a multiple of their size. Take 203.0.113.64/26: a /26 leaves 6 varying bits, so the block holds 64 addresses and starts at a multiple of 64, which puts it at 203.0.113.64 through 203.0.113.127. The address 203.0.113.77 falls inside it; 203.0.113.130 does not, because it belongs to the next /26 starting at 128.

For prefixes between /17 and /23 the same arithmetic moves to the third octet: a /22 covers four consecutive third-octet values, so 203.0.112.0/22 runs from 203.0.112.0 to 203.0.115.255. Most IP lookup tools and registry records do this for you by showing the containing block, but being able to check by hand is what lets you spot a rule that was written one bit too wide.

IPv6 addresses are 128 bits long and use the same slash notation. The prefix that matters most is the /64: RFC 4291 sets the interface identifier at 64 bits for ordinary unicast addresses, so a /64 is one subnet, the network behind one router, and a single device inside it can hold many addresses at once, which is why one laptop can appear as dozens of IPv6 addresses in a day and why counting IPv6 addresses the way you count IPv4 addresses overstates everything.

End sites are assigned larger blocks than one subnet. RFC 6177 describes the practice of giving a site a /48 or a /56, which contain 65,536 and 256 subnets respectively, so a home or small office behind one connection may legitimately use any address in a /56. For rate limits and blocks, the practical unit is the /64 for one network and the /56 or /48 for one subscriber, a point the IPv4 and IPv6 privacy guide and the API rate limiting guide both rely on. The 2001:db8::/32 block is reserved for documentation by RFC 3849, the IPv6 counterpart of the examples above.

Addresses are allocated, routed and published in blocks, so almost every piece of context you can attach to one address is really a property of its range. A WHOIS or RDAP record describes the allocated block and its holder, an autonomous system announces whole prefixes to the routing table, and cloud providers publish their address space as lists of CIDR ranges, which is how data-center and hosting addresses are identified. Attackers who rotate through a hosting account's addresses stay inside one of those blocks, which is what makes range-level analysis worthwhile.

The same fact cuts the other way. A /24 can be split among many customers of one provider, and behind carrier-grade NAT a single address in the 100.64.0.0/10 shared space (RFC 6598) can stand for thousands of subscribers; the CGNAT guide explains why. Private ranges such as 10.0.0.0/8 and 192.168.0.0/16 (RFC 1918) never appear on the public internet at all, so a log entry that shows one means the address was recorded on the wrong side of a proxy or load balancer. The reserved and special-purpose address guide lists the full set of ranges a lookup will not place anywhere.

Match the width of a rule to the width of the evidence: one abusive address justifies a /32, a pattern across a hosting customer's block justifies that block as the registry defines it, and nothing short of an operator-wide problem justifies a whole provider allocation. Before widening any rule, run the range through an IP lookup and the registry record to see whether it is one organisation's block or a shared mobile or CGNAT pool where one address already means many users, give every range rule an expiry, and review the ones that keep matching. The firewall blocking guide covers temporary versus permanent rules, allowlists, and the collateral damage that broad range blocks cause.