PA vs PI address space: which addresses you keep when you leave your provider
Somebody offers you a block, or your provider hands you one, and the question that decides what it is worth is whether you keep it when you leave. That answer lives in a single status string on the registry record, it means different things in different regions, and the vocabulary everybody reaches for started in one region and does not travel cleanly to the others. Here is what the labels mean, what each registry's own text says about returning space, and the two things portability does not buy you. Every policy document below was read on 20 August 2026 and is cited by its own version.
The split, in the policy's own words
PA and PI are RIPE community vocabulary. The current IPv4 policy for the RIPE NCC service region, ripe-826 of June 2024, says the two types of IPv4 address it describes are provider aggregatable and provider independent, and it is blunt about the consequence: if a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. Note the modality, because it varies elsewhere. The same document makes clear contractual arrangements mandatory for PA space, and requires the LIR to warn End Users of exactly that condition when it assigns them some. PI, by contrast, is assigned to an End User for a specific purpose and is registered to them rather than to the provider, which is why it survives a change of provider. It comes with its own restriction: ripe-826 says PI space cannot be used to make further assignments to other parties, so a PI holder cannot become a small provider on the back of it.
Reading the status string
In the RIPE Database the answer starts as a field rather than an inference, which is a better place to start than a broker’s description. The IPv4 status values listed in ripe-826 section 7.0 are ALLOCATED PA, ALLOCATED UNSPECIFIED, ALLOCATED-ASSIGNED PA, SUB-ALLOCATED PA, LIR-PARTITIONED PA, LEGACY, ASSIGNED PA, AGGREGATED-BY-LIR, ASSIGNED PI and ASSIGNED ANYCAST. One older value survives in the policy text but not in the database: section 5.3 says LIRs holding ALLOCATED PI or ALLOCATED UNSPECIFIED allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks inside. Six of the ten matter to a buyer, and the first is the one most often on offer. ALLOCATED PA is the registry’s own allocation to a member, held by that member rather than by any upstream, so it does not go back when the member changes transit provider, and it is what most blocks sold on the transfer market are. The return rule bites on space a provider handed down, not on space the registry allocated to you, which is why becoming a member and holding your own allocation is the ordinary answer for a network that wants addresses of its own. ASSIGNED PI travels with the holder. ASSIGNED PA does not, and neither does anything under a sub-allocation, since ripe-826 says all assignments made from a SUB-ALLOCATED PA block are PA and cannot be kept when moving to another provider. AGGREGATED-BY-LIR covers assignments an LIR registers in one object instead of individually, whether to parts of its own infrastructure or to End Users of its services, so the customers behind it are not listed separately; ripe-826 says purpose and contact details must be consistent across the whole assignment and that it cannot be kept when the LIR's services end. LEGACY is a third thing entirely, neither PA nor PI, covered in its own piece. Two traps are worth knowing. ripe-826 says address space with no explicit type in the status attribute is assumed to be PI, and tells LIRs to mark every new assignment PA or PI. That default is aimed at old assignment records rather than at the typed values above, so a missing type is not a neutral answer, but it does not turn an AGGREGATED-BY-LIR record into PI. And the IPv6 vocabulary is a separate list: ALLOCATED-BY-LIR is an inet6num value, and we found no IPv4 use of it when we checked the policy and the database documentation on 20 August 2026. Live examples, as the records read on 20 August 2026 and worth rechecking against the live report, since a status string changes the day a block is transferred or converted: 171.25.193.0/24 is ASSIGNED PI, 88.198.0.0/20 is ASSIGNED PA inside a provider's own datacentre pool, 2.56.0.0/24 sits under an ALLOCATED PA allocation, and 130.89.0.0/16 is LEGACY.
The same question in other regions
Outside the RIPE region the concept survives and the words change, so a contract drafted with RIPE vocabulary can land oddly elsewhere. ARIN's Number Resource Policy Manual does not use this language: a search on 20 August 2026 found neither provider independent nor provider aggregatable, because ARIN's terms are allocation, reallocation and reassignment, and it no longer uses a separate direct assignment category for space it issues. ARIN does have a return expectation, it is simply softer and lives elsewhere: its policy recommends that a customer moving to another provider return the addresses and renumber, and encourages ISPs to require it. APNIC document apnic-127, version 015 of 20 February 2025, calls the same split portable and non portable, and section 5.2.2 says downstream delegations are non portable and must be returned to the LIR if the customer ceases to receive connectivity from it. The LACNIC Policy Manual version 2.21 writes portable, in brackets provider independent. AFRINIC's Consolidated Policy Manual version 1.6, the current published version when we checked, defines both terms and says the space should be returned and the network renumbered, a should where ripe-826 says must. That is one question answered at three strengths, must in the RIPE and APNIC texts, should in AFRINIC’s and a recommendation in ARIN’s, with the LACNIC manual naming the split without setting a return rule of its own, assembled from five separate manuals, and ripe-826 itself notes that it does not describe the policies of other registries. The practical reading for a buyer: ask which registry's policy governs the block, then read that registry's own words rather than the ones your broker used.
Why you cannot simply buy new PI
If PI is the good stuff, the obvious question is how to get some, and in the RIPE region the ordinary answer is that you cannot. ripe-826 says the RIPE NCC no longer allocates or assigns PI address space except to Internet Exchange Points, and the cut off is older than most people think: it came on 14 September 2012, the day the last /8 policy took effect, seven years before the November 2019 exhaustion date that usually gets the blame; the RIPE NCC's announcement that day said no new IPv4 provider independent space would be assigned. The exchange point exception is narrow rather than a side door: the space comes from a reserved /15, it may be used to run an exchange peering LAN only, other uses are forbidden, and unused space goes back. Do not read peering LAN and PI as synonyms either, since large exchanges run their peering LANs on PA space, the LINX London peering LAN at 195.66.224.0/21 among them. Two real routes remain. Existing IPv4 PI can be transferred: ripe-807, published 30 October 2023, allows provider independent resources to move to a RIPE NCC member, or to an entity with a contractual relationship with one, subject to the holding period on scarce resources, and it excludes resources that RIPE policy requires to be returned to the RIPE NCC. And legacy space can be converted, since the RIPE NCC states that an LIR holding legacy space can convert it into a PA allocation or a PI assignment, and that a legacy holder registered through a sponsoring LIR can convert it into a PI assignment. That one is worth weighing rather than treating as free PI. Legacy space already survives a change of provider, and converting it moves the range under the sponsoring LIR contract and the fee and return conditions set out below, with no route back to legacy status. The gate is one way in both directions that matter: the RIPE NCC says converting a PI assignment into an allocation is irreversible, and since ripe-826 stops the RIPE NCC assigning PI at all outside the exchange point pool, there is no route back from a PA allocation to a PI assignment.
What portable does not mean
Two disappointments are worth absorbing before you pay a premium. The first is that PI is not ownership, it is a registration contingent on paperwork. In the RIPE region the community policy ripe-637, of 11 March 2015, requires an End User to hold a contract with a sponsoring LIR or with the RIPE NCC, and requires that contract to state that the resources may not be sub-assigned and that they return by default to the RIPE NCC if the holder cannot be contacted or the annual fee goes unpaid. If sponsorship lapses, ripe-815 of January 2024, a RIPE NCC procedural document rather than a community policy, gives notice to arrange a new sponsor and then, in its own word, starts deregistering the resources. The second disappointment is that no registry sells you routability, and the four whose manuals we read on 20 August 2026 say so in their own words: LACNIC warns that portable addresses are not guaranteed to be globally routable, APNIC says small portable assignments are the most likely to suffer routability problems, ARIN says an allocation in no way guarantees the addresses will be routed by any particular operator, and AFRINIC calls PI expensive to route and possibly not globally routable. Routing and registration are separate systems, and prefix filtering and RPKI are how one is pulled into the other. That separation cuts the other way too, and it is the practical trap for a customer multihoming on PA space: authority to publish a route object or a ROA sits with whoever holds the covering object, so if you are announcing your provider's space from your own AS, whether the networks that filter on registry and RPKI data keep accepting it depends on your provider publishing those objects for you, or delegating the authority so you can publish them yourself. Negotiate it before you sign, not after you leave.
Look the block up on the front page before you agree terms: the report's Type row carries the registry’s own status string verbatim, so ALLOCATED PA, ASSIGNED PI, ASSIGNED PA, SUB-ALLOCATED PA, AGGREGATED-BY-LIR or LEGACY is right there on the record, with the separate Status row showing the registry's own flag. Beside it you get the organisation and the published contacts, which for RIPE records often means an organisation handle in one row and the holder by name in the contacts table, though read that name for what it is, since on ALLOCATED PA, SUB-ALLOCATED PA and AGGREGATED-BY-LIR records it is the provider or the LIR and the customers using the addresses are not listed at all. It tells you who to ask about the block, not who was behind any one address inside it, and a block that size can cover many unrelated networks, the abuse contact the block resolves to, and which networks have announced it and since when. If the seller's description and the status string disagree, that is a question to settle before signing: ask which agreement the block sits under, member, sponsoring LIR, direct or none, rather than taking either at face value.