CIDR Notation Explained (e.g., 203.0.113.0/24)
This guide covers: CIDR Notation Explained (e.g., 203.0.113.0/24).
Before CIDR, the internet was running out of addresses faster than anyone could allocate them, and the global routing table was about to overflow the memory of every router on the planet. That was 1993. The fix shipped as a pair of RFCs that quietly rewrote how IP allocations worked, and the slash-number you see after every IP today is what came of it. Reading CIDR fluently is one of those skills that pays off every time you look at a firewall rule, a BGP announcement, an ISP WHOIS record, or a cloud VPC config — which is to say, more or less constantly. The notation is short on purpose. The story behind it is anything but.
Why CIDR exists at all
IPv4 originally used a classful system: any address starting with bits in a particular range was automatically a Class A (/8, 16.7 million hosts), Class B (/16, 65,536 hosts), or Class C (/24, 254 hosts). The classes existed to make routing decisions trivially simple in 1981 hardware. They also wasted addresses on a colossal scale. A medium-sized company that needed 5,000 IPs got handed a Class B with capacity for 65,536, and the other 60,000 sat unused on its books for years. By the early 1990s the Internet Engineering Task Force was projecting IPv4 exhaustion within five years and the BGP table was growing faster than commodity router silicon could absorb.
RFC 1518 and RFC 1519, published together in September 1993, killed the classes and replaced them with prefix-length notation. Now any block could be any size on any bit boundary. ARIN could hand a company a /22 (1,024 addresses) instead of a Class B, cutting the waste by an order of magnitude. ISPs could aggregate their customer routes into a single upstream announcement, cutting the routing-table burden by another order. The notation was awkward for the first decade — older equipment kept using subnet masks for years — but the math underneath has been the same for thirty years.
IPv4 still ran out anyway. ARIN exhausted its general free pool in September 2015, RIPE NCC followed in November 2019, and APNIC and LACNIC ran out earlier. The current secondary market trades IPv4 addresses at around fifty to sixty dollars per address as of 2025; a small /24 changes hands for fifteen thousand dollars. CIDR did not save IPv4 forever. It bought thirty years of breathing room while the IPv6 transition stumbled forward, and it left the internet with a routing system that still works at scale.
What the slash number actually does
An IPv4 address is 32 bits. The slash number is the number of those 32 bits that count as the network portion; whatever is left counts as host bits. /24means "the first 24 bits are the network, the last 8 are addresses inside it." Eight host bits give you 28 = 256 addresses, of which two are reserved (network and broadcast), leaving 254 usable host addresses. The whole table follows from that single rule.
Memorize a few anchor points and you can size any block in your head:
/32= 1 address. A single host route. You see this constantly in firewall rules where you need to permit or deny one specific IP./31= 2 addresses, both usable. RFC 3021 carved out this special case for point-to-point links so neither address has to be wasted on a network or broadcast value./30= 4 addresses, 2 usable. The classic point-to-point WAN subnet from the pre-3021 era./29= 8 addresses, 6 usable. Common for small ISP hand-offs and dedicated server hosting./28= 16 addresses, 14 usable. Small office subnets, management VLANs, point-of-sale segments./27= 32 addresses, 30 usable. A slightly bigger office segment./24= 256 addresses, 254 usable. The unit of measurement for most ISP-level conversations and the smallest prefix most BGP peers will accept./22= 1,024 addresses, four/24s combined. A mid-sized ISP allocation./16= 65,536 addresses. Cloud VPC default, large campus networks./8= 16,777,216 addresses. Tier-1 ISP allocations, historical Class A blocks held by IBM, Apple, the US DoD, etc.
Notice the inversion that trips up beginners constantly: a bigger slash number means a smaller network. /24 is sixteen times larger than /28, even though 28 is the bigger number. The slash counts the fixed bits, not the variable ones.
Subnet masks are the same thing, written longer
Older equipment and tutorials still use dotted-decimal masks like 255.255.255.0. That is just the prefix length expressed as the actual 32-bit pattern, with all the network bits set to 1 and the host bits set to 0. The two notations are interchangeable:
/8=255.0.0.0/16=255.255.0.0/24=255.255.255.0/25=255.255.255.128/26=255.255.255.192/27=255.255.255.224/28=255.255.255.240/30=255.255.255.252
Every modern tool accepts either form. CIDR has won decisively in practice — it is shorter, less error-prone, and impossible to get wrong by accidentally setting a non-contiguous bit pattern (which the mask form theoretically allows but no real network would ever deploy). Use CIDR when you write rules for humans to read; the only reason to type subnet masks anymore is when a piece of legacy gear forces you to.
How to calculate a CIDR block by hand
Three quick mental tricks cover almost every CIDR question that comes up in real work.
How many addresses? 2(32 minus prefix) for IPv4. /26 gives 26 = 64 addresses, of which 62 are usable for hosts.
Where are the boundaries? Find the octet where the prefix lands and figure out the step size in that octet. A /22 sits inside the third octet (between 16 and 24); the third-octet step size is 2(24 minus 22) = 4. So /22 blocks march in steps of 4 in the third octet: 198.51.96.0/22 covers 198.51.96.0 through 198.51.99.255. A /28 is inside the fourth octet; the step size is 2(32 minus 28) = 16, so /28 blocks march in steps of 16 in the last octet.
Are two IPs in the same block? Apply the prefix as a mask to both, compare the results. If they match, the IPs are in the same block. Mental shortcut for human-readable cases: for a /24, the first three octets must match. For a /16, the first two. For a /26, the first three octets match and the fourth must round to the same multiple of 64.
For anything more complex, reach for a tool. ipcalc and sipcalcon Linux give you full breakdowns from the command line. Python's ipaddress module in the standard library is excellent for scripted work: ipaddress.ip_network("198.51.96.0/22").num_addresses returns 1024 in one line. Wireshark accepts CIDR in display filters directly.
Where you see CIDR in the wild
- Regional registry allocations. ARIN, RIPE, APNIC, AFRINIC, and LACNIC describe every IP block in CIDR. Run a WHOIS / RDAP query on any public IP and the response includes the surrounding CIDR block, the assignee, and the abuse contact.
- BGP announcements. Tier-1 and regional networks announce reachable prefixes in CIDR form. The size of the prefix is one of the inputs to whether a route gets accepted by upstream peers — anything more specific than
/24for IPv4 or/48for IPv6 is usually filtered out at the major transit boundaries. - Firewall rules. Allow or deny lists almost always use CIDR.
iptables -A INPUT -s 10.0.0.0/8 -j ACCEPTmatches every RFC 1918 ten-dot address.nft add rule inet filter input ip saddr 192.0.2.0/24 acceptin the modern nftables syntax does the same. AWS security groups, Azure NSGs, and GCP firewall rules all consume CIDR natively. - Cloud VPCs. AWS, Google Cloud, and Azure all ask for a CIDR block when you create a virtual network. The choice you make is hard to reverse — VPCs cannot be resized in place — so the picking matters.
- Threat-intelligence feeds. Spamhaus, FireHOL, Talos, and dozens of smaller blocklist services publish attacker-associated ranges in CIDR so operators can ingest them straight into firewalls.
- Geolocation databases. MaxMind, IP2Location, and IPinfo all express their data in CIDR. Each block has an associated country, ASN, and city guess.
Reserved CIDR blocks worth recognizing on sight
A handful of IPv4 ranges are special. Knowing them by heart speeds up log review and saves you from chasing IPs that cannot possibly appear on the open internet.
10.0.0.0/8,172.16.0.0/12, and192.168.0.0/16— RFC 1918 private space. Never routed publicly. If you see one in a public log, the source is spoofing or the upstream is broken.100.64.0.0/10— RFC 6598, dedicated CGNAT. If a public IP lookup returns something inside this range, the user is behind carrier-grade NAT, almost certainly on a mobile network.127.0.0.0/8— loopback. Only127.0.0.1gets used in practice but the entire /8 is reserved for the local host.169.254.0.0/16— link-local autoconfiguration (APIPA). When DHCP fails, the OS picks an address from this range. Seeing it in a network details panel means the device never got a real lease.192.0.2.0/24,198.51.100.0/24,203.0.113.0/24— TEST-NET blocks reserved for documentation and examples. Never appears in real traffic. If you see one in a log, somebody is testing or spoofing.224.0.0.0/4— multicast. Used for protocols like OSPF, IGMP, mDNS. Not assignable to hosts.240.0.0.0/4— historically reserved "future use." Has been the subject of recurring proposals to unlock as additional unicast space; none have shipped because deploying support across every existing TCP/IP stack is impossible.
CIDR for IPv6, where the math gets airy
IPv6 addresses are 128 bits. The CIDR notation is identical, the numbers are absurd. A typical end-site allocation is a /48 giving the customer 280 addresses, an amount roughly equal to the entire IPv4 address space squared. Inside that allocation the standard subnet size is /64, which is a hard convention rather than a mathematical requirement. Stateless Address Autoconfiguration depends on a /64 boundary because it derives the lower 64 bits from the interface identifier; smaller subnets break SLAAC and you usually do not want to.
Common IPv6 prefix sizes:
/64— single subnet, the default for any LAN./56— small site allocation, gives the customer 256 subnets. Many residential ISPs hand out a/56per customer./48— site allocation per RIPE policy and similar guidance, gives 65,536 subnets./32— typical ISP allocation from an RIR. Gives the ISP 65,536/48s to hand out to customers./12,/16,/20— RIR-level chunks, allocated to regional registries by IANA.
Documentation prefix: 2001:db8::/32 is the IPv6 equivalent of the IPv4 TEST-NET ranges. Anything inside it should never appear in real traffic.
VLSM: mixing prefix sizes inside one allocation
Variable Length Subnet Masking is the practice of carving one allocation into sub-blocks of different sizes. Pre-CIDR classful addressing required every subnet inside a Class B to be the same size, which wasted addresses on segments that needed only a few endpoints. VLSM lets you hand out exactly what each segment requires.
Worked example. You receive 203.0.113.0/24 and need: a /26 for the main office (62 usable hosts), two /27s for branch offices (30 usable each), and a /30 for a router-to-router link (2 usable). A clean layout:
203.0.113.0/26— main office, hosts .1 through .62.203.0.113.64/27— branch one, hosts .65 through .94.203.0.113.96/27— branch two, hosts .97 through .126.203.0.113.128/30— router link, hosts .129 and .130.203.0.113.132through203.0.113.255— free space for future growth.
Allocate the largest subnet first and work down. Aligning each block on its natural boundary keeps the address plan readable and leaves the biggest contiguous free chunk for whatever comes next.
Supernetting: aggregating many small routes into one
Aggregation is the opposite direction. An ISP that owns four contiguous /24s aligned on a /22 boundary can announce them as a single /22, replacing four BGP routes with one. Multiplied across the global table, this practice is the only reason the IPv4 BGP table — currently around one million routes — still fits in commodity router memory at all.
The aggregation rule: the constituent blocks must be contiguous and aligned on the parent boundary. 198.51.100.0/24 and 198.51.101.0/24 combine cleanly into 198.51.100.0/23. Four consecutive /24s starting at a /22 boundary aggregate into /22, and so on. Mixing non-contiguous or misaligned blocks breaks aggregation and forces multiple announcements. ISPs sometimes intentionally announce the aggregate plus the more-specific routes, the latter for traffic engineering, but that is a deliberate choice.
Why BGP filters anything more specific than /24
Tier-1 networks enforce minimum prefix-length filters to keep the global routing table within survivable bounds. The de facto floors are /24 for IPv4 and /48 for IPv6. Announcing anything more specific than that — say, a /27 — works on your own network and between friendly peers but gets silently dropped at the major transit boundaries. The traffic does not stop flowing; it just falls back to whatever less-specific route the upstream has, which may not be yours.
Prefix length also affects path selection. Routers prefer the longest matching prefix when choosing where to send a packet. If two networks announce overlapping space — one ISP advertising a /22 and another announcing a more specific /24 carved from inside it — traffic for any address inside the /24 follows the more specific path. Multihomed networks use this for traffic engineering: announce the aggregate to both upstreams, then announce a /24 with prepends or selective community values to steer traffic on a per-block basis.
Two related real-world concerns. Route hijacking exploits this same longest-match behavior — a malicious or misconfigured ASN announces a more-specific route inside someone else's space and steals traffic. RPKI (Resource Public Key Infrastructure) with Route Origin Authorizations cryptographically asserts which ASN is allowed to announce which CIDR block, and route-origin validation lets routers drop announcements that do not match. RPKI deployment crossed roughly 50 percent of IPv4 prefixes in the early 2020s and continues climbing; networks that have not published ROAs for their space remain hijackable.
How cloud providers slice CIDR blocks
Every major cloud platform asks for a CIDR block at VPC creation time, and every one has its own idiosyncrasies.
- AWS VPCs. Accept
/16through/28. The primary CIDR is locked for the VPC's lifetime; you can add secondary CIDR ranges later. AWS also reserves five addresses in every subnet (network, broadcast, plus three for AWS internal use), so a/28subnet with 16 total addresses gives you 11 usable. That last detail catches everyone the first time. - Google Cloud. Custom-mode VPCs let you pick a CIDR block per region and per subnet. Auto-mode picks defaults across all regions automatically, which is fine for a sandbox and a footgun in any environment that needs to peer with on-premise networks.
- Azure virtual networks. Support multiple CIDR ranges per virtual network and per subnet. IPv6 is configured as dual-stack on a single subnet rather than as a separate network.
- Kubernetes. Cluster networking consumes a large pod CIDR (often
/16or bigger) plus a separate service CIDR. Both must not overlap with the VPC, with on-premise ranges you peer to, or with other clusters that might one day need to interconnect. Picking10.0.0.0/16for the pod network when half the internet uses the same range is the most common and most painful mistake.100.64.0.0/10(CGNAT space) is deliberately allocated for cases like this and is a much safer choice.
The cross-cutting rule: pick ranges that do not collide with anything you own now or might own later. RFC 1918 space is finite in practice because everyone uses the same handful of defaults. Picking a less-obvious slice of 10.0.0.0/8 — say 10.176.0.0/16 rather than 10.0.0.0/16 — costs nothing and prevents an entire class of future merger-and-acquisition pain.
The default route, the /0 special case
0.0.0.0/0 is the default route — a CIDR block that matches every possible IPv4 address. The IPv6 equivalent is ::/0. Routing tables list the default route last because it is the catch-all: if no more specific prefix matched the packet's destination, the default route handles it. Most consumer networks have exactly one default route, pointing at the ISP's upstream gateway. Enterprise networks and BGP routers may have multiple, with priority decided by metrics, AS path length, or local preference.
Two practical implications. First, in firewall rules, 0.0.0.0/0means "any IPv4 address," which is sometimes what you want and frequently a sign that the rule is broader than the author realized. Cloud security groups that allow inbound from 0.0.0.0/0 on management ports like SSH (22) or RDP (3389) are the single most common cloud configuration mistake; they are why the bulk of internet-wide scanning continues to find easy targets. Second, in BGP, announcing 0.0.0.0/0upstream is how stub networks request a default route from a transit provider. The BGP-side details get covered in vendor documentation, but recognize the notation when you see it: it is not a typo, it is the special-case way of describing "everywhere."
Anycast and one CIDR announced from many places
Anycast is the routing technique where the same CIDR block is announced from multiple locations and the network routes each request to whichever is topologically closest. CDN edges, recursive DNS resolvers, and DDoS-mitigation networks all use anycast heavily. 1.1.1.1 is announced from hundreds of Cloudflare data centers globally; 8.8.8.8from Google's; the root DNS servers from dozens of operators. From the perspective of a CIDR record there is one prefix; from the perspective of the global routing table there are many equivalent paths to it.
The CIDR block size matters here too. Anycast works at the prefix level, so the announcement must be at least /24 to propagate globally. Smaller blocks announced from one location cannot effectively be made anycast on the open internet because the more-specific announcement does not propagate. This is one of the more practical reasons large operators hold many full /24s rather than consolidating into one big block — operational flexibility for per-region announcements.
Bogons: CIDR ranges that should never appear
A bogon is a CIDR block that has no business being seen on the public internet. Three categories overlap: reserved blocks (RFC 1918, loopback, link-local, TEST-NET, multicast, etc.), unallocated blocks not yet handed out by IANA or any RIR, and blocks that have been allocated but are not currently routed. Traffic claiming to come from a bogon is either spoofed or comes from a misconfigured network and should be dropped at the edge.
Team Cymru maintains the canonical bogon list. Spamhaus publishes a similar feed. Both are designed for ingestion into BGP-aware routers via a feed protocol, so the filter updates automatically as IANA allocates new ranges. For static rule sets in firewalls or cloud security groups, the reserved-blocks portion is stable and worth dropping: anything claiming to originate from RFC 1918 space, link-local, or TEST-NET should never reach a public-facing interface.
The IPv4 secondary market, where CIDR blocks are now real estate
Since regional registries ran out of free IPv4 space, the secondary market has filled the gap. Brokers like IPv4.Global, Hilco Streambank, Avenue4, and several smaller firms run marketplaces where existing IPv4 holders sell their unused blocks to networks that need addresses. ARIN, RIPE, and the other RIRs validate the transfers and update the WHOIS records; the brokers handle the contract, escrow, and price discovery.
Prices have moved over the past decade. Early 2014 transfers traded around six to seven dollars per address. By 2020 the average was around twenty-five dollars. Through 2022 the market peaked above fifty dollars per address. The current 2025 range is roughly thirty to forty-five dollars per address depending on block size and reputation, with cleaner blocks (no historical spam listings, no abuse complaints) commanding the top of the range. A standalone /24 trades for ten to fifteen thousand dollars; a /22 for fifty to seventy thousand.
The market exists because IPv6 transition is incomplete. Every cloud provider still bills for IPv4 addresses (AWS started charging for them per-hour in 2024), and every consumer ISP must hand each subscriber a working IPv4 address. The arithmetic of buying versus waiting for IPv6 maturity has kept IPv4 prices high enough that selling unused legacy blocks has funded entire small operations. Apple, Hewlett-Packard, the US Department of Defense, and several universities have been the most visible sellers; cloud providers and growing ISPs have been the buyers. CIDR blocks moved from being allocations on a registry to being assets on a balance sheet.
Real BGP incidents that came down to CIDR mistakes
A short history of cases where misconfigured CIDR announcements broke things at internet scale.
- February 2008, Pakistan vs YouTube. Pakistan Telecom announced a
/24covering YouTube's IP space to its domestic transit provider, intending to black-hole YouTube within Pakistan. The provider leaked the announcement upstream, and within minutes the more-specific/24drew global YouTube traffic into Pakistan. YouTube was effectively offline for two hours until both networks corrected the routes. - June 2019, Verizon and Cloudflare. A small Pennsylvania ISP, DQE Communications, leaked thousands of BGP routes to its upstream Verizon. The leaked routes included specific announcements that won path selection over legitimate Cloudflare and Amazon prefixes. Verizon accepted and propagated the routes, redirecting traffic for roughly two hours. The fix was process, not technology; Verizon did not have RPKI validation enabled at the time.
- October 2021, Facebook DNS withdrawal.Not a hijack but a self-inflicted CIDR error. Facebook's internal automation withdrew the BGP announcements for the prefixes carrying its DNS authoritative servers. The result was that Facebook, Instagram, and WhatsApp became unresolvable globally for six hours, including for Facebook's own engineers trying to reach the data centers to fix the problem.
- February 2022, KlaySwap.Attackers gained access to a small Korean ISP's BGP infrastructure and announced specific routes for the IP carrying KlaySwap's JavaScript SDK. They served a malicious version of the script for two hours, draining roughly two million dollars in cryptocurrency from users who happened to load the SDK during the window.
The pattern across all four: a more-specific CIDR announcement wins routing, and the global table accepts the announcement because no validation prevented it. RPKI deployment would have stopped or limited each of them. The lesson, twenty years on, is that CIDR is not just notation; it is the unit of trust on which the entire BGP-routed internet runs, and securing it cryptographically with ROAs is the difference between an accident causing two hours of outage and an accident being caught at the first hop.
Common mistakes
- Forgetting reserved addresses. A
/30has 4 total addresses and only 2 usable. A /29 has 8 and 6 usable. Always quote usable counts unless you have a specific reason to talk about totals. - Writing CIDR with a non-aligned address.
10.1.2.5/24is technically meaningful (it identifies an IP and the prefix) but ambiguous when used as a range — the canonical form is10.1.2.0/24. Some tools auto-correct, others reject; pick the canonical form and avoid the question. - Announcing too-specific routes in BGP. Most peers drop anything longer than
/24or/48. Announcements for traffic engineering need to stay above those floors or get arranged through community-tag propagation rather than raw advertisement. - Trusting CIDR for precise geolocation. Geolocation databases label entire blocks under one city even when parts of the range serve completely different regions. Treat block-level location as a routing hint, not a precise fact.
- Picking 10.0.0.0/16 for everything. Half the AWS, GCP, and on-premise networks in the world have already claimed it. Future merger or peering work will be painful. Use a less-obvious range from the start.
- Ignoring the IPv6 plan. IPv4-only thinking carries real cost as carriers and cloud providers move IPv6-first. Every CIDR allocation in 2026 should have a parallel IPv6 plan even if deployment lags.
Tools you can actually use
- ipcalc on Linux gives a full breakdown of any CIDR block in one command:
ipcalc 198.51.100.0/22. - sipcalc is the more flexible alternative, handles IPv6 cleanly.
- Python's ipaddress module is the right tool for scripted analysis.
list(ipaddress.ip_network("198.51.96.0/22").subnets(new_prefix=24))returns every/24inside the parent in one line. - Our ASN Lookup shows the prefixes a given ASN announces in CIDR form, useful when checking what an ISP actually controls.
- Our WHOIS / RDAP Lookup returns the CIDR block an IP belongs to plus the registered owner and abuse contact.
- Our Reverse DNS Lookup reveals hostname patterns inside a CIDR block, useful for classifying residential vs business vs hosting ranges.
- Our IP Address Lookup pairs each result with its surrounding CIDR block so you can see the context at a glance.
- bgp.tools and bgp.he.net for live BGP state, route history, and prefix announcements globally.
A real-world subnet planning walkthrough
Suppose you are building a small office network from a single /23 allocation (10.50.0.0/23) and the requirements are: 200 host capacity in the main user VLAN, 60 hosts in a guest VLAN, 30 hosts in a printer/IoT VLAN, two point-to-point router uplinks, and headroom for at least one more 30-host VLAN later. Total of 512 addresses, requirements adding up to roughly 320 endpoints plus growth.
A clean allocation:
10.50.0.0/24— main user VLAN, 254 usable addresses, plenty of room for the 200-host requirement plus growth.10.50.1.0/26— guest VLAN, 62 usable for the 60-host requirement.10.50.1.64/27— printer/IoT VLAN, 30 usable.10.50.1.96/27— reserved for the future 30-host VLAN.10.50.1.128/30— primary router uplink.10.50.1.132/30— secondary router uplink (or/31if both ends support RFC 3021).10.50.1.136through10.50.1.255— 120 addresses of free space for whatever comes next.
Notice the discipline: largest segment first, each following segment aligned on its natural boundary, free space kept as one contiguous block at the end. That last detail matters because the moment you need to grow a segment by combining it with adjacent space, alignment is what makes the merge possible.
CIDR in scripts and automation
Almost any CIDR question becomes a one-liner with the right tool. A few patterns worth remembering:
# List every /24 inside a parent block
python3 -c "import ipaddress; \
print('\n'.join(str(s) for s in \
ipaddress.ip_network('198.51.96.0/22').subnets(new_prefix=24)))"
# Check whether an IP belongs to a CIDR block
python3 -c "from ipaddress import ip_address, ip_network; \
print(ip_address('198.51.97.42') in ip_network('198.51.96.0/22'))"
# Aggregate a list of small blocks into the minimum set of supernets
python3 -c "from ipaddress import collapse_addresses, ip_network; \
blocks = [ip_network(b) for b in \
['198.51.100.0/25','198.51.100.128/25']]; \
print(list(collapse_addresses(blocks)))"
# AWS CLI: list all VPCs and their CIDRs
aws ec2 describe-vpcs \
--query "Vpcs[*].[VpcId,CidrBlock]" \
--output table
# Match every CIDR in a config file
grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/[0-9]+' config.yaml | sort -uFor routine work, scripting beats memorizing. The Python ipaddress module in particular handles every edge case (alignment, IPv6, mixed lists) and ships with the standard library, so it is one import away on any modern system.
Frequently asked questions
Does a bigger slash number mean a bigger network? No, the opposite. A larger prefix length means more bits are fixed as network, so fewer remain for hosts. /16 is sixteen million times the size of /40. The slash counts the locked bits, not the free ones.
Why is /31 allowed on point-to-point links? RFC 3021 lets routers treat a /31 as two usable addresses on a strictly point-to-point link, removing the need for network and broadcast addresses where there are only ever two endpoints. It saves substantial address space on networks with many interlinks.
Can a domain belong to a specific CIDR block? Not directly. Domains resolve to IPs, and those IPs belong to CIDR blocks. A single domain can resolve to many IPs across different blocks if it is hosted on a CDN or load-balanced across providers — Google.com, for example, resolves differently from different parts of the world depending on Anycast routing.
How do I know if two IPs are in the same CIDR block? Apply the prefix length as a mask to both addresses and compare. Or, mentally, check whether the bits up to the prefix length match. 10.1.2.5 and 10.1.2.200 share /24 (first three octets identical) but not /25 (the fourth-octet bit at position 7 differs).
Why does my AWS subnet have fewer usable IPs than I expected? AWS reserves five addresses per subnet, not the usual two. The first (network), the last (broadcast), plus the second, third, and fourth for AWS-internal services. A /28 subnet has 16 total addresses but only 11 usable on AWS.
What is the smallest CIDR block I should announce in BGP? /24 for IPv4 and /48 for IPv6 if you want the announcement to propagate to the whole internet. Anything more specific gets dropped at most major transit boundaries.
Can I get my own CIDR block? Through the regional internet registries, yes, but the IPv4 free pool is gone and the secondary market is the practical route for new IPv4 allocations. Expect to pay roughly fifty to sixty dollars per address as of 2025. IPv6 allocations are still freely available from RIPE, ARIN, and the others — the application is a few hundred dollars in setup fees and an annual maintenance fee.
How does CGNAT space (100.64.0.0/10) affect what I see in IP lookups?If you are on a CGNAT carrier, the public IP your phone or modem reports may fall inside this range, but the address you appear from to the open internet is a different, shared public IP belonging to the carrier's gateway. Mobile networks and budget cable ISPs use this widely.
What is RPKI and why should I care?Resource Public Key Infrastructure is the cryptographic system that binds CIDR blocks to specific ASNs. Networks publish ROAs (Route Origin Authorizations) that say "this CIDR is allowed to be announced from this ASN." Routers performing route-origin validation drop announcements that do not match. If your organization owns IP space, publishing ROAs is the modern anti-hijacking baseline.
Related glossary terms: CIDR, ASN, and NAT. To see the network details for a public IP, use the IP Address Lookup. Related reading: What Is ASN?, What Is WHOIS?, CGNAT IP Address Range, and Reserved IP Address Blocks.
