The Internet is built from independently operated networks.
Internet service providers, cloud platforms, data centres, enterprises, universities, governments, telecom operators, and content networks may all operate their own infrastructure while relying on common technical identifiers to communicate.
Among the most important of those identifiers are:
- IPv4 addresses
- IPv6 addresses
- Autonomous System Numbers (ASNs)
The IANA Internet Number Resources system coordinates these resources globally, with Regional Internet Registries playing an important role in their regional administration.
For network operators, however, an important question sits beneath that structure:
What happens if the organization administering the registration layer for a network's number resources fails, becomes unavailable, or can no longer provide the continuity the operator requires?
If leaving the administrative relationship means losing practical continuity of the resource, the operator does not have a meaningful exit.
That is why IP address portability matters.
Portability should not be viewed only as a convenience for network operators. It is increasingly relevant to a bigger discussion about Internet resilience, infrastructure continuity, competition, and the appropriate limits of centralized coordination.
What Is IP Address Portability?
The term IP address portability can describe several related ideas.
At the service-provider level, it may refer to a network's ability to continue using the same addresses after changing connectivity or infrastructure providers.
At the Internet governance level, there is a deeper concept:
resource-level registry portability.
Under this concept, a network operator would be able to preserve the operational continuity of a particular Internet number resource while changing the administrative or registry-service structure surrounding it.
The resource stays the same.
The operator may stay the same.
The running network may stay the same.
What changes is the administrative relationship.
This is different from an ordinary IPv4 transfer, where control of the resource moves from one organization to another.
A simplified comparison is:
Transfer
Company A → IPv4 block → Company B
Portability
Same company → Same IPv4 block → Different administrative or registry service
This distinction is important because network operators may not want to sell, transfer, or abandon their resources.
They may simply need a credible continuity path if the institution supporting those resources becomes a risk.
Why Internet Number Resources Matter So Much
An IP address may initially appear to be little more than network capacity.
Over time, however, it can become deeply embedded in infrastructure.
IPv4 addresses may appear in:
- DNS records
- Customer allowlists
- Firewalls
- APIs
- VPN configurations
- Cloud environments
- Data-centre infrastructure
- Monitoring systems
- Security policies
- Partner configurations
Autonomous System Numbers can become equally important to organizations operating their own BGP routing.
This is why the LARUS Foundation's discussion of why IP addresses matter for stability and security extends beyond simple addressing. IP resources can become part of an organization's operational identity and continuity.
The Foundation's guide to network identity makes a similar point: a network's identity is shaped not only by IP addresses, but also by ASNs, routing information, registry records, security practices, and operational reputation.
Once those components become interconnected, replacing an IP block is no longer necessarily a simple technical change.
It can become a business-continuity event.
Portability Is Ultimately About Exit
A resilient infrastructure relationship should have an exit path.
Businesses routinely change:
- Cloud providers
- Transit providers
- Internet service providers
- Data centres
- DNS providers
- Security platforms
- Equipment vendors
Migration may be difficult, but the possibility of changing providers creates an important discipline.
The provider has to keep earning the relationship.
If a customer cannot leave without losing essential infrastructure, the relationship begins to look less like service and more like lock-in.
The same principle should be considered at the Internet number-resource layer.
Regional Internet Registries provide important services associated with IP addresses and ASNs.
The Internet Numbers Registry System itself exists to support important goals such as uniqueness, registration, and efficient distribution of Internet number resources, as described in RFC 7020.
Those coordination functions are important.
But the importance of the function does not automatically mean the organization currently performing it must be permanently irreplaceable.
A more resilient principle is:
The more critical the function, the stronger its failover and replacement mechanisms should be.
Coordination Without Exit Can Become Lock-In
Internet number-resource coordination solves a real technical problem.
Addresses must remain unique.
The same exclusive number resource should not accidentally be assigned to incompatible users.
Resource information should be accurate.
Changes should be traceable.
Routing-security information should remain coherent.
These are legitimate coordination requirements.
But none of them necessarily requires an operator to remain permanently dependent on one administrative institution.
The core coordination layer needs to protect:
- Uniqueness
- Accurate records
- Proof of control
- Auditability
- Security assertions
- Operational continuity
Portability asks whether those functions could remain intact even if the service provider administering them changes.
If the answer can eventually become yes, the Internet becomes more resilient.
If the answer must always remain no, the registry layer becomes a structural dependency.
Registry Failure Should Not Automatically Become Network Failure
Network operators already understand redundancy.
Production networks may use:
- Multiple upstream providers
- Redundant routers
- Backup power
- Multiple data centres
- Redundant DNS
- Disaster recovery
- Multiple cloud regions
The reason is straightforward.
Critical infrastructure should not have unnecessary single points of failure.
Why should the number-resource administration layer be different?
Consider what could happen to any critical service provider:
- Technical failure
- Insolvency
- Governance breakdown
- Litigation
- Cybersecurity incidents
- Operational paralysis
- Loss of key personnel
- Institutional restructuring
A resilient design should ask:
Can essential functions continue even if the organization performing them changes?
For Internet number resources, that means preserving the technical and administrative components that networks actually depend on.
What Must Continue?
The answer is not necessarily the institution itself.
What operators need is continuity of the function.
That includes:
Resource Records
The system should preserve accurate information identifying the number resource and the relevant recognized control relationships.
RDAP and WHOIS
Public registration information should remain available and accurate.
Reverse DNS
Operational reverse-DNS delegation should not disappear because an administrative provider changes.
RPKI
Route Origin Authorizations and associated validation infrastructure need a safe continuity path.
Routing Information
Operators need to retain the ability to establish and verify appropriate routing relationships.
Historical Records
Transfers, changes, disputes, and previous registry states should remain auditable.
Running Networks
Most importantly, customers and production infrastructure should not be unnecessarily disrupted.
This principle is closely related to the distinction made in the LARUS Foundation article What Happens When You Lose Control of Your IP Resources: the operational value of Internet resources depends heavily on maintaining continuity and control.
Why Renumbering Is Not Always a Good Exit Strategy
One argument against portability is simple:
If a network needs to leave a provider or administrative structure, why not obtain new addresses and renumber?
For small or temporary deployments, that may sometimes be reasonable.
For established networks, the situation can be very different.
Consider an IPv4 prefix used for years by a SaaS company.
Its addresses may have been added to hundreds of customer allowlists.
Partners may have documented them.
Security systems may trust them.
Firewalls may reference them.
DNS records may point to them.
VPN infrastructure may depend on them.
Monitoring platforms may associate years of operational history with them.
Replacing those addresses may require coordination across organizations the network operator does not control.
The cost of changing the number can therefore become much greater than the technical cost of configuring another IP address.
IP Addresses Can Become Network Identity
This leads to a broader concept.
An IP address can begin as capacity and gradually become identity.
For example, suppose a financial platform uses a stable range for API traffic.
Customers add the prefix to their security controls.
Partners use it to verify legitimate connections.
Internal compliance documentation references it.
Security monitoring establishes a historical baseline around it.
At that point, changing the address affects much more than routing.
The address has become part of how external systems recognize the network.
The LARUS Foundation's article on network identity explores how IP addresses, ASNs, routing records, registry information, and reputation combine to establish that technical identity.
Portability helps protect this identity from unnecessary dependence on the surrounding service-provider structure.
Portability Can Separate Identity From Delivery
A network's delivery infrastructure will change.
A business may switch:
- ISP
- Transit provider
- Data centre
- Cloud platform
- Firewall
- Managed service provider
Those are normal infrastructure decisions.
What does not necessarily need to change every time is the network's established public identity.
Portability helps separate:
Network identity
from
Network delivery.
The delivery path can change.
The network architecture can change.
The provider can change.
But the number resource can remain stable.
This can reduce switching costs and improve operator independence.
Portability Can Support Competition
Portability also has economic consequences.
When customers can leave a service provider without losing essential resources, providers have more incentive to compete on:
- Service quality
- Reliability
- Price
- Support
- Technical capability
- Trust
Without exit, a customer can become dependent on the provider simply because changing would be too disruptive.
Portability therefore does not only protect technical continuity.
It can also encourage healthier service relationships.
A registry or administrative service should ideally remain valuable because operators trust it—not because operators have no alternative.
Portability Is Not an Argument Against Registries
This point is important.
Portability does not mean that registries or coordinated number-resource systems are unnecessary.
The Internet needs coordination.
IANA maintains authoritative registries for IPv4, IPv6, and Autonomous System Numbers, while RIRs perform important resource-administration functions within the wider number-resource framework.
The relevant question is not:
“Should coordination disappear?”
It is:
“How do we make coordination resilient?”
The answer should include:
- Reliable records
- Security
- Auditability
- Transparency
- Failover
- Portability
A system is stronger when the function can survive changes in the organization performing it.
Portability and Internet Governance
This is therefore also an Internet governance issue.
Internet governance concerns the rules, institutions, standards, and decision-making processes that influence how the Internet operates and evolves.
The LARUS Foundation provides a broader introduction in What Is Internet Governance?.
Number-resource administration is particularly important because it sits close to live infrastructure.
A governance decision concerning a general Internet policy may be abstract for many organizations.
A decision affecting an IPv4 prefix can potentially touch routing, customers, infrastructure, and revenue directly.
That means governance around number resources should be designed with operational consequences in mind.
Portability and ICP-2
The discussion is especially relevant to the principles surrounding Regional Internet Registries.
The original ICP-2 criteria describe technical and organizational expectations for the establishment of Regional Internet Registries, including the capability to provide registration and allocation services.
LARUS Foundation has also published an introduction to what ICP-2 is and why it matters.
As the Internet evolves, continuity discussions should ask not only how a registry becomes recognized, but also:
What happens when an existing registry can no longer perform its role effectively?
A mature infrastructure framework requires both entry and failure architecture.
Recognition matters.
Succession matters too.
A Registry System Needs a Failure Model
Engineering systems normally define failure modes.
If a router stops working, traffic may move to another path.
If a server fails, a backup may take over.
If one data centre becomes unavailable, workloads may move.
Critical systems are designed around the assumption that components can fail.
Registry systems should adopt the same mindset.
A robust number-resource system should anticipate:
- Registry technical failure
- Institutional failure
- Legal paralysis
- Governance disputes
- Loss of operator trust
The objective should not be to pretend these events cannot happen.
It should be to ensure that the Internet remains operational when they do.
What Could Registry Portability Require?
A credible future portability framework would need careful technical design.
It cannot simply copy a database row from one organization to another.
Several components would have to remain consistent.
1. Proof of Control
The successor system must be able to establish who legitimately controls the resource.
A portability mechanism that creates duplicate claims would undermine the very purpose of coordination.
2. Registry Accuracy
Organization and contact information would need to move accurately.
3. Historical Integrity
Previous resource states and transfers should remain auditable.
4. Reverse DNS
Delegation should continue or transition safely.
5. RPKI
Certificates, repositories, and ROAs would need a defined continuity mechanism.
6. Routing Coordination
The transition should avoid unnecessary disruption to existing legitimate routing.
7. Conflict Handling
If two parties claim the same resource, portability must not become a tool for bypassing legitimate dispute resolution.
These requirements demonstrate that portability is technically challenging.
But challenging does not mean undesirable.
Difficult infrastructure problems are precisely the problems that deserve advance planning.
RPKI Continuity Deserves Special Attention
RPKI strengthens routing security by allowing networks to verify whether an ASN is authorized to originate a prefix.
That makes RPKI an important part of any portability discussion.
A poorly designed registry transition could create uncertainty around:
- ROAs
- Certificates
- Repositories
- Trust relationships
- Route validation
A credible portability architecture would therefore need security continuity built into the design.
The goal should be:
Change the administrative provider without unnecessarily changing the security truth of the running network.
Security infrastructure should remain associated with legitimate operational control rather than becoming dependent on the permanence of one institutional operator.
Portability Can Improve Dispute Isolation
Internet number-resource disputes will happen.
Organizations merge.
Companies fail.
Contracts are challenged.
Fraud is alleged.
Control changes.
Administrative information becomes outdated.
A resilient system should isolate these disputes rather than allowing them to create unnecessary damage to running networks.
For example, when a genuine dispute exists, a system could potentially:
- Preserve the last verified state
- Record a conflict
- Prevent conflicting changes
- Preserve evidence
- Maintain essential continuity
- Refer the matter to an independent resolution mechanism
The objective should be to resolve uncertainty without prematurely destroying the infrastructure that depends on the resource.
This principle aligns with the broader idea that registry records should reflect reality rather than attempt to manufacture it.
Portability Supports a More Decentralized Internet
The Internet is resilient partly because thousands of networks make decisions independently.
Network operators choose:
- Which providers to use
- Which routes to accept
- Which services to deploy
- Which technologies to adopt
A number-resource coordination layer should preserve enough common information for those independent networks to interoperate.
But the common layer does not need to determine every operational or commercial choice.
A thin coordination layer can focus on:
- Uniqueness
- Accurate records
- Proof of control
- Security assertions
- Auditability
- Transfer records
- Continuity
Other decisions can remain with operators, markets, contracts, technical communities, and lawful public authorities as appropriate.
Portability helps preserve that distinction by ensuring that the service provider managing the common coordination layer does not become an unavoidable permanent gatekeeper.
Running Networks Should Be the Priority
Internet technical culture has long emphasized implementation and operational reality.
The IETF's mission statement in RFC 3935 emphasizes technical competence and the tradition of “rough consensus and running code.”
That principle offers a useful perspective for number-resource governance.
When designing coordination systems, ask:
What does the running Internet actually require?
It requires unique addresses.
It requires interoperable identifiers.
It benefits from accurate registration information.
It benefits from routing-security assertions.
It requires networks to continue communicating.
It does not inherently require one particular administrative corporation to operate forever.
If the administrative operator can change while the technical invariants remain intact, the Internet should continue functioning.
That should be considered a feature, not a threat.
Protect the Function, Not Institutional Permanence
This leads to one of the most important principles in the portability discussion.
Registry continuity is necessary.
Institutional permanence is not necessarily necessary.
Suppose a registry experiences serious failure.
The priorities should be:
Protect the records.
Protect number uniqueness.
Protect RDAP and WHOIS continuity.
Protect reverse DNS.
Protect RPKI.
Protect routing continuity.
Protect operators and customers.
The institution itself may continue, restructure, or eventually be replaced.
The underlying technical functions should survive regardless.
This is how other critical infrastructure is designed.
The component serves the system.
The system should not become hostage to the component.
Portability Matters Especially for Smaller Network Operators
Large organizations can often absorb administrative problems more easily.
They may have:
- Dedicated legal teams
- Registry specialists
- Multiple address pools
- Multiple corporate entities
- Significant technical resources
Smaller operators may have fewer options.
A registry or number-resource problem can therefore represent a much larger proportion of their operational risk.
Portability can reduce that imbalance.
A smaller ISP or hosting provider should not need enormous institutional resources simply to preserve continuity of the identifiers its customers already depend on.
Clear exit and failover mechanisms benefit the entire ecosystem, but they may be especially important for organizations without the resources to manage prolonged institutional disputes.
Why Governments and Critical Infrastructure Operators Should Care
Number resources also support critical infrastructure.
Telecom operators, financial institutions, cloud services, government networks, healthcare providers, transportation systems, and other essential services can depend on stable Internet identifiers.
This does not mean governments should replace RIRs with centralized state control.
That could simply exchange one concentration of power for another.
Instead, resilience can come from:
- Redundancy
- Portability
- Transparent coordination
- Independent dispute mechanisms
- Clear technical standards
The goal is not to determine who should become the next permanent gatekeeper.
The goal is to reduce the need for any permanent gatekeeper.
What Network Operators Can Do Today
Full resource-level registry portability is not a universal operational mechanism today.
But network operators can still prepare for number-resource risk.
Start by auditing your dependencies.
Know Your Resources
Document:
- IPv4 blocks
- IPv6 blocks
- ASNs
Know Your Registry Relationships
Understand which registry administers each resource.
Protect Administrative Access
Maintain secure and documented access to resource-management accounts.
Keep Records Accurate
Update:
- Organization details
- Technical contacts
- Abuse contacts
- Administrative contacts
Document RPKI
Know:
- Which ROAs exist
- Which ASNs they authorize
- Who can modify them
Document Reverse DNS
Understand how reverse-DNS authority is managed.
Map External Dependencies
Identify:
- Customer allowlists
- Partner systems
- Firewalls
- DNS
- APIs
- VPNs
that depend on stable addresses.
Maintain Evidence
Organizations should understand what documentation supports their control and operational relationship with number resources.
Include Number Resources in Business Continuity
Do not limit disaster recovery to servers and data centres.
Ask what happens if the number-resource administration layer becomes unavailable.
Questions Every Network Operator Should Ask
A useful number-resource continuity review should ask:
- Which IP and ASN resources are business-critical?
- Who currently administers them?
- Who has account access?
- Are the registry records accurate?
- Are RPKI configurations documented?
- Who controls reverse DNS?
- Which customers depend on these specific addresses?
- What would renumbering cost?
- What happens if the current registry becomes unavailable?
- Is there a clear historical record proving control?
- How would a serious resource dispute be handled?
- What technical functions would need to survive a registry transition?
These questions help move number-resource planning from an administrative task to a resilience discipline.
Toward a More Resilient Number-Resource System
A future Internet number-resource framework can be evaluated against several principles.
Uniqueness
No portability mechanism should compromise the uniqueness of Internet number resources.
Accurate Records
Registry information should remain reliable and auditable.
Proof of Control
Changes should require credible evidence.
Portability
Operators should have a credible exit from failing administrative structures.
Failover
Critical registry functions should survive institutional failure.
Security Continuity
RPKI and related security infrastructure should remain coherent.
Independent Dispute Resolution
The recordkeeper should not need to become the final judge in every dispute involving the records it maintains.
Operational Continuity
Running networks and their users should remain the ultimate continuity priority.
Together, these principles point toward a coordination architecture that remains useful without becoming unnecessarily centralized.
Why This Matters to the LARUS Foundation
The LARUS Foundation works to make Internet governance, infrastructure, and policy easier to understand and more accessible.
IP address portability sits directly at the intersection of those areas.
It is technical because the Internet needs globally unique number resources.
It is operational because networks build production infrastructure around those resources.
It is economic because renumbering and infrastructure disruption can create significant cost.
And it is a governance issue because the structure of the coordination layer determines how much institutional dependency operators must accept.
The goal should not be coordination without institutions.
Nor should it be institutions without limits.
The goal should be reliable coordination with resilience, accountability, and credible exit paths.
Final Thoughts
IP address portability matters because Internet infrastructure should not be trapped inside an administrative relationship with no credible exit.
Registries perform valuable functions.
They maintain important records.
They help preserve uniqueness.
They support number-resource administration.
They contribute to the security and coordination systems on which networks rely.
But the importance of these functions strengthens the case for portability rather than weakening it.
Critical infrastructure needs failover.
Critical databases need backups.
Critical security systems need succession plans.
And critical number resources need continuity paths.
The carrier may change.
The cloud provider may change.
The data centre may change.
The registry operator may one day need to change.
The running network should not have to disappear with them.
That is the deeper purpose of portability.
It supports operator autonomy.
It reduces institutional lock-in.
It strengthens competition.
It protects network identity.
It improves infrastructure resilience.
And it keeps the Internet closer to its decentralized design.
The question for the next generation of Internet governance should therefore not simply be:
Which institution should control Internet number resources?
A more resilient question is:
How can we design number-resource coordination so that no individual institution ever needs to become irreplaceable?
That is the path from dependency to resilience.
And it is why IP address portability deserves a central place in the future discussion of Internet number-resource governance.
Frequently Asked Questions
What is IP address portability?
IP address portability is the ability to preserve the operational continuity of IP address resources when changing the service-provider or administrative structure around them. Registry-level portability would allow resource administration to move without necessarily forcing a live network to renumber.
Why does IP address portability matter?
Portability reduces dependency on a single provider or administrative institution, protects network continuity, supports competition, and gives operators a credible exit path if a service structure fails.
Is IP address portability the same as transferring IPv4?
No. A transfer generally changes the organization controlling the resource. Portability can keep the same resource and operator while changing the administrative or registry-service relationship.
Why is renumbering difficult?
Addresses may be embedded in DNS, firewalls, VPNs, customer allowlists, APIs, monitoring systems, security policies, and partner integrations. Replacing them can therefore become a significant migration project.
How does portability support network resilience?
It reduces the chance that the failure of one administrative provider will automatically become a failure of the network resources that provider administers.
Does portability mean RIRs are unnecessary?
No. Regional Internet Registries perform useful coordination functions. Portability is about making those functions resilient and replaceable rather than eliminating coordination.
Is cross-registry portability available today?
Resource transfers exist under various RIR policies, but universal resource-level registry portability—where the same holder can freely move registry administration without transferring or renumbering the resource—is not currently a universal feature of the RIR system.
How does RPKI relate to portability?
A credible portability mechanism needs to preserve routing-security continuity, including appropriate certificates, ROAs, repositories, and validation relationships.
How is portability different from provider-independent IP space?
Provider-independent addressing helps reduce dependence on a particular connectivity provider. Registry-level portability addresses a deeper question: whether the administration of the underlying number resource can itself have a credible replacement or failover path.
What should network operators do today?
Operators should audit their IPv4, IPv6, and ASN resources, maintain accurate registry records, secure account access, document RPKI and reverse-DNS arrangements, map customer dependencies, preserve evidence of control, and incorporate number-resource risk into business-continuity planning.