Number Resource Society

Legacy IPv4: registration, transfers and the risks worth checking

A working route does not prove that the evidence, registration or management rights are in order. How to investigate a legacy block's history, corporate succession, service agreements and status before a transfer.

Ann YongFirst published October 27, 2026Updated October 28, 2026

On this page

Reading edition revised on 28 October 2026 from Ann Yong’s original article. The original publication date is retained. Current registration rules and NRS reform proposals are distinguished; the sources below were checked on 28 October 2026.

Some IPv4 addresses were in use before today's Regional Internet Registry system existed. The networks using them have changed, and their holders may have been renamed, acquired or reorganized several times. Registration records have not always kept up. These resources can support modern infrastructure, but “it still works” is not enough for a transaction or a continuity plan. The questions are where the resource came from, who holds it now, how that history can be proved and what the next change will mean.

Legacy describes a resource's origin, not just its age

Legacy IPv4 generally refers to resources issued before, or outside, the modern hierarchical RIR allocation system. IANA's top-level registry labels some space allocated by the early central Internet Registry and now administered by RIRs as LEGACY. RIPE NCC's definition also concerns resources obtained outside the current allocation system. Check the responsible registry's definition and treatment for the particular resource.

An address block does not become legacy simply because it has been used for many years. Its allocation history and current registration status matter more than the age of the equipment or the organization using it.

Early allocations are still part of today's Internet

The regional registry system developed as the Internet grew. Earlier registration arrangements had already issued resources to businesses, universities and other organizations. When ARIN was established in December 1997, for example, its region already contained previously issued resources. A change of institution did not make those allocations disappear.

The resource, the network using it and the organization maintaining its records can each have a different history. Understanding legacy space means reconciling those histories, not treating it as a technically obsolete form of IPv4.

The differences are administrative, contractual and historical

There is no legacy version of an IPv4 packet. The important differences concern registration history, the basis for holding resources, service agreements and applicable procedures. A more recent allocation will often have entered the RIR's contractual and policy framework directly. A historical allocation may predate that framework, so the holder's present relationship with the registry needs separate examination.

Evidence requirements, eligibility for particular services, fees and transfer procedures can differ. At ARIN, legacy resources not covered by an agreement can still receive basic registration maintenance and reverse-DNS services; ARIN-provided RPKI and IRR services require an appropriate agreement. The absence of an agreement is not, by itself, proof that a resource cannot be registered or routed.

RIPE NCC describes several arrangements, including membership, a sponsoring LIR, a non-member service contract and updating registration without a formal relationship. That last option is not an entitlement to every new service: its guidance distinguishes continuing existing services from obligations to provide additional ones. Confirm the terms and eligibility relevant to the actual resources.

Legacy does not mean unregistered

Many legacy resources have current RDAP and WHOIS records, organization and contact details, reverse DNS and routing-security arrangements. IANA's top-level records can help identify the RIR administering the larger address space. The issue is not whether a resource is somehow outside all registration. It is whether the records accurately reflect its history, present holder and management authority.

Check the specific prefix, not just a top-level label

Use IANA's IPv4 Address Space Registry to identify the top-level space and responsible registry. Then examine that RIR's authoritative RDAP, WHOIS and resource records for the exact prefix, organization, status, contacts and events. A LEGACY label on a parent /8 is a starting point, not a substitute for checking the particular resource.

Compare the public record with allocation letters, earlier registration records, corporate documents, name changes, merger and assignment agreements and correspondence with the registry. Registration, legal relationships, routing and operational access should corroborate one another. No single layer supplies the whole history.

A registry entry does not settle every ownership question

The registered holder, the party exercising operational control and the person or entity with legal rights are not always interchangeable concepts. A registry record is important evidence of whom the registry recognizes, which organization is associated with the resource and who may request changes. It does not automatically resolve every legal dispute.

A fuller assessment may require the original allocation, contracts, corporate succession, assignment documents, applicable law and court decisions. For resources that predate current service agreements, reducing that history to one database field is particularly misleading. High-value transactions and contested claims warrant advice from professionals familiar with the relevant law.

Reconstruct the chain before a transaction exposes its gaps

A holder may change its name, be acquired and later move a network into a different business entity. Staff leave, old mailboxes close and original documents become scattered. While the network works, the missing links are easy to overlook. They become urgent when the organization needs to update registration, transfer the resource or answer a competing claim.

