AS60077 Reveals a Routing Edge, Not Cloud.ir's Full Delivery

Summary

RIPE RDAP identifies AS60077 as the active AT-CLOUD autonomous system registered to ORG-ADA42-RIPE / Asre Dadeha Asiatech, while RIPEstat observed 18 originated IPv4 prefixes, 14,080 IPv4 addresses, and visibility from 324 of 325 reporting RIS IPv4 peers on 20 July 2026.
The same routing snapshot showed no current visible originated IPv6 prefixes and only one observed neighbour, AS43754. A single appearance of 2a05:1a30::/34 on 13 July is evidence of a timestamped announcement, not proof of an ongoing customer IPv6 service.
Cloud.ir maintains a live customer-facing catalogue spanning cloud servers, VPS, cloud data center, cloud switch, domain management, CDN, and storage. Its claims about Asiatech data centers, ISO27001, TIA-942, and Tier 2/3 characteristics remain operator statements in this source set rather than independently verified facility evidence.
AS60077 proves that a current IPv4 control surface exists. It does not, by itself, establish which Cloud.ir services use that network, where workloads physically run, whether an independent upstream path exists, how much capacity customers can use, or how service restoration works outside the narrower guarantees and exclusions in Cloud.ir's SLA.

The clearest evidence sits at the network edge

Cloud infrastructure is often described from the product inward. A provider lists virtual machines, storage, data-center services, connectivity features, and support promises, then asks the reader to infer the operating system beneath them. AS60077 allows the analysis to begin in the opposite direction. It supplies a measurable network identity before the product language begins.

RIPE RDAP lists AS60077 as active under the name AT-CLOUD. The record associates it with ORG-ADA42-RIPE and Asre Dadeha Asiatech. It gives an autnum registration date of 27 June 2022 and a last-changed date of 23 January 2026. Those fields are not a complete corporate history, but they are useful anchors. They establish that the autonomous system is not merely a name left on an old webpage and that its registry record was maintained relatively recently before this article's source capture.

RIPEstat adds an observed routing state. At the query time of 20 July 2026 at 08:00 UTC, its AS overview named the holder as AT-CLOUD Asre Dadeha Asiatech and marked the network as announced. Its routing-status view then supplied the more operational numbers: 18 visible IPv4 prefixes, 14,080 IPv4 addresses, and 324 of 325 reporting RIS IPv4 peers seeing the autonomous system. It recorded 193.151.156.0/24 as a last-seen prefix at 16:00 UTC that day.

That is strong evidence of a live public routing surface. It is also point-in-time evidence. Routing tables change, collector visibility has limits, and an autonomous system is not the same thing as an entire cloud product. The correct inference is therefore narrow but meaningful: Asre Dadeha Asiatech had a currently announced and broadly observed IPv4 origin at the time of capture. The record does not prove that every Cloud.ir server, storage volume, CDN node, or customer connection traverses AS60077.

This distinction matters because names can make separate layers look interchangeable. CLOUD Asre Dadeha Asiatech is the directory entity. Asre Dadeha Asiatech is the organization named in the network records. AT-CLOUD is the registered AS name. Cloud.ir is the customer-facing service identity found on the official pages. The sources connect these layers, but they do not provide a packet-level map from every advertised product to AS60077. Treating the AS as visible is justified. Treating it as a complete diagram of Cloud.ir is not.

Eighteen IPv4 prefixes form a substantial public signal

The prefix inventory gives AS60077 more substance than a single route or a dormant registration. RIPEstat's announced-prefixes data showed active IPv4 announcements across several address blocks: 78.110.112.0/21; 85.198.8.0/22 and 85.198.12.0/22; the smaller 85.198.16.0/23, 85.198.19.0/24, 85.198.20.0/23, and 85.198.22.0/23; a sequence of /22 blocks from 193.151.128.0/22 through 193.151.152.0/22; and /24 announcements from 193.151.156.0/24 through 193.151.159.0/24.

