Summary

The registry record and the routing table tell two different stories about Thanh Trang Cloud Computing and Technology Company Limited, and the gap between them is the story.

The registration record

Start with what the company provably owns. The corporate registry lists Thanh Trang Cloud Computing and Technology Company Limited under business ID 0318310564, registered on 22 February 2024 with charter capital of VND 100,000,000, at 108 Tran Dinh Xu, Nguyen Cu Trinh Ward, District 1, Ho Chi Minh City. https://vnbis.com/products/companies/translated-name-thanh-trang-cloud-computing-and-technology-company-limited-2860121/ That address matches the WHOIS record for the /23 exactly — this is not a coincidence of naming; the same legal entity holds both the registration and the network resources.

The number resources are real and portable. The block 157.66.252.0/23 was registered with status ALLOCATED PORTABLE under APNIC, last-modified 8 May 2024, and carries the netname THANHTRANG-VN. https://records.ping.pe/whois/157.66.252.0/23 Five days later, on 13 May 2024, a route object appeared in the registry pointing that block at origin AS150820. https://records.ping.pe/whois/157.66.252.0/23 So from the very beginning of the block's life, the record itself said the routing would not run under Thanh Trang's own AS number.

Vietnam's number-resource environment matters for context. VNNIC, Vietnam's National Internet Registry, administers IP and ASN resources nationally under APNIC, including the 4-byte AS block AS151851–AS151950 from which Thanh Trang's AS151934 was allocated on 9 October 2023. https://ipgeolocation.io/browse/asn/AS151934 https://vnnic.vn/index.php/ipasn Vietnamese operators therefore often obtain their ASNs and address space through the NIR path, and the administrative contact chain in Thanh Trang's records runs through VNNIC's abuse address. https://vnnic.vn/index.php/ipasn

The routing table

Then look at what the routing table actually says. AS151934 is allocated to the company — its ASN object names Thanh Trang, the domain cloudthanhtrang.online, and an admin/tech contact inside the company. https://ipgeolocation.io/browse/asn/AS151934 But it announces nothing: zero IPv4 routes, zero IPv6 routes. https://ipgeolocation.io/browse/asn/AS151934 IPinfo, an independent source, shows the same: zero prefixes, status "Inactive", last updated 8 May 2024. https://ipinfo.io/AS151934

What does carry the /23 is AS150820, Lienvps Technology Company Limited. bgp.tools shows Lienvps originating 13 IPv4 prefixes, including 157.66.252.0/23 explicitly described as belonging to Thanh Trang Cloud Computing and Technology Company Limited. https://bgp.tools/as/150820 The block's transit runs through FPT Telecom (AS18403) and Megacore (AS140810). https://bgp.tools/as/150820 IPIP.NET's routing view for the same netblock echoes the FPT relationship. https://whois.ipip.net/AS150820/157.66.252.0/23

Here is the part that elevates this from a routing curiosity to an infrastructure-economics finding: the announcement is RPKI valid. The aggregate status of 157.66.252.0/23 is VALID with sole origin AS150820, under a ROA that authorises AS150820 to originate the prefix at maximum length 23. https://records.ping.pe/157.66.252.0/23 IPinfo independently confirms the RPKI-valid status for AS150820 on that range. https://ipinfo.io/AS150820/157.66.252.0/23

Why the ROA matters

Route Origin Validation is normally discussed as a security control: it binds a prefix to the AS authorised to announce it, so a hijacker announcing the same prefix without a valid ROA should be rejected by RPKI-aware networks. In this case, the control is working perfectly — and it is validating the wrong party, from the holder's point of view. The only cryptographically protected path into Thanh Trang's address space is one that Lienvps controls. If Thanh Trang ever wanted to originate the block itself from AS151934, it would fail ROV at every validating network, because no ROA names AS151934. https://records.ping.pe/157.66.252.0/23

This is the concrete, verifiable form of a dependency that a marketing page cannot show. A customer buying "cloud" capacity from Thanh Trang is buying addresses that reach the internet through a competitor-operator's AS, protected by a cryptographic authorisation that names that operator. The registration says Thanh Trang owns the resource; the routing security layer says Lienvps is entitled to carry it. Both are true at once, and neither is wrong — this is the standard signature of a delegated, leased or BYOIP-style arrangement in which the resource holder contracts routing to an operator with transit and peers.

The public record cannot distinguish which of those commercial arrangements is in place, and it does not need to for the finding to hold: whatever the contract says, the operational control — the ability to announce, protect and withdraw the routes — sits with AS150820. https://bgp.tools/as/150820 https://records.ping.pe/157.66.252.0/23

What a "cloud company" is, in evidence terms

The label "cloud computing" is a legal and marketing identity. The evidence trail here — corporate registration, APNIC allocations, route objects, RPKI ROAs and live BGP tables — lets a reader test what stands behind it. For Thanh Trang, the test returns a split answer: real, portable number resources in the company's name; zero routes from the company's own network; live, RPKI-protected routing operated by another company; and no public evidence of racks, capacity or a recovery site in the company's own control. https://records.ping.pe/whois/157.66.252.0/23 https://bgp.tools/as/150820 https://records.ping.pe/157.66.252.0/23

That is not an accusation. Resource leasing is a legitimate and common market structure — IPv4 scarcity has made it routine for young companies to obtain address space they cannot buy and contract announcement to operators who already have transit. What it means practically is that the continuity of any service sold on this space depends on a second company's network, its transit providers and its willingness to keep the ROA and the announcement in place. https://bgp.tools/as/150820 https://records.ping.pe/157.66.252.0/23 The dependency is not hidden — it is written into the public routing record — but it is invisible to anyone who stops reading at the company's name on the allocation.

Limits of this analysis

Three boundaries should be stated plainly. First, aggregator route counts can lag real BGP state; "zero routes" for AS151934 is a reported value from two independent sources, not a real-time measurement. https://ipgeolocation.io/browse/asn/AS151934 https://ipinfo.io/AS151934 Second, WHOIS route objects and ROAs reflect authorisation and intent, not proof of traffic — the /23 may carry customer traffic, internal services, or nothing at all; the public record does not say. https://records.ping.pe/whois/157.66.252.0/23 https://records.ping.pe/157.66.252.0/23 Third, the commercial relationship between Thanh Trang and Lienvps is not public; "delegated or resold routing" is the structural inference from the evidence, not a documented contract. The masked director entry in the corporate registry ("TO T.T") similarly cannot be resolved further from public sources. https://vnbis.com/products/companies/translated-name-thanh-trang-cloud-computing-and-technology-company-limited-2860121/