Summary

  • AFRINIC’s cidr0_cidrs value restates the address interval held in an RDAP registration object as one or more CIDR expressions.
  • A matching prefix can also appear in BGP, but only separate, timestamped routing evidence can establish an announcement, origin, path or reachability claim.
  • Systems that combine registry and routing data should preserve the source and observation time of each fact instead of deriving route state from registration syntax.

One prefix, two evidence systems

The distinction starts with the container. AFRINIC returned an RDAP object whose class is ip network, whose handle is the inclusive range 196.1.0.0 - 196.1.0.255, and whose type is ASSIGNED PI. In that registration-data context, the cidr0_cidrs member 196.1.0.0/24 is a compact expression of the same interval. It sits alongside fields that describe the registered object, including its starting and ending addresses, parent handle, country code, lifecycle events and registry status.

Each of those fields inherits meaning from the object that contains it. The parent handle points to another network registration in the hierarchy. The active value is the status of the registered object. The cidr0_cidrs array renders its address boundaries as prefixes. Reading one of these values outside the RDAP object may preserve its characters while discarding the qualification that makes the fact accurate.

AFRINIC’s own service guidance makes the lookup’s purpose clear. An IP-network query returns the most-specific, or smallest, registered network that completely encompasses the address or prefix submitted by the user. The result answers a registration question: which recorded network object contains this resource? It does not claim to return the most-specific route seen on the Internet, the route preferred by any router or the path packets will follow.

The cidr0 extension reinforces that distinction. RDAP’s base IP-network model uses an inclusive start address and end address because a registration range need not fit into one CIDR expression. The extension supplies an array so that even an “off-bit” range can be represented exactly by several prefixes. In this observation the conversion happens to require only one member: the addresses from 196.1.0.0 through 196.1.0.255 align cleanly with 196.1.0.0/24. That neat conversion describes the registry object; it does not report an event in the routing system.

BGP uses the same prefix notation for a different proposition. A BGP route pairs destinations carried as network-layer reachability information with path attributes exchanged between autonomous systems. Its meaning depends on an observation: which speaker reported the route, when it was visible, what origin and path attributes accompanied it, and whether a later update replaced or withdrew it. A slash prefix in an RDAP document supplies none of that routing context.

The lexical match can nevertheless be tempting. A dataset may contain 196.1.0.0/24 in a registry column and the same string in a routing column. Matching the strings is a valid join key. Treating the match as proof before the routing row exists is not. The registry record can establish the address interval associated with the recorded object; a separate routing observation must establish whether that interval, a covering aggregate or a more-specific prefix was announced at the relevant time.

That separation matters most when a system tries to automate a conclusion. A non-empty cidr0_cidrs array should not set a flag called routed, assign an origin autonomous system or imply live reachability. Those outputs add facts the source never supplied. The safe transformation is narrower: store the CIDR expressions as registration-range evidence, retain AFRINIC and the capture time as provenance, and leave routing fields unset until a routing source is observed.

The two evidence systems become more useful, not less, when their boundary remains visible. An analyst can compare the registered interval with an independently captured route, identify a missing or more-specific announcement, or investigate a change in origin. The comparison may reveal alignment or divergence. But the investigation begins with two separately sourced facts; it cannot begin by turning one RDAP array into both of them.

What the CIDR array contributes

The NRO’s cidr0 extension solves a representation problem. The core RDAP network object records a start address and an end address. Those boundaries are precise, but many network tools work with prefixes rather than inclusive ranges. When the boundaries align cleanly, one prefix can express the object. When they do not, a sequence of prefixes is needed to cover the range without adding addresses that the registration does not contain.

That is why the field is an array. Each member carries a version-specific prefix and a length: v4prefix with a length from zero through 32 for IPv4, or v6prefix with a length from zero through 128 for IPv6. The array must be read as the CIDR rendering of the IP-network registration that contains it. It is not a list of routes discovered elsewhere and inserted into the registry response.

For the AFRINIC object observed on 28 August 2026, the start and end addresses align exactly on a /24 boundary. The field therefore contains one expression rather than a decomposition into several blocks. This makes the record easy to consume, but simplicity does not broaden its evidentiary scope. A single CIDR member and a ten-member CIDR array answer the same kind of question: how can this registered interval be represented as prefixes?