For an infrastructure researcher, that inventory answers several basic questions. There is more than one originated block, and the inventory contains several address blocks rather than one isolated /24. The network was visible through nearly all of the reporting IPv4 peers in the RIPEstat routing-status snapshot. A third-party routing summary from bgp.tools independently described AS60077 as an active network, attributed 18 originated IPv4 prefixes to it, named AS43754 as its upstream, and applied a Server Hosting tag.

None of those observations reveals how the addresses are allocated to customers. A prefix may support cloud servers, management systems, shared services, internal platforms exposed to the internet, or other workloads. The packet does not assign product, tenant, region, or utilization labels to individual routes. Even the aggregate count of 14,080 IPv4 addresses is an address-space observation, not a statement that 14,080 addresses are available for sale or currently used by customers.

RIPEstat's routing-consistency data provides another useful boundary. The IPv4 prefixes seen in BGP for AS60077 also appeared in RIPE Whois. That alignment reduces one kind of ambiguity: the active public announcements were not detached from the corresponding registry data in this snapshot. At the same time, the consistency view contained broader or component ranges that were present in Whois but not in BGP. Registered space and routed space are therefore not interchangeable lists.

A registry entity can describe a range without proving that the same range is currently originated, and a broader registration can contain only some components that are visible as routes.

The same caution applies to routing policy records. AS43754 appeared in both the BGP and Whois import/export evidence. AS212895 appeared in Whois import data but not in the observed BGP view. That difference does not justify calling AS212895 a current path, a standby path, or an independent redundancy mechanism. It is evidence that a policy reference existed in the registry data used by RIPEstat. Without a matching observed route relationship in this packet, the operational meaning remains unresolved.

The result is a well-defined control-plane finding. AS60077 was not merely registered; it originated a diversified set of IPv4 prefixes that was broadly visible. The finding is stronger than a marketing claim and weaker than a service-capacity audit. It tells customers and peers that a public routing edge exists. It does not tell them what lies behind each address, how heavily that infrastructure is loaded, or which physical dependency would become decisive during a failure.

Visibility through collectors is not a map of delivery

The figure of 324 out of 325 RIS IPv4 peers is striking because it shows reach across the collectors contributing to that snapshot. It should not be converted into a percentage availability promise. Collector visibility answers whether reporting peers carried paths to the origin. It does not measure application response, packet loss to a particular customer, congestion on a private interconnection, capacity inside a facility, or the state of a virtual machine.

This is where public network research can become overconfident. A route that is widely propagated is a necessary part of reaching an internet service at those addresses, but propagation is only one link in delivery. The server may still be unavailable. A customer workload may be isolated by configuration. A storage dependency may fail while the route remains perfectly visible. Conversely, a service can use network paths that do not appear under the autonomous system a researcher expects. The source packet does not trace Cloud.ir products end to end, so it cannot close any of those possibilities.

The time labels also matter. RIPEstat reported the AS overview at one query time and identified a last-seen prefix at another time on 20 July. Those observations support a current snapshot, not a continuous history of all 18 prefixes or a guarantee about the next day. The last-changed date in RIPE RDAP shows registry maintenance, not continuous routing. The service sitemap's 2025 and 2026 modification dates show that official product pages were maintained, not that each underlying system passed an availability test on those dates.

A disciplined reading keeps each timestamp attached to the claim it supports. On 20 July, AS60077 appeared announced and broadly visible over IPv4. In the captured official web surface, Cloud.ir presented a current service catalogue. The article can combine those facts into a picture of an active public operation, but it cannot fill the gap between the route collector and the customer workload with assumptions about physical placement or performance.

That gap is not a technicality. It is the central due-diligence problem in this case. The public record is unusually specific at the edge and sparse behind it. The more accurately the edge can be measured, the more tempting it is to treat the rest of the platform as equally documented. It is not.

IPv6 appears as a trace, not a current service claim

