Summary
- A registry-recognized transfer proves a recorded change associated with a prefix. It does not by itself prove payment, possession, public routing, customer use, productive integration or the identity of the network operating the addresses.
- Post-transfer states should be classified separately as holding, leasing, operational reserve, renumbering, committed future use, failed integration or routed production. A block can move between these states, and more than one state can apply to different portions of the same transferred range.
- BGP is the strongest public evidence of route origination and propagation, but route collectors see only what their volunteer peers send them. A prefix can be hidden by aggregation, visible only through private or limited paths, temporarily withdrawn or used inside an arrangement that does not expose the commercial party.
- RPKI adds evidence of origin authorization, not evidence that a route exists or carries traffic. Reverse DNS adds evidence of naming and delegation, not utilization. RDAP adds registration and contact evidence, not an operating census. Each source answers a different question.
- Time is essential. A daily label attached to the transfer date will misclassify ordinary staging. The study should retain pre-transfer baselines, observe exact and covering routes, measure origin and visibility changes, and keep unresolved cases open rather than forcing them into "used" or "unused."
- Non-routing must never be treated automatically as speculation. Reserve capacity, disaster recovery, staged renumbering, customer commitments, financing conditions, litigation, technical contamination and abandoned integration can all produce silence without proving manipulative intent.
- Better market evidence would publish state transitions, observation coverage and uncertainty without demanding confidential contracts. The registry should keep an accurate transfer history; operators, researchers and market entities should be able to test what happened next without turning network telemetry into a licence for commercial approval.
A closing is not a packet
The title describes a common analytical mistake rather than a single scandal. A buyer and seller agree terms. The required checks are completed. A registry changes the recorded holder and adds a row to a public transfer list. The transaction is now visible to anyone who downloads that list. Yet a route collector never sees the transferred prefix announced by the buyer.
What happened?
The tempting answer is that the buyer acquired the block only to sit on it. That answer may be right in a particular case. It is not established by the evidence. The transfer record and the routing record are observations of different systems.
The registry record concerns recognized administration. Depending on the region and transfer type, it may identify a source, recipient, prefix, date, country code and whether the event was a policy transfer or a change in business structure. It marks an institutional event. It does not disclose the private bargain, the settlement date, financing conditions, lease arrangements, migration plan, customer contracts or internal network design.
BGP concerns reachability information exchanged among autonomous systems. A route seen at a collector shows that at least one monitored path carried an announcement for a prefix at a time. It does not identify the beneficial owner. It does not show the purchase price. It does not show whether packets reached a functioning service. It does not tell us whether the route came from a lessee, transit customer, managed-service provider or the acquirer itself.
The Internet Numbers Registry System described in RFC 7020 makes the boundary unusually clear. Registration accuracy and uniqueness are registry goals, while whether addresses are actually announced and how they are advertised are operational questions outside the registry system's scope. Scarcity did not erase that separation. It made the consequences of forgetting it more expensive.
A transfer researcher should therefore begin with two independent questions. What change did the registry recognize? What changed in observable network operation? Only after both are answered should the study ask what economic state is consistent with the combined evidence.
The market needs seven states, not a binary verdict
"Routed" and "unrouted" are useful observations. They are poor economic categories. A transferred /16 may contain several /20s in production, a /19 held for growth, smaller blocks leased to customers and a portion being cleaned after earlier abuse. One label for the whole /16 destroys the very information the market needs.
A more useful classification begins with seven states.
Holding means that the recipient retains recognized control without enough evidence to assign an immediate operational purpose. Holding is a description, not a judgment. It covers a pension-like long position, an inventory position, a company waiting for a sale, or simply a case for which public observers know too little. The term should not be silently upgraded to "hoarding" or "speculation."
Leasing means that another operator receives contractual use while the top-level registered holder may remain unchanged. The lessee may originate the routes from its own autonomous system, use a managed origin supplied by the lessor, or place customers behind the addresses. Public routing may reveal an origin inconsistent with the registered name without explaining the contract.
Reserve means that the block is held as operational insurance or planned capacity. Disaster recovery, merger contingency, customer failover, address reputation separation and a margin for sudden growth can all create option value before a public route appears. Reserve is economically active even when packets are not flowing.
Renumbering means that deployment is in transition. The acquirer may prepare routing policy, access lists, geolocation corrections, reverse DNS, security controls, customer notices and application changes before announcing the new range. Old and new ranges may overlap for months. A transferred block can be productive only after a deliberately slow cutover.
Future use means that a credible deployment is committed but not yet live. The distinction from reserve is evidence of a dated project, customer contract, equipment order, facility opening or migration plan. Public observers often cannot see that evidence, so they should record the state as possible rather than declare it proved.
Failed integration means that the intended use did not materialize. The cause may be a lost customer, financing failure, damaged address reputation, routing-policy conflict, geolocation errors, legal dispute, corporate change or a technical plan that proved uneconomic. This is commercially important because a closed transfer can still fail as an investment.
Routed production means that the block is observably announced and supported by additional signs consistent with operation. Even this category needs levels. A route seen once is not the same as sustained visibility across collectors, stable origin authorization, reverse naming and reachable services.
The states are not mutually exclusive at aggregate level. Classification should occur at the most specific stable prefix supported by the data and should preserve transitions. The question is not "Was the deal used?" It is "Which portions entered which states, at what times, on what evidence?"
Public transfer logs establish an event boundary, not an economic conclusion
The common NRO transfer-log format gives researchers a valuable starting point. It allows RIRs to publish cumulative intra-regional and inter-regional transfer records in a shared JSON structure. The value is comparability: a prefix, transfer type, source, recipient, date and related regional fields can be normalized across institutions.
That shared record is still not a ledger of every commercial fact. A transfer row can represent a prefix rather than a whole bargain. One commercial acquisition may be split into many rows because the address space was fragmented. Several rows on one day may reflect one price and one settlement. Conversely, one transferred aggregate may later be divided among different operating arrangements.
The event type matters as well. RIPE NCC's transfer statistics distinguish policy transfers from changes in business structure and can identify permanent or temporary cases. A merger-related update is not automatically a market sale. A temporary registration change is not equivalent to permanent disposal. Counting every row as a purchased asset would corrupt both price and deployment analysis.
The published date must also be interpreted carefully. APNIC's historical transfer-log specification describes the transfer date as the date on which the recipient received the resource in the record. That date is an administrative anchor. The commercial agreement may be earlier, payment may be conditional, and operational migration may be later.
The correct unit is therefore a reconciled transfer case. Rows with the same parties, event type, institutional path and close date may be linked, while preserving each prefix. The case should keep at least three clocks: agreement or settlement where confidential contributors can supply it, registry recognition and first observed operational state change.
Public analysis can proceed without knowing the price. It can ask how the prefix behaved before and after registry recognition. But it must never describe the transfer date as if a switch were thrown in every router. The date creates an observation window; it does not predetermine what the window should contain.
BGP provides the best public route evidence and an incomplete view
RFC 4271 defines BGP as an exchange of reachability information subject to local routing policy. Speakers receive routes, choose among them and decide what to advertise to peers. This makes BGP data powerful: it can show the appearance, withdrawal, origin and propagation of a route in a way no registration entry can.
It also explains why a collector is not the Internet. RIPE's Routing Information Service receives BGP updates and withdrawals from networks that voluntarily peer with its route collectors. RouteViews likewise archives RIB and UPDATE data from its own collector peers. These projects provide broad and historically deep observation. They do not receive every route from every autonomous system.
The first route test should look for the exact transferred prefix. If a /20 moved, did any collector see that /20? Record the origin AS, first-seen date, last-seen date, number of collector peers, number of distinct collectors and the persistence of the observation.
The second test should look for more specifics. The /20 may never appear as one route because the operator announces sixteen /24s. A study that checks only the transferred prefix will call an active deployment silent. More-specific coverage should be measured by address count and time, with care not to double-count overlapping routes.
The third test should look for covering routes. The transferred /20 may sit inside a /16 already announced by a parent, provider or group company. The global table can reach the addresses through that aggregate without exposing a separate /20. A route collector will not reveal the transferred boundary because routing aggregation is doing exactly what it was designed to do.
The fourth test should measure origin continuity and change. A new origin after transfer can indicate integration, leasing or a managed routing arrangement. An unchanged origin can mean the seller still operates the network temporarily, the parties belong to the same corporate group, the buyer acquired the operating company, or the address space is leased back. Origin continuity is evidence, not a verdict.
Finally, the study should retain collector coverage. "Not seen" must mean not seen by the listed collectors and peers during the stated period. Without that sentence, absence is overstated.
Route visibility is not traffic, service or revenue
A stable BGP route is stronger evidence than a registry row for routed production, but it remains control-plane evidence. It shows an advertised path. It does not measure customer count, address occupancy, packet volume, service quality or revenue.
An operator can announce an entire /16 while using only a small portion. The route provides reachability for the aggregate, not a utilization map. A hosting company can place thousands of active endpoints behind a /20, while another operator announces the same-sized block for a handful of infrastructure systems. BGP treats both as one prefix announcement.
The opposite error also matters. A route can be visible while no useful service is available. A buyer may announce a block briefly to test filters or update geolocation services. A lessor may keep an aggregate route present while no customer uses a particular subrange. A hijack or route leak may create visibility unrelated to authorized production.
Data-plane measurements can add context. Responsive addresses, DNS answers, TLS handshakes and path measurements can support an operational inference. Yet each method has blind spots. Firewalls suppress responses. Services can be private, access-controlled or reachable only from selected networks. Anycast can make one probe location unrepresentative. Network address translation can support many users behind few public addresses. Ethical scanning limits what should be attempted.
The evidence ladder should therefore be explicit. A route observation proves visibility at monitored BGP vantage points. Persistent exact or more-specific routes across diverse peers support broad propagation. Consistent data-plane response supports active service. Customer or operator records can support productive use under confidentiality. No single rung should be relabeled as complete economic utilization.
This distinction matters for market valuation. Buyers care about whether a block can be routed cleanly, but they also care about reputation, geolocation, upstream acceptance, customer demand and internal cost. A route that appears is one milestone. It is not the income statement.
RPKI proves authorization, not announcement
RPKI is often misread in the opposite direction. A Route Origin Authorization appears to provide a crisp link among a prefix, a maximum length and an origin AS. It is therefore tempting to treat a new ROA as proof that the buyer deployed the block.
The architecture says otherwise. RFC 6480 explains that allocation information in the resource public-key infrastructure is not enough to guide routing decisions. A ROA makes an origin authorization explicit. It states that an AS is authorized to originate a route for a prefix within the permitted length. Authorization is not an announcement.
A recipient can create a ROA weeks before launch as prudent preparation. It can authorize several origins for failover. A lessor can authorize a lessee's AS. A company can leave an authorization in place during a migration. A stale ROA can survive after the operational plan changes. None of these entities tells us whether a route was visible or carried traffic.
The absence of a ROA is equally ambiguous. RPKI adoption is incomplete. An operator may route validly in the ordinary BGP sense without publishing an origin authorization. Its route will be "not found" rather than proven unauthorized. A study that counts only RPKI-covered space will understate operation.
RFC 6811 adds two further cautions. Origin validation assigns a state to a received BGP route; it does not attest the whole AS path. Routers then apply local policy to the validation state. Different caches can temporarily hold different views because the signed entities are distributed and refreshed over time.
For transfer analysis, RPKI supplies useful transition evidence. Did the old authorization disappear? Did a new origin become authorized? Was there a make-before-break overlap? Did visible routes become invalid because a maximum length or origin did not match? These observations can reveal integration quality and operational risk.
They cannot prove why a block remained silent. A new ROA followed by no route is consistent with future use, reserve, a failed launch or a cautious buyer. No ROA and no observed route is consistent with holding, private use, covered routing or simple non-adoption. The honest label is unresolved unless another source narrows it.
Reverse DNS shows delegation and naming discipline, not occupancy
Reverse DNS is another useful but overinterpreted signal. IPv4 reverse mapping places addresses under in-addr.arpa. Delegation can show that an operator or customer has prepared authority for a range. PTR records can reveal naming conventions associated with access, hosting, infrastructure or customers.
Preparation is not production. A buyer may establish name servers and populate templates before routing. A block may remain actively routed with sparse or absent PTR records because the service does not need them. Consumer access ranges may use generic names. Hosting providers may create reverse records only on request. Security-conscious operators may deliberately disclose little.
Delegation boundaries also complicate measurement. RFC 2317 describes classless reverse delegation for ranges smaller than a /24. The technical arrangement can use aliases and child zones that do not map neatly onto a transfer row. A parent organization may retain reverse authority while delegating customer ranges. A stale delegation may persist after the economic relationship changes.
The best use of reverse DNS is as a dated change signal. New authoritative name servers near the transfer date can support an integration inference. A change from the seller's naming pattern to the buyer's can mark renumbering. Diverse customer-branded PTR records can support production or leasing. The disappearance of old names can show cleanup.
Absence should remain low-weight. A missing PTR response does not show that an address is unused. A present PTR response does not show that the named host exists. Even a responsive forward-confirmed reverse name proves only a configured relationship at the time of observation.
Researchers should preserve zone-delegation evidence separately from individual PTR density. They should record query time, resolver path and whether the answer was authoritative. Bulk reverse-DNS studies can also create privacy concerns by exposing naming patterns never intended as market disclosure. Aggregate findings are usually sufficient.
Reverse DNS is valuable precisely because it is independent from the transfer log. It adds operational texture. It becomes misleading only when a configuration clue is treated as an occupancy meter.
RDAP tells us who the registry recognizes, within publication limits
RDAP modernizes access to registration information. RFC 7480 defines its use over HTTP, while RFC 9082 defines queries for Internet-number resources and related records. RFC 7484 provides a way to find the authoritative service for an address range.
For transfer research, RDAP can confirm the current registered range, entities, status, events, links and notices that the server makes available. Repeated snapshots can show when public registration changed and whether a range was split. RDAP is often more structured and automatable than old WHOIS output.
It still reflects registration, not every economic role. The listed entity may be the recognized holder, a parent company, an administrative contact, an abuse contact or another role defined by the service. The operator announcing the route may be a subsidiary, customer, lessee, managed provider or transit partner. Privacy and publication rules can suppress details. Contact information can lag reality.
A transfer study should not "resolve" an origin mismatch by assuming one source is wrong. If RDAP names Company A and BGP shows an origin associated with Company B, the relationship is unknown until supported. It may be a legitimate lease, outsourcing arrangement, merger, customer assignment or group structure. It may also be a hijack. The mismatch is a research lead, not a finding of misconduct.
RDAP events can improve chronology, but event semantics vary by service. A last-changed timestamp is not necessarily the commercial closing date or the start of use. Caches and mirrors can add delay. Historical snapshots are therefore important; a current query cannot reconstruct every intermediate state.
The strongest registration statement is narrow: at the stated time, the authoritative RDAP service returned the stated record for the queried range. That can validate a public transfer row or reveal a later change. It cannot prove that every address is occupied, that a buyer paid, or that a named entity controls the route origin.
This restraint is not pedantry. It protects legitimate operators from being accused on the basis of role confusion.
Time turns weak clues into a credible sequence
A single-day snapshot is almost guaranteed to exaggerate certainty. Transfers and network migrations are processes. The evidence becomes useful when placed on a common timeline.
The baseline should begin before the first known commercial or registry event. At minimum, the study needs enough history to distinguish a truly silent block from one that was intermittently announced. It should record exact, more-specific and covering routes; origins; collector visibility; ROAs; reverse delegation; RDAP holder data; and obvious data-plane signals.
The transfer window then needs event markers. These can include public transfer date, RDAP change, old-route withdrawal, new ROA creation, new-route appearance, reverse-DNS change and first sustained response. Where parties contribute private evidence, agreement, escrow, registry submission, settlement and customer launch can be included under confidentiality.
After the transfer, observation should continue long enough to capture ordinary staging and failed plans. Seven days may detect immediate deployment. Ninety days can detect migration. A year can reveal reserve activation, lease placement or resale. No universal cutoff converts silence into motive. The study should publish several horizons rather than choose one moral deadline.
State transitions are more informative than endpoints. A sequence of registry change, new ROA, reverse delegation and then sustained route visibility supports planned integration. A sequence of registry change, no configuration change and a later transfer may support inventory holding. A brief route, repeated invalidity and withdrawal may support failed integration. Each remains an inference with a confidence label.
Intermittency deserves its own measure. A block seen on two days out of a year differs from one seen daily. Collector breadth matters too. First-seen and last-seen dates should be accompanied by visible-day share, median peer count and origin stability.
Unresolved cases must remain unresolved. A study should resist the pressure to make every row fit a final chart. In a market where leases and internal operations are private, uncertainty is part of the subject, not a defect to be hidden.
Holding is a fact pattern, not a moral category
Suppose a transferred prefix is absent from exact and more-specific BGP observations for eighteen months. RDAP shows the recipient. No ROA or reverse delegation changes. The recipient later transfers the block again. This is strong evidence of a holding period without public routed production.
It still does not establish harmful speculation by itself. The buyer may have intended deployment and abandoned it. It may have bought several alternatives and selected another. It may have held the block as collateral or inventory. It may have waited for a sale. Motive requires evidence beyond the telemetry.
Market governance often collapses this distinction because "holding" sounds passive and scarcity gives passivity political weight. Yet every capital market contains inventory and option value. An operator keeps spare routers, fiber pairs, cloud capacity and cash. The relevant question is not whether an input sat unused at a moment. It is whether conduct caused a defined harm that justifies intervention.
Public evidence can measure concentration, holding periods, route activation and repeat transfer. It can show whether a small number of entities acquire large volumes that remain publicly silent. It can compare later deployment and resale. Those are valuable facts. They do not automatically identify manipulation, market power or false representation.
The word "speculation" should therefore be reserved for cases with an economic definition: acquisition primarily to profit from expected price change, supported by transaction behavior or disclosed intent. Even then, speculation is not synonymous with abuse. A separate analysis must show deception, artificial scarcity, manipulation, policy evasion or another cognizable harm.
This discipline improves research rather than weakening it. A finding that 30 per cent of a cohort remained unobserved at one year would be meaningful if coverage and state definitions were sound. Calling the same addresses "hoarded" would add rhetoric and remove precision.
The market needs measurement of inactivity. It does not need telemetry turned into a character judgment.
Leasing separates registered control from routed operation
Leasing is the most obvious reason a transferred holder and route origin may differ. A buyer can acquire recognized control and then grant use to another network. Depending on the arrangement, the lessee may announce the prefix from its own AS, use the lessor's origin, or receive addresses behind a managed network.
BGP can expose an origin change without disclosing the agreement. RDAP may continue to identify the holder. RPKI may contain a ROA authorizing the lessee's AS. Reverse DNS may point to the lessee, its customers or the lessor's infrastructure. Taken together, these signals can support a leasing hypothesis.
They cannot prove the payment relationship. The same pattern can result from outsourced routing, a subsidiary, a customer reassignment, a merger not yet reflected in public branding or a managed security service. Corporate mapping and party confirmation are necessary before labeling a specific case.
Leasing also means a block may be economically productive before a clean public route pattern emerges. A lessor can prepare the range, repair reputation and stage customers gradually. The lessee may announce more specifics under a covering route. Some addresses may serve private interconnections or limited-access services that broad collectors and scans do not observe.
For market analysis, the useful distinction is between top-level recognized control and operating use. Both should be recorded. A holder can be economically active by supplying capacity even if it is not the origin AS. An operator can depend on addresses it does not own or hold at the top level.
This has governance consequences. If a registry tries to infer prohibited leasing from an origin mismatch, it risks punishing ordinary network relationships. If it ignores operating roles entirely, abuse and continuity contacts may point to the wrong party. The answer is role clarity, not forced identity.
A thin record can identify the recognized holder, an optional authorized operator and an operational contact without publishing rent, term, customer lists or other sensitive provisions. The market can then distinguish leasing from unexplained mismatch while preserving commercial confidentiality.
Reserve capacity has economic use before routed use
Networks are built for peaks and failures, not average-day elegance. An address block kept for disaster recovery can be valuable precisely because it is not in normal production. A customer migration reserve can prevent an emergency purchase. Capacity held for a signed data-center opening can support financing and sales commitments before the first router advertises it.
Reserve therefore has economic use without current public routing. The value is optionality. The holder pays to reduce the probability that a future shortage, contaminated block or delayed transaction will interrupt service.
Public telemetry will often classify reserve as silence. There may be preparatory ROAs or reverse delegation, but prudent operators can also wait. Internal address plans and customer commitments are not normally public. Researchers should not demand their disclosure merely to avoid a negative label.
The defensible method is probabilistic. A block bought by an operating network, adjacent to its existing holdings, accompanied by new authority entities and activated during a later capacity event is consistent with reserve. A block held through several years and repeatedly offered for sale is more consistent with inventory. Neither inference is certain without party evidence.
Reserve also changes how utilization policy should be judged. A rule that recognizes only addresses carrying packets at the review date penalizes resilience. It encourages operators to create cosmetic traffic or announce space prematurely. It can make disaster recovery less robust while claiming efficiency.
Market transparency should distinguish planned reserve from unexplained inactivity where the holder chooses to attest the difference. The attestation can remain confidential to an auditor, with public output limited to aggregate categories and verified time bands. No registry needs customer contracts or network diagrams to keep the top-level record unique.
The key principle is that routing is one form of use, not the definition of all value. An insurance policy is useful before the fire. Reserve addresses are similar: their contribution is the capacity to respond when ordinary supply cannot.
Renumbering is slow because dependencies are real
It is easy to say that a buyer should route immediately after closing. It is harder to move a production network without breaking customers.
Addresses appear in router policy, firewalls, access lists, monitoring rules, DNS, geolocation systems, fraud controls, partner allowlists, certificates, application configuration, customer documentation and vendor contracts. Some dependencies are held by third parties who update on their own schedules. A clean migration therefore requires more than an origin announcement.
A buyer may first verify that upstreams accept the range and that route filters have caught up with registration. It may create ROAs, request reverse-DNS delegation, correct geolocation, test reputation services and notify customers. During cutover it may announce old and new ranges together. It may move low-risk services first, then databases, payment partners or regulated customers.
The BGP sequence can look untidy. The old origin may persist. New more specifics may appear briefly. A covering route may hide the transferred boundary. Some routes may be invalid until authorizations are corrected. A daily snapshot could label each phase differently.
This is why first route appearance is not enough. The study should estimate a stabilization date: the point after which origin, visibility and authorization remain within a defined range for a sustained period. It should also retain the old block's withdrawal and the overlap duration where visible.
Failed renumbering needs separate treatment. If the new range is contaminated by geolocation or reputation errors, the buyer may reverse the move. If a critical partner refuses the addresses, the deployment may stall. The registry transfer can remain valid while the operational project fails.
These are market-quality signals. A block that is legally transferable but expensive to integrate is worth less. Evidence on time to stable routing, authorization errors and reverse-DNS transition can help buyers price that risk. The evidence should improve diligence, not become a reason for an institution to approve the buyer's business plan.
Future use is credible only when the time claim can be tested
"Future use" can explain any silent block, which makes it easy to invoke and hard to evaluate. A credible category needs a horizon and evidence.
The evidence might be a signed customer commitment, facility lease, equipment purchase, board-approved capacity plan, financing condition or migration schedule. None must be public. An independent reviewer can verify the existence and date of the evidence without revealing counterparties or amounts. The public classification can say "verified committed use within twelve months" and later report whether activation occurred.
The point is not to revive a needs test through the back door. The market does not need an administrator to decide whether the project deserves addresses. The evidence serves research and voluntary disclosure. A buyer unwilling to disclose can remain in the unobserved category without losing recognition.
Time makes the claim accountable. If the stated horizon passes, the record can change to delayed, reserve, failed integration, leased, held or routed production. The original claim remains in history. That allows researchers to estimate how often committed plans materialize without converting misses into misconduct.
Future-use evidence is especially important for large transactions. A hyperscale deployment may require long lead times and multi-region coordination. A small access provider may need addresses immediately for a launch. Applying one grace period to both would be arbitrary.
The category can also expose financing friction. A lender may require registry recognition before releasing funds for equipment. The buyer may therefore close the address acquisition first and build the network second. Silence during that interval is not proof that the acquisition lacked purpose; it may be a consequence of the financing sequence.
Good data would let the market compare promised horizon, actual activation and reasons for delay. It would not give a registry power to cancel an acquisition because a project slipped. Commercial failure belongs to the parties unless another legal claim is established.
Failed integration is evidence the transfer market should not erase
Completed-transfer statistics usually treat recognition as success. From a registry-service perspective, that is understandable. The record changed correctly. From an economic perspective, a buyer can still lose.
Failed integration occurs when the planned route, lease or customer deployment does not become sustainable. Address reputation may make mail or consumer services unusable. Geolocation providers may place the range in the wrong country. Upstream filters may reject announcements. A corporate acquisition may unravel. A major customer may cancel. Financing may disappear after closing.
Public signals can reveal part of the failure. A short-lived announcement followed by withdrawal, repeated origin invalidity, rapid changes in reverse DNS or a later resale can form a pattern. None proves the cause. Party interviews, broker records, support tickets and dated reputation checks may be needed.
The category matters because silence after transfer is otherwise interpreted as deliberate holding. That hides poor block quality and institutional friction. If a buyer tried and failed to route, the market needs to know which obstacles recur. Better diligence, geolocation correction, reputation appeals and upstream preparation can reduce those failures.
It also matters for price studies. A failed block may return to market at a discount. If researchers label the holding period as speculation, they miss the quality shock that caused the resale. They may then blame the buyer for an outcome created by hidden operational defects.
Failure data can remain confidential. Aggregate reporting can identify the proportion of contributed cases affected by reputation, routing acceptance, legal dispute, customer cancellation, integration cost or unknown cause. Contributors should disclose coverage so one broker's clientele is not presented as the whole market.
A mature capital market learns from failed deployment, not only completed paperwork. The registry need not guarantee commercial success. It should simply avoid describing recognition as proof that economic integration occurred.
Routed production needs a confidence ladder
Because every evidence source is partial, routed production should be graded rather than asserted as a single fact.
Level one: observed announcement. The exact prefix or a more specific appears at one or more named BGP collectors. Record the time, origin and vantage count. This is direct evidence of an announcement reaching those observers.
Level two: sustained propagation. The route remains visible across a stated share of days and multiple independent collectors or peers. Origin and prefix length are reasonably stable. This supports continued public routing.
Level three: authorization coherence. Relevant routes are covered by consistent RPKI origin authorization where the holder uses RPKI, with transition windows explained. This supports authorized origination, not traffic.
Level four: operational configuration. Reverse delegation, PTR patterns, IRR objects or other public configurations align with the observed operator. This supports intentional deployment.
Level five: service evidence. Ethical, limited data-plane observations or contributed operator records show active services, customers or traffic. This supports production.
The ladder prevents false equivalence. A prefix announced for an hour during a test should not count the same as a block visible for a year with coherent authorization and services. A block under a covering route may reach level four or five even without an exact route.
Confidence should also decline when evidence conflicts. A route from an unexpected origin without a matching ROA may be legitimate but unresolved. A stale RDAP contact weakens role attribution. A data-plane response from one address cannot establish use of the entire block.
Public reporting can show address-weighted and prefix-weighted results. Large aggregates otherwise dominate address counts, while fragmented /24s dominate prefix counts. Both views matter.
The purpose is not a universal certification label. It is a reproducible research method. Another analyst using the same observation set should be able to reach the same level, see the same limitations and challenge the inference.
The evidence matrix should preserve contradiction
A strong transfer study does not force every source to agree. Contradiction is often the most informative result.
Consider a recipient shown in RDAP, an unchanged seller-associated origin in BGP, a new ROA authorizing that origin and reverse DNS still under the seller's name servers. This can describe a transition service, leaseback, managed operation or incomplete handover. The evidence supports continuity and planned authorization. It does not identify the contract.
Now consider a new recipient, no exact route, active more specifics under several third-party origins, matching ROAs and customer-branded reverse names. This is consistent with leasing or customer assignments. Calling the aggregate unrouted would be wrong.
A third case may show a new recipient, a new ROA, an exact route for three days, repeated invalid more specifics, withdrawal and no later activity. That pattern supports attempted but unstable integration. It remains possible that operation continued outside collector visibility, so confidence should be stated.
The matrix should store each observation independently: registry event, RDAP state, exact route, more-specific coverage, covering route, origins, collector breadth, RPKI state, reverse delegation, PTR density, data-plane signal and contributed private evidence. The classification is derived from the matrix and can change when new evidence arrives.
Contradiction must not be "cleaned" by choosing an authoritative source for every question. RDAP is authoritative for the record it serves, not for BGP propagation. BGP collectors are direct witnesses to received routes, not to contracts. RPKI is authoritative only within its certificate and authorization chain, not for actual forwarding.
This architecture produces more uncertainty than a binary chart. It also produces more truth. Markets can tolerate unknowns when they are named. They become dangerous when an institution hides them behind one status word.
A cohort study can test the market without spying on operators
The empirical project is feasible with public data and voluntary confidential contributions. Begin with all published IPv4 transfer rows over a declared period. Reconcile rows into cases while retaining prefixes and event types. Exclude or separately report merger, temporary and corrective events where they cannot be compared with market acquisitions.
For each prefix, collect a pre-transfer baseline and post-transfer time series from both RIS and RouteViews where available. Measure exact routes, more-specific address coverage, covering routes, origin changes, visible days and observer breadth. Keep collector membership changes so an apparent visibility shift is not caused by a new peer.
Collect RPKI observations from dated validated payload archives, not only the current state. Record authorization changes and route-origin-validation status without treating "not found" as failure. Capture reverse-DNS delegation and sample PTR patterns at ethical density. Store RDAP snapshots with query times and response provenance.
Apply the seven-state classification at fixed horizons: for example 30, 90, 180 and 365 days, plus latest observation. The exact bands can be debated, but they must be declared before inspecting outcomes. Allow unresolved and mixed states.
Invite buyers, sellers, lessors, brokers and operators to contribute confidential event dates and purpose categories. Require contributors to identify their role, and deduplicate the same case reported by several parties. Publish the share of public cases covered by private contributions.
The outputs should be descriptive before causal. What share became observably routed? How long to sustained visibility? How much remained covered by an aggregate? How often did origins change? Which cases show coherent leasing signals? How many attempted deployments failed? How many remain unknown?
No individual prefix needs to be publicly accused or rated. Aggregate cells can be suppressed when contributor counts are small. Researchers can publish methods, coverage and uncertainty while protecting contracts and network security.
This is market intelligence rather than surveillance: measure institutional and operational outcomes at the level necessary to understand the system, not to expose customer topology.
Registries should publish better event evidence, not police subsequent use
RIRs control facts that route collectors cannot supply: case type, record-update time, directed inter-RIR path, corrections and whether several rows belong to one administrative case. Publishing those facts consistently would improve analysis without exposing price or customer information.
The common transfer log should carry a stable case identifier or privacy-preserving case linkage so one bargain split across prefixes is not counted many times. It should distinguish policy transfer, merger, temporary change, correction and other recognized event types. It should preserve revisions rather than silently replacing rows.
Each institution could also publish machine-readable timestamps for acceptance, completion and public-record update, with definitions. None of this requires disclosure of a buyer's internal utilization plan.
What registries should not do is use post-transfer telemetry as a new approval power. A route absence alert can help a holder catch an integration problem. It should not trigger cancellation merely because the institution prefers immediate routing. A route-origin mismatch can prompt a security notice. It should not be treated as proof of leasing or unauthorized control.
The difference is purpose. Evidence can improve record accuracy, security and service quality. It becomes dangerous when an administrator claims that public visibility gives it authority over commercial purpose.
RFC 7020's separation remains a sound boundary. Registration systems preserve uniqueness and accurate records. Operators decide whether and how to announce routes. Markets, contracts and courts address commercial rights and disputes. Security systems can validate authorization without owning the investment decision.
A registry that publishes precise transfer evidence will become more trusted, not less. It can say exactly what it did and leave other institutions to prove the facts within their competence.
Market entities can turn visibility limits into priced diligence
Buyers already care about route history because it affects integration. A disciplined evidence report can make that concern comparable.
The report should show historical origins, exact and covering announcements, periods of silence, known more specifics, RPKI history, reverse-DNS authority, RDAP history, transfer events, reputation observations and unresolved conflicts. Every field needs a timestamp and source. Absence must name the observation scope.
The report should not certify "unused." It can say "no exact or more-specific route observed at the listed RIS and RouteViews peers during the stated interval." That sentence is longer and far more valuable. It lets the buyer understand what was tested and what remains unknown.
The same evidence can support sellers. A holder can demonstrate a clean withdrawal period, coherent authority state and the absence of conflicting registration. A lessor can show that a prior customer route ended. A buyer can preserve the report as a baseline for later disputes.
Pricing can then reflect actual risk components. Persistent historical hijacks may reduce value. Fragmentation and route-filter acceptance may raise integration cost. A long, clean silent period may be positive for reputation but says nothing certain about title. Existing ROAs can be assets or transition hazards depending on control and timing.
Evidence portability matters. If the report exists only inside one broker's private system, the party must repurchase its own history at the next transaction. A signed, exportable record lets the holder carry observations between providers and challenge errors.
The market does not need a single score. Composite ratings conceal trade-offs. It needs dated facts and explicit inferences. One buyer may value a long unrouted history; another may prefer a block with proven global propagation. A neutral report enables both choices without deciding which business deserves the resource.
NRS can host a portable evidence standard without becoming a use tribunal
Number Resource Society can make a constructive contribution by defining an open transfer-evidence record. The record would not determine price, approve purpose or decide whether holding is virtuous. It would preserve observations and their limits.
At minimum, the record could link a recognized transfer receipt to dated RDAP responses, BGP visibility summaries, RPKI changes, reverse-DNS delegation and voluntary private attestations. Each observation would identify its collector, query source, time range, method and confidence. Derived states would be versioned so later evidence does not erase earlier reasoning.
The holder should be able to export the record and move it to another service provider. Researchers should be able to implement the public method independently. Competing analysts may disagree about interpretation while agreeing on the underlying observations.
Confidential evidence can be represented by a verifiable statement that an authorized reviewer inspected a dated document supporting reserve, lease or committed future use. The statement need not reveal customer, price, term or network design. Participation should be voluntary; refusal should leave the state unknown, not create a negative presumption.
NRS should also publish coverage. A BGP summary must identify which collector families and peers were used. A reverse-DNS report must state sample density. An RPKI statement must identify the observation time. Portability without provenance would only make weak claims travel faster.
This is a narrow institutional role with high practical value. It reduces repeated diligence, makes state transitions comparable and preserves evidence when a broker, registry or platform changes. It does not place NRS above the operator.
The positive test is simple: can a holder leave the evidence service with a complete, verifiable copy and continue operating? If yes, the service supports the market. If leaving causes the evidence to lose validity or the addresses to lose recognition, the service has become another gatekeeper.
The visibility limit must appear in every conclusion
There is no global camera above BGP. RIS and RouteViews observe routes received from participating peers. Their breadth makes them indispensable, but not omniscient. Peer composition changes. Export policy hides paths. Aggregation hides transfer boundaries. Private interconnection and restricted services may remain invisible.
There is no complete RPKI census of use. A ROA is authorization. It may precede, outlive or never accompany a route. "Not found" is not "unused." Invalidity can reflect an integration error rather than unauthorized operation.
There is no complete reverse-DNS census of occupancy. Names can be absent from active addresses, present on inactive addresses, delegated at different boundaries or retained through a transition.
There is no registration response that lists every economic role. RDAP can provide authoritative registration data while omitting a lease, customer operation or beneficial relationship. Public contact and status fields are constrained by policy and privacy.
Even private evidence has selection bias. Entities with successful deployments may contribute more readily than failed buyers. Brokers see selected transactions. Large operators keep better records than small ones. Every aggregate estimate should publish coverage and contributor composition.
These limits do not make research impossible. They define the claims the evidence can support. "Observed sustained routing" is defensible. "No route observed at these vantage points" is defensible. "The buyer never used the block" is usually not.
The discipline should survive headlines. A dramatic finding about silent transferred space will attract attention. The methodological sentence must not disappear from the public summary. If the uncertainty is too important for the footnote, it belongs in the conclusion.
The deal that never routed may still have changed the network economy
A registry-recognized transfer is important. It changes the recorded relationship around a scarce operational input. It can unlock financing, settle an acquisition, enable a lease, create reserve capacity or begin a migration. It can also leave a buyer with a block that never works as intended.
Routing evidence is equally important. BGP can show whether announcements appeared, how origins changed and how widely routes propagated among observed peers. RPKI can show authorization. Reverse DNS can show configuration. RDAP can show registration. None should impersonate the others.
The market needs the seven states because silence has causes. Holding, leasing, reserve, renumbering, future use, failed integration and routed production differ economically and institutionally. Some are visible. Some can be verified only privately. Some remain unknown.
The central prohibition is therefore analytical, not commercial: do not convert "not observed" into "speculative" without evidence of motive and harm. Scarcity creates incentives, but it does not repeal the rules of inference.
A better transfer market would preserve the registry event, collect operational observations over time, publish coverage, protect confidential terms and allow evidence to travel with the holder. Registries would remain accurate recordkeepers. Operators would remain responsible for routes. Researchers would state uncertainty. Buyers would price integration risk rather than rely on folklore.
The deal that closed but never routed is not a contradiction. It is a reminder that an IPv4 transfer can be a legal event, an institutional event, an operating project and an investment at different times. The evidence becomes useful only when those times and roles are kept separate.
Sources
- RFC 7020, The Internet Numbers Registry System - registration accuracy, uniqueness and the explicit separation of route announcement from registry-system scope.
- ARIN, NRO Transfer Log Format - the common cumulative transfer-log structure used to compare recognized intra- and inter-RIR events.
- APNIC, Transfer Log Format - historical public transfer fields, integrity files, retention and the administrative meaning of the transfer date.
- RIPE NCC, Transfer Statistics - published transfer fields and distinctions among policy transfers, business-structure changes, permanent cases and temporary cases.
- RFC 4271, A Border Gateway Protocol 4 - route exchange, local policy, RIBs, announcements and withdrawals.
- RIPE NCC, Routing Information Service - collector architecture, volunteer BGP peers, RIB and UPDATE archives and the observation boundary.
- RouteViews API Documentation - collector, peer, RIB and archive interfaces used for a second family of public BGP observations.
- RFC 6480, An Infrastructure to Support Secure Internet Routing - the distinction between resource allocation information and explicit route-origin authorization.
- RFC 6811, BGP Prefix Origin Validation - validation states, local routing policy, cache timing and the limitation to origin rather than full-path validation.
- RFC 7480, HTTP Usage in RDAP, RFC 9082, RDAP Query Format, and RFC 7484, Finding the Authoritative RDAP Service - structured access to authoritative registration responses and the limits of what those responses establish.
- RFC 2317, Classless IN-ADDR.ARPA Delegation - reverse-DNS delegation below /24 boundaries and why reverse naming does not map mechanically to transfer rows.
- Livadariu, Elmokashfi and Dhamdhere, On IPv4 Transfer Markets - independent comparison of reported transfers and routing-based inference, used with its stated assumptions and visibility limits.

