Summary

  • APNIC's 28 January 2025 row moved sixteen /22 IPv4 ranges—16,384 addresses—and AS64013 together from CONA HOSTING SDN BHD to CyberForest LLC.
  • AS136209 arrived separately in March; AS64013 left for YANCY LIMITED in September. Current RDAP leaves all sixteen /22s and AS136209 with CyberForest, and AS64013 with YANCY.

The transfer row looked like a ready-made network kit. On 28 January 2025, APNIC recorded 16 separate /22 IPv4 ranges and AS64013 moving from CONA HOSTING SDN BHD to CyberForest LLC. in one RESOURCE_TRANSFER. The address ranges hold 16,384 unique IPv4 addresses. A reader of that single row could easily imagine the number and the addresses travelling as a permanent pair. APNIC's later rows tell a less tidy story: the addresses and the routing identifier take different exits.

The first new arrival came seven weeks after the big bundle. On 17 March 2025, CONA HOSTING SDN BHD sent AS136209 to CyberForest in a second transfer that carried no IPv4 range. The second change came on 3 September: CyberForest sent AS64013 to YANCY LIMITED in an ASN-only transfer. The sixteen /22s do not appear in either ASN-only row. This sequence is specific, not a general claim about how networks are run: one IPv4 bundle plus one number came in, another number came in alone, and the first number went out alone.

Current APNIC RDAP makes the split measurable. Each of the sixteen exact /22 lookups still covers its corresponding transferred interval and names CyberForest LLC. as registrant. The blocks are scattered through 43/8, 45/8, 103/8 and 202/8; they are sixteen noncontiguous pieces, each 1,024 addresses. Their sum is a /18's worth of addresses, but there is no single contiguous /18 in the transfer. Calling the bundle a /18 would erase the routing and registration boundaries that the receipts actually preserve.

The ASN lookups tell the other side. Current RDAP for AS64013 names YANCY LIMITED, matching the September transfer. Current RDAP for AS136209 names CyberForest LLC., matching the March arrival. The January row's recipient field uses country code ZZ, while the exact current IP objects present their own registration details; the code in one historical transaction row is not a passport for a whole resource history. The reliable join uses resource identifiers and dates, then checks each holder view independently.

APNIC's public format deserves credit for putting IPv4 and ASN transfers in the same machine-readable record when they happen together. The trap is treating that record as if it were a permanent bundle. It describes a transaction on one day. The resources can separate on later days, even if the original sixteen address ranges remain under the same name. A portfolio view of CyberForest's current position therefore needs sixteen current IP objects and two current ASN objects, as well as three dated transfer rows. One receipt cannot answer a question asked nearly twenty-two months later.

The records do not show whether AS64013 was ever used to originate any of these sixteen prefixes; a dated BGP origin record would answer that operational question. What they do show is the institutional mechanism: APNIC registered the same day bundle and the later unbundling separately. Anyone selling, buying or auditing address space should stop reading at the resource boundary, not at the transaction row. The tile that left the box was AS64013. The sixteen address tiles stayed.

APNIC source receipts