AS210087 makes Ontix's public route visible, but not the neutral-host

Summary

Companies House records active ONTIX SITES NO. 1 LTD under company number 10795153, while RIPE RDAP links Ontix Sites No1 Limited to active autonomous system AS210087.
RIPEstat sees AS210087 originate one current IPv4 route, 89.190.132.0/22, covering 1,024 addresses and visible to 330 of 330 sampled full-table IPv4 RIS peers.
The current routing snapshot reports no IPv6 origin. A historical first-seen field names an IPv6 prefix from 2019, but that is not evidence of current IPv6 service.
RIPEstat observed one BGP neighbour, AS35266. The observation does not prove a commercial relationship, exclusive upstream, physical path diversity or failover.
The sampled RPKI query returns unknown with no validating ROA. That is a bounded current observation, not proof of insecurity or the absence of every possible routing safeguard.
Ontix's own service descriptions explain why the ASN matters, but they remain first-party claims and do not independently establish the delivery footprint behind the public route.

One exact company identity sits behind the ASN

The strongest identity bridge begins with two public recordkeepers. Companies House lists ONTIX SITES NO. 1 LTD as active under company number 10795153. It records a private limited company incorporated on 31 May 2017, a registered office at Third Floor, 91 Jermyn Street in London and the business classification 61900, other telecommunications activities. It also preserves the previous company name, ONTIX LIMITED, used from incorporation until 11 February 2020.

RIPE's RDAP response for AS210087 names the autonomous system ONTIX. Its registrant entity ORG-OL199-RIPE is Ontix Sites No1 Limited, with the same Jermyn Street address. The company record and number-resource record therefore agree on a specific legal identity rather than merely sharing a brand word. That agreement is useful because the public-facing name Ontix can appear across products, partnerships and older coverage without proving which legal entity controls a particular resource.

The RDAP chronology adds another bounded fact. The autonomous system object was registered on 10 October 2018 and last changed on 21 February 2026. Those dates describe the current registry object. They do not establish when hardware entered service, when the first customer used a network, or when a particular small-cell deployment went live. Registry events and operating events belong to different clocks.

The contact information also illustrates why identity should not be compressed into one label. The registrant organisation uses the current Jermyn Street address. The administrative and abuse contact is Ripemaster Ontix Ltd and carries another London address in the captured record. That difference may reflect record history, operating arrangements or ordinary contact maintenance. The accepted evidence does not explain it, so the difference should be visible rather than silently harmonised.

Companies House itself warns that it does not check the accuracy of filed information. RIPE maintains number-resource records but does not certify the commercial performance of the holder. The two systems together support an exact legal and registry identity. They do not establish ownership of every street asset, fibre segment, small cell or service associated with the Ontix name.

This is the first important boundary. AS210087 is not a generic reference to a wireless brand. It is a unique coordination identifier associated with Ontix Sites No1 Limited. That makes it a valid monitoring object. It does not make the ASN a complete description of the company.

One IPv4 route defines the current public origin

RIPEstat's announced-prefixes response lists one current origin for AS210087: 89.190.132.0/22. A /22 contains 1,024 IPv4 addresses. The routing-status response independently reports one IPv4 prefix and 1,024 addresses, so the two endpoints agree on the size of the visible origin set at the captured time.

The route was visible to 330 of 330 sampled full-table IPv4 RIS peers. That is strong evidence of broad control-plane propagation in the RIPE Routing Information Service view. It means the sampled collectors saw the AS210087 origin across the full peer set used in the response. The observation can be reproduced, timestamped and compared with future snapshots.

Visibility is not the same as service availability. BGP can carry an origin while hosts behind the route are unreachable, filtered, unused or dependent on systems that are not represented in the route. A route can remain visible during an application failure. It can also be withdrawn during maintenance without proving a business failure. Control-plane presence is an important operating signal, but it is not an end-to-end service test.

The 1,024-address count is not a measure of users, radios, small cells, customers, bandwidth or revenue. Public addresses may be assigned to routers, gateways, management systems, services or unused inventory. Network address translation can place many endpoints behind one public address. A large allocation can be lightly used, while a small allocation can support important systems. Address count and service scale are different quantities.

