Summary
- Legacy status describes a historical and contractual starting point, not immunity from identity checks and not an invitation to leave records stale. In ARIN's current account, relevant resources originated before ARIN began on 22 December 1997, while the early allocations often lacked the formal legal agreement now associated with registry service.
- A modern interaction can contain four different acts: authenticating the current holder, updating contact or organisational facts, recognising a transfer to a recipient and entering a service contract. Combining those acts in one electronic acceptance obscures which consent was necessary for which result.
- ARIN presently permits several ordinary record-management actions for legacy holders without an ARIN agreement. It also distinguishes the legacy source from the transfer recipient: since 2011, a legacy source in a specified-recipient transfer has not had to place the space under an RSA or LRSA merely to be vetted, while the receiving side enters the applicable modern service relationship.
- A contract can offer real value, including defined registration rights, RPKI and authenticated routing services, support obligations and a termination mechanism. That value is strongest when it is chosen explicitly. It is weakened when an urgent correction, company update or continuity-sensitive transfer is used as the only practical moment at which the holder can accept or refuse a much broader set of terms.
- Registry proof and routing continuity answer different questions. Officer authority, historical records and corporate succession can prove who may request a change; staged ROAs, route objects, reverse DNS and upstream coordination keep networks reachable. Neither proof set should be treated as consent to legal propositions that it does not address.
- A fair transition design uses a no-waiver maintenance lane, an evidence-only transfer lane and a separately signed service lane. The holder and recipient should receive a before-and-after statement of status, services, fees, policy exposure, review rights and operational effects before any irreversible record change.
The email address changes; the legal position should not change by surprise
Consider a company that has used the same IPv4 block since the early commercial Internet. Its administrative contact retired. The registered office moved. The block still supports customer systems, and the routes have remained stable. The company asks the registry to replace an obsolete contact and correct its address.
That request proves almost nothing about the company's willingness to enter a contemporary registration contract. It says that the public record should be true. It gives the registry a reason to authenticate the person asking for the change. It may justify documents showing that the company exists and that the signer can act for it. It does not, by itself, express assent to a new fee regime, future policy changes, transfer restrictions, liability allocation, arbitration, bankruptcy language or a modern account-service contract.
Now change the facts. The company has agreed to transfer the block to another operator. The registry must establish that the source is the legitimate registrant, that the source representative is authorised, that the recipient is correctly identified and that no incompatible request has already been accepted. A new holder will need a service relationship suited to the resulting record. The registry also has to coordinate a cutover whose poor sequencing could impair routing security or reverse DNS.
The additional work is real. It still does not merge every legal act. The source's proof of authority is not necessarily the source's agreement to place all its historical resources under present terms. The recipient's acceptance of a contract does not retroactively change what the source accepted decades earlier. The registry's record update does not decide every disputed theory of property. The network's continued use does not decide the contract.
This is the contract-boundary problem. A holder approaches a unique recordkeeper for one necessary act. The recordkeeper may also have a legitimate modern contract to offer. If the necessary act and the offered bargain are presented as one indivisible click, signature or ticket, the administrative choke point can do more than verify a change. It can manufacture consent.
The solution is not to exempt legacy holders from proof. It is to match proof and consent to the act being performed.
Legacy is a historical category before it is an argument
ARIN's legacy-resource history supplies an unusually clear starting point. Early Internet number resources were issued under a much lighter administrative system, often without a formal legal agreement. When ARIN began in December 1997, it took responsibility for records not then administered by RIPE NCC or APNIC. ARIN says its board decided at formation to continue registration services for those earlier resources without requiring their original holders to sign an RSA or pay service fees.
That history matters because it defeats two convenient fictions. The first is that every active resource began under today's contract. It did not. The second is that historical origin makes all later verification illegitimate. It does not. A forty-year-old record can be wrong, an original holder can disappear, a corporation can merge and an account can be compromised. Historical difference changes the starting rights and evidence; it does not remove the need for a trustworthy current record.
ARIN now defines a legacy number resource more narrowly than casual market speech often does: an IPv4 address or ASN originally issued to the current registrant by InterNIC or a predecessor before ARIN's inception on 22 December 1997 and not brought under an ARIN agreement. Resources placed under an LRSA retain a legacy designation. Transaction counsel and market entities should therefore avoid using “legacy” as a universal synonym for “old.” Date, current registrant, agreement status and registry treatment can each matter.
The historical record also crossed regional boundaries. ARIN's account of the Early Registration Transfer project explains that beginning in 2003, early registrations were moved to the RIR serving the region where the resources were used. This means legacy history is not reducible to one institution's contract vocabulary. A resource can have an early allocation, a later regional custodian, a later contractual choice and a later transfer destination. Each step needs its own evidence.
The correct legal conclusion for any particular block may depend on jurisdiction, documents and facts that are not public. This article does not invent them. Its claim is institutional: a recordkeeper should not use uncertainty about the historical position to obtain an unrelated waiver through a maintenance request. Where rights are disputed, the record should preserve the dispute and the proven facts rather than resolving the uncertainty through forced assent.
Four acts are routinely compressed into one word
The word “update” is too broad. So is “transfer.” A reliable process separates at least four acts.
Authentication asks whether the requester is who they claim to be and has authority to act for the organisation connected to the resource. Evidence can include current public registration documents, an officer attestation, a board authority, a power of attorney, historical correspondence or a chain of corporate succession. Authentication protects against impostors. It does not require the requester to agree with the registry's account of all underlying rights.
Maintenance changes a fact while the relevant holder remains the same: a postal address, a point of contact, a nameserver, a network name or another accurate public detail. Maintenance makes the record safer. It should carry no implication that the holder surrendered a pre-existing claim merely by correcting an error.
Recognition of succession or transfer changes the organisation that the registry records for the resource. The registry needs evidence connecting the old and new position. In a sale, that may include the parties' confirmed request and evidence of authority. In a merger, it may include filed instruments showing legal succession. In a reorganisation, it may require a chain through several entities. Recognition is more consequential than maintenance, but its necessary proposition remains specific: the registry is satisfied that the recorded position should move from A to B.
Contract formation creates obligations between the registry and a holder. It can define services, fees, policy incorporation, rights to registry entries, termination, assignment, liability and dispute resolution. Contract formation deserves an intentional signature and a durable copy. It should not be inferred from evidence submitted only to authenticate a record change.
Compression produces errors in both directions. A holder may say “I am only updating the record” when the evidence shows that a different legal person has succeeded to the resource. The registry may say “this is only the transfer form” when completion also requires a recipient to sign a broad modern agreement. Good administration corrects the holder's understatement without adopting the registry's understatement. It labels every act.
ARIN's own service map demonstrates that maintenance can stand alone
The strongest evidence for a clean maintenance boundary is not theoretical. ARIN publishes a service table for legacy holders that distinguishes basic services available without an agreement from services tied to an RSA or LRSA.
According to that table, a holder of uncovered legacy resources can maintain unique registration in Whois and RDAP, update and manage publicly available information, manage reverse DNS delegations, maintain records through ARIN Online and use DNSSEC. The more detailed list includes changing resource points of contact, nameservers, NetName or ASName, simple reassignment information for eligible direct allocations, mailing address and public comments. A holder can validate contact records, ask questions, request resources, request a transfer and seek organisation recovery.
ARIN says an RSA is required for recovery only if the recovery leads to a transfer.
The line is not total service parity. ARIN says uncovered legacy holders cannot use its RPKI or authenticated Internet Routing Registry services without an agreement. Those services can be operationally important. The distinction is nevertheless decisive for the boundary principle: accurate basic records do not inherently require a new registration contract. ARIN already operates a lane in which authentication and maintenance occur without one.
That lane should be treated as a governance safeguard, not a grudging exception. Stale contacts and obsolete names increase fraud risk. If updating them required acceptance of a disputed contract, the people most reluctant to sign would have a reason not to correct the record. The registry would then weaken the very accuracy it is meant to protect.
There is a legitimate security threshold. A person with no connection to an old contact cannot demand a sensitive change merely by producing a new email address. Recovery may require stronger corporate and historical evidence. The distinction is between stronger proof and broader surrender. A registry can demand the former without smuggling in the latter.
Every maintenance confirmation should therefore contain a plain statement: the accepted change updates specified fields only; it does not alter the resource's agreement status, transfer status or historical designation unless a separately identified instrument says otherwise. That one sentence would turn an implied boundary into an auditable one.
The LRSA was a bridge, and the bridge has changed
ARIN offered the Legacy Registration Services Agreement from 11 October 2007 through 31 December 2023. The arrangement acknowledged that holders of pre-ARIN resources did not enter from the same position as organisations asking ARIN for newly issued space. It offered a defined relationship and, for qualifying signers, a legacy fee cap.
The institutional offer changed over time. ARIN's current legacy FAQ records that its board voted in 2022 to end the fee cap, that the cap retired at the end of 2023 and that requests received from 1 January 2024 bring legacy resources under the ordinary RSA and current Registration Service Plan fees. Existing covered resources under older LRSAs keep the treatment applicable to those agreements.
Contract version matters just as much as programme name. ARIN's current RSA FAQ addresses version 14.0. It says existing customers do not have to update merely because ARIN publishes a new RSA, while a new signature is required when the organisation's legal status has changed since the earlier agreement. The same FAQ notes a 2025 termination addition for a holder that believes a Service Terms change materially and adversely affects its rights or use, subject to the agreement's process.
These changes make vague references to “the RSA” unreliable. A holder can be outside any agreement, under an old LRSA, under an earlier RSA, considering RSA version 14.0 or interacting with online terms that govern a different service. A transfer desk must identify which state exists before the request, which state is required after it and which document creates the transition.
The historical bridge also shows why disclosure must precede signature. Bringing old resources under agreement can provide clearer contractual rights and expanded services. It can also attach fees, policy exposure and termination consequences that did not govern the uncovered state in the same way. A rational holder may welcome that exchange. Its legitimacy depends on seeing the exchange as a choice rather than discovering it inside an urgent operational request.
The transfer source and transfer recipient stand on different sides of the boundary
The source of a transfer and the recipient do not make the same request. The source asks the registry to recognise that its recorded position should end or change for identified resources. The recipient asks to become the recognised holder and receive continuing services. Requiring the two parties to prove different things is not unequal treatment; it reflects different acts.
ARIN confronted this distinction directly in 2011. Its archived announcement on the legacy-agreement requirement says that a transferor of legacy address space would no longer be required to place the space under an LRSA or RSA for a specified-recipient transfer. Without an agreement, vetting might take longer or fail if ARIN could not confirm a valid transferor. ARIN would require an officer attestation instead. The stated purpose was to remove a requirement some organisations viewed as burdensome.
That change contains the core of the correct design. The registry did not abandon source verification. It substituted evidence aimed at authority for a broad source-side service contract. The officer attestation does not prove every possible title claim, but it answers a relevant question: an accountable person with corporate authority confirms the request. Additional historical or corporate evidence can be demanded when the record presents specific doubt.
The receiving side is different. ARIN's current transfer guide says a transfer completes after approval, a signed RSA from the receiving organisation, applicable fees and any inter-RIR coordination. In an 8.2 merger or acquisition transfer, the receiving organisation must sign an RSA and may retain the legacy status of qualifying IPv4 resources issued before ARIN's formation.
This sequence should be described honestly. The source has not necessarily accepted the recipient's contract. The recipient is not merely receiving a neutral update; it is entering the service position required for the future record. Legacy designation and agreement coverage can coexist. “Retaining legacy status” does not mean the recipient remains in the identical uncovered state as the historical source.
A closing memorandum should show both columns. Source: current agreement status, evidence used, resources released and warranties made to the registry. Recipient: resulting status, agreement signed, services enabled, fees, transfer restrictions and effective time. A single “approved” label conceals too much.
A modern contract is substantive, not ceremonial paperwork
It is tempting to describe a registry agreement as housekeeping. The current ARIN RSA shows why that description is inadequate.
Version 14.0 identifies included resources and services, incorporates the Number Resource Policy Manual and other published policies into defined Service Terms, and describes how policy changes bind the holder. It grants specified contractual rights, including the exclusive right to be the registrant within ARIN's records, the right to use the included resources within that registry and the right to transfer registration under policy. It addresses information duties, fees, review of resource use, bankruptcy, liability, termination, assignment, successors and dispute resolution.
Some provisions are protective. The agreement says ARIN will not reduce services or revoke included resources merely for underutilisation within the limits stated there. Version 14.0 permits a cause-based termination route for materially adverse Service Terms changes, and qualifying resources that were legacy immediately before agreement can resume legacy status if the specified cause is established through the contract's process. Earlier RSA holders are not automatically forced onto the new version merely because it exists.
Other provisions allocate serious risk. Policies can change. Fees are part of continuing service. Non-payment can lead through notices to stopped service and, eventually, contractual remedies over the resources. The agreement treats certain changes in controlling managerial or voting interest as assignments requiring permission consistent with transfer policy. It includes broad liability and bankruptcy treatment. A reader need not take a position on the enforceability of any clause to recognise that the document is consequential.
This is precisely why a modern RSA should not arrive as a ceremonial attachment at the last minute. A recipient may decide that the contractual rights and services are worth the obligations. A historical holder may decide to remain outside. A reorganised successor may need advice on whether a prior agreement continues or a new one is required. Those are substantive decisions.
The registry's duty is not to advise a party on private law. It is to identify the operative public form, provide versioned terms before the decision point and avoid representing that signature is merely a verification step. The holder's duty is to read and authorise. Explicitness protects both.
No waiver should be inferred from an accuracy duty
The registry has a legitimate claim that holders must keep records accurate. The Internet depends on current contacts, clear authority and unique registration. That duty can coexist with a no-waiver rule.
A no-waiver maintenance lane would provide that submission and acceptance of evidence for a specified correction do not, without a separate signed instrument, alter agreement status or concede disputed historical propositions. The requester remains responsible for the truth of the documents and statements supplied. Fraud, misrepresentation and account compromise remain grounds for correction and review. What disappears is the idea that asking for a truthful record amounts to accepting every legal conclusion preferred by the recordkeeper.
This design improves data quality. A holder should not have to choose between preserving a legal position and replacing the email address of a former employee. A successor should not leave a dissolved entity in the record because the only offered path appears to settle more than succession. A registry should not prefer stale certainty to current qualified truth.
The rule also protects the registry from inflated expectations. Recording a verified maintenance change does not mean the registry guarantees property title, resolves every creditor claim or warrants global routability. Its receipt can state exactly what it found: the named officer was authorised; the organisation document is current; the requested contact change was accepted; no agreement status changed.
Where facts are disputed, the record can be more expressive. It can preserve the current public position while placing a time-limited administrative hold on further changes. It can identify that a succession claim is under review without publishing confidential allegations. It can tell the parties what issue remains: corporate existence, signatory authority, a court order, a competing request or an incomplete chain.
No waiver is not no accountability. It is disciplined scope.
Holder proof should establish authority, not ideological agreement
Legacy records are unusually vulnerable to proof problems. Original paperwork may be old, entity names may have changed, contacts may be dead and corporate archives may have passed through several custodians. A registry cannot safely accept a claim merely because the claimant knows the prefix.
The proof task should begin with a chain. What was the original or earliest reliably recorded organisation? What documents show its continuation, conversion, merger, dissolution or asset succession? Which current legal person claims authority? Who can bind that person? Does the requested change fit the documentary chain? Is there a conflicting claim, active court order or suspicious account event?
Evidence should be cumulative rather than ritualistic. Government-issued current registration can show present existence. Filed merger or conversion documents can connect legal forms. Historical registry correspondence can connect the original record. Board resolutions and powers of attorney can show authority. Public filings can corroborate corporate events. A notarised officer attestation adds personal accountability. None alone is a magic title certificate.
The registry should ask only for evidence responsive to a real uncertainty. If the same corporation remains in existence and an authorised administrator changes a phone number, demanding an entire acquisition archive would be disproportionate. If the original corporation dissolved twenty years ago and a third party seeks to transfer a valuable block, a current business certificate alone would be inadequate.
This is also where confidentiality needs precision. Corporate instruments can contain prices, tax schedules, customer identities and unrelated assets. ARIN's transfer guide says sensitive financial information may be redacted and notes the availability of a standard nondisclosure agreement. A registry that needs proof of succession should identify the operative pages, signatures, parties, effective date and asset connection rather than treating the whole transaction archive as its natural entitlement.
The result of review should be a reasoned proof statement, not a declaration of metaphysical ownership. “The supplied evidence establishes that B is the successor authorised to request this record change” is appropriately bounded. “B has surrendered every contrary historical right” is not a conclusion that follows unless B expressly agreed.
Recipient proof is about the future record
Recipient diligence begins where source diligence ends. The source must prove authority to release or succeed. The recipient must prove identity, authority to accept, eligibility for the resulting registry relationship and readiness to maintain the future record.
The recipient's legal name, registration number, jurisdiction and authorised signer should match. If a parent, subsidiary or transaction vehicle is involved, the record should identify the entity that will actually hold the registry relationship, not merely the best-known brand. If the recipient will use a sponsoring arrangement or another permitted service path, the responsible parties should be named. If the transfer is inter-RIR, the destination requirements and resulting status should be confirmed before the source relinquishes its position.
The recipient should also receive a contract-impact statement. It should list the exact agreement and version, covered resources, fee category, services immediately available, services requiring additional enrolment, retransfer restrictions, applicable policy status and any condition that survives closing. This statement is not legal advice. It is a transaction receipt for facts controlled by the registry.
Legacy status needs a dedicated field because regional treatment differs. RIPE NCC's current inter-RIR guidance says incoming legacy resources can retain LEGACY status and that a contractual relationship is not required merely to receive them, although it is required for RPKI. Its legacy-transfer page similarly describes due diligence followed by a choice, where applicable, about entering a contractual relationship.
That model is not identical to ARIN's. The comparison demonstrates that uniqueness does not logically require one universal contract outcome. Registries can verify parties and update records while making different policy choices about status and services. The right question is therefore not whether every recipient must be contract-free. It is whether the chosen boundary is explicit, proportionate and known before the transaction becomes irreversible.
Routing continuity must not become collateral in the contract negotiation
IPv4 blocks are often supporting live networks while lawyers and registries discuss their status. The contract boundary is therefore an operational boundary as well.
A transfer or succession can affect Whois and RDAP, reverse DNS, route objects, RPKI authorisations, account permissions and abuse contacts. Some changes are under registry control; others belong to the holder, its routing providers or independent networks. If the old authority is removed before the new authority is ready, a technically valid registry change can still cause interruption.
The continuity plan should be make-before-break wherever the security model permits it. The source and recipient identify intended origin ASes, existing ROAs, authenticated route objects, reverse-DNS delegations, upstream filter requirements and emergency contacts. The registry states which entities it will remove, preserve or recreate and at what time. The recipient confirms access before seller credentials are extinguished. Observers then verify that intended routes remain visible without treating visibility as proof of legal title.
Continuity does not justify giving the source permanent control. Old credentials and obsolete authorisations should be retired promptly after the new state is proven. Nor does it justify asking networks to accept an unsafe route. Each operator keeps its routing policy. The point is sequencing: a disagreement over contract language should not create an avoidable outage merely because the registry bundled service acceptance with operational cutover.
For an uncovered legacy holder, the RPKI distinction can create strong pressure. ARIN makes RPKI and authenticated IRR services available only for resources under agreement. A recipient may rationally sign because it needs those services. That is a legitimate service choice if disclosed. It becomes problematic if a maintenance correction is withheld until the holder accepts an agreement needed only for a separate enhanced service.
The continuity receipt should therefore distinguish basic record completion from service activation. The record changed at one time. RPKI enrolment became available at another. A new ROA appeared at another. Routes stabilised at another. Each fact has a responsible actor and should not be used as evidence for the others.
Separate electronic consent is an engineering control
Contract clarity is often treated as a matter for lawyers after the process has been built. It should be designed into the interaction.
The first screen or form should ask what the requester seeks: contact maintenance, organisation recovery, legal-name correction, corporate succession, source transfer, recipient acceptance or additional service. A case may contain several requests, but the system should preserve them as separate decisions.
The evidence stage should state why each document is required. “Current registration certificate: verifies legal existence.” “Filed merger instrument: connects predecessor and successor.” “Officer attestation: verifies authority to release.” A document submitted for one purpose should not be treated as acceptance of another term.
The status stage should show the before-and-after position. Before: legacy, no agreement, basic services. After maintenance: legacy, no agreement, same services. Or before: legacy source without agreement; after transfer: source released, recipient retains legacy designation under RSA version 14.0 with listed services and fees. The exact combinations will vary, but silence should never be a status.
The contract stage should open a separate versioned document, require an authorised signatory and record the time and version. It should not use a pre-ticked box. It should make clear whether refusing the contract cancels the whole request, only the future holder's acceptance, or only an optional service. If the request cannot complete without agreement, the reason should be identified.
Finally, the completion receipt should list each accepted act separately. Authentication completed. Maintenance fields changed. Transfer approved. Contract executed. Enhanced service activated. Operational checks observed. A party reviewing the case years later should not need to infer consent from a generic ticket close.
This separation is not bureaucratic multiplication. It is how a registry proves that its power over a necessary record was not used to manufacture a broader bargain.
A refusal should name the missing proposition
Legacy cases can fail for legitimate reasons. The evidence may not connect the claimant to the registered holder. A signer may lack authority. A court order may prohibit change. Two successors may assert incompatible claims. The recipient may refuse a required service relationship. The proposed destination may not support the requested status. The registry may detect compromised credentials.
A defensible refusal identifies the proposition that failed. “Current legal existence not established.” “Chain from registrant A to claimant C is missing the A-to-B transaction.” “Officer authority not demonstrated.” “Recipient has not accepted the agreement required for future service.” “Conflicting request placed under review.” These reasons tell the parties what can be corrected and permit later consistency review.
“Legacy status not accepted” is too vague. So is “policy non-compliance.” The first may hide a dispute about contract entry, source authority, recipient status or regional compatibility. The second gives no clue which rule and fact controlled.
Review should be independent enough to matter. A person who designed or first applied the disputed requirement should not be the only reviewer. The case record should preserve submitted versions, requests for more evidence, the status statement shown to the party and every contract version offered. Timeliness should be measured by stage so additional proof does not become an indefinite holding pattern.
Emergency holds need the same discipline. A registry may temporarily block a change when account compromise is credible. The hold should identify its scope, start time, review owner and next decision date. It should protect existing routing and basic records where safe. A security measure should not become a quiet method of forcing contract acceptance.
The missing proposition rule has another benefit: it distinguishes a registry's competence from a court's. The registry can decide that evidence is limited public evidence for its record. It need not claim that no legal right exists anywhere. A later order or additional document can change the evidentiary state without requiring the institution to reverse an overbroad declaration.
The strongest argument for a modern agreement is still not an argument for bundling
There is a serious positive case for bringing legacy resources under a modern agreement. Written rights and duties can reduce uncertainty. Defined contacts and information obligations support accurate records. Fees fund continuing services. RPKI and authenticated routing records can improve operational trust. Transfer rights can be stated rather than inferred. A contract can bind the registry as well as the holder.
The current RSA's acknowledgement of registry rights and its termination mechanism offer more explicit protection than an uncovered relationship based mainly on institutional practice. Organisations with governance requirements may prefer the certainty of a signed instrument. Buyers and lenders may value a clear service relationship. Government bodies can seek legally required accommodations under ARIN's published process.
None of that requires bundling. In fact, the stronger the agreement's value, the less need there is to obtain it through an unrelated choke point. A holder shown defined services, rights, fees and remedies can choose on the merits. A registry confident in the fairness of its terms should welcome separate consent.
Bundling also harms the pro-contract case. If signature occurs only because a live route, urgent correction or transaction deadline is at risk, critics can plausibly question whether the holder evaluated the bargain. If the registry maintains a no-waiver lane and the holder later signs for enhanced services, consent is easier to defend.
The correct institutional stance is therefore neither “legacy holders owe nothing” nor “modern service requires modern submission in every interaction.” It is modular: basic truth should remain correct; enhanced contractual services can carry explicit terms; a new recipient can be required to accept a future relationship where policy says so; and the historical source should not be made to surrender more than the requested act requires.
A practical boundary standard
A credible legacy transition can be tested against ten controls.
- Classify the request. State whether it is maintenance, recovery, succession, source transfer, recipient acceptance or optional service enrolment.
- Identify the starting status. Record legacy date, current registrant, current agreement coverage and available service tier without treating any one field as complete title proof.
- Match evidence to risk. Ask for documents that resolve a stated uncertainty, with proportionate redaction and confidentiality.
- Separate source and recipient. Produce distinct evidence and consent records for each side.
- Show the resulting status. Disclose legacy designation, contract version, fees, policies, retransfer limits and services before completion.
- Require separate contract assent. Use an authorised signer, versioned text, no preselected acceptance and a durable copy.
- Preserve a no-waiver lane. Make routine accuracy corrections without altering agreement status unless a separate instrument expressly does so.
- Protect continuity. Sequence access, reverse DNS, route objects and RPKI so administrative change does not unnecessarily break service.
- Give reasons and review. Identify the missing proposition, correction path, reviewer and next date.
- Issue a layered receipt. Timestamp authentication, record update, contract execution and operational activation separately.
These controls do not decide whether an IPv4 address is property under every law. They do not prevent a registry from enforcing an agreement actually signed. They do not make all legacy claims valid. They establish a narrower and more important proposition: the registry can preserve unique, accurate records without converting every request for its indispensable action into consent to a larger legal programme.
The boundary is where legitimacy is won
Legacy resources are not museum pieces. They support active networks, enter corporate transactions, cross regional service areas and depend on contemporary security tools. Their historical position cannot freeze administration in the 1980s. Their modern use does not erase the circumstances in which they were issued.
ARIN's own history contains both sides of that truth. It preserved basic services without an agreement for original legacy holders. It built the LRSA as a contractual bridge. It later ended the new LRSA path and now offers the ordinary RSA. It permits specified source transfers without forcing uncovered legacy space under a source-side agreement, while requiring a receiving relationship for the future holder. It distinguishes basic record services from RPKI and authenticated IRR.
Those distinctions are not inconvenient exceptions to be smoothed away. They are the architecture of legitimate consent. They show that authentication can exist without surrender, that maintenance can exist without contract entry, and that a recipient's future obligations can be separated from a source's historical position.
The decisive rule is therefore modest. Ask for the proof needed to establish the requested record fact. Keep live networks safe while the fact changes. Offer modern services under clear modern terms. If a contract is required, say which party must sign, which resources it covers, which rights and obligations change, and what happens if the party declines. Never infer a waiver from the act of correcting the record.
A registry earns trust when the boundary is visible before a holder crosses it. The holder should know whether it is changing an email address, proving corporate succession, releasing a resource, accepting future service or doing all four. The receipt should preserve the same distinctions.
Legacy history and modern administration can coexist. What they cannot survive is ambiguity used as leverage. The accurate record is a shared operational necessity. It should not be the price of surrendering a position that the requested update never asked the registry to decide.
Sources
- ARIN, Legacy Resources at ARIN — the early-allocation history, pre-agreement service decision, current maintenance services available without an agreement, LRSA dates and Early Registration Transfer history.
- ARIN, Legacy Resource FAQs — current definition of legacy resources, basic service position, treatment of new resource requests, LRSA closure, fee transition and agreement-exit explanation.
- ARIN, Registration Services Agreement Version 14.0 — included resources, services, contractual rights, policy incorporation, fees, review, termination, assignment and successors provisions.
- ARIN, Registration Services Agreement FAQs — version 14.0 change, treatment of earlier RSA versions, legal-status change and post-2023 handling of legacy resources brought under agreement.
- ARIN, Quick Guide to Internet Number Resource Transfers — source and recipient requirements, 8.2 evidence, receiving RSA, absence of a needs test for 8.2 and legacy designation after qualifying merger or acquisition transfers.
- ARIN, LRSA Requirement Modified for 8.3 Transfers, 20 April 2011 — removal of the source-side agreement requirement for legacy specified-recipient transfers and substitution of officer attestation and vetting.
- ARIN, Resources Under RSA Report — public distinction between full registry services and basic legacy services, including agreement coverage for routing-security tools.
- RIPE NCC, Legacy Transfers — legacy-holder due diligence, retained LEGACY status, record update and optional contractual relationship where applicable.
- RIPE NCC, Inter-RIR Transfers — incoming status choices, source and recipient documents, synchronised registry updates and the distinction between receiving legacy resources and entering a contract for RPKI.

