Summary

  • Public records provide an administrative starting point for examining ROYA and AS210837, but the research package contains no defined-UTC live response from which current prefixes, announcements, paths, peers, reachability or resilience can safely be stated.
  • A credible operating-footprint assessment requires a chain: registry identity, declared routing intent, timestamped observations from independent collectors, reachability checks, attributed control and repeated evidence of detection and recovery.

ROYA Communications and Internet Services Company Ltd appears in the public record through the autonomous-system identifier AS210837. That association matters because an autonomous system is a handle through which routing activity can be investigated. It does not, by itself, answer the operational questions that follow: Is the system originating routes now? Are those routes reachable from more than one vantage point? Which networks appear adjacent to it? Are those adjacencies commercial dependencies, private arrangements or merely path observations? Who can change the routing policy?

What would show that an interruption was detected and repaired rather than simply disappearing from view?

Those questions are deliberately narrower than a claim that ROYA is active or inactive. The evidence assembled for this investigation maps the sources needed to answer them but does not preserve a timestamped live payload from the relevant endpoints. Exact current prefixes, announcements, upstreams, peers, reachability and resilience therefore remain unresolved. The absence of a captured response is not evidence that AS210837 has stopped operating.

The first link: administrative identity

The RIPE Database aut-num object is the primary place to examine the registered AS name, organisation handle, contacts, maintainer, status and creation or modification fields associated with AS210837. The RIPE delegated statistics provide a separate resource-allocation view, including the responsible registry, country attribution, delegation timing and status. Together, these sources can establish how the number is represented administratively, but administrative identity is not a measurement of live traffic or current control.

The RIPE Database aut-num record for AS210837 is the appropriate starting point for the registered AS object. The latest RIPE delegated statistics can help separate the history of resource delegation from later routing observations. Those statistics should be read as registry data, not as a service map. A country code or registered address may describe the resource record while saying little about where routers, customers or services are physically located.

This distinction is especially important for a company whose public description can invite a geographic conclusion. A registry association with Iraq may be relevant context, but it cannot alone establish a complete Iraqi service footprint, a customer base in every locality or the location of the equipment carrying traffic. IP metadata, PeeringDB disclosures and RIPE Atlas probe locations can add clues, yet each describes a particular dataset or self-reported observation rather than the whole operating surface. The IPinfo ASN view is one possible metadata comparison. RIPE Atlas probe data can show measurement infrastructure associated with an ASN, but probe presence is not proof of customer coverage.

The second link: declared routing intent

An inverse-origin search in the RIPE Database can identify route and route6 objects whose declared origin is AS210837. This is useful because it shows what an operator or resource holder has registered as an intended routing relationship. It is not the same as seeing the prefix in BGP.

The RIPE inverse-origin search is the relevant source for registered route and route6 objects. A route object can remain after an announcement is withdrawn, become stale, or coexist with an announcement that is visible through another registry. Conversely, a route can be observed in BGP without the same object appearing in the particular IRR source being queried. The comparison between declaration and observation is therefore more informative than either dataset in isolation.

A disciplined investigation would create two separate inventories. The first would list every route object and its dates, origin and relevant maintainer fields. The second would list prefixes actually observed during a defined UTC window. Matching entries would support a limited statement: a declared routing object and an observation were consistent at that time. Mismatches would create questions about stale registration, route filtering, another IRR source, a changed origin or a transient announcement. None of these outcomes alone proves who operates the underlying equipment.

The third link: observed routing activity

RIPEstat provides several measurement views that can test whether AS210837 is visible in the routing system. The AS Overview endpoint can connect a holder label and registry information with an indication of observed announcement state. The RIPEstat AS Overview endpoint is designed for that bridge between registry context and routing visibility. The Announced Prefixes endpoint can provide a time-sensitive list of IPv4 and IPv6 prefixes observed with AS210837 as origin. That endpoint is the relevant candidate for a timestamped prefix inventory. The Routing Status endpoint can add visibility and first-seen or last-seen context. Its results should be interpreted as observations from the underlying measurement system, not as a permanent property of the ASN.

The critical missing ingredient in this run is not a theory of what these endpoints can do. It is a retained response tied to a defined UTC retrieval time. BGP changes quickly. A result that says “announced” at one moment does not establish uninterrupted operation, and a result with no currently visible prefix does not establish that an operator has ceased service. Collector placement, route filtering, aggregation and update timing all shape what becomes visible.