The IPv6 evidence demonstrates why a source packet needs both route history and current routing status. RIPEstat's announced-prefixes data contained 2a05:1a30::/34, but only for one timestamp on 13 July 2026. In the routing-status snapshot used here, AS60077 had zero visible originated IPv6 prefixes and was seen by zero of 321 reporting RIS IPv6 peers. bgp.tools likewise summarized the network with zero originated IPv6 prefixes.

The safe conclusion is not that Cloud.ir has no IPv6 service. Public route collectors cannot rule out every customer arrangement, another origin ASN, a non-public use, a service delivered through a partner, or a later routing change. None of those alternatives is proved by this packet either. The evidence supports only a narrower statement: the source capture did not show AS60077 currently originating IPv6 space, and the one listed 2a05:1a30::/34 appearance was too brief to establish an ongoing public origin.

That distinction has practical value. A buyer looking for native IPv6 should not treat the historical timestamp as confirmation. It would need a current product-specific answer: which Cloud.ir services expose IPv6, which autonomous system originates the relevant route, whether addresses are assigned to customers, and what support or availability terms apply. The packet does not supply those answers.

Nor should the absence of a current visible origin be turned into a claim about engineering capability. It says nothing definitive about plans, internal deployment, hardware readiness, or customer demand. It is an observation about the public control plane at the captured time. The difference between "not visible in this routing snapshot" and "does not exist" is small in wording and large in evidentiary quality.

AS60077's IPv4 evidence is therefore current and broad. Its IPv6 evidence is historical and momentary. Keeping those two states separate prevents a familiar reporting error in which any appearance of a prefix becomes a permanent feature of the provider. For this article, 2a05:1a30::/34 is a limitation marker: it shows that the data was sensitive enough to capture a brief event, while also showing why that event cannot carry a larger service claim.

A valid route origin is not a resilience certificate

One AS60077 prefix has an additional layer of validation. RIPEstat's RPKI check for 193.151.156.0/24 returned valid, with ROAs that authorized origin 60077 for the prefix. RIPE RDAP resolved the address to an active assigned PA range named IR-AT-20210316, with country code IR, covering 193.151.128.0 through 193.151.158.255. The registration named ASIATECH-MNT and Asiatech NOC in the administrative and technical contact material.

Together, those sources create a coherent chain for the sample. The range exists in the registry. The maintenance and contact identifiers point back into the Asiatech operating context. AS60077 was observed originating the /24. The RPKI result said that the origin was authorized by the validating ROAs at query time. This is exactly the kind of layered evidence that makes a routing claim more credible.

It still answers only a routing question. RPKI validity does not certify a data center, audit a cloud control plane, measure available bandwidth, confirm an upstream failover, or guarantee that a customer can recover data after an incident. It does not show whether the server answering on an address is healthy. It does not establish that every one of the 18 IPv4 prefixes has the same validation state, because the packet records a specific validation result for 193.151.156.0/24.

The value of the result lies in its precision. It is better to say that this currently announced sample had a valid origin than to generalize about the security of the whole service. It is also better to recognize that route authorization and service assurance solve different problems. One helps networks reject an origin that is inconsistent with published authorization. The other requires evidence about systems, facilities, people, procedures, contractual scope, and recovery.

The RDAP range deserves the same care. An active assigned PA registration supports the address-space relationship. The country field and contact identifiers provide registry context. They do not locate a particular server room, prove where a customer workload resides, or establish that the entire registered range is currently routed by AS60077. Indeed, the upper boundary described by RDAP and the mix of observed /22 and /24 announcements show why address registration must be read alongside, rather than substituted for, BGP evidence.

This sample is therefore one of the strongest pieces of the public record and one of the clearest demonstrations of its limit. The route can be tied to an authorized origin with named registry contacts. The physical and operational chain behind the route remains undocumented by those same sources.

The observed topology narrows to AS43754

RIPEstat's neighbour view returned one observed neighbour for AS60077: AS43754. The routing-consistency data also showed AS43754 in the BGP relationship and in the corresponding Whois import/export material. RIPEstat and RIPE RDAP identify AS43754 as active and held by Asiatech Data Transmission company. bgp.tools presents the same ASN as AS60077's upstream.

