Summary

  • AFRINIC’s response for 196.216.2.1 describes the registered range 196.216.2.0–196.216.3.255 and reports ipVersion: v4.
  • RFC 9083 scopes that value to the returned network object. It is not an inventory of every address family, route or service associated with the organisation.

The answer follows the question

The live AFRINIC response is an ip network object. It gives start and end addresses, a handle, name, type, country, parent, status and events. Because the queried address is IPv4, its ipVersion value is v4.

That is exactly the job specified by RFC 9083: v4 signifies an IPv4 network and v6 signifies an IPv6 network. The field helps parsers interpret the address bounds and keep unlike objects apart. It says nothing about whether the registrant, an associated entity or the registry itself holds other records in another address family.

The common analytical error is a scope jump. A system queries one familiar IPv4 address, sees v4, and labels the organisation “IPv4-only”. The response never performed an organisation-wide search. It did not enumerate IPv6 allocations, test AAAA records, inspect IPv6 BGP announcements or probe any service over IPv6.

Build an IPv6 claim from IPv6 evidence

If the question is registration, search the relevant registry for IPv6 objects and preserve query scope, time and identifiers. If the question is routing, record IPv6 prefixes and path attributes from named collectors. RFC 4271 locates route evidence in destinations and path attributes exchanged in UPDATE messages, not in an RDAP address-family label. If the question is service readiness, test specific hostnames and services from declared vantage points.

These observations may disagree without contradiction. An organisation can have IPv6 registration but no visible route, a route but no public dual-stack service, or a working service absent from the original IPv4 object. The disciplined statement remains narrow: at capture time, AFRINIC returned this bounded network object as IPv4.

Sources