The prefix-overview response maps the exact /22 to AS210087, names the holder ONTIX Ontix Sites No1 Limited and marks the route announced. It reports no related prefixes in the captured result. That alignment strengthens the origin statement. It does not disclose whether the block is used for backhaul, management, public Wi-Fi, fixed wireless, private networks, small-cell transport or a combination of functions.

An observer can therefore say that AS210087 had one compact, widely visible IPv4 origin at the snapshot. The observer cannot say where traffic terminates, how many sites depend on it, whether every Ontix service uses it or which operating party controls each physical link. The route is a public edge of the delivery system, not a map of the delivery system.

Current IPv6 absence must not be confused with route history

The current routing-status snapshot reports no IPv6 origin for AS210087. Its IPv6 visibility field is zero of 324 sampled peers, and its announced IPv6 space is zero prefixes. The announced-prefixes response likewise contains only the IPv4 /22. Within this bounded evidence set, the current public origin is IPv4-only.

The same routing-status response contains a historical first-seen field for 2a0d:bc40::/30 under origin AS210087 in February 2019. That field records an earlier observation in the data service. It does not say that the prefix remained visible, that it belonged to the current registrant arrangement, or that Ontix currently offers IPv6 through AS210087.

This distinction matters because historical routing data can easily be turned into a false present-tense claim. A first-seen record answers when a collector first associated an origin and prefix. The current announced-space fields answer what the snapshot sees now. The former cannot override the latter.

The absence of a current IPv6 route also has limited meaning. It does not establish that Ontix has no IPv6 capability. A service can receive IPv6 through another autonomous system, use a partner network, maintain private IPv6, or keep an allocation that is not globally announced. None of those possibilities is proved here. The only defensible statement is that the frozen RIPEstat view does not show a current IPv6 origin under AS210087.

For due diligence, that creates a precise question rather than a verdict. A counterparty requiring IPv6 can ask which ASN originates it, which prefixes apply, whether the path differs from IPv4, and how the service is monitored. A dated BGP snapshot cannot answer those contractual and architectural questions.

Monitoring should keep current origin state and historical observations in separate fields. If an IPv6 route later appears, that is a new control-plane event. If a previously observed prefix returns, the record can show continuity or change. Combining historical and current evidence would erase exactly the distinction that makes route monitoring useful.

One observed neighbour is a handoff signal, not a dependency map

RIPEstat's BGP-neighbours response records one observed left-side neighbour for AS210087: AS35266. It records no right-side neighbour in the captured view. The power and peer fields describe how the neighbour appeared in the sampled paths, not a commercial contract between the parties.

The observation supports a narrow statement: sampled BGP paths exposed one adjacent autonomous system on the side from which AS210087 was reached. It is reasonable to treat that as a visible logical handoff. It is not reasonable to name the handoff as an exclusive upstream, a paid transit provider, a settlement-free peer or a reseller without separate evidence.

BGP path position does not reveal the physical route. Two logical adjacencies can share a duct, building, power source or carrier. One adjacency can cross several physical paths. A backup may remain hidden until used. A route server or remote peering arrangement can further separate logical appearance from physical implementation. The current neighbour list therefore cannot support a claim about physical diversity.

Nor does one observed neighbour prove operational fragility. The data service has a bounded collector view and a particular query time. Other paths may be filtered, less visible, private or absent from the sample. A service may depend on systems outside the public ASN. The result identifies a question about external dependency; it does not answer it.

The right operational questions concern the handoff behind the observation. Who controls change approval? What monitoring detects unexpected origin or adjacency changes? Is there another path, and if so, is it physically and operationally independent? Which services depend on the AS210087 route? What happens when the visible adjacency is unavailable? Those questions require operator evidence.

The single neighbour also helps prevent an opposite error: treating a globally visible route as proof of a richly interconnected network. Broad propagation can occur through one visible adjacency. Visibility and diversity are separate properties. The first is measurable from the snapshot; the second requires a topology and dependency record.

