Whois status decoded: what ASSIGNED PA, SUB-ALLOCATED PA, LEGACY and the rest actually mean
Somewhere in every registry record sits a short string in capital letters, and people paste it into a search box because nothing on the page explains it. The status field is each registry's own vocabulary for one thing: the registration relationship. It tells you who was given the space, whether they may hand it onward, and what sits above them in the hierarchy. It does not tell you whether the space is clean, and the same kind of block wears different words in different regions. This is the decoder, registry by registry, with the practical translation a buyer, lessee or investigator actually needs.
A registration vocabulary, not a quality score
First, where the string lives. In RIPE style whois output it is the status attribute; in ARIN whois it is the NetType line. In RDAP, the protocol replacing whois, the same string sits in the type field of the IP network object, which RFC 9083 defines as an RIR specific classification of the network. RDAP also has a field literally named status, and it is a trap: it describes the state of the database object and in practice comes back as active, so a script reading status and expecting ASSIGNED PA will in practice just get active. The registry classification is in type. Whois vs RDAP covers the two protocols; this post is about the words themselves.
The RIPE dialect: ten values, one hierarchy
The RIPE Database recognises ten status values on IPv4 network objects, the attribute is mandatory and single valued, and the database documentation calls its own wording advisory, deferring to the policy documents for the formal definitions. The vocabulary encodes a tree, and reading it is reading the tree.
| Status | What it marks | Registered below it |
|---|---|---|
| ALLOCATED UNSPECIFIED | Mostly registry level space the RIPE NCC itself administers, plus a few historic member allocations | Allocations, PI, anycast, legacy, or another block like it |
| ALLOCATED PA | The block the RIPE NCC issued to a member LIR | Partitions, sub-allocations, assignments |
| ALLOCATED-ASSIGNED PA | An allocation with a single assignment of the same prefix length, one object doing both jobs | n/a |
| LIR-PARTITIONED PA | The LIR splitting its own allocation for internal management, same organisation throughout | More partitions, sub-allocations, assignments |
| SUB-ALLOCATED PA | A chunk handed to a different downstream organisation, which delegates onward itself | That organisation's assignments |
| AGGREGATED-BY-LIR | Many same purpose assignments folded into one object, hiding the individual end users | Individual assignments, where registered |
| ASSIGNED PA | End user space at the bottom of the provider chain | n/a |
| ASSIGNED PI | Space the RIPE NCC assigned directly to an end user, outside any LIR allocation | n/a |
| ASSIGNED ANYCAST | DNS anycast infrastructure space, TLD nameservers originally, Tier 0/1 ENUM added by a later policy | n/a |
| LEGACY | Space held since before the RIPE NCC existed | Varies |
Three of these deserve a sentence more. SUB-ALLOCATED PA is the one that signals an intermediary: an organisation between the LIR and the end user, delegating onward from space it does not ultimately hold. AGGREGATED-BY-LIR is the bulk shortcut, a status IPv4 gained only in mid 2024 when proposal 2023-04 was implemented, and its whole point is that the individual end users are not separately visible. And ASSIGNED PI is the odd one out of the PA world: PA versus PI covers the difference in depth, but the short version is that PI was issued by the registry directly, the holder keeps a contractual link to the RIPE NCC either through a sponsoring LIR or directly, and new IPv4 PI is no longer issued except to internet exchange points.
The ARIN dialect: three everyday values, a retired one and the leftovers
For space ARIN itself administers and has issued to organisations, the NetType line reads Direct Allocation for space issued by ARIN, and Reallocated or Reassigned for space an upstream has delegated to a customer. The policy manual draws the line cleanly: a reallocation is meant to be carved up further for the recipient's own customers, a reassignment is for the recipient's exclusive use. Older guides list a fourth value, Direct Assignment, and you will still meet it in old records and documentation: ARIN stopped distinguishing direct assignments when its harmonised fee schedule took effect in January 2022, a later policy scrubbed the term from the manual, and classic end user blocks like MIT's 18.0.0.0/11 now print Direct Allocation like everything else.
Two wrinkles matter for anyone decoding ARIN records. There is no LEGACY value: space issued before ARIN's founding in December 1997 prints an ordinary Direct Allocation when an organisation actively holds it, and the clue is a registration date older than ARIN itself, though only in one direction, since transfers reset dates and a recent date proves nothing about origin. Pre RIR ranges not registered to a specific organisation wear their history openly in an Early Registrations NetType family, with both Transferred to and Maintained by wordings observed on live records, and reserved ranges print IANA Special Use. The second wrinkle is the data source: ARIN's RDAP renames the downstream types, so a block whois calls Reallocated comes back from RDAP as plain ALLOCATION and Reassigned comes back as ASSIGNMENT. Only the DIRECT prefix tells you the block came straight from the registry.
APNIC, LACNIC and AFRINIC in one pass
APNIC splits status on two axes: ALLOCATED versus ASSIGNED, meaning may be carved up further versus end use, and PORTABLE versus NON-PORTABLE, meaning the space survives a provider change versus must be returned to the upstream. The four combinations are the whole current vocabulary, and APNIC's guide adds that an ASSIGNED NON-PORTABLE block may not be sub assigned. Resist the tempting shortcut of reading PORTABLE as PI: it holds at the assignment tier, where ASSIGNED PORTABLE plays roughly the role of RIPE's ASSIGNED PI and ASSIGNED NON-PORTABLE that of ASSIGNED PA, but an ALLOCATED PORTABLE block is a registry to LIR allocation, the counterpart of RIPE's ALLOCATED PA despite the different label. LACNIC uses plain English with no suffixes at all: live records show ALLOCATED, ASSIGNED and REALLOCATED, which LACNIC's documentation describes as space issued by the registry to ISPs, space issued to end users, and ISP sub delegations respectively, and the same documentation lists a fourth, rarer value, REASSIGNED, for sub delegations made below an end user block. AFRINIC runs a RIPE derived database, so a RIPE trained eye can read its common statuses directly: ALLOCATED PA, ASSIGNED PA and ASSIGNED PI on live records, with its documentation also listing SUB-ALLOCATED PA, ASSIGNED ANYCAST, POLICY-RESERVED and ALLOCATED UNSPECIFIED placeholders like 41.0.0.0/8.
What a status lets the holder do
The practical questions behind a status string are always the same three: can this holder sell or lease the space, who controls the records above it, and where does responsibility land. On transfers, the dependent statuses are the hard stop. RIPE policy says space assigned or sub allocated by a service provider must be returned and renumbered when the relationship ends, so ASSIGNED PA and SUB-ALLOCATED PA space cannot change hands on its own; only the enclosing allocation trades. At ARIN, the seller must be the current registered holder, which in practice rules out a downstream customer selling space its ISP merely reassigned to it. Everything else is more transferable than folklore suggests: under the current RIPE transfer policy any legitimate resource holder can transfer, LEGACY space included, with the status mostly deciding who may receive it. Leasing follows the same logic one rung down: whoever offers you space on lease should either be its registered holder or hold it under a status that permits onward delegation, and leasing out IPv4 safely covers the lessor's side of that arrangement. What the string never shows are the time locks: IPv4 in the RIPE region cannot be transferred for 24 months from the date the current holder received it, however they received it, with a further merger or acquisition the one exception the policy itself states, so a counterparty who acquired a block last year cannot legitimately sell it yet. Check the current policy text before a deal, and the post transfer checklist for what comes after.
Control follows the hierarchy. For sub delegated space the parent's maintainer gates the records: in the RIPE Database, reverse DNS authorisation runs against the covering network object's maintainer chain, so a sub allocation holder only controls its own reverse DNS if the parent set it up that way, and at ARIN a downstream customer manages reverse DNS only where the upstream registered the delegation to them. ARIN's own guidance states the power relationship plainly: the direct registrant retains the ability to reclaim a reassignment or reallocation at any time. Abuse contact chains work the same way, through the records the upstream chose to publish: RIPE's abuse-c inherits down the hierarchy when a more specific object carries none, and ARIN's abuse contact hangs off the organisation record rather than the network type.
How not to misread a status string
The misreadings are more dangerous than the ignorance. The word ASSIGNED tells you nothing by itself at RIPE: the suffix does the work, since ASSIGNED PA is dependent customer space and ASSIGNED PI is a direct, transferable registration. Never map RIPE's ASSIGNED PA onto ARIN's old assignment concept either; one points down the hierarchy, the other pointed at the registry. A LEGACY flag is not suspicion material: it records when and how the space entered the system, the holder may sit on any of several contractual footings, and what legacy space actually is takes the full story. Above all, nothing in RIPE or ARIN policy attaches quality, trust or conduct meaning to any of these values. The status describes registration mechanics as they stand today; it is not evidence that a range is clean or dirty, and a block can change behaviour completely without its status ever moving.
On our reports the decoder applies directly: the Type row prints the registry's status string verbatim, in the registry's own wording, RDAP renames included, with the Status row adding the registry's own flag when it differs and the Organisation row naming the holder. The Enclosing blocks table carries a Type column of its own, so the hierarchy this vocabulary encodes is visible on one screen: an ASSIGNED PA block with the ALLOCATED PA it is carved from sitting in the Enclosing blocks table of the same panel. Reading the two together answers the question the string alone cannot: not just what kind of block this is, but whose block it is carved from.
Next time a record shows you a status string you do not recognise, look the range up on the front page and read the Registration panel against this post: the Type row is the registry's word for the block, the Enclosing blocks are the layers above it, and the rest of the report, the routing record, the announcing network and any confirmed tags, is where behaviour lives. Status tells you where a block sits. Everything else tells you what it has done.