APNIC moves a 2014 IPv6 /32 from allocated to reserved

APNIC Took a 2014 IPv6 /32 Off Its Allocated List. The Whole Block Is Reserved.

Why it matters

The address block `2401:c480::/32` appeared in APNIC's 3 November inventory as an allocation carrying a 2014 date. In the 4 November file, the same full /32 sits in the reserved pool. APNIC's current RDAP gives a broad registry record where a holder-specific card would answer the obvious question: whose allocation changed?

Theo March3 November 2026Reading Time 2 minLast update: 3 November 2026

APNIC’s two daily files reclassify the complete 2401:c480::/32 from a dated allocation to reserved space.

Summary

APNIC's 3 November extended file lists 2401:c480::/32 as allocated, country code HK, with an allocation date of 22 November 2014.
Its 4 November file lists that same entire /32 as reserved, without the former country code, date or holder identifier.

The block did not shrink into a smaller allocation. APNIC's 3 November row reads apnic|HK|ipv6|2401:c480::|32|20141122|allocated|A9142C40. The next daily file removes it and writes apnic||ipv6|2401:c480::|32||reserved|. Same starting address, same prefix length; a different administrative column. The 4 November file reports 3 November as its data date, so the public daily comparison pins down the change between snapshots rather than a transaction minute.

The current RDAP query for the exact /32 returns APNIC's broad 2400::/12 record. It does not return a current holder card for 2401:c480::/32. APNIC's status guide draws the important line: allocated resources are delegated to account-holding organisations; reserved resources sit in APNIC's pool. The guide describes several uses for reservations, including quarantine for some returned or reclaimed resources. It does not identify which procedure touched this block. A dated APNIC account or recovery record would.

The active APNIC resource policy adds a second stake. Section 5.1.4 directs APNIC to create AS0 route-origin authorisations for its undelegated available and reserved space. The daily classification puts this /32 in the category covered by that policy. A signed RPKI object for the exact prefix would establish whether the policy is reflected in its current route-origin data.