Summary

  • APNIC’s live RDAP response for 1.1.1.1 returns an IP-network object for 1.1.1.0–1.1.1.255 whose status array contains active.
  • RFC 9083 defines that array as the state of a registered object. It does not turn the value into evidence that a prefix is visible in BGP, globally reachable or carrying a working service.

One word, two evidence planes

Query APNIC’s RDAP service for 1.1.1.1 and the response is admirably structured. It identifies an ip network object, gives the handle 1.1.1.0 - 1.1.1.255, supplies the start and end addresses, records registration events, and includes a status array containing one value: active.

That final word is easy to overread. In operational dashboards, “active” often means that a service is responding, a route is visible, a circuit is passing traffic or a customer account is enabled. The APNIC response makes none of those claims merely by returning the status value.

The reason is definitional rather than interpretive. RFC 9083’s status section says the array indicates the state of a registered object. APNIC’s RDAP documentation likewise presents the service as a way to access Internet resource registration data. The object being described is a registration record for an IP network.

This gives active a useful but bounded meaning. A consumer may record that APNIC exposed the registered object with that status at the time of retrieval. The value can support registry-data inventories, change detection, exception handling and reconciliation between registration systems. It cannot, without another source, answer whether a route collector currently sees the prefix or whether packets reach a particular destination.

Registration state is not route state

BGP operates on a different evidence plane. RFC 4271 describes routing information in terms of reachable destinations and the path attributes associated with them. A BGP observation has a collector or peer, a timestamp, a prefix, a path and a visibility scope. An RDAP registration response has a registry service, a queried resource, an object boundary and registration metadata.

Those records can refer to the same address space while answering different questions. The RDAP object can remain active while a route is absent from a particular collector. A route can be visible while a host inside the range drops traffic. A globally anycast service can produce different reachability results from different networks. None of these conditions makes the registry response defective; they show why the sources must not be collapsed.

Preserve the observation before drawing the conclusion

A defensible evidence record should retain the exact endpoint, queried address, retrieval time, object class, handle, address bounds and status array. If the decision concerns routing, attach independently sourced route observations with their own collectors and timestamps. If it concerns service availability, add measurements that name the probes, targets, protocol and success criteria.

This separation is more than data hygiene. Security teams may otherwise treat active as proof that a suspicious address is reachable. Asset systems may use it to mark infrastructure online. Procurement or compliance workflows may infer that a service is in use. Incident responders may mistake a registry-state transition for the start or end of an outage. Each conclusion asks the registration field to carry evidence it was not designed to provide.

The precise statement is simpler: at the recorded retrieval, APNIC’s RDAP service returned the specified IP-network object with status active. Whether the corresponding prefix was announced, visible from a given vantage point, reachable, or serving traffic requires a separately scoped observation.

Sources