Summary

  • APNIC’s signed all-transfer log records nine M&A prefixes moving from ZTNET CO., LTD in KH to ZT INFORMATION NETWORK CO., LIMITED in HK on 1 September 2026.
  • Those prefixes contain 57,088 addresses, or 223 /24 units. A /24 and a /19, containing 8,448 addresses, remain on the prior-holder side; together the two sets reconstruct the original /16 exactly.
  • The next signed delegated file keeps 20071203 on all eleven resulting rows. APNIC’s own format says that a resource transferred from another registry retains the first assignment or allocation date supplied by the original RIR.
  • Neither clock is defective. A defensible market or governance record must preserve the event date and the resource-origin date as separately named facts, with the source files and prefix arithmetic attached.

A transfer on Tuesday, an allocation in 2007

The APNIC all-transfer log dated 1 September 2026 contains nine records that share the same parties, economies, dates and transfer type. The source organisation is ZTNET CO., LTD, marked KH; the recipient is ZT INFORMATION NETWORK CO., LIMITED, marked HK. The prior delegation date is 20071203, the transfer date is 20260901, and the type is M&A.

The records cover 79.109.0.0/24, 79.109.2.0/23, 79.109.4.0/22, 79.109.8.0/21, 79.109.16.0/20, 79.109.32.0/19, 79.109.64.0/18, 79.109.128.0/18 and 79.109.192.0/19. APNIC’s prop-142 transfer-log specification defines transfer_date as the date on which the recipient received the resource. It defines M&A more narrowly than the acronym can sound in ordinary business reporting: a transfer processed under the Merger and Acquisition policy.

That category does not reveal a purchase price, consideration, contract, asset schedule or the corporate mechanism behind the change. The log establishes the registry event and its policy class. It does not establish whether an observer should describe the underlying arrangement as a sale, reorganisation, acquisition of control or anything else.

The prefix arithmetic is more informative than the number of lines. The nine blocks hold 57,088 addresses: 223 units of /24. Two pieces of the former /16 are absent from the recipient set. They are 79.109.1.0/24 and 79.109.224.0/19, together 8,448 addresses or 33 /24 units. Add the two sides and the boundary closes: 57,088 plus 8,448 equals 65,536; 223 plus 33 equals 256 /24s, exactly one /16.

That reconciliation matters because “nine transfers” is a count of records, not a measure of the address space. It also prevents an analyst from assuming the missing addresses disappeared. They remain visible as a precise remainder in the following state.

The daily file preserves another clock

The signed delegated file for 1 September has a single row for the range: 79.109.0.0, value 65,536, economy KH, status allocated, date 20071203 and opaque holder ID A91100B2.

APNIC published the 2 September file as a gzip. Once decompressed, the one row has become eleven. Nine rows are marked HK with opaque ID A91556B2 and reproduce the transferred prefix set. Two rows are marked KH with the earlier opaque ID and reproduce the /24 and /19 remainder. Every one of the eleven rows still says 20071203.

It would be easy to call that date stale. APNIC’s README for extended delegated statistics says otherwise. Its date field normally records when an allocation or assignment was made by the RIR. Where a resource has been transferred from another registry, the date represents the first assignment or allocation received from the original RIR. The file is preserving origin chronology, not trying to repeat the latest transfer event.

The cumulative transfer log supplies another useful boundary. It contains an earlier entry for the whole 79.109.0.0/16: from RIPE to ZTNET CO., LTD in APNIC on 9 October 2025, with 20071203 as the previous delegation date. That does not explain the 2007 allocation’s business history. It does demonstrate why the delegated row can carry an old original-RIR date through later registry events.

Two file families therefore answer different questions:

  • When did this recipient receive these nine prefixes under APNIC’s recorded transfer process? The transfer log answers 1 September 2026.
  • What original assignment or allocation date accompanies these transferred resources in the delegated-statistics series? The delegated file answers 3 December 2007.

Flatten them into a generic column called allocation_date and one of the facts will be mislabelled.

The row count moves for a third reason

The daily delegated summary adds another trap. Its IPv4 count rises from 61,519 records on 1 September to 61,542 on 2 September, a net increase of 23. APNIC’s README is explicit that summary counts are record-line counts, not quantities of resources.

This transition explains ten of the 23 new lines: one old range row becomes eleven rows, so the local net change is plus ten. It does not explain the other thirteen. Nor does it add addresses to the /16; the address total is unchanged. A dashboard that reports “23 more IPv4 allocations” from the summary would be confusing representation with amount and this event with every other change in the file.

The evidence package checked all three payloads against their published MD5 companions. It also validated the detached OpenPGP signatures for both delegated files and the transfer log under the exact UID-less key bytes APNIC publishes at CURRENT_PUBLIC_KEY, fingerprint 53484F6685D112B194DD25D9CB342F01D1524E14. That proves the captured bytes match signatures under that published key. It does not supply a third-party identity certification, a Web-of-Trust conclusion or a guarantee that an archived URL can never be replaced.

Registration is a check, not an operating map

APNIC’s prop-142 specification recommends checking recipient holdings in Whois. The current public RDAP record for 79.109.0.0/24 identifies ZT1-HK, economy HK, with registration and last-change events on 1 September 2026. The retained /24 and retained /19 remain registered as ZTNETCOLTD-KH, economy KH, with events on the same day.

That is a useful state check. It is not proof of route origination, RPKI authorisation, traffic, customer service, physical location or beneficial ownership. APNIC’s delegated-file documentation also warns that the economy code describes the organisation and is not authoritative evidence of where addresses are currently used. The article therefore does not publish contact details from RDAP and does not turn a registry partition into a company profile.

A small receipt can keep both dates honest

The correction belongs downstream as much as at the registry. A transfer analysis should preserve the transfer-log filename and SHA-256, transfer_date, transfer_type, prior delegation date, exact prefix set and address total. It should bind those fields to the before-and-after delegated files, their hashes, the original-date definition, the retained remainder, the time of the Whois or RDAP check, and any later correction or supersession.

This two-clock receipt is an editorial proposal, not a requirement attributed to APNIC. It does not ask the registry to expose contracts, member tickets, invoices, internal approvers or private contact data. It simply prevents a dataset from making one date impersonate another.

What the evidence does not establish

The sources do not establish a sale, price, contract terms, motive, routing change, ROA state, outage, harm or wrongdoing. They do not explain why the prior holder retained 8,448 addresses. M&A is the public policy category, not a complete corporate narrative. Opaque IDs are in-series grouping values and are not guaranteed to remain constant between versions. The event explains ten—not all 23—of the daily file’s net IPv4 record increase.

Sources