Choosing between a /24, /23 and /22: sizing your first own block
The size of your first own IPv4 block is a planning decision that is hard to undo. Choose too small and you’ll soon be adding scattered blocks that don’t fit together; choose too large and you pay for addresses that sit idle. This guide compares the /24, /23 and /22 on routability, growth, aggregation and subnet planning, so you can size the block around how you will actually use it.
The basics: what each size gives you
| Prefix | Addresses | Equivalent to | Can be announced as |
|---|---|---|---|
| /24 | 256 | One /24 | One /24 |
| /23 | 512 | Two /24s | One /23 or two /24s |
| /22 | 1,024 | Four /24s | One /22, two /23s, four /24s, or a mix |
The number of addresses you can give to hosts is always lower than the total. Every subnet you create uses a network and a broadcast address, and you’ll need addresses for gateways, routers and management. Plan with usable addresses, not the raw count.
Routability: why the /24 is the floor
A /24 is the smallest IPv4 prefix widely accepted in the global routing table. Many networks filter out announcements longer than /24, so a /25 announced on its own is unlikely to be reachable from much of the internet.
This has two consequences for sizing:
- Any block you plan to announce yourself should be at least a /24. Smaller pieces only work inside a provider’s network that announces the covering prefix.
- Every /24 inside a larger block can be routed independently. A /22 gives you four units you can announce separately, for example from different sites or through different upstreams.
Cloud BYOIP programmes follow similar logic. AWS requires a /24 minimum, Azure custom IP prefixes accept /21 to /24, Google Cloud advertised prefixes range from /16 to /24, and OVHcloud accepts /24 to /19. A /24 fits within every one of these ranges, and a larger block lets you place separate /24s with different providers.
Aggregation: one announcement or several?
A /23 or /22 can be announced as a single aggregate instead of several separate /24s. That means fewer route objects, fewer ROAs and a smaller footprint in the global table. It also gives you a choice: announce the aggregate everywhere, or add more-specific /24s to steer traffic, such as sending one /24 through a particular upstream.
Two technical points to watch:
- Alignment. A /23 must start on an even third octet – x.y.10.0/23 covers x.y.10.0 to x.y.11.255 – and a /22 must start on a multiple of four. Two adjacent /24s that don’t line up this way can’t be combined into one /23.
- ROA scope. If you announce more-specifics, your ROAs must cover each prefix you originate. Creating ROAs only for the prefixes you actually announce, rather than setting a loose maximum length, makes certain hijacks harder.
Acquiring two unrelated /24s later is not the same as starting with a /23. They need separate registry objects, may carry different reputation histories, and will never aggregate.
Growth: size for the next stage, not forever
Start from a realistic count of what you need now, then add growth:
- List current needs: customer services, infrastructure (gateways, loopbacks, management, monitoring), mail, and anything reserved for planned products.
- Estimate growth over the period you can plan for with reasonable confidence.
- Add headroom for subnetting overhead and future restructuring.
As a rough guide, a /24 suits a single site, a smaller operator, or a block used mainly for infrastructure and a limited number of customers. A /23 suits operators who expect to outgrow a /24, or who want two routable units for two sites or upstreams. A /22 suits operators who need four routable units: several locations, a firm split between infrastructure and customer space, or growth that is already visible.
If you’re torn between two sizes, compare the cost of being wrong in each direction. Too small means acquiring more space later, probably not contiguous with what you have. Too large means paying for idle addresses, although unused /24s in an owned block can be leased out.
Plan your subnets before you announce anything
Write a subnet plan on day one, even for a single /24:
- Separate infrastructure from customer space, and keep management networks apart from both.
- Allocate on aligned boundaries (/25, /26, /27 and so on) so ranges can be merged or split cleanly later.
- Use /31s for point-to-point links and /32s for loopbacks to avoid wasting addresses.
- Keep unallocated space in one contiguous range at the end of the block rather than in scattered gaps.
- Record every assignment and its reverse DNS in an IPAM tool, or at minimum a shared spreadsheet.
Our subnet calculator is useful here for checking boundaries and usable host counts before you commit to a layout. Try your plan against each candidate size: if a /24 leaves no room for the next product or site, that tells you more than any rule of thumb.
How TACS can help
Once you’ve settled on a size, we can supply aligned space that leaves room to grow, whether you buy IPv4 or lease IPv4. We can also set up the route objects, ROAs and reverse DNS so the block is ready to announce from the start.