TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD. is best read as a thinly documented infrastructure company record linked to AS204936; public network evidence is real, but it does not by itself prove rack location, power design, server inventory or customer-ready capacity.
• The visible AS204936 footprint is IPv6-only in the current RIPEstat view, has one observed neighbouring ASN in RIPEstat, and is associated with conflicting market records, so customers should require redundancy proof before treating it as resilient hosting capacity.
• The failure path to test is practical: a leased prefix, single upstream, remote hands delay, abuse contact gap, billing dispute or facility outage can make a nominally global cloud service feel local, fragile and difficult to migrate from.

A small visible network is not the same thing as a proved cloud platform

The public record around TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD. starts with a useful but modest fact: the BTW directory profile links the company record to AS204936. RIPEstat's AS204936 overview currently shows the holder string as WISDOM-TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD., and the RIPE Database RDAP record for AS204936 maps that autonomous system to ORG-WCIT2-RIPE. Those records matter because an autonomous system is the public routing handle through which networks announce address space, take upstream reachability, and appear in the global BGP table. They do not, however, identify a data hall, a cage, a power feed, a server model, a storage platform, a support roster or a tested recovery plan. A buyer who sees the word cloud in a company name still has to ask where the machines are, who pays for cross-connects, which carriers are contracted, and what happens when the single visible path becomes unavailable.

That distinction is especially important here because the exact directory name looks like a routing label wrapped around the better-corroborated Singapore company name. RIPE's organisation entity for ORG-WCIT2-RIPE names WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD., gives Singapore as the country, lists registration number 202243723W, and identifies the organisation type as an LIR. The same RIPE organisation record gives 10 Anson Road in Singapore as the registered address. A separate Companies.sg profile describes Wisdom Cloud Internet Technology Pte. Ltd. as a live Singapore exempt private company incorporated on 2022-12-08, with principal activity Telecommunications network operation and secondary activity Telecommunications resellers/third party telecommunications providers. Those company and LIR facts are meaningful, but they still do not show that the specific BTW directory entity has an independently described hosting product or a named colocation footprint.

The safest reading is therefore narrow. TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD. is a directory entity whose public network identity is anchored by AS204936 and an alias relationship to Wisdom Cloud Internet Technology Pte. Ltd. It should not be treated as a fully documented cloud provider merely because the public Internet can see an ASN and IPv6 prefixes. The visible records support the existence of a routed network surface. They do not settle whether customers are buying VPS instances, bare-metal servers, IP transit, address leasing, mobile connectivity, reseller service, or some combination of those products.

That uncertainty is not a reason to ignore the company. It is the reason the article focuses on physical dependency, installed versus usable capacity, redundancy proof and migration paths rather than on marketing language.

What the AS204936 evidence actually says

The RIPE REST aut-num entity for AS204936 lists as-name: WISDOM-TECHNOLOGY, org: ORG-WCIT2-RIPE, status: ASSIGNED, and the maintainers RIPE-NCC-END-MNT and lir-sg-wisdom-cloud-1-MNT. It was created on 2022-05-30 and last modified on 2025-05-12. The RIPEstat whois view gives the same basic shape. This is useful provenance: the entity is not an anonymous page in a marketing directory, and it connects the ASN to a named RIPE organisation. But an aut-num entity is administrative infrastructure. It records who can maintain the route identity. It does not say how many racks are leased, whether cross-connects are diverse, whether customer servers are in Singapore, Europe, Hong Kong, the United States, or a reseller environment, or whether the support desk has twenty-four-hour operational coverage.

The routing picture is even more specific. RIPEstat's routing-status call for AS204936 shows first-seen visibility in 2018 for an IPv6 prefix and a last-seen prefix on 2026-07-15. The same call reports that zero of the measured IPv4 RIS peers see AS204936, while 322 of 322 measured IPv6 RIS peers see it. RIPEstat's prefix-count call reports zero IPv4 prefixes and 28 IPv6 prefixes in the July 2026 sample. The announced-prefixes call shows those visible announcements as /33 IPv6 slices, including families such as 2a00:e462::/33, 2a11:9601::/33, 2a12:5f47::/33, 2a13:9ac3::/33, and 2a10:bc45::/33. That is a real routing footprint, but it is not the same thing as a broadly usable hosting platform.

