Common Myths About Selling IP Addresses

Can you sell IPv4 addresses?

Organizations can transfer eligible IPv4 address space through the applicable Regional Internet Registry (RIR), and commercial parties commonly describe that transaction as selling IPv4 addresses. The registry process is not an ordinary handoff of a list of numbers. It verifies the source, recipient, resource status, policy path, authority, documents, and other regional requirements before changing the registration.

The exact legal, tax, accounting, and property characterization depends on the organizations, contracts, jurisdictions, and facts. An RIR policy explains what the registry will accept; it is not a general legal opinion. A seller should therefore keep the private agreement, payment controls, registry request, and operating handover aligned without assuming that one document proves every other layer.

Start with the exact CIDR, RIR, registered organization, current use, routing state, RPKI and IRR records, prior transfers, disputes or restrictions, and dependencies. Then verify the current policy at the authority responsible for the resource. The Number Resource Organization lists the five RIR service regions; each registry maintains its own transfer rules and procedures.

Five myths about selling IPv4 addresses

IPv4 sale myths, the evidence to check, and the seller action

Myth	What current evidence says	Seller action
1. “Selling IPv4 addresses is always illegal.”	RIRs publish transfer paths for eligible resources, but registry eligibility does not settle every contract, tax, sanctions, or local-law question.	Confirm the current RIR path and obtain case-specific professional advice where the transaction requires it.
2. “The old holder has no responsibilities after transfer.”	Historical BGP, reputation, geolocation, cached contact, and incident records can remain visible after a registry transfer. RPKI is different: ARIN removes transferred resources and their ROAs from the source certificate, while RIPE NCC says a transfer removes the underlying ROAs. In both cases, the recipient must create new ROAs under the applicable RIR procedure.	Plan the registry-triggered ROA removal or invalidation and the recipient’s new authorization alongside every route, IRR, DNS, contact, reputation, and incident task.
3. “IPv6 makes every IPv4 block worthless.”	IPv4 and IPv6 still coexist, but demand and value vary by block, region, eligibility, routing history, reputation, buyer need, timing, and alternatives.	Compare dated indications for the exact prefix and distinguish an asking price, offer, and completed transaction.
4. “A broker automatically handles everything.”	A broker, registry specialist, escrow provider, legal adviser, tax adviser, and routing operator have different roles. Scope varies by provider and engagement.	Put included tasks, exclusions, fees, evidence, response targets, conflicts, and post-transfer support in writing.
5. “A transfer automatically improves Internet allocation.”	A transfer can move eligible space to a new operator, but transaction cost, policy, consolidation, routing limits, buyer behavior, and later use determine the outcome.	Judge the exact transaction from verified registration and operating evidence rather than a universal market claim.

Is your IPv4 block ready to sell?

Readiness is more than “unused space.” A prefix can appear quiet in BGP while still supporting private interconnection, disaster recovery, allowlists, certificates, tunnels, customer contracts, DNS, security policy, or future capacity. Inventory the technical and business dependencies before advertising the resource or signing a term sheet.

IPv4 seller readiness evidence

Area	Evidence to prepare	Pause when
Registered authority	Current RDAP or Whois record, RIR account, organization identity, authorized contacts, registration agreement, and chain of control	The registered holder, signing entity, or authorized contact cannot be reconciled
Transfer eligibility	Current RIR policy, resource type, allocation or assignment date, prior transfer date, minimum size, status, and intra- or inter-RIR compatibility	A restriction, dispute, reserved status, lock, or incompatible registry path remains unresolved
Current use	IPAM export, BGP routes, firewall and NAT rules, DNS, certificates, allowlists, customer records, monitoring, and asset-owner sign-off	Any system or customer still depends on the prefix without an approved migration plan
Routing authority	Origin ASN, upstreams, LOAs, ROAs, IRR objects, prefix filters, route visibility, and planned withdrawal evidence	No named operator controls the withdrawal and post-transfer validation sequence
Reputation and abuse	Dated observations from sources relevant to the intended use, incident history, abuse tickets, rDNS, geofeed, and remediation record	A material issue is hidden, disputed, or described with an unsupported “clean” guarantee
Commercial authority	Entity documents, board or management approval where required, intermediary mandates, conflicts, price basis, fees, tax review, and payment controls	A party, account, fee, or last-minute payment instruction cannot be independently verified
Handover and retention	Milestones, acceptance evidence, rollback boundaries, data retention, contact changes, support period, and record archive	The contract and registry or network plan assign the same task to different parties—or to nobody

How to sell IPv4 addresses through a registry transfer