The strongest conclusion is therefore modest. AS35266 was the one adjacent ASN visible in the sampled response. The observation is useful for monitoring, incident coordination and follow-up. It cannot support claims about contract type, exclusive dependency, physical route, failover or resilience.

An unknown RPKI result is a security metadata gap, not a verdict

The bounded RIPEstat RPKI query for AS210087 and 89.190.132.0/22 returns status unknown and no validating ROA. The response does not mark the route valid or invalid. It says that the query did not find a validating origin authorisation in the sampled validation result.

RPKI is designed to let a resource holder authorise an autonomous system to originate a prefix, subject to a maximum prefix length. A validating ROA can help networks distinguish authorised origins from conflicting announcements. The metadata is one control against certain routing mistakes and hijacks. It does not secure hosts, encrypt traffic or guarantee that an authorised route is operational.

An unknown state should not be rewritten as invalid. Invalid means a route conflicts with available origin-authorisation data. Unknown means no matching validation covered the prefix-origin pair in the response. The operational implications depend on the policies of networks receiving the route. Some treat unknown routes differently from invalid ones; many continue to carry them.

The result also does not prove that Ontix has never created a ROA, that no broader authorisation exists elsewhere, or that the state will remain unchanged. RPKI data can change, validators can differ, and query timing matters. The appropriate claim is point-in-time and endpoint-specific.

For Ontix, the unknown result creates an accountability question linked to the public route. How is the expected origin documented? Is a ROA planned or maintained through another resource arrangement? Who monitors validation state? How would an origin change be authorised during migration or recovery? Those questions are legitimate because AS210087 and the /22 are visible. The current evidence does not supply the answers.

Security assessment must remain layered. RPKI metadata concerns origin authorisation. BGP visibility concerns route propagation. Application security, access control, abuse handling, change management and incident response require other evidence. A positive result in one layer cannot certify the others, and an unknown result in one layer cannot condemn the whole operation.

The reality layer is precise: the sampled route is widely visible, and the sampled RPKI result is unknown. Both facts can be monitored. Neither supports a company-wide security rating.

Ontix's service proposition explains why the route matters

Ontix's own website describes the company as a next-generation wireless infrastructure provider. It presents outdoor mobile Infrastructure-as-a-Service, indoor mobile systems, public Wi-Fi, fixed wireless access, private networks, smart-city connectivity and analytics. The site says Ontix designs, builds and operates carrier-class solutions for mobile operators and other customers.

The outdoor-mobile page provides more detail about the claimed operating model. It says Ontix acquires rights to portfolios of street furniture, invests in infrastructure, installs small cells, builds neutral-host transmission networks and deploys core fibre in advance. It describes a carrier-grade Ethernet platform and a 60 GHz distribution layer. It also says Ontix provides an end-to-end managed service.

These statements explain the commercial context for AS210087. A neutral-host provider must coordinate identifiers, paths, contacts and dependencies even when much of the radio and physical footprint is not visible in BGP. The public ASN may support management, transport, Internet access, customer handoff or other functions. Knowing the expected role matters during incidents and changes.

The website is a first-party source. It records what the company says it offers. It does not independently measure how many sites are live, which assets are owned, what capacity is available, whether fibre paths are diverse, how an SLA performs, or which services use the public /22. Specific speed, cost and deployment claims on the page remain attributed claims unless corroborated.

The public route cannot fill those gaps. An ASN does not reveal street-furniture rights, radio count, fibre ownership, customer contracts, power arrangements or maintenance coverage. A prefix cannot show whether one site or many sites depend on it. BGP can reveal that a route is propagated; it cannot prove that the neutral-host service is delivering the promised outcome.

The two evidence layers are still valuable together. The company claims a managed infrastructure role. RIPE records a matching number-resource identity. RIPEstat sees a live origin. That alignment provides a starting point for verification. It is stronger than a brand-only profile and weaker than an independently tested delivery map.

