The abuse ticket looked ordinary until everyone tried to name the responsible party. A regional ISP had received complaints about credential-stuffing traffic from a small /27 used by one of its business customers. The registered holder of the parent IPv4 block was visible in the AFRINIC record. The origin AS was visible in BGP. A reseller sat somewhere in the commercial chain. A managed firewall provider handled the edge device. The customer whose servers were generating the traffic wanted privacy, partly because the machines might have been compromised and partly because it did not want its hosting arrangements exposed to competitors. The upstream wanted accountability. The bank that filed the complaint wanted a person who could stop the attack. The registry ledger named the holder, not the small operational user.
That gap is the subject of suballocation visibility. The word "suballocation" has a formal meaning in AFRINIC policy: an LIR can distribute space to downstream ISPs for subsequent distribution, subject to size, documentation and registration rules. The economic problem is wider than the formal label. Scarce IPv4 is now used through holders, LIRs, downstream ISPs, resellers, hosting providers, managed-service vendors, cloud platforms, brokers, leasing arrangements, enterprise customers and sometimes further delegated users. Some of that use is legitimate and ordinary. Some of it is privacy-sensitive. Some of it is commercially confidential. Some of it is where abuse, fraud, sanctions screening, law-enforcement requests, geolocation errors, routing mistakes and reputational damage actually arise.
The public record often sees only the first layer. The internet operates through many more layers. A prefix can be registered to one party, originated by another, delegated in reverse DNS to a third, listed in an IRR object maintained by a broker's contact, covered by a ROA created by the formal holder, and used by customers whose names never appear in RDAP or WHOIS. None of this is automatically suspicious. Division of labour is normal in network operations. The problem begins when every outsider must bear the cost of discovering the responsible operator after something has already gone wrong.
AFRINIC is a useful test case because the downstream layer is already embedded in the operating rules that networks must live with, while its recent institutional history shows why visibility below the holder matters. The African Network Information Centre serves Africa and part of the Indian Ocean as the regional internet registry. It sits on the services that turn resource use into public evidence: WHOIS, RDAP, reverse DNS, an Internet Routing Registry and RPKI. The relevant operating rules require allocations, assignments and suballocations to be registered in the AFRINIC database, and say registration data such as names, blocks, contacts and status must remain correct. They also tie reverse delegation to registered assignments or suballocations. Those rules are not ornamental. They are the narrow points where downstream operating reality is supposed to become legible.
The pressure on those points has risen. AFRINIC entered IPv4 Soft Landing Phase 2 on January 13th 2020, with ordinary new IPv4 allocation and assignment sizes constrained to small blocks, including a /24 minimum and /22 maximum. Public reporting has described allegations of address-record manipulation involving dormant African IPv4 space, the high-value dispute between AFRINIC and Cloud Innovation over resource use and commercialisation, a 2021 court freeze of AFRINIC funds, receivership from 2023, board and election discontinuity, an annulled 2025 election attempt, later board restoration, and continuing recovery questions in 2026. These events should not be turned into a generic governance morality tale. For suballocation visibility, their importance is narrower: when the registry itself is under stress, markets rely even more heavily on clear evidence of who is using scarce addresses, who can be contacted, and which uncertainty is real rather than rumour.
The right question is not whether every customer should be publicly named. That would be dangerous and economically foolish. The right question is how much downstream detail should be visible, to whom, at what level of certainty, and with what effect on the cost of routing, abuse response, transfers, leasing, public procurement and registry accountability. A public ledger is not a private customer list. But if it exposes only the formal holder while the practical user sits three contracts away, it leaves the market to price opacity.
The invisible customer is now the expensive fact
In the abundance era, a hidden downstream customer was often a nuisance rather than a pricing problem. If abuse came from a customer subnet, the provider could trace it inside its own systems. If a contact was stale, another allocation might be available. If a small range was misconfigured, renumbering was painful but not a capital event. IPv4 scarcity changed that arithmetic. A small block can support hosting revenue, payment infrastructure, government portals, SaaS customers, VPN access, anti-fraud systems, mail reputation and network continuity. The customer behind the address is no longer just an operational detail. It is a source of risk, value and liability.
Opacity has a measurable economic path. It raises search cost, because a complainant, upstream, buyer, bank, insurer or investigator must spend time determining whether the listed holder, origin AS, reseller, managed-service provider or end customer can fix the issue. It raises error cost, because if the responsible /27 cannot be identified quickly, counterparties overblock a /24, a /22 or an entire holder reputation. It raises contracting cost, because customers and counterparties demand warranties, indemnities, escrow, emergency contacts, service credits and extra diligence when the public record does not tell them enough. It raises capital cost, because a lender or buyer discounts revenue tied to addresses whose operating responsibility cannot be independently reconstructed.
The invisible customer also changes incentives inside the chain. A holder that can collect revenue while leaving the downstream user unrecorded may underinvest in abuse response and customer verification. A reseller that can pass responsibility upward may sell to riskier customers. A managed provider that does not appear in the record may avoid reputational damage when its configuration fails. A customer that cannot be publicly named for legitimate privacy reasons may still need to provide authenticated responsibility to the holder, the registry or a lawful requester under defined conditions. If no one knows which layer bears which duty, everyone has an incentive to keep the profitable part visible and the risky part private.
AFRINIC's policy language points toward the correct distinction. Suballocations and assignments are supposed to be registered because uniqueness, troubleshooting and continuity require more than the holder's name. At the same time, the manual does not require a public dossier on every downstream user. The useful middle ground is responsibility visibility: enough public and authenticated information to identify the responsible operating layer, without exposing every customer identity to the whole internet.
The cost of getting this wrong is highest for smaller networks. Large platforms can build private trust channels with major banks, transit providers, security vendors and public authorities. Small ISPs and regional hosting firms cannot. They depend on public and semi-public records to be believed by strangers. If the public evidence is thin, they pay through delays, stricter filtering, lost customers and weaker bargaining power. Suballocation opacity therefore becomes a regressive tax on the networks least able to absorb it.
The downstream layer is already part of the allocation economy
AFRINIC's policy manual does not describe address distribution as a one-step transaction between registry and final user. It defines a hierarchy. An LIR receives allocations from a regional registry and primarily assigns address space to end users. A suballocation is distribution by an LIR to an ISP for subsequent distribution. An assignment is a block given by an LIR to an ISP or end user for specific use within the infrastructure that party operates. Provider-aggregatable space can be assigned or suballocated to downstream networks as non-portable space, while provider-independent assignments are not for further suballocation. This is already a layered system.
The manual then attaches responsibilities to that layering. It says every allocation, PI assignment, PA assignment, suballocation and other resource assignment must be registered in the AFRINIC database, and that unregistered resources will be considered invalid. It requires registration data to be correct at all times. It sets the minimum formal IPv4 suballocation at /24. It requires LIRs to make suballocations within their suballocation windows or seek AFRINIC approval above those windows. It makes LIRs responsible for ensuring that space allocated to them and subsequently suballocated is used according to community policies and guidelines. It advises slow start for downstream ISPs. It treats downstream ISP space as non-portable within the LIR's aggregatable block.
Those rules reveal the institutional logic. AFRINIC does not have to know every packet's user, but it cannot remain indifferent to downstream structure. If a downstream ISP receives a /24, the registry's database should not remain blind. If an end user's public address space is not merely point-to-point infrastructure, the manual says it should be registered with end-user contacts, with a privacy accommodation for individuals. If reverse DNS is requested for a /24, the manual says at least one assignment or suballocation must be registered for that specific /24. The registry services themselves assume registered downstream facts.
The modern difficulty is that commercial reality creates layers that do not always match the old categories. A hosting company may assign /29s, /28s or /27s inside a registered /24. A firewall provider may operate security appliances for many customers inside a provider's aggregate. A reseller may sell virtual private servers without receiving a formal /24 suballocation. A broker may help arrange use without appearing as a technical operator. A leasing platform may coordinate customer access while the registered holder remains unchanged. A managed-service provider may control abuse remediation but not route origination. The downstream layer is more granular than the policy unit.
That mismatch should not lead to two bad answers. The first is to pretend the public registry can ignore everything below the registered holder. That makes troubleshooting, abuse response, diligence and law-enforcement routing too expensive. The second is to require every small customer range and every customer name to be public. That creates privacy and security harms and may push legitimate operators into private arrangements that reveal less, not more.
A better answer starts from functional visibility. The record should distinguish holder-operated space from customer assignment, downstream ISP suballocation, reseller-managed space, managed-service operation, lease-supported operation, privacy-protected end-user use and disputed or stale status. It need not always publish the customer's legal name. It should publish enough to show which layer is responsible for operational response and how much weight attaches to that statement. The holder remains accountable for the registry relationship. The downstream operator becomes findable for operational matters. The customer can remain shielded where law, safety or commercial confidentiality justify it.
That registration logic already supports a responsibility map. Registration exists to ensure uniqueness and provide information for troubleshooting. In an IPv4 scarcity market, troubleshooting now includes abuse reachability, route-origin explanation, reverse-DNS consistency, subdelegation evidence, transfer diligence, public-sector procurement and the ability of strangers to distinguish a hidden customer from an abandoned record.
A public ledger is not a private customer list
The institutional boundary is simple to state and hard to implement. A public registry ledger should not become a customer list. It should become a responsibility map. The distinction matters. A customer list discloses who buys services from whom. A responsibility map discloses which role is answerable for a resource segment, which contact channel is live, what evidence supports the role, and how much confidence outsiders should assign to it.
For public users, the minimum useful record is not full customer identity. It is role and reachability. A public record can show that a /24 is holder-operated, assigned to an organisation, suballocated to a downstream ISP, used through a managed service, delegated to a privacy-protected end user, leased or commercially delegated under holder responsibility, or subject to dispute or stale confirmation. It can publish role contacts: holder contact, technical contact, abuse contact, routing contact and reverse-DNS contact. It can expose timestamps: first registration, last validation, last material update and validation expiry. It can show whether the downstream role was self-attested by the holder, validated by AFRINIC, inferred from routing evidence, confirmed by reverse-DNS delegation, or privacy-redacted.
For authenticated counterparties, more detail may be appropriate. A transit provider evaluating a route, a buyer conducting transfer diligence, a registry handling a review, or a public body with a lawful request may need the legal identity of the downstream operator, a letter of authorisation, contract evidence, emergency contacts, operational geography, customer category, escalation time windows and proof that the holder can compel cooperation. Those details need not be world-readable. They can be held by the holder, deposited with the registry in limited form, shared under nondisclosure, or disclosed through court order or statutory demand.
For courts and law enforcement, the threshold should be higher but the information deeper. Where a lawful request seeks the identity behind a privacy-protected assignment, the system should not require investigators to guess across five intermediaries. The holder should be able to trace the chain. The registry should know whether the holder claims such traceability. The public record should show that a privacy-protected downstream user exists and that lawful escalation has a defined path, not that the customer is invisible to everyone.
Evidence labels are essential, but they should be used sparingly and plainly. The same visible fact has different value depending on how it was obtained. A holder-attested downstream ISP is not the same as a registry-validated one. A routing-observed origin is not the same as a registered operational user. A reverse-DNS delegation is not proof of abuse responsibility. A privacy-redacted user is not the same as an unknown user. A record refreshed last month is not the same as one last touched in 2014. A registry that exposes these differences lowers the cost of interpretation without pretending to know more than it knows.
The same structure protects the registry from overreach. By publishing role, contactability, evidence status and uncertainty, AFRINIC can improve public reliance without asserting a right to inspect every customer for policy conformity. It can say: this is the recognised holder; this block is downstream-operated; the responsible operational channel is here; the legal identity is withheld from public view but traceable under defined conditions; the last validation date is current or stale. Such a ledger is thinner than a customer database and thicker than a bare holder record. That is the economically useful middle.
Scarce IPv4 turns opacity into a market discount
Suballocation opacity is not only a security problem. It is a market discount. When a scarce resource cannot be traced from holder to actual operational responsibility, every counterparty prices the gap. The buyer of a block wants to know whether undisclosed downstream users will resist migration. The lessee wants to know whether the lessor can support route, reverse-DNS and abuse changes through every intermediate reseller. The bank wants to know whether address-supported revenue depends on customers whose contracts cannot be verified. The public buyer wants to know whether a critical service sits on addresses whose authority chain is ambiguous. The upstream wants to know whether it can accept the route without becoming the first reachable party for every complaint.
AFRINIC's scarcity facts make the discount concrete. Its exhaustion notice said that Phase 2 began when no more than a /11 of non-reserved space remained in the final /8. In Phase 2, ordinary allocation or assignment range is small, with a /24 minimum and /22 maximum. Such limits do not eliminate demand; they move demand into reuse, transfers, leasing, hosting supply, customer reassignment and operational delegation. The more demand moves through existing holders, the more important it becomes to know what is happening below those holders.
Opacity also makes old records more dangerous. KrebsOnSecurity reported in 2019 on allegations that valuable African IPv4 space associated with dormant or defunct organisations had been diverted or sold through companies linked to a former senior AFRINIC figure; researcher Ron Guilmette estimated the affected space at more than $50m in market value. The significance for suballocation visibility is not only the alleged corruption. It is that dormant records and weak authority trails become valuable when IPv4 has a price. A record that does not clearly reveal who can speak for downstream use invites both fraud and defensive discounting.
The Cloud Innovation dispute shows the opposite edge of the same problem. Public analyses described a conflict over millions of IPv4 addresses, commercial leasing, actual use compared with registered or expected use, and AFRINIC's claimed ability to review or terminate resource recognition. Cloud Innovation contested AFRINIC's theory and litigation escalated. For suballocation visibility, the lesson is not that every lease is bad or that every registry inquiry is legitimate. The lesson is that when actual downstream use is opaque, the registry may be tempted to ask for broad customer information, while the holder may resist by claiming commercial privacy. Both sides can be partly right and still produce a bad equilibrium.
In a good equilibrium, holders reveal structured responsibility without surrendering raw customer lists. In a bad equilibrium, they reveal little, the registry demands too much, litigation starts, and the market discounts the whole portfolio. Scarce IPv4 makes that discount large enough to change behaviour. A holder with poor downstream visibility faces lower buyer confidence, higher legal cost, worse reputation after abuse and weaker public-sector acceptance. A registry with poor visibility faces pressure to use broad reviews because narrower evidence is unavailable. The absence of visibility thus creates the argument for discretion.
The economic target should be to make responsible use cheaper than hidden use. A holder that maintains validated downstream role records, live contacts, traceable privacy-protected customers and plain uncertainty labels should face lower friction in transactions and incidents. A holder that cannot explain who is using its space should pay through discounts, slower approvals and stricter scrutiny. That is not punishment. It is pricing information quality.
The evidence stack is plural, and each surface has limits
No single data source can answer the downstream-responsibility question. RDAP and WHOIS provide registered holder and contact data. BGP shows which autonomous system originates a route. IRR objects express routing policy and route authorisation conventions. RPKI and ROAs can validate origin authority. Reverse DNS can reveal naming patterns, customer delegations and operational history. Geolocation databases, traceroute, latency, TLS certificates, abuse histories, DNS zones, mail reputation, hosting banners, corporate records and customer contracts may each add clues. None is conclusive by itself.
That plural evidence stack is both useful and dangerous. It is useful because downstream responsibility often appears only when signals are combined. A /24 registered to a holder, originated by a hosting ASN, covered by a ROA for that ASN, named with a reseller's reverse-DNS pattern, listed in an IRR object maintained by a third party, and carrying abuse history tied to VPS customers is likely not holder-operated in the simple sense. But it is dangerous because inference can outrun proof. A reverse-DNS label may be stale. An IRR object may be unauthorised. A geolocation database may be wrong. A ROA may prove route-origin authority, not customer identity. An origin AS may be a transit or managed-service operator, not the ultimate user.
AFRINIC's public services sit across much of this stack. The registry provides WHOIS, RDAP, reverse DNS, IRR and RPKI-related services. Its policy manual connects reverse delegation to registered assignments or suballocations. Its abuse-contact policy creates a place for abuse information while acknowledging that the object, like other objects, faces the data accuracy problem. The candour matters. A field can create a channel without proving the channel is correct. A ROA can authorise an origin without proving the downstream customer. An assignment can identify an end-user range without proving every later operational detail.
The public record should therefore expose evidence type. A downstream role can be registered, holder-attested, registry-validated, routing-observed, reverse-DNS-consistent, contract-deposited, traceable by lawful escalation, stale, disputed or privacy-redacted. These labels can sound bureaucratic if overused. Used well, they are economically valuable. They prevent a weak signal from being treated as a strong signal and prevent absence of public identity from being treated as absence of responsibility.
Evidence labels also reduce the incentive for private mythology. In opaque markets, brokers and counterparties fill gaps with claims: clean block, court-backed, first-party, Africa-compliant, no abuse, fully authorised, safe for public-sector use. Some claims may be true. Some may be marketing. A registry record that exposes structured evidence gives buyers and operators a way to test claims without turning AFRINIC into a commercial referee. The registry can say what it has validated and what it has not. The market can price the rest.
This matters especially under institutional stress. During receivership, election disputes or litigation, rumours become substitutes for records. If the public database cannot distinguish ordinary downstream operation from disputed delegation, or privacy protection from unknown use, counterparties will infer from headlines. A thin evidence label can prevent an expensive overreaction. The registry does not need to guarantee every downstream fact. It needs to disclose the status of the facts it carries.
The evidence stack should be read as a probability map. The stronger the combination of registered suballocation, validated contact, matching route origin, current ROA, coherent reverse DNS and recent confirmation, the lower the ambiguity tax. The weaker the combination, the more caution is justified. That is how markets already behave informally. AFRINIC can improve the market by making the informal probability map more explicit.
Abuse reachability is a consequence, not the whole story
Abuse complaints are often where suballocation opacity becomes visible. A bank sees attacks. A security vendor sees malware callbacks. A mail operator sees spam. A copyright claimant sees hosting. A public body sees scanning against a government service. The complainant queries the registry and sends mail to the listed contact. If the listed holder is not the actual operator, the ticket starts moving sideways: holder to reseller, reseller to hosting provider, hosting provider to managed firewall vendor, vendor to customer. Each hop adds delay and error.
It is tempting to make abuse contact the whole subject. That would be too narrow. Abuse reachability is one output of downstream visibility, not the full economics. The same visibility affects routing acceptance, transaction diligence, customer continuity, public procurement, sanctions screening, law-enforcement response, geolocation, reverse DNS, RPKI maintenance and reputation management. An abuse ticket is simply the moment when the hidden structure becomes expensive enough to notice.
AFRINIC's abuse-contact policy is useful evidence of this limited role. It specifies a dedicated object as the preferred place to publish public abuse contact information, referenced in inetnum, inet6num and aut-num objects. It aims to help abuse reports reach the correct network contact. It also acknowledges a disadvantage: the object faces the same data accuracy problem as other objects and does not by itself improve database accuracy. That is exactly the point. A mailbox does not solve downstream opacity if the mailbox belongs to the wrong layer or if the holder cannot compel the downstream operator to act.
A better structure ties abuse reachability to role visibility. If a block is holder-operated, the holder's abuse desk should be the primary public channel. If it is suballocated to a downstream ISP, the downstream ISP's validated abuse channel should be visible, with holder escalation preserved. If it is assigned to an enterprise customer whose identity is privacy-protected, the public record should publish a responsible operational desk or proxy plus a lawful escalation path. If it is managed by a firewall or hosting provider, the public record should show which operational layer receives abuse first. If responsibility is disputed or stale, the record should say so.
This avoids two common failures. The first is the wrong-desk problem, where complaints reach the legal holder but not the operator able to remediate. The second is the unaccountable-customer problem, where the holder claims privacy or reseller distance and no reachable party acts. In both cases, the cost shifts to outsiders. Banks overblock. Upstreams threaten suspension. Reputation services mark neighbouring space. Law enforcement escalates through slower channels. Innocent users share the penalty.
Abuse visibility also protects holders. A holder that can show validated downstream responsibility can narrow its own exposure. It can tell a complainant: this range is operated by this downstream role; here is the abuse channel; the holder remains available for escalation if the downstream desk fails. That is better than receiving every ticket, missing some, and being treated as negligent. It is also better than publishing raw customer identities in a way that creates privacy or safety risks.
The economics are therefore not about making every holder run a large abuse department. They are about making the path to responsibility short enough that fixed incident costs do not fall on random outsiders. Suballocation visibility is the broader infrastructure that makes abuse-contact policy work.
Accountable redaction is the privacy bargain
The strongest objection to downstream visibility is privacy. It deserves to be taken seriously. A public registry that names every downstream customer could expose vulnerable organisations, security operations, whistleblower infrastructure, political groups, public-sector contractors, financial institutions, health providers and ordinary businesses. It could also turn the registry into a reconnaissance tool. Attackers could map customers, infer procurement relationships, identify managed-security vendors, target migration windows or pressure service providers. Commercial competitors could learn who hosts whom. A visibility policy that ignores these harms would defeat itself.
But privacy does not justify complete opacity. The internet already imposes externalities on strangers. Packets from a range can attack a bank, scan a hospital, host phishing pages, pollute mail reputation, trigger sanctions review or affect a public service. If the responsible party is hidden behind privacy language and no traceable channel exists, privacy becomes a way to export cost. The design problem is to preserve confidentiality while preserving accountability.
The practical answer is tiered disclosure. Public records should carry role, contactability, status, validation date and evidence strength. They should not necessarily publish every legal customer name. Authenticated counterparties can receive more detail under contract or operational need. The registry can hold or verify limited evidence without disclosing it publicly. Law enforcement and courts can obtain deeper identity information through lawful demand. Emergency channels can exist for imminent harm without making emergency disclosure routine. Individuals can receive stronger redaction than corporate downstream ISPs. Public agencies can use designated security contacts rather than exposing every contractor.
Redaction should be labelled, not silent. "Customer identity withheld for privacy; holder maintains traceable contact; abuse proxy validated" is economically different from "no downstream information." It tells outsiders that there is a responsible structure even if the name is not public. It also creates accountability for the holder: if the holder claims privacy-protected traceability, it must be able to trace. Failure to trace under defined conditions should have consequences, because otherwise privacy becomes a false status.
The label should also separate privacy from commercial secrecy. A bank's sensitive infrastructure, a human-rights group and a reseller's customer list may all deserve protection, but for different reasons and against different disclosure levels. A downstream ISP receiving a formal /24 suballocation is not in the same position as an individual customer receiving a small assignment. The public interest in identifying an operational network is higher than the public interest in naming every end user. AFRINIC's policy manual already contains a limited privacy accommodation when an end user is an individual: space may be registered with the provider's contact information while referencing the end user in the database object. That logic can be extended carefully.
The institutional test is whether the system can answer a narrow question: if harm, dispute or lawful demand arises, who can act? It need not answer every curiosity. It need not publish every customer. It must not let privacy erase responsibility. In a scarce IPv4 market, the privacy design that works is not secrecy. It is accountable redaction.
Routing, IRR and RPKI prove authority, not use
Routing evidence is powerful because it is observable. If a prefix is originated by a particular AS, the operational internet can see it. If an IRR route object exists, networks can infer an asserted routing policy. If a ROA authorises an origin AS, relying parties can validate route-origin authority. These signals matter for downstream visibility, but they should not be mistaken for a complete account of use.
BGP origin identifies the network announcing the route, not necessarily the customer using the addresses. A hosting provider may originate space for many customers. A managed-service provider may announce a prefix on behalf of an enterprise. A lessor may authorise a lessee's AS while the lessee serves thousands of small users. A transit provider may appear in evidence because of route handling rather than customer responsibility. The origin AS is a clue about operational control, not a legal identity for every downstream user.
IRR objects have similar limits. They can help upstreams and peers build filters. They can show that someone has created a route or route-set object consistent with a claimed origin. But IRR data can be stale, duplicated, created in different databases with different authentication standards, or maintained by a party that is no longer operationally responsible. An IRR object maintained by a broker's technical contact may help explain how the route was accepted, but it does not prove who handles abuse or customer contracts.
RPKI and ROAs are stronger for origin authority, but narrower for responsibility. A valid ROA can say that a specified AS is authorised to originate a prefix. It cannot say why the AS is using the space, who the downstream customer is, whether the use is regional, whether a reseller is involved, whether abuse reports reach the right desk, or whether a customer assignment exists below the covered prefix. RPKI is a route-origin security tool, not a customer-identity system.
This distinction matters for AFRINIC because RPKI and IRR services sit near registry recognition. A holder may be able to create a ROA for a lessee's AS. That makes the route look legitimate in a security sense. It does not make the downstream chain visible. Conversely, absence of a ROA may reflect operational delay or low adoption rather than unauthorised use. If the public record treats RPKI as the only proof, it will miss the actual responsibility problem.
The correct use of routing evidence is triangulation. A downstream role record can say that the registered holder has authorised AS X to originate prefix Y; that a ROA exists or does not exist; that an IRR object exists and is current or stale; that the abuse contact for the operational role is reachable; and that the customer identity is public, authenticated-only or privacy-redacted. This combines routing authority with responsibility visibility. It does not overload a cryptographic or routing-policy artefact with facts it cannot prove.
AFRINIC's institutional recovery would benefit from this precision. The registry does not need to become an omniscient judge of downstream use. It needs to stop allowing one evidence surface to impersonate another. Routing says reachability. RPKI says origin authority. IRR says policy assertion. RDAP and WHOIS say registered recognition and contacts. Reverse DNS says naming delegation. Downstream visibility says who is responsible below the holder, and how sure anyone can be.
Reverse DNS is a clue, not proof
Reverse DNS is often treated as a secondary technical service, but in downstream visibility it carries disproportionate practical weight. A PTR record can reveal a hosting brand, a reseller pattern, a customer label, a country hint, a mail-service identity or an old use that should have been removed years ago. Mail systems, security tools, customer support teams and investigators routinely look at reverse DNS because it offers a human-readable clue when the registry record is too abstract.
AFRINIC's policy manual gives reverse DNS a formal link to downstream registration. It says AFRINIC accepts reverse-delegation requests from active LIRs and that no reverse delegation of administered or allocated IP address space is allowed unless an assignment or suballocation from the specific allocation is registered appropriately in the AFRINIC database. For a /24 reverse delegation, at least one assignment or suballocation must be registered for that specific /24. That rule is a quiet acknowledgement that reverse DNS should not float free from registered downstream facts.
The clue can still mislead. Reverse DNS is often stale after a customer leaves. Naming conventions may use generic labels that hide the actual operator. A holder may delegate reverse DNS to a reseller whose customer controls the service. A security provider may use neutral names to avoid exposing customers. A mail operator may set names for deliverability rather than identity. A malicious user may create misleading names. Reverse DNS therefore cannot be treated as proof of downstream identity.
Yet stale or opaque reverse DNS has economic consequences. Mail reputation systems may distrust a range. Customers may ask why names point to a prior provider. Security teams may send complaints to the wrong organisation. Geolocation and hosting-intelligence vendors may absorb old labels into risk systems. A public-sector customer may fail a procurement or security review because address naming does not match the declared service. A buyer may demand price concessions if reverse DNS control appears unclear. A lessee may discover that the lessor cannot update names quickly because the registered assignment trail is incomplete.
The answer is not to force meaningful names into every PTR record. Operational naming has security and privacy tradeoffs. The answer is to treat reverse DNS as one evidence surface. A public responsibility map can say whether reverse DNS is holder-controlled, downstream-delegated, customer-managed, stale, privacy-neutral or inconsistent with the registered role. That is more useful than trying to infer everything from the names themselves.
Reverse DNS also illustrates why suballocation visibility cannot be solved only in RDAP or WHOIS. The registry database may show a holder and a suballocation. The reverse tree may show a different operational story. The route may show a third. The abuse contact may show a fourth. A serious visibility regime reconciles these surfaces. It flags inconsistencies without assuming every inconsistency is misconduct. It asks whether the inconsistency matters for reachability, reputation, lawful escalation or market reliance.
For AFRINIC, a narrow improvement would be valuable: when a reverse delegation is tied to a registered assignment or suballocation, the public record should make the linkage legible. If a /24 has reverse DNS delegated because a downstream ISP assignment exists, outsiders should be able to see that the reverse delegation is not random. If reverse DNS remains under the holder while operational use is downstream, the record should say who handles naming changes and abuse escalation. This does not expose customers. It exposes responsibility for a service that already affects them.
Regional-use claims require humility
AFRINIC's region gives suballocation visibility a special political charge. The registry serves Africa and part of the Indian Ocean. Its exhaustion materials and policy manual frame resources around the AFRINIC service region. Its Soft Landing policy includes regional-use language for resources during the exhaustion period. Public analyses of the Cloud Innovation dispute described AFRINIC concerns about discrepancies between registered usage descriptions and actual countries of use, and about services originating within the region. Cloud Innovation and aligned critics contested that interpretation and argued that global network operation cannot be reduced to a simple geography rule.
For downstream visibility, the key point is that regional use is not always directly visible. Routing geography is not customer geography. A prefix originated from an AS in Europe may serve African users through a content or security platform. A server in Johannesburg may support customers worldwide. A Seychelles-registered holder may lease addresses to a network with customers in China, Nigeria and South Africa. A geolocation database may place a block in one country because of registry data, another because of routing, and a third because of user reports. Reverse DNS may use country codes for operational convenience. Latency may indicate where traffic enters the network, not where the economic service is delivered.
This does not mean regional-use evidence is useless. It means it should be expressed as confidence, not certainty. A responsibility record can distinguish declared service region, observed route origin, geolocation consensus, customer category, African dependency, out-of-region operation and unknown status. It can say whether a holder has self-attested that use supports connectivity to the AFRINIC region, whether the registry has validated a specific regional-use claim, whether evidence is routing-observed only, or whether the question is disputed. That is more honest than pretending a single country field settles the matter.
Humility is also economically efficient. If the registry treats weak inference as proof, holders will resist disclosure and litigate. If holders treat geography as unknowable, the registry and public stakeholders will assume evasion. A confidence-based record gives both sides a less explosive vocabulary. It allows AFRINIC to see patterns without demanding raw customer lists for every block. It allows holders to disclose regional relevance without exposing every customer. It allows markets to price uncertainty rather than invent a binary of compliant and non-compliant.
Regional-use inference also matters for development claims. Some argue that African-issued IPv4 should support African connectivity. Others argue that global markets and cross-region demand will matter more than guarding the residue of regional stock. The public ledger should not decide that debate through obscure fields. It should provide evidence: where downstream responsibility sits, what use is declared, what is observed, what is validated and what remains uncertain. Good evidence may inform policy. Bad inference becomes capital control by guesswork.
The standard should be cold and practical. Publish declared role and region at the right level of detail. Label observed signals. Preserve privacy where justified. Escalate only when evidence conflicts materially with policy or public reliance. In a region where the registry has already faced litigation over use and control, that humility is not weakness. It is risk management.
Intermediaries need responsibility tags
The modern downstream chain is rarely a straight line. A holder may work with a broker. The broker may introduce a reseller. The reseller may package addresses into VPS, mail, VPN or managed firewall products. A hosting provider may operate the origin AS. A customer may control the server. A third-party abuse vendor may triage complaints. A managed DNS provider may control reverse zones. The public record may show only the holder and perhaps the origin AS. When trouble arises, every layer can say that another layer has the operational facts.
Brokers and resellers are not inherently bad. They reduce search costs, match unused capacity with demand, provide technical onboarding, assemble documentation and help smaller networks obtain addresses they could not otherwise find. Managed-service providers also solve real problems. Many customers do not want to run routing, reverse DNS, abuse desks or RPKI. Outsourcing can improve quality. The visibility problem is not intermediation. It is unlabelled intermediation.
A responsibility tag is a narrow disclosure of role. It does not say the broker owns the block or that the reseller is the final customer. It can say that a commercial intermediary is involved but is not the operational contact. It can say that a reseller is responsible for customer vetting. It can say that a managed-service operator receives abuse first. It can say that the holder remains responsible for registry changes. It can say that a downstream ISP controls customer assignments. It can say that the customer identity is privacy-redacted but traceable through the operator. Tags tell outsiders where not to send the wrong request.
Such tags would reduce common failures. An upstream evaluating a route would know whether the origin AS is acting as a lessee, managed operator or holder network. A complainant would know whether the public abuse mailbox reaches the operator closest to the customer. A buyer would know whether undisclosed resellers may have customer continuity claims. A public buyer would know whether a contractor's address supply depends on a brokered chain. The registry would know whether a holder claiming privacy has at least mapped its responsibility chain.
Responsibility tags also help distinguish leases from suballocation visibility without making leases the main frame. Leasing is one channel through which opacity appears. The relevant question here is not the lease's private remedies or commercial price. It is whether the lease or other commercial delegation changes who is using the space and who can be contacted. A lease with clear responsibility tags may be less risky than an ordinary hosting assignment with no traceability. A sale with hidden downstream customers may be more problematic than a transparent time-limited delegation.
The same logic applies to customer privacy. A tag can say "privacy-protected end user, traceable by holder" without naming the end user. It can say "law-enforcement contact available through holder escalation" without publishing sensitive channels. It can say "reseller-controlled customer list" so counterparties know the holder may not have immediate logs. This is not a customer list. It is a map of who has which operational duty.
Intermediaries become economically safer when their roles are legible. If they resist all role disclosure, markets will assume the worst. If the registry demands full customer disclosure, legitimate intermediaries will resist. Tags offer a lower-cost alternative: visible responsibility, protected identity and priced uncertainty.
Public-sector dependency turns opacity into state-capacity risk
Suballocation opacity becomes more serious when public-sector systems depend on the address chain. A ministry may host citizen services with a local provider that uses addresses from a regional holder. A public hospital may buy managed security from a vendor whose firewall nodes sit inside a leased or suballocated block. A police cybercrime unit may need subscriber or customer information after an incident. A national education network may rely on downstream providers for campuses. A court may need to preserve evidence while a service remains online. In each case, the public body may not know that its continuity depends on an address chain several layers deep.
For ordinary commercial customers, opacity is a risk allocation problem. For public-sector customers, it can become a state-capacity problem. A tax portal that loses mail deliverability because reverse DNS is stale, a procurement platform that is blocked because neighbouring addresses are abusive, or an emergency-service vendor that cannot prove route authority is not merely facing an IT inconvenience. The cost is borne by citizens and public institutions that did not choose the hidden address structure.
Law-enforcement needs are also specific. Investigators often start with an IP address, timestamp and port. If the public record names only the holder, the investigator must travel the chain: holder, reseller, managed provider, customer, end user. NAT, CGNAT, VPS tenancy and short-term hosting make time critical. If the holder does not maintain traceability or if the reseller is not recorded, lawful requests may arrive too late or at the wrong party. Overbroad public disclosure is not the answer, but a structured escalation path is.
AFRINIC's crisis history raises the stakes because public authorities may already be looking at the registry as an institution. Reporting around the Mauritian receivership described a mandate to preserve operations and restore governance, while later coverage described continuing court pressure, failed election mechanics, board-restoration questions, lawsuits and disputes over the treatment of numbering resources. In such an environment, public-sector users need evidence that address continuity does not depend on unrecorded private arrangements that collapse under litigation or governance change.
A public-sector procurement standard could be simple. Providers using AFRINIC-administered IPv4 for public services should be able to show the registered holder, operating network, route-origin authority, reverse-DNS control, abuse and security contacts, downstream responsibility tags, privacy arrangements, lawful-request escalation and any dispute affecting the space. The public version need not reveal every customer. The buyer-facing file should be complete enough to support continuity and accountability.
Public-sector dependence therefore changes the privacy balance. The public does not need every customer name. It does need assurance that critical services have traceable address responsibility. A registry that helps create that assurance is not becoming a surveillance body. It is reducing public procurement risk in a market where address scarcity and institutional instability have made the address layer visible.
Recovery will be judged below the holder line
AFRINIC does not need a maximal transparency regime. It needs a visibility compact that states what downstream visibility is for: uniqueness, troubleshooting, abuse reachability, route-authority diligence, reverse-DNS consistency, lawful escalation, transaction confidence and continuity for customers that depend on scarce IPv4. It should also state what visibility is not for: publishing raw customer lists, judging every commercial arrangement, exposing sensitive users, or using registration fields as leverage in unrelated disputes.
The compact could begin with a few record types. Formal suballocations at or above the policy minimum should be publicly visible with downstream ISP identity, contacts, status, validation date and holder escalation. End-user assignments that require public operational accountability should identify the end user or a privacy-protected proxy with clear role labels. Smaller customer ranges below public-suballocation thresholds need not be named publicly, but holders should maintain traceability and publish responsibility tags where abuse, routing, reverse DNS or lawful requests make the role material.
Every record should carry evidence status: registry-validated, holder-attested, counterparty-confirmed, routing-observed, privacy-redacted but traceable, stale, disputed or court-constrained. These labels would stop a public field from pretending to be more certain than it is. They would also allow markets to reward better evidence. A block with current downstream responsibility should be cheaper to route, transfer, lease, finance and procure than a block with stale holder-only data.
The compact should include validation cycles. Contacts and role tags should expire unless refreshed. Material changes, such as a new downstream ISP, new origin AS, managed-service takeover, reverse-DNS delegation change or large customer migration, should trigger update obligations. Failure to update should first produce visible uncertainty and cure procedures, not immediate resource impairment. Severe remedies should be reserved for false statements, untraceable high-risk use, fraud, court orders or repeated refusal to maintain minimum responsibility.
There should also be a private evidence layer. Holders should keep records of customer assignments, authorisations, reseller contracts, abuse escalation, routing permissions and privacy justifications. AFRINIC should not need every document by default. It should be able to request proportionate evidence when a formal suballocation, public-sector dependency, transfer, dispute, major abuse pattern or reverse-DNS/RPKI conflict makes the downstream role material. The request should be specific, time-bound and narrower than an audit of all customers unless the evidence justifies more.
The compact should reward correction. If a holder voluntarily updates stale downstream responsibility, the default response should be record correction, not broad enforcement. Otherwise rational holders will hide. Fraud and intentional falsehood require different treatment, but ordinary correction should be encouraged. A registry recovering from record-corruption history must be firm against falsity and safe for truth.
AFRINIC's public recovery is often discussed through boards, budgets, receivership, court orders, ICANN intervention and institutional legitimacy. Those matters are real. But for many operators the practical test will sit below the holder line. Can a customer, upstream, buyer, public body, law-enforcement desk or abuse reporter understand who is responsible for a specific use of scarce IPv4 when that use is not by the registered holder? If not, governance recovery remains too abstract.
The registry can be legally preserved and still leave downstream responsibility opaque. It can elect a board and still expose only holder-level records. It can operate RDAP, WHOIS, reverse DNS, IRR and RPKI and still fail to connect those surfaces into a responsibility map. It can announce policies and still make markets guess whether a routed prefix is holder-operated, reseller-operated, leased, suballocated, assigned, privacy-protected or disputed. In a scarcity market, that guess is expensive.
AFRINIC's recent history gives it both reason and obligation to do better. The address-theft reporting shows the danger of weak record authority. The Cloud Innovation dispute shows the danger of opaque commercial delegation and broad registry discretion colliding. Receivership shows the need for continuity when corporate governance fails. Election discontinuity shows that member authority and institutional legitimacy can themselves become market facts. Continued litigation shows that public claims about leasing, commercialisation and court recognition can move confidence. Suballocation visibility will not solve all of that. It will narrow one important uncertainty that otherwise fuels the rest.
The correct institutional posture is modest. AFRINIC should not claim to know every customer. It should not become the economic regulator of every downstream service. It should not demand customer lists as a substitute for clear policy. It should not use visibility to punish unpopular business arrangements without due safeguards. But it should insist that registered holders can explain and evidence downstream responsibility at the level where outsiders rely on the address record. That is the difference between a ledger and a private fog.
The payoff is practical: narrower abuse reports, less crude filtering, cleaner reverse-DNS and RPKI changes, less broker-dependent diligence, stronger public procurement and protected customers with accountable traceability. Markets would price verified responsibility rather than rumours.
The compact would also discipline holders. A holder that rents, assigns, suballocates or delegates scarce IPv4 capacity should not be able to say only: the public ledger names me, therefore everyone else must trust me. The holder is the anchor, not the whole story. If it profits from downstream use, shields customers or uses intermediaries, it must know who can act. If it cannot, the market is right to discount the block.
AFRINIC is a test case because Africa's registry has lived through the full collision of scarcity, record integrity, commercial delegation, litigation and institutional recovery. The lesson is not that every downstream user should be public. It is that responsibility cannot remain private when the costs of its absence are public. A useful registry ledger does not expose the customer list. It exposes enough of the responsibility chain for strangers to act without joining the fight.