BYO IP vs ISP-Assigned Space: PA vs PI Addresses When You Switch Providers

You signed a new provider for better pricing or better reach, then asked the question that should have come first. Do your IP addresses move with you. The answer depends entirely on where those addresses came from, and the distinction is built into two abbreviations that shape every provider change you will ever plan. PA for Provider Aggregatable and PI for Provider Independent.

Bring Your Own IP, or BYO IP, is how you use PI space in practice. You bring a block that a Regional Internet Registry assigned to you and ask a provider to announce it on your behalf or you announce it yourself over BGP. Provider assigned space works the opposite way. Your ISP lends you a slice of its own aggregate, which means the space is convenient today and non portable tomorrow. Understanding which type you hold decides whether a provider switch is a routing change or a renumbering project.

At a Glance: PA vs PI Address Space

What Provider Assigned Space Really Means

PA space is simple by design. Your provider holds a large aggregate from its Regional Internet Registry, and your assignment is a more specific carved from that parent. The provider announces the aggregate to the global table, and your prefix is covered by it even if it is not announced separately. That aggregation is what keeps the global routing table manageable, because thousands of customer prefixes can be represented by a handful of provider blocks instead of thousands of separate announcements.

The tradeoff is ownership. PA space is allocated to the provider, not to you. Your contract gives you the right to use it while you are a customer, and that right ends when the service ends. The RIR record points to the provider’s organization, the reverse DNS is usually delegated through the provider, and the routing policy assumes the space stays topologically near the provider that aggregates it. This is why PA space is often free or included with the circuit, why it is fast to obtain, and why it is the default for most single homed sites.

For you this means PA space is operationally lightweight and strategically fragile. It costs little to acquire and nothing to maintain, and you can get it in hours instead of weeks. It also means you build a dependency that only surfaces when you try to leave, because every address you placed on firewalls, DNS, VPN peers, NAT pools, and allow lists is tied to a block you will have to return.

What Provider Independent Space Changes

PI space reverses the ownership model. The block is assigned directly to your organization by the RIR, either as a direct assignment or through a sponsoring LIR depending on the region and policy. You hold the registration, you control the reverse delegation, and you authorize who may announce the prefix through RPKI Route Origin Authorizations. The prefix is yours to keep as long as you maintain the registration and meet the RIR policy that justified it, regardless of which provider carries it.

Portability comes with responsibilities that PA space hides from you. You need an Autonomous System Number, which itself requires RIR registration and justification. You need to speak BGP or have a provider willing to originate the prefix for you under a Letter of Authorization. You need to publish ROAs so that RPKI validating networks accept your announcement and reject hijacks. And you need to respect global filtering norms. Most networks filter IPv4 prefixes longer than a /24 and IPv6 prefixes longer than a /48, so a block smaller than that may be unreachable even if you announce it correctly. A PI /25, for example, is portable on paper and filtered in practice.

PI space also does not aggregate under a provider. Every PI block is a separate entry in the global table, which is why RIRs apply stricter justification and why some providers charge for carrying it. You gain stability for your public endpoints and you pay for it in table size that the whole internet carries.

What Happens When You Switch Providers

This is where the two models diverge sharply. With PA space, a provider change is a renumbering event. You must return the old block, receive a new block from the incoming provider, and touch every place the old addresses appeared. Firewalls, NAT pools, VPN peer addresses, DNS A and AAAA records, PTR delegation, TLS certificate SANs that pin an IP, hard coded allow lists at partners, monitoring targets, and automation variables all need to move. If you use the PA block on customer facing services, you also need a migration window where both blocks are live, with DNS TTLs lowered in advance and old addresses kept reachable long enough for caches and partner configs to roll forward. Teams that have done this once know that the technical work is manageable and the coordination work is what slips, because you cannot force every external party to update on your schedule.

With PI space, a provider change is a routing event. You stop announcing through the old provider, start announcing through the new one, and the prefix itself does not change. Your DNS records, firewall rules that match the PI range, and partner allow lists stay valid because the addresses stay the same. That does not make the cutover free of risk. You still need to coordinate BGP withdrawals and announcements, validate that the new provider propagates the prefix with the correct AS path, confirm that RPKI validation passes for the new origin if the announcing ASN changes, and watch for filtering or dampening along the path. You also need to plan for propagation time. Global convergence is fast but not instant, and during the transition some networks will see the old path and some will see the new one.

A common middle case is BYO IP into a cloud or colocation provider while keeping PA space elsewhere. You may hold PI for your public service front ends and use PA for office connectivity. That hybrid is normal, and it is exactly why your inventory must distinguish which prefixes are portable and which are not. When the next contract is negotiated, the question is not how many addresses you have but how many of them you can actually keep.

The Real Cost of BYO IP

Bringing your own addresses is not just a form with your RIR. It is a small operational program that you commit to running.

First is the administrative layer. You need RIR membership or a sponsoring LIR, annual fees, and a demonstrated need that satisfies allocation policy, which has tightened for IPv4 in most regions as free pools have exhausted. Waiting lists, transfer markets, and stricter justification mean the cost of acquiring PI IPv4 space is materially higher than it was a decade ago. IPv6 PI is easier to justify but still requires registration and maintenance.

