Asked to allowlist an IP range: whether the requester holds it, who else is inside it and the width you can defend

What the ticket claims, and why an allow rule inverts the risk

A ticket that asks for a range to be trusted is making three claims at once, and it can prove none of them by itself. That the requester holds or controls the range: the ticket says so, and a ticket is not a registry. That nobody else is inside it: a /24 has room for a great many people, and when one address is many people already sets out how one address can front a workforce or a subscriber pool, and what a /24 actually contains adds the hosting box full of tenants. That it will stay that way: address space is reassigned, re-announced and re-sold, and the rule you write today has no way of noticing. The reading for a block rule already exists on this site, and choosing a width you can defend records that, as of 23 August 2026, across the documents it cites, we found no published document that sets a numeric threshold for widening a rule. The search for an allow side counterpart came back the same way on 14 September 2026: none of the RFCs cited on this site, the ARIN Number Resource Policy Manual (version 2025.1, dated 3 March 2026) or the APNIC policy document publishes a width or a lifetime for an access control allow rule. 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 published documents offer instead is direction, and the direction is inverted: the deny side risks catching a bystander, the allow side risks admitting a stranger.

The published basis is short and worth reading in its own terms. RFC 6269, an Informational document from June 2011, says that where one public IPv4 address is shared the address no longer uniquely identifies a subscriber, and draws the consequence for the rule in your hand: simple address based identification used to populate access control lists will fail when an address no longer identifies a subscriber, and adding port numbers to those lists may be possible at the cost of extra complexity and may need static port assignment. RFC 7754, an IAB document from March 2016, names the model you are being asked to run: a whitelist model, block by default, which it says captive portals, walled gardens and security sandboxes usually require because the scope of allowed communication is narrow, and it carries the counterweight in the same document: whitelists carry similar risks to blacklists, approved sites can turn bad, and blocking all traffic for an address can impact unrelated occupants of the same address. NIST SP 800-41 Revision 1, from September 2009 and listed as Final on the NIST site on 14 September 2026 with no withdrawal notice, is the deny by default reference, and it says two things that matter here: rulesets should be as specific as possible about the traffic they control, and deciding which addresses should be blocked is often one of the most time consuming and error prone parts of an IP policy because the address associated with an undesired entity often changes over time, a sentence written about a deny rule whose reason applies unchanged to an allow rule. It gives no prefix width for an allow rule and no interval for a review; it says rules should be reviewed periodically, which why there is no number reads as a cadence rather than a duration, and that, wherever practical, each rule should carry a comment so that others can tell why it was made.

Map the three claims to three reads on one report. The holder is the Registration panel. Who else is inside is the Routing panel, the address sampling panel and the tags. Whether it will stay that way is the origin history and the Time machine. And say in the same breath what the report cannot do: it cannot see the ticket, the account or the device, it cannot verify the requester, and nothing it prints is a statement about who is using an address today. A review that works and triaging the signal each give the allow direction one clause and move on; this post is that clause, opened out.

Who the registry says holds it: the Registration panel

Look the range up as the ticket wrote it. The Registration panel sits near the foot of the report, and its heading is the first tell: when the registry holds a single registered block that is not the block you typed, the heading reads Registration: followed by that block as a link, so a /24 in a ticket that resolves to a /22 or a /19 is a slice of somebody's larger assignment, and the requester's name may appear nowhere on the page. Under the heading the rows are the ones the registry supplies, with empty rows dropped rather than printed: RIR, Registered blocks when the record covers several, Range and Addresses where they add to the block, Net name, Organisation, Handle where it adds to the name, Type, Status when it adds something to Type, Country, Registered, Last changed, Allocated and the Abuse contact as published, with a Remarks block where the registry published any. Beneath them sit two collapsed tables: Registry contacts, with Role, Name, Organisation and Email from the registry's entities, and Enclosing blocks, with Block, Name, Type and Country for each larger block above this one, which the docs call parent blocks. The finding Part of something bigger, in the findings under the overview, names the enclosing block, its size and the registry's name for it before you reach the Registration panel.

