Summary

  • Public registry and routing-data systems identify AS210837 as the relevant autonomous-system identifier for investigating ROYA, but the available package contains no fresh timestamped prefix, path, neighbour, reachability or upstream result.
  • The accountability question is therefore not whether ROYA is inactive. It is whether the operator can demonstrate a continuously observable network, controlled routing dependencies and repeatable recovery evidence rather than relying on a registry record that may outlast operations.

The question behind the ASN

An autonomous-system number is a useful investigative handle. It gives researchers a stable reference around which to compare registry data, routing observations and operational claims. The RIPE Database aut-num interface is the primary candidate for checking the administrative association, status, maintainers and any declared import or export policy for AS210837. RIPEstat supplies candidate views of announced prefixes, routing status, neighbouring autonomous systems, BGP state, routing history and first- and last-seen observations.

Those sources are relevant because they can connect an administrative identifier to time-stamped network behaviour.

But the distinction between an identifier and an operating network is the centre of this case. A registry record can remain active while announcements change, disappear or become visible only from selected collectors. A declared routing policy is not the same as an observed AS path. An observed adjacency is not automatically a contract, a peering agreement or proof of organizational control. And a route visible to one measurement system is not proof of universal reachability or customer service.

The available evidence package therefore supports a narrow starting point: public registry and routing-data sources identify AS210837 as the relevant identifier for investigating ROYA’s network identity. It does not provide a fresh live response value for the current state of that record. The result is an evidence boundary, not a finding of abandonment.

What the available sources can establish

The relevant public source landscape is broad. RIPE Database and RIPEstat can test the holder record, declared policy, announced prefixes, routing state, neighbours and historical visibility. The candidate endpoints include the RIPE aut-num record at the RIPE Database, the RIPEstat AS overview, announced-prefixes data, routing status, ASN neighbours, BGP state, routing history and first- and last-seen data.

Other services provide possible cross-checks rather than automatic confirmation. A profile at bgp.tools and the Hurricane Electric BGP Toolkit may show prefixes and adjacent networks. BGPView’s prefix endpoint and upstream endpoint may offer aggregated or inferred relationships. CAIDA AS Rank can contribute an inferred relationship view. Raw Route Views archives and RIPE RIS data are candidates for reproducible collector-level checks, while RIS Live can support event-level observation. PeeringDB may add network metadata if a record exists and is current.

Each source answers a different question, and none should be stretched beyond it. A prefix list can show that an observer sees routes originated by an ASN; it does not identify the customer using the route. A neighbouring ASN can be a candidate upstream, peer or downstream; path adjacency alone does not disclose the commercial relationship. A history endpoint can bound when an observer saw routes; it cannot prove the precise beginning or end of the operator’s real-world activity. A PeeringDB record can describe a network’s self-reported presence; it does not substitute for current routing or service evidence.

What was not established in this investigation

A live refresh was attempted specifically to obtain current values for AS210837: announced status, prefix counts, observed AS paths, neighbours, upstreams, routing history, PeeringDB metadata and corroboration from independent collectors. The refresh reported that no web-search or HTTP-fetch capability was available in the runtime. It returned no current observations and stated that live values could not be retrieved or verified without fabrication.

That limitation has three consequences.

First, this article does not say that AS210837 currently announces no prefixes. No such result was captured. Second, it does not say that ROYA has stopped operating, because a missing retrieval is not evidence of cessation. Third, it does not treat the persistence of the registry association as proof that the network remains operational. The honest conclusion is narrower: the supplied public-source package defines a test for current operation, but does not itself contain the timestamped measurements needed to complete that test.

The gap matters because prior coverage already established the difference between administrative identity and operational proof. The additional question here is how to turn that distinction into a continuity and accountability framework: who should detect a mismatch, what should be preserved during an incident, and what observations would demonstrate that a repair lasted.

The control chain: prevention, detection and response

The first control is prevention. An operator associated with an ASN should maintain accurate registry, routing-policy, address-resource, RPKI and contact records. Those records reduce ambiguity when a route changes or disappears. They also make it possible for an upstream, registry or incident responder to reach the responsible party. Yet accurate records prevent confusion; they do not prove that a service is being delivered.