The responsible frame is not promotional or suspicious. It asks how the visible ASN relates to the systems Ontix says it operates. The operator can answer with current topology, asset, dependency, service and control evidence. Until then, the route remains a bounded public surface.

Neutral-host delivery contains several hidden control planes

A neutral-host small-cell service combines more than one kind of infrastructure. There can be radio equipment, mounting rights, power, fibre or wireless backhaul, aggregation, carrier interconnection, management systems, monitoring, access control and support. Different parties can own or operate different layers.

The public ASN exposes only part of that arrangement. If traffic or management systems use AS210087, the route provides a coordination point. Other parts may use mobile-operator networks, partner infrastructure, private addresses or other autonomous systems. The accepted sources do not map those relationships.

Street assets create a property and permission layer. Radio nodes create a coverage and capacity layer. Backhaul creates a transport layer. Carrier interfaces create an interconnection layer. Management systems create an operational-control layer. Contracts assign responsibility across those layers. An externally visible route can intersect several of them without representing all of them.

This layered structure is why claims about operational control need evidence. A company may design and manage a service while leasing fibre. It may own a node while relying on a council concession for the site. It may provide transport while a mobile operator controls radio policy. None of those arrangements is inherently weak. The risk comes from unclear boundaries and untested dependencies.

For AS210087, the public evidence does not show whether the /22 carries customer traffic, management traffic or supporting services. It does not show whether the single observed BGP neighbour corresponds to the primary service handoff. It does not show which sites would be affected by a withdrawal.

A useful dependency map would identify the role of the ASN, each route, each major external network, the physical paths behind logical handoffs and the owners responsible for changes. It would also distinguish normal operation from recovery arrangements. That map is not available in the accepted sources.

The absence of a public map is not evidence of failure. Infrastructure operators often keep detailed topology private for security and commercial reasons. The appropriate public conclusion is that the operating boundary remains unproved, followed by specific questions that can be answered under due diligence.

Company, contact and network records need separate maintenance

The Companies House record, RIPE organisation record and RDAP contact card agree on the core Ontix identity but not on every historical detail. Companies House preserves a previous legal name. RIPE carries both the current organisation name and a Ripemaster Ontix Ltd contact. Addresses differ across parts of the captured registry response.

This is normal enough to require care rather than alarm. Corporate records, resource records and operating contacts can be updated on different schedules. A registered office serves a legal function. An abuse mailbox serves incident coordination. A network team may work elsewhere. The records should be connected deliberately, not assumed to be interchangeable.

During an incident, reachable operational contacts matter more than a perfectly formatted company name. During contracting, the exact legal entity matters. During a routing change, the authorised resource holder and network operator matter. One contact record cannot substitute for all three functions.

The captured RDAP response lists [email protected] as an abuse contact. That is a concrete coordination path in the registry. The source set does not test mailbox delivery, response time, escalation ownership or round-the-clock monitoring. A listed address is not proof of an effective incident process.

Record maintenance should therefore be treated as operational work. Changes to company name, office address, network team, abuse contact or resource arrangement should be reflected in the appropriate systems. A mismatch can delay coordination even when the underlying service is healthy.

For a counterparty, the practical check is to compare the contract entity, registry organisation, support contacts and incident escalation path. If they differ, the operator can explain why and document who owns each responsibility. That explanation is stronger than forcing every record into one label.

AS210087 gives this maintenance question a precise anchor. The ASN and registrant are clear. The remaining task is to show how the legal, network and operating contacts fit the current delivery model.

Existing Ontix coverage sets a strict commissioning boundary

The production collision check found three existing English titles containing Ontix. One concerns small-cell upgrades in Bristol's Clifton area. Another concerns 80 small cells in central London. A third concerns an indoor 5G network using MOCN. Those pieces cover concrete deployments and partnerships.

The AS210087 thesis is different. It does not retell where small cells were installed, how many were announced, or which mobile operator participated. It asks what the public number-resource record reveals about Ontix's own routing identity and what it leaves private about delivery control.

