Summary

  • Public registry records can establish an administrative association between ROYA and AS210837, but they cannot by themselves prove current route announcements, customer service, reachability or operational control.
  • A defensible continuity finding would require timestamped evidence that connects registration, observed announcements, reachability, dependencies, operational decisions and repeated recovery—not a single green status or a stale route object.

The first discipline in examining AS210837 is to separate four questions that are often collapsed into one.

The first is identity: which organisation is associated with the autonomous system in the relevant registry records? The second is control-plane activity: are routes being announced, withdrawn or changed in ways that independent collectors can observe? The third is service reality: can those routes be reached, and do they correspond to a functioning service rather than a control-plane advertisement? The fourth is resilience: when a route or service is interrupted, can the operator detect the problem, restore service and demonstrate that the repair is repeatable?

Those questions overlap, but none answers the others. A registry can answer an administrative question while leaving the operational questions open. An observed route can show visibility while leaving customer traffic and internal control uncertain. A valid RPKI result can authorise a prefix-origin pair without proving that an upstream rejects invalid routes or that the underlying service is available. A restored announcement can show control-plane recovery without proving that users could reach the network during the interval or that the cause of the failure was removed.

That distinction is especially important here because the public research material reviewed for this article identifies authoritative sources but did not retrieve their current responses. The responsible conclusion is therefore bounded: the sources define a rigorous verification method; they do not support current claims about AS210837’s prefixes, neighbours, upstreams, ROAs or continuity events.

1. The registry establishes an identity trail, not a live network

The RIPE Database aut-num record and RIPE RDAP record are the natural starting points. The aut-num object can record an ASN’s status, organisation references, maintainers, administrative contacts and declared routing policy. RDAP can corroborate the handle, linked entities, notices and registration events. Together, these records can establish how AS210837 is represented administratively and what information the registry exposes at the time of retrieval.

That is meaningful evidence, but it is evidence of a different kind from a live route. A created or last-modified date describes an object’s history. It does not describe uptime. An organisation reference identifies a registered relationship. It does not prove that the named organisation controls every router, BGP session, address block or operational decision associated with the ASN today. A registry status such as ASSIGNED, if confirmed in a current response, would still be an administrative status rather than a service-level assertion.

The same caution applies to the Internet Routing Registry. RIPE route and route6 objects can express a declared origin for a prefix. They may help an operator generate filters or investigate whether the registry contains an expected object. But an IRR object is a declaration of routing intent. It is not proof that a BGP session is active, that a route is visible from outside the declaring network or that the route has a matching cryptographic authorisation.

The practical control question is therefore: who maintains the records, who can change them, and how are those declarations checked against independent observations? A mature process would compare the current RIPE aut-num and RDAP records, inspect the relevant IRR objects, record retrieval times and then compare each declared prefix and neighbour with observed routing data. A mismatch should not immediately be labelled misconduct or failure. It may reflect stale registry data, incomplete route objects, collector coverage, a changed relationship or a difference in observation time.

But the mismatch is a detection signal that deserves resolution.

2. Observed BGP activity tests visibility, not the whole service

RIPEstat’s announced-prefixes, BGP-state, ASN-neighbours, BGP-updates and routing-history services provide different views of the control plane. The announced-prefixes view can identify prefixes that RIPE RIS attributes to AS210837. BGP-state can expose collector-observed prefixes and AS paths. The neighbours view can show adjacent ASNs and observation counts. Updates and routing history can support a time-bounded account of announcements, withdrawals, disappearances and reappearances. BGPlay can help visualise path changes over a selected interval.

These observations are useful precisely because they are independent of a registry declaration. They can show that a route was visible to a particular set of collectors at a particular time. They can help investigators identify a withdrawal, a new origin, a path change or a period in which visibility changed. They can also provide a basis for testing whether an operator’s declared policy resembles what the wider routing system observed.

But route-collector evidence has boundaries. A prefix absent from one result may still be visible from another vantage point. A route observed by a collector is not automatically reachable from every network. An AS immediately preceding AS210837 in a path is evidence of an observed adjacency on that path; it is not conclusive proof of a paid transit contract. An inferred upstream or peer relationship is a useful hypothesis, not a contract, and may be classified differently by different services.

