Summary

  • APNIC's notice schedules GCP network-environment updates for 29 September 2026, 10:00–12:00 UTC+10. It names DASH, the notification service, REx and the AS0 ROA Service, and says no downtime is expected. That is a forecast, not a report of an incident or a guarantee that every kind of data is current.
  • APNIC's active resource policy says it creates AS0 ROAs for address space marked Available or Reserved and removes a prefix when it delegates that space. A 2020 deployment account described removal and republication within under five minutes in normal circumstances. The 2020 operating description does not establish a 2026 service-level target.
  • The AS0 publication chain has more states than an HTTP check: registry delegation, recalculation of AS0 coverage, signed-object publication, repository retrieval and each relying party's observation. A reachable endpoint could in principle serve an older object. There is no evidence here that it has done so during this future window.
  • APNIC uses a separate Trust Anchor Locator and recommends advisory or alerting use, not automatic BGP filtering. A TAL changes which relying parties elect to ingest the assertion; it does not itself prove that the publishing infrastructure is independent of the announced maintenance.

The calendar entry and the assertion

The APNIC service-update index dates the announcement to 24 September. The window it describes begins five days later, on Tuesday 29 September. Between 10:00 and 12:00 at UTC+10, APNIC says it will update the GCP network environment used by four named services. Its forecast is unambiguous: no downtime is expected. The generic closing line apologising for an “outage” is not an observation that one occurred. At the time of this article the window has not happened.

The list is nevertheless revealing because the four names do different work for their users. A dashboard may be tested for access. A notification service has a delivery or retrieval question. REx has its own availability and data question. The AS0 ROA Service adds a more exact kind of freshness question: when APNIC's registry changes the status of a prefix, does the publicly retrievable security assertion reflect the change? These are proposed distinctions for reading the notice, not claims that APNIC has published four separate service-level objectives or that its systems share one backend.

A 31 July 2025 maintenance notice named the same four services during a Kubernetes upgrade, also expecting no downtime. That earlier co-listing helps establish that APNIC has treated AS0 as part of a named maintenance surface before. It cannot show that the 2026 deployment, database, routing path or failure domain is unchanged. Two notices listing the same products are not an architecture diagram.

What has to change when a block is delegated

An AS0 ROA is a deliberately unusual signed statement. RFC 6483 describes a ROA whose origin is AS 0 as a disavowal of routing origination for the stated prefix and its more specifics. APNIC's current policy applies that mechanism to APNIC-administered IPv4 and IPv6 space not yet delegated, represented as Available or Reserved in its extended delegated statistics. On delegation to an account holder, the policy says APNIC removes the prefix from the AS0 ROA. That removal is not administrative tidying. It is the difference between asserting “not delegated” and recognizing that the registry has changed the resource's state.

The 2020 implementation record is unusually useful because it describes an operating chain, not only a policy aspiration. APNIC then said its production service applied live delegation changes to both its main and AS0 RPKI state within five minutes, with the undelegated assertion removed after assignment or allocation from the free pool. It described a registry-coupled in-house component, a cloud publication repository and continuous monitoring. The companion blog called the under-five-minute interval a normal-circumstances goal to which the deployed implementation conformed. These are facts about what APNIC reported in 2020.

They should not be silently upgraded into a present-day SLA or a measured 2026 result; the current policy states the removal duty but not an interval.

The relevant sequence is therefore concrete. First a resource is delegated in the authoritative registry. Then whatever process computes the AS0 coverage must exclude it. A changed signed object must be made available at the publication point. A relying party that has opted into APNIC's AS0 trust anchor must retrieve and validate the new state; its downstream router policy is a further, local decision. APNIC controls the registry and publication steps. It does not control when every independent relying party fetches a repository or how every operator uses the result.

This makes “up” and “current” separate propositions. A successful request for a TAL or repository object can prove reachability at one time and vantage point. It cannot alone prove that the object incorporates a particular delegation. Equally, a particular relying party's delayed refresh would not by itself prove APNIC failed to publish promptly. To locate any delay, a reviewer needs the dated registry transition, the old and new AS0 coverage, the signing or publication version, and an independently observed repository version. The observation must distinguish the producer's clock from the consumer's clock.

The consequence remains conditional

If a prefix were newly delegated but remained covered by a stale AS0 assertion, a relying party that had deliberately installed the AS0 TAL could still receive a signed disavowal for it. What that meant for a route would depend on the full set of covering ROAs, validator behaviour and the network's routing policy. It would not automatically prove dropped packets or a universal routing failure. APNIC's own current caution says errors could interrupt routing depending on configuration and strongly recommends advisory or alerting use rather than automatic filtering. That advice matters precisely because the operational consequence is conditional on local adoption.

The separate TAL is a useful boundary. A network must choose to add it. That prevents APNIC's undelegated-space assertion from being inadvertently treated as part of the ordinary trust anchor. It is not, however, an uptime mechanism or proof that the AS0 repository is physically isolated from a GCP network update. The 2020 implementation presentation located its publication repository in the cloud; the 2026 notice mentions a GCP network environment. Connecting those sentences into a claim about today's exact topology would exceed the evidence.

The safe conclusion is simply that APNIC itself has named AS0 among the potentially affected services and has forecast no downtime.

Nor does the current notice say that APNIC will delegate a prefix during those two hours. There may be no state transition to test in the window. A pre-window and post-window observation of the same object could therefore be entirely normal. The most informative test is event-conditioned: if a relevant delegation occurs, what was the time from the authoritative change to the changed AS0 publication, and what did an independent relying party see? Without the event, a green availability light answers only the smaller question.

A narrow account would make the forecast inspectable

APNIC could describe the outcome of this maintenance in service-specific terms. A dated statement that interfaces remained reachable would substantiate one part of “no downtime”. For AS0, a separate account could say whether a delegation event occurred, whether the publication path was exercised, what current latency objective APNIC uses if any, and how publication and retrieval were checked. If no qualifying event occurred, saying so would be more honest than presenting an untested freshness interval as proven. This is an editorial proposal, not an assertion that APNIC has promised a report or lacks internal monitoring.

The same distinction should shape an operator's reading of any security feed. A registry may make a correct and timely assertion; a validator may fetch late; a router may enforce, warn or ignore. Each stage has a different custodian and a different way to fail. It is reasonable to ask APNIC to make its own change visible, and reasonable to ask operators to keep their own ingestion and enforcement choices observable. It is not reasonable to infer an incident from a maintenance notice or to demand that an RIR certify what every external validator saw.

APNIC's wording may prove entirely accurate on 29 September. The question raised by the notice is not whether “no downtime” is false. It is what the words measure. For a service that publishes a signed statement about unallocated address space, the decisive boundary is crossed when an address is allocated and the statement changes accordingly. The page can stay open throughout. The clock is still worth watching.

Sources