Organisation is the registrant, which is often the requester's provider rather than the requester, and Type says where in the hierarchy the block sits. In RIPE data the value is one of ten, and the RIPE dialect walks them; the three this ticket meets are ASSIGNED PA, end user space at the bottom of the provider chain, SUB-ALLOCATED PA, space an intermediary has been given to delegate onward from a block it does not ultimately hold, and ALLOCATED PA, the member's own block, and RIPE's own documentation says the attribute records the type of data and its position in the hierarchy, deferring to policy for the formal definitions. In ARIN data the ARIN dialect is shorter, and what SWIP is carries the manual's definitions of reassignment and reallocation and the incidental use carve-out; what matters for this ticket is that the organisation on a record need not be the only party using the addresses, that ARIN says the organisation name in a simple reassignment is free text it does not vet and that such a record grants that entity no rights over it, and that ARIN describes a network record as showing the organisations and contacts with authority over a range, which is a statement about authority and not about who uses the addresses.

So a name match is a name match, and not control. Nothing on the page closes that gap, and only two things outside it can: a demonstration from the range itself, such as a value you issue served back from an address inside it, or confirmation from the contact the registry publishes for the registered block rather than from the ticket. Ask for one of those before any grant. What a record proves settles the direction: a record tells you which operator to ask, never who is using the address today, and a missing customer record has innocent explanations, so the absence of the requester's name is not a finding against them either. Parents, allocations and assignments is the reading of the tree itself. The holder read ends in one of three states, and the table below keys on them: the record names the requester's own organisation, in the Organisation row or in an assignment beneath the provider's block; the record names a provider whose customer the requester claims to be, which includes the case where it names the very ISP the ticket named, since that is a fact the requester supplied; or the record names nobody the ticket mentions. Only the first is close to what the ticket asserted, and even there what a status lets the holder do is the reminder that ASSIGNED PA space belongs to the service agreement, not to the customer.

Who else is inside it: routing, sampling and tags

The Routing panel answers the second claim from the announcement side. Its rows are Announced, yes, no or n/a when no routing source answered; Routed prefix, printed only when the announced prefix is not the block you typed, so a /24 whose Routed prefix is a /20 sits inside an announcement wider than the ticket; Origin AS with the announcing network's holder name where the source gives one; RPKI, the status as the source supplies it, which the docs define as valid, invalid or unknown when no ROA covers the space; More specifics, a count of announcements inside the covering prefix; and Less specific, the larger announcement above, when there is one. The collapsed Validating ROAs table beneath lists Prefix, Origin, Max length and Validity, and its prefixes can be wider than the range in the ticket. A ROA authorises an origin, not a holder's identity: RFC 9582, the ROA profile from May 2024, says the validation provides authorization but not authentication, and custody is four dates is where that distinction is worked through. The findings above the panels read the same rows for you. Carved into smaller blocks fires on an aggregate when several networks announce pieces inside it rather than the range itself, Space is sub-let names the companies using sampled addresses when they are not the network that runs them, Announced by someone else says sampled addresses report a different network from the one announcing the block, which the finding itself describes as how leased or sub-allocated space looks, and Mixed use says the sampled addresses do not agree about what the block is. The block dissolves into /24s is the pattern behind the first of those.

The address sampling panel answers from inside the block. Its heading reads Address sampling with how many of the block's addresses have been checked, and the docs' rule travels with it: the site samples addresses inside the queried block, readings accumulate across lookups, and an unsampled address is not a clean address. The chip row counts the sampled addresses carrying each verdict, VPN, proxy, Tor, datacenter, abuser and blocklisted, printing a chip only for a verdict the sample turned up, and each count carries an agreement breakdown, how many rest on more than one feed, on a single feed alone or on a claim another feed denies, so a count that rests on one unopposed feed is visible as such. A mixed use chip appears when the sampled addresses disagree, a red Blocklisted on line names every list any feed reported, and where the site's own active check has confirmed proxies the panel prints one line, in the docs' example form, that a number of addresses in this block answered as a proxy on our active check on a date; what a check does and how it chooses what to look at is not documented, and the absence of that line means not checked, not clean. The block map draws one cell per sampled address against the unsampled remainder, and when the read hit its row cap the head says addresses shown rather than sampled and every count is a floor. Beneath it the collapsed Per-source detail table carries one row per feed for each sampled address, with Address, Source, Verdict, Risk, Blocklists and Checked, plus ASN and Operator columns when they vary across rows, a value identical on every row being restated once above the table instead; its Checked cell gives the latest date and how many readings stand behind the row, its Operator cell can carry a tenant's name in parentheses beside the operator's, and its Verdict cell carries the mobile flag that is the carrier NAT tell how to recognise a shared address reads. The address versus the range around it is the density argument in full.

