Summary

  • Brisanet's AS28126 record as retrieved on 10 November 2026 declares 3,000 IPv4 prefix announcements against 1,000 IPv6 ones, alongside 13 exchange and nine facility presences — a routing admission, not a count of addresses or customers.
  • The registry record that would convert that declaration into address holdings was not readable through the Registro.br or LACNIC autnum endpoints, and Brisanet's investor-relations portal still listed only second-quarter documents, so nothing in the public record ties the declared footprint to commercial scale.

What the declaration actually says

PeeringDB's public API answers a narrow question and answers it plainly. Asked for the network record of AS28126, it returns eight fields: an internal record id of 5911, an organisation id of 8242, the network name "Brisanet Servicos de Telecomunicacoes", the autonomous system number 28126, and then four counts — 3,000 IPv4 prefixes, 1,000 IPv6 prefixes, 13 internet-exchange presences and nine facility presences (PeeringDB network record).

Read that list for what it is. Every one of those four numbers is a declaration made by the network about itself. None of them is drawn from a registry allocation, an audited filing or an external route monitor. PeeringDB is a coordination database that network operators populate so that other operators can find them; its numbers are only as current as the last person who edited a profile.

That is not a criticism of Brisanet. It is a statement about what the instrument measures. A company that maintains its PeeringDB record accurately is doing its peers a favour. A reader who treats the resulting field list as a financial or asset disclosure is making an inference the instrument was never built to support.

The distinction matters commercially because these are the fields that appear first in any screen of a network operator's footprint. An analyst who wants to size a Brazilian fibre provider's address position, or to compare it against a peer, will find 3,000 sitting in a database column with no unit attached to it. In ten seconds that number can become a spreadsheet input. In ten seconds more it can become a comparative claim that the underlying data cannot carry.

A prefix is not an address

The word doing the damage here is "prefix". A prefix is a routing object: a block of address space announced into the global routing table, written in classless notation, with a length that states how much space it covers. The announced length is the whole story. One prefix of length /24 contains 256 addresses. One prefix of length /20 contains 4,096. A single aggregation can carry either, and the same count of prefixes — 3,000 — can describe wildly different quantities of address space depending on how the network happens to have structured its announcements.

So the honest reading of "3,000 IPv4 prefixes" is: Brisanet tells its peers that it originates three thousand distinct IPv4 routes. That is a statement about routing-table structure. It tells you something real about operational complexity — every one of those announcements needs a filter, a policy, a monitoring rule and a place in somebody else's prefix list.

It tells you almost nothing about how many IPv4 addresses the company controls, because block size is exactly the variable the count discards.

There is a second reason the count cannot stand in for holdings. A network's announced prefixes need not be co-extensive with its registry allocations. Operators announce space they hold, but also space held by downstream customers, by acquired networks still running their own registrations, or by partners under a routing agreement. The reverse also happens: allocated space may sit unannounced, held in reserve for future deployment or for transfer.

A prefix count and an allocation register are two different ledgers, maintained by two different parties, for two different purposes, and they are not reconciled by anyone.

This is the gap that a due-diligence reader needs to hold open. If you want to know what a company owns, you read the registry. If you want to know what it announces, you read the routing record. If you want to know what it owns and announces, you need both — and if one of them is unreadable, you have half a balance sheet.

The three-to-one tilt

Within the declaration itself, one ratio is worth extracting, and it should be extracted with its status made explicit. The declared IPv4 prefix count is three times the declared IPv6 count: 3,000 against 1,000, computed directly from the verbatim fields in the same record (PeeringDB network record).

What does a three-to-one tilt mean? It is consistent with a network that still does considerable IPv4 work alongside a mature but less fragmented IPv6 deployment. It is also consistent with a network whose IPv6 addressing has been aggregated more aggressively, which would be good engineering and would produce exactly this shape of count without any difference in deployment depth. The field cannot distinguish those explanations, because it counts announcements and not addresses, and because a well-aggregated IPv6 plan can cover a large estate with a small number of prefixes.

That ambiguity is not a reason to ignore the ratio. It is a reason to state it precisely: Brisanet's declaration shows an IPv4 announcement structure three times as granular as its IPv6 one. Anyone who wants to argue from that to a conclusion about dual-stack maturity, address pressure or future transfer demand is making an argument the field can support only weakly, and should say so.