That convergence makes AS43754 a material part of the visible dependency picture. It is not just a policy string found in an old record. It appeared in the observed routing relationship, was active in the registry and overview sources, and was independently summarized as the upstream. The public view available to this packet therefore points from AS60077 to a single observed network neighbour within the wider Asiatech context.

What it does not show is independent upstream redundancy. Because AS43754 is identified as Asiatech Data Transmission company, its appearance cannot be treated as evidence that AS60077 has a separately controlled external path. The source packet found no second observed BGP neighbour that could support such a claim. AS212895's presence in Whois import data does not change that conclusion because it did not appear in the packet's observed BGP view.

The wording must remain exact. "One observed neighbour" does not mean "only one connection exists in reality." Public routing datasets can miss private arrangements, backup configurations that were inactive during capture, internal paths, or relationships not exposed in the selected view. The packet did not audit router configurations or obtain a network diagram. It can say that no independent multi-upstream path was verified, not that no other path is technically possible.

This difference is especially important when the subject is a cloud service. A provider can build redundancy at many layers, and not all of it appears as a distinct public neighbour. Multiple physical circuits could terminate into one upstream ASN. Different facilities could use the same upstream organization. Internal traffic engineering could change paths without changing the neighbour count visible to collectors. None of those configurations is demonstrated here. They remain possibilities, not findings.

From a customer's perspective, the current public picture raises a focused question rather than delivering a verdict. If AS43754 has an operational problem, what alternate route, if any, carries the address space originated by AS60077? Is that alternate independently operated, physically separate, and regularly tested? Does it cover all customer-facing prefixes or only a subset? The sources do not answer.

The question matters because an ASN relationship can reveal organizational concentration even when it cannot reveal every physical circuit. AS60077 is visible as a distinct origin, but the one observed upstream is another Asiatech network. That may be a deliberate architecture and may operate reliably. The evidence simply does not establish an independent failure domain. A route map that stops at AS43754 should not be presented as a completed resilience map.

PeeringDB records the network but leaves the physical map blank

PeeringDB has a current network record for ASN 60077 named Asre Dadeha Asiatech. The record's network and RIR status fields are both ok. That supports the basic identity chain and shows that the ASN has a recognized entry in a widely used interconnection directory.

The rest of the public profile is notable for what it does not disclose. At capture time it reported ix_count=0 and fac_count=0. It listed no website, looking glass, route server, policy URL, traffic level, or geographic scope. Those fields do not establish that the network has no facilities, no exchange connection, no traffic, and no routing policy. A zero or empty field in PeeringDB is evidence about disclosure in that record, not definitive proof about the underlying infrastructure.

That caveat should not make the zeros meaningless. PeeringDB is one of the places where network operators can make facility and interconnection relationships publicly legible. In this case, the record cannot be used to corroborate an exact metro, an internet exchange attachment, a facility presence, a public peering fabric, or a disclosed traffic scale for AS60077. The blank physical map therefore survives the source check.

The result contrasts sharply with the BGP view. RIPEstat can count prefixes and observing peers. RPKI can validate a sampled origin. RDAP can name the organization and address contacts. PeeringDB, however, contributes no facility attachment that connects those routes to a named building or site. The public record becomes less detailed precisely where the analysis moves from logical reachability to physical delivery.

That absence also prevents an easy redundancy claim. Two facility records in different locations would not by themselves prove independent power, transport, staffing, or failover, but they would at least create public entities that could be checked. Here there are no such AS60077 facility entries in the captured record. The source packet cannot compare sites, confirm metro separation, or test whether multiple service locations share the same underlying dependency.

The responsible interpretation has two parts. First, Asre Dadeha Asiatech maintains an active network identity with a PeeringDB record in good standing. Second, that record supplies no public facility or exchange evidence for AS60077. It is neither fair nor accurate to convert the second statement into an accusation that facilities do not exist. It is equally inaccurate to let Cloud.ir's product pages fill the gap as if a commercial description were a facility inventory.

