Summary
- An IPv4 transfer contains at least three legally and operationally distinct events: the parties form and close a commercial agreement; the responsible RIR changes the authoritative registration position; and networks originate, accept and propagate routes for the transferred prefixes. Each event has its own actor, evidence, timestamp and failure condition.
- A sale agreement can allocate price, risk, warranties and closing duties, but it cannot by itself rewrite an RIR's records or compel an upstream to carry a route. A registry entry can identify the recognised holder, but it does not prove payment, all contractual obligations or global reachability. BGP observations prove that some networks saw an announcement, not that the announcer bought the block or that every registry condition was satisfied.
- The registry's proper transfer role is narrow but important: authenticate the parties, verify that the offering party controls the registered position, detect conflicting claims or applicable locks, preserve uniqueness, update the record, coordinate an inter-RIR change and publish a clear completion state. It should not become price setter, broker, commercial court, network planner or guarantor of routability.
- RPKI sharpens rather than erases the separation. A ROA expresses an address holder's authorisation for an origin AS; operators still decide locally whether and how to use validation results. Transfer sequencing therefore needs make-before-break handling for routing authorisations without pretending that a valid ROA is a sale deed or a BGP command.
- A credible completion design uses three timestamps and three receipts, plus an exception record for disputes. Commercial closing, registry completion and first stable operational use should be reconcilable without being collapsed. This allows buyers, sellers, lenders, brokers and operators to locate delay and allocate responsibility accurately.
- Number Resource Society points toward a more disciplined future: a portable, auditable ledger service with deterministic state transitions, bounded review, clear finality, standard evidence and no discretionary control over price, financing, deployment timing or routing choices that do not threaten uniqueness or record integrity.
Three clocks are running in the same closing room
Imagine a buyer has agreed to acquire a block of IPv4 addresses from a seller. The parties have negotiated a price, completed diligence, signed documents and placed money with an escrow agent. The seller has opened a transfer request. The buyer has acknowledged it. The RIR is reviewing authority and eligibility. Engineers at the buyer and its upstreams are preparing route filters, reverse DNS, geolocation notices, abuse contacts and origin authorisations.
Everyone may use the word "transfer" for what is happening. They are not describing one act.
The commercial team means a bargain under which the seller promises to deliver an agreed registration position and the buyer promises to pay. The RIR means a controlled change in the organisation associated with a number resource in its authoritative records. The network team means a set of operational changes through which packets can reach the addresses under the buyer's intended topology. Those acts may occur on the same day, but simultaneity does not merge their legal or technical character.
The distinction matters most when something fails. If the registry declines the request, was there still a contract? Usually there may be a binding agreement subject to a failed condition, but the answer depends on its terms and governing law. If the registry approves the change but the buyer cannot obtain usable transit, was the resource transferred? The registration event may be complete even though operational deployment is not. If routes appear from the buyer's ASN before the record changes, did a sale occur? Not necessarily.
The seller may have authorised temporary use, provided a letter of authorisation or arranged a staged migration.
A single status field cannot answer all three questions. Nor should one institution try. The evidence must be separated because each event protects a different interest. Contract evidence protects the bargain. Registry evidence protects uniqueness and recognised control. Routing evidence protects operational reliance. A sound market needs all three, connected but not confused.
Event one is the bargain between seller and buyer
The first event is commercial. Its essential facts are the identity and authority of the parties, the specified prefixes, the price or other consideration, the obligations attached to closing, the allocation of fees and taxes, the treatment of failed approval, and the remedies if one side does not perform. A broker may introduce the parties and coordinate documents. An escrow provider may hold funds. Lawyers may define representations about authority, disputes, prior use, abuse history, sanctions exposure or the condition of related records.
The bargain can be signed before either side asks a registry to act. It can also be conditional. Many sensible agreements distinguish signing from closing: signing creates obligations, while closing occurs only after identified conditions have been met. Registry approval may be one such condition. Payment release may depend on evidence that the record changed. A holdback may remain until technical cleanup or agreed assistance is complete.
None of that requires the RIR to adjudicate every commercial term. A registry needs enough evidence to know that authorised representatives of the recognised holder and intended recipient request a change. It does not need the price, the buyer's financing margin, the broker's commission, the escrow dispute clause or the parties' full warranty schedule merely to preserve a unique and accurate registration state.
RIPE NCC's published transfer agreement illustrates the distinction with unusual clarity. Its form says that the offering and receiving parties agree to transfer the registration of listed Internet number resources. The form identifies the parties, their registration details and the resources, and records their request for a registry change. It is not a complete purchase agreement. A separate commercial contract can exist around it, and the registry form does not reveal or settle the entire bargain.
LACNIC states the boundary even more directly on its transfer-facilitation page: it does not intervene in commercial operations between the parties. It may list potential offerors, recipients or intermediaries and apply the policy governing record changes, but it does not audit or assume responsibility for a broker's services. That is institutional restraint, not abdication. The market remains accountable through contract, law, diligence and professional responsibility rather than being absorbed into the registry desk.
Proof of the first event is therefore contractual. It may include signed agreements, corporate authorities, escrow notices, invoices and closing certificates. Those materials can show that value changed hands and obligations became effective. They do not, without independent registry evidence, show that the authoritative record moved.
Event two is the registry's recognised state change
The second event is administrative and evidential. The responsible RIR authenticates the request, checks the offering party against the registration position, confirms the recipient's status under the applicable policy, tests any transfer lock or dispute condition, and then updates its records. For an inter-RIR transfer, the source and receiving registries must coordinate so that the resource is not left simultaneously under conflicting administration or lost between systems.
Current RIPE policy states that the original holder remains responsible until the transfer to the receiving party is completed and that the RIPE NCC updates registration records to reflect completion. APNIC's public guide describes a source-initiated request, recipient acknowledgment, policy evaluation, fee payment where applicable and then an update of the APNIC Whois Database. ARIN's policy requires the source to be the current registered or recognised holder and free of a dispute over the resource's status for specified-recipient transfers.
LACNIC's transfer rules likewise call for holder verification, dispute checks and a record update after completion.
These are different regional procedures, but the common core is visible. The registry does not create the buyer's network and does not move packets. It changes the shared administrative account of who is recognised for the block. That act is valuable because operators, counterparties, security systems and courts need a reliable reference. It reduces the chance that one prefix is represented as belonging to two unrelated parties at once.
Registry completion should have its own timestamp. The date in a public transfer log is often the date on which the RIR processed or registered the change. RIPE NCC defines its published date that way. That date should not silently be described as the date the sale agreement was signed, the date payment was released or the date the buyer first routed the space. It is the registry event.
The evidence for that event includes the registry's completion notice, the public transfer log where one exists, the changed registration record and the account state visible to the recipient. It may also include a resource certificate or control surface made available after the change. Each item has a defined scope. A public log can prove that a registry recorded a transfer from one named party to another for listed resources on a date. It usually cannot prove the commercial price, the exact contractual closing conditions or the buyer's live use.
The record deserves authority over its narrow subject. It does not deserve metaphysical authority over every fact surrounding the resource. Treating it as conclusive proof of a sale overstates what the registry observed. Treating it as irrelevant understates the coordination value of a unique record. The disciplined position lies between those errors.
Event three is operational use in routing
The third event occurs in networks. The buyer or an authorised service provider originates routes, upstreams accept them, peers propagate them, and other networks select paths according to their own policy. The transferred addresses may then support servers, access networks, cloud infrastructure, customer assignments, translation pools or other services. This is the event through which commercial value becomes live connectivity.
BGP was not designed as a conveyancing system. RFC 4271 defines a route as destination reachability information paired with path attributes. A BGP speaker receives routes, applies local policy, selects routes for its own use and decides what to advertise to peers. The protocol does not ask for a purchase agreement. It does not query the price. It does not declare an organisation the legal owner of the prefix merely because an ASN appears at the end of an observed path.
That architecture makes routing evidence powerful and limited. Historical BGP data can show when a prefix was visible, which origin AS appeared, how widely observations spread and whether announcements changed around a registration date. RIPE NCC's Routing Information Service has collected updates from peers since 1999, and its archives can support this reconstruction. RIPEstat provides current and historical views, while other collectors offer additional vantage points.
No collector sees the whole Internet. A route visible at one observation point may be filtered elsewhere. An origin change may reflect a provider migration, DDoS mitigation service, anycast deployment, customer reconfiguration or temporary leak rather than a sale. A block can be registered to a new holder while remaining originated by the same ASN because the buyer keeps the seller or a common provider during transition. Conversely, a new origin may appear before registry completion under a permitted service arrangement.
Operational proof should therefore be stated with precision. "The prefix was observed from origin ASN X at these collectors from this time" is supportable. "The buyer owned the addresses from that time" is not established by BGP alone. Reachability tests, routing collectors, upstream confirmations and configuration evidence together can show use. They cannot replace the contract or registry receipt.
RPKI adds an authorisation event without turning it into carriage
RPKI can make the three-event model appear more complicated because it adds cryptographic material close to both registration and routing. In reality it clarifies the boundaries.
RFC 6480 says resource certificates represent the allocation hierarchy and allow a legitimate holder to authorise one or more ASes to originate routes. It also says allocation information alone is not sufficient to guide routing decisions. A Route Origin Authorization supplies an explicit statement that a given AS is authorised to originate specified prefixes. RFC 6811 then describes how a BGP speaker can derive a validation state, while making the action taken on that state a matter of local policy.
A valid ROA therefore proves neither sale nor universal reachability. It proves that a cryptographically valid authorisation exists within the RPKI hierarchy for an origin and prefix combination. An operator may use that result to reject, de-preference or accept a route according to configured policy. Other operational controls still matter: prefix filters, routing registries, customer contracts, max-prefix settings, path policy and the physical availability of transit.
Transfers create a delicate handover. The seller may have ROAs covering the space. The buyer may intend to keep the same origin, use a new one or authorise several providers. Revoking an old authorisation too early can cause routes to become invalid before the replacement propagates through caches. Keeping an obsolete authorisation indefinitely can leave unnecessary authority. RFC 6480 recommends make-before-break handling when a holder wants continued reachability: establish an appropriate alternative before revoking the prior ROA and allow relying parties to fetch the new state.
This does not give the registry permission to plan the buyer's network. It gives the registry and certificate system a duty to make the authorised handover reliable and observable. The recipient chooses origins and deployment timing. Upstreams choose import and export policy. The RIR maintains the resource-linked credential service consistently with the recognised record.
In a transaction record, RPKI should appear as a fourth receipt attached to the second and third events: the time at which new authorisation became available and old authority was removed. It must not be mistaken for the contract closing timestamp or the first stable route.
The possible sequences prove that no single event is decisive
The simplest transaction sequence is agreement, registry completion and routing deployment. Even there, the clocks rarely align exactly. The parties may sign weeks before completion. The registry may update at a time chosen by its service desk. The buyer may announce a test prefix immediately, wait for geolocation and filtering updates, or hold the block unused until a planned network launch.
Other sequences are legitimate. A buyer may obtain pre-approval before negotiating price. A seller may permit a temporary announcement so the buyer can test upstream acceptance, with closing still conditional. A buyer may acquire a business whose network already originates the routes, making the commercial control change first while the origin ASN remains constant. A temporary RIPE transfer can put registration with the receiving party for a defined term and then return it, while the commercial arrangement resembles a lease more than an outright sale.
The reverse sequence can also expose risk. Routes may move while the old registrant remains in the public record. Abuse reports and geolocation systems then point at the wrong organisation. An upstream may rely on a letter of authorisation that becomes contested. A seller's credentials may remain capable of changing routing authorisations after the buyer has paid. These are reasons to align the events, not reasons to declare them identical.
A registry change without routing change is not inherently suspicious. The buyer may be inventorying a block, migrating gradually, retaining a managed network provider or acquiring a holding company whose operating subsidiary continues to originate. A routing change without registry change is not proof of a covert sale: customer announcements, reassignment, leasing, hosting and mitigation services can all separate use from top-level registration.
The audit question is not whether every transfer follows one ideal order. It is whether the order was authorised, documented and safe; whether no incompatible claims existed; and whether each actor performed only the decision assigned to it.
Transfer logs are registry receipts, not complete market tapes
RIR transfer logs are indispensable because they create a public trace of recognised changes. RIPE NCC publishes the offering party, original and transferred blocks, receiving party, country information where available, transfer type and processed date. APNIC maintains a public log across market, merger, acquisition and historical transfers. ARIN publishes transfer statistics and data for in-region and inter-RIR activity. LACNIC's policy requires a publicly accessible log with parties, resources and transaction date.
Those logs should be read as administrative receipts. They are stronger than anecdote for the fact of registry recognition and weak evidence for everything omitted. Most do not publish price, payment date, failed conditions, broker fee, financing structure, first route, old and new ROAs, contract warranties or the amount of time the registry controlled the request.
An APNIC analysis of RIR logs estimated that entries since 2012 represented about 309 million transferred addresses through 2024, while warning that blocks transferred more than once make that aggregate an overstatement of unique space. The analysis also raised the unresolved question of whether every practical transfer is registered. That caveat is precisely why the three-event model is useful. A registry log can be complete on its own terms while missing private use arrangements. BGP can reveal operational change while missing the bargain. Neither dataset should be stretched to cover the other.
Good public reporting would connect the layers without disclosing confidential contracts. It can publish registry completion, transfer type, prefix and parties; aggregate processing time and refusal reason; and an optional, later operational indicator showing whether the block became visible from a new origin. Price transparency belongs to a separate market-reporting design and should use aggregation where confidentiality is justified.
The discipline is to label every field by event. A date without a definition is a source of false certainty.
Brokers connect the events but do not fuse them
Brokers exist partly because the three events require different expertise. They find counterparties, help determine whether a block is eligible, arrange diligence, coordinate RIR forms, sequence escrow and introduce technical checks. APNIC maintains a list of brokers that agree to conduct transfer activity fairly, act in good faith and represent RIR policies accurately. LACNIC permits intermediaries on its matching list while making clear that their use is optional and their services are not guaranteed by the registry.
The broker's practical power makes role definition important. A broker may know the transaction timetable better than any single entity, but should not certify facts outside its evidence. It can attest that the parties signed through its process or that it submitted specified materials. It cannot conclusively attest that every upstream will accept the routes. It should not represent registry pre-approval as a guarantee of closing if source eligibility, disputes or inter-RIR coordination remain open.
Conflicts also cross the event boundaries. A broker paid on closing may prefer a quick commercial agreement, while engineers need time to test route acceptance. A broker holding or selecting escrow may influence payment release. A broker that also leases space could have an interest in whether the buyer chooses ownership or temporary use. These conflicts call for disclosure and contractual controls, not for the RIR to take over brokerage.
The best broker record is a reconciliation sheet. It lists contract signing, conditions, registry submission, party acknowledgments, approval, record update, escrow release, credential handover, ROA change, first announcement and stable use. Each line identifies the responsible actor and evidence. The sheet does not convert the broker into a public authority. It makes coordination inspectable.
Upstream networks hold an independent operational decision right
Buyers sometimes treat registry approval as if it obliges a provider to route the space. It does not. Upstreams have contracts, routing policies, security controls, prefix-length rules, customer authentication and risk judgments. RFC 8212 reflects the principle that external BGP routes should not be sent or accepted without explicit policy. RPKI validation may be one input. Registry data, routing entities and letters of authorisation may be others.
That independence can frustrate a buyer that has paid and completed the record change. Yet removing it would be worse. A central registry should not command thousands of autonomous networks to accept a route. Operators must remain able to filter a hijack, reject a malformed announcement, enforce customer boundaries and choose paths. The price of distributed control is that operational acceptance needs preparation rather than ceremonial approval.
The buyer's technical diligence should begin before closing. It should inventory prefix sizes, current origins, more-specific announcements, route objects, ROAs, reverse DNS, abuse contacts, geolocation history, blocklists and provider requirements. It should ask each intended upstream what evidence and lead time it needs. None of these checks means the upstream decides whether the commercial sale is valid. They mean the provider decides what it will carry.
The seller also has duties. It should identify live services, customers, delegations and credentials that must be removed or migrated. It should not withdraw routes or revoke authorisations earlier than agreed if that would interrupt service. Nor should it retain operational control after the handover. A clean transfer narrows the period in which two organisations can plausibly act on the same block.
Routing finality is consequently probabilistic and defined. It may mean the intended origin has remained visible at a declared set of collectors and accepted by named upstreams for a specified interval, with no conflicting origin and an acceptable RPKI state. It cannot honestly mean that every network on Earth has converged forever.
Finality needs three receipts, not one grand declaration
Markets need a point at which parties can release money, recognise an asset and stop expecting ordinary reversal. The three-event model does not reject finality. It makes finality more precise.
Commercial finality is governed by the agreement. It occurs when stated closing conditions are met or waived and consideration is released. The receipt may be a closing certificate or escrow confirmation. Contract remedies can survive closing, but the bargain has crossed its defined threshold.
Registry finality occurs when the responsible RIR has committed the recognised state change, made the recipient capable of managing the resource under its service model, and issued a completion notice. Any correction or reversal power should be bounded: fraud, clerical error, a competent court order or another clearly defined ground, accompanied by notice and review where urgency permits. A registry record that can be reopened at undefined discretion is not final enough for a capital asset market.
Operational finality is a service criterion. It occurs when the intended announcements and authorisations are stable enough for the buyer's deployment, not when a registry clerk presses a button. The parties may make payment release depend on registry finality alone, on a short operational confirmation, or on staged milestones. They should choose explicitly.
Three receipts also improve disputes. If payment was released but no record change occurred, the commercial remedy is visible. If the record changed but routes failed because an upstream rejected an invalid origin, the operational cause is visible. If the registry delayed after both parties satisfied a published checklist, institutional performance is visible. Collapsing everything into "transfer failed" protects the wrong actor from scrutiny.
A common transaction identifier can link the receipts without exposing secret terms. It need not be a universal public number. The parties and RIR can maintain a shared reference, with public reporting using a privacy-preserving derivative where appropriate. The essential feature is reconciliation, not surveillance.
The registry has a narrow decision right and a real service duty
Narrowness should not be confused with passivity. A registry that merely accepts any email and edits a record would invite forged authority, double transfer and contested state. The proper service has several affirmative duties.
It must authenticate the organisations and authorised representatives. It must establish that the source is the recognised holder or lawful successor for the requested resource. It must identify locks, prior transfers, reserved blocks and active disputes that policy makes relevant. It must ensure the recipient can enter the applicable service relationship. It must coordinate with another RIR when administration crosses regions. It must commit one coherent state, preserve an audit trail and provide reasons when it refuses.
Those duties protect the global invariant of uniqueness and the practical integrity of the record. They are different from evaluating whether the price is fair, whether the buyer's investors are wise, whether its product deserves capital, which upstream it should use or when it should launch. The registry should test authority and state, not commercial merit.
The distinction can be expressed as a counterfactual. Ask whether the questioned fact could change without creating two valid holders, corrupting the record or violating a defined security restriction. Price can change without harming uniqueness. Financing can change. The buyer can choose one upstream or another. It can delay deployment. Those matters belong outside ordinary registry judgment. The source's authority cannot be ignored because accepting a false source would corrupt the record. A simultaneous conflicting transfer cannot be ignored. Those matters belong inside.
The RIR's service duty includes timeliness. A narrow role is not an excuse for an indefinite queue. Publish the required evidence, identify whether a clock is waiting on the applicant or the registry, provide status, and measure the tail as well as the median. When a difficult case requires more evidence, explain the category without exposing confidential material. Finality depends on bounded administration.
Disputes require a freeze that preserves facts, not a takeover of the bargain
Real transfers encounter insolvency, fraud allegations, corporate succession, sanctions, court orders and competing signers. The three-event model is most valuable here because it prevents a dispute in one layer from silently rewriting all layers.
If two people claim authority for the seller, the registry may need to pause the record change while it verifies corporate authority or respects a competent order. That pause does not determine who breached the purchase agreement. A court or agreed tribunal may decide contractual rights. The RIR supplies accurate records, preserves evidence and follows the outcome within its lawful role.
If routes move during a registry dispute, their existence should be recorded but not treated as automatic victory. An unauthorised announcer can create an operational fact without acquiring a contractual or registration right. Equally, the registry should not describe a valid existing route as technically unreal merely because a commercial dispute is pending. Operators may need continuity while claims are resolved.
A proportionate freeze has scope, reason, start time, reviewer and expiry or review date. It prevents the contested registration state from changing while preserving current services where safe. It should not freeze unrelated resources, disclose confidential allegations as proven fact or force the parties into a settlement preferred by the registry.
Emergency action may be necessary when there is credible evidence of account compromise or forged authority. Even then, restoration and review should follow. A security hold protects the record; it is not an opportunity to acquire an open-ended power over the holder's business.
Inter-RIR transfers need a two-ledger commit
When a transfer crosses RIR boundaries, the registry event itself has two institutional sides. The source RIR knows the existing record and source restrictions. The receiving RIR knows the recipient relationship and destination policy. If they update independently without a shared completion rule, the resource can appear in both places, neither place or different states at different times.
The solution resembles a controlled two-ledger commit. First, each RIR validates the facts assigned to it. Second, both mark readiness against the same resource set and parties. Third, one coordinated action establishes the effective completion time. Fourth, public and account records are reconciled. If the action cannot complete, the system returns to the prior state without pretending that half a transfer is final.
This language describes service design, not a claim that current RIR systems literally use one technical transaction protocol. The requirement is observable consistency. Parties should receive one effective registry timestamp and know which institution is responsible for any remaining discrepancy.
Inter-RIR policy compatibility is a separate issue. One registry may impose a needs test or longer holding period. That can prevent the transfer even when the record-update technology is sound. The present article does not resolve that trade barrier. It insists that a policy refusal be labelled as such rather than disguised as a technical inability to change the record.
Routing remains outside the two-ledger commit. Origin authorisations can be sequenced around it, but external operators retain local choice. A global registry transaction that attempted to make route acceptance automatic would turn a useful record service into a command system.
An audit should reconstruct the three events separately
A high-quality transfer audit begins with three columns. The commercial column records signing, conditions, closing authority, escrow status and payment release. The registry column records pre-approval where relevant, submission, evidence requests, party acknowledgment, policy decision, coordinated completion and public record change. The operational column records intended origins, ROA states, route objects, upstream acceptance, first announcements, stability and retirement of the seller's access.
Each entry needs a source, timestamp, actor and confidence. A signed contract is primary evidence for its terms. A registry completion notice is primary evidence for registry recognition. Collector observations are primary evidence for what those vantage points saw. A broker's recollection may connect missing context but should not displace stronger records.
The reconstruction should preserve disagreement. If the contract defines closing at 14:00 UTC and the public transfer log shows the next calendar day, the difference may reflect processing or time-zone convention. It should be explained, not rounded into one date. If a prefix appeared from two origins during migration, the overlap should be measured. If the buyer never routed the block, the operational column should say so without implying that the registry transfer was invalid.
This method also prevents inflated claims in market analysis. Counting registry rows measures recognised changes. Counting origin changes measures routing events. Counting broker deals measures commercial arrangements known to that broker. The denominators are different. A researcher can compare them, but should not add them as if they were one population.
For the parties, the audit becomes a post-closing control. It confirms that seller credentials were removed, buyer contacts are accurate, authorisations match intended origins, and contractual records reconcile to the registry receipt. For the RIR, aggregate audits can expose delayed cases, inconsistent evidence requests and recurrent inter-RIR failures without exposing prices.
Number Resource Society can make the ledger thinner and the transfer safer
The positive alternative is not a market without records. Scarce, globally unique identifiers need reliable state, and markets need finality. Number Resource Society offers a direction in which that state service becomes more portable, testable and modest.
An NRS transfer service would define the minimum valid state transition: identified source, proof of control, identified recipient, exact resource, no incompatible prior state, authorised signatures, effective time and durable history. The validation rules would be public. Evidence formats would be standard. The holder's record and proofs would be exportable rather than trapped in one operator's account system.
Service providers could verify and publish the transition without acquiring authority over the price, financing, broker selection, customer plan or route. A disputed transition would carry a visible status and evidence path rather than being erased by unexplained discretion. Finality rules would identify the narrow grounds and process for correction. Independent mirrors and tested succession would protect continuity if one service operator failed.
Portability is essential because it disciplines the recordkeeper. If a holder can move its verified state and history to a compatible service without losing practical recognition, poor service has an exit consequence. The operator still has to preserve uniqueness; it does not gain a licence to create conflicting copies. Portability concerns custody and service, not duplication of the resource.
NRS also clarifies the routing boundary. It can support portable proof of control and route-authorisation entities, but networks continue to validate and choose locally. The common layer states what is authentic. Operators decide what to carry within their security and commercial relationships.
This is stronger than simply asking today's RIRs to promise restraint. It makes restraint part of the service architecture: a small set of deterministic checks, a complete audit trail, a portable record, explicit finality and no standing permission over ordinary business choices.
The word transfer should never again stand alone
IPv4 scarcity has made a registry change economically significant, but significance does not merge institutions. The seller and buyer create a bargain. The registry recognises a state change. Operators create and accept reachability. RPKI links recognised control to origin authorisation while leaving routing action local. Brokers and escrow agents coordinate the boundaries without becoming the source of all truth.
The practical reform is linguistic as well as institutional. Every serious report should say which transfer it means. Was the contract signed? Did it close? Did the RIR complete the record change? Did the buyer obtain account control? Was an intended ROA published? Did the new origin become visible? Did upstreams accept it? These are answerable questions. "Did the transfer happen?" is not answerable until the event is named.
This precision protects all sides. Buyers gain a clearer closing design and can locate operational risk before paying. Sellers can prove delivery without guaranteeing the buyer's network. Brokers can state the limit of their coordination. Upstreams retain routing autonomy. Registries can be held to a demanding but bounded service standard.
Most importantly, the distinction returns the recordkeeper to the scale of the record. The registry did not create the commercial value, negotiate the bargain or carry the packets. It performs the indispensable middle act: preserving one coherent account of recognised control. That act deserves careful authentication, prompt execution, auditability and continuity. It does not justify dominion over the acts on either side.
A mature transfer market will therefore publish and reconcile three clocks. Contract finality, registry finality and operational use can be close, but they will never be the same event. The system becomes safer when it stops pretending otherwise.
Sources
- ARIN, Number Resource Policy Manual, Section 8 - current source and recipient conditions, dispute status, express transfer approval, registration agreements and specified-recipient requirements.
- ARIN, Transferring IP Addresses and ASNs - public description of transfer types, party responsibilities and the relationship between policy review and registration change.
- APNIC, Internet Number Resource Policies, Part 5 - transfer purpose, source and recipient conditions, accurate Whois registration, public logging and the distinction between transfer types.
- APNIC, IPv4 Transfer Guide - source initiation, recipient acknowledgment, evaluation, fees, pre-approval and the timing of the Whois update.
- APNIC, IP addresses through 2024 - aggregate transfer-log analysis, repeat-transfer caveat and the unresolved boundary between registered and unregistered practical transfers.
- RIPE NCC, RIPE Resource Transfer Policies, RIPE-807 - holder responsibility until completion, permanent and temporary transfers, record updates, restrictions and public transfer fields.
- RIPE NCC, Transfer Agreement Template v6.0 - a registry-facing agreement expressly framed as transfer of registration between offering and receiving parties.
- RIPE NCC, How to Transfer IP Addresses and ASNs - party documents, authorised signatures, submission and the operational description of holdership change.
- RIPE NCC, Transfer Statistics - definitions of offering party, recipient, transferred block, transfer type and processed date.
- LACNIC, Possible IPv4 Transfers - explicit separation between LACNIC's registry role and the commercial operations of parties and optional intermediaries.
- RFC 4271, A Border Gateway Protocol 4 - BGP route information, local preference, route selection and operator-controlled advertisement.
- RFC 6480, An Infrastructure to Support Secure Internet Routing - separation of allocation information from route authorisation, ROA meaning and make-before-break handling.
- RFC 6811, BGP Prefix Origin Validation - origin-validation states and the operator's local policy decision over their routing effect.
- RFC 8212, Default External BGP Route Propagation Behavior Without Policies - explicit import and export policy as a prerequisite for external route use and propagation.
- RIPE NCC, Routing Information Service - global BGP update collection since 1999 and archived routing observations used to distinguish route evidence from registry evidence.

