Summary

  • APRICOT publishes a demanding network specification and increasingly candid reports of what was deployed, measured and repaired.
  • The record supports a claim of observable practice, not flawless delivery, ordinary production economics or authority over Asia-Pacific operators.

A constitution normally allocates authority in words. APRICOT’s conference network does something narrower and, for technical claims, more useful: it exposes commitments to traffic. The published specification calls for two independent operators, redundant fibre, two border routers, dual core switches, full IPv4 and IPv6 BGP feeds, local DNS and DHCP, route-origin validation capability, monitoring and both dual-stack and IPv6-mostly service. These are institutional claims until an event report or an outside observer shows what ran.

The distinction matters. A requirements page can describe two independent upstreams; it cannot prove physical diversity, a tested failover or a service-level agreement. A Routinator cache in a diagram cannot prove that a border router dropped invalid routes. A prefix visible to route collectors cannot prove that every network could reach it. APRICOT’s strongest evidence begins where the specification meets inconvenient observations.

In 2024, the IPv6-only SSID produced inspectable code as well as slides. A public coredhcp pull request added support used by the event and was reviewed and merged upstream. The report counted 142 unique MAC addresses, of which 115 requested DHCP Option 108. That is useful protocol evidence, but not a count of people: randomised MAC addresses and repeat clients break the conversion from devices to delegates. The same report recorded devices repeatedly requesting IPv4, wireless-controller exclusions, intermittent UDP problems, a banking-app failure and an NDP issue linked to an older Jool version.

The experiment’s credibility lies partly in those frictions.

The 2025 report showed repetition at a larger observed scale. It described AS24555, the stable IPv4 and IPv6 blocks, two one-gigabit links, local services and an IPv6-mostly configuration. Of 1,082 unique MAC addresses on the reported day, 944 used IPv6 with NAT64 and 138 used IPv6 plus IPv4. Peak traffic was reported at 400 Mbit/s. Again, these are client-mode and traffic measures, not attendee adoption rates or availability statistics. A DNS geolocation problem sent users to servers roughly 100 milliseconds away; changing the forwarding path reportedly reduced that figure to 2 milliseconds.

The intervention is concrete, but the raw probe series and sample distribution were not published.

The 2026 report is the strongest protection against a promotional reading. It named multiple connectivity actors and again used AS24555 and the two address aggregates. It reported 609 unique MAC addresses, a 70–30 split between IPv6-plus-NAT64 and IPv6-plus-IPv4, and a 300 Mbit/s peak. It also disclosed four different incident classes. The opening crowd caused Wi-Fi overload and an outage. Some autonomous systems could not reach the prefixes even while RouteViews and RIPE RIS appeared to show global routes; the committee described a possible ghost route and said one external AS corrected a configuration.

One access point broadcast the right SSID but sat outside the local controller. Public DNS intermittently failed for some IPv4 recursive queries, after which the team deployed local resolvers.

Those incidents test different parts of the operating compact. Density planning did not prevent a capacity outage. Control-plane visibility did not guarantee data-plane reachability. A local-controller rule mattered only after an unmanaged device violated it. Local DNS became valuable when a public dependency failed. Publication turns these events into evidence; it does not establish that the reports disclose every failure or that the fixes permanently prevented recurrence.

Outside observation corroborates only part of the story. APNIC RDAP describes AS24555 and both address blocks as resources used for conferences in the Asia-Pacific region and explicitly does not make APNIC the network operator. RIPEstat observed both aggregates originated by AS24555 across an interval spanning APRICOT 2026 and later saw no current announcement, consistent with temporary use. RPKI records covered the aggregates during the event window, and current validation accepts AS24555 as the origin. None of that proves venue-router ROV enforcement or an invalid-route drop.

APRICOT also did not invent this model. RIPE offered a best-effort NAT64 meeting network in 2016, and the IETF publishes its own prefixes, IPv6-only-preferred and dual-stack services, local DNS, filtering controls and on-site support. APRICOT belongs to a broader operator-conference tradition of testing protocols under real user load.

That comparison strengthens the right conclusion. The conference network is APRICOT’s strongest “constitution” only as a metaphor for a repeatable and falsifiable operating compact. It is not a legal instrument, and “strongest” is not a measured ranking. Its value is that design choices can be compared with routes, client behaviour, faults and repairs.