Summary

  • AFRINIC’s live response for 196.216.2.0 gives the returned network object the handle 196.216.2.0 - 196.216.3.255 while also carrying explicit start and end addresses.
  • RFC 9083 defines a handle as registry-unique and scoped to the closest enclosing object. It is not a universal routing, ownership or operational identifier.

One string, two different jobs

The live AFRINIC response describes an IP-network object spanning 196.216.2.0–196.216.3.255. Its handle repeats that interval as a human-readable string. Separate members still state startAddress, endAddress, ipVersion, name, type, country, parent, status, contacts and events.

That separation matters. The address members describe the numeric bounds of the registered object. The handle gives the registry a way to refer to the object instance. A database can choose a familiar string for a handle without turning that string into a universal key for every other system that discusses the same addresses.

RFC 9083 supplies the controlling scope: registries have registry-unique identifiers that can specifically reference an object instance, and a handle refers to the closest enclosing object where it appears. The standard does not promote that reference into a globally shared identity across RIRs, IRRs, RPKI repositories, BGP collectors or commercial inventories.

Preserve the namespace with the value

A durable observation should therefore store the handle together with the registry, object class, queried endpoint and capture time. Stripping those qualifiers creates a false promise of universality. Two systems may format, normalize or key the same address space differently without contradicting the AFRINIC record.

The handle also does not prove legal title or transferable ownership. It does not name a BGP origin AS, identify a transit provider, reveal route propagation, demonstrate reachability or locate traffic. Those conclusions require their own legal, registry, routing and measurement evidence.

Sources