For a company in Brazil, this is not a neutral framing. Brazil has been one of the more aggressive IPv6 adopters among large emerging markets, and the country's exchange fabric — the IX.br structure that concentrates domestic traffic — is where that adoption gets measured. A large Brazilian access provider with a three-to-one IPv4 announcement tilt is therefore not an outlier to be explained away; it is a normal transitional shape. The interesting question is not whether the tilt exists but whether it narrows, and on what timetable. That is a watchable indicator, and it needs a dated baseline to be watchable at all.

The baseline, as of 10 November 2026, is 3,000 and 1,000.

Thirteen exchanges, eighteen connections

PeeringDB's connection endpoint tells a second story, and it must be told with the right provenance. As summarised from that endpoint, the network maintains 18 exchange connections across a mix of IX.br (PTT.br) locations — São Paulo, Rio de Janeiro and Fortaleza among them — and DE-CIX locations including Frankfurt, New York, Rio de Janeiro and São Paulo, with connection speeds reaching 100,000 Mbps at major hubs (PeeringDB connection list).

Two qualifications belong beside those numbers rather than after them. First, this is a provider-written summary of the endpoint rather than a verbatim field-by-field JSON excerpt, so the totals and speeds carry the coordination database's own declaration status. Second, 18 connections across 13 exchange presences is an exchange-presence pattern, not a count of participants. A network with multiple ports at a busy exchange appears more than once.

Reading the two figures as a member count or a customer count is the natural error, and it is an error of a different kind from the prefix confusion — same instrument, same self-declaration, different column.

What the pattern does say is more useful than what it does not. A regional access provider that connects at both the domestic exchange fabric and at European and North American exchange points is doing something specific: it is trying to hold its own international traffic in its own hands rather than buying all of it as transit. That is a capital decision — ports, cross-connects, routers, engineering time — and it appears on the cost side of the accounts long before it appears on the revenue side.

It is also a decision with a failure path worth naming. Exchange presence converts to money only when traffic volumes through those ports justify the fixed costs, and when the remote content that a Brazilian access network most wants — the large content networks and caches — is reachable at those exchanges on commercially sane terms. A port at a Frankfurt exchange is not the same asset as traffic at a Frankfurt exchange.

The declared connection tells you the wire exists. It does not tell you the load, the peering ratio, or whether the traffic is settlement-free. Those are operational facts that no coordination database carries, and no inference from port speed should be allowed to substitute for them.

The disclosure that was not there

Here the story becomes about timing rather than fields, and timing is what makes this article possible today rather than any day.

Brisanet's investor-relations portal, retrieved on 10 November 2026, listed documents for the second quarter of 2026 and nothing later: a results release, financial statements, a presentation, conference materials and an Excel workbook, all labelled 2T26 (Brisanet investor relations). The portal also indicated, according to the same retrieval, that third-quarter results were scheduled for disclosure on 10 November 2026 with a conference call on 11 November.

Put those two facts next to the network declaration and the shape of the public record becomes clear. On the morning of the day Brisanet was due to tell the market how the third quarter went, the only machine-readable measurement of its network was the eight-field declaration it maintains for its peers. The financial perimeter had not yet opened. The network perimeter, such as it is, never closes — but it only ever says what Brisanet chooses to put in it.

There is a discipline in that ordering that deserves to be named rather than complained about. Disclosure calendars are not administrative decoration; they define the window in which a company's numbers are attributable, comparable and dated. A reader who wants to argue about Brisanet's capital intensity has to wait for the company to speak, because nothing else in the public record substitutes for it. The announcement count, the exchange count and the facility count are not early indicators of the financials.

They are a different category of fact entirely, published to a different audience for a different purpose, and treating them as a preview of earnings is a category error dressed up as diligence.

The second half of the timing story is less comfortable. Two registry endpoints that should have converted the declaration into something harder — the Registro.br and LACNIC autnum records for AS28126 — returned no registration data when queried for this review. That is a retrieval failure and must be reported as one. It is not evidence that Brisanet's allocation record is absent, thin or unusual. What it does mean is that no statement about the size, vintage or structure of Brisanet's address holdings can be made here, and no attempt to build a per-customer address ratio should be read into any figure in this article.

