Loading country data...
This tab shows how well government domains in support IPv6 and DNSSEC. Every domain is scanned to check whether its nameservers, mail servers and web servers can be reached over IPv6. Click any row in the table below to see the full technical detail for that domain.
| Domain | Organization | Sector | DNS | Web | DNSSEC |
|---|
No analysis results yet
Domains are registered but haven't been analysed. Run the monitor to generate results.
This tab shows how many internet users in actually use IPv6, measured by the APNIC Measurement Lab. IPv6 Capable is the share of users whose device and network can reach IPv6 destinations. IPv6 Preferred is the share who choose IPv6 over IPv4 when both are available. The table below breaks these figures down by network operator.
Source: APNIC Measurement Lab,
APNIC measurement data is not available for this country.
| ASN | Provider Name | IPv6 Capable % | IPv6 Preferred % |
|---|
AFRINIC is the Regional Internet Registry for Africa. It distributes internet number resources, such as IP addresses and AS numbers, to organisations across the continent. This tab lists every IPv6 address block AFRINIC has allocated or assigned to organisations in . Think of a block as a reservation: the organisation owns that range of addresses and may use it, but holding a block does not by itself make those addresses reachable on the internet. The BGP Routing tab shows which of these blocks are actually announced and reachable.
Source: AFRINIC, the allocation registry for Africa
No AFRINIC IPv6 allocation data found for this country. Run node fetch-afrinic.js to populate.
Each row is one AFRINIC member organisation and the number of IPv6 blocks they hold. Members holding more than one block show their first block. Click the row to see all of them.
| AFRINIC Member | IPv6 Blocks | Number of Blocks |
|---|
This tab shows which AFRINIC members in are advertising their IPv6 address blocks to the rest of the internet. The data comes from AFRINIC's own Border Gateway Protocol (BGP) announcement records, which track whether each allocated block appears in the global routing table and which network announces it. Once a member announces a block, addresses in that range become reachable from anywhere on the internet. A block marked More specifics is not advertised at its full allocated size, but smaller parts of it are routed. A block marked Not Routed has been allocated but is not yet reachable.
Source: AFRINIC allocations × AFRINIC BGP announcement dataset
No BGP routing data available. Run node fetch-afrinic.js && node build.js to populate.
Each row is one AFRINIC-allocated IPv6 block and its BGP routing status
| AFRINIC Member | IPv6 Block | BGP Status | Announcing ASN(s) |
|---|
Every domain on the Domain tab sits underneath a country code top level domain, or ccTLD. 's ccTLD is the zone its national registry runs, and it is the single most important zone in the country: if the registry's authoritative nameservers cannot be reached over IPv6, nothing underneath them can be either, no matter how well an individual domain is configured.
This tab asks five questions of every one of those nameservers. Does it have an IPv6 address? Does it answer over IPv6? Can it serve a DNS query over IPv6? Does it handle EDNS(0), the extension every modern resolver uses to ask for answers larger than the 512 bytes the original protocol allowed? And when an answer is too large for one UDP packet, does the server say so and then deliver it over TCP? The delegation comes from the IANA root zone, which is where every resolver on the internet starts when it looks up a name in this country. It also checks that delegation against what the registry's own servers say, because the two can drift apart when a nameserver is added or retired.
The first three questions only prove a server can answer the smallest question there is. A signed zone's answers are far bigger: DNSSEC signatures push a reply well past the 1232 bytes that can be counted on to cross the internet in a single UDP packet, and the server is then meant to reply "too big", so the resolver asks again over TCP. That second path is where DNS over IPv6 most often breaks. So for every zone that is signed and validated we deliberately ask for an answer we know is too large, and check both halves: the "too big" signal, and the TCP retry over the same IPv6 address. Zones that are not signed are marked not tested rather than failed, because they have nothing large to send.
Measured from a single vantage point in Africa, so a nameserver answering here does not prove it answers from everywhere. Serving queries is the reliable signal: some operators drop ICMPv6, which makes a server look unreachable while it answers queries perfectly well. The EDNS(0) result is read from the reply to the query we already send, so it reports whether the server understands the extension, not the full compliance suite AFRINIC's own study of African ccTLD servers ran.
No ccTLD data found for this country. Run node fetch-cctld.js to populate.
| Nameserver | ccTLD | Has IPv6 | Reachable | Serving Queries | Large Answers | IPv4 |
|---|