1. Confirm the resource and authority. Record the exact CIDR and RIR, compare the public registration with the organization and account, identify authorized contacts, and document how the signing entity controls the resource. Resolve stale organization names, missing agreements, disputed status, or account access before presenting the block.
2. Map current use and dependencies. Search IPAM, route tables, DNS, certificates, access lists, VPNs, customer records, security tools, monitoring, billing, and continuity plans. Measure actual traffic over an appropriate period. Obtain sign-off from each owner before classifying space as releasable.
3. Check the current registry path. Determine whether the transaction is an intra-RIR transfer, an inter-RIR transfer, or a merger or reorganization path. Verify source and recipient conditions, waiting periods, size limits, documents, agreements, fees, and reciprocal-policy requirements directly with the relevant RIR.
4. Compare a sale with retaining or leasing the block. Model dated sale proceeds against transaction cost, tax and professional work, migration, remaining capacity, and strategic control. Model a lease against term, operating workload, route authority, reputation and abuse exposure, renewal, counterparty risk, and return. Neither model guarantees a price or outcome.
5. Prepare a dated technical evidence pack. Include registration data, BGP history, origin ASN, ROAs, IRR objects, LOAs, reverse DNS, geofeed, reputation observations, abuse history, active dependencies, and the migration plan. State what each source proves, when it was checked, and what remains uncertain.
6. Evaluate offers and counterparties on the same basis. Normalize block size, currency, payment timing, intermediary and registry fees, taxes, conditions, escrow, diligence rights, expiration, and what happens after rejection or delay. Verify the legal entity, authorized contacts, bank or escrow instructions, source of funds requirements, and conflicts through independent channels.
7. Make closing conditional on verifiable milestones. The agreement should identify the prefix, parties, authority, representations, evidence, confidentiality, payment release, refunds, registry rejection, migration, liability allocation, records, and dispute path. Coordinate the private agreement with the RIR request; do not treat a commercial acceptance email as registry approval.
8. Execute and verify the handover. Complete the registry process, release funds only under the agreed controls, verify the RIR’s source-certificate and ROA changes, create and validate the recipient’s ROA, remove or replace old routes and remaining authorizations, update DNS and contacts, test external registration and routing state, monitor incidents, and preserve an immutable closing file. Use a named rollback or escalation path for any milestone that does not match.

For a current example of regional variation, review ARIN transfer guidance, RIPE NCC transfer guidance, APNIC transfer guidance, the LACNIC Policy Manual, and AFRINIC resource-transfer guidance. Do not carry a condition from one region into another without checking the current source and recipient policies.

Sell IPv4 addresses or lease them?

Sale and lease decision factors for an IPv4 holder

Decision factor	Approved sale or transfer	Authorized lease
Registry relationship	The approved transfer changes the registry-recognized holder or recipient according to the applicable path	The registered holder commonly remains in place while a contract grants time-bound use; exact registry treatment varies
Economic pattern	One-time proceeds subject to price, fees, diligence, approval, tax treatment, and closing conditions	Recurring payments subject to term, utilization, service cost, renewal, default, and return; revenue is not guaranteed
Control	The seller gives up the transferred registration position after completion, subject to the agreement and registry records	The holder retains a continuing relationship and usually more operating and counterparty exposure
Operations	Requires migration, route and object updates, registration acceptance, and a defined post-transfer support boundary	Requires continuing authority, routing, RPKI and IRR coordination, monitoring, abuse response, renewal, and return
Reputation	Historical observations may persist after the holder changes; acceptance criteria and transition evidence still matter	Activity during the term can affect the same prefix while the holder expects it back; controls and enforcement are central
Continuity	The seller must be able to operate without the transferred capacity and dependencies	The holder needs processes for source authority, lessee continuity, replacement, default, renewal, and withdrawal
Best starting question	Can the organization permanently release this exact prefix under the current policy and migration plan?	Can the organization safely operate the relationship and recover the prefix at the end of the term?

Use the IPv4 cost calculator to compare consistent block sizes and periods, then replace illustrative inputs with dated case-specific evidence. The managed IPv4 leasing service explains the operating path, while the IPv4 buyer guide shows the diligence the other side should expect.

Registry approval and operational handover

Registry approval changes the registration according to the accepted transfer and can remove or invalidate the source organization’s ROAs as the applicable RIR documents. It does not, by itself, announce the prefix in BGP, select the recipient’s origin ASN, create the recipient’s new Route Origin Authorization, update an Internet Routing Registry object, remove an old Letter of Authorization, change reverse DNS, refresh a geolocation database, close an abuse case, or make every network accept the route.

The handover plan should name the actor, exact object or system, earliest safe time, prerequisite, proof, observer, fallback, and retention period for each change. Sequence matters. Removing the seller’s route too early can interrupt service; leaving it active too long can create conflicting origins or ambiguous authority. Creating a buyer ROA without matching BGP and upstream filters can still leave the route unreachable.

