Summary

  • RIPE RDAP records AS212483 as an active administrative object and associates the named organisation record with LEVEL EIGHTY-SIX COMMUNICATIONS LTD. That establishes a number-resource identity; it does not show that a route, session, router or customer service is operating.
  • PeeringDB’s returned profile declares eleven exchange rows for Level 86, while the RIPEstat routing-status response reports sharply different IPv4 and IPv6 visibility at its stated query time. Both are useful records, but one is a participant-maintained declaration and the other is a threshold-bounded collector observation.
  • The defensible conclusion is about evidence discipline: retain the ASN as the common object, preserve the timestamp and vantage-point boundary of every routing observation, and do not turn directory fields into claims about traffic, capacity, physical diversity, resilience or service health.

One ASN, three different questions

An autonomous system is a network, or a group of networks, that presents a common routing policy to the internet. Its autonomous system number, or ASN, gives that routing domain a unique public identifier. Networks use the Border Gateway Protocol, commonly called BGP, to exchange reachability information associated with such identifiers.

AS212483 is the common object across the records examined here, but each record answers a different question. The registry asks which administrative object and organisation are associated with the number resource. A coordination directory records what a participant declares about its network and interconnection presence. A route collector reports what selected observation points saw under a defined method at a particular time.

Those questions are related, not interchangeable. A stable identifier lets an operator compare records without relying on a company name alone. It also gives customers, researchers and incident responders a precise starting point when names, brands or service descriptions vary. The identifier does not make every surrounding field operational evidence.

What the RIPE RDAP record establishes

The RIPE RDAP response covers exactly autonomous-system number 212483. It uses the handle AS212483, names the object level86, and marks the registry object active. Within the response, the organisation registrant handle ORG-LECL2-RIPE carries the name LEVEL EIGHTY-SIX COMMUNICATIONS LTD. That exact organisation name provides the narrow identity bridge to the Level 86 directory entry.

The RDAP event history records registration at 8 August 2022, 13:34:13 UTC, and a last-changed event at 9 December 2025, 10:25:29 UTC. These are administrative record events. They do not establish when a router was installed, a route was announced, a session was established, a service changed or a customer experienced an outcome.

The same boundary applies to the word active. It means that the registry object carries that administrative status. It is not a health indicator for equipment or applications, and it does not test BGP reachability. The response also includes other objects with registrant roles, so the commercial identity should not be inferred from every role label. The named organisation object is the relevant identity link.

This is what makes a registry useful as a ledger. It keeps a unique number resource attached to reviewable names and administrative history. A ledger can support coordination and reduce ambiguity without claiming authority over the state of the running network at every moment.

What PeeringDB declares

The PeeringDB response contains one network row for ASN 212483. It names the network Level 86, provides 86 COMMUNICATIONS as an alternate name, classifies the profile as Enterprise, declares an open general peering policy, and lists the IRR set AS-86. The row also declares 100 IPv4 prefixes and 120 IPv6 prefixes.

Those are participant-maintained directory fields. They provide a public statement of intended identity and coordination details. They do not show which prefixes were visible to route collectors at the same moment, which routes another network accepted, or whether any path carried traffic.

The nested exchange data contains eleven rows. Ten are marked operational and one is marked not operational; all eleven carry a route-server-peer flag. The listed exchanges are NetIX, CHIX-CH, LOCIX Frankfurt, Poema IX, FogIXP, NL-ix, Lambda-IX, LOCIX Düsseldorf, BGP.Exchange Zurich, FREMIX and ZXIX Hong Kong.

The declared speeds are two 100 Mbps rows, one 250 Mbps row, one 500 Mbps row, six 1,000 Mbps rows and one 10,000 Mbps row. These values may help an operator identify the directory entry that should be checked against a design or a session configuration. They do not measure current traffic, usable headroom, contracted capacity or performance.

Likewise, an operational flag is not continuous BGP-session telemetry, and a route-server-peer flag does not prove that a session is established or exchanging routes. Eleven logical entries do not establish eleven independent facilities, fibre paths, power domains or upstream networks. Physical diversity requires evidence about the actual dependencies, not a count of public directory rows.

What the RIPE RIS snapshot observed

RIPEstat’s routing-status response provides the running-observation layer, but only within its own scope. The response gives query_time as 7 August 2026 at 00:00 UTC. At that query time, it reports no qualifying IPv4 prefix visible among the listed 327 IPv4 full-feed RIS peers. It reports 16 announced IPv6 prefixes, representing 31 /48s, visible to all 320 listed IPv6 full-feed RIS peers.

