The Practical Applications of PI Space
Provider independent, or PI, space is rare – and in incredibly high demand right now. For organizations, the topic of buying some usually arises right after a provider change, a multihoming project, or the sudden realization that half the network is numbered out of someone else’s block. However, between the incredibly low prices of IPs nowadays and desire for less reliance on third-parties, PI space has taken center stage.
What Is PI Space, and Why Is It Different?
In simplest terms, PI space is a type of IP space wherein the address block belongs to your organization’s network identity, not to the ISP that happens to carry your traffic this year. That is what makes it different, and that difference has real operational consequences.
If your addresses came from a provider, the provider is the parent of that space. If your addresses are PI, the provider is just moving packets for you. The addresses stay yours to use with whatever upstream or upstreams you choose, subject to registry policy and normal Internet routing realities. ARIN’s own guidance calls directly held resources “portable” and contrasts them with ISP-issued space that is generally non-portable and must be returned when service ends. APNIC makes the same distinction in its Whois guidance: direct delegations are portable, while member-delegated customer space is non-portable.
What PI is usually being compared to
PI is really being compared to PA space: Provider Aggregatable address space, sometimes loosely called provider-assigned space. PA space comes out of an ISP or LIR allocation. RIPE says the advantage of PA space is that routing information for many customers can be aggregated once it leaves the provider’s routing domain. That aggregation is the whole point. It keeps the global routing system from carrying every customer prefix as its own little snowflake.
So the practical split looks like this. PA space is optimized for the Internet’s routing economy. PI space is optimized for the end user’s autonomy. Neither is “better” in the abstract. They solve different problems.
The real difference: control
The first and biggest difference is portability. With PA space, changing providers often means renumbering. With PI space, it does not. That alone can justify PI for environments where renumbering is painful: large enterprise WANs, customer-facing services, security policies tied to fixed source ranges, partner allowlists, or legacy infrastructure that nobody wants to touch twice. ARIN is explicit here: directly held resources can be used with any ISP, and there is no need to return them when service with an ISP ends.
The second difference is multihoming and routing policy. PI space is a natural fit when you want to announce the same prefix through multiple upstreams and keep your addressing stable while doing it. You are no longer depending on one provider’s aggregate and one provider’s routing design. That is a big reason PI shows up in conversations about resiliency, traffic engineering, and cleaner provider transitions. APNIC’s eligibility page for portable assignments and ARIN’s guidance on directly held space both reflect that PI-style resources are meant for organizations that need independent use and advertisement of their own space.
The third difference is the one network operators care about even when finance does not: aggregation. PI space is usually announced as its own prefix. RIPE notes that PI assignments are usually small and cannot be aggregated into larger blocks, which is exactly why they add more specifics to the global routing table. That is also why PI is never a free lunch. Your organization gets independence, but the Internet gets another independently visible route.
So when does PI actually make sense?
PI makes sense when the cost of renumbering, provider lock-in, or routing inflexibility is higher than the added operational burden. If you are multihomed, expect to change carriers, need stable externally visible prefixes, or want the cleanest separation between your network identity and your transit vendors, PI is usually the right tool. We see the outsized impact of each of these on the market right now, leading to the high demand.
In the world of multicloud and outsourced network operations, being multihomed for high availability, redundancy, and load-balancing is the new normal, making this more desirable than in years past. While there may or may not be a direct expectation by organizations to change carriers in the near term, there is absolutely more of a desire, especially in Europe, to be more independent from the vendors they work with – which starts with more flexibility in being able to bring their IPs with them if/when they go without worrying about onboarding new ones and renumbering.
Needing the separation between your network identity and transit vendors, coupled with
Why PI is not automatically the right answer
PI space gives you independence, but it also makes you more responsible for your own routing posture.
First, routability is not guaranteed just because you have a block.
RIPE explicitly warns that operators across the Internet may choose not to route PI assignments. ARIN says the same thing more generally in policy language: receiving number resources does not guarantee that any particular network operator will route them. In practice that means prefix length, filtering norms, IRR/RPKI hygiene, ASN strategy, and upstream coordination still matter. PI helps with address ownership. It does not exempt you from operational reality.
Second, the policy path is not identical everywhere.
This is where engineers get tripped up by half-remembered forum advice. In the RIPE region, the current public guidance says end users can request PI IPv6 and ASNs through a sponsoring LIR, and RIPE’s FAQ states that no new IPv4 PI space can be assigned there because RIPE has exhausted IPv4. In the ARIN region, ARIN still documents direct end-user assignments and explains how organizations can request resources directly from ARIN. APNIC’s current guidance includes portable IPv6 PI assignments for eligible members and distinguishes portable direct delegations from non-portable member-assigned customer space. So “get PI space” is not one universal workflow; it depends on your RIR and whether you are talking about IPv4 or IPv6.
PA space is often the better fit when you have a simpler topology, a single upstream, no real need for independent announcements, and no appetite for carrying extra routing and registry overhead. That is why PA remains the default for many networks. It scales better for the ecosystem and keeps life simpler for smaller deployments. RIPE’s guidance says exactly that: PA is the model that supports Internet scaling by minimizing routes.
In the end, it’s about your needs
The right question is not whether PI is better, but whether the benefits of portability, autonomy, and routing independence outweigh the extra burden. For organizations that need that control, PI space is often worth the effort.