Summary

  • The Bhutan Internet Exchange appears in three independent public layers — a PeeringDB exchange record, two APNIC organisation objects and a Hurricane Electric country row for AS7615 — and those layers agree on the name, the city and the exchange's own autonomous system number.
  • Read closely, the record describes a single flat Ethernet LAN called TTPL-LAN at the Thimphu Techpark, with a maximum transmission unit of 1500 bytes, 802.1Q tagging reported as not enabled, a route-server autonomous system number of zero, and service-level and terms fields that both read Not Disclosed.

The first thing to understand about the Bhutan Internet Exchange is that its public identity is thin, and the thinness is structural rather than accidental. PeeringDB holds an exchange record with the identifier 2355, short name btIX, long name Bhutan Internet Exchange, in Thimphu, country BT, region Asia Pacific, on Ethernet media (PeeringDB IX record for Bhutan). That is the whole of the geography. There is no second city, no second facility, no alternate site listed. For a country whose international connectivity has historically run through India, a single domestic exchange point in the capital is not a detail; it is the entire domestic switching layer as far as this record is concerned.

The record's child object is where the engineering actually lives. The exchange LAN is named TTPL-LAN. Its maximum transmission unit is reported as 1500 bytes. Its 802.1Q support field reads false. Its route-server autonomous system number reads 0. It was created on 22 September 2018 at 17:01:27 UTC, the same minute as the parent exchange record, and it was last updated on 30 June 2026 at 01:34:08 UTC. Its status reads ok.

Those five fields, taken together, describe an architecture rather than a wish. An MTU of 1500 is ordinary Ethernet: nothing here suggests jumbo frames, nothing suggests a specialist fabric tuned for large flows. The absence of 802.1Q support means the LAN is presented as a single flat broadcast domain in the record's own terms, so an operator reading it should not expect per-member VLAN handoff as a documented feature.

A route-server autonomous system number of zero is the most consequential value in the whole dataset, and it deserves to be stated plainly: the field that would name an exchange-operated route server is empty of any usable number. Whatever route-server function btIX may run, the public record does not name it as a numbered service.

That single zero changes what membership means. At an exchange with a route server, a member configures one BGP session to the exchange and receives the collective routing table; the exchange becomes a technical party to every member's routing decisions, and the exchange's own operational competence becomes part of every member's blast radius. At an exchange without one, each pair of members that wants to exchange routes must negotiate and configure a bilateral session.

Bilateral peering is more work per pair but it keeps control at the edge: no shared routing brain, no single process whose failure degrades everyone, and no exchange operator holding the policy pen over what prefixes get announced to whom. The zero in that field is therefore not a gap in the record. It is a statement about where control sits.

The facility mapping confirms the physical picture. PeeringDB attaches the exchange to one facility, identifier 5806, named Thimphu Techpark, operated by an organisation recorded as Bhutan Data Centre Services, with a CLLI code of TTPL and coordinates of 27.427781 north and 89.650988 east (PeeringDB IX record for Bhutan). The postal details run Thimphu Techpark, Wangchuktaba, Thimphu, state Thimphu, postal code 11001. The facility was created on 22 September 2018 at 16:43:21 UTC — twenty minutes before the exchange record — and last updated on 26 September 2025 at 22:51:32 UTC. Its status reads ok.

The facility's own counters provide the sharpest single contrast in the dataset. It reports two networks, one exchange and zero carriers. Two networks at a national exchange point, in the exchange's own facility record, is a number small enough to hold in mind without help. It is also the number that makes every downstream question about competitive effect easy to frame and hard to answer: with two networks listed at the site, the marginal value of the exchange depends entirely on which two, whether they would otherwise interconnect, and what the price of interconnection is.

The record answers the first question not at all, the second not at all, and the third with the phrase Not Disclosed.

The naming problem, which is really a detection problem

The most instructive artefact in this dataset is not a field about Bhutan at all. It is the difference between two queries against the same API. A query filtered by the literal string in the name parameter — bhutan internet exchange — returned an empty data array and empty metadata (PeeringDB name-filter response). A query filtered by country BT returned a record whose long name is Bhutan Internet Exchange and whose short name is btIX (PeeringDB IX record for Bhutan).