That distinction changes the opening mechanism. Deployment coverage begins with a place, partner, count or launch. The current inquiry begins with an ASN, one /22 and a registry-to-company identity bridge. Its central uncertainty is not whether a reported installation happened. It is how a visible control-plane identifier relates to the neutral-host layers described by the company.

The evidence base is also different. Companies House, RIPE RDAP and RIPEstat are the core recordkeepers. Ontix's service pages supply attributed operating context. The existing deployment titles are collision signals, not factual sources for the current network claims.

The allowed conclusion is correspondingly narrower. AS210087 gives Ontix a reproducible public routing identity. It does not prove that the ASN carries every small-cell service or that one visible neighbour supports each deployment. Keeping that limit avoids turning a resource record into a second deployment announcement.

Multiple pieces can legitimately concern one organisation when they use different theses, evidence and operating questions. The test is whether the new work adds a distinct monitoring surface. Here, the ASN, prefix, neighbour and RPKI state create that surface. Any later revision should preserve the same difference rather than drift back into place-by-place launch coverage.

Incident coordination starts with expected state

The AS210087 snapshot supplies a compact expected state: holder Ontix Sites No1 Limited, one IPv4 origin 89.190.132.0/22, broad sampled visibility, one observed neighbour AS35266, no current IPv6 origin and an unknown RPKI result. Each field can be checked again.

If the origin changes, investigators can ask whether the change was authorised. If the /22 disappears, they can separate a route withdrawal from an application fault. If a new neighbour appears, they can ask whether it reflects migration, redundancy, route leakage or collector variation. If RPKI becomes valid or invalid, they can record a security-metadata change without conflating it with service quality.

The baseline does not identify every incident. A fibre cut can occur while BGP remains stable. A small cell can fail without affecting the ASN. A management platform can fail while the public route continues. Conversely, a route change can be planned and harmless to customers. Expected state narrows diagnosis; it does not replace service telemetry.

Coordination also depends on ownership. The registry names an organisation and an abuse contact. An effective process would connect those public records to the team authorised to change routing and to the team responsible for customer impact. The source set does not show that chain.

An incident runbook can keep the evidence layers separate. First confirm the company and resource identity. Then check origin and visibility. Then check origin authorisation. Then test service paths. Finally map the affected service to physical and contractual dependencies. Skipping directly from BGP to a customer-impact conclusion would be unsafe.

The compact route set makes this discipline practical. One /22 is easy to monitor. The challenge is not enumeration; it is interpretation and escalation. Accurate records, current contacts and clear control ownership determine whether the public signal becomes useful during a real event.

Procurement should test the hidden delivery boundary

A customer considering an Ontix service can use the public evidence to ask more precise questions. The first is whether the purchased service depends on AS210087 or another network identity. If it does, the customer can request the expected prefixes, origins and external handoffs.

The second question concerns resilience. Does an alternate logical path exist? Is it physically diverse? Does it use separate power, facilities and carriers? A second BGP neighbour would not by itself answer those questions, and the current snapshot shows only one. The operator must explain the dependency design.

The third concerns security metadata and change control. Who maintains route objects and origin authorisations? How are routing changes approved? What alerts fire on an unexpected origin, withdrawal or more-specific announcement? The current RPKI result is unknown, so the control should be documented rather than inferred.

The fourth concerns service mapping. Which small cells, indoor systems, public Wi-Fi services, fixed-wireless customers or management systems use the public /22? Are critical control functions carried separately? What happens if the route is unavailable while radio or local transport remains active?

The fifth concerns incident ownership. Which team receives an abuse report? Which team owns a route leak? Which party handles street assets, fibre, radio, carrier interconnection and customer communication? The neutral-host model can distribute those responsibilities across several organisations.

These questions do not assume that the service is weak. They convert public facts into a verification plan. The company may have robust controls that are not public. Procurement can test them through architecture documents, contracts, service-level definitions, change records, incident exercises and independent measurements.

The public route is therefore neither a certification nor a warning label. It is a precise entry point. It tells a customer which identifier to cite and which current state to compare. The operating assurances must come from evidence matched to the purchased service.