The absence of IPv4 visibility matters. Many customers still depend on IPv4 for control panels, inbound web service, SMTP reputation, customer VPNs, legacy monitoring, licensing servers and third-party integrations. An IPv6-only visible route surface can be valuable for transit experiments, address market activity, specialized anycast, internal connectivity or dual-stack service if paired with another IPv4 provider. It becomes risky when a customer assumes that the provider can serve ordinary cloud traffic without a separate IPv4 plan.

A buyer should therefore ask whether AS204936 is a production serving network, an auxiliary route origin, a leased-prefix test bed, or a back-office route identity. Each answer implies a different migration path. If the network is only an IPv6 surface, the customer needs a second provider for IPv4 reachability before it moves any public-facing workload.

The neighbour data also pushes the evidence grade down. RIPEstat's ASN-neighbours call for AS204936 shows one neighbouring ASN, AS55201, with IPv6 peer visibility and no IPv4 peers in that data set. Third-party market data points in the same cautious direction. The PeeringDB record for AS204936 currently appears as HT2, gives https://su.mt as a website, lists AS-HT-DW as the AS set, reports zero IPv4 prefixes, 200 IPv6 prefixes, traffic of 0-20Mbps, Europe as scope, zero exchange count and zero facility count. PeeringDB records are self-reported and can be stale. In this case they conflict with RIPE's current holder string and should not be over-weighted. Their value is negative evidence: they do not provide a named facility, a declared exchange presence or a large public traffic profile that would make redundancy easy to verify.

IPinfo's demo record for AS204936 adds a different perspective: it names Wisdom Cloud Internet Technology Pte. Ltd., identifies the registry as RIPE, tags the type as hosting, reports no IPv4 addresses, and lists IPv6 netblocks whose names point to address-market or upstream organisations such as IP MARKET - FZCO, R-TEL LIMITED, NETLABS LLC and LLC IT NETWORKS CHAT. This is useful because it shows the address surface is not a simple story of a single owned datacentre block. It appears to involve routed IPv6 resources associated with other address holders or networks. That can be legitimate. Hosting and network-service firms often route leased, delegated or customer-held address space. But it changes the operational question. The customer has to know which party controls the ROA, which party can change the route object, which party handles abuse reports, and which party keeps the address block available when commercial terms change.

The physical dependency behind the name

A cloud or hosting service has to become physical somewhere. The AS204936 records do not name that somewhere. They identify Singapore registration, RIPE LIR administration, IPv6 routing, a NOC role and a small visible neighbour set. If the company is selling hosted capacity, the customer-facing service still depends on racks in one or more data centres, cross-connects from those racks to transit or peering partners, usable electrical capacity, cooling, hardware spares, remote hands, monitoring, backup storage, account management and a way to export workloads.

Those dependencies may be inside a leased colocation room, a wholesale cloud partner, a carrier-neutral facility, a downstream reseller arrangement, or another provider's network. The public record does not disclose which.

The difference between registered address and operating site is central. The RIPE organisation record lists 10 Anson Road, while the RIPE NOC role entity lists 260B Ang Mo Kio Street 21 and a phone number. Companies.sg also notes the 10 Anson Road registered office and describes that unit as a high-density registered address. None of those addresses should be assumed to be a data centre. Registered offices, NOC contacts and legal addresses often serve administrative purposes. The operating racks could be in another Singapore facility, in Hong Kong, Japan, Europe, North America, or entirely inside a reseller partner. If a buyer needs data locality, Singapore law exposure, low-latency Singapore access or regional disaster recovery, it should not infer location from a registration line. It should request facility names, service addresses, data-processing locations, remote-hands arrangements and written notice periods for relocation.

Power is the next hidden dependency. A provider can have an assigned AS and visible prefixes while still relying on one cabinet, one power feed, a single wholesale host, or a partner's oversold rack. Installed electrical capacity is the rated or contracted power that could be delivered to the cage or rack. Usable capacity is what remains after redundancy rules, breaker limits, cooling headroom, reserved failover space, server power draw, storage growth, and supportable spare inventory are accounted for. AS204936's 28 visible IPv6 prefixes do not say how many servers can be powered.

