IPv4 Lease Exit Checklist: Clean Handback Guide

By Savvas Bout, Founder of Prefixx. Last updated 14 October 2026.

Returning a leased IPv4 block without a structured IPv4 lease exit process can lead to many problems such as inheriting a list of blocked IP addresses. Leaving ROAs dangling in the RPKI repository or spending weeks searching for an LOA (Letter of Authorization) that was never revoked.

The operational impact of such mistakes can be severe: abuse reports from down stream providers for IP addresses that you are no longer responsible for. Geolocation databases routing traffic to your old IP addresses for long time to come, and the. IRR (Internet Routing Registry) database reflecting that your organization is the originating AS for IP addresses for which you are no longer responsible.

A clean exit from a lessor requires coordination with at least four different groups: the lessor itself, the relevant RIR, the upstream transit provider, and all systems that had referenced the now-deleted IP block. This can cause huge problems for you or your lessor's next tenant if one of these groups is not coordinated properly.

This checklist goes through all of the steps to coordinate a clean exit for buyers in order, including revoking routing, withdrawing RPKI ROAs and IRR route objects, cleaning up rDNS delegations, notifying upstreams. Additionally, Verifying that the IP block has been deleted before the lease actually closes. Go through these steps in order to make sure that nothing is left behind.

What selling IPv4 addresses actually involves

The process of exiting an IPv4 lease is far from simply cancelling a SaaS service. Unwinding announcements from routing tables, coordinating with multiple third parties and ending a formal written agreement with all parties whilst maintaining service will give rise to exposed mistakes and potential route leaks. Blacklisting and even breach of contract. These operational complexities require careful planning and execution to avoid service disruption.