The useful question is not merely how long the addresses have been used. It is how today's applicant succeeds to the entity named in the historical records. RIPE NCC's legacy-transfer due diligence, for example, can require corporate registration, name-change and transfer evidence. Preserve that connection whenever the organization changes.

Build a resource file that can outlast its administrator

Organize evidence by resource rather than leaving it in one person's inbox. Relevant material can include allocation and registration documents, historical WHOIS and RDAP snapshots, incorporation and name-change records, merger and asset-transfer agreements, registry correspondence and authorities to act. Record current administrative contacts, account-recovery responsibility, routing arrangements, reverse DNS and the management of ROAs and IRR objects as well.

Not every application will require every document, but the business should be able to explain how the resource reached its current holder. Keep credentials and keys in appropriate security systems, not ordinary shared evidence folders. Public query snapshots do not replace contractual and succession records.

A transfer depends on the resource and the rules at both ends

Some RIR systems support transfers of legacy resources. That does not create a universal right to transfer under identical conditions. RIPE NCC's intra-region legacy process updates registration after holder verification and due diligence, preserving LEGACY status under that process. Inter-RIR transfers require separate checks of the source and destination rules.

Before signing, establish the responsible registry, recognized holder, exact status, available procedure, recipient eligibility, required documents and resulting status. An agreed price does not mean registration and service handover are ready to proceed.

Some status changes cannot be undone

RIPE NCC allows a holder to request conversion from legacy space to a PA allocation or PI assignment and explicitly describes that conversion as irreversible. The resulting resource is subject to the relevant allocation or assignment policies. This is more than an administrative relabelling.

Check whether an intended change affects status, contractual obligations, fees, service eligibility or later transfers. Ask whether accepting a service and giving up historical status are separate choices or are being bundled into one step.

Read the obligations alongside the services

Registry agreements differ between institutions and can change over time. ARIN, for example, distinguishes the fee treatment of some earlier legacy agreement coverage from resources brought under coverage later. It would be unsafe to infer that all legacy resources are free of charges or qualify for historical terms.

Review services, holder obligations, fees, termination, disputes, status effects and future transfers together. Requiring an agreement for a particular service does not automatically establish that every pre-existing right disappears. Equally, a historical allocation is not permission to ignore a contract that actually applies.

A working route is evidence—not a completed assessment

Legacy status does not itself prevent a prefix from routing. Operational checks should still establish who announces it, whether the origin ASN is expected, whether unusual or more-specific announcements exist, whether ROAs and IRR objects match the network and whether reverse DNS remains under the right control.

Registration describes resource and administrative relationships. BGP distributes reachability. RPKI provides information for route-origin validation. Account access determines who can make changes. These layers interact, but success in one does not prove the others are ready for the next operational change.

Do not leave routing security until after completion

Check eligibility for the relevant registry's RPKI service, control of existing ROAs and whether a transfer requires objects to be adjusted or reissued. ARIN's agreement-linked service eligibility is one specific arrangement to investigate, not a rule to attribute to every RIR. Access to an RPKI service is also different from a network's ability to deploy route-origin validation.

A transfer or reorganization plan should sequence changes to ROAs, IRR objects and management authority, including any interval in which validation states could change. Updating the registered holder alone does not complete the security handover.

Hand over the ability to change reverse DNS

Verify delegations, name servers, PTR service and change permissions. ARIN lists reverse-DNS management among the basic services available to legacy holders without the relevant agreement; check the actual resource's responsible registry and service arrangement rather than generalizing that example.

After a transfer, acquisition or service change, the receiving team needs more than a configuration record. It must be able to maintain that configuration. A new holder with no working route to update its delegations has not received a complete operational handover.

The registry cannot infer what a corporate deal changed

A share purchase, legal merger and asset sale can have different consequences. Determine whether the resource-holding entity still exists, whether ownership of that entity or the resource itself has changed, what registration updates are needed and which documents establish the relationship.

The corporate transaction, registry process and network changes may follow different schedules. Discovering after closing that addresses remain registered to a dissolved company—or that a departed employee controls the only account—creates avoidable difficulty. Resource due diligence belongs before completion.

Nine risks can hide behind “we have always used it”