Public verifiability is itself an operational attribute for buyers, peers, and researchers. It affects how quickly an outside party can understand concentration and reach the right technical contacts. AS60077 is easy to find as a route origin and difficult to map as a physical service. That asymmetry is one of the article's central findings.

Cloud.ir presents a current and broad service surface

The official service side is not dormant. Cloud.ir was reachable over HTTPS during source collection. Its homepage and service sitemap presented active pages for cloud servers, VPS, cloud data center, cloud switch, cloud domain management, CDN, and cloud storage. The sitemap showed 2025 and 2026 modification dates for core service pages, supporting the view that this is a maintained customer-facing catalogue rather than an abandoned archive.

Cloud.ir's own account says the cloud service began in Iranian year 1399, offers more than 20 cloud products, and runs on Asiatech data centers in Iran. Those statements help define how the operator wants customers to understand the platform. The contact page also provides a current sales and support surface. Together, the official pages support a finding of active commercial presentation.

They do not independently establish customer scale. A product page does not count active tenants, disclose sold or spare resources, identify the addresses used by each service, or prove that an advertised feature is available in every deployment. The packet contains no customer roster, utilization record, service-by-service route trace, or audited inventory. It would therefore be a mistake to use the breadth of the menu as a proxy for the breadth of physical capacity.

The relationship to AS60077 must be framed with the same restraint. The network records name Asre Dadeha Asiatech, and the official service pages situate Cloud.ir on Asiatech data centers. That is enough to analyze a connected public operating surface. It is not enough to say that all Cloud.ir services are delivered from AS60077. A CDN, storage service, cloud switch, management plane, or customer VM could have a delivery path that differs from the public origin a researcher sees. The packet does not resolve those product-level paths.

This is not a reason to dismiss the product pages. They establish what customers are invited to buy and which operational promises deserve examination. Cloud servers and VPS imply compute and network dependencies. Cloud storage introduces persistence and restoration questions. CDN services raise questions about edge placement and origin reachability. A cloud data-center offer raises the most direct questions about facility, power, cooling, and inter-site design. The official catalogue is therefore a useful map of claims and dependencies, even when it is not proof of the implementation behind them.

The breadth of that catalogue also makes the narrowness of the public network map more consequential. If Cloud.ir advertised only a single experimental service, an incomplete topology record might describe a small edge. With more than 20 products claimed across multiple service families, customers need to know which evidence applies to which product. The packet can verify a live website, maintained service pages, an active IPv4 ASN, and a set of current routes. It cannot join every product tile to a specific prefix, facility, or recovery procedure.

The distinction between a service surface and a delivery chain should remain visible throughout the article. Cloud.ir's pages are primary evidence for what the operator says it offers. RIPE, RIPEstat, RPKI, PeeringDB, and bgp.tools are public evidence for parts of the network identity. Neither source class, alone or together, completes the physical map.

Data-center and standards claims remain self-described

Cloud.ir's official pages invoke data-center resilience and standards language. They describe operation on Asiatech data centers in Iran and make claims involving ISO27001, TIA-942, and Tier 2/3 characteristics. These statements may be relevant to the operator's design and compliance work, but the present source packet did not independently verify them.

The limitation is specific. The packet did not contain an independent facility certificate tied to a named site and current scope. It did not establish an exact facility list, identify which Cloud.ir products run at which site, or show whether the same certification applies across all locations. It did not document power feeds, cooling topology, generator runtime, fuel arrangements, physical network entrances, or customer-usable compute and storage capacity.

That does not show that the claims are false. It shows that their evidentiary status differs from the AS60077 routing facts. A route collector can independently observe an origin. RDAP can independently return a registry entity. The data-center descriptions in this packet come from the operator's own pages. They should therefore be attributed as Cloud.ir statements, not rewritten as independently certified conditions.

