Before an IPv4 transfer, the parties should review the RIPE Database objects connected to the resource. Old contacts, inaccessible maintainers, and obsolete routing records can create conflicting information or delay changes required during the handover.
RIPE Database cleanup before an IPv4 transfer is the process of reviewing registry objects associated with an address range and correcting data that no longer reflects its current holder or use. Its purpose is to align inetnum, organization, contact, maintainer, and routing records with the real resource before ownership changes.
The review should begin with the address resource and then follow its references. Checking objects separately can miss dependencies between the inetnum object, contacts, maintainers, and routing records.
A practical review should cover:
The goal is to determine which data remains valid, which fields need correction, and which objects no longer serve an operational purpose.
The inetnum object should describe the same IPv4 range identified in the transaction. Address boundaries, organization references, and responsible contacts should be consistent with the current administrative structure and transfer file.
Status, netname, org, admin-c, tech-c, and maintenance-related fields should be reviewed together. Some attributes depend on RIPE NCC procedures rather than direct holder edits, so discrepancies should be identified before the transfer begins.
Contact records can remain long after employees or contractors leave. An outdated admin-c or tech-c can direct notifications to inactive people, while an old maintainer can prevent changes to objects required during the transaction.
The organization should confirm that responsible contacts are reachable and that it controls the authentication required by the relevant mntner. This should happen early because one maintainer may protect several related objects.
An old object should not be deleted only because it appears outdated. The team must first determine whether it still supports authorization, routing, reverse DNS, delegation, or another active function.
Potential cleanup candidates include:
Dependencies should be checked before deletion so cleanup does not create a new inconsistency immediately before the transfer.
The goal is not to redesign BGP but to determine whether existing route objects still describe the current announcement and which records must change when the new holder activates its routing plan.
A route object for the old origin ASN may still be required until cutover. Removing it too early can disrupt routing, while leaving it indefinitely after the transition can create stale authorization data.
More-specific route objects should also be identified, along with who can modify them. Changes that are not required for transfer readiness should remain part of the separate routing cutover plan.
Registry data and transfer documents should describe the same resource and holder. Differences in company name, address boundaries, organization reference, contacts, or authority of the requesting party should be identified before submission.
This matters when a company plans to sell IPv4 addresses because registry information helps establish control over the resource. A buyer preparing to buy IPv4 addresses should also understand which records are current and which changes belong after the transfer.
Cleanup should not become bulk deletion of every old record. Some contacts, route objects, and maintainers may still be required until authorization or routing responsibility changes.
A safer sequence is:
This keeps database cleanup aligned with the transfer rather than creating an avoidable authorization or routing problem.
Not every change belongs before ownership changes. Some records must remain valid for the previous holder until transfer or routing cutover is complete, while others can only be updated after the new holder receives control.
A post-transfer review should confirm that obsolete contacts and route objects are removed and that active references now match the new operational state.
Should a route object for the old ASN always be deleted before the transfer?
No. It may still be required while the old ASN continues to announce the range.
What if the organization no longer has access to an old mntner?
The authorization issue should be resolved through the applicable RIPE procedure before the object is needed.
Should every old person object be deleted?
No. It should first be checked for references elsewhere in the database.
Does a clean RIPE Database guarantee that the transfer will succeed?
No. The transfer also depends on resource status, documentation, authorization, and applicable RIPE NCC requirements.
Once the registry review is complete and the resource data is consistent with the planned transaction, InterLIR can be used to arrange the purchase or sale of the IPv4 block. Database cleanup reduces avoidable inconsistencies before ownership and operational control change.
Evgeny Sevastyanov
Support Team Leader
A Beginner’s Guide to Subnetting IPv4 and IPv6 Addresses Subnetting is a critical
Why IPv4 Leasing Is Becoming the Smart Choice for Businesses in 2025 1. Introduction
As CEO of InterLIR, I’ve witnessed firsthand how network isolation strategies
What is an ASN? ASN stands for Autonomous System Number. It is a unique identifier
Anycast DNS: A Leader’s Guide to Protecting Your Digital Infrastructure Executive
RPKI Certification: A Leader’s Guide to Internet Routing Security Executive
Executive Summary: What You Need to Know 🎯 Strategic Importance – Internet
When AWS DynamoDB failed in October 2025, thousands of businesses discovered that
Executive Summary: What You Need to Know 🎯 IP reputation directly impacts your
Live chat is provided by Intercom and is loaded only after you enable it. You can also contact us without enabling the chat.