The distinction matters for accountability. If an operator claims that a route was continuously available, an investigator should ask: continuously visible to which collectors, for which prefix, over what interval and with what path changes? If a route disappeared, the next question is not simply who is to blame. It is whether the event is corroborated, whether the same interval shows a withdrawal or path change elsewhere, whether a data-plane signal changed, and whether the operator had a detection and escalation mechanism capable of seeing it.

A defensible timeline would record the exact prefix, origin, observation window, collectors used, first observed withdrawal, first observed reannouncement and any material path changes. It would keep control-plane and data-plane conclusions separate. A stable BGP announcement can coexist with a broken service. A restored announcement can coexist with an unreachable customer network. Conversely, a collector gap can resemble an outage even when another vantage point continued to see the route.

3. Reachability is a separate test from route announcement

IODA and Cloudflare Radar are candidate sources for comparing externally observed routing and reachability signals. Their value is not that any single dashboard can settle the question. Their value is that different measurement systems can reveal whether a control-plane change coincided with an externally visible impact.

Even then, reachability should be stated narrowly. A measurement from one probe, resolver, country or network does not establish universal reachability. An outage signal may indicate a change in network behaviour without identifying its cause. The absence of an outage signal does not prove that all customers, internal systems or services remained healthy.

For ROYA’s AS210837, the relevant question is whether multiple dated observations converge. A credible continuity finding would ideally pair route visibility with measurements from more than one independent vantage point, identify the affected prefix or service, and show whether the condition persisted, recovered or varied by location. It would also distinguish reachability of an address from availability of the service delivered through that address.

That distinction is not a technicality. Network operators often depend on several layers: address resources, origin authorisation, BGP sessions, upstream or peer connectivity, edge equipment, internal transport, DNS, power and local access. A route can remain visible while one of those layers fails. A route can disappear because of a control-plane decision while the underlying equipment remains available. Without evidence that connects the layers, a public observer should not convert a route graph into a complete service narrative.

4. RPKI strengthens origin control, but does not prove resilience

RPKI is often described too broadly. Its relevant unit is the prefix-origin pair. As specified in RFC 6482, a Route Origin Authorization can say that a particular autonomous system is authorised to originate a prefix, subject to the authorised maximum length. The origin-validation procedure described in RFC 6811 classifies an observed route as Valid, Invalid or NotFound according to the covering VRPs and the origin presented.

That is an important preventive control. It can reduce the risk that a route with an unauthorised origin is accepted by networks that perform route-origin validation. It can also help an investigator compare the routes an operator intends to originate with the routes observed in BGP.

But a Valid result is not a certificate for the entire path. It does not authenticate every AS in the path, prove that all upstreams enforce rejection of invalid routes, or establish that the service behind the prefix is available. A NotFound result does not by itself prove that a route is unauthorised; it may mean that no covering VRP was available to the validator. An Invalid result needs to be interpreted with the exact prefix, origin, covering ROA and retrieval time.

The RIPEstat RPKI history and Cloudflare RPKI explorer are candidate sources for checking origin authorisation; their current responses were not retrieved here. The correct question for AS210837 is therefore not “does the ASN have RPKI?” in the abstract. It is: for each observed prefix-origin pair, what was the validation state at the relevant time, which ROA covered it, what maximum length applied, and what evidence shows that receiving networks enforced the result? A route-origin control can prevent one class of error while leaving route leaks, path manipulation, equipment failure, upstream loss and data-plane outages unresolved.

This is also where prevention and detection meet. RPKI can support preventive filtering, but an operator still needs monitoring that detects unexpected origins, invalid states, withdrawals, path changes and service impairment. The existence of a preventive mechanism does not prove that someone watched its output or acted when conditions changed.

5. Peering and upstream data describes dependency hypotheses

PeeringDB can provide operator-maintained information about a network name, policy, facilities, Internet exchanges and contact roles when a matching record exists. Its presence can reveal what an operator chooses to publish. Its absence can establish only that no matching public record was found at retrieval time. Neither outcome proves the existence or absence of active sessions, private transit, customer links or backup paths.

BGPView’s prefix, upstream and peer views, alongside bgp.tools and CAIDA AS Rank, are candidate sources for comparing observed prefixes and inferred relationships. These are valuable for comparison, especially when they expose differences between registry declarations and observed routing. But labels such as “upstream” or “peer” should not be rewritten as commercial facts without supporting evidence. A route server, reseller, backup provider or private interconnection can produce an observed path that is not equivalent to a conventional transit contract.