The second control is detection. A serious continuity process would monitor announcements, withdrawals, path changes, reachability and mismatches between registry state and observed routing. It would use multiple collectors because any one vantage point has blind spots. It would preserve timestamps, prefixes, origin observations, AS paths and the collector context. It would distinguish a route absent from one feed from a route absent across independent views.

The third control is response. If AS210837 experienced a withdrawal or path change, a useful incident record would correlate the routing event with operator records, upstream notifications, change approvals, restoration actions and the time at which independent observers saw the route return. Without that timeline, a later announcement cannot show whether the underlying cause was repaired, bypassed or simply no longer visible from the original vantage point.

The final control is durable repair. A route returning once is not enough. A durable assessment would require repeated post-event observations across independent collectors, stable prefix and path behaviour, current contactability and some corroborating operational or service evidence. It would also test whether the same dependency remains a single point of failure. Continued registry presence alone is insufficient.

These controls assign responsibility without inventing an incident. The public material supplied for this article contains no evidence of a specific outage, customer impact, contractual dispute or recovery event involving ROYA. The framework identifies what an operator, upstream, registry researcher or affected party would need to preserve and compare if continuity became contested.

Dependency is not the same as adjacency

The most tempting shortcut is to read the AS immediately before AS210837 in a path as ROYA’s upstream provider. That may be a reasonable candidate for investigation, but it is not a proven commercial relationship. An AS path can reflect transit, peering, route-server behaviour, a downstream relationship, path prepending or other routing policy. Inferred relationship databases can disagree, and selective announcements can make a backup provider appear absent.

A defensible dependency assessment would therefore require recurrence. The same adjacent ASN should be observed across multiple timestamps, collectors and relevant prefixes, with the direction of the path understood. The result should then be compared with declared policy, network metadata and, where available, operator or provider statements. Even after that work, the public evidence may establish technical dependence without establishing contractual terms or who controls the endpoint.

This distinction is central to continuity risk. A network with one repeatedly observed path may be more exposed to a provider failure than a network with diverse paths, but the public data would still need to show the relevant routes and time period. A list of possible upstreams is not a resilience assessment. Nor is a public listing.

What would change the assessment?

The assessment would materially change if a fresh, timestamped RIPEstat response showed AS210837’s announced prefixes and routing status, and if those results were corroborated by an independent collector or raw RIB. A stable set of originated prefixes observed repeatedly over time would support a current, publicly visible operating footprint. It would still not prove customer traffic, commercial value or the identity of every party controlling the infrastructure.

The assessment would also change if repeated AS paths identified one or more recurring external dependencies. That would support a technical dependency map, subject to the distinction between adjacency and contract. A documented change in those paths, combined with a dated incident or restoration timeline, could support an analysis of prevention, detection and response.

The strongest repair evidence would combine several layers: repeated route visibility after the event; stable origin and path behaviour; corroboration from more than one measurement system; current, working operational contacts; and independent evidence that the relevant service or network function remained available. If those layers conflict, the conflict itself should be reported rather than smoothed into a single conclusion.

The reverse result would also be informative. If multiple independent, timestamped collectors showed no current announcements while historical data showed earlier visibility, that would support a finding of an observed routing lapse. It would not, without more evidence, prove that ROYA had ceased all network activity. The conclusion would need to specify the collectors, time window and limits of the observation.

An evidence boundary is an operational finding

The public association between ROYA and AS210837 is not meaningless. It identifies a network resource and creates a path for testing control, visibility and continuity. But the burden of proof changes as the claim changes. Administrative association may be enough to identify the subject of an investigation. It is not enough to establish current operation. Current route origination is not enough to establish customer dependence. A recurring path is not enough to establish a contract. A restored route is not enough to establish durable repair.

The immediate accountability issue is therefore not a claim that ROYA has failed. It is whether the operator’s public evidence is sufficient for others to distinguish a live, controlled network from a registry identity whose operational status remains unresolved. In the supplied record, it is not yet sufficient. The decisive next step is not rhetorical confidence but a timestamped, reproducible, cross-collector observation package.

Until that package exists, AS210837 should be treated as an investigative lead with an unresolved continuity status. That conclusion is deliberately bounded. It protects against the two symmetrical errors that routinely distort infrastructure reporting: turning a registry record into proof of service, or turning an unavailable live lookup into proof that service has ended.

For the public company context associated with this investigation, see ROYA Communications and Internet Services Company Ltd.