PeeringDB's no-facility declaration does not prove there are no racks, but it also does not prove there are any. A customer should ask for power draw per rack, A/B feed design, UPS and generator coverage, measured monthly utilisation, maintenance windows and the number of cabinets that can survive one feed or upstream failure.

Routing is the other physical layer. Internet service is not simply an ASN in a database. It is routers, optics, cross-connects, transit contracts, filter rules, route objects, RPKI status, DDoS handling, and staff who know how to change policy during an outage. RIPEstat's single observed neighbouring ASN for AS204936 makes a specific redundancy question unavoidable: is the production path actually single-homed, or is the data set only seeing one current upstream because the other path is private, inactive or not visible from RIS collectors?

If it is single-homed, a failure at AS55201, a filtering dispute, a session reset, a billing problem or a maintenance event can disconnect the visible network. If it is multi-homed in practice, the provider should be able to show looking-glass output, BGP communities, route-policy documents and incident evidence that prove the second path carries traffic.

Support labour is physical in a different way. It is the difference between a ticket number and a person with access to the right cage, router, console server or escalation contact. A Singapore LIR record with an abuse contact is not the same thing as a support operation that can replace a failed SSD at 03:00, coordinate a carrier maintenance event, restore a customer's VLAN, or produce a clean data export before an account suspension. The public records around AS204936 give administrative contacts and a website reference, but not a support SLA, a network status page, a maintenance archive or a published escalation ladder.

That matters because small hosting providers often fail slowly before they fail abruptly: billing confusion, unanswered abuse notices, delayed renewals, unavailable spares and unclear ownership of leased IP space all create outages before a cabinet goes dark.

Installed capacity versus usable capacity

For AS204936, installed capacity is difficult to establish from public material. The route surface shows IPv6 announcements; the RIPE route6 search for AS204936 shows route6 objects for large /29 IPv6 aggregates such as 2a00:e460::/29, 2a0c:65c0::/29, 2a0d:b140::/29, 2a10:bc40::/29 and 2a12:5f40::/29, with maintainers including NETWORK-SUPPORT-MNT, IPSERVICES-MNT and DEMENIN-MNT. Those entities indicate permission or intent to originate routes. They do not show server count, bandwidth commit, cooling capacity or customer entitlement. A route object is a control-plane artifact; it says something about who can publish a route, not how much compute capacity exists behind it.

Usable capacity is a stricter test. It asks how much service a paying customer can actually consume while staying inside supportable limits. A single /33 IPv6 announcement can contain an enormous number of addresses, but address count is not a compute pool. Customers cannot run applications on address count alone. They need CPU, memory, storage, network throughput, DDoS tolerance, snapshot capability, backup bandwidth, replacement hardware and a support team. The visible evidence does not show those ingredients. If AS204936 is part of a VPS or hosted-service offer, the provider should be able to state how many nodes are in service, which facility or wholesale platform hosts them, what network commit is purchased, how oversubscription is governed, what happens when the upstream is saturated, and how long it takes to migrate a customer to another node or another provider.

That separation becomes more urgent because the public evidence contains mismatches. RIPEstat currently sees 28 IPv6 prefixes; PeeringDB self-reports 200 IPv6 prefixes and very low traffic; IPinfo lists an IPv6-only hosting type and names third-party address holders. None of those views is necessarily wrong, because they measure different surfaces at different times. Together, though, they make a warning label. Customers should not treat any single data set as a capacity statement.

They should ask for a current looking glass, a route-origin authorization report, an inventory of active upstreams, a list of facilities used for customer traffic, and a migration rehearsal. Without those documents, the safest capacity grade is installed route capacity visible, usable hosted capacity unproven.

Failure paths customers should test before relying on it

The first failure path is upstream dependency. If AS204936 is effectively single-homed through one neighbouring network, a failure in that neighbour can make every announced prefix unreachable even while the company, the servers and the DNS records remain intact. The operational test is simple: ask the provider to demonstrate how traffic exits during an upstream maintenance window, how quickly routes converge when the primary session is withdrawn, and whether customer IP space remains reachable through another carrier.

If the answer relies on manual intervention, ask who is awake, who has router access, and what the target restoration time is.