Leasing IPv4 addresses: what you actually own (and what you don't)

Leasing typically conveys usage rights rather than ownership. The registered address for the lessor remains in place throughout the leasing term and post exit.

You can’t just announce no more space and walk away. The lessor must verify that the space has been de-announced, re-take the LOA, and update any RPKI ROAs or IRR route objects announced on your behalf.

In a clean exit three parties are involved:

• Lessee withdraws BGP announcements, moves traffic and checks de-peering with upstream.
• Lessor, Revokes the LOA, removes or amends existing ROAs and confirms block is cleared for re-let.
• Upstream provider, must delete any prefix filters or route-policy entries for the leased CIDR block.

A RIR may also be involved in these marketplace occasions, such as when the lease also includes a sponsored RIPE LIR membership, or if the block in question carries legacy resource annotations that need to be updated.

Why a structured checklist prevents costly mistakes

Most of the failure modes around this process revolve around sequencing. Taking an IP address block out of service before notifying the lessor of that block means that the old ROAs will be marked as RPKI-invalid for the new lessee. Paying first and disabling the account afterward means that you lose access to the portal to update rDNS and geofeed records for your existing resources. Understanding these timing dependencies helps organizations anticipate and mitigate the risks inherent in coordinating multiple technical and administrative changes.

A structured exit checklist delivers real value by compelling the correct sequence of activities such as website traffic migrated before BGP withdrawn, BGP withdrawn before LOA's revoked, LOA's revoked before final contract close. Each step in turn depends on the step before it. This sequencing discipline helps ensure that technical operations align with contractual obligations throughout the exit.

To illustrate this, a /22 that a lessee announces from two PoPs can only drain traffic from each PoP individually. After that, he confirms that there is no traffic announced any more and informs his lessor to withdraw the ROA. If he forgets to drain traffic from only one of the PoPs, there will be a short blackhole until the withdrawal window has passed.

How much notice do I need to give before ending an IPv4 addresses lease?

Lease agreements usually require 30-90 days written notice for cancellation. The specific period of notice usually depends on the block size of the IP addresses reserved and the terms that were negotiated at the time of signing of the lease agreement. Larger blocks (e.g. /20s and above) require longer periods of notice since it takes time to rehome that amount of IP address space. The notice period should be considered carefully in light of your migration timeline to avoid service disruption or unexpected costs.

You could even end up owing for the period of the overlap if you give notice too late. Giving notice too early without a proper migration plan in place can also leave a window where there are no routable addresses whilst your new block is brought on line. Overlapping lease periods can create unexpected financial obligations that affect your operational budget and revenue planning.

Prefixx consultants review the notice obligations of clients at the outset of an exit engagement in order to secure a fixed time frame before any changes to the routing of customer calls can take place. When choosing an exit strategy, clients benefit from understanding how notice periods interact with routing changes and downstream dependencies.

Why many businesses exit IPv4 leases and when to start planning

IPv4 lease exits fail very rarely (almost never) for technical reasons. Most lease failures occur because the operational tail is longer than expected and sufficient planning did not occur soon enough. This article explains why a lease expires and what has to happen for each of the different exit types to occur in an orderly fashion. A well-managed exit reflects the same level of professional discipline that should characterize the entire lifecycle of the lease relationship.

Common reasons a company exits before lease duration ends

There are a number of common patterns for exit triggers. A project may complete and the associated address space no longer be required. A company may migrate to purchasing its own space in order to have long term fixed costs. A cost restructure may determine that the lease costs are not justified. A change in provider may require a renumbering of IP addresses. A business shut down will require return of all allocated resources prior to dissolution of the company.

Each trigger has a different level of urgency and associated ‘to-do’ list. It’s possible to plan an exit from a project in good time (months) but a business closure has the potential to compress all of the activities into a few months. Additionally, It’s easy to make mistakes. Understanding these exit triggers helps lessees recognize planning opportunities that can reduce risk and cost.

When to start planning: notice periods and the operational tail

The written notice period required for most agreements is between 30 and 90 days and this is the execution period not the planning period. It is sensible to start planning to bring a lease to an end approximately half way through the duration of any agreement greater than six months. Planning ahead is essential to avoid rushing through critical coordination tasks under time pressure.

When companies talk about “returning a block” to the Internet community, they often underestimate the scope of work involved in withdrawing a single BGP announcement. In addition to removing Reverse DNS records, withdrawal of route objects from the Internet Routing Registry (IRR), co-ordination of revocation of Route Origin Authorizations (ROAs), update of geofeed entries, and notification of dependent services that are using the addresses in question, each of these tasks has its own dependencies.

Understanding these interconnected tasks reveals how exit planning creates opportunities to strengthen operational discipline across routing, registry hygiene, and vendor coordination.

The detailed breakdown of why skipping steps doesn’t make them go away. A stale ROA on a returned block can cause problems for the next holder of that block. An unreturned IRR route object can cause problems and create noise for a block’s reputation score. These are the support tickets that surface months after an exit.

What happens to my RPKI ROA when I return a leased block?

The only thing you lose when returning a leased block of addresses is the right to hold or publish a ROA for that leased space. The ROA must be withdrawn before or at the time of the return of the leased space. If the lessor-managed space was under the lessor’s resource certificate, then they will also revoke the ROA for that space.

This ROA was published by you under a hosted or delegated RPKI service, so you must delete it before the lease expires. If you fail to remove the ROA, the next person to hold the block will find that it’s routed as RPKI-invalid. This makes the block unusable and also prevents clean routing from their upstreams.

The full ROA lifecycle is managed by Prefixx during the lease term. Withdrawal of the storage is organized as part of the offboarding checklist (including IRR and geofeed clean up) and is managed as a white-glove service to ensure all necessary steps are taken on time. The greatest benefit of this approach is at exit where timing and automated processing both fail at high frequency. The platform provides comprehensive tracking and validation tools accessible through its online interface to ensure compliance at every stage.

My recommendation is to build an exit checklist at the same time you sign the lease to the unit and not at the time you decide to leave. The notice period specified in the lease agreement is the minimum contractual period and thus a floor and not a planning guide.

Start building your operational checklist 60 days or more prior to your desired return date, regardless of the agreement’s technical requirements. Proper diligence at the outset ensures that all stakeholders understand their responsibilities and that no critical task is overlooked during the eventual transition.

Step 1 -- audit your current IPv4 addresses usage

Before you can plan your clean exit from an IPv4 lease, you first need an accurate inventory of the IPv4 addresses currently in use. The gaps in your current inventory are often the cause of delays, disputes, and exposures after the lease term for a wind-down. Thorough research into your deployment architecture will reveal which subnets are actively routing traffic and which have already been decommissioned.

Preparation: pull your full block inventory

1. Record the leased block(s) in CIDR notation as described in the LOA. Note that the LOA should clearly describe the specific prefix, prefix length and corresponding subnet mask for the allocated block(s). Any errors with the documentation of the leased block(s) can cause major problems down the line.
2. Check the block against your RIR and provider information. Verify the prefix against the routing announcement that your provider has listed. A discrepancy between what you believe you have and what is actually announced can lead to complications with return and subsequently with the release to your future buyers in the marketplace.

Note: If your block spans multiple subnets, treat each one as a separate inventory unit. A single /22 broken into four /24s needs four individual usage records, not one combined entry.

Execution: map every address to a function

1. List all the IP addresses assigned to services and devices. Go through all the servers, load balancers, email servers, firewalls and even single standalone devices that have been assigned a static IP address. For each IP address, list the hostname, the purpose of the IP address and the team that is responsible for it.
2. Identify all downstream and sub-assigned addresses to the identified addresses. List all addresses that were passed on to clients or to other downstream networks and note their wind-down requirements. Notify the third party using the space and start migrating them before attempting to return the block of IP addresses to the pool.
3. Unused addresses must be accounted for in the block as well. An unused address is different from an unimportant address, an unused address is still part of the leased prefix and must be returned formally. All undocumented idle addresses in returned blocks must be clearly accounted for to ensure that all space in the returned block was released.

Verification: validate and flag risks before you proceed

1. Run a reputation scan on the whole prefix. Scan all addresses for a given prefix against global blacklists to uncover any past abuse that occurred during your time as a tenant. The Prefixx portal performs a reputation scan that checks 12+ DNSBLs and returns results per addressed checked.
2. Flag any active PTR records or geofeed entries for special treatment to ensure proper cleanup. The reverse DNS records and geolocation data for former leases won’t disappear on their own. While Prefixx’s white-glove service and support team handles the paperwork, it first needs to be identified.

Can I be held liable for blacklist entries after the lease ends?

Liability to the terms of a lease will be that of the lessee. But it is a real liability. IP of an address in a block can be associated with listings generated from that address whilst you are a tenant. Spam/abuse traffic, in particular, will follow the listing, and a subsequent holder of the IP will inherit the associated reputation problems.

The only clean way to do this is to audit and remediate prior to returning the block. Prefixx’s white-glove service includes reputation monitoring and blacklist scan ning as part of the service included with every lease. Check your rep now before the handback.

Step 2 -- review the IPv4 lease exit checklist and obligations

Before you do anything on the IPv4 address lease exit, read the whole agreement from cover to cover. Most disputes over exits are caused by a single clause that the lessee misunderstood during the onboarding process. Get out the contract and read it from cover to cover, it’s the best risk mitigation on this list of actions. Careful research into each clause will reveal obligations that may not have been apparent when the lease was first signed.

Clauses that control your timeline

First, find the notice period. It is usually fixed at 30, 60 or 90 days and has to be notified in writing prior to the return date. If this is not met then the auto-renewal clause will be triggered and you will be fixed into another long term period together with the relevant costs and charges.

These same provisions also define holdover terms and, often, create a new billing period or trigger a penalty rate by announcement of prefix one day past the agreed return date. You should verify the exact date of the return date’s cutoff and then reflect that in your internal project calendar.

Auto-renewal mechanics

The auto-renewal clause varies widely from a requirement to opt-out in writing to a requirement for the lessor to receive a signed termination notice on a specific date or earlier. Record the opt-out deadline in your ticketing system as soon as you identify it, do not rely on your memory or on earlier email threads.

Routing object and RPKI obligations

This agreement needs to state who will delete the corresponding RPKI ROA and the corresponding IRR route objects for the route lease to end. As a trivial detail it has serious implications in reality: a stale ROA in a registry might prevent a subsequent user's announcements from passing RPKI validation, and a stale IRR route object might trigger filtering by upstream providers in peering sessions, causing real disruption for businesses that demand reliable access to those networks.

For some lessors, ROA withdrawal is dealt with by them once the assignment of the address block has reverted back to them. Others have made the withdrawal of ROA the responsibility of the lessee and require a clean up to be proved before the lessee’s security deposit is released. Check your agreement as to which approach you are to take when modifying the routing infrastructure.

Reputation and abuse liability

Even when you’ve decided to move on, all abuse complaints registered during the lease term are your responsibility to resolve. Some agreements require the lessee to lift all blacklists which are active at the time of return whilst others are the responsibility of the lessor post-handback. This isn’t one size fits all.

Does the agreement reference specific reputation lists or set a standard for remediation? If not, a written amendment to fix liability is best. If left ambiguous, such can lead to pricing disputes down the road as lessors hold for reputation damage to Lessors’ deposits and settlement is otherwise delayed.

Get this in writing: Who pulls the ROA, Who clears the IRR objects, Who owns the open abuse tickets on the return date. Verbal agreements are worthless.

Leasing vs selling IPv4 addresses what is the difference

Returning a leased set of addresses is an operational handback. As a lessee, you never transferred ownership of a block of numbers, only right to use them under contract.

When that contract expires or is terminated, there is no money changing hands, no transfer of numbers at a RIR, and no change to the registrant of the corresponding WHOIS register. You just stop advertising the relevant IP addresses and confirm the corresponding routing objects have been cleaned up as per the contract.

Note that selling owned addresses is a formal transfer of property (as opposed to a lease), in which the registrant record is changed at the RIR. An inter-RIR/intra-RIR transfer is filed and paid for by the seller. Additionally, The seller receives payment for the domain(s).

The process of a formal transfer includes escrow, RIR approvaland post-transfer routing maintenance. Additionally, Thus while there are a number of technical steps involved in both lease and formal transfer of domain name space, there are significant legal and time differences between the two processes.

Step 3 -- migrate services off the leased address space

The operational core of any IPv4 address rental exit is migrating services off the leased address space. Getting the sequencing right here and starting this well before you send the termination notice for the lease is critical to avoid issues such as services going down. Mail reputation being lost or client integrations with services being broken.

Sequence your migration from longest lead time first

Management of DNS TTLs is the longest lead-time item in your list. Reduce your existing TTLs to 300s or less 48 hours or more prior to your cutover time. With newly updated DNS information having a reduced propagation time to complete, users will reach your new IP addresses within a shorter time frame than if they were to hit against stale DNS information cached on servers around the world.

Mail infrastructure is particularly important to get right. As email reputation is tied to the IP address from which mail is sent (not the domain name), it benefits you to first look up the current standing of your IP address on various DNSBLs, then build up a good reputation on the new IP address over time.

Update your SPF records, re-sign with DKIM on the new email address and make sure the PTR record on the new IP address matches the hostname from which you send email exactly.

Work through this sequence in order:

1. Decrease lower the TTL for all the DNS records that point to the leased IP block.
2. Provision replacement IPs (owned or new) and warm them up.
3. Update the SPF, DKIM and PTR records for the mail infrastructure.
4. Reconfigure firewalls and ACLs to accept traffic on the new IP addresses.
5. Update all references to hardcoded IP addresses in application configs, load balancer rules and monitoring tools.
6. Flip DNS records to the new IP addresses and let the old IP addresses time out.
7. Notify clients and partners of change to new IPs and effective date.

Update geolocation registrations before go-live

Note that geolocation data does not automatically update when an IP address changes hands. Submit an RFC 8805 geofeed update and correct your geolocation records with MaxMind, IP2Location and other providers before your site goes live. An incorrectly geolocated site can trigger additional fraud protection measures or deny region-specific content to true locals.

As part of our white-glove service for each Prefixx lease, the team prepares the necessary geofeed corrections as provider submissions that will get processed in a timely manner to ensure none of them get stale after the cutover.

How long does long term service migration off a leased block take?

A simple migration of DNS, firewall rules and application settings typically takes one to two weeks. However, mail reputation warming up can take longer to achieve. A high volume sender would typically need 4-6 weeks to build up equivalent sending permission on a new network.

Mark unused secondary IP addresses in the block you leased early in the procedure. By returning all addresses you are no longer sending traffic for you can avoid having them held in reserve and simplify your handback to your provider. The better pre-migration inventory you have, the better your post-migration handback will be.

Step 4 -- clean up routing, RPKI and IRR records

Making sure that routing information is properly cleaned up after a lease has expired is probably the most technically relevant thing to do during the exit from a lease. Old BGP adverstisements, old RPKI ROAs as well as old IRR route objects for a block that has been returned to a lessor to reuse or to sell to another operator damaged the reputation of that block and prevented the lessor from releasing or selling the IPs.

Withdrawing BGP announcements

First, you have to withdraw the leased block of IP addresses from all upstream BGP routes. This means you have to remove the IP addresses from all your router’s network statements or from the routes that are added via route maps. To check if the IP addresses have propagated worldwide yet, buyers of IP blocks can use a looking glass or RIPEstat to verify that the IP addresses are no longer visible from other locations on the Internet.

The propagation typically completes within minutes but some upstream paths take longer to converge. So just because your session says the route has been withdrawn don't assume it has completed yet for others. Check this step with at least two independent looking-glass nodes before marking it complete.

Removing RPKI ROAs and IRR route objects

Remove the RPKI ROAs for all RPKI authorized RPKIs for which your ASN is the originator for that RPKI authorized RPKI Block after BGP has converged and is now clean. The RPKI ROAs for RPKI authorized RPKI Resources are stored in the resource holder’s RPKI repository.

The RPKI repository for a given RPKI authorized RPKI may be published by the RIR themselves or by a third-party publication service on behalf of the RIR. A single ROA authored by your lessor for your ASN after return will cause announced RPKI authorized RPKI of the above type to display “RPKI Invalid” to any new operator attempting to announce the space. In the interim, the returned lessor space is useless.

Route objects used for IRR purposes should be deleted/withdrawn from all relevant registries (RIPE DB, ARIN IRR, RADB, ). Conflicting IRR entries in different registries can prevent the returned block from passing prefix-filter checks in automatic prefix-filtering implemented by most networks. This means the lessor will be precluded from re-leasing this space until all IRR entries have been updated accordingly.

A table outlining the three cleaning tasks, tasks performed, and tasks skipped is provided below.

Do I need to contact the RIR directly when exiting a lease?

Typically, direct contact with RIRs is not required for standard lease exits. Leases do not transfer registration of blocks of IP numbers and in the end the block(s) of IP numbers will remain registered to the lessor. What will change is the routing authorization for the number(s), and that is handled online with the RIRs via their RPKI and IRR web portals to update the global routing authorization and to add/delete objects in the RIRs' databases for IRR filtering purposes.

However, there are exceptions. First, where a sub-assignment has been recorded with the RIR (e.g. via an update to the assigning LIR’s contact details). The sponsoring LIR or the resource holder must update the records to remove the lessee’s details from the relevant records.

Second, a lessee operating under a sponsoring-LIR or Resource Holder agreement must have the sponsoring LIR or Resource Holder’s details removed from the agreement by the team handling the return (whether in-house or via a broker) prior to the contract closing.

For Prefixx leases our specialists will complete the LOA, RPKI ROA and IRR route objects for you during the lease period. On exit the removal of all records is managed by us and confirmed to be fully complete before documents confirming return are issued. Confirmation of full routing hygiene on a formal written document is critical to us and must be signed by both parties to confirm the full and satisfactory exit of all IP ranges.

Step 5 -- address reputation and abuse management before return

Returning a leased block of IP addresses with active blacklist entries is one of the most common issues causing post-exit disputes with Lessees. While tearing down routing is usually the Lessee’s responsibility, many forget that the IP addresses’ reputation is not removed together with the traffic that caused the listing but is tied to the addresses themselves. Go through these steps before returning the block of IP addresses.

Preparation: audit the block's reputation

1. Run a full dnsbl scan across all major lists.

   Check the block against Spamhaus ZEN, Barracuda, SpamCop, SORBS, CBL, and any additional lists your lessor requires. A single listed IP can trigger delivery failures for the next operator.

   Note: Do not rely on a single lookup tool. Different tools query different subsets of lists, so use a scanner that covers all 12 or more DNSBLs to get a complete picture.

2. Pull the scan results into a dated document.

   Screenshot or export every list result, including clean results. This timestamped record is your evidence of reputation state at return. Without it, any listing discovered after handoff can be disputed as your liability.

3. Cross-reference open abuse complaints.

   Check your abuse inbox and your upstream provider's abuse queue. Any unresolved complaint tied to the block should be considered an open item until it is formally closed or acknowledged.

Execution: file delisting requests and close complaints

1. Submit delisting requests for every active listing.

   Each DNSBL has its own removal workflow. Spamhaus, for example, requires you to identify the spam source before it will start a review. Follow each registry's procedure exactly.

   Note: We do not guarantee delisting. Removal timelines are controlled entirely by the list operators, not by you or your lessor. File early.

2. Resolve open abuse tickets with your lessor.

   Contact the lessor directly and provide a written summary of each complaint, what caused it, and what you did to remediate it. Leaving tickets open is one of the primary reasons security deposits are withheld.

3. Notify your upstream of the impending return.

   If your upstream provider holds abuse records tied to the block's ASN path, coordinate with them so those records are linked to your tenancy period, not the block's future use. This matters especially for blocks that were announced under ARIN or other RIR registrations with auditable routing history.

Verification: document and hand off cleanly

1. Compile a reputation handoff report.

   Include the scan date, every list checked, status of each delisting request, and the abuse management actions taken. Send this to your lessor before or on the return date.

2. Confirm receipt in writing.

   Get written acknowledgment from the lessor that the block was returned with the documented reputation state. This closes the loop and protects both parties.

What should I do if I still need IP space after the lease ends?

Renewal of an existing lease, sourcing of a new one or even buying of a resource outright all depend on the author’s current address requirements. If the usage of the previous block(s) has been relatively stable and they fulfilled the requirements well then renewal is the easiest option.

However, if the requirements have changed or even grown then a review of required block size and RIR region, plus a calculation whether owning the resource would be more cost effective than renting it, is in order.

We take care of both scenarios for you. We source vetted IP space in all five RIR regions, handle all the transfer paperwork for you and monitor the reputation of every leased block on 12 DNSBLs.

We can discuss your needs and work out what we can do for you next at Prefixx.net.

Step 6 -- confirm geolocation and reverse DNS are returned to lessor control

Simply withdrawing a network from service does not bring the lease to an end. BGP announces the change in the routing table to the lessor’s servers.

However, after the lease has ended, two datastructures persist for months to come: geolocation databases mapping IP addresses to the leases of organizations and countries, as well as reverse DNS zones for IP addresses mapping them back to hostname. They must be explicitly withdrawn from service by the lessee for them to carry correct identities for the lessee for any length of time.

Geofeed entries and database propagation

RFC 8805 defines a simple text geofeed format which operators can publish to a fixed URL. Every row of the feed contains a prefix and maps it to a country, region and city. The providers geolocation (MaxMind, IP2Location, DB-IP, ipinfo.io) then read these files on their respective crawl schedules and correct the respective database entries using these.

The organization of the lessee will typically appear as the geofeed publisher for that block of IP addresses for the duration of the lease. At lease end, the lessee must delete these rows or transfer publication of these IP addresses to the lessor.

If these IP addresses are left to time out in the geofeed publisher’s database, for example, they will continue to return the country and organization of the lessee in subsequent lookups for IP addresses which are being advertised from a new origin ASN.

Note that geolocation database updates are not instant and typically providers re-crawl geofeeds on a schedule of their choosing. Some commercial databases have manual correction queues for entries that need to be updated, and these can take weeks to be put into production as a single update.

record the geofeed URL that was used for the lease and verify that the corresponding block is no longer referenced by that URL. For lessors managing their own RFC 8805 file, add the prefix back under their own entry as soon as handoff is completed.

Provider correction submissions

Just because geofeed data is ingested by a provider does not mean that provider will update on schedule. Most major providers have a correction/feedback undertaking in place. MaxMind has a GeoIP correction form for network corrections. IP2Location and DB-IP have similar forms for corrections. ipinfo.io has an API-backed update path for corrections.

Once the geofeed has been updated by the lessor, the corrections should be sent to the individual providers. This ensures that the time between the handoff and the data being up-to-date is as short as possible. The lessor should also retain the confirmation receipts for the exit documentation as a re-deployed block that geolocates to a different country could trigger a number of issues with fraud filtering. Content blocking and ad targeting for the lessor’s subsequent lessee or customer.

Reverse DNS zone delegation

The reverse DNS for a /24 or larger block is typically a delegated in-addr.arpa zone that is delegated to the lessor’s name servers during the lease and then undeployed and returned to the lessor’s managed name servers at the end of the lease.

Update the NS-records for the delegation at the RIR or your upstream DNS operator. Check lessor controlled PTR lookups for all addresses in the block. Remove or change all PTR records for lessee hostnames in the affected block of IP before releasing it to the market.

Prefixx publishes a daily RFC 8805 geofeed at Prefixx.net. For each prefix record, the PTRs and full zone delegations are managed through the client portal. Lessees working with Prefixx therefore have a single source of truth, published daily, that can be verified to confirm that geolocation and reverse DNS are being fully delivered for them, protecting their revenue-generating operations and avoiding unnecessary expenses. No manual collation is required with other providers.

Step 7 -- obtain written confirmation and close the agreement

Relying on verbal confirmation by the lessor that they have accepted return of a block is not sufficient. Businesses are required to maintain a written closure file on demand to avoid being held liable for errors in billing, for breaches of arrangement, or for any failure that causes router conflicts long after the IPv4 address contract has ceased to have any effect.

What a proper closure document must contain

A complete closure report should set out all points in writing. This will protect the lessee in case of any disputes at a later date.

• Lessors’ written acknowledgement that lessors have received and accepted address block.
• Verify that all relevant routing announcements, RPKI ROA s, IRR route objects as well as the related rDNS delegations of the lessee have been withdrawn or reassigned.
• An explicit release of liability for the lease period and for any Abuse Complaints or Reputation Damage that has occurred during the Tenant’s occupation.
• Proof that final invoice has been paid in full (or zero-balance statement showing no outstanding amount(s)).

An email thread sent from the lessor’s official domain (e.g. from a domain such as example.com) which includes a reference to the lessor’s prefix and the lease accord number for that property is acceptable as written evidence. A signed PDF would be stronger though. A phone call or chat message is not acceptable under any terms and conditions.

Why ad-hoc arrangements create disputes

The return of a lessee is dealt with by structured lessors in a fixed manner. As a rule, a closure log is issued to both parties.

Informal arrangements made by IP holders or small resellers to lease IP often don’t have a formal operation to return a block of IP addresses. As lessee, you assume the lessor has returned the IP addresses, but the lessor may not have updated their routing or started using RPKI.

Months later an abuse complaint is raised or the IP addresses are hijacked via BGP, and there is no entry to verify who held the IP addresses and when they held them.

Our consultants at Prefixx manage the return steps for you end-to-end. This means we confirm the routing has been withdrawn. Check that the RPKI ROA for the block of IP has been removed and then issue a letter of close to both parties before we close the lease on your behalf in the portal.

Storing and referencing the closure document

Close the form and store it with the corresponding ASN Lease pact. Use prefix ASN and tag with RIR region and ASN Effective Return Date.

If your organization runs multiple leases across different RIR regions, a simple naming convention prevents confusion. For example: CLOSURE_192.0.2.0-24_RIPE_2025-09-01.pdf is unambiguous and searchable.

Keep certificate(s) for the length of your company’s standard contract retention period. Even after a lease has ended, disputes about routing and reputation can arise long after and your closure paperwork will be the proof of performance on time.

What to do with the address space you need next

Leasing out a block of IP addresses to exit a lease contract is all well and good but your infrastructure will still require an allocation of IP addresses. There are three basic methods to allocate addresses to your infrastructure: lease them for a while and then dispose of them, buy them outright to own them. Alternatively, Use a cloud or bare metal service and allocate addresses via their BYOIP.

The three paths compared

The table below maps out the alternatives along the most relevant criteria for a post-exit network operator.

Leasing IPv4 addresses versus buying: the core trade-off

The leasing model is suitable for any situation where the amount of traffic, the time-frame needed for a project or the business model not yet fully fixed are variables. Leasing a block of IP IPs means only paying a recurring fee, getting the block of IP prefixes provisioned very fast and returning it clean when no longer needed. There is no ‘capital expenditure’ and thus no RIR paperwork needed.

Buying makes sense when you can project stable, multi-year usage. At some point, cumulative lease payments exceed what you would have paid to acquire the block outright. That crossover is the core of the lease-vs-buy calculation, and it shifts with block size, registry region, and current market rates. The Prefixx /lease-vs-buy page walks through this decision in detail.

BYOIP: when you already hold the block

BYOIP allows you to bring your own address space to any cloud provider or bare metal platform that you own or control. Instead of leasing a new block of address space, you can bring an existing block to AWS, GCP, Azure, OCI, or Cloudflare, for example. The main value here is that of consolidation: one block, many targets, no separate lease.

Prefixx will prepare LOA, RPKI ROA and IRR route objects for you. BYOIP is natively included on all our bare metal servers with no additional charge per IP. We support all major BYOIP programs and will do all the necessary routing paperwork for you for cloud servers as well.

How businesses can decide

Start with your future usage horizon. Under 12 months or uncertain? Lease. Workload running beyond the payback period for a stable service? Buy. You already hold a block and are now planning a move to cloud or bare metal? Then BYOIP is the obvious route.

Prefixx handles all three options. Purchases carry zero buyer fees, and every lease includes white-glove service: geo-location correction, reverse DNS, reputation monitoring, and abuse complaint handling. Reach out through Prefixx.net to get a personalized offer on whichever path fits your next deployment.

Common mistakes that turn a clean exit into a dispute

Most IPv4 rental contract exits fail not because of the lessee's bad faith but because of a few small missteps, the kind that savvy selling parties know to avoid, that can easily lead to billing disputes, routing conflicts or even service outages. A clean return touch note and associated routing hygiene, DNS state and written confirmation are complex issues. Each of the errors listed below can be fixed by checking off the associated step in the checklist.

Preparation mistakes with IPv4 addresses

1. Missing the notice window and triggering auto-renewal. Most lease agreements require written notice 30 to 90 days before the term ends. Missing that window locks you into another full term. Note: calendar the deadline the day you sign, not the day you plan to leave.
2. Don’t assume the lessor will handle all the cleanup. Verbal agreements are usually worthless when a billing dispute comes up. Get a written confirmation of all the cleanup tasks that the lessor is responsible for completing before you return the block (ROA withdrawal, IRR deletion, rDNS teardown etc.). Anything not confirmed in writing in advance will be your responsibility by default.

Execution mistakes with IPv4 addresses

1. Stale RPKI ROAs or IRR objects for prefixes that have been withdrawn from BGP distribution can cause problems for the next holder (i.e. mark a prefix as RPKI-invalid) or even cause problems for upstream route filters (route-filter mismatches) as stale route objects are removed. These should be deleted in reverse order to which they were enabled (i.e. BGP announcement withdrawn first, then delete ROA and IRR objects one at a time, recording time stamp for each deletion).
2. Failing to bring down DNS TTLs prior to the return date. Even if you set your TTLs to 24 hours for example. Additionally, Bring back the block at midnight, all resolvers around the world will continue to send traffic to those IP subnets for the remainder of the 24 hour TTL period. Bring down all relevant TTLs to 300 seconds or lower at least 48 hours prior to the return date. This is one of the biggest miss-points of the exit sequence.
3. Return a block with all active blacklist entries and no explanation for the block (let lessor assume worst case. It Block is actively listed with Spamhaus or Barracuda and lessor will expect you to undertake remediation). Perform a full DNSBL scan in the week leading up to return and writeup findings (all clean or list of active blacklists with corresponding links). If any active blacklists are found, lessor must be notified in writing prior to return date with corresponding documentation. Prefixx’s portal performs a 12 DNSBL scan and times the results so you can provide strong evidence of a block being returned in a clean state.

Common IPv4 addresses verification mistakes

1. Don’t assume objects have been removed simply because you’ve requested deletion. Verification is required to confirm deletion has completed successfully. Check RIPE NCC or ARIN portal directly, check RPKI validator, and cross-check IRR with WHOIS lookup. Save copies of the screen shots and export files as proof of closure.
2. Not require written acknowledgment from lessor. Although a signed return receipt or email confirmation of acceptance of the block(s) to lessor’s account would be sufficient to close loop on billing dispute or routing issue, this should be processed same day as final verification is completed.

Leasing IPv4 addresses through Prefixx: what the exit looks like

Leasing IPv4 IP ranges instead of buying them is often a good idea for companies that need to operate with to have IPv4 address blocks with a routed address space but do not have the funds to buy them.

However, the exit from a lease is difficult for many lessees. Stale routing objects, old blacklists and RIR paperwork that one did not know about are typical problems that lessees encounter. Prefixx structures every lease so that a smooth handover is possible from the very beginning.

• Non-revocation guarantee. The full lease term is covered by a non-revocation clause in the lease deal. All your address space will remain routable for the entire signed term. They will not be unexpectedly recalled mid-contract.
• White-glove routing setup and teardown. We set up RPKI ROAs and IRR route objects for you as part of your routing setup. Additionally, We handle the teardown and handoff to the reputation and routing of the lessee when the lease ends. We manage all the necessary RIR documents for you.
• We offer an abuse handling / reputation monitoring service as part of our white-glove service. We can scan 12 DNSBLs, deal with any related complaints, change a block’s geo-location and provide reverse DNS for a block. We check the status of a block before we provision it and keep an eye on it for the duration of your understanding.
• We give every lessee visibility into the BGP monitoring (via RIPEstat) and the reputation, geolocation and rDNS management for the space(s) they rent. All accessible via the client portal at any time during the lease of the relevant subnet and IP address range.
• Prefixx is a registered broker across major registries (ARIN, RIPE NCC, APNIC) and our services are configured to adhere to the policies and transfer rules of each registry for leasing IPv4 IP blocks across regions.
• We provision IPv4 within 24 hours. Leasing IPv4 from a experienced team that handles LOA. ROA and IRR objects for you means your block of IP address ranges can be announced quickly without you having to chase round different organizations for different documents.

For businesses evaluating leasing options, the information of exit terms and ongoing support are just as important as the cost of the space itself. If you want to review what a lease commitment with Prefixx looks like in practice, explore our leasing page or reach out to our consultants to compare options for your specific block size and region.

Step 4 -- clean up routing objects and RPKI records

When services have been migrated from a leased IP address block, the routing authorization must be removed/updated before the lease can be returned to the lessor. This applies to IRR route objects as well as to RPKI Route Origin Authorizations.

If the required changes are not made to the routing authorization for a former leased address block, a new lessee as well as the lessor himself will not be able to re-authorize the address block in a clean way. In the worst case, such stale information will persist in the global routing table until it has expired or has been deleted manually.

Objects for route IRR route objects are typically stored in databases such as ARIN, RIPE, and RADB. You must delete the object that references your ASN as origin. If the lessor created objects on your behalf when you moved into the lease, verify whether they are responsible for deleting the objects or if you are, in writing.

The responsibility for deleting objects can vary greatly from lease to lease. Often the lessor created the objects so the tenant has to deal with their removal unless otherwise specified in the contract with the lessor.

Notification of removal of ROAs is typically performed directly via the RIR portal by the resource holder (ie. the party who holds the certificate for the announced space). The block in question will be registered by the lessor for the duration of the lease, therefore it is the lessor’s responsibility to remove ROAs.

Your only responsibility is to advise the lessor in writing that you are no longer announcing the block of IP (i.e. specific prefix(s)) from your AS. This enables the lessor to remove the ROA(s) in question to prevent the space going into RPKI-invalid states for other announcements.

To facilitate your de-enabling of the IPv4 addresses, a practical check list would include verification of BGP withdrawal on all relevant peer sessions, a written confirmation from the lessor that the relevant ROA has been revoked, verification that the relevent ASN has been deleted from all IRR route and route6 objects, and a print screen shot of the relevant page of the LES portal with a timestamped stamp on said print screen shot to prove clean de-enabling.

Some lessor agreements stipulate a time frame of five to ten business days in which all records must be deleted from the lessor's portal. Adhering strictly to this time frame benefits all parties in the long term by helping to avoid holdover fees or potential disputes in the event of any routing incidents which may occur after the intended date of de-enabling.

IPv4 lease exit checklist: the complete reference

A simple IP address lease exit checklist to ensure that a complex methodology does not turn into excessive cost. Audit active usage of IP network prefixes on all subnets in service, review your lease covenant for return of IP IPs including notice period and other conditions and possible penalties. Migrate all services and applications off the IPv4 IP prefixes leased to you before the agreed handback date.

Clean up routing by withdrawing your BGP announcements, revoking your RPKI ROAs and deleting your IRR route objects for the respective block. abuse remediation: resolve all open complaints and remove the block from all spam listings. Return geolocation and rDNS control to lessor by removing geofeed entries for the respective subnet and deleting corresponding PTR records. Verify with lessor in writing that the compact has been terminated and that all assigned IP prefixes have been released.

Whether lessee or lessor, each step serves a purpose to protect both parties. Failure to properly clear routing information can result in old Route Objects Advertisements (ROAs) to cause problems for subsequent users of the IP blocks in question.

Similarly, failing to obtain written confirmation that all obligations under the lease have been met can mean that there is no write-up to verify that the lease has ended and that lessor and lessee are both released from their respective obligations under the lease.

Leasing IPv4 subnets involves real responsibilities on the way out of using the IP ranges as well as on the way in. Ensure that all items are completed in sequence and that none are left open. All of this can be done with discipline and the work can remain with the company in the next network in which it exists.

Leaving allocated IPv4 space without disruption requires three things: a complete audit of what is running off the allocated space. A clear understanding of contractual notice periods and a successful migration of workloads off the space before it is released and the IP prefixes returned.

If the exit is prompting a broader review of your IP strategy, whether that means sourcing a replacement block, leasing under better terms, or buying space outright, that conversation is worth having before you're under deadline pressure. Prefixx handles the full picture: vetted blocks across ARIN, RIPE NCC and APNIC, escrow-secured transactions, and white-glove routing paperwork so your team isn't managing LOAs, RPKI ROAs and IRR objects from scratch. Contact Prefixx to talk through your next move.