Selling unused IPv4 address space may look straightforward.
An organization identifies a block it no longer needs, finds a buyer, agrees on commercial terms, completes the required transfer process, and receives payment.
But IPv4 is not simply a collection of numbers.
An active IPv4 block can be connected to BGP routing, RPKI authorization, reverse DNS, geolocation databases, security systems, allowlists, customers, applications, and years of reputation history.
That means organizations preparing to sell IP addresses should understand what needs to change before, during, and after the transfer.
Failure to identify these dependencies can create problems for both the seller and the new network using the addresses.
Why Selling IPv4 Is More Than a Commercial Transaction
Organizations often consider selling IPv4 when they have more address space than they currently use.
Common reasons include:
- Data center consolidation
- Cloud migration
- Business restructuring
- Mergers and acquisitions
- Network downsizing
- IPv6 deployment
- Closure of legacy services
- Reduced hosting requirements
If an IPv4 block appears unused, selling it may seem like a logical way to release value.
However, an address block can appear unused from a server-capacity perspective while still being connected to network infrastructure.
Before deciding to sell IP address space, organizations need to identify those dependencies.
1. Check Whether the IPv4 Block Is Still Being Routed
The first question should be simple:
Is the prefix still being announced to the internet?
An IPv4 block may still appear in the global BGP routing table even if few or no production systems are actively using it.
Before a transfer, network operators should identify:
- Current origin ASN
- Upstream providers
- Existing BGP announcements
- Route objects
- Routing policies
- More-specific advertisements
Continuing to announce a transferred block from the seller’s ASN after the new holder begins using it can create routing confusion.
The transition therefore needs coordination.
2. Review RPKI Before the Transfer
RPKI adds another layer to IPv4 routing.
A Route Origin Authorization, or ROA, identifies which Autonomous System is authorized to originate a particular IP prefix.
Imagine an organization sells an IPv4 block but leaves an old ROA authorizing its own ASN.
The new network may then announce that prefix from a different ASN.
Depending on the existing authorization, that route could become RPKI invalid.
Before completing an IPv4 transaction, identify:
- Existing ROAs
- Authorized origin ASN
- Maximum prefix length
- Who controls the RPKI configuration
- When old authorization should be removed
- When new authorization should become active
Routing security should be part of the transfer plan rather than an afterthought.
3. Identify Reverse DNS Dependencies
Reverse DNS is another area sellers can overlook.
PTR records map IP addresses back to hostnames.
An organization may have configured rDNS years ago for:
- Mail servers
- Hosting systems
- Network appliances
- Customer services
- Monitoring infrastructure
Those records may remain even after the associated systems have been retired.
Before you sell IP addresses, review the reverse DNS zones associated with the block.
Old PTR records pointing to the seller’s domains can create confusion after the address space moves to another network.
The new user may also need control over rDNS for their own infrastructure.
A clean transition should therefore establish when existing records are removed and how reverse DNS control will move.
4. Check IP Reputation
Every IPv4 address develops history.
That history does not necessarily disappear when the address changes users.
Security platforms, spam filters, threat-intelligence systems, and other databases may have records associated with the block.
Before selling, organizations should review whether the addresses have:
- Blocklist listings
- Spam history
- Malware associations
- Abuse reports
- Botnet activity
- Suspicious traffic history
A buyer will often perform similar due diligence.
Understanding the reputation of the resource before negotiations can therefore reduce surprises later.
5. Review Old Allowlist Relationships
Some IPv4 addresses become trusted because third parties have explicitly allowed them.
For example, customers or business partners may add a company’s public addresses to:
- Firewall allowlists
- API access policies
- VPN rules
- Security gateways
- Database controls
- SaaS administration portals
If the organization later sells those addresses without updating its partners, the new user could inherit network addresses that remain trusted by external systems.
That creates a security concern.
Before transferring an IPv4 block, identify whether the addresses appear in third-party allowlists and request their removal where necessary.
6. Check Internal Firewalls and Access Controls
The same issue can exist internally.
Old IPv4 blocks may still appear in:
- Firewall rules
- ACLs
- SIEM systems
- VPN configurations
- Cloud security groups
- Monitoring platforms
- Routing filters
Once ownership or operational control changes, those addresses should no longer automatically be treated as part of the seller’s trusted infrastructure.
Updating access controls should therefore be part of the decommissioning process.
7. Review DNS Records
A network may stop actively using an IPv4 address but still have DNS records pointing toward it.
Before selling an IPv4 block, search for:
- A records
- MX-related dependencies
- NS records
- Application endpoints
- API hostnames
- Legacy domains
- Monitoring hostnames
Old DNS records can continue sending legitimate users or automated systems toward addresses now operated by another organization.
That is unnecessary risk for both sides.
8. Check IP Geolocation
IPv4 geolocation often reflects historical deployment.
Suppose a block previously operated in Germany but is sold to a network that will announce it from Singapore.
Geolocation databases may continue reporting the old location for some time.
That matters because IP location can influence:
- Content localization
- Advertising
- Fraud controls
- Streaming restrictions
- Security systems
- Customer experience
The seller should document the previous deployment, while the new operator should be prepared to update relevant geolocation providers.
9. Review WHOIS and RDAP Information
Registry information is another essential part of the transition.
Before marketing IPv4 resources, ensure that the records associated with the block are accurate.
Outdated organization names, contacts, or resource information can slow a transaction.
After an approved transfer, the relevant registry records should reflect the new resource relationship according to the applicable RIR process.
Accurate registration data supports clearer network accountability.
10. Look for Hidden Customer Dependencies
The most difficult dependencies are sometimes outside the network team’s immediate visibility.
Customers may use an IPv4 address for:
- API integrations
- Allowlisting
- Remote administration
- DNS configuration
- VPN access
- Security policies
- Custom applications
An address that appears unused internally may still be important externally.
Before selling a block, organizations should communicate with relevant teams such as:
- Network operations
- Security
- Customer support
- DevOps
- Product engineering
- IT
- Compliance
The objective is to make sure the addresses are genuinely no longer required.
When Is an IPv4 Address Truly Unused?
A block is not necessarily unused simply because no server currently responds on it.
A better definition is:
An IPv4 resource is operationally unused when the organization no longer depends on it for routing, applications, security, customer access, DNS, reputation, or future network capacity.
This distinction is important.
Selling IPv4 too early can force a company to obtain replacement address space later.
What Happens After You Sell IPv4 Addresses?
Once an eligible transfer is completed, the receiving organization can begin integrating the resources into its own network.
That may involve:
- Updating registry information
- Creating new routing authorization
- Updating RPKI
- Announcing the prefix through BGP
- Configuring reverse DNS
- Updating geolocation
- Establishing abuse contacts
- Monitoring address reputation
For the seller, the process should include removing old dependencies and ensuring that internal systems no longer consider the block part of the company’s network.
Sell IPv4 or Keep It for Future Growth?
Before selling, organizations should consider future requirements.
IPv4 remains limited.
If network demand later increases, the seller may need to obtain address space again through purchasing or leasing.
Questions to consider include:
- Are we certain the block will not be needed again?
- Are we expanding into new regions?
- Could future acquisitions increase IPv4 demand?
- Will customers continue requiring IPv4?
- How quickly is IPv6 reducing our actual requirements?
- Would retaining some reserve capacity be useful?
A decision based only on current utilization can overlook future network strategy.
Sell IPv4 or Lease It Instead?
Organizations with surplus addresses have another option: leasing.
Selling and leasing address different objectives.
Selling may make sense when:
- IPv4 is permanently surplus
- Immediate capital is preferred
- Future use is unlikely
- The organization wants to exit responsibility for the resource
Leasing may make sense when:
- The addresses are temporarily underused
- Future IPv4 demand remains possible
- The organization wants to retain the resource
- Long-term flexibility is important
IPv4 leasing allows address resources to remain productive without necessarily giving up long-term control.
This distinction becomes particularly important when an organization is uncertain about its future infrastructure requirements.
Why IPv4 Continuity Matters
Public IP addresses often become deeply embedded in infrastructure.
Networks can change servers more easily than they can sometimes change IP addresses.
An address may be connected to:
- Customer configurations
- DNS
- Firewall rules
- Reputation
- Routing
- Access controls
- Third-party systems
This is why IPv4 should be treated as part of network identity and continuity rather than simply as unused inventory.
Before permanently transferring an address resource, organizations should understand what operational relationships have formed around it.
How to Prepare an IPv4 Block for Sale
A structured preparation process can reduce risk.
Step 1: Inventory the Address Space
Identify:
- Prefixes
- Current utilization
- Route announcements
- Associated services
- Reserved capacity
Step 2: Map Dependencies
Search for relationships involving:
- DNS
- Firewalls
- APIs
- Customer allowlists
- VPNs
- Monitoring
- Applications
Step 3: Review Routing
Check:
- BGP announcements
- Origin ASN
- Route objects
- Upstream configuration
Step 4: Review RPKI
Document existing ROAs and plan how they will be changed.
Step 5: Review Reputation
Check blocklists, abuse history, and other known reputation indicators.
Step 6: Check Reverse DNS
Identify existing PTR records and determine when they should be removed.
Step 7: Confirm Registry Data
Make sure organizational and resource information is accurate.
Step 8: Confirm Transfer Eligibility
Review the requirements of the applicable Regional Internet Registry.
Step 9: Remove Old Trust Relationships
Update firewalls, allowlists, customer configurations, and internal security systems.
Step 10: Complete the Operational Handover
Coordinate registry, routing, RPKI, rDNS, and other changes with the new operator.
Common Mistakes When Selling IP Addresses
Treating the Block as Completely Independent
IPv4 resources are often tied to more systems than expected.
Perform dependency checks first.
Removing Routes Too Early
Stopping an announcement before migration is complete can interrupt services.
Leaving Routes Active Too Long
Continuing to announce a transferred prefix can interfere with the new operator.
Forgetting RPKI
Old ROAs can make the buyer’s new route invalid.
Ignoring Old PTR Records
Reverse DNS should reflect the new operating environment.
Leaving IPs in Allowlists
Previously trusted addresses should be removed from systems that no longer have a reason to trust them.
Selling All Spare Capacity
Organizations should retain enough IPv4 for expected future requirements.
Why Organizations Should Think Beyond the Sale Price
The financial value of an IPv4 sale is easy to measure.
The operational value of retaining an address block can be harder to quantify.
That value may include:
- Future network flexibility
- Stable customer configurations
- Routing continuity
- Reduced migration work
- Reserve capacity
- Control over network identity
Organizations should consider both before deciding to permanently transfer IPv4 resources.
Where IPv4 Leasing Fits
For organizations that are not ready to permanently sell their address resources, IPv4 leasing provides an alternative model.
The organization can potentially retain long-term control while allowing another network to put unused capacity into productive use.
LARUS focuses on IPv4 as operational infrastructure, where issues such as routing, RPKI, reverse DNS, reputation, geolocation, abuse handling, and continuity all affect real-world usability.
Organizations evaluating whether to sell or retain IPv4 can explore IPv4 leasing with LARUS as part of that broader resource strategy.
The decision should ultimately reflect how the organization expects its network to evolve.
Final Thoughts
Organizations preparing to sell IP addresses should look beyond the commercial transaction.
IPv4 resources can carry years of technical and operational relationships.
BGP routes may still exist.
RPKI may authorize an old ASN.
PTR records may point to legacy hostnames.
Customers may still have the addresses in allowlists.
Geolocation databases may reflect a previous deployment.
Reputation systems may retain historical information.
A responsible IPv4 transfer therefore begins with understanding those dependencies.
For organizations searching for how to sell IP address space, the first step should not simply be finding the highest offer.
It should be determining whether the addresses are genuinely surplus, whether the operational dependencies have been removed, and whether permanent transfer is the right long-term decision.
When future IPv4 requirements remain uncertain, retaining the resources and exploring IPv4 leasing can provide another option without immediately giving up a limited network resource.
Frequently Asked Questions
What should I check before I sell IP addresses?
Review transfer eligibility, current BGP announcements, RPKI/ROA configuration, reverse DNS, reputation, WHOIS/RDAP records, geolocation, DNS records, firewalls, customer allowlists, and future IPv4 requirements.
What happens to BGP when IPv4 addresses are sold?
The seller’s existing route announcements generally need to be withdrawn as the new operator establishes the appropriate routing for the transferred prefix. The transition should be coordinated to avoid routing conflicts or outages.
What happens to RPKI after an IPv4 transfer?
Old Route Origin Authorizations may need to be removed or changed so that the new operator’s ASN can announce the transferred prefix with the correct RPKI validity.
What happens to PTR records when IPv4 addresses are sold?
Legacy reverse DNS entries should be reviewed and removed or replaced. The new operator may need control over PTR records for its own services.
Can IP reputation transfer with an IPv4 address?
Historical reputation can continue to influence how security or filtering systems treat an address after it changes users. Buyers commonly review reputation as part of IPv4 due diligence.
Should I sell unused IPv4 addresses or lease them?
Selling may suit resources that are permanently surplus. Leasing may be more appropriate when the organization wants to retain the address space or expects that it could need the resource again.
Can I sell an IPv4 block that is still being announced?
A routed prefix may still be transferable if it meets the applicable registry requirements, but its existing network dependencies should be carefully removed or transitioned as part of the process.