The second failure path is address control. Several IPv6 blocks visible through AS204936 appear to be associated with other organisations in IPinfo or RIPE route records. If the company routes delegated address space, a customer has to know what contract governs that delegation. Can the upstream or address holder revoke the block on short notice? Does the provider control RPKI? Are route objects maintained by the provider, by the address holder, or by a broker? If abuse complaints arrive, who answers them and how quickly? Address-space disputes are not abstract governance issues.

They can make a customer's servers disappear from the Internet even when the servers are physically healthy.

The third failure path is facility opacity. When the public record does not name a facility and PeeringDB shows no facility count, customers must assume the data-centre dependency is unverified until the provider proves otherwise. A rack outage can start with a breaker trip, a failed top-of-rack switch, a maintenance error, an unpaid colocation invoice, a remote-hands queue, or a cooling issue. The customer should ask for written evidence of data-centre location, cabinet ownership or lease, A/B power design, cross-connect ownership, hardware replacement process, and backup access.

A provider may decline to disclose sensitive details publicly, but it should be able to disclose them under a commercial agreement to a serious customer.

The fourth failure path is support continuity. The RIPE abuse contact and NOC role show that there is a nominal administrative channel, but they do not show a support rota. For infrastructure customers, the most damaging outage is often not the first failure; it is the silence after the first failure. If a router session goes down, a disk array fails, a remote console cannot be reached, or a billing flag suspends a server, customers need accountable escalation.

They should test a low-risk support request before migrating production workloads, ask for after-hours coverage, and confirm whether the same team controls network, compute, billing and abuse response. Fragmented support is especially dangerous when the service is built on leased racks or third-party address space.

The fifth failure path is migration lock-in. Thinly documented hosting providers can be attractive because they offer low-cost IP space, fast provisioning or niche connectivity. They become dangerous when customers cannot move. A customer should maintain off-provider backups, external DNS control, exported VM images, infrastructure-as-code templates, independent monitoring, an alternate IPv4 and IPv6 provider, and a tested restore path. The provider's own migration promise is not enough. The customer should prove that it can rebuild the service elsewhere before the first invoice dispute, abuse escalation or route withdrawal occurs.

Who is affected if the system fails

The affected parties depend on what AS204936 is actually carrying. If it is only an internal or auxiliary IPv6 route origin, the impact may be limited to experimental services, address-leasing customers, or a small set of downstream networks. If it supports hosted servers, the affected group expands to web publishers, SaaS operators, resellers, VPN users, DNS operators, monitoring endpoints, mail operators and customers whose backup paths depend on IPv6 reachability.

If the company is acting as a reseller behind another cloud or colocation provider, customers may not even know that AS204936 is part of their dependency chain until traceroutes, abuse reports or outage notices reveal it.

Regional impact is also ambiguous. The company registration is Singaporean; PeeringDB's older AS204936 record says Europe; IPinfo lists IPv6 resources associated with address holders in the UAE, Hong Kong, Great Britain and Ukraine; the BTW directory categorises the service area as global. This is not unusual for address routing, but it matters for customers who care about jurisdiction, latency or data residency. A server bought from a Singapore-registered company may run outside Singapore. A prefix whose holder is in one country may be routed from another.

A customer with regulatory obligations should require a written data-location statement and a list of jurisdictions involved in support access, backups and network routing.

The dependency can also affect peers and upstreams. A poorly filtered route, an RPKI mismatch, an abuse flood or a sudden withdrawal from a small AS can create operational work for neighbours even if the customer base is small. If AS204936 depends heavily on one neighbour, that neighbour becomes the practical choke point for route propagation, DDoS tolerance and incident communication. If route objects are maintained by several third-party maintainers, coordination becomes part of the outage surface. The more parties required to restore service, the longer the repair path can become.

What redundancy proof should look like

A credible redundancy package for TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD. would start with topology. The provider should show active upstreams, not just planned or available carriers. It should show route propagation from more than one upstream, current BGP sessions, maintenance history, route filters, RPKI status and the conditions under which traffic will fail over. A screenshot is not enough. Customers should ask for dated, independently reproducible evidence: looking-glass output, RIPEstat comparisons, route collector views, or test windows during which one upstream is intentionally withdrawn.