Standards names can create an especially strong impression because they compress a complex assurance question into a familiar label. Yet scope is decisive. A management-system certification, a facility design reference, and a tier-style availability description answer different questions. The source packet does not provide the documents needed to determine the precise claim, issuing body, covered legal entity, covered building, validity period, or exclusions. Repeating the labels without that scope would make the article more certain than its evidence.

The same problem applies to the phrase "Asiatech data centers." It identifies an organizational dependency and a country, but not a facility path. It does not say whether a particular Cloud.ir workload uses one site or several, whether those sites share an upstream, how data is replicated, or whether a customer can select a failure domain. AS60077's routes cannot supply those missing details. PeeringDB's zero facility count supplies no independent site attachment to bridge the gap.

For infrastructure buyers, the useful next evidence would be concrete and product-specific: a named facility list; the relationship between each site and the services sold; certificate documents with scope and dates; a description of independent power and network paths; capacity commitments; and tested restoration procedures. The current packet contains none of those items. It is therefore appropriate to call the delivery path unproven in public, not to declare the underlying infrastructure absent.

This distinction protects both sides of the analysis. It prevents an operator's self-description from becoming an unearned audit result, and it prevents missing public evidence from becoming an unearned allegation. The article can say exactly what was visible: Cloud.ir made the claims, the routing edge was active, and the independent sources in the packet did not verify the physical detail behind them.

The SLA draws a narrower operational perimeter

Among Cloud.ir's official pages, the SLA is the most useful source for understanding where the service promise stops. It limits uptime guarantees to network and cloud-server availability under ordinary operations. It then excludes a wide range of circumstances, including customer software, operating systems, configuration, denial-of-service attacks, suspension, maintenance, critical patches, force majeure, customer equipment failures, customer-requested downtime, non-payment, and legal or security orders.

Those exclusions matter because a customer experiences an application as one system while the contract separates it into layers. A route may remain visible while the operating system fails. A cloud server may be running while customer configuration prevents access. The infrastructure may be available while a denial-of-service event affects use. Maintenance or a critical patch can interrupt service without being treated in the same way as an ordinary network outage. The SLA defines which parts of that experience are inside the guarantee and which are not.

The page should not be read as proof that any excluded event has occurred. Nor does the existence of exclusions, by itself, show weak service quality. It is contractual evidence about attribution. It tells the reader that a broad claim of cloud availability cannot be interpreted as a guarantee covering every cause of downtime.

That boundary is particularly important when compared with the product catalogue. Cloud.ir presents cloud servers, VPS, storage, CDN, domain management, network switching, and cloud data-center services. The captured SLA language focuses its uptime guarantee on network and cloud-server availability under ordinary operations. The source packet does not show a single, equally detailed recovery promise covering every product family. A buyer should therefore avoid assuming that a headline availability concept applies identically to storage restoration, CDN behavior, customer configuration, or data-center service dependencies.

The exclusions also illuminate why AS60077 cannot answer the resilience question. BGP data can show whether prefixes are visible. It cannot identify whether an interruption falls under maintenance, a critical patch, a security order, customer software, or force majeure. It cannot show whether the customer is entitled to a remedy. It cannot measure how quickly a failed service is rebuilt or whether stored data returns at the same point in time.

Most importantly, the SLA does not provide the missing facility path. The fact that network availability is covered under ordinary operations does not reveal which building, circuit, or upstream carries the service. It does not establish that a second site can take over. It does not disclose the amount of spare capacity reserved for failover. It does not say whether AS43754 is bypassed during an upstream incident. Those are separate operational facts.

The treatment of maintenance and critical patches deserves close attention. They are operationally necessary activities, but their exclusion means the observed customer outcome may fall outside the ordinary uptime calculation described on the page. The packet does not provide maintenance-frequency data, notification performance, or historical duration, so no conclusion about actual disruption is possible. What can be said is that maintenance belongs to the contract's boundary rather than to an unconditional availability promise.

The same is true of denial-of-service attacks and legal or security orders. They can affect reachability or service continuity for reasons that a route-origin snapshot will not explain. The article should not speculate about the likelihood of those events. Their relevance is that the operator expressly places them among the exceptions. A complete risk assessment needs the SLA as well as the route table because the two documents answer different questions.