There is no denominator in the record, and inventing one would be the exact failure this piece is describing.

What the registry does confirm

One registry fact is available and it is worth its own paragraph precisely because it is so modest. LACNIC's public member directory lists BRISANET SERVICOS DE TELECOMUNICACOES S.A as a member with registry country Brazil (LACNIC member directory). That is the full extent of what the institutional record establishes: membership, jurisdiction of record, a Brazilian presence.

It does not establish ownership, leadership, corporate structure, licensed service areas or commercial scale. Those are different registers maintained by different authorities — securities filings, company registries, telecoms regulators — and none of them was read in this review. The directory record is an anchor, not a dossier, and a reader who treats a membership listing as a corporate profile is doing the same thing as the analyst who treats a prefix count as an address ledger: reaching for a number that answers a neighbouring question.

This is the argument of the whole piece, compressed. Modern infrastructure disclosure is dense in declarations and thin in conversions. PeeringDB will tell you what a network announces. LACNIC will tell you that a company is a member in a country. An investor-relations portal will tell you which quarters it has published. None of these will tell you what the other two mean, and the work of a serious reader is almost entirely the work of refusing to let one register answer another register's question.

Why this matters for a Brazilian fibre operator

The company at the centre of this is a Brazilian access provider whose identity in the directory is tied to LACNIC membership in Brazil (Brisanet directory entry Only for Strategic Circle). Brazilian fibre operators sit in a market where the physical build is expensive, the subscriber acquisition is competitive, and the address position is an operating input rather than a trading asset. For a network like that, IPv4 holdings matter for practical reasons — customer premises equipment, address pool availability for new subscribers, the cost of working around scarcity — and not primarily because of what the space might fetch in a transfer market.

That makes the missing registry record more than a technical annoyance. It is the difference between knowing whether a growing access provider has the address cushion to add subscribers without expensive workarounds, and guessing. And it is precisely the kind of question that gets answered badly when an analyst substitutes a prefix count for an allocation, because prefix counts move with routing policy — a re-aggregation, a new customer announcement, a withdrawn route — while allocations move only with registry transactions.

So the practical instruction for anyone modelling this company is narrow and worth stating once. Treat the declaration as an operations signal: three thousand IPv4 announcements is a lot of routing surface to maintain, and thirteen exchanges is a real peering commitment. Treat the allocation as unknown until a readable registry record exists. And treat any address-per-subscriber figure circulating in public without a dated allocation source as an artefact of the confusion this article describes, not as a data point.

What would change the picture

Three observable conditions would move this from a note about measurement to a note about a measured company. First, a readable Registro.br or LACNIC autnum record for AS28126 would convert the declaration into holdings and make the address question answerable. Second, the publication of Brisanet's third-quarter financials — the release, statements and presentation the portal's calendar pointed to — would supply revenue, capital expenditure and subscriber figures, and with them a denominator.

Third, a future snapshot of the same PeeringDB fields would reveal whether the IPv4-to-IPv6 announcement tilt narrows, which is a genuine engineering signal in a market where dual-stack depth is a competitive variable.

None of those has happened in the record used here. The declaration is dated 10 November 2026 by retrieval, and the ratio, the exchange count and the facility count should be read as of that date and no other. When the next set of facts arrives, the test is simple: does any of them let a reader compute something the declaration cannot? If yes, the picture changes. If not, the instrument is still the instrument.

The instrument is the story

There is a habit in infrastructure coverage of treating a database field as a floor plan. It is comfortable, because a field is a number and a number feels like knowledge. But the most useful thing a reader can carry away from Brisanet's public record on this date is a discipline rather than a figure: know which register you are reading, know who populated it, and know what question it was built to answer.

PeeringDB answered a coordination question. LACNIC answered a membership question. Brisanet's investor-relations portal answered a publishing-calendar question.

The address question — how much space this company holds, how old it is, whether it is enough — went unanswered, and the honest response to an unanswered question is to leave it unanswered in public until a document answers it. Three thousand prefixes is what Brisanet declares. It is not what Brisanet owns, and the difference is the whole article.