The package should then show facility resilience. That does not require publishing rack numbers to the world, but it does require commercial proof to customers: facility name, country, city, power design, cooling class, cross-connect providers, remote-hands SLA, spare hardware policy, backup media location and the process for moving workloads to a second site. If the provider uses a wholesale platform, it should say so. A reseller can still be reliable when it is honest about the boundary between its own support desk and the underlying operator. It becomes risky when the customer is told only that the service is global.

Capacity proof should separate installed, committed and usable capacity. Installed capacity includes racks, circuits, routers and address entities that exist. Committed capacity is what the provider has purchased from upstream and facility vendors. Usable capacity is what customers can consume while redundancy still holds. A provider with one 10Gbps port but a 1Gbps commit, one power feed, limited spares and no second site cannot honestly sell the same resilience as a provider with diverse transit, tested restore plans and spare power. For AS204936, the public record does not reveal those numbers. The buyer must request them.

Support proof should include response history. Customers should ask for an incident-report sample, maintenance notice template, escalation path, abuse handling SLA and data-export commitment. A small provider may have excellent support, but the evidence has to come from actual operational practice. In a thinly documented environment, support is the redundancy layer that customers often underestimate. If there is no second facility and no second upstream, the only remaining recovery asset is the speed and authority of the people handling the incident.

How to migrate or use the service without concentrating risk

The safest way to use a provider with this evidence profile is to treat it as a component, not as the only home for a service. Keep DNS outside the provider account. Use short TTLs where appropriate, but do not rely on DNS alone for emergency restoration. Keep object storage, backups and configuration in a separate jurisdiction or at least a separate provider. For workloads that need IPv4, do not rely on an IPv6-only visible AS as the sole public path. Place a second cloud, VPS or bare-metal provider in the design before moving production traffic.

For web applications, the migration pattern is straightforward. Run the application from images or declarative configuration that can be rebuilt elsewhere. Store databases with off-provider backups and test restoration. Use an external CDN or load balancer only if it can point to a second origin. Keep certificate automation independent of a single server. For mail, maintain a secondary provider or a tested emergency relay. For VPN or access services, maintain a second endpoint on a different ASN.

For customers using address space routed through AS204936, keep proof that the addresses can be withdrawn, transferred or replaced without destroying the service.

For businesses buying IP transit, hosted routers or address-market services, the migration issue is more subtle. The customer should document BGP communities, route objects, ROAs, prefix filters, abuse contacts and commercial notice periods. It should know whether a leased prefix can move to another origin AS, whether the prefix holder must approve the move, and whether the provider will cooperate during a dispute. Address portability is not a detail to leave for the outage day. It is part of the purchase.

The procurement test for a narrow IPv6 surface

A serious buyer should turn the weak public footprint into a structured procurement test. The first set of questions should be about identity. Which legal entity signs the contract? Is the counterparty TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD., Wisdom Cloud Internet Technology Pte. Ltd., a reseller using the Wisdom Cloud brand, or another affiliate? Which entity controls AS204936? Which entity issues invoices? Which entity answers abuse notices and maintenance notices? These questions sound clerical, but they decide who has authority when a route has to be withdrawn or a server has to be moved.

If the sales contact, ASN holder, facility customer and billing entity are different parties, the customer needs that boundary in writing.

The second set should be about service geography. AS204936's public evidence points to Singapore registration, a RIPE LIR organisation, and IPv6 resources associated with several non-Singapore address contexts. That does not tell customers where packets enter the network or where disks store data. A buyer should ask for a list of countries involved in customer data storage, backup storage, support access and network routing. It should also ask whether the provider can guarantee that a workload remains in one jurisdiction.

If the answer is no, the provider may still be useful for test environments, IPv6 experiments, low-risk services or transit-adjacent work, but not for workloads whose contracts require tight data-location control.

The third set should be about operational evidence from the last ninety days. Ask for a current route collector view, a current list of announced prefixes, a current upstream list, a current route object and ROA summary, and at least one recent maintenance notice. Public records show that the route surface changes over time; a due-diligence packet from 2025 is not enough for a 2026 purchase. Customers should require dated evidence, not a generic statement that redundancy exists. They should also ask whether all customer traffic uses AS204936 or whether AS204936 is only one part of a larger service.