Customer-side exclusions create another layer of ambiguity. Software, operating systems, configuration, and customer equipment can all produce downtime that looks, from the user's seat, like a cloud failure. Cloud.ir's contract distinguishes those causes from covered infrastructure availability. That makes observability and support escalation important, but the packet contains no incident examples, response-time history, or support-resolution data with which to evaluate them.

The SLA therefore contributes more than a legal footnote. It defines the maximum safe claim about the public service promise. Cloud.ir offers an uptime framework for network and cloud-server availability in ordinary conditions, subject to specified exclusions. The packet does not prove end-to-end application uptime, all-cause availability, facility failover, data recovery, or a uniform guarantee across the full catalogue.

Four evidence layers must remain separate

The source set becomes easier to interpret when divided into four layers.

The first is identity. RIPE RDAP links AS60077, AT-CLOUD, ORG-ADA42-RIPE, and Asre Dadeha Asiatech. The address RDAP record links IR-AT-20210316, ASIATECH-MNT, and Asiatech NOC to the range covering the sampled prefix. These are durable registry statements with dates and status fields.

The second is current network observation. RIPEstat saw AS60077 announced, counted 18 IPv4 prefixes and 14,080 IPv4 addresses, recorded broad RIS IPv4 visibility, found one observed neighbour, and showed no current visible IPv6 origin. bgp.tools supplied a consistent public summary. The RPKI result validated origin 60077 for 193.151.156.0/24. These findings establish a measurable public control plane at the captured time.

The third is the commercial service surface. Cloud.ir's official pages present more than 20 products and expose current pages for compute, VPS, data-center, switching, domain, CDN, and storage services. They say the service operates on Asiatech data centers in Iran and describe standards and tier characteristics. The SLA states the contractual availability boundary and exclusions. These are primary sources for the operator's own offer and claims.

The fourth is physical and recovery assurance. This layer would connect products and prefixes to named facilities, independent network paths, usable resource levels, replication design, restoration procedures, and tested failover. It would also tie standards claims to exact sites and current certificate scope. That evidence is not present in this packet.

Confusion arises when a fact from one layer is used to fill another. An active AS registration cannot prove a current route, which is why the RIPEstat observation matters. A current route cannot prove a facility, which is why PeeringDB and independent site evidence matter. A product page cannot prove spare capacity. An SLA cannot prove that failover succeeds. A valid RPKI origin cannot prove that a customer application is available.

The layers do interact. The identity records make the observed route attributable. The route records make part of the service operator's network visible. The official pages explain why that network matters to customers. The SLA exposes conditions under which the customer's experience and the contractual guarantee can diverge. The combined picture is stronger than any one source, but it still has a defined edge.

That edge is the point at which this article should stop making factual claims and start naming questions. The public evidence supports a live network and a live storefront. It does not support a completed statement about physical diversity, independent upstreams, capacity, or recovery. Preserving that line is more informative than either repeating marketing language or treating every missing field as proof of failure.

The unresolved questions are product-specific

A serious customer evaluating Cloud.ir would gain more from a short set of precise requests than from a general demand for "more transparency." The first request should map network evidence to the purchased service. Which Cloud.ir products use addresses originated by AS60077? Are management endpoints, customer workloads, storage services, and CDN nodes on the same origin? Do some products use AS43754 or another autonomous system directly? The packet does not provide that mapping.

The second request should address the physical path. Which named facilities host each service, and can a customer select or verify a location? Are two advertised sites independent in power, cooling, building access, and network entrance, or do they share a material dependency? PeeringDB cannot answer because AS60077's record has no facility attachments, and the official pages do not supply an independently verified facility inventory in this source set.

The third request should clarify upstream design. AS43754 was the only observed neighbour. If AS60077 loses reachability through that network, what alternate path is expected to carry its prefixes? Is the alternative active in BGP, reserved for failure, or provided within the same organization? How often is it tested, and which prefixes are covered? A Whois import reference to AS212895 is not enough to answer those questions because it was not observed as a BGP relationship in the packet.

