Why is /24 the smallest announceable range? Your options if you own a /25

The wall teams most often hit when planning to announce their own IP range over BGP is not a technical one but a policy one: if your range is smaller than a /24 it is effectively invisible on the global internet. Routing works, your neighbour accepts the announcement, everything looks right from your side — and most of the traffic never reaches you.

This article covers why the limit exists and what options remain if you hold a /25 or something smaller.

Terminology first: a "longer prefix" means a smaller range

Half the confusion comes from the wording. As the prefix length grows, the range shrinks:

Why the usable column is always three short is a separate matter: in every routed block the network address, the broadcast address and the gateway go straight away. "I have a /25" means you have 128 addresses, and "a prefix longer than /24" describes exactly that size and everything below it.

Why the limit exists

The global routing table is a shared resource. Every transit router on the internet carries the list of all announcements in the world, and each additional prefix entering that table consumes memory and processing on everyone's hardware, not just yours.

Now picture it: if every holder of a /24 split it in two and announced two /25s, that portion of the table would double overnight. Split it four ways and it quadruples. That is why operators put a limit on the prefix length they accept, and on the IPv4 side the common limit is /24. It is not a decision handed down from one place but a filtering policy applied separately by independent operators — though the effect is as absolute as a central decision would be.

On the IPv6 side the same logic puts the commonly accepted limit at /48.

The practical result: not partial, but nothing

What matters here is that the outcome is not "less traffic" but "no traffic from those networks". Customers of an operator that applies the filter never learn about your /25; the traffic goes to a wider announcement covering the range if one exists, and nowhere if one does not.

Tested from your own network and a couple of neighbouring ones, everything can look fine. That is why the failure of a /25 announcement is usually noticed only after the cutover, once real user traffic has gone missing.

The pull of a more specific announcement — the real reason for the limit

The rule in routing is clear: traffic to an address follows the path indicated by the longest prefix covering it. While a /24 is announced, if someone announces a /25 out of the same space, the traffic falling in that /25 shifts to the new path.

That rule explains two things at once. First, why announcing a /25 looks appealing: a more specific announcement pulls traffic to itself. Second, why the filters are so widespread: the same mechanism is how prefix hijacks work. A long-prefix filter protects table size and narrows that attack surface at the same time.

For the same reason it matters that the maxLength on your ROA matches the length you actually announce; the detail is in what RPKI and ROA are.

If you hold a /25 or smaller

There are four options, and which one fits depends on how the range is divided.

1. If the whole covering /24 is yours, announce that. How you subdivide it internally is your network's business; announcing a single /24 to the outside is enough. This is the cleanest answer, and in most cases the issue is simply that nobody noticed it was available.
2. Let the holder of the /24 announce it and have the traffic tunnelled to you. If the range is shared with another organisation, the holder of the covering block makes the announcement and your part is delivered over a tunnel. This is the same build as BGP protection; the only difference is who originates the announcement.
3. Rent the addresses. You do not have to announce a range of your own. Under IP rental the addresses are announced through the Datafex network, so announceability and the records stay our responsibility; rDNS and routing you configure yourself from the panel.
4. Lean on IPv6. There is no address scarcity on the IPv6 side, and a dual-stack setup markedly reduces how much IPv4 you need. It does not solve IPv4 on its own — clients that need IPv4 exist — but it shrinks how many addresses you have to find.

Why "then I will just get a bigger range" is not easy

The IPv4 address space is capped at 4.3 billion addresses and that pool is gone. RIPE NCC, which serves the European region, announced on 25 November 2019 that its free IPv4 pool had run out. Since then allocations come only from returned addresses and a waiting list, at a maximum size of /24.

Those two limits combine into an interesting result: the largest range you can be newly allocated today and the smallest range you can announce in the global table are the same size — a /24. In practice it is both the ceiling and the floor.

The same scarcity explains why requests for extra IPs are assessed against a justification: an address is an allocation decision, not a stock item. And when you work out how many you really need, avoid the common misconception that every domain needs its own IP — thanks to SNI, hundreds of domains and certificates run fine on a single address.

If you have an ASN but a small range

The BGP protection model rests on two prerequisites at once: your own ASN and a range of at least /24. Having the ASN alone is not enough; you need something to announce.

If that is your situation, the fastest route is an inventory: the prefixes you hold, who holds the covering blocks, and which service genuinely needs an address of its own. Share those three when you write to us and which option is workable usually separates out on first reading. All of the data centre services and which scenario each one fits are on the data centre page.