The response’s conformance list provides another useful control. It includes cidr0, telling a client which extension defines the additional member. A client that understands the extension can parse the field according to the registered specification. A client that does not understand it should not guess at its semantics merely because the field resembles a route. Conformance metadata is therefore part of the evidence: it connects a compact JSON name to the specification that bounds its meaning.

This is a modest but important form of interoperability. Registry data can be normalized without forcing every consumer to reinvent range-to-prefix conversion. Security teams can use the registered interval in an access-control inventory; researchers can compare allocation records with routing observations; operators can reconcile address-management systems. All of those uses begin with a faithful registration fact. Any claim about route state must arrive from the other side of the comparison.

What routing evidence remains missing

An RDAP response is a snapshot of registration data, not a view of the global routing system. The observed object does not say that 196.1.0.0/24 was present in a BGP table at the capture time. It does not identify an origin autonomous system, report an AS path, count observing peers, distinguish a covering aggregate from a more-specific announcement or show when a route was introduced or withdrawn.

Those are not small omissions that can be filled by inference. They are the defining components of a routing claim. RFC 4271 describes BGP as an inter-autonomous-system protocol for exchanging reachability information. A destination prefix becomes part of a route in conjunction with path attributes carried by an update and observed by a BGP speaker. The same prefix characters in a registry response do not reproduce that message or observation.

Even a confirmed BGP announcement would answer only some operational questions. It could establish that a collector or peer saw a route with particular attributes at a particular time. It would not by itself prove end-to-end packet delivery, traffic volume, service quality, contractual transit, router access or corporate control. The evidence ladder must therefore remain explicit: registration range, routing observation and traffic or organisational claims occupy different steps.

Time is equally important. The AFRINIC record and any routing measurement may be captured at different moments. A registration can remain stable while the route changes, or a route can remain visible while registry metadata is updated. Joining the two without timestamps turns a comparison into an accidental narrative. A reliable analysis records when each source was observed and limits its conclusion to the period those observations support.

The burden of proof rises further for negative claims. Failure to see a route in one collector does not establish that the prefix was absent everywhere. Visibility depends on the observation point, collection method and time window. The responsible conclusion is bounded: a specified source did or did not observe a specified route at a specified time. AFRINIC’s CIDR array cannot resolve that uncertainty because it was never intended to measure propagation.

A field-level method for using the record

The safest workflow is to preserve three layers. First, store the RDAP fact exactly as observed: source URL, capture time, object handle, start address, end address, conformance identifiers and cidr0_cidrs members. Second, attach the narrow interpretation supplied by the specifications: the array renders the registration range as CIDR expressions. Third, create separate records for any routing, traffic or organisational evidence used to extend the analysis.

This structure prevents an apparently harmless transformation from becoming an unsupported claim. A field named registeredPrefixes can be populated from cidr0_cidrs. A field named observedRoutes cannot. An origin-AS column must remain null until a routing source supplies it. A reachability claim needs evidence suited to reachability. Null is not a failure here; it is an accurate statement that the registry source did not answer the question.

Provenance also makes disagreement intelligible. A registered range may be covered by an aggregate rather than an exact route. A more-specific route may appear within it. Different collectors may report different paths. A later observation may show a different origin. None of those outcomes invalidates the RDAP record; each describes a different property or time. Keeping the records separate lets analysts ask why they diverge instead of forcing them into false consistency.

The same discipline applies to reader-facing prose. “AFRINIC records this interval as 196.1.0.0/24” is supported by the captured response. “The prefix is routed” requires a cited routing observation. “The registrant controls the network” requires evidence of authority and operations that neither the CIDR array nor a route alone can provide. Small changes in wording protect large differences in meaning.

Evidence boundary and sources

The observation underlying this briefing is intentionally narrow. AFRINIC’s public RDAP endpoint returned the selected IP-network fields for 196.1.0.0/24 at 2026-08-28T06:35:54Z. The analysis does not add a routing-table lookup and makes no claim about the prefix’s current announcement, origin, path, reachability or traffic.

The field semantics come from AFRINIC’s RDAP documentation, the IANA RDAP Extensions registry, the NRO extension specification and the IETF standards for RDAP JSON responses and BGP. These sources define what the observed record can establish and, just as importantly, what remains outside it.