Summary

  • NVIDIA ARC GmbH, the German company the BTW directory records against autonomous system AS40971, is an observed route origin rather than a silent registration: the RIPEstat overview for AS40971 returns the holder string NVIDIA-ARC NVIDIA ARC GmbH together with announced: true (RIPEstat AS overview for AS40971).
  • Its entire observed announced footprint is one IPv4 prefix, 192.31.14.0/24 — 256 addresses — with that origin-prefix pair observed as early as 13 June 2006 and as late as 21 October 2026 (RIPEstat announced prefixes; RIPEstat routing status).

The tension sits in a single pairing. Say "AI infrastructure" and the mind supplies halls of compute; open the routing record and you find one block of 256 addresses. That gap has practical stakes, because routing records are the evidence people reach for when they need a number: an analyst gauging a supplier, a counterparty testing whether a network relationship exists, anyone deciding what a directory row is worth. At 256 addresses this record describes a corporate edge, not a compute campus.

Read it instead as a measure of scale and the resulting error arrives with dates and an autonomous system number attached, which is what makes it look like evidence rather than inference.

An origin is what you get when an address block and an autonomous system are written down together. The number is the identifier, the block is the prefix, and the pairing asserts one narrow thing: traffic for those addresses should arrive through that network. Registration and announcement are separate acts. A block can sit in a registry for years without ever being announced, and an announcement survives only as long as somebody keeps the configuration in place — which is why a pairing that has lasted twenty years is a maintenance fact before it is a strategy fact.

Think of the record as a company nameplate on a single loading bay. The plate establishes which bay the holder may use, and the measurement systems confirm that traffic has been seen arriving there. It says nothing about how much freight moves through the building, what is stored inside, or whether the company owns the building at all.

The people who act on this record are the holder's own network engineers, who decide what AS40971 originates, and the registry and measurement systems that record those decisions after the fact. Neither produces a service catalogue.

The registry record, as displayed

A RIPE Database search for AS40971 returns an organisation object with primary key ORG-MIG3-RIPE, the name NVIDIA ARC GmbH, country DE, and the address Fasanenstr. 81, D-10623 Berlin (RIPE Database search for AS40971). That is the registry's own rendering of a responsible party: an organisation handle, a legal name, a country code and a postal address.

Two details are worth separating. The organisation name is NVIDIA ARC GmbH, while the holder string attached to the autonomous system in the routing overview is NVIDIA-ARC NVIDIA ARC GmbH. The strings are close but not identical, because they come from different objects maintained for different purposes. This is ordinary registry housekeeping rather than a discrepancy to resolve: a holder string is a label on a routing record, an organisation object is a registration of a party.

The BTW directory adds dated context around that party. Its projection, generated on 18 August 2026 with its latest network observation on 24 July 2026, records a single associated autonomous system, AS40971, an allocation date of 23 May 2006, a legal type of private company, and no IXP presence. The BTW directory entry for NVIDIA ARC GmbH carries the same legal identity, and the card itself carries no topic label.

One prefix, measured in two different ways

The routing-status record gives two timestamps for prefix 192.31.14.0/24 with origin 40971: first_seen at 2006-06-13T16:00:00 and last_seen at 2026-10-21T00:00:00 (RIPEstat routing status). The announced-prefixes record lists exactly one prefix — the same 192.31.14.0/24 — carrying a timeline that runs from 2026-10-06T08:00:00 to 2026-10-20T08:00:00 (RIPEstat announced prefixes).

These two endpoints measure different things, and conflating them would overstate the case. The routing-status timestamps are the earliest and latest observations of that origin-prefix pair in the recorded history. The announced-prefixes timeline is a short recent window inside the same record. Neither is a continuous up-and-down log. The defensible statement is therefore narrower than it first appears: this is the same single prefix at both ends of a twenty-year span, not proof that a route was present for every hour between them.

The arithmetic is small enough to hold in mind. A /24 contains 256 IPv4 addresses — a rounding error against the address consumption of any modern compute campus.

Where the directory and the routing record disagree

The directory's projection for this record reports prefix_total: 0. The announced-prefixes response reports one prefix. Both cannot describe the same moment, and the difference has a mundane explanation: a projection materialises what an import pipeline captured, and it can lag or miss a layer. The routing record is the narrower, more direct instrument here, and it governs the announcement claim. What the zero shows is a gap in the directory's pipeline, not an absence of routing.

A second zero deserves the same care. The projection lists an RPKI total of 0 with no coverage percentage and no status breakdown. That is an absence of evaluation, not a validation verdict. Reading it as a clean bill of routing health, or as a finding of insecurity, would convert a blank field into a conclusion the record does not support; origin validation for this prefix has to be checked against a validation output, not inferred from a count.

The projection also carries five observed relationships — four labelled downstream and one peer — toward COLT Technology Services Group Limited and toward AS8220, observed between 17 June 2026 and 24 July 2026. These are inference classes, and observed describes how they were derived, not what was signed. A downstream label in a relationship record does not establish a commercial transit contract, and a peer label does not establish a settlement-free interconnection agreement.

What this footprint can and cannot describe

A single /24 is a plausible size for a corporate edge: mail relays, VPN concentrators, a management plane, a handful of public-facing services, and the addresses a firm needs so that its own staff and partners can reach it. It is not the shape of a datacentre fabric, which consumes address space in proportion to rack count, tenant isolation and virtual network sprawl. A company can run a large cloud business and originate one small block from a corporate autonomous system; the two facts describe different layers, and neither measures the other.

The contrast inside the catalogue is instructive. The broader NVIDIA card is filed under the topic "German industrial AI cloud and European compute capacity". The NVIDIA ARC GmbH card carries no topic at all. Neither is a measurement; both are filing. Anyone reading the catalogue as a capacity statement would be reading a classification decision, and the routing record would not support the inference.

What this record does not say

Three document classes that would sharpen or overturn this reading were not obtained as readable text in this review.

First, the RPKI origin-validation state of 192.31.14.0/24. Three retrieval attempts covering an RPKI validation output, the aut-num object and a prefix overview each ended with provider capacity unavailable. Whether that prefix carries a valid route origin authorisation is therefore unexamined, and an RPKI validation response for the prefix is the instrument that would settle it.

Second, the aut-num object text and the inetnum and route object history. This article makes no claim about the ASN's registration status field, about the registration date of the address block, or about the maintainers recorded on those objects, because none of those documents was read.

Third, NVIDIA's own dated statements about German and European AI cloud buildout, and which legal entity or operator it names as responsible. Without that material, this company cannot be credited with datacentre capacity, customer workloads or cloud revenue, and the article does not do so. A dated capacity disclosure or a site commissioning statement naming the responsible entity is the class of document that would change the picture.

What would move this reading is concrete rather than rhetorical: a second announced prefix, an IPv6 block, presence at an internet exchange, a route origin authorisation, or a published capacity disclosure naming NVIDIA ARC GmbH as the operator. Until one of those appears, the record supports a modest, dated statement. Two decades of a single /24 is a story about continuity and administrative stability at the resource layer — not about compute.