Summary

  • AS210973, the autonomous system held by the Vienna company DATAMATIX Datensysteme GmbH since 30 July 2021, is fully verifiable at the canonical layers: the RIPE NCC allocation, two RPKI ROAs covering five prefixes, and the Austrian Firmenbuch all converge on one name.
  • The commercial mirror layer does not converge. Hurricane Electric lists three IPv4 prefixes and omits 194.0.132.0/24, which RIPEstat's RIS snapshot of 11 September 2026 includes; Qrator Radar omits it too; NLNOG's IRR Explorer reports the prefix is not seen in the DFZ at all despite existing route objects and a valid ROA.
  • Mirror labels attach names to prefixes that no canonical record supports: IPinfo shows 'Rapid Solution Development' and the domain crashcars.at on 212.236.10.0/24, video-broadcast.at on 212.236.9.0/24, and Hurricane Electric lists a person, 'Clemens Schmikal', as prefix registrant — none of which appears in the RIPE objects themselves.
  • The RIPE route objects for both 212.236.x prefixes are maintained by AS8245-MNT, the maintainer of Video-Broadcast GmbH, created on 16 August 2021 — a third party's maintainer object standing between DATAMATIX and its own announced space.
  • The lesson generalises: registry records and cryptographic authorisations are evidence of a specific, checkable kind; commercial mirror labels are unverified claims about that evidence, and readers who cannot distinguish the two will inherit every mirror's attribution errors.

