Block the address, the /24, or the whole ASN? Sizing a block to the evidence you have
One address keeps coming back, so somebody widens the rule to its /24, and when that does not settle it, to the AS number. Each step feels like the same decision at a bigger size. It is not: each step changes who else is inside the rule. The evidence about the offender tells you how narrow you can afford to be; what the range contains tells you what a wider rule would cost. You need both. Here is how to read that before you widen, and what the registry can and cannot tell you. How long a block should last is the other half of the same question.
Three different objects
A lookup can answer three questions about a range and they routinely give different answers: who the registry says holds the block, which AS announces it today, and whether a ROA authorises that AS to do so. Keep them apart, because widening a rule silently switches between them. The registry vocabulary alone has several layers: ARIN's manual distinguishes an allocation issued directly from the registry, a reallocation sub-delegated to an organisation for onward distribution, and a reassignment sub-delegated for the exclusive use of the recipient, while the RIPE region treats sub-allocations to downstream operators as part of an LIR's aggregatable space. The announced prefix is a fourth thing entirely and belongs to BGP rather than to any registry. So when you widen from an address to "its range", the first question is which range you mean, and if the range you mean is the announced prefix, or the /24 you reached for by habit, that boundary was drawn for routing convenience rather than to enclose one actor.
What a /24 actually contains
The /24 feels like a natural unit because it is the practical floor of the global routing table, but that convention is about propagation, not about tenancy. RFC 7454 (BCP 194, February 2015) records the position rather than setting it: it says acceptable specificity is decided for each peering between the two peers, and cites the RIPE community as having documented that, at the time that RFC was written, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 were generally neither announced nor accepted, adding that these values may change in the future. Large networks publish the same floor, on pages that carry no version or date and which we read on 23 August 2026: Hurricane Electric's published filtering algorithm rejects IPv4 prefix lengths outside 8 to 24, and NTT's routing policy says it will accept any properly registered prefix from customers but will announce only /24 and shorter prefixes to its peers, which are two different statements worth separating. Operator community guides, also undated and read the same day, agree and name the exceptions: the NLNOG BGP filter guide recommends filtering IPv4 routes longer than /24 and IPv6 routes longer than /48, and the DENOG routing guide gives /24 as the IPv4 minimum with blackholing or an announcement carrying a no-export community as possible exceptions. A RIPE Labs measurement from October 2014 put numbers on it, finding a /24 visible to about 92 percent of the full-feed collector peers it measured while longer prefixes reached 10 to 20 percent; a RIPE Labs re-measurement published in April 2019 reported the picture effectively unchanged since 2014; both are sampled sets of collector peers, so treat the exact figures as illustration. The consequence for a rule is the important part: registries set their general minimum at that floor, with narrow exceptions such as APNIC's smaller default delegation to a new internet exchange point, and providers subdivide below it, so a /24 can be one customer or hundreds of them, and on shared hosting a single address inside it can front many unrelated sites, and the routing table cannot tell you which. ARIN says as much in its own policy: section 4.2.1.5 of the manual as served on 23 August 2026 reads that if allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.
What an AS number is not
An AS number identifies a routing policy, not a company, and RFC 1930 warned against the confusion thirty years ago, observing that the term is often misused as a convenient way of grouping prefixes under one administrative umbrella. Three practical consequences. First, a rule written against an AS number matches whatever the address's origin AS is, and a transit provider commonly originates space on behalf of single-homed customers, which is exactly what RFC 1930 recommends: a separate AS is not needed and the prefix should be placed in an AS of the provider. So the rule catches those customers alongside the operator you meant, while a multihomed customer announcing under its own AS number is not caught at all. Second, the announcing AS need not be the holder, and that is normal rather than suspicious: a live and checkable example is 1.1.1.0/24, which the APNIC database records as APNIC Research and Development with country AU while AS13335 announced it when we checked on 23 August 2026, an arrangement the APNIC record documents in its own remarks as routed globally by that AS, with a matching valid ROA. The registry says who holds, BGP says who announces, and a ROA, as defined in RFC 9582 of May 2024, says which AS the holder authorised: three questions, three sources, and here all three agree. They do not always, and a disagreement changes who you are looking at rather than settling anything. An announcement the holder never authorised makes the origin AS the party in question, and a rule written against the holder's other space would land on somebody with no part in it. Stale and missing ROAs are ordinary too, so treat a mismatch as a reason to look further and not as a verdict either way. Third, an operator can hold more than one AS number, so an ASN rule is both too wide and too narrow at once. Sibling and customer-cone datasets exist, notably CAIDA's, but they are inferred from observed BGP paths and registry dumps, and CAIDA itself notes that real AS relationships are more complex than the model allows. Treat that data as a lead rather than a roster.
When one address is many people
Carrier NAT is the best documented case, not the only one. Corporate and campus egress, mobile gateways, and consumer privacy relay or VPN services also put many unrelated people behind a single address, and those addresses commonly read as hosting rather than residential space, so the fact that a range does not look like an eyeball ISP is not evidence that nobody real is behind it. Underneath all of this sits the case where even the single address is too wide. RFC 6269, an Informational document from June 2011, states that where one public IPv4 address is shared between several subscribers the address no longer uniquely identifies a subscriber, and its section 13.3 gives the concrete case: blocklisting the address of a spammer behind a carrier NAT leaves every other subscriber sharing that address with their ability to source SMTP packets restricted to some extent. That is the RFC's scope and the RFC's qualifier, and both are worth keeping; the general point about uninvolved subscribers is ours rather than the RFC's. It gives no ratio and neither should you. One correction worth carrying, because blogs get it backwards: carrier NAT space itself, 100.64.0.0/10, is shared address space reserved by RFC 6598 (BCP 153, April 2012), which requires that packets with those source or destination addresses must not be forwarded across service provider boundaries, so what reaches your service is ordinary public space that looks like a single host and is not one. Two published measurements are worth citing rather than reproducing: Cloudflare wrote in December 2022 that on a network like its own a single address represents thousands of servers, and cited a review finding that of roughly 6.5 million resources blocked in one national scheme as of June 2017, about 97 percent were blocked collaterally; a RIPE Labs analysis published in September 2025 measured thousands of fully blocked domains in another national scheme and attributed most of the damage to address-level blocking. Those are their measurements of their own vantage points, not ours. Neither measures widening from an address to a prefix to an AS number; both measure the cost of the narrowest rule in common use, which is already an address, and both find it lands mostly on people nobody meant to reach.
Choosing a width you can defend
As of 23 August 2026, across the RFC series, the ARIN, RIPE NCC and APNIC policy manuals and the operator filter guides cited here, we found no published document that sets a numeric threshold for when to widen from an address to a prefix or to an AS number. That is an absence in what we checked rather than proof that nothing exists, so if you are handed a number, ask what it rests on. What the record does offer is a direction and a discipline. The IAB's RFC 7754 observes that blocking is generally viewed as less objectionable when it is highly granular and does not cause collateral damage to unrelated services, and RFC 6471 advises list operators that listings should be considered temporary and should expire unless the reasons still exist. Translated into a rule review: pick the narrowest width the evidence supports, write down what you would need to see to widen it, and give wider rules shorter review intervals than narrow ones. And widening is not the only move available: when a narrow rule keeps being evaded, a different control at the same width, a rate limit, a challenge, or requiring an account, usually costs bystanders less than a wider block. Before widening, start with your own logs, because they are the only part of the case that is yours. How much of the range have you actually seen? One address seen once is evidence about one address; the same behaviour arriving from address after address inside the same boundary is the evidence that the boundary is too narrow. Then read the range rather than the incident. Is the whole range announced as one prefix, or carved into smaller announcements by several different networks? Does the space read as an eyeball ISP full of ordinary subscribers, or as hosting? And if it is hosting, is it one tenant or a provider selling to many unrelated customers, which is the more common case? Is the prefix you are about to block the one that is announced, or a larger aggregate carrying unrelated customers? For the registry side, a query against the specific sub-block is what answers who holds it, and absence of detail is not evidence of a single tenant: a downstream record can be missing because the block sits below a registration threshold, because the region allows aggregated registration, because the upstream marked it non-public, or because the delegation itself happened only days ago and, in the ARIN region, policy allows seven calendar days for it to become visible. Country-level rules deserve the most scepticism of all. The country code in the registries' published statistics is defined only as the code of the organisation the allocation or assignment was made to, with the registries adding that it is not intended as an authoritative statement of where a resource is in use, and RIPE says of the country attribute in its own database that it has never been specified what that country represents.
Before you widen a rule, look the address up on the front page and read what is around it: the registered block that contains it and its holder, the enclosing blocks above it, which network announces it and which prefix it actually announces, the RPKI state, and whether the report reads the space as carved into smaller announcements by several networks rather than announced as one. Where a tag has been applied, on the block or on the announcing network, it will tell you whether the space reads as eyeball ISP, hosting or proxy space. No tag is not a finding of innocence, and a proxy or hosting tag is not a finding of guilt: relay services and corporate egress put ordinary users behind exactly that kind of address. That is the difference between blocking one tenant and blocking a building. The same read run with the risk pointing the other way, for a range a ticket asks you to trust, is in vetting an allowlist request.