Vetting an IPv4 lessee: reading a tenant's ASN when no registry will check it for you
Somebody wants to rent a /22 from you. Your block is clean, you have read its history yourself, and none of that is the question. The question is the autonomous system that will announce it, because for as long as the lease runs your addresses sit inside that network's record and are judged along with it. A lease has registry paperwork, and recording the sub-assignment is part of doing it properly, but no registry examines your tenant, so the reading is yours and the decision stops with you. Every panel, row and figure named here was confirmed against a live report on 22 September 2026.
What the lease actually attaches
A lease is described as renting addresses, and that description is what makes the vetting look optional. Addresses do not announce themselves. Somebody originates them, and for the length of the lease that somebody is your tenant, from their autonomous system, alongside everything else they announce.
This matters because a good deal of the judgement applied to address space is not applied at address granularity. Some of it is applied to the announcing network. The mechanics are already set out in the two lists that judge an origin: one of them is scoped to the announcer, and its own description of the consequence is that blackholing a listed system makes all networks announced by them unreachable. The other publishes a formula that counts impacts against the total address count of the autonomous system, so the unit of assessment is the network, not your block inside it.
That post reads the situation from the tenant's chair: an operator with clean space, choosing where to have it announced, and learning that the choice carries consequences. Turn it around and the same paragraph describes your position exactly, with one difference that is not in your favour. The operator choosing an upstream can change their mind and move. You have signed a term.
The lessor's side of this has been stated on the site once, in a single clause: the autonomous system named on the letter of authority is the autonomous system whose history you are attaching your space to. It is correct and it is the whole argument in compressed form. What follows is the reading it implies, which panels of a report carry it, and, more usefully, which panels look like they carry it and do not.
Everything downstream of the decision is covered elsewhere and is not repeated here. The paperwork that limits damage once you have said yes, the contract terms worth having, what to watch while the lease runs and how to unwind it at the end are each their own section of leasing out IPv4 space safely. Who may sign what, and why a letter exists at all, is in what an LOA is for IP address space. This post is only about the read that happens before any of that.
The column that is not a history
Look up an autonomous system and the Autonomous system panel carries an Announced prefixes table, one click in, with four columns: Prefix, Family, First announced and Last seen. It is one of the first things a lessor reaches for, because it looks like the tenant's track record, and it is the one most easily read as more than it is.
First announced is not the date the network first announced that block. It is the start of the earliest visibility window inside the period the report asked about, and the period it asks about is short. The site states the scope in its own writing on routing history: on an ASN report the announced prefix list covers roughly the last two weeks, so a prefix a network dropped a month ago is absent from it. The same boundary that removes an old prefix also truncates the dates on the ones that remain.
The effect is easy to see on a network nobody would call new. AS16276 has been allocated since February 2001. Reading its table on 22 September 2026, the rows at the top carried First announced dates of 22 September, 21 September and 16 September 2026, with Last seen reading current. Nothing is wrong with the data. The column is answering a narrower question than its label asks, and on a network with many current prefixes the rows you meet first are the ones seen most recently.
For a lessor the failure runs in the dangerous direction. A tenant who registered an autonomous system last month and a tenant who has announced the same space for a decade can produce tables that look alike, and the one you should be asking more questions about is the one whose dates are genuinely recent. You cannot tell them apart on this panel. Reading it as provenance converts a measurement window into a character reference.
Two figures inherit the same boundary and are worth naming so they are not read as totals. The Prefixes row in the Autonomous system panel, which prints a count of v4 and v6 entries, counts what is in that window. So does the announced space figure that the active checking panel divides by. Neither is a statement about everything the network has ever held.
There is a reading that does carry history, and it is one lookup away. Origin history is built for a prefix, not for a network. Take the blocks that matter from the tenant's table, look each one up on its own, and you get the announcements with their periods, which is the record you thought you were reading. It is slower and it is the real thing. How to research an ASN covers how to read churn once you have it, including the point that movement alone is not a finding and the shape of the movement is.
What a network report does not ask, and what it answers about something else
An address lookup and a network lookup do not draw the same report, and the difference is not cosmetic. Ask about an autonomous system and several panels you may be used to are simply not there: there is no Routing panel, no Origin history, and no per-address sampling panel. A reader who has learned the report on addresses and prefixes will notice their absence, and the natural conclusion, that nothing was found, is wrong. They are absent because those questions are asked about address space and a network is not address space. Nothing came back clean. Nothing was asked.
The same care is needed one level down. In the Autonomous system panel a row whose value is missing is not drawn at all, so the panel you are reading is only the fields that answered. An Allocated date and a Registered date that are present tell you something. Their absence does not distinguish between a record that has no such date and a source that did not respond on the day you looked. The Sources panel at the foot of the report is where that distinction lives, because it names each source and whether it answered, and on a decision of this size it is worth reading.
One panel invites a specific misreading. Registration renders on a network lookup, under the same heading it carries on a block lookup, and it is not about address space. It is the registry record of the autonomous system itself. There is no block in it and no range, and it does not tell you anything about what the tenant holds. If you have built a habit of reading Registration as the holder of a prefix, that habit will mislead you here. The identity read that panel supports on a block, including how to resolve a handle into a name and what the contact roles do and do not imply, is set out in the post on buying from a company the record does not name, and it applies to the counterparty in a transfer rather than to a tenant.
The flag beside the AS number is a registry fact and not a business one. It records where the number is registered. A company can operate anywhere, and plenty do, so a mismatch between the flag and the letterhead is a question rather than a finding.
Finally, the Time machine renders on a network lookup, and on a network lookup it has very little to say. It reports that the announcing network has not changed in anything we hold, and gives the date that holding starts. That date sits inside the same short window as everything else on the page. It reads as a stability record. It is a restatement of how far back the question reached.
What a machine labelled, and what a person did
Tags on a report come from two places and the difference decides how much weight a tag will bear. Two can arrive without anybody looking, both off the site's own active checks: one records that proxy exits were observed, which is a measurement and stops at the addresses, and one names the network as a proxy provider, which is an attribution about what a business sells. They are not the same kind of claim, and the heading above the chip row tells you which you are reading. Every other label in the vocabulary, including most of the ones a lessor wants, is applied by a person who looked at that specific network and confirmed it.
That list is worth reading slowly, because it is exactly the list of things you are trying to find out. Address leasing, meaning a holder who leases space to third parties rather than using it. Shell ASN. Frequent origin change. Hijacked space. Fabricated registration. Unreachable abuse contact. Every one of those is a claim about a business, and not one of them is reached automatically from a lookup. They appear when somebody has been through the network and concluded it.
The consequence is the one sentence to take from this section: the absence of a tag is not evidence. A clean chip row on a small autonomous system usually means nobody has had cause to examine it, and a tenant nobody has examined is the ordinary case rather than the reassuring one. A present tag is worth a great deal. An absent one is worth nothing at all, and the report is careful not to claim otherwise.
There is a related subtlety on the suggestions row. Suggested labels shown on a network page were produced by earlier lookups of addresses and blocks inside it, not by the lookup you just ran. They are a record of what sampling has proposed over time. They are not the output of the query in front of you, and an empty row is another absence that means nothing on its own.
The active checking panel is the one place a network report states its own coverage and it states it plainly. On AS16276 it read, on the day of writing, that our own active checks swept 17 /24s in this network and found proxy exits in 9, that this is under 0.1 percent of about 17,935 /24 equivalents of announced space, and that this is not enough of the network to describe the operator, so the finding stays with the blocks. Read the third sentence as carefully as the second. Nine in seventeen is a ratio with almost nothing behind it at that coverage, and the panel says so in its own voice rather than leaving you to work it out. None of that is a finding about the operator, and the panel declines to make one. What it supports is a question about those blocks.
What the leasing measurement says, and what it does not
There is a published figure that bears on this decision, and it needs its scope kept intact or it turns into something it is not. A 2024 measurement study inferred that 4.1 percent of advertised IPv4 prefixes were leased in April 2024, and that 1.1 percent of those leased prefixes were announced by systems listed on ASN-DROP, the deliberately small list Spamhaus calls its worst of the worst, against 0.2 percent of non leased ones. Roughly five times as likely. The full reading, with both studies it sits beside, is in what the measurements actually show.
The authors' own explanation is mechanical rather than moral. A lease arrives with routing authorisation attached, so announcements that RPKI would once have filtered as unauthorised now validate. The leasing market is attractive to an abuser because it solves a routing problem for them, not because leased space is inherently worse.
Two guards belong with the number every time it is quoted. It is a portrait of who leases, not a penalty measured on clean tenants: it describes the population of lessees, and a particular tenant in front of you is not a population. And the complement deserves the same care, because about 99 percent of leased prefixes were not announced by a listed system, which is not the same as 99 percent clean. That list is tiny by design. Absence from it says nothing about listings at address or prefix granularity on the same space.
So what does it license? Pricing, and attention, not refusal. It says the base rate for this specific hazard is meaningfully higher in the market you are selling into than outside it, which is a reason to do the reading rather than a reason to decline. A lessor who takes it as grounds to turn tenants away has drawn a conclusion the measurement does not support.
A read you can repeat
The mechanics of reading an autonomous system are covered in full in a method you can repeat, and this is not a second copy of it. What changes when the network is asking to rent your space is which parts of that read carry weight, and where the threshold sits.
Start with the findings the report puts at the top, because several of them are directly about the shape of a business rather than the state of a block. Newly registered is one, and on its own it describes a great many honest networks, so it sets the term rather than the answer. Named like a VPN is another, and it is worth knowing that this one reads the wording of the record rather than the behaviour of the network, so it is a prompt to ask what the space is for rather than an answer. It is also held back where an analyst has already classed the network, so its absence is not the opposite of its presence. No public profile is a third, and it is common enough among networks that simply never registered one. One way in, meaning a single upstream, is a fourth, and on a network proposing to take a /22 it is a fair question rather than a fault. Nowhere to report abuse is the fifth and the one worth weighing hardest, because it describes what will happen when something goes wrong on your addresses.
Then read the space they already announce, not as a count but as a population. The space it announces makes the point that a block nobody has sampled is grey rather than green, and that concentration matters more than the total. A tenant announcing a handful of blocks, all of them looked at and all quiet, is a different proposition from one announcing a great many of which almost none have been examined, even though the second will look emptier of bad news.
Then go one level down and look up the blocks themselves, for the reason given earlier: history lives on the prefix. Pick the ones that would sit next to yours. What you want to know is whether this network has held space steadily or has cycled through it, and that is visible on a prefix lookup and is not visible on the network page.
Read the upstream and downstream tables for shape, not as a roster. They come from routing observations rather than from contracts, so they record who was seen carrying traffic recently. A downstream list is often the most informative thing on the page for this decision, because a tenant who resells to others is running a different business from one using space themselves, and that raises the question this whole post is a long way of asking: if your space is sub-let onward, whose reading of their customers are you relying on?
Finally, ask for the declaration in writing, because no panel will ever answer it. The use the space is put to is a contract term and the report cannot see intent. The existing advice on that, and on what different answers should do to your price, is in vetting the lessee like a landlord.
Four answers, and no registry behind any of them
The read resolves into four situations, and they are not four grades of the same thing.
| What you found | What it supports | What it does not settle |
|---|---|---|
| A confirmed label on the network, with the chip row heading naming who confirmed it | Declining, or pricing the risk explicitly and writing the use into the contract | Whether it still describes the business, which is a question about its date |
| Proxy exits observed inside blocks this network announces | A question about those blocks, and a declaration of use before you go further | Anything about the operator: where the sample is thin the panel says so itself |
| An unremarkable record with nothing confirmed either way | Proceeding, with the paperwork and the monitoring doing the work | Whether anyone has ever examined this network at all |
| A record too thin to read, on a young or quiet network | Asking directly, and setting the term and the exit accordingly | Everything. Thin is not clean, and no further lookup will thicken it |
The fourth row is the uncomfortable one, and on a small or young network it is the one you should expect. Nobody has had reason to write anything about most of the networks in this market, so the reading returns a shrug. That is a real answer and it is not the same as a good one.
Compare this with the equivalent decision on a purchase, which ends somewhere else entirely. The post on buying a block from a company the record does not name works through its own branches and the last of them hands the matter to the registry, where the question is settled inside a process neither party watches. There is no such branch here. A lease does have registry paperwork, and recording the reassignment is part of doing it properly. What it does not have is a registry that examines your tenant, forms an opinion and can refuse. The marketplaces that sit in the middle of this market run their own checks, and what actually separates providers puts it precisely: a platform that verifies its lessees is protecting its holders' address space. What that verification proves is that a legal entity exists, which is a floor rather than a ceiling, and it is not a reading of the network.
Which leaves the reading with you, and makes the thin answer the important one to sit with rather than the one to rush past. The panels will tell you a great deal about a network somebody has already examined. On a network nobody has examined they will tell you almost nothing, clearly and without pretending otherwise, and what you do then is a commercial judgement that no report is going to make for you.
Look up the autonomous system on the letter, then look up the blocks it announces one at a time, and read the first table on the network page for what it is: a recent window, not a career. The decision you are making is not about your block. It is about whose record yours is about to join.