The fourth request concerns IPv6. The single 2a05:1a30::/34 timestamp should prompt a current product answer rather than a yes-or-no conclusion from public data. Is IPv6 available to customers now? If so, which product, which prefix, which origin ASN, and which SLA apply? If not, the packet offers no basis for predicting when that might change.

The fifth request should separate allocated resources from usable capacity. Eighteen IPv4 prefixes and 14,080 addresses demonstrate routed address space, not available compute, storage, bandwidth, or recovery headroom. Customers need commitments that match the resource they buy: reserved or elastic capacity, limits during failover, storage replication behavior, and the conditions under which resources may be unavailable. None can be derived from prefix counts.

The sixth request should put the standards claims into scope. Which legal entity and facility are covered by ISO27001? What exact TIA-942 assessment or design claim is being made? What does Tier 2/3 mean for the particular service and site? What are the document dates, issuers, and exclusions? The questions do not presume the claims are invalid. They ask for the evidence needed to move them from operator description to independently checkable assurance.

The seventh request should follow the SLA into operations. How are maintenance and critical patches notified? What telemetry distinguishes provider network failure from customer configuration? What restoration sequence applies when compute, storage, and network layers fail together? What is the escalation path when an event falls into a disputed exclusion? The packet confirms that support and sales contact surfaces exist, but it does not supply historical response or recovery performance.

Finally, buyers should ask which claims are contractual. A service page can describe high availability, persistence, or uninterrupted connectivity, while the SLA defines narrower covered conditions. The source set does not show how every product statement is incorporated into the customer's agreement. A precise service schedule, with the relevant exclusions and remedies, would carry more weight than an undifferentiated cloud promise.

These requests follow directly from the evidence gaps. They do not assume that Cloud.ir lacks facilities, capacity, alternate circuits, recovery procedures, or certifications. They identify what an outside reader cannot verify from the 20-source closure used here. That is the proper role of public-source infrastructure analysis: to turn uncertainty into specific diligence, not into unsupported certainty.

A visible origin is only the beginning of assurance

AS60077 gives Asre Dadeha Asiatech a clear and current public edge. RIPE RDAP identifies the autonomous system and organization. RIPEstat shows 18 IPv4 prefixes, broad collector visibility, and an announced state. A sampled prefix has a valid RPKI origin and a coherent address registration. bgp.tools reaches a consistent summary. Cloud.ir, meanwhile, presents an active and broad service catalogue.

Those findings are enough to reject two simplistic readings. This is not merely a cloud name with no observable network operation. It is also not a fully documented delivery chain just because the routes are visible. The evidence is strongest where the internet control plane begins and weakest where customer risk becomes physical and procedural.

The one observed neighbour, AS43754, is a genuine dependency signal, but not proof of the complete topology and not evidence of an independently controlled backup. PeeringDB's empty facility and exchange fields limit public corroboration without proving absence. The official data-center and standards descriptions remain self-attributed in this packet. The SLA establishes a real availability framework while carving out conditions that prevent it from becoming an all-cause guarantee.

The resulting conclusion is measured. Public evidence supports a live IPv4 routing surface associated with Asre Dadeha Asiatech and a current Cloud.ir customer-facing service surface. It does not prove the exact facilities behind the services, the route taken by every product, independent upstream diversity, customer-usable capacity, ongoing IPv6 origination, or the recovery boundary after a multi-layer failure.

That is not an indictment. It is an evidence boundary. AS60077 makes the operator easier to observe, and that visibility is valuable. It also makes clear how much remains outside the route table. For customers deciding whether a cloud service can absorb an outage, the next decisive documents are not more prefix counts. They are product-to-network mappings, facility-specific evidence, independent path details, scoped assurance records, and recovery commitments that survive the exclusions in the SLA.

AS60077 Reveals a Routing Edge, Not Cloud.ir's Full Delivery Chain