Summary
- RIPE’s Registration Data Access Protocol (RDAP) object records AS200427 and Proximity Data Centres Limited in an administrative ledger. Its
activestatus identifies the registry object; it does not establish routing, equipment or service health. - PeeringDB has one exact AS200427 row named
nLighten - IX ASN, not Proximity Data Centres Limited. The ASN joins the records, but this source set does not establish ownership, a rename, an acquisition or operational continuity between those labels. - A frozen RIPE Routing Information Service (RIS) response at 7 August 2026, 00:00 UTC reports zero qualifying visibility among 325 listed IPv4 peers and 320 listed IPv6 peers. Those product-, time- and collector-bounded zeroes do not prove an outage, universal route absence or service unreachability.
One number, three evidence layers
An autonomous system is a network, or group of networks, that presents a common routing policy to the wider internet. Its autonomous system number, usually shortened to ASN, is a unique identifier used when networks exchange reachability information through the Border Gateway Protocol, or BGP.
AS200427 is the stable join key across the records examined here. It connects the directory subject to an exact registry object, an exact PeeringDB row and a routing-status response for the same number. That makes the ASN more reliable than a name alone when a reader needs to distinguish one routing domain from similarly named companies or profiles.
The shared number does not make every field interchangeable. RDAP exposes administrative registry records. PeeringDB is a participant-maintained coordination directory. RIPE RIS gathers BGP information from observation points and publishes products derived from those views. Each source can be accurate within its own purpose while leaving another operational question unresolved.
This separation matters in routine due diligence and during an incident. A registry object can help a reader identify the recorded holder and contacts. A participant profile can show declarations that may support coordination. A collector snapshot can report what met a product’s method at a particular time. None of those records alone says whether an application worked, whether a route was authorised, whether two corporate labels describe a continuous organisation or whether a physical dependency was available.
RIPE RDAP is the administrative ledger
The RIPE RDAP response covers exactly autonomous-system number 200427. Its starting and ending numbers are both 200427, its handle is AS200427, and its object name is PROXIMITY-AS. The response records Proximity Data Centres Limited as the registrant entity and labels the object active.
It also records registration and last-changed events at 19 December 2022, 15:15:02 UTC. Those fields provide a reviewable administrative identity and event history. They are useful when an operator or investigator needs to confirm that a question is attached to the intended number resource rather than to a company with a similar name.
The word active belongs to the registry object. It is not router telemetry. It does not say that a BGP session is established, a route is visible, an announcement is authorised or a customer-facing system is reachable. A registry can preserve an accurate ledger entry while the state of running systems changes independently.
That boundary is a feature of responsible verification. Registries support uniqueness, accuracy and contactability for number resources. They should be read as ledgers, not as sovereign verdicts on the live network. When the question concerns running code or observed routing, the reader needs evidence designed for that layer.
PeeringDB introduces a label difference
The captured PeeringDB response contains one exact row for ASN 200427, record id 31834. The row is named nLighten - IX ASN. Its profile status is ok, its information type is Enterprise, its general policy is Selective, and its recorded update time is 28 March 2024, 13:05:57 UTC.
That label differs from Proximity Data Centres Limited, the name in the production Entity and RIPE RDAP registrant field. The exact ASN provides a technical join between the records. It does not independently establish why the labels differ. These four sources contain no adequate corporate evidence for an acquisition, rename, ownership chain or continuity of operations between them. A careful article therefore preserves both labels instead of silently treating one as an alias for the other.
The profile’s other fields need the same discipline. It declares zero IPv4 prefixes, zero IPv6 prefixes, an empty IRR AS-set and zero netixlan rows. It also supplies a participant-entered traffic band and website. PeeringDB records what a participant chose to publish; it does not continuously measure every route, session, exchange connection or unit of traffic.
Zero declared prefixes do not prove that the ASN originates no address space. Zero exchange-LAN rows do not prove absence from every exchange, route server, private interconnection or bilateral session. The Selective label is a declared general policy, not evidence that a particular session exists or has been refused. The traffic band is likewise a profile declaration, not an independently measured statement of current load or capacity.
The profile status ok describes the database row. It is not a health check for routers, links, equipment or services. Used within those limits, PeeringDB remains valuable: it tells a reader what public coordination data was present, which label was used and which questions still require authorised operational or corporate evidence.
The frozen RIPE RIS response has a narrow boundary
The routing-status response used for this article is frozen with a query time of 7 August 2026, 00:00 UTC. It reports zero of 325 listed IPv4 RIS peers seeing qualifying routes and zero of 320 listed IPv6 peers seeing qualifying routes. Its announced-space fields report zero IPv4 prefixes and addresses, zero IPv6 prefixes and /48 equivalents, and zero observed neighbours.
Those values describe one RIPE RIS product response, with its own query time, method and collector set. They do not prove that no route existed anywhere on the internet. A route could fall outside the product’s qualifying view, appear at vantage points not represented in the listed peer set or require a different observation method. The response also cannot prove that the network was down or that any named system or service was unreachable.
The zeroes do not resolve route authorisation. Collector visibility reports an observed origin relationship, not whether an address holder authorised it or whether a relevant route-origin authorisation existed. Nor do the zeroes reveal traffic, latency, capacity, topology, diversity, resilience, uptime or customer experience. Those questions require their own timestamp-aligned evidence.
The accurate conclusion is narrower: at the stated query time, this product returned no qualifying IPv4 or IPv6 visibility among the listed peer denominators. Preserving the denominators matters. “Zero routes” without the product, timestamp and observation scope would turn a bounded result into a universal claim that the evidence cannot support.
The 2017 fields are not an outage interval
The same frozen response includes historical fields. Its first_seen field names prefix 185.94.255.0/24, origin 200427, at 18 December 2017, 00:00 UTC. Its last_seen field names the same prefix and origin at 18 December 2017, 16:00 UTC. The response query time is nearly nine years later, on 7 August 2026, 00:00 UTC.
Those labels belong to fields selected by the endpoint. They do not, by themselves, establish that the ASN operated only for sixteen hours, stopped announcing after 2017 or remained absent until 2026. A continuity conclusion would require a purpose-built route-history series with explicit coverage, thresholds and vantage points. An outage conclusion would additionally require evidence about the affected systems and time window.
Keeping query time, first seen and last seen separate protects readers from a common error: turning three timestamps from one response into a narrative the source never stated. The fields can be reported exactly. Their causal meaning remains unresolved.
How to verify the next question
A useful verification sequence starts with identity. Confirm AS200427 in the directory and RIPE RDAP record, including the exact number range, handle and registrant name. This step reduces the risk of assigning evidence to the wrong company or routing domain.
Next, inspect PeeringDB for the declarations actually present. Record the exact profile label and ASN before evaluating other fields. Here, the label difference should trigger a corporate-evidence question, not an assumption. An authorised source would be needed to establish whether Proximity Data Centres Limited and nLighten - IX ASN have a legal or operational relationship.
For routing questions, preserve the RIPE RIS product name, query time, address family, peer denominator and returned prefixes. Compare another suitable time-bounded observation source when the decision needs broader confidence. For continuity, use a route-history series. For authorisation, examine the applicable origin-authorisation and registry evidence. For a service question, add end-to-end tests and system evidence aligned to the same time window.
This layered method does not force a single source to answer a question it was not built to answer. RIPE registration, the participant-maintained PeeringDB profile and the frozen RIPE RIS response are different evidence layers; none alone proves a live peering session, an absence of routes, corporate continuity, universal reachability, route authorisation, capacity, resilience or customer service.
What the records do not establish
The admitted sources support a focused account of the AS200427 administrative identity, a participant profile under a different label and a frozen collector result. They do not establish ownership, acquisition history, a rename, corporate continuity, services, customers, operating geography, facilities, equipment, upstream relationships, commercial scale or market position.
They also do not establish live exchange presence, route-server participation, a bilateral session, traffic, throughput, latency, spare capacity, physical diversity, resilience, uptime or a customer outcome. The directory is an identity and navigation surface rather than independent operational evidence. The PeeringDB profile is a declaration layer. The RIPE RIS response is an observation layer with a fixed temporal and collector boundary.
The strongest public conclusion is therefore deliberately limited. RIPE RDAP records Proximity Data Centres Limited with AS200427. PeeringDB contains one exact ASN row named nLighten - IX ASN, without evidence here that bridges the two corporate labels. The frozen RIPE RIS response reports zero qualifying visibility within its listed peer sets at its stated query time. These facts can coexist without implying failure, contradiction or continuity.
What to watch
- changes to the AS200427 number range, registrant identity, administrative status or event history in RIPE RDAP;
- changes to the exact label, policy, prefix declarations or exchange-LAN rows in the PeeringDB record;
- corporate evidence that explicitly explains the relationship, if any, between Proximity Data Centres Limited and
nLighten - IX ASN; - later routing observations that disclose their product, query time, address family, peer denominator and method;
- purpose-built route-history or origin-authorisation evidence when the question concerns continuity or permission;
- authorised operational evidence when the question concerns a live session or customer experience.