DATAMATIX Datensysteme GmbH is, by the standards of the companies this publication covers, a small entity. The Austrian company register records it as a GmbH seated at Märzstraße 1/Top 2.7, 1150 Wien, entered on 18 October 2003 under Firmenbuchnummer FN 240683x, with Michael Kastelic as managing director and sole shareholder since that same date (https://www.evi.gv.at/f/240683x). Its stated share capital is modest — EUR 36,000 according to the register mirror at evi.gv.at, though the commercial mirror Firmenabc shows EUR 34,000 against the same company, a discrepancy this article returns to later (https://www.evi.gv.at/f/240683x; https://www.firmenabc.at/datamatix-datensysteme-gmbh_HkT). Its product catalogue, published at datamatix.at, describes industrial wireless data systems — the kind of equipment, as BTW's earlier reporting documented, that is engineered to work without depending on public networks or cloud services at all (https://datamatix.at/impressum.html; https://btw.media/en/datamatix-as210973-operational-capability).

And yet the same company holds an autonomous system number, AS210973, allocated by the RIPE NCC on 30 July 2021, announcing a set of IPv4 and IPv6 prefixes under two Route Origin Authorisations that two independent rpki-client validation mirrors — one in the primary console, one in Amsterdam — show identically (https://console.rpki-client.org/AS210973.html; https://console-ams.rpki-client.org/AS210973.html). The aut-num object names the organisation ORG-DDG16-RIPE, carries the as-name DATAMATIX-AS, was created at 09:39:47 UTC on 30 July 2021 and last modified on 5 June 2023, and is maintained by RIPE-NCC-END-MNT together with the LIR maintainer lir-at-datamatix-1-MNT (https://bgp.he.net/AS210973). BTW's prior reporting walked this chain end to end: from the RIPE allocation record, through the Firmenbuch entry that links the same legal entity to a real company with a real address, to the operating business (https://btw.media/en/datamatix-as210973-evidence-chain-closed). That chain is closed. It is not the subject of this article.

The subject of this article is what happens one layer further out, where dozens of commercial services repackage the canonical record for their own customers — and where, for AS210973, the repackaging has visibly come apart.

A network that five monitors cannot agree on

Start with the simplest question a reader might ask: which prefixes does AS210973 announce? The canonical evidence — the ROAs — covers five prefixes: 212.236.9.0/24, 212.236.10.0/24, 149.62.35.0/24, 194.0.132.0/24 and 2a10:fd00::/32 (https://console.rpki-client.org/AS210973.html; https://console-ams.rpki-client.org/AS210973.html). RIPEstat, the RIPE NCC's own data platform, lists four IPv4 prefixes for the AS — 149.62.35.0/24, 194.0.132.0/24, 212.236.9.0/24 and 212.236.10.0/24 — against a RIS snapshot dated 11 September 2026, and notes that the network is not seen in RIS as a transit provider (https://stat.ripe.net/resource/AS210973).

Hurricane Electric's ASN page tells a different story. It reports four originated prefixes — three IPv4 and one IPv6 — and its count of IPv4 space omits 194.0.132.0/24 entirely. It also attaches a warning that the network announces bogons, and its footer carries an update date of 26 June 2026 (https://bgp.he.net/AS210973). Qrator Radar, over a window the page dates from 20 May 2026 to 20 August 2026, lists 2a10:fd00::/32, 149.62.35.0/24, 212.236.9.0/24 and 212.236.10.0/24 — again omitting 194.0.132.0/24 — while showing RPKI ROA status valid and route object status valid with 100% propagation for everything it does list (https://radar.qrator.net/as/210973/connectivity/prefixes).

The most pointed divergence comes from NLNOG's IRR Explorer, which reconciles BGP observation, RPKI state and IRR route objects prefix by prefix. For 194.0.132.0/24 it reports the sharpest possible finding: route objects exist, and an RPKI ROA exists, but the prefix is not seen in the DFZ — the global routing table itself. In other words, on the question of whether this prefix is actually carried by the internet, IRR Explorer's answer is no, while RIPEstat's RIS-based listing says yes (https://irrexplorer.nlnog.net/asn/AS210973; https://stat.ripe.net/resource/AS210973). HE and Qrator, by omission, side with neither cleanly (https://bgp.he.net/AS210973; https://radar.qrator.net/as/210973/connectivity/prefixes).

None of this is a data error in the ordinary sense. Each monitor answers a slightly different question over a slightly different window with a slightly different visibility threshold. RIS-based listings use rolling windows and peer-count thresholds, which means a prefix announced but poorly propagated can appear in one snapshot and vanish from another. A monitor that samples at a moment when the announcement is withdrawn or filtered will simply never see it. The divergence is therefore itself the evidence: 194.0.132.0/24 is the one prefix in AS210973's ROA set whose presence in the live routing table is not robust enough to survive every observer's methodology. Whether that reflects intentional non-announcement, upstream filtering, or an announcement so marginal that mainstream vantage points miss it cannot be determined from the public record (https://irrexplorer.nlnog.net/asn/AS210973).

The same reconciliation exercise surfaces a second structural finding. For 149.62.35.0/24 and for the IPv6 prefix 2a10:fd00::/32, IRR Explorer flags RPKI-invalid route objects: RIPE route objects exist with origin AS24953 and origin AS210973 simultaneously, while the DFZ shows only one of them and the ROA authorises only AS210973 (https://irrexplorer.nlnog.net/asn/AS210973). Stale or conflicting IRR objects coexisting with a valid ROA is a common condition in the global routing system, but it matters here for a specific reason: it demonstrates that even on prefixes where the registry ownership is not in dispute, the routing-registry layer can remain internally contradictory. BTW's coverage of the fourth prefix made exactly this point — registry clarity and routing-registry consistency are two different problems, and fixing one does not fix the other (https://btw.media/en/datamatix-as210973-evidence-chain-closed).

The mirror labels that no registry supports

The deeper problem with the mirror layer appears when those services attach names to prefixes. The canonical RIPE record ties AS210973 to ORG-DDG16-RIPE and, through the Firmenbuch cross-reference BTW established earlier, to DATAMATIX Datensysteme GmbH (https://bgp.he.net/AS210973; https://btw.media/en/datamatix-as210973-evidence-chain-closed). The commercial mirrors tie the prefixes to an assortment of other names.

On 212.236.10.0/24, IPinfo shows a registry identifier of 'RSD-SUB1', lists the ASN domain as crashcars.at, and attributes the overlapping /16 to AS8245 Video-Broadcast GmbH (https://ipinfo.io/AS210973/212.236.10.0/24). Hurricane Electric's page for the same block lists the origin as AS210973 with origin registrant DATAMATIX Datensysteme GmbH — correct — but the prefix registrant as 'Rapid Solution Development', and confirms that the less-specific announcements 212.236.0.0/19, /18 and /16 come from AS8245 (https://bgp.he.net/net/212.236.10.0/24). A separate IPinfo lookup of the address 212.236.10.1 carries the same attribution pattern (https://ipinfo.io/212.236.10.1).

On 212.236.9.0/24, the labels diverge again but in the same direction. IPinfo shows a registry identifier of 'DATAMATIX-01' — closer to the truth — but pairs it with an ASN domain of video-broadcast.at, and notes that the neighbouring 212.236.10.0/24 is attributed to Rapid Solution Development (https://ipinfo.io/AS210973/212.236.9.0/24). Hurricane Electric lists the prefix registrant for this block as a person: 'Clemens Schmikal' (https://bgp.he.net/net/212.236.9.0/24).

None of these names — Rapid Solution Development, crashcars.at, video-broadcast.at as a prefix attribute, Clemens Schmikal — appears in the canonical RIPE objects for these prefixes as reproduced across the retained sources. What does appear in the canonical layer is a different third-party trace: the RIPE route objects for both 212.236.x prefixes are origin AS210973 but maintained by AS8245-MNT, the maintainer object of Video-Broadcast GmbH, both created on 16 August 2021 — at 14:43:57 UTC for 212.236.9.0/24 and 14:44:24 UTC for 212.236.10.0/24, twenty-seven seconds apart (https://bgp.he.net/net/212.236.10.0/24; https://bgp.he.net/net/212.236.9.0/24). The maintenance relationship is real and recorded; the mirror labels are, by contrast, inferences of unstated provenance.

Where do mirror labels come from? A reasonable reading of the pattern is that attribution engines combine whatever signals they can harvest: historical WHOIS snapshots, reverse DNS on addresses inside the block, web domains associated with addresses, contact records, and heuristics that propagate a neighbour's identity onto adjacent space.

Video-Broadcast GmbH holds the parent /16 and announces the covering less-specifics, so its domain bleeds onto DATAMATIX's sub-allocation; an address in the block may once have resolved to a host named for a person or a business; a downstream customer of the space leaves a footprint the engine mistakes for ownership. Each inference is individually explicable. Collectively they produce a record in which the same /24 carries three mutually incompatible attributions across two mirrors.

The cost of this is not abstract. Anyone performing due diligence on DATAMATIX — a credit analyst, a procurement officer, a security researcher deciding whether an abuse report belongs to the right entity — who consults a mirror first will inherit an attribution that the registry does not support. BTW's earlier reporting on the 212.236.x space found precisely this split: operational control attributable to AS210973, ownership attributable to no party in any consultable public record (https://btw.media/en/datamatix-as210973-prefix-attribution). The mirror layer, this article's reading shows, does not merely fail to resolve that ambiguity — it manufactures additional, spurious attributions on top of it.

The upstream structure the mirrors do capture

If the mirror layer's identity labels are unreliable, its connectivity data is on firmer ground, because connectivity is an observational fact rather than an inference. Three upstream providers carry AS210973's routes: AS24953 NETPLANET, which provides both IPv4 and IPv6 transit; AS8218 Zayo, IPv4; and AS8245 Video-Broadcast, IPv4 (https://bgpthingy.xindi.eu/asn/210973; https://bgp.he.net/AS210973). The network participates in no known internet exchange point (https://bgpthingy.xindi.eu/asn/210973).

BTW's earlier analysis of this structure found that the three named upstreams are not three independent paths to the internet: AS8245 and AS24953 both sit beneath AS8218 in the observed topology, meaning every route the network announces ultimately traverses the same aggregation infrastructure operated around AS8245's position (https://btw.media/en/datamatix-as210973-entangled-upstreams). The mirror data corroborates that reading directly — the peers are consistently the same three across sources, and the less-specific 212.236.0.0/16, /18 and /19 announcements from AS8245 confirm that DATAMATIX's two prefixes inside that /16 ride beneath a covering announcement from the very operator whose maintainer object controls their route objects (https://bgp.he.net/net/212.236.10.0/24; https://bgp.he.net/net/212.236.9.0/24).

One further detail in the retained record is worth flagging for anyone tracking this network over time: Hurricane Electric's data shows a RIPE route object for 212.236.0.0/19 originated by AS8245 and created on 17 May 2026 — a recent addition to the covering structure, five years after the /24 route objects beneath it (https://bgp.he.net/net/212.236.9.0/24). The significance of that timing cannot be established from the public record; it is noted here as an observable change in the covering layer, not an interpretation of intent.

Corporate record: one company, two capital figures

The corporate layer holds its own small divergence lesson. The Austrian Firmenbuch mirror at evi.gv.at records DATAMATIX Datensysteme GmbH with a Stammkapital — statutory share capital — of EUR 36,000, managing director and sole shareholder Michael Kastelic since 18 October 2003, and Prokurist Ing. Patrick Romberger, BSc since 23 September 2021, with the most recent register entries dated 25 September 2025, 14 September 2024 and 27 September 2023 (https://www.evi.gv.at/f/240683x). The commercial mirror Firmenabc, for the same company and register number, shows EUR 34,000 (https://www.firmenabc.at/datamatix-datensysteme-gmbh_HkT).

Both figures cannot be simultaneously current, and the canonical register is the authority; the mirrors are snapshots of it at different times or with different reporting bases. The pattern is identical to the routing case at smaller scale: a canonical record exists, two repackaging services disagree about its content, and only a discipline of going to the source resolves the question. It also illustrates that the mirror-reliability problem is not specific to routing data — it is a property of the secondary-source business model, in which aggregation replaces verification.

What the ROA set proves, and what it deliberately does not

The two ROAs are the strongest cryptographic statements in the retained record. One authorises AS210973 to originate 212.236.9.0/24 and 212.236.10.0/24 with maximum length /24; the other authorises 149.62.35.0/24 and 194.0.132.0/24 with maximum length /24 and 2a10:fd00::/32 with maximum length /32, all under the RIPE Trust Anchor (https://console.rpki-client.org/AS210973.html; https://console-ams.rpki-client.org/AS210973.html). Both independent rpki-client mirrors show the same set (https://console-ams.rpki-client.org/AS210973.html).

A ROA proves that the holder of the covering resource — in this case the organisation behind the allocations within the RIPE service region — signed an authorisation naming AS210973 as a legitimate origin. It does not prove ownership of the address space in any property-law sense; registry records, as BTW's evidence-chain reporting established, are not asset adjudications (https://btw.media/en/datamatix-as210973-evidence-chain-closed). And it does not speak to the identity questions the mirrors get wrong: the ROA names an autonomous system, not a company. The company attribution rests on the aut-num's organisational reference and the corporate register, which is why the correct evidence chain runs registry → Firmenbuch → business, and why every mirror that skips the middle step and guesses at identity from routing adjacency produces the noise documented above.

This is also why the 212.236.x prefixes present the sharpest test case. IRR Explorer reports them as fully consistent — BGP origin 210973, RPKI 210973/24, RIPE route object 210973, 'Everything looks good' (https://irrexplorer.nlnog.net/asn/AS210973). Yet these are the same two prefixes whose ownership is unattributable in the public record and whose route objects sit under a third party's maintainer (https://btw.media/en/datamatix-as210973-prefix-attribution). A reader who takes IRR Explorer's summary at face value concludes the space is clean. A reader who traces the maintainer objects and the /16 allocation concludes the space is clean at the origin-and-authorisation layer only, and unresolved one layer down. Both conclusions are correct; they answer different questions. The failure mode this article documents is the industry habit of collapsing those questions into one.

Attribution as an unsolved problem, in one worked example

The complete picture for AS210973 as of the retained record:

Every layer a careful analyst needs is publicly consultable. Every layer a careless analyst consults first is the one most likely to be wrong about identity. That inversion — the easiest data being the least reliable — is the structural finding of this article, and it is not specific to DATAMATIX. It is a property of how the infrastructure-evidence ecosystem is built: canonical records are free but awkward, mirrors are polished but inferential, and nothing in the mirror products marks the boundary between the two.

BTW's earlier work on this subject asked what routing footprints can prove about a business, and answered: authorisation, announcement and continuity, but not service, customers or commercial category (https://btw.media/en/datamatix-as210973-operational-capability). This article adds the mirror dimension to that answer. A routing footprint cannot prove identity either — and the services built to make routing data legible will, in this documented case, assert identities the underlying records do not contain.

The remaining mirrors in the retained record fill in the outer ring of the disagreement without resolving it. bgpthingy lists five ROAs under the RIPE trust anchor while counting four originated prefixes on the same page (https://bgpthingy.xindi.eu/asn/210973); worldip and the mirror whois.ipip.net each reproduce holder and registration details with their own gaps (https://worldip.io/asn/210973; http://whois.ipip.net/AS210973); ipgeolocation.io's ASN page attaches its own attribution pattern (https://ipgeolocation.io/browse/asn/AS210973), while its page for the neighbouring AS43855 shows adjacent space resolving to a different network entirely (https://ipgeolocation.io/browse/asn/AS43855); the whisper.security mirror adds another independent rendering (https://canon.whisper.security/asn/210973); and a network lookup on 212.236.9.0/24 returns its own label set (https://www.bigdatacloud.com/network-lookup/212.236.9.0/24). The directory record for the subject entity is maintained at https://btw.media/en/directory/datamatix.