Tags sit on the overview at the top. Confirmed tags carry a confidence and, on a block tag, the block it sits on, under a label that says who confirmed them, and the docs' rule is that a tag on a network or a block was confirmed by a person with evidence, with one exception for a high confidence finding from the site's own active checks; machine proposals sit in a separate row labelled as not yet confirmed. The ones that read a range for this question are the infrastructure labels, Hosting / datacenter, Cloud provider, Business ISP, Eyeball ISP and Mobile carrier, which the docs, naming hosting and eyeball ISP as examples, say may be applied from sampled evidence, and the anonymity labels, VPN provider, Proxy provider, Residential proxy and Mobile proxy, which are claims about what a business sells and are never applied from sampled evidence alone. The read: eyeball or mobile space is shared by construction; hosting or cloud space holds many tenants, and a record naming one tenant on a small block narrows that without settling it; a proxy, VPN or Tor chip that more than one feed agrees on marks a range carrying strangers by design, and a chip resting on one feed or disputed by another is a reason to open the Per-source table before deciding. Every one of those carries its counterweight. The report has no registry roster of tenants; Space is sub-let rests on what the feeds say rather than on a registry record; unsampled is not clean, and a clean sample is not a clean block; and no tag is not innocence, since a tag is applied only where somebody, or the site's own check, looked and decided. What shared actually buys you is the same reading from the sender's chair, and what an AS number is not is why none of this ever widens to a network.

Four kinds of range a ticket names

An office or enterprise egress. A small block or a handful of addresses, usually Business ISP space registered to the company itself, one origin, no sub-let or carved finding, and a population that is the requester's own staff and their guests. Where the record names only the ISP the ticket names, read the range as the next kind, because any customer of that ISP could have written the same ticket, and where the space reads as Eyeball ISP or Mobile carrier, read it as the last. Triaging the signal is where one corporate egress address fronts a whole workforce, so even the best case is a crowd, and corporate egress and browser relays is the reminder that secure web gateway vendors route customer traffic through their own egress ranges, which are the third kind rather than this one.

A security scanner or a partner's hosting range. A hosting tag on a provider's block, one origin, and a claim that the requester is the only tenant, which no record answers and the sample cannot: a detailed reassignment or an ASSIGNED PA object naming the requester says the provider delegated the block to them for their own use, a SUB-ALLOCATED PA object naming them says they sit between the provider and further customers of their own, which is more tenants rather than one, and a simple reassignment says only that the provider wrote their name. This is the kind the table calls provider space with the requester as one tenant, and it is the ordinary case.

A vendor's SaaS or cloud egress. A Hosting / datacenter or Cloud provider tag, a slice of a large provider assignment, and a range the vendor publishes itself and changes. Two vendors publish such a file, and their own pages, each read on 14 September 2026 and each named here only as the author of its own page, say what it is. The AWS documentation page for its published IP address ranges says the file exists so that you can identify traffic from AWS and allow or deny traffic to or from some AWS services, that it covers the services customers commonly use for egress filtering and does not publish the ranges for all services, that customer brought address space is not included, that some of its services run on the address space the file lists under its compute service, and that to keep a history you save successive versions yourself; its notifications subpage says a notification goes to subscribers whenever the ranges change, and neither page gives a frequency or uses the word allowlist. The Microsoft page for Microsoft 365 URLs and IP address ranges says its endpoint data is updated as needed at the beginning of each month with mid-month updates possible, that new addresses and URLs are published 30 days before becoming active, that its scope is connections from a user's machine to the service and nothing inbound, that its service area groupings cannot effectively be used to restrict access because features span workloads, and its connectivity principles page says Microsoft does not support selective allow-listing, that domain endpoint data is what it recommends as the primary source, and that IP prefixes are published for some services only. Its tables list host sized entries beside blocks as wide as a /13. So a vendor range is shared by design, the vendor's own page is the authority for what is in it and the ticket is not, the site does not read any vendor's file, so nothing on a report says whether a range is in one, and a vendor's range is never a reason to exempt anyone from the MFA prompt. Category, not verdict is why a Cloud provider tag on such a range is a description of the space and not a finding against the vendor.

A shared access range. A Mobile carrier or Eyeball ISP tag, a mobile flag in the Per-source table, carrier NAT behind the address, a platform relay, and a population exclusive to nobody; what to do instead and what the published lists cannot settle are the two readings of that population. Each kind sets a default for the table, in the order above: the office egress, as asked, with an expiry and a scope; the scanner or partner range, narrower, plus a paired account or device control; the vendor's egress, the vendor's own published list plus a paired control, and never a network's width, since the routing unit, not the company has settled that an AS number is a routing policy and not a company, and RFC 1930 itself says a single homed site's prefix should be placed in an AS of the provider; and the shared range, declined, with a request for a different identifier.