Legacy resources are not inherently insecure, but their long history can conceal missing original documents, outdated names or contacts, unclear corporate succession, failed account-recovery paths, unintended status changes, inconsistent transfer requirements, interruptions to security-service eligibility or control, incomplete reverse-DNS handovers and competing claims that weak evidence cannot resolve.

Identifying these issues early creates more options to resolve them without disrupting customers. A useful risk assessment produces evidence, accountable owners and workable responses. It does not manufacture a claim that a network outage is inevitable.

Eight areas to resolve before committing

Registration: which RIR is responsible, what is the exact prefix's status and is the holder correct? Documentation: can original receipt, name changes, succession and transfers be connected? Access: who can log in, are contacts authorized, is appropriate multi-factor authentication used and how does recovery work if the primary administrator leaves? Routing: do origin ASNs and announcements match the organization's records?

Security: who manages ROAs and IRR objects, and could the transition create a gap or mismatch? Reverse DNS: who controls the delegation, are name servers correct and can the recipient manage them? Contracts: which agreements, fees and obligations apply, and could a change affect status? Transfers: is the intended procedure available, is the recipient eligible, are inter-RIR requirements involved and will legacy status remain?

For each area, retain evidence, name an owner and record unresolved questions. A tick beside “understood” is not a substitute for resolving an issue before signing or implementation.

Accurate registration should help recognize the history

Even strong historical evidence becomes harder to use when public records point to an entity that disappeared decades ago. Good registration services should recognize documented succession, correct records and retain an auditable change history. Preserving the past and accurately recording the present are compatible tasks.

A registry record is part of the resource's history, not the whole of it. Original allocation, established operations, corporate succession and contracts all deserve examination. The database should not be presumed to have created every relationship it records. NRS argues for registration that is more accurate, transparent and useful for verifying control and transfers.

Historical status should not become a tool for locking holders in

Whether a resource was obtained in 1992 or 2026, the Internet needs uniqueness, accurate records, reliable contacts, security information and clear change history. The institutional question is whether a holder must surrender historical status or accept new commercial restrictions simply to obtain the service that maintains those records.

In section six of Note 71, The Policy Mirror, Lu Heng proposes that moving into a registration-publication service should not itself extinguish legacy or equivalent status. A status change should require the holder's separate, explicit choice rather than become an implied price of accepting the service. This is a reform proposal, not a policy already adopted jointly by the RIRs.

NRS seeks stronger holder rights, transparent and contestable rules, and practical exit paths. Before investing in, transferring or building a critical business on these resources, organizations should be able to understand how the rules will affect them. A service relationship should not quietly become an inescapable control relationship.

Make the history, records and network agree

Legacy IPv4 is part of the Internet's living infrastructure, not merely a collection of old addresses. It can continue to support modern networks when origin and succession are traceable, registration is understood and someone can actually manage the resource and its security services.

Establish those facts before making transactional or governance assumptions. Routing does not replace due diligence, and registration does not replace an operational handover. A trustworthy system should make those tasks reinforce one another, without forcing holders to choose between network continuity and their established position.

Frequently asked questions

What makes an IPv4 resource legacy?

Usually its origin before, or outside, the modern hierarchical RIR allocation system. Age alone is insufficient: check the particular resource's history and the responsible registry's current records.

Can legacy addresses still be used?

Legacy status does not itself invalidate an address or prevent routing. Actual operation depends on registration, routing, security objects and management permissions.

Who maintains legacy registration today?

Many legacy resources are administered by an RIR. IANA's top-level registry helps identify the responsible institution, but the specific prefix and holder need to be checked with it.

Can legacy IPv4 be transferred?

Some systems permit it through the applicable procedure and due diligence. Intra-region and inter-RIR requirements, service handover and resulting status can differ. One region's procedure is not proof of another's.

Understand your exposure—and help change the rules

If uncertain records, management authority or service arrangements are affecting your business, explore the support NRS Shield offers. Current actions provide ways to work for institutional change. If you want NRS to represent you in a particular matter, review the POA and representation guidance separately, including whom you authorize, the scope, duration, withdrawal and accountability arrangements. Seeking help, joining and signing a POA are different decisions. A POA does not guarantee resource security or automatically confer election eligibility, and it does not replace a registry's representation or voting procedures.