Summary

  • The autonomous system AS210860 was registered as a RIPE aut-num on 24 August 2021 under the name edeka_digital, with the organisation ORG-EDG14-RIPE and the role object DFINFRA (DA9499-RIPE) as both administrative and technical contact. The role object itself was created on 10 June 2021, roughly ten weeks before the ASN it serves.
  • Hurricane Electric's routing view binds exactly one originating IPv4 prefix to AS210860 — 193.21.248.0/21 — while recording zero currently announced prefixes and no visibility in the global routing table since 26 March 2026. The retained sources expose no first-seen date, so continuous prior visibility cannot be asserted.
  • The aut-num's declared import and export policy names two transit relationships, AS9211 and AS13237; the only peer Hurricane Electric observes is AS9211. A PeeringDB-derived record still self-declares ten IPv4 prefixes and an open peering policy, in direct contradiction of every independent observation.
  • Two identity conflicts remain unresolved: RIPEstat renders the RIR status as RESERVED with no holder while the aut-num mirrors show ASSIGNED, and two mirrors give different names for the same organisation ID.

Prior BTW coverage of DFINFRA — published on 11 September, twice on 26 September and again on 27 September 2026 — performed three distinct jobs. It established that the name is not a company at all but a role object in the RIPE Database serving as the administrative and technical contact for autonomous system AS210860 inside EDEKA's number-resource administration. It then re-verified, through three independent routing observers, that the network has been silent — zero announced prefixes, no global-table visibility — since 26 March 2026, while a PeeringDB-derived self-declaration continued to claim ten IPv4 prefixes.

Finally, it ran what its own authors called the commercial half of the test: across nineteen retained public sources, no service catalogue, no customer, no price, no contract and no revenue figure could be attached to this network.

What none of those pieces did was assemble the lifecycle ledger. Each established a present-tense state — registered, silent, commercially unproven — but the timeline underneath that state was left open. When was the autonomous system actually created? When was the contact role created, relative to the network it serves? Which prefixes does the registry and the routing system actually bind to the ASN, as opposed to the ten a self-declaration claims? What transit relationships were declared, and do any of them appear in observed BGP?

And which parts of the public record contradict each other — not in interpretation, but in the identity fields themselves?

This article fills those rows. The evidence base is narrower than the question deserves: the primary RIPE Database query interface returned only an application shell in this research environment, so the registry field values below come from third-party reproductions of the RIPE record, not from the primary object itself (RIPE Database query interface). That limitation is stated here once and applied everywhere it matters, because every registry fact in this ledger inherits it.

The registry record: an aut-num created in August 2021

The aut-num object for AS210860, as reproduced by a mirror of the RIPE Database, carries the as-name edeka_digital, the status ASSIGNED, the source RIPE, the organisation reference ORG-EDG14-RIPE, and two maintainer objects, RIPE-NCC-END-MNT and EDDI-MNT (IPIP.NET mirror of the RIPE record). Its creation timestamp is 24 August 2021 at 08:30:41 UTC and its last-modified timestamp is 27 October 2021 at 08:53:15 UTC.

Both timestamps deserve their ordinary reading, and neither deserves an inflated one. The creation date marks when the registry object was entered — a paperwork event with a precise time, not evidence that any router anywhere began announcing anything. The last-modified date marks the final edit to the object, which means the record has been stable for nearly five years.

In an ecosystem where contact objects are routinely churned through reorganisations and acquisitions, an aut-num that has not changed since 27 October 2021 is itself a finding: whatever restructuring happened around EDEKA's digital operations, it never touched this registration.

The mirror reproduces the object's declared routing policy as two symmetric import/export pairs: import from AS9211 accept ANY with export to AS9211 announce AS210860, and the identical pattern for AS13237. These are declarations of intent, written into the registry by the resource holder. They bind no one. But they identify who the operator expected to hand traffic to, and they become testable the moment an observer looks for them in live BGP.

The role object that predates its network

The DFINFRA role object, nic-hdl DA9499-RIPE, appears in a reproduction of the RIPE Database output as a role created on 10 June 2021 at 07:41:42 UTC — roughly ten weeks before the aut-num object it serves (ip.cc reproduction of RIPE output). The same reproduction shows the organisation ORG-EDG14-RIPE with the org-name EDEKA DIGITAL GmbH, org-type LIR, located at New-York-Ring 6, 22297 Hamburg, with the DFINFRA role listed as admin-c, tech-c and with a separate abuse contact.

The ordering is worth registering precisely. The contact role existed before the network number did. That is a common enough sequence — an operator sets up its registry administration before requesting resources — but it reverses the intuitive reading of prior coverage, which treated DFINFRA as an attribute attached to AS210860. In the registry's own timeline, the administrative scaffolding came first, the autonomous system second. The role was never the shadow of a network; the network was provisioned into an existing administrative structure.

The role object carries the same stability as the aut-num. Prior reporting recorded that it had not been modified since 27 October 2021. On the same date the aut-num was last touched. One edit session, apparently, updated both.

What the registry and observers actually bind: one prefix