Whether it will stay that way: origin history, the Time machine and the review

The third claim is one the requester cannot honour, because the future of the range is not theirs to control either. The Origin history panel prints one row per network and prefix, Network with the holder and a flag, Prefix, and When as first seen to current or to a last seen date, with the number of periods beneath when an announcement broke and came back, and it keeps covering routes from larger blocks in a collapsed section of their own, described on the page as transit rather than control. The findings The route changed hands and It changed hands recently are the churn read, and a parade of origins is the pattern in full. One consequence for a slice is worth knowing before you look: a /24 that has only ever been carried inside a wider announcement has no origin history of its own. The panel then prints that no announcement of this exact prefix is recorded, files the wider announcements under covering routes, and the Time machine, which is built from announcements of the block or of pieces inside it and never from covering routes, does not appear. The stability read for such a range belongs to the Routed prefix, so look that block up as well.

Where the Time machine does appear it gives the origin AS at a chosen moment, prints Origin changed from one network to another when the announcing network differs from the previous moment, says what a chosen date predates, and ends with the line that registration, RPKI and labels are shown only where they were recorded, never back-filled into a date nobody was watching. That is the read for who announced this range on the day the contract was signed, and it is a sample with collector bounds, as a sample of the routing system, not a recording states, and as the routing ledger reads for a single date. Verdict changes we have recorded, beneath the Per-source table, is the sampling side of the same question. And nothing watches. What is and is not on offer is explicit: no monitoring, no alerts and no notifications; a lookup runs when something asks for it. An allow rule needs an expiry and a review exactly as the deny rule in a review that works does, run against the fields what to store and what to diff names, through the keyless API on your own schedule, and what a gap means is the caveat that the days between two runs are unseen, not quiet. A range that changes hands after the rule is written tells nobody until somebody looks.

The decision table

Four notes on the table. The ordinary outcome for hosting or cloud space is narrow and pair, not grant and not decline, because a provider's block carries other tenants whether or not the record shows them, and what the letter is, and is not is the reminder that a range asserted in a ticket is an unauthenticated assertion to everyone but its author, exactly as a letter of authorization is. Declining is a request for a different identifier, an account, a device, a client certificate or a static egress the requester actually controls, and RFC 7754 concludes that filtering should be done on the endpoint whenever possible, while naming a hybrid of endpoint and network filtering as least damaging; it is not an accusation against the requester or the holder. No row grants an MFA exemption: the connection a rule admits is evidence about a network and never about a person, so a range can narrow who reaches the prompt and never replace it. And every grant carries an expiry, a review date and the dated read attached to the ticket, so the review is a diff rather than an argument, and the unsettled row is a fallback, not an override: where the holder and a sampled block already place a range in a row above, that row wins. Triaging the signal reaches the same pairing from the fraud side, and choosing a width you can defend is the mirror image of every row.

What a subnethistory report shows for a range in an allowlist ticket, and what it cannot

For the range: the overview with its holder chip, which names the announcing network where the report holds one and otherwise the registrant, and the confirmed tags with their confidence and the block each sits on; the findings, one line each; the address sampling panel with its chips, block map, Blocklisted on line, Per-source detail and Verdict changes; the Routing rows and the Validating ROAs table; the Time machine where the block or pieces inside it have announcements of their own; the Origin history with its covering routes kept apart; the Autonomous system panel for the announcing network; and the Registration heading and rows with Registry contacts and Enclosing blocks beneath. For the review, what the report shows for a block you watch walks the same panels for a block you hold, and the fields to keep are in what to store and what to diff above.

What it cannot show, stated in the same breath. Whether the requester holds, controls or uses the range: Organisation is the registrant, the requester may appear nowhere, and a matching name is a name. No reverse DNS and no PTR record anywhere on the page or in the API. No registry children under a block, and no tenant behind each address beyond a name the feeds report. Sampling only where somebody looked, so unsampled is not clean and a clean sample is not a clean block; readings that accumulate across lookups rather than from any watch on the range, with nothing watching and nothing notifying. Any vendor's published range file, which the site does not read. And the absence of a tag, which is never a finding of innocence. What a clean result does and does not mean and attribution ends where the evidence does are the two limits paragraphs this one leans on, and the tell is the transport is why what a rule admits is a fact about a network, and the person behind it is never in the packet. The site's own terms say it plainly: sources disagree, lag and make mistakes, confidence scores are estimates and not verdicts, everything is provided as is, so verify independently before you block, buy, accuse or decide. An allow rule is a decision.