Both responses are correct. The record is named btIX, and its long name is a separate field that the name filter evidently did not match on the form of the string supplied. Anyone who searched the registry for the exchange's full English name, which is how a researcher, a journalist or a foreign operator would search, received a clean negative. Anyone who searched by country found it immediately.

In risk terms this matters more than it looks. A registry's value to the public is a detection function: it is how an outsider establishes that an exchange exists, who is on it and what it is for. When a name search fails against a record that exists, the registry does not merely have an indexing quirk; it has produced a false negative for exactly the audience that depends on it. The failure mode is asymmetric. A person inside the Bhutanese network community knows the local short name, because that is what people call the thing. A person outside it does not.

The registry therefore works for insiders and fails for outsiders, which is the opposite of what a disclosure register is for.

The exchange LAN record contains a related signal. Its IX-F member-list URL visibility field reads Private, while its IX-F import enabled field reads true. IX-F is the standardised interchange format through which exchanges publish machine-readable member lists so that other registries and tools can mirror them. A private visibility setting on the member-list URL, with import enabled, describes an exchange that is willing to ingest from the interchange format but has chosen not to publish its own member list through it. The member list is not merely unpublished; it is marked as deliberately withheld.

That distinction is worth holding onto, because it separates two very different explanations for thin public data. One explanation is neglect: nobody has gotten around to it. The other is policy: the operator has decided that the list is not public. The first is a maintenance problem with an obvious remedy and no defensible rationale. The second is a governance choice, and governance choices can be interrogated. Private visibility is a setting someone selected. It means the exchange, or whoever maintains its record, has taken a position on member-list disclosure and that position is: not through this channel.

There is a practical consequence. An outsider who wants to know which networks peer at btIX has one registry-level route left, which is to read the exchange's participant records indirectly through each network's own PeeringDB entry, or through routing data. Both routes are weaker than a member list, because both describe what networks say about themselves rather than what the exchange confirms about its own membership.

What the registry layer can and cannot confirm

PeeringDB is not a regulator and does not claim to be. Its records are crowd-maintained and operator-editable, which is precisely what makes them useful for mapping and precisely what makes them insufficient for verification. A record with a status of ok means the record is intact, not that the facility is powered or the LAN is passing frames. An exchange can be listed, current and status-ok while carrying traffic that no one outside Thimphu has ever measured.

This is why the APNIC layer matters. The registry record is not self-reported in the same way; it is a formal allocation object with a maintainer and an audit trail. APNIC's Whois service returns two organisation objects under the name Bhutan Internet Exchange (APNIC Whois query for the exchange). The first, ORG-BIE1-AP, carries the country BT and an address block reading Bhutan Internet Exchange, Thimphu Techpark, Post Box 633, Wanghcuktaba, Babesa. The second, ORG-BIE2-AP, is typed as a Local Internet Registry, carries the address Thimphu Techpark, Wangchuktaba, Post Box 633, is maintained by APNIC-HM, references that same maintainer, and carries a last-modified timestamp of 5 September 2023 at 02:17:38 UTC with the source recorded as APNIC.

Two organisation objects for one exchange is not unusual in itself; registry objects accumulate as addresses are requested and contacts change, and the older object is often left in place. What matters for accountability is which object is authoritative and what the typing means. The LIR type is the significant field. A Local Internet Registry is an organisation that receives address space from the regional registry and sub-allocates it to its own customers.

An exchange typed as an LIR is therefore not merely a switch in a building; it is a distribution point for number resources, with the obligations that follow from holding them — records, contact objects, maintenance of assignments.

The maintainer field sharpens this. Both objects are maintained by APNIC-HM, which is the regional registry's own house maintainer for higher-level objects. An exchange that holds registry objects under the registry's own maintainer is bound into the registry's administrative structure rather than operating as a fully independent registry member. That is a common arrangement for small organisations and it is not a criticism.

It does mean that the paper trail for the exchange's number resources terminates inside APNIC's own administration, which is exactly where an investigator would expect to find it and exactly where an outside party cannot look further.

The last-modified date on the second object is 5 September 2023. Objects are modified when something changes; a static date is evidence of administrative stability rather than of operational activity. Read alongside the PeeringDB timestamps, a pattern emerges that is worth naming. The parent exchange record was last updated on 22 January 2020. The APNIC object was last modified in September 2023. The exchange LAN record was updated on 30 June 2026, and the facility on 26 September 2025.