A monitoring record should preserve facts before conclusions

AS210087 is suitable for lightweight repeated observation because the visible origin set is small. A monitoring record can preserve the holder, prefix set, visibility, neighbour set, RPKI state, registry contacts and observation timestamps.

Each field should retain its source. Companies House status is a legal record. RDAP organisation and contact fields are resource-registry records. RIPEstat visibility and neighbours are sampled routing observations. Ontix service descriptions are first-party claims. Combining them into one unlabelled profile would weaken the record.

Changes should be classified before interpretation. An identity change includes a new holder, organisation handle, company status or registered name. A routing change includes a new origin, prefix, withdrawal, neighbour or visibility shift. A security-metadata change includes a new RPKI validation state. A service-claim change includes a revised operating description.

The classification helps avoid false alarms. A contact update can be routine maintenance. A neighbour change can be planned. A brief visibility dip can reflect collector behaviour. A website update can be marketing rather than architecture. Review is necessary before assigning cause or impact.

Monitoring should also preserve absences carefully. No current IPv6 origin is a dated route observation, not proof that the company cannot deliver IPv6. No validating ROA in one response is a dated metadata observation, not proof of negligence. No related prefix in the overview is not proof that no private or partner network exists.

The record becomes more valuable over time. If AS210087 later adds IPv6, a second visible adjacency or a validating ROA, the change is concrete. If the /22 moves to another origin, the control boundary changes. If nothing changes, the stable baseline remains useful during incident checks.

This method favours reproducible state over rankings. It makes the evidence useful without pretending that public data can score a private operating system.

Registry and running code answer different questions

The registry is a recordkeeper. It maintains the ASN, organisation, contacts and event history. BGP is running code and distributed operational state. It shows what origins and paths the sampled network accepted. Companies House records the legal entity. The company website describes the commercial proposition.

No source is sovereign over the others. Companies House cannot certify routing control. RIPE RDAP cannot certify service delivery. RIPEstat cannot certify legal ownership or physical infrastructure. Ontix's site cannot independently verify its own capacity or resilience claims.

The sources become strong when their bounded claims align. The legal company name matches the RIPE organisation. The ASN holder matches the exact directory entity. The origin is visible. The service proposition explains why the network identity could matter. That alignment supports a reality-based account of a public control surface.

The gaps are equally important. The visible route does not map to specific small cells or customer services. The neighbour does not reveal the commercial or physical handoff. The unknown RPKI response does not reveal the operator's full security process. The website does not independently prove the current footprint.

Treating the registry as a licence to make broad service claims would exceed its function. Treating a BGP snapshot as a complete operating diagram would exceed its function. Treating first-party claims as measurements would exceed their function. The disciplined approach keeps every layer within scope.

That separation is not evasive. It is how infrastructure accountability works when much of the system is private. Public identifiers provide coordination. Running routes provide observations. Contracts, topology, measurements and incident records provide the rest.

AS210087 is therefore meaningful precisely because its meaning is bounded. It makes one part of Ontix's network identity visible and testable. It leaves the neutral-host delivery chain as a subject for direct evidence.

A service map should connect identifiers to measurable outcomes

The most useful next document would not be another general description of wireless infrastructure. It would be a bounded service map that starts with the exact company and shows how a purchased outcome crosses each operating layer. The map can protect sensitive details while still naming owners, identifiers, handoffs and failure responsibilities.

At the public edge, it should record AS210087, 89.190.132.0/22, the expected origin, the current RPKI policy and the contacts authorised to change routing. If the public /22 does not carry a particular service, the map should identify the network identity that does. This prevents an observer from using the most visible ASN as a proxy for every Ontix system.

The next layer should identify external handoffs. Logical adjacency, physical carrier, building entrance, power source and commercial responsibility are separate fields. A design can have two carriers but one physical path, or two BGP sessions that terminate on one device. Conversely, one visible BGP neighbour can sit above private or partner diversity that collectors cannot see. The service map should state which form of diversity is claimed and how it was tested.