For continuity analysis, dependency mapping matters more than a simple list of adjacent ASNs. The key questions are: which connections appear necessary for reachability; how many independent alternatives are visible; which dependencies are shared; who can change the relevant route policy; and what evidence shows that failover has been tested rather than merely described?

Public routing data cannot answer all of those questions. It can identify candidate control points and dependencies. It cannot reveal contractual terms, internal topology, staffing, maintenance procedures or the operator’s actual authority over a third party’s equipment. A responsible article should therefore describe a relationship as observed, inferred, declared or unverified, rather than flattening all four categories into “upstream.”

6. What would demonstrate prevention, detection and repair?

The investigation becomes more useful when it turns the evidence chain into a control model.

Prevention concerns the measures intended to stop an avoidable routing or service failure. Relevant public evidence could include current IRR objects, correctly scoped ROAs, consistent route filters and a declared policy that matches observed operations. None of these alone proves that the control is enforced. The strongest public case would connect the configuration to an observed result: an unauthorised origin rejected by relevant networks, or a route announcement constrained to the authorised prefix and origin.

Detection concerns whether the operator or independent observers could identify a harmful change. Candidate signals include BGP withdrawals, unexpected origin changes, invalid RPKI states, path instability and external reachability loss. A single alert is not proof of an effective detection process. Evidence of detection requires timing: when the condition began, when it was observed, when it was acknowledged and whether the response corresponded to the affected dependency.

Response concerns the decision that follows detection. Public routing data may show a withdrawal, reannouncement or path change, but usually cannot identify who made the decision or why. Attribution requires named operational records, incident notices, regulator or court material, or another source that directly connects an action to an accountable actor. In the absence of that evidence, the article should describe the event and leave responsibility open.

Repair concerns more than restoration of a green dashboard. A durable repair would be supported by repeated observations after the change, consistent route-origin authorisation, stable or intentionally managed paths, restored reachability from multiple vantage points and evidence that the underlying dependency was addressed. A recurrence of the same failure mechanism would weigh against a claim of durable repair, even if the route returned temporarily. If only the route returned but service remained unavailable, the control-plane repair was incomplete.

This framework avoids two opposite errors. It does not treat every gap in public data as proof of operational failure. Nor does it treat a current-looking registry object or a single route observation as proof that the system is healthy and controlled. It asks what each source can establish, what remains unknown and what additional evidence would close the gap.

7. The bounded conclusion for AS210837

The public evidence assembled for this review supports a method, not a current operational verdict. RIPE Database and RDAP are appropriate sources for the administrative representation of AS210837. IRR objects can test declared routing intent. RIPEstat and other collectors can test observed announcements, paths, neighbours and time-bounded changes. RPKI services can test route-origin authorisation per prefix-origin pair. PeeringDB and relationship databases can identify published or inferred dependencies. IODA and other measurement systems can help test whether control-plane events coincided with external impact.

But the current research record did not retrieve the live responses from those endpoints. Current prefixes, ROA states, AS paths, relationship classifications, reachability and continuity events therefore remain unverified in this review. It would be inaccurate to say that AS210837 is currently active, inactive, resilient, abandoned, reachable or failing on the basis of the source list alone. It would be equally inaccurate to assign operational blame to ROYA without evidence of a specific decision, control failure or duty.

The useful finding is narrower and more demanding: a registered identity is the first link in an evidence chain, not the chain itself. To establish operational control, an investigator must connect the identity to observed routing, then connect routing to reachability, dependencies, decisions and repeated recovery. Each link needs a timestamp and an appropriate source. Each source must be used within its limits.

For ROYA and AS210837, the next responsible step is a fresh, time-stamped retrieval of the registry, routing, RPKI, peering and reachability records, followed by comparison across independent measurement systems. Until that is done, the strongest conclusion is not that the network works or does not work. It is that the public record has identified the questions that a durable continuity claim would have to answer.

Sources and evidence boundaries

The sources above are authoritative or technically relevant for the questions described, but the current responses were not retrieved for this review. No present-day prefix count, route state, ROA result, neighbour list, commercial relationship, reachability condition or continuity event should be inferred merely from the existence of these URLs.