Second is the routing layer. Your organization needs an ASN, BGP capable equipment or a managed BGP service, and at least one provider willing to peer with you. If you are multihomed, you gain resilience and traffic engineering control, and you also take on prefix filtering, flap dampening, and path selection. If you are single homed with PI, some providers will announce your prefix for you over a static LOA and you avoid running BGP yourself, which reduces complexity but leaves you dependent on their announcement hygiene.

Third is the security layer. RPKI is now expected for portable space. You must create ROAs that bind your prefix to your origin ASN, keep them current when you rotate providers or ASNs, and monitor validation status so that an expired or misconfigured ROA does not make your legitimate announcement look invalid and get dropped by peers that enforce validation.

None of this is exotic for a network team that already runs its own backbone, but it is real overhead for a team whose core skill is running applications rather than running a network. Before you commit, price the full program, not just the address fee. ASN maintenance, IP transit with BGP support, potential surcharges for PI carriage, and the engineering time to monitor routing and RPKI.

How BYO IP Works with Clouds and Colocation

The mechanics are consistent across physical and cloud environments, only the paperwork changes name. In colocation or with a transit provider, you provide a Letter of Authorization that empowers the provider to announce your prefix, plus ROAs that authorize the origin. The provider configures the announcement, you verify propagation through looking glasses and RPKI validators, and your PI space becomes reachable through their network. When you leave, you revoke the LOA and the announcement moves to the next provider.

In public clouds, BYO IP follows a similar authorization flow with provider specific validation. AWS, Google Cloud, and Azure each let you bring a publicly routable prefix that you already hold at the RIR, verify control of the block through ROA or RIR records and DNS or WHOIS challenges, and then advertise it from their edge. The cloud edge then announces your prefix globally and you carve it into the provider’s assignment inside your account. That gives you provider independent addressing for cloud front ends without the global routing burden of your own BGP, and it is often the most practical entry point to BYO IP for teams that do not want to run a full peering presence.

Colocation adds a useful middle path. Many facilities offer IP transit from multiple carriers in the same building, so you can announce PI space there over BGP while keeping PA space at office sites that do not need portability. This lets you concentrate the BGP and RPKI work where it matters, on the prefixes that serve customers or partners, while the rest of the network stays on simpler PA allocations.

Choosing Between PA and PI

The right answer is rarely all PA or all PI. It is a split based on where renumbering pain would actually land.

PA is the right default when you have a single provider per site, no public services that depend on stable addressing, and a network where renumbering is bounded to a handful of devices and DNS changes. Branch offices, temporary sites, and workloads behind a NAT or API gateway that already abstracts the origin often fit here. You benefit from fast provisioning and you accept that a provider exit means a scheduled readdressing.

PI earns its keep when addresses are part of your external identity. Public APIs with IP allow listed partners, VPN concentrators whose peer address is configured on the far end, mail and voice infrastructure with reputation tied to IP, and any service where a DNS change propagates slowly through caches that you do not control are all signals for PI. Multihoming is the other clear signal. If you want two providers active at the same time for resilience or performance, you need space that both can announce, which by definition must be PI.

A practical rule is to make PI the exception rather than the rule, and to place that exception precisely where it removes the most friction. Hold PI for the smallest set of prefixes that must stay stable and announce them where that stability matters, such as your primary site or your cloud edge. Keep PA everywhere else so you are not paying RIR and routing overhead for address stability you do not need.

Before you commit to either path for a new site, ask three questions with your team. How long will this site live and how likely is a provider change inside that window. How many external parties would need to update if these addresses changed. And does your current team have the BGP and RPKI skills to maintain portable space without creating an availability risk that outweighs the portability benefit.

Keeping Your IP Inventory Honest

Whatever you choose, your address plan must make the choice visible. An inventory that lists prefixes without noting which are PA and which are PI hides the exact risk a provider negotiation needs to surface. For every aggregate, record the allocation type, the RIR object and the organization that holds it, the origin ASN and ROA state, the provider currently announcing it, and the sites and VLANs that consume from it. That is the context that turns a prefix table into a portability map.

This is also where IP address management earns its keep during a provider transition. When PA and PI aggregates live in the same hierarchy with ownership, ASN, and utilization attached, you can answer the critical questions without a spreadsheet hunt. Which subnets are affected if you return the ISP block, what is the utilization of the PI block you will expand into, and which firewall or DNS records still reference the old range. Tracking utilization at the aggregate level also prevents the quiet failure where you move a PI prefix to a new provider only to discover it is already over allocated inside your own plan.

If you are evaluating how to document this today, start by tagging every public aggregate in your current inventory as PA or PI, adding the ASN and LOA status for every PI block, and linking each prefix to the provider relationship that announces it. The next time a contract renewal or circuit quote arrives, the portability picture will already be on the page, and the conversation will be about strategy rather than discovery.

Provider assigned space and provider independent space are not two flavors of the same thing. They are two different contracts with the internet. One trades portability for simplicity and the other trades simplicity for portability. Choose with intent, record the choice, and the provider switch that once felt like a renumbering threat becomes a planned routing change.