• Registration: save the approval and verify RDAP or Whois against the expected organization, prefix, contacts, and referral.
• Routing: observe the intended origin and propagation from independent sources; check that old announcements and filters are removed as planned.
• RPKI and IRR: validate the active ROA and route objects against the exact prefix lengths and origin ASN; archive replaced objects.
• DNS and geolocation: assign owners for reverse DNS and geofeed changes, record provider-specific update latency, and avoid promising a universal completion date.
• Reputation and abuse: preserve dated pre-transfer evidence, update contacts, close or transfer open cases appropriately, and monitor the agreed post-transfer period.
• Security and continuity: remove credentials, allowlists, monitoring access, tunnels, and internal references only after their replacements are tested.

When should a seller pause the transaction?

Pause when a material fact cannot be reconciled. Pressure to move faster is not evidence that a problem is harmless.

• The organization offering the space does not match the registered holder and cannot show a documented chain of authority.
• The resource is disputed, locked, reserved, recently received, partly used, or subject to a policy condition that has not been cleared with the RIR.
• A buyer, broker, escrow account, beneficiary, fee, or payment instruction changes without independent verification.
• The agreement promises guaranteed approval, guaranteed routing, instant geolocation or reputation changes, or a universal legal result.
• The exact CIDR, price unit, fees, currency, taxes, registry path, payment milestones, rejection treatment, or refund conditions are missing.
• No owner can withdraw old routes and authorizations, validate the buyer state, support incident response, or execute the migration fallback.
• The seller would lose capacity or a hidden dependency that the remaining network cannot replace.

What should an IPv4 broker or provider do?

A provider can help discover counterparties, normalize offers, collect evidence, coordinate registry submissions, support diligence, sequence routing work, and keep a transaction record. Those are useful services only when their boundaries are explicit. Support scope varies by engagement.

Ask who represents whom, who pays each fee, how conflicts are disclosed, which RIR programs or relationships are claimed, who controls documents and payment instructions, and which people remain responsible after closing. Confirm any registry program directly with that registry. A listing, logo, or intermediary title does not transfer approval authority from the RIR or professional responsibility from the parties.

For i.lease, a qualified request starts with the exact CIDR, RIR, registered organization, current use, routing state, timing, and dependencies. Review the IPv4 seller request path to prepare those facts. An initial review identifies the next evidence and route; it is not a valuation, buyer commitment, legal opinion, or transfer guarantee.

Selling IPv4 addresses FAQ

Is it legal to sell IPv4 addresses?

RIRs publish policies for transferring eligible IPv4 resources, so a registry-approved transfer path can exist. That does not create one universal legal, tax, sanctions, accounting, or property answer. Verify the current RIR policy and obtain advice appropriate to the parties and jurisdictions.

Can I sell one IPv4 address?

Usually not through an RIR transfer. Registry transfers operate on CIDR blocks and regional policies can set minimum sizes, resource types, and routing or recipient conditions. Check the current policy before dividing a prefix or promising a quantity.

How much are my IPv4 addresses worth?

There is no universal live price. Compare dated indications for the exact block size, RIR region, eligibility, registration status, routing history, reputation observations, buyer requirements, payment terms, fees, taxes, and migration work. An asking price or broker estimate is not a completed-sale value.

How long does an IPv4 transfer take?

No single timetable applies. Account readiness, authority, source and recipient policy, inter-RIR coordination, documents, fees, agreements, questions, diligence, payment conditions, and migration can all affect timing. Use milestones and dependencies instead of a guaranteed date.

Does selling a block erase its old reputation?

No. Registration can change while historical BGP, abuse, blocklist, geolocation, DNS, and cached registration observations remain. Record dated evidence, disclose material issues, assign remediation and contact changes, and agree how post-transfer incidents will be handled.

Can I lease IPv4 space instead of selling it?

Possibly, if the holder has authority and the arrangement is compatible with the applicable policy, contracts, routing, and operations. A lease retains an ongoing relationship and needs clear term, use, LOA, RPKI and IRR, reputation, abuse, renewal, default, withdrawal, and return controls.

Do I need an IPv4 broker?

Not every RIR path requires a broker. A broker or coordinator can help find a counterparty and organize evidence, but the RIR applies policy and the parties retain their commercial, legal, tax, payment, and operating responsibilities. Compare scope, fees, conflicts, evidence, and support in writing.

What should I prepare before requesting a sale review?

Prepare the exact CIDR, RIR, registered organization and contacts, resource and prior-transfer status, current use, dependencies, BGP origin, ROAs, IRR objects, LOAs, reverse DNS, geofeed, reputation and abuse observations, desired timing, migration plan, authority, and any existing lease or service commitments.

Primary registry sources

• NRO: Regional Internet Registries and service regions
• ARIN: Transferring IP Addresses and ASNs
• ARIN: Number Resource Policy Manual
• ARIN: RPKI transfer FAQ
• RIPE NCC: Resource transfers and mergers
• RIPE NCC: Resource Transfer Policies
• RIPE NCC: RPKI system and transfers
• APNIC: Transfer resources
• LACNIC: Current policy manual
• AFRINIC: Resource transfers