For small-cell and neutral-host service, the map should then connect transport to radio and site dependencies. It can show whether the relevant node uses fibre, fixed wireless or another backhaul, which party controls the mounting right and power, which party owns the active equipment, and which party monitors faults. Exact street addresses need not be public, but customers and incident teams need an authoritative internal view.

The operating-control layer should identify who can approve changes, who receives alarms and who leads recovery. A routing team may restore a withdrawn prefix while a field team repairs a site. A mobile operator may control radio parameters while Ontix controls transport. A local authority may control access to street assets. Recovery depends on the handoff among those responsibilities as much as on any single component.

Measurable outcomes belong at the end of the map. Availability, latency, capacity, restoration time and coverage should be tied to a defined service, location, interval and measurement method. The public BGP snapshot cannot supply those values. It can supply an expected origin and help diagnose one class of failure.

This structure also makes assurance easier to update. A new carrier changes the handoff layer. A new prefix changes the public edge. A new site changes the asset layer. A revised service level changes the outcome layer. Each update can be reviewed without rewriting the whole operating story.

The purpose is not to force private topology into public view. It is to keep identifiers and claims connected inside the organisation and available to authorised counterparties. AS210087 offers a precise starting point. A service map would show where that starting point is relevant and where another control surface takes over.

What new evidence would change the assessment

A current route-origin authorisation could change the RPKI finding. The relevant evidence would identify the exact prefix, authorised origin, maximum length, validation status and observation time. A later valid result would not erase the earlier unknown snapshot; it would show a documented change.

A new IPv6 origin would change the protocol footprint. The route, origin, visibility and relationship to the service would need separate verification. A historical first-seen field would still not be enough; the route would have to appear in a current snapshot.

A second BGP neighbour could change the visible adjacency set. It would not automatically prove diversity. Physical path, facility, power, carrier and failure-domain evidence would still be required. The change would create a stronger question, not an automatic resilience claim.

Independent deployment evidence could connect the ASN to service delivery. Examples include a topology showing which systems use AS210087, a carrier interconnection document, route-policy records, independently verified site inventories, service measurements or incident exercises. Each would need a clear date and scope.

Contact verification could strengthen the coordination layer. Evidence that the registry mailbox is monitored, escalations are owned and changes are reviewed would address questions that a listed email alone cannot answer. The proof could remain private while the operator supplies a bounded assurance.

Corporate changes would require rebuilding the identity bridge. If the legal name, registrant or resource holder changes, the current association should not be carried forward by habit. Exact entity, company number, registry handle and current route should be checked again.

The assessment is intentionally updateable. It does not claim that Ontix has a fixed architecture. It records a current public surface and names the evidence needed to expand it.

Conclusion

Ontix Sites No1 Limited has an exact, reproducible public network identity. Companies House records the active UK company. RIPE RDAP links that identity to AS210087. RIPEstat sees the ASN originate 89.190.132.0/22, covering 1,024 IPv4 addresses and visible to every sampled full-table IPv4 peer in the frozen response.

The same snapshot shows no current IPv6 origin, one observed BGP neighbour and an unknown RPKI result with no validating ROA. Those are useful operating facts. They do not prove failure, insecurity, exclusivity, diversity, capacity or customer impact.

Ontix's own descriptions place the company in neutral-host wireless infrastructure, small cells, fibre, interconnection and managed service. That context explains why route accountability matters. It does not connect the public /22 to every asset, site, carrier or customer promise.

The defensible finding lies between the recordkeeper and the service claim. AS210087 is visible running state tied to the exact company. The physical, contractual and operational delivery chain behind it remains private and requires operator evidence. Counterparties can use the public baseline to ask precise questions about route authority, external handoffs, service mapping, change control and incident ownership.

That is a distinct form of coverage from place-specific deployment news. It does not count radios or celebrate a launch. It identifies a network coordination surface, records what the Internet can observe and marks the line where operator evidence must begin.

AS210087 makes Ontix's public route visible, but not the neutral-host delivery chain

Why it matters