Summary

  • AS24388 sits inside an APNIC-assigned block, 23552-24575, held as "CHIX-AS-AP - Christchurch Internet Exchange"; the same registry overview reports "announced": false across a query window ending 2026-10-21T00:00:00.
  • A second routing surface reports 0 prefixes announced and 2 observed BGP peers for that ASN, both IPv6 and none IPv4, while the exchange's own site and its PeeringDB record returned only a dated inaccessibility note — leaving participants, sites, ports, route servers and traffic unverified.

A peering fabric and the autonomous system number registered to it are two different objects, and only one of them was readable in this research window. What follows separates them deliberately: first the records that answered, then what those records structurally cannot say, then the material that did not arrive and the instruments that would replace it.

What the registry actually returns

The AS overview for AS24388 is a small JSON object, and its fields are unusually explicit. Read on 21 October 2026, it places the number inside block 23552-24575, described as "Assigned by APNIC" and named in the record as the IANA 16-bit Autonomous System (AS) Numbers Registry. The holder string is "CHIX-AS-AP - Christchurch Internet Exchange" (RIPEstat AS overview for AS24388). The same object carries "announced": false, with query start and end both stamped 2026-10-21T00:00:00.

That flag is narrower than it looks. It says that in the window queried, no prefix originated by AS24388 was observed in the routing table the registry consulted. It does not describe the exchange, its membership, its switches or the volume of traffic passing between its participants. An allocation record is evidence that a number exists and who holds it; it is not a description of what that holder operates.

The second surface, and why agreement is not corroboration

The BGP toolkit entry for the same number reports the routing state in more granular form: "Prefixes Announced (all): 0", with 0 for both IPv4 and IPv6, and "BGP Peers Observed (all): 2", split into 0 IPv4 and 2 IPv6 (BGP toolkit entry for AS24388). The two readings look like independent confirmation of the same picture. They are not.

Both surfaces derive from the global routing table as collected by route-monitoring projects; neither runs its own independent probe of the Christchurch fabric. When two views of one underlying table agree, the reader has one observation reported twice, not two measurements. The timestamps differ as well: the registry states its window explicitly, while the toolkit excerpt retained here carries no observation time at all, and the two cannot be shown to be simultaneous.

Zero prefixes is a normal property, not a verdict

At an exchange point, participating networks announce their own address space over sessions to a route server or directly to each other. The exchange's own AS number typically originates nothing of its own, because its job is to carry other networks' routes rather than to be a network with customers. A count of zero prefixes announced by AS24388 is therefore compatible with a fabric that is doing exactly what a fabric does.

Nor is the IPv4 line a service declaration. Two observed neighbours, both IPv6 and none IPv4, describe the sessions the monitoring projects could see involving that AS number. They do not establish that the exchange offers no IPv4 connectivity, that it is IPv6-only, or that any particular network is or is not present. A count of neighbours on an ASN is not a count of members, and the two must not be used interchangeably in a procurement file or an investment memo.

The remarks field points somewhere else

Inside the retained excerpt sits a line that is easy to skim and hard to interpret: a remarks field directing exchange policy questions to a terms page on the nzix.net domain. It is a referral, recorded in the routing object rather than in any document the exchange publishes.

What that establishes is modest and worth stating precisely: the record carries a pointer. What it does not establish is who operates, owns or governs the Christchurch fabric, whether that terms page is current, or whether its conditions apply to this exchange at all. Nothing retained here confirms any of that, and a link inside a remarks field is not a governance document. The related New Zealand exchange organisation is a separate subject with its own record and should not be merged into this one on the strength of a URL.

The half that did not arrive

The exchange's own site returned a dated note rather than text: "The requested page was inaccessible during the research period" (chix.net.nz). The PeeringDB IX record at identifier 466 returned the identical note (PeeringDB IX record 466).

That sentence is a statement about access, not about the operator. It does not say the exchange has no members, no ports, no route servers or no traffic; it says this reading could not verify any of those things from those pages. The distinction matters because retrieval failure is the single easiest fact to misread as an operator's silence, and silence is the easiest thing to escalate into a conclusion about viability.

Even our own directory entry for this exchange rests on one evidence basis — the registry endpoint cited above — at a confidence of 0.7, and it records the string "Global" in both its country and its jurisdiction fields. "Global" is not a jurisdiction (directory entry for Christchurch Internet Exchange). The card's own open questions ask for a verified legal country, current services, visible assets and responsible public leadership, which is an honest description of where the record stands.

What would settle the fabric

The gap is not mysterious, and neither is its remedy.

Five instrument classes would convert this from a record reading into an infrastructure account: the operator's own pages read as text, listing sites, switches, ports, route-server addresses, joining conditions and participants; a PeeringDB IX record or an IX-F member export with a stated date, giving member count, facilities and media types; route-server configuration or looking-glass output showing sessions, received routes and last-seen times; an APNIC organisation or whois record tying the ASN to a legal entity; and independent measurement of domestic peering, latency or traffic volume in the South Island.

Each of those carries a different weight. A member export proves declared participation on a date. A looking glass proves sessions existed when it was queried. Traffic graphs prove volume if their measurement basis is stated. None of them substitutes for the others, and none of them can be reconstructed from the number of neighbours an ASN shows.

What this reading supports

The defensible conclusion is bounded. Christchurch Internet Exchange holds an APNIC-assigned 16-bit autonomous system in block 23552-24575, and on 21 October 2026 the routing records consulted showed that number originating nothing and carrying two observed IPv6 neighbours. The exchange's public description of its own fabric was not readable in this window, so the size, participation, physical footprint and traffic of that fabric remain unestablished here.

For anyone weighing South Island interconnection, that is the operative distinction. The record layer answers an administrative question — does an exchange exist under this name, and what number is registered to it. It does not answer the engineering or commercial questions, and treating a zero and a two as if they did would put a routing artefact in the position where a measurement belongs.