Four objects, four different vintages, and the freshest one is the technical child rather than the policy parent. Whoever maintains this record is updating the LAN and the facility while leaving the exchange's own description — the layer that would carry terms, service levels and policy contacts — frozen since the first weeks of 2020. That is a maintenance pattern, and patterns are evidence. It says the technical mapping is alive and the commercial description is not.

Four numbers and the discipline not to over-read them

Routing data adds a third layer, from a different direction entirely. Hurricane Electric's BGP toolkit publishes a country table for Bhutan. Within it is a row reading, exactly: AS7615 Bhutan Internet Exchange 2 3 2 3 (Hurricane Electric country view for Bhutan). The column header above that row names, in order, the ASN, the name, IPv4 adjacencies, IPv4 routes, IPv6 adjacencies and IPv6 routes.

The row establishes something the other two layers do not: that the exchange holds its own autonomous system number, AS7615, and that this number is visible in a global routing-data aggregation. The exchange is not only a registry entry and a facility tenant; it is an addressable entity in the routing system, with its own AS number carried in a table that network engineers consult.

The four single digits are where discipline is required. Two, three, two, three. It is tempting to translate that row into a sentence like "the exchange has two peers and three routes", and that sentence would be wrong in a way that matters. The excerpt preserves the header and the row but does not bind each value unambiguously to a column, and a four-value row rendered from a wide table can lose its alignment. The honest reading is that the row carries four small values against columns naming adjacencies and route counts, and that all four are in the single digits.

What can be said without overreach is that a single-digit adjacency count for a national exchange's own autonomous system is small. A route server or a large exchange typically shows adjacency counts in the dozens or hundreds. A count of that magnitude is consistent with a small number of member networks, which is consistent with the facility record's two networks, which is consistent with two networks being the whole of the domestic interconnection story as far as these records go. Three independent layers produce small numbers that point the same way, and each layer is weak on its own but the agreement is informative.

What cannot be said is that any particular Bhutanese network is or is not present. The fact that a row for AS7615 exists says nothing about which other autonomous systems it exchanges routes with, and the country table does not enumerate the pairings. A claim that the incumbent operator peers at btIX, or that a mobile network does not, would require a member list or session data, and neither is in hand.

The terms field is the accountability field

Of all the fields in the exchange record, the two that read Not Disclosed are the ones a board should notice. Service level and terms. Both are blank in the disclosure sense.

An exchange's commercial terms determine who can connect and on what basis. A flat annual port fee, a per-megabit charge, a settlement-free model, a tiered structure by port speed — each produces a different market. A settlement-free exchange lowers the marginal cost of domestic interconnection to the price of a cross-connect, which favours new entrants and small networks. A paid exchange raises it, which favours whoever already has volume and can absorb the fee. The choice between those models is a governance decision with distributional consequences, and it is invisible in a record that reads Not Disclosed.

For a buyer, the consequences are practical. A network considering a port cannot model the cost of domestic peering from the public record, because the price is not there. It cannot compare btIX against carrying that traffic internationally, because the comparison requires a number. It cannot judge whether the exchange's service level is adequate for the traffic it would move, because the service level is also not there.

The result is that the decision to join is made on the basis of relationships and conversations rather than published terms — which is normal in small markets and also exactly the condition under which insiders have an advantage.

The IX-F visibility setting connects directly to this. A prospective member trying to assess whether joining is worth the effort would want to know who is already there. The exchange has marked that list private. The combination — private member list plus undisclosed terms — means an outsider evaluating btIX can confirm that it exists and roughly where, and cannot confirm who they would be peering with or what it would cost. That is a specific and describable disclosure posture, and the posture is conservative.

There is a defensible reason for it. Member lists and prices can be commercially sensitive in a market with two or three participants, because publication reveals relative traffic volumes and negotiating positions. An exchange that publishes its member list in a two-network market publishes its members' competitive situation. A small operator might reasonably conclude that discretion serves its members better than transparency serves the public. That argument is coherent. It is also a choice that trades external accountability for internal flexibility, and it should be described as such rather than as an accident.

The multicast bit, and why small fields carry large implications

The record enables unicast and IPv6 and disables multicast. Of these, the IPv6 setting is the one that will matter most over time and the multicast setting is the one that reveals most about intent.

