Summary
- DDCatch Inc. is an active Florida corporation and the registered holder of AS211818, but its public website describes a domain drop-catch service and says its customer portal is still forthcoming. There is no public evidence that it sells fixed broadband, operates a last-mile network or serves a defined local access territory.
- AS211818 did operate, in a narrow technical sense. RIPE route collectors first saw it originate one IPv6
/48on 1 October 2025. The visible prefix changed during January 2026, and the replacement route was last seen on 13 May 2026. On 10 July, RIPE reported no announced IPv4 or IPv6 space and no observed neighbours. - The address resources and interconnection records point toward a European supplier chain, not a Florida access plant. Inferno Communications sponsored the ASN and controls the parent IPv6 allocation; the later
/48is registered with a Netherlands country code; and an exchange database associates AS211818 with NL-ix. None of those records identifies a rack, building entrance or physically independent circuit. - DDCatch's public website is outside AS211818: its current A record resolves into Hawk Host's AS20068 and it has no AAAA record. The website can therefore remain reachable while the company's own ASN has no visible route, and website uptime cannot be used as proof that AS211818 is operating.
- The network evidence grade is Negative for the commissioned regional-ISP hypothesis and Weak for current standalone network operation. The records prove corporate identity, number-resource control, historical IPv6 routing and route authorization; they do not prove present routing, customer traffic, access plant, usable failover, local field crews or service restoration capacity.
The first infrastructure finding is that this is not a demonstrated local ISP
The public record for DDCatch is small, but it is unusually decisive about the business it presents. The company's live homepage calls DDCatch Inc. a domain drop-catch service, provides a contact address in St. Petersburg, Florida, and says a customer portal is coming. It does not advertise an internet-access plan, a service map, an installation method, a speed tier, a network status page or a telephone support line. A reader arriving through an autonomous-system index might reasonably assume that the company is an ISP. The company's own page does not support that assumption.
The legal entity is nevertheless real. The Florida Division of Corporations record identifies DDCATCH INC as a Florida profit corporation, document number P23000055531, filed on 27 July 2023 and listed as active. It names Siarhei Kulich as president, secretary and director, and Viktar Kliuchenia as treasurer and director. The principal and mailing address is the same suite shown on the website and in the internet-number records.
That address should be read as a legal and correspondence location, not as a network point of presence. A corporate filing does not say that routers, servers, fibre entrances, technicians or customers are present at the registered office. The distinction is especially important here because the routed evidence points across the Atlantic while the website itself is hosted on a third party's network. Treating the Florida address as the physical centre of AS211818 would turn a registry field into a topology claim.
There is a similar boundary around the term "domain drop catch." An expired domain can pass through renewal and redemption stages before deletion; ICANN's Expired Registration Recovery Policy sets minimum renewal-notice and redemption practices for registrars. When a name becomes available, a drop-catch provider may try to register it for a customer. The registry interface commonly used by registrars is the Extensible Provisioning Protocol described in RFC 5730, but DDCatch does not publish its registrar relationships, registry connections, software design or fulfilment method. The business description is therefore clear while the operating system behind it is not.
The current ICANN accredited-registrar list contains no exact entry for DDCatch Inc. That does not mean the company cannot offer a drop-catch service. It could use one or more accredited registrars, act as a reseller, work through an application interface or still be preparing a service. It means only that an autonomous system and a corporate registration do not establish direct registrar status. The promised portal, the absent public offer details and the lack of a named fulfilment partner leave the commercial stage uncertain.
The correct starting proposition is consequently narrow. DDCatch is a registered company with a live informational page, a domain-related stated purpose and a public autonomous-system identity. It is not, on the evidence available on 10 July 2026, a demonstrated regional access provider. Any analysis of poles, towers, customer-premises equipment or home installations would invent assets that the company has never publicly claimed.
AS211818 was active, then its one visible route disappeared
The strongest evidence of actual network operation comes from the history of AS211818. The RIPE autonomous-system record names the network DDC-LND, links it to DDCatch Inc., records Inferno Communications Ltd as the sponsoring organisation, and marks the resource assigned. It was created on 30 September 2025. The companion RIPE organisation record ties the holder to Florida document number P23000055531. These are strong administrative facts: DDCatch controls an assigned ASN through the RIPE system.
Assignment is not the same as operation. Border Gateway Protocol makes a destination reachable only when an origin announces a prefix and other networks accept and propagate the route. The distinction is built into the protocol: RFC 4271 defines BGP as the system by which autonomous systems exchange reachability information and select paths. An ASN with no originated route is still a valid identifier, but it does not provide a public path to addresses of its own.
RIPEstat's routing history for AS211818 shows a short but genuine operating interval. Route collectors saw 2a0f:85c1:d61::/48 from 1 October 2025. That prefix remained broadly visible through the first part of 2026. A second prefix, 2a0f:85c1:dd4::/48, overlapped the first in the history around 19 January and then became the sole visible origin. The later route continued until May. This is stronger than a static registration: hundreds of full-feed peers saw reachability attributed to AS211818.
The last day matters. RIPEstat's 13 May 2026 routing snapshot reports one announced IPv6 /48, seen by all 315 IPv6 peers included in that aligned collection view. A snapshot for 14 May reports that only eight peers still saw the route, below the service's normal visibility threshold, with no announced space counted. The current announced-prefixes result is empty, and the 10 July routing-status result shows zero IPv4 and IPv6 visibility, zero announced prefixes and zero observed neighbours. It records the last observation at 16:00 UTC on 13 May.
That sequence looks like a route withdrawal, but it does not reveal cause. The company may have intentionally shut the network, changed suppliers, migrated to unobserved infrastructure, paused a test, suffered a configuration fault or allowed a session to lapse. RIPE's public collectors cannot see a private network, a route visible to fewer than their threshold, or services hosted in someone else's ASN. They can, however, settle one important point: AS211818 was not visibly originating public address space at the research cut-off.
The prefix transition also resists a simple outage story. The first /48 remains assigned to DDCatch in the RIPE records, as does the second. Both have route objects and valid route-origin authorisations. A change from d61 to dd4 therefore need not mean a transfer of the ASN. It could reflect renumbering, a location change, a supplier-side allocation change or a planned replacement. The timing in the coarse route history does not expose whether endpoints moved cleanly, whether both blocks carried traffic or whether the first prefix had any externally used host at all.
This is the central operating-status result. DDCatch crossed the line from paperwork to public routing for about seven and a half months. It then crossed back. A current description must preserve both halves: calling the ASN a mere reservation ignores the observed route, while calling it an active network ignores nearly two months with no visible announcement.
The address block came through a supplier, and its location remains bounded
The IPv6 records show an ownership chain rather than an owned global address estate. RIPE's record for the parent 2a0f:85c0::/29 identifies it as an allocation to Inferno Communications Ltd. The first DDCatch /48 record names DDC-LND, links the assignment to DDCatch and gives Inferno's maintainer control over the allocation. The replacement /48 record names DDC-NL0 and is maintained jointly by Inferno and DDCatch.
This arrangement establishes a supplier boundary. DDCatch was authorised to originate the /48; Inferno held the larger allocation from which it was carved and sponsored the ASN. The arrangement is common for a small network that is not itself a RIPE member with its own independent address allocation. It also creates a recovery dependency. If the contractual assignment, maintainer permissions, routing objects or upstream handoff fail, DDCatch may need the sponsor's action as well as its own configuration change.
It would still be wrong to turn the records into a precise map. The first /48 carries a US country code, the second carries NL, and the parent allocation carries GB. RIPE database country fields are administrative attributes; they do not prove where every router or host is physically installed. The labels DDC-LND and DDC-NL0 are suggestive, but neither expands into an authoritative facility name. "LND" could be an operator convention, and "NL0" could identify a logical site or intended geography. A label is not a rack audit.
The best independent location clue is interconnection data. The European Internet Exchange Association's IXPDB entry for AS211818 associates DDCatch with NL-ix and shows The Hague as the exchange's city. NL-ix describes itself as a distributed, pan-European fabric: its locations page lists 83 data centres across 15 metropolitan areas, including a Rotterdam grouping that covers Delft and The Hague. An NL-ix membership therefore does not by itself locate DDCatch in one building. It shows access to an exchange service whose fabric spans many facilities.
The historical route paths are consistent with that picture without completing it. A RIPE BGP-state snapshot from 13 May repeatedly shows paths ending AS34927 AS211818, while many other collector paths appear to reach AS211818 directly. Some commercial summaries consequently identified iFog's AS34927 as an upstream and a large set of networks as peers. Yet NL-ix route servers can redistribute one member's routes to hundreds of other members while keeping the route server out of the visible AS path. NL-ix's peering guide says a participant can replace many bilateral sessions with sessions to its route servers and recommends two IPv4 and two IPv6 route-server sessions for resilience.
The direct-looking paths can therefore represent exchange route-server propagation, not dozens of physical cross-connects into DDCatch's rack. The path through AS34927 is stronger evidence of upstream reach, but even it does not prove a dedicated circuit or a second independent entrance. The static RIPE policy also names AS209735, AS207841 and AS44355 in import/export statements. Those statements describe declared policy at the time the object was created; the May route snapshot does not show those three as a simple, current set of independent transit providers.
The defensible physical description is modest: DDCatch had an IPv6 origin authorised from an Inferno-controlled parent block; its route was visible through a European interconnection environment; one historical path commonly ran through AS34927; and AS211818 appeared in NL-ix membership data. Public sources do not disclose the server, router, port, cross-connect, data-centre suite, access circuit or city in which DDCatch's BGP session actually terminated.
A reachable website is not evidence that the ASN is reachable
DDCatch.com remains online even though AS211818 does not. The domain's Verisign RDAP record shows that it was registered on 2 July 2023, uses Dynadot as registrar, is delegated to dyna-ns.net name servers and is renewed through July 2027. That is a separate registry relationship from the company's autonomous-system registration.
Current DNS makes the separation visible. Google Public DNS's A response resolves the website to 103.119.217.34, while its AAAA response contains no IPv6 address. The ARIN record for the IPv4 address places the enclosing assignment with Hawk Host Inc.; current route information attributes the prefix to Hawk Host's AS20068. The page, name servers and mail endpoint can thus use infrastructure that DDCatch does not originate through AS211818.
This split is operationally sensible for a small company. External hosting can keep the public contact page reachable when the company's experimental or production edge is down. Outsourced authoritative DNS reduces the chance that the same route failure makes both the service and its domain unresolvable. A third-party host also removes the need to expose a web server from the company's one IPv6 block. But those are architectural implications of the observed separation, not claims about DDCatch's intentions.
The separation changes how an outage should be interpreted. A successful request to ddcatch.com proves that Dynadot's delegation, the selected DNS path, Hawk Host's route and the shared web server are working. It does not exercise the DDCatch ASN. Conversely, the disappearance of AS211818 does not necessarily interrupt the website or an application hosted through another provider. A status test that checks only the homepage would miss the very routing failure under examination.
It also exposes the limits of the word "capacity." The website's IPv4 address says nothing about DDCatch's former IPv6 throughput. The /48 says nothing about website load. The BGP origin says nothing about how many domain orders could be processed. These are distinct layers: public identity, application hosting, internet routing and commercial fulfilment. Their suppliers may overlap, but the available records do not prove that they do.
For a domain-catch business, that separation can be material. The customer-facing site, payment or account portal, registry-facing transaction system, monitoring and corporate email need not sit on the same network. A failure of one can leave the others alive. DDCatch publishes no production architecture, so the safe conclusion is simply that the one public service that can be tested today does not depend on AS211818 for its visible web path.
The installed-versus-usable ladder is unusually stark
Small network records often look more substantial than the service behind them because each layer records permission or design, not consumption. DDCatch provides a clean example of the difference.
An assigned ASN is an administrative capability. It allows an organisation to express an independent routing policy, but it does not create a router, a session or a route. A registered /48 is an address assignment. Under IPv6 practice, a /48 provides 65,536 conventional /64 subnets; RFC 6177 explains why end-site assignments should support flexible subnetting rather than be mistaken for a count of devices or paying customers. The enormous mathematical number of IPv6 interface identifiers inside the block is not bandwidth, server count or market reach.
A route object is another permission layer. The RIPE records contain route6 objects naming AS211818 as origin for both DDCatch prefixes. Those objects help other networks build filters, but they do not announce anything. A Route Origin Authorisation adds cryptographic authority. RIPEstat currently reports the first prefix and second prefix as RPKI-valid for origin AS211818. RPKI validation can reject an unauthorised origin; it cannot make an authorised route appear.
The next rung is a BGP announcement. For seven months, DDCatch reached that rung. Hundreds of collectors saw the route, which means the prefix was broadly propagated. Yet an announcement still does not prove that an address answered, that an application used it, that customer packets crossed it or that the path had useful headroom. IPinfo's AS211818 summary reported no IPv4, one IPv6 /48, no hosted domains and no pingable addresses in its latest scan while the route was still represented in its data. Those negative observations cannot prove an empty network, since operators can block probes and keep services private, but they caution against equating a visible prefix with a populated service.
Interconnection is another rung. Membership in an exchange can make many efficient paths available. A route-server session can spread a route widely. Neither guarantees full internet transit. Peering normally exchanges traffic only with participating networks and their permitted customers; a route server simplifies control-plane sessions but does not carry the data packets itself. RFC 7947 makes that separation explicit in its description of internet-exchange BGP route servers. A small network still needs a path to destinations not covered by its peers, whether through paid transit, a default route, a bundled exchange product or another provider.
Finally comes usable service: a healthy host, correct DNS, a successful application transaction, sufficient throughput, monitoring and someone accountable when it fails. DDCatch publishes no measurements at this rung for AS211818. There is no latency series, traffic graph, route-monitoring page, uptime statement, customer count, service-level commitment or incident history tied to the ASN. The company's only public page runs elsewhere.
The difference between installed and usable capacity is therefore not a minor qualification. DDCatch still holds the administrative components - ASN, two assigned /48s, route objects and valid origin authorisations - while the public route is absent. Almost everything required to resume is present on paper. The missing announcement shows why paper capacity and operating capacity cannot be merged.
The local bill is concentrated at the upstream and facility boundary
For a conventional regional ISP, the monthly bill spreads across poles, towers, fibre leases, customer drops, vehicles, premises equipment, spectrum, upstream transit and local labour. DDCatch has disclosed none of that access plant. Its evidenced network is closer to a compact internet edge. The likely cost categories are correspondingly concentrated, though no public contract reveals prices or vendors.
The first category is number-resource administration. The sponsoring organisation maintains the ASN relationship; the parent IPv6 holder maintains the address assignment; registry and RPKI records need to remain accurate. Some of this may be bundled with hosting or transit. It is a real dependency even when the cash amount is small, because loss of sponsorship or authorisation can prevent clean routing.
The second category is the physical or virtual place where BGP runs. It could be a hardware router, a virtual router on a server, a hosted BGP service or a combination. It needs processor and memory headroom, stable interfaces, configuration storage, secure management and monitoring. If it is in a shared facility, the operator pays directly or indirectly for rack space, power, cooling and a handoff. If it is a remote virtual machine, the cloud or hosting provider owns more of the physical chain but the dependency does not disappear.
The third category is external reach. A cross-connect or transport circuit must bring the edge to an exchange or transit network. Peering may reduce the volume sent through paid transit, but it cannot be valued from peer count alone. NL-ix's own transit description distinguishes peering routes from full transit and describes products that combine them over one port or separate VLANs. DDCatch's public paths do not reveal which commercial arrangement it bought, whether AS34927 carried default or full-table transit, or whether the exchange connection was delivered directly or through a reseller.
The fourth category is operations. Configuration backups, route filtering, origin validation, traffic monitoring, security updates and incident response consume attention even when they do not require a truck. RFC 7454 describes the filtering, maximum-prefix controls, session protection and operational discipline expected around BGP. A one-prefix network has a tiny forwarding table of its own, but it can still leak routes, accept a bad default, lose a session or become unreachable after an origin-policy mistake.
The final category is field repair, but "field" here should not be imagined as a line crew beside a road. It may mean data-centre remote hands replacing an optic, reseating a fibre, power-cycling a server, moving a patch lead or attaching a console. It may mean the upstream's technician repairing a transport link or the facility operator restoring power. Public records show no DDCatch employees, spare inventory, maintenance contract or response time. The labour exists somewhere in the chain; its employer and availability are unknown.
This concentration can make a small network inexpensive. One server, one exchange handoff and one transit arrangement can create global route visibility without a local access build. It can also make the network brittle. If all reach depends on one virtual host, one cross-connect, one facility or one supplier account, the saving is achieved by accepting a common failure point. Route visibility before May does not reveal how many of those components were duplicated.
Three apparent upstreams are not three proven recovery paths
The static AS211818 object declares imports from AS209735, AS207841 and AS44355 and exports of AS211818 to each. At first glance that looks like three upstreams. It is useful evidence of intended policy in September 2025, but it is not proof that three sessions were simultaneously established, carrying traffic and physically independent.
The observed paths tell a different, changing story. Early third-party route summaries saw AS207841 and AS209735 immediately adjacent to DDCatch's first prefix. Later views of the second prefix frequently showed AS34927. Some current data providers list AS34927 and Hurricane Electric's AS6939 as upstreams, even though many RIPE paths place AS6939 before AS34927 rather than directly before AS211818. This is why neighbour tables must be read with route-server and collector context. A provider appearing anywhere in a path is not necessarily contracted by the origin network.
At an exchange, the path can become more deceptive. NL-ix route servers deliberately let members exchange routes without maintaining hundreds of bilateral BGP sessions. The route server generally does not insert its ASN into the path, so a receiving member can see a path that ends directly at AS211818 even though the control-plane relationship runs through exchange infrastructure. A commercial database can label those adjacencies "peers" and still leave the physical delivery unresolved.
True recovery diversity requires several separations at once. The BGP sessions must terminate on components that do not fail together. Their circuits must avoid a shared cross-connect, line card, carrier tail, building entrance and conduit. Their suppliers must not buy the same underlying transport. The router must have a working policy that withdraws or de-preferences the failed path without discarding all valid reachability. The surviving path must have spare capacity. Facility power and management access must survive long enough for convergence to matter.
Nothing public verifies those properties for DDCatch. The historical snapshot proves broad propagation and at least one effective path. The declared policy proves awareness of multiple external networks. The exchange association proves access to a fabric capable of many logical peerings. Together they support a conclusion of connectivity, not resilience.
The May withdrawal is therefore the most revealing recovery test available, and it is incomplete. On 14 May a handful of collectors still saw the prefix after the main route had disappeared. That could be normal withdrawal propagation, stale state, a partial surviving session or low-visibility reach. By the cut-off, all visible paths were gone. No secondary route restored broad visibility. If the event was accidental, the public outcome indicates that whatever alternate control-plane options existed did not keep the prefix globally announced. If it was intentional, no resilience conclusion follows because the operator may have withdrawn every route by design.
What would settle the issue is not another list of peers. It would be a current route, a dated topology identifying two handoffs, evidence of separate transport and power domains, and a failover observation showing the prefix remain visible while traffic continues. DDCatch publishes none of those. The appropriate judgement is single-route exposure unrefuted, not single-route architecture proven.
Failure starts at the route, then descends into the facility
The most immediate failure path has already occurred in public view: the route can disappear. When AS211818 withdraws its /48, routers elsewhere remove that destination after BGP convergence. Any public service addressed only inside the withdrawn prefix becomes unreachable from networks that no longer have a path. A valid ROA and route object remain inert. Restoration requires the originating session to return, policy to accept the prefix and upstream networks to propagate it again.
The second failure path is an upstream or exchange loss. If DDCatch depended on AS34927 for full reach and used NL-ix primarily for peering, failure of the AS34927 handoff could leave many peer routes available but remove destinations reached only through transit. If it depended on a bundled exchange transit product, a port or VLAN failure could remove both peering and global reach despite two logical services. These are plausible structures, not established facts; the public record does not identify the purchased product.
The third is facility or server power. A router, host, optical device and management switch all need local electricity. Data centres commonly provide redundant feeds and generators, but the existence of a data-centre service does not prove that a particular customer ordered dual feeds, installed dual power supplies or cabled equipment to separate distribution paths. A virtual router can have the same weakness in a different form if its host or availability zone is singular. DDCatch publishes no backup runtime or power topology.
The fourth is a physical handoff fault. Fibre connectors become contaminated, optics fail, patch cords are moved and transport circuits are cut. A network with no local staff relies on remote hands and carrier escalation. The time to restore then includes detection, ticket acceptance, facility access, diagnosis, spare availability and authority to change the circuit. A replacement optic in a nearby locker produces a very different outage from a proprietary component shipped across a border. No public evidence describes DDCatch's spares or response arrangement.
The fifth is a configuration or security error. The change between two /48s required address, route, filtering and possibly DNS changes. A stale prefix list can reject the replacement. A maximum-prefix setting can close a session when the expected count changes. A mistaken origin or overly specific route can fail RPKI validation. RFC 9234 addresses route leaks by formalising provider, customer and peer roles, but deployment still depends on accurate bilateral configuration. DDCatch's two ROAs are valid today, which reduces one class of origin error; it does not verify session policy.
The sixth is congestion. One announced /48 can carry almost no traffic or saturate a large port; address size gives no clue. A cheap upstream link may be sufficient for a control service until a burst of domain activity, attack traffic or backup transfer coincides with ordinary load. A second path helps only if routing moves traffic to it and it has unused capacity. No traffic graph, port speed or busy-period measurement is public.
The seventh is supplier administration. Sponsored resources can be technically healthy while a commercial or compliance issue changes the relationship. A lapsed service, unresolved abuse report, failed renewal or maintainer dispute could affect the handoff or records. There is no evidence that any such event caused the May withdrawal. The point is structural: the parent allocation and ASN sponsorship sit outside DDCatch, so recovery may need coordination across corporate boundaries.
The eighth is application failure outside the ASN. The website can remain online through Hawk Host while a future portal, registration transaction or internal database fails elsewhere. It can also fail while AS211818 remains healthy. A complete incident view must test DNS, web hosting, transaction processing and the autonomous-system route separately. Public reachability of one layer should never be used to close an incident in another.
No one should infer a domain-service outage from the BGP withdrawal alone. There is no public endpoint tied to the former /48, no disclosed customer count and no report connecting May's routing change to an application interruption. The route loss establishes exposure. It does not identify affected transactions.
Who is affected cannot be counted from the public data
For an access provider, a tower outage can be translated into households, buildings or businesses. DDCatch supplies none of those units. There is no coverage map, subscriber figure, prefix-use inventory or list of hosted domains inside AS211818. The absence is not merely a reporting inconvenience; it prevents a credible impact estimate.
At the narrowest level, the affected party is DDCatch itself. Losing its only visible origin removes an independently controlled IPv6 path and any routing policy attached to it. That can reduce technical autonomy even when services continue through third-party hosting. It may also make historical addresses unusable until renumbered or reannounced.
At the next level are unknown counterparties. If the /48 hosted monitoring, private interconnection endpoints, APIs, name servers, employee access or test systems, those users could be affected. None is publicly identified. If the route was only a network experiment, the effect could be limited to the operator. A route collector cannot distinguish the two.
Website visitors are a useful control group. They continue to reach the informational page over AS20068, demonstrating that a visible corporate presence can survive the ASN withdrawal. Future customers could still be affected by a failure in a registrar partner, application host or DNS provider, but that would be a different incident chain.
There is no basis for claiming that households lost connectivity, that a region lost broadband or that local technicians were dispatched. Those outcomes belong to an access network that has not been evidenced. The only responsible impact statement is conditional: any endpoint that relied exclusively on DDCatch's withdrawn prefixes lost normal global IPv6 reach, while publicly visible services hosted elsewhere may have continued.
The evidence needed for a current operating claim is concrete
DDCatch could move from Weak to Medium evidence quickly because the missing facts are observable. A current globally visible announcement would establish that AS211818 had resumed public routing. A live route seen through more than one independent collector would reduce the chance of mistaking a narrow leak or stale view for broad service. A responding endpoint or published service address inside the originated block would show that the route carries something usable.
A facility and interconnection disclosure would answer the physical questions. It need not reveal sensitive rack details. Naming the metropolitan area, exchange handoff, transit providers and whether circuits use separate entrances would distinguish a pan-European exchange membership from a specific operating site. Stating whether BGP runs on one or two routers, and whether those routers share a host or power feed, would make redundancy assessable.
Recovery evidence would be more valuable than design language. A dated failover test could show the prefix remaining visible after one session is disabled, the surviving path, convergence time, packet loss and available capacity. A power test could state the supported runtime. A remote-hands agreement could state response hours and where critical spares are stored. These are the facts that convert "multi-homed" from a policy aspiration into an operating property.
For the commercial service, the company could identify whether it is an accredited registrar, reseller or service working through named registrar partners; publish supported top-level domains; explain the order and refund process; and launch the promised portal. That information would not prove network resilience, but it would connect the autonomous-system investment to a real customer journey.
For any future broadband claim, the evidence threshold is higher and different: a serviceable geography, access technology, address-level installation method, backhaul topology, customer demarcation, support channel and current subscribers. Nothing in the ASN record substitutes for those facts. Until they appear, the regional-ISP label should be treated as a broad catalogue placement, not a description of demonstrated operations.
A small route can still reveal a large dependency
DDCatch's case is valuable because it strips networking back to its minimum dependencies. A Florida corporation obtained a RIPE-sponsored ASN, received IPv6 space from a British allocation holder, appeared through a European exchange environment, originated one /48, changed that prefix and then disappeared from the visible routing table. Its website remained online through a Canadian hosting company's network. Every element can be true at once because corporate domicile, address sponsorship, routing location, application hosting and customer service are different layers.
The low apparent cost of such a network is the mirror image of its dependency. There is no evidenced tower estate or trenching programme to finance. There is also no evidenced independent access loop, second facility, spare path or local repair team to absorb failure. The bill is concentrated in upstream reach, a place to run the edge, resource sponsorship and the labour needed to restore a handoff. Saving at each line can reduce the number of independent components left when something breaks.
On 10 July 2026, the most important fact is negative but not empty: AS211818 is assigned and authorised, yet it is not visibly announcing. That does not erase the months in which it operated, and it does not prove that DDCatch's domain business stopped. It does mean current connectivity claims must wait for a current route. The company has shown it can create a globally visible IPv6 edge. It has not shown that the edge is active now, that it carries a public service, or that another path and a repair response stand behind it.