If the actual service uses another AS for IPv4, the customer needs that AS in its dependency map.

The fourth set should be about failure ownership. Suppose AS55201 is unavailable, a route object is filtered, or a delegated IPv6 block is withdrawn by the address holder. Who opens the upstream ticket? Who can alter route policy? Who can contact the address holder? Who tells customers whether the issue is provider-side, upstream-side or registry-side? How long before the provider will move a workload to another upstream or another facility? These questions are more useful than asking whether the provider is reliable in general. They force the seller to describe the actual repair path.

The fifth set should be about exit rights. If the customer cancels service or the provider loses a routed block, can the customer export virtual machines, receive storage snapshots, keep reverse-DNS records for a transition period, move assigned addresses, and receive written confirmation that data has been deleted? If the service is IPv6-only, can the customer obtain a replacement IPv6 block elsewhere quickly? If the provider is also handling DNS, can DNS be moved without account approval from the same support queue that might be failing? A small provider can be perfectly acceptable when the customer has a tested exit.

It becomes a systemic risk when the customer has no independent copy of data or identity.

Signals that would improve or weaken the grade

Several pieces of evidence would improve the grade. A public or customer-shareable facility statement would help. A list of active upstream carriers, even without commercial rates, would help. A looking-glass page showing AS204936's live routes would help. A status page with historical incidents would help. A published product page explaining whether the service is VPS, bare metal, transit, mobile connectivity or address routing would help. A clear statement that IPv4 is supplied through another AS, or not supplied at all, would prevent customers from making unsafe assumptions.

Dated RPKI and IRR evidence would help customers assess route stability.

Several signals would weaken the grade. If the provider cannot explain why PeeringDB and RIPE disagree on the AS204936 profile, customers should be cautious. If support cannot name the active upstream, that is a serious warning sign. If the company claims facility diversity but cannot provide even city-level evidence under a commercial discussion, the claim should be treated as unproven. If address blocks are leased without customer notice periods, the migration risk is high.

If there is no documented process for route withdrawal, abuse escalation or data export, customers should assume that the repair window will be long when a commercial dispute or upstream failure occurs.

The important point is that none of these tests requires the provider to publish sensitive rack numbers or customer lists. It requires the provider to prove the operating model to the customer that is being asked to rely on it. In infrastructure, trust is not built from a company name or a route count. It is built from repeatable evidence that the same service can survive foreseeable failures. AS204936 gives enough evidence to start that conversation. It does not give enough evidence to end it.

For procurement teams, that gap should remain visible in every service review, renewal discussion and incident rehearsal.

The editorial grade

The evidence grade for TECHNOLOGY WISDOM CLOUD INTERNET TECHNOLOGY PTE. LTD. is Weak to Medium, depending on the claim. It is medium for a basic network-identity claim: AS204936 is visible, assigned, tied to WISDOM-TECHNOLOGY, connected to ORG-WCIT2-RIPE, and observed in IPv6 routing data. It is weak for cloud-service capacity: there is no public proof of rack location, facility count, power design, upstream diversity beyond one observed neighbour, support depth, hardware inventory, customer base, backup architecture or tested migration process. That difference is the whole story.

The company may be a legitimate infrastructure operator, a reseller, an address-market entity, a mobile or telecom brand with a network side, or a combination of those roles. The public material does not settle the operating model. Customers should therefore treat the visible route surface as a starting point for diligence, not as a substitute for diligence. The practical question is not whether AS204936 exists. It does.

The practical question is whether the company can keep a customer's workload alive when a carrier session drops, a leased address block changes, a facility has maintenance, a router needs replacement, or an account has to be moved quickly.

Until that proof is supplied, the right purchasing posture is cautious. Use the service only where the workload can tolerate interruption, or pair it with another provider from the start. Demand evidence for facility, power, routing and support claims. Separate installed route capacity from customer-usable hosting capacity. Keep exports and backups independent. A small provider can be valuable precisely because it offers flexible routing, niche IPv6 capability or responsive commercial terms. But the economics of small hosted capacity still run through racks, transit, power, hardware and people.

AS204936 makes the network visible; it does not make the dependencies disappear.