IPv6 support being enabled means the exchange's record asserts that it can carry IPv6 traffic. For a country with a small number of networks, an exchange that carries IPv6 is the cheapest possible path to domestic IPv6 interconnection: without it, two Bhutanese networks that both want IPv6 must either tunnel, or route domestically through an international transit provider, or not interconnect at all. An exchange with IPv6 enabled in its record lowers the cost of that path to the price of a port.

Multicast being disabled is a more specific statement. Multicast at an exchange is how content distribution networks and internet television operators deliver a single stream to many access networks without replicating it per member. Disabling it means the exchange's record does not claim that capability. For a market where video distribution matters — and in every market it does — the absence of multicast is a limit on what the exchange can be used for. It pushes that traffic to unicast, and unicast pushes it back toward the international path or toward private interconnection.

This is the point at which the record stops being a directory entry and becomes a description of a bottleneck. A domestic exchange that carries unicast IPv4 and IPv6, on one flat LAN, at 1500 bytes, with no named route server and no multicast, is a functioning interconnection point for general traffic. It is not a distribution fabric. The distinction determines which of a country's traffic problems the exchange can solve and which it cannot, and it is visible entirely in fields that someone chose to set.

Who is accountable, and to what

Here the public record runs out, and it runs out in a way that is specific enough to describe rather than simply lament. Across the four records examined for this article, none identifies the exchange's legal form, its owners, its governing body, its membership rules or the process by which an admission dispute would be resolved (APNIC Whois query for the exchange).

That is a bounded statement and its bounds should be stated: four public records, queried on one day, do not contain those fields. Earlier coverage of this exchange in BTW's own directory recorded a founding date, a reported launch, a hosted root-server instance and a participant list with autonomous system numbers (BTW directory entry for the Bhutan Internet Exchange Only for Strategic Circle). Those facts are not re-reported here and are not contradicted by anything in these four records; they sit at a layer this article did not interrogate.

What this article interrogated is the layer that an outside party can reach without a relationship: the registry entry, the address-registration object, and the routing table. In that layer, the exchange is legible as an institution in exactly two respects — it holds an AS number and it holds a Local Internet Registry object. Both are real. Both are administratively consequential. Neither tells you who decides.

For control purposes, that is the finding. The public record describes an exchange's plumbing in unusual mechanical detail — LAN name, MTU, tagging, route-server field, facility coordinates, creation and update timestamps to the second — and describes its governance not at all. A regulator asking whether the domestic interconnection point is operating in the public interest would have to ask the operator. A network asking whether to join would have to ask the operator. A researcher asking whether domestic traffic stays domestic would have to ask the operator.

In each case the registry confirms the existence of the thing being asked about and supplies none of the answer.

There is a design question buried here that is worth naming for anyone who runs a disclosure regime. The fields that got filled in are the fields a network engineer needs to configure a session: the LAN name, the MTU, whether tagging works, whether there is a route server. The fields that did not get filled in are the fields an outsider needs to hold the institution to account: terms, service level, member list, legal identity. Registries get populated by the people who operate infrastructure, and operators populate what they need. The accountability fields fill last, if at all.

What would change this classification

A classification is only useful if it can be updated, and this one can be, by specific and observable changes.

If the exchange LAN record began naming a route-server autonomous system number other than zero, that would be a structural change in the exchange's architecture, not a cosmetic one. It would mean an exchange-operated routing function exists, and it would move a meaningful share of routing policy control from bilateral pairs to the exchange itself.

If the IX-F member-list visibility field moved from Private to Public, the participant question would become answerable from machine-readable data instead of inference. That single field change would convert the weakest part of this article's evidence base into the strongest, and it would cost the operator nothing but a disclosure decision.

If the service-level and terms fields stopped reading Not Disclosed, a buyer could model cost and a regulator could assess whether the pricing structure favours incumbents. If the parent exchange record's update timestamp moved past January 2020 — it has not, in the record captured here — the commercial description would be shown to be maintained rather than abandoned.

If a national regulatory filing described the exchange's ownership, its admission rules or its dispute process, the governance layer would exist in a citable document rather than in the gap between registry fields. Until then, the honest summary is the one the fields themselves support: btIX is a real, registered, addressable exchange in Thimphu, on one flat Ethernet LAN, without a named route server, without published terms, and without a public member list. The plumbing is documented to the second. The accountability is documented not at all, and that asymmetry is the story.