RIS is the Routing Information Service, a collection system that receives routing information from participating observation points. The endpoint states that its results exclude routes seen by fewer than ten RIS full-feed peers. The IPv4 value therefore describes what qualified for this returned collector view under that threshold. It does not prove that every possible IPv4 route was absent everywhere, that every Level 86 service lacked IPv4 reachability, or that an outage occurred.

The IPv6 value has the same kind of boundary. Visibility at all 320 listed IPv6 full-feed peers is strong evidence about this collector set and this response. It is not proof of universal internet reachability, route authorisation, resilience, low latency or a working customer application. A route may be visible while a service behind it fails, and a service test may fail for reasons that a route collector cannot observe.

The response also reports 2,964 observed neighbours. That is a collector-derived value within the endpoint’s model. It must not be described as 2,964 direct peers, commercial relationships, contracts, facilities or independent paths.

Query time and last-seen time are distinct fields

The routing-status response separately reports a last-seen field for the IPv6 prefix 2401:5a0:ff03::/48 at 7 August 2026, 00:00 UTC. That last-seen field carries the same timestamp as the response’s stated query time, but it remains a distinct field with a different meaning. The correct treatment is to preserve both fields exactly as the endpoint returned them and to avoid manufacturing a single “current state” time from the pair.

The distinction matters because timestamps describe specific fields and methods. Query time labels the endpoint’s reported query context. Last seen belongs to the returned last-seen prefix field. Without additional evidence about the endpoint’s processing and update behaviour, the two values should not be converted into an operational timeline or an assertion that a route changed on the basis of the two fields.

The response also identifies 41.216.185.0/24 as a first-seen prefix for origin 212483 at 13 October 2021, 00:00 UTC. That historical field records what the endpoint labels first seen. It does not establish ownership, authorisation or continuous announcement between then and the later snapshot.

A verification sequence for operators and readers

The safest investigation begins with identity. Confirm that the intended subject is AS212483 and that the named organisation and directory entry refer to the same network object. Then check the administrative record for status, organisation handle and event history. This prevents a similar brand name or unrelated network from being substituted for the object under review.

Next, treat PeeringDB as a coordination checklist. Compare the declared network name, policy, IRR set and exchange rows with the design relevant to the question. If an exchange row or address is being used to diagnose a service, verify the actual session state and configuration through authorised operational sources. A matching directory entry is a lead, not a closure condition.

Only then move to time-stamped running evidence. For a routing question, record the collector, query time, visibility threshold, address family and exact prefixes observed. Compare more than one suitable vantage point when the decision requires broader confidence. For a service question, add end-to-end tests and application evidence. For a capacity question, use defined interface or service measurements over a stated period.

This sequence keeps conclusions proportional to the evidence. RDAP can identify the resource without proving a route. PeeringDB can declare interconnection context without proving a session. RIS can observe routes without proving customer experience. Each layer remains valuable because its limitations are explicit.

What the public record cannot establish

The four public records support a precise description of Level 86’s network identity, its declared interconnection surface and a bounded routing observation. They do not establish the company’s full physical topology, the commercial terms behind any relationship, or the path used by a particular customer.

They also do not establish traffic volume, spare capacity, fault isolation, route authorisation, security controls, performance, resilience or service availability. No outage conclusion follows from the returned IPv4 visibility field. No universal-reachability conclusion follows from the returned IPv6 field. No physical-diversity conclusion follows from the number of exchange rows.

The public record is strongest when used as a reality layer: a set of named objects and dated observations that can be checked against the running system. The defensible conclusion is narrow. RIPE’s registry associates AS212483 with the named Level 86 organisation; PeeringDB declares a multi-exchange interconnection profile; and RIPE RIS reports a sharply different IPv4 and IPv6 view under its stated query conditions. Any claim about live service outcomes needs additional, time-matched operational evidence.

What to watch

  • changes to the AS212483 organisation record, administrative status or event history in RIPE RDAP;
  • changes to the Level 86 network name, policy, IRR set, prefix declarations or exchange rows in PeeringDB;
  • later routing-status observations that preserve query time, address family, peer denominator and low-visibility threshold;
  • authoritative session or route evidence that confirms or contradicts a specific directory declaration;
  • service-specific telemetry when the question concerns availability, performance or customer impact.

Sources