The aut-num object itself enumerates no prefixes. In the RIPE framework, prefixes are bound to an origin ASN through separate route objects, and the independent routing view is the operational test of what those bindings produce. Hurricane Electric's BGP view of AS210860 records exactly one originating IPv4 prefix, 193.21.248.0/21, attributed to EDEKA DIGITAL GmbH, with zero IPv6 prefixes originated and zero RPKI-originated entries in its view (Hurricane Electric BGP Toolkit). Its IPv4-specific page repeats the same figures (Hurricane Electric IPv4 view).

Against a self-declaration of ten IPv4 prefixes and one IPv6 prefix (HostDir record derived from PeeringDB), the observed count is one and zero. The gap is not a rounding difference; it is the difference between what a party says about itself in a directory it controls and what independent collectors have ever recorded as actually originated. And the single prefix that does exist in the observation record — 193.21.248.0/21, an eleven-bit block of 2,048 addresses — is itself now dark.

Declared policy versus observed peer

The declared transit relationships are AS9211 and AS13237. The observed record shows one of them. Hurricane Electric reports a single BGP peer for AS210860: AS9211, Nawork Internet Informationssysteme GmbH (Hurricane Electric BGP Toolkit). AS13237 appears nowhere in the retained observation sources as a live relationship of this AS.

CIDR Report, independently, lists AS210860 as EDEKA_DIGITAL, DE, and states that the AS is not currently used to announce prefixes in the global routing table nor used as a visible transit AS (CIDR Report AS report). RIPEstat's resource view agrees on the routing side: it reports that AS210860 does not originate prefixes visible in RIS and is not seen in RIS as a transiting AS, on a snapshot dated 14 September 2026 (RIPEstat resource view).

Put the three layers side by side and the shape is exact. The registry layer declares two upstreams. The observation layer sees one peer and no announcements. The self-declaration layer claims ten prefixes and an open door. Each layer is a different kind of statement — a written intent, a measurement, and a marketing claim — and only the measurement has stayed consistent across every observer, every snapshot, and six months of silence.

A silence with a date but no beginning

Hurricane Electric states that AS210860 has not been visible in the global routing table since 26 March 2026. The phrasing implies prior visibility — a network cannot lose visibility it never had — but neither Hurricane Electric nor any other retained source exposes a first-seen date. The ledger therefore records the silence as bounded at one end only: last seen on or by 26 March 2026, first seen unknown.

This matters more than it looks. If the network had a long routing history before March 2026, the current state is a shutdown. If it was visible only briefly, the current state may be a project that never fully launched. The retained evidence cannot distinguish these, and prior coverage's observation that the gap between registry and routing "has neither narrowed nor widened" (BTW, 27 September 2026) should be read with the same discipline: the corpus supports absence since March 2026, not a biography before it.

Two identity conflicts the sources leave open

The lifecycle ledger contains two contradictions that no retained source resolves, and honest reporting names them rather than papering over them.

The first is a status-layer conflict. RIPEstat's resource view renders the RIR status of AS210860 as RESERVED with no holder name (RIPEstat resource view), while both mirrors of the aut-num object show status ASSIGNED under an EDEKA organisation (IPIP.NET mirror). The two renderings may reflect different data layers — an administrative object versus a resource-status lookup — but the retained excerpts do not explain the discrepancy, and it cannot be resolved from the corpus.

The second is an org-name conflict across mirrors. The IPIP.NET mirror titles the AS holder EDEKA Verwaltungs- und Beteiligungs GmbH (IPIP.NET mirror), while the ip.cc reproduction of the same organisation ID, ORG-EDG14-RIPE, shows org-name EDEKA DIGITAL GmbH, org-type LIR (ip.cc reproduction). Either the organisation was renamed between mirror snapshots, or the mirrors hold divergent copies. Both are consistent with what prior reporting already established about the corporate layer — a holding company and an IT subsidiary absorbed by merger on 5 August 2025 — but neither mirror's freshness is verifiable, so which name is current is not established here.

What the ledger establishes, and what it does not

The lifecycle ledger is a bounded artifact. It establishes, on mirror reproductions with unknown freshness: creation dates for the role and the aut-num; a declared two-upstream policy; one observed peer; exactly one prefix ever bound in the observation record, now unannounced; a last-visible date of 26 March 2026; and two unresolved identity conflicts. It does not establish that no business ever existed behind this registration — that would require evidence the corpus cannot supply, and prior coverage correctly framed its empty commercial column as a statement about nineteen retained sources, not a proof of nonexistence.

What the timeline does add is directional. Prior coverage documented a divergence between declaration and observation. The lifecycle record shows the divergence is not recent: the network's operational footprint, to the extent it ever existed beyond a single prefix and one peer, was never rebuilt after the 2021 registration, and the registry objects have been untouched since October 2021.

The next observable condition that would falsify this dormant-state picture remains the one prior coverage defined: persistent, independently corroborated re-announcement of prefixes by AS210860, a new RIPE route-object binding, or a first-party service description from EDEKA DIGITAL.