Independent confirmation is therefore part of the evidence standard. Raw RIPE RIS data and Route Views archives can be processed to reconstruct announcements, withdrawals, origins and AS paths over a chosen interval. The RIPE RIS archive provides raw routing observations for that kind of reconstruction. The Route Views archive supplies a separate collector system against which those observations can be compared. Agreement across collectors and across time would strengthen a claim about recurring visibility. Disagreement would not automatically disprove activity; it would define the limits of the observation.

Third-party summaries are useful for triangulation but should not be mistaken for a single authoritative live view. BGP.Tools presents a convenient routing profile for comparison with collector-backed data. The Hurricane Electric BGP Toolkit offers another profile of prefixes and path relationships. BGPView can provide a separate prefix inventory. These services may refresh at different times and use different collection and presentation methods. Their value lies in convergence, divergence and reproducibility, not in treating one displayed number as the complete network state.

The fourth link: dependencies without overclaiming

An ASN’s visible neighbours can indicate how announcements travel through the network. They cannot, without additional evidence, tell readers whether a relationship is paid transit, settlement-free peering, a customer-provider arrangement, a route-server path or an incidental adjacency.

RIPEstat ASN-neighbour data can identify observed path adjacencies and their frequency. BGPView separately offers upstream and peer classifications. Its upstream endpoint can be used as a dependency hypothesis, not as a contract record. Its peer endpoint can identify classified relationships or adjacencies for comparison. CAIDA ASRank can provide another algorithmic topology view. That view is useful for testing whether a relationship inference persists across datasets, while remaining an inference.

The practical distinction is between an observed path and a commercial relationship. If a route collector repeatedly sees AS210837 through a neighbouring ASN, the evidence supports a statement about path visibility from that collector. It may suggest dependency, especially if many observed paths converge on one adjacent network. It does not establish a contract, paid transit, backup capacity or operational control. Those stronger claims require operator documentation, PeeringDB disclosure, contractual evidence or repeated technical observations combined with attributable action.

PeeringDB can help test what a network publicly discloses about facilities, exchanges, policy and presence. The PeeringDB network endpoint is a relevant source for those self-reported fields. A populated record would not prove every listed service is active. An absent or stale record would not prove that a facility, exchange or private interconnection does not exist. Public disclosure is evidence about what has been reported, not a complete inventory of the operating network.

For operators, this distinction changes how continuity is assessed. A single upstream inference may identify a concentration risk worth investigating, but it cannot quantify outage exposure. A route visible through two collectors may show broader observation, but it cannot show that customers have two independent physical paths. A peer listed in a database may be important to routing, but the label does not reveal whether the session is redundant, contractual, geographically diverse or operationally supervised.

The fifth link: reachability and service

Route visibility is not the same as reachability, and reachability is not the same as customer service. A prefix can be announced while a service endpoint is misconfigured. An address can respond from one vantage point while failing from another. A route can remain visible while the underlying service is unavailable. The evidence chain must therefore move from control-plane observation to data-plane tests and then to an attributable service or operating claim.

A future verification window should record the UTC time, collector, prefix, origin, AS path, visibility status and any withdrawal or path change. It should then test selected addresses or services from independent vantage points, recording protocol, destination, result and timing. The point is not to produce a false precision score. It is to distinguish what was observed from what was inferred.

The geographic question needs the same discipline. Registry country, IP geolocation, self-reported facilities and measurement probes can be compared, but a disagreement is not necessarily a contradiction. It may show that different datasets describe the registered holder, an address block, an observation point or a service location. IP metadata can contribute to that comparison but cannot establish the full physical footprint. PeeringDB can document disclosed interconnection locations without proving that every listed location carries customer traffic.

This is why the public directory entry should be read as an investigation anchor, not as a service guarantee. The directory record identifies the subject of this research and provides the canonical public reference for the entity. It does not substitute for routing measurements, reachability tests or evidence of operational decision-making.

The sixth link: control and resilience

Operational control is the hardest link because it cannot be inferred safely from a name in a registry. A stronger case would require convergent signals: organisation and contact records aligned with the ASN; routing policy or maintainer actions attributable to the operator; repeatable changes observed after a documented intervention; and evidence that someone can detect, diagnose and restore service.

A route announcement can show that a route was visible. It cannot show who pressed the relevant control, whether the action was authorised by ROYA, or whether a provider originated the route on another party’s instruction. A contact address can show where operational responsibility is publicly directed. It cannot prove that the contact remains staffed or that the named organisation controls every dependency. A PeeringDB record can reveal declared policy. It cannot prove that policy is enforced continuously.

Resilience requires a time series rather than a snapshot. Evidence of continuity would ideally include repeated observations from independent collectors, stable or explainable changes in prefixes and paths, data-plane reachability, and an incident or maintenance record showing detection, intervention and restoration. Evidence of recovery is stronger when the same service becomes observable again after a bounded interruption and when the operator’s account can be matched to the technical timeline.

Nothing in the current package supports a claim that ROYA is resilient, nor a claim that it is not. The RIPEstat routing-status view is a candidate source for time-sensitive visibility, but its current response was not retained here. RIS and Route Views archives could support a historical sequence if their records were processed for a defined interval. The available source set therefore defines a verification path rather than a conclusion about present continuity.

What this changes for investors and public-interest readers

For investors, the relevant risk is not simply whether an ASN appears in a database. It is whether a network asset can be connected to a verifiable operating surface: routes that are observed, services that are reachable, dependencies that are understood, and controls that can be exercised during failure. Without that chain, an ASN may be an important lead while remaining an unreliable proxy for revenue, customers, capacity or bargaining power.

For operators, the practical issue is evidence of continuity. A public registry can outlast an operating arrangement. A route can disappear temporarily. A third-party profile can lag an incident. A robust operating record would make these transitions legible through dated announcements, documented maintenance, redundant dependencies and recovery evidence. The absence of such public evidence does not prove poor operations; it limits what outside observers can responsibly conclude.

For public-interest infrastructure readers, the distinction protects against two symmetrical errors. The first is treating a registered ASN as proof of a functioning local network. The second is treating a missing current observation as proof that the operator has disappeared. Both claims exceed the available evidence. The more defensible conclusion is conditional: AS210837 is a registered object that warrants measurement, and the public evidence chain remains incomplete until current observations are captured, compared and tied to attributable operational action.

A reproducible test for the next observation window

A future assessment should preserve, at minimum, six linked records:

  1. The exact RIPE Database aut-num and organisation responses, with retrieval timestamps and relevant revision fields.
  2. The RIPE IRR route and route6 objects, separated from observed BGP announcements.
  3. Prefix and routing-status results from RIPEstat, with the UTC retrieval time and collector context.
  4. Raw or summarized observations from both RIPE RIS and Route Views, including AS paths, withdrawals and first- or last-seen context.
  5. Independent comparisons from BGP.Tools, Hurricane Electric, BGPView, CAIDA and PeeringDB, with their differing definitions clearly labeled.
  6. Data-plane reachability tests and any attributable operator evidence showing control, incident response or recovery.

That test would not produce certainty from one successful lookup. It would build a sequence in which each claim has a matching type of evidence. Registry data would answer who the record names. IRR data would answer what routing intent has been declared. Collectors would answer what was observed and when. Reachability tests would answer what could be reached from specified vantage points. Operator evidence would answer who acted. Repeated observations would answer whether the result persisted.

The central finding is therefore an evidence boundary, not an activity verdict. Public records associate ROYA Communications and Internet Services Company Ltd with AS210837. They provide a structured route for investigating declarations, announcements, dependencies, geography and control. This run did not retain a defined-UTC live payload that would justify stating the current prefix set, routing state, upstreams, peers, service reachability or recovery capacity. Until that evidence is collected and connected, the responsible description is neither “operating” nor “inactive,” but “administratively identified and operationally unresolved.”

Sources and verification boundaries

  • RIPE Database aut-num object: source
  • RIPE NCC delegated statistics: source
  • RIPE Database inverse-origin search: source
  • RIPEstat AS Overview: source
  • RIPEstat Announced Prefixes: source
  • RIPEstat Routing Status: source
  • RIPEstat ASN Neighbours: source
  • RIPE RIS archive: source
  • Route Views archive: source
  • BGP.Tools AS210837 profile: source
  • Hurricane Electric BGP Toolkit: source
  • BGPView prefixes: source
  • BGPView upstreams: source
  • BGPView peers: source
  • PeeringDB network record: source
  • CAIDA ASRank: source
  • IPinfo AS210837 metadata: source
  • RIPE Atlas probe query: source
  • BTW directory record: source