Legacy IPv4 Space: Status, Services and Transfers
Legacy IPv4 space comes from registrations made before or outside the current hierarchical registry system. Its operational treatment depends on the responsible RIR, recognized holder, agreements and transfer history. An early allocation date alone does not establish today’s status or access to registry services.
Record four separate facts
- Which resource?
Exact prefix, current registry and current resource record.
- Which holder?
Current legal entity and evidence linking it to the original registrant.
- Which agreement?
Service coverage, billing category and the resources covered by the agreement.
- Which services?
Confirmed account access, reverse DNS, routing-registry and resource-certificate eligibility.
Use WHOIS/RDAP for the record and registry correspondence for account questions. An old allocation letter supports history; it does not prove today’s signing authority.
Treatment differs by registry
ARIN
Registration and reverse DNS can continue without an agreement. ARIN-hosted resource certificates (RPKI) and routing-registry (IRR) services require agreement coverage. Historical fee caps are limited to qualifying older legacy agreements.
RIPE NCC
Services depend on the direct or sponsoring relationship. Agree the resource’s status and available services before a proposed transfer.
APNIC
Historical-resource transfers have a distinct procedure. Resources received through it become subject to current APNIC policy.
LACNIC
Legacy addresses transferred into the region lose legacy status under the ordinary transfer policy.
AFRINIC
Transferred legacy IPv4 addresses lose legacy status under the regional transfer policy.
Checked 8 November 2026. ARIN’s legacy-service guidance and RIPE NCC legacy-resource guidance explain the service relationships that matter most before a routing-security or transfer project.
A cap attached to a historical agreement is not a fee available to any new recipient. Budget the recipient’s actual agreement and current schedule using the registry fee reference.
Establish authority before changing anything
Trace the original registration
Start with the recognized holder and historical resource evidence.
Result: The starting legal entity is known.
Explain changes of entity
Document name changes, mergers and asset transfers. Long-term operation of the network is not proof of legal succession.
Result: Every change is supported.
Resolve missing authority with the registry
If the company has ceased to exist, use the recovery or corporate-change process. A quiet route or unreachable contact does not make a prefix available.
Result: The current authority is established before changes.
Use merger and acquisition evidence where a corporate event explains the gap, and retain the registry decision with the inventory.
Plan service changes before a transfer
Confirm the receiving relationship
Before filing
Agree destination status, service agreement, recurring fees and eligibility for routing-security services. The source’s legacy treatment may change.
Assign the new operational controls
Before network cutover
Confirm certificate ownership, validity of route authorizations during cutover, routing-registry updates and reverse DNS replacement. Visible old objects may no longer be authorized.
For transfer support for an older block, provide the legal history and service details before agreeing routing changes or payment milestones.