Resumo

  • O Bhutan Internet Exchange aparece em três camadas públicas independentes — um registro de ponto de troca no PeeringDB, dois objetos de organização no APNIC e uma linha de país do Hurricane Electric para o AS7615 — e as três coincidem no nome, na cidade e no número de sistema autônomo do próprio ponto de troca.
  • Lido de perto, o registro descreve uma única LAN Ethernet plana chamada TTPL-LAN no Thimphu Techpark, com unidade máxima de transmissão de 1500 bytes, suporte a 802.1Q declarado inativo, número de sistema autônomo de servidor de rotas igual a zero e campos de nível de serviço e condições que dizem Not Disclosed.

A primeira coisa a entender sobre o Bhutan Internet Exchange é que sua identidade pública é fina, e essa finura é estrutural, não acidental. O PeeringDB mantém um registro de ponto de troca com o identificador 2355, nome curto btIX, nome longo Bhutan Internet Exchange, em Thimbu, país BT, região Ásia-Pacífico, sobre Ethernet (registro do ponto de troca butanês no PeeringDB). A geografia inteira cabe aí. Não há segunda cidade, segunda instalação nem site alternativo. Para um país cuja conectividade internacional passou historicamente pela Índia, um único ponto de troca doméstico na capital não é detalhe: é toda a camada de comutação nacional, ao menos tal como este registro a descreve.

O objeto filho é onde a engenharia de fato mora. A LAN do ponto de troca se chama TTPL-LAN. Sua unidade máxima de transmissão está registrada em 1500 bytes. Seu campo de suporte a 802.1Q diz falso. Seu número de sistema autônomo de servidor de rotas diz 0. Foi criada em 22 de setembro de 2018 às 17:01:27 UTC, no mesmo minuto do registro pai, e sua última atualização é de 30 de junho de 2026 às 01:34:08 UTC. Seu status diz ok.

Esses cinco campos, juntos, descrevem uma arquitetura e não um desejo. Uma MTU de 1500 é Ethernet comum: nada aqui sugere jumbo frames, nada sugere uma malha ajustada para grandes fluxos. A ausência de suporte a 802.1Q significa que a LAN é apresentada, nos termos do próprio registro, como um único domínio de difusão plano; quem lê a ficha para dimensionar portas não deve esperar entrega por VLAN como função documentada.

E o número de sistema autônomo de servidor de rotas em zero é o valor de maior consequência de todo o conjunto, e merece ser dito sem rodeios: o campo que nomearia um servidor de rotas operado pelo ponto de troca não contém número utilizável.

Esse zero muda o significado de ser membro. Num ponto de troca com servidor de rotas, um membro configura uma única sessão BGP para o ponto de troca e recebe a tabela coletiva; o ponto de troca se torna parte técnica das decisões de roteamento de cada membro, e sua competência operacional entra no raio de impacto de todos. Sem servidor de rotas, cada par de membros que queira trocar rotas precisa negociar e configurar uma sessão bilateral.

O peering bilateral custa mais trabalho por par, mas mantém o controle na borda: sem cérebro de roteamento compartilhado, sem um processo único cuja queda degrada todo mundo e sem um operador do ponto de troca segurando a caneta da política sobre quais prefixos são anunciados a quem. O zero nesse campo não é lacuna do registro. É uma afirmação sobre onde está o controle.

A correspondência com a instalação confirma o quadro físico. O PeeringDB vincula o ponto de troca a uma única instalação, identificador 5806, chamada Thimphu Techpark, operada por uma organização registrada como Bhutan Data Centre Services, com código CLLI TTPL e coordenadas 27,427781 norte e 89,650988 leste (registro do ponto de troca butanês no PeeringDB). O endereço diz Thimphu Techpark, Wangchuktaba, cidade Thimbu, estado Thimbu, CEP 11001. A instalação foi criada em 22 de setembro de 2018 às 16:43:21 UTC — vinte minutos antes do registro do ponto de troca — e atualizada pela última vez em 26 de setembro de 2025 às 22:51:32 UTC. Seu status diz ok.

Os contadores dessa instalação oferecem o contraste mais nítido do conjunto. Ela registra duas redes, um ponto de troca e zero operadoras de transporte. Duas redes num ponto de troca nacional, segundo a ficha do próprio ponto de troca, é um número pequeno o bastante para ser guardado sem ajuda. É também o número que torna toda pergunta posterior sobre efeito competitivo fácil de formular e difícil de responder: com duas redes declaradas no site, o valor marginal do ponto de troca depende inteiramente de quais sejam, de se elas se interconectariam de outro modo e de qual é o preço da interconexão.

O registro não responde nada à primeira pergunta, nada à segunda e responde à terceira com a expressão Not Disclosed.

O problema do nome, que na verdade é um problema de detecção

A peça mais instrutiva deste conjunto não trata do Butão. É a diferença entre duas consultas à mesma API. Uma consulta filtrada pela string literal bhutan internet exchange devolveu um arranjo de dados vazio e metadados vazios (resposta do filtro por nome no PeeringDB). Uma consulta filtrada por país BT devolveu um registro cujo nome longo é Bhutan Internet Exchange e cujo nome curto é btIX (registro do ponto de troca butanês no PeeringDB).

As duas respostas estão corretas. O registro se chama btIX, e o nome longo é um campo separado que o filtro por nome evidentemente não consultou na forma da string fornecida. Quem procurasse o ponto de troca pelo nome inglês completo — ou seja, um pesquisador, um jornalista ou um operador estrangeiro — recebeu uma negativa limpa. Quem procurasse por país o encontrou imediatamente.

Em termos de risco isso pesa mais do que parece. O valor de um registro para o público está na função de detecção: é assim que um terceiro estabelece que um ponto de troca existe, quem está nele e para que serve. Quando uma busca por nome falha contra um registro que existe, o registro não sofre uma esquisitice de indexação: ele produziu um falso negativo para exatamente o público que depende dele. O modo de falha é assimétrico. Alguém de dentro da comunidade de rede butanesa conhece o nome curto local, porque é assim que se chama a coisa. Alguém de fora não.

O registro, portanto, funciona para os iniciados e falha para os demais, que é o oposto do propósito de um registro de divulgação.

A ficha da LAN tem um sinal vizinho. Seu campo de visibilidade da URL da lista de membros em formato IX-F diz Private, enquanto o campo de importação IX-F diz true. O IX-F é o formato de intercâmbio padronizado pelo qual pontos de troca publicam listas de membros legíveis por máquina, para que outros registros e ferramentas as espelhem. Visibilidade privada sobre a URL da lista, com a importação ativa, descreve um ponto de troca disposto a ingerir o formato mas que escolheu não publicar a própria lista por esse canal. A lista de membros não está apenas não publicada: está marcada como deliberadamente retida.

Essa distinção vale guardar, porque separa duas explicações muito diferentes para um registro público fino. A primeira é negligência: ninguém cuidou. A segunda é política: o operador decidiu que a lista não é pública. A primeira é problema de manutenção, com remédio óbvio e nenhuma justificativa defensável. A segunda é escolha de governança, e escolhas de governança podem ser interrogadas. Visibilidade privada é um ajuste que alguém selecionou. Significa que o ponto de troca, ou quem mantém sua ficha, tomou posição sobre a divulgação da lista de membros, e essa posição é: não por este canal.

A consequência prática é direta. Um terceiro que queira saber quais redes estão presentes no btIX tem uma única via no nível do registro: ler as fichas de participante de cada rede no PeeringDB, ou passar pelos dados de roteamento. As duas vias são mais fracas que uma lista de membros, porque descrevem o que as redes dizem de si mesmas, e não o que o ponto de troca confirma da própria composição.

O que a camada de registro confirma e o que não pode confirmar

O PeeringDB não é regulador e não pretende ser. Suas fichas são mantidas pela comunidade e editadas pelos operadores, o que as torna valiosas para mapeamento e insuficientes para verificação. Um status ok significa que a ficha está intacta, não que a instalação tem energia ou que a LAN está passando quadros. Um ponto de troca pode estar listado, atualizado e com status ok enquanto carrega tráfego que ninguém fora de Thimbu jamais mediu.

É por isso que a camada do APNIC importa. O registro regional não é autodeclarado do mesmo modo; é um objeto formal de alocação, com mantenedor e trilha de auditoria. O serviço Whois do APNIC devolve dois objetos de organização sob o nome Bhutan Internet Exchange (consulta Whois do APNIC sobre o ponto de troca). O primeiro, ORG-BIE1-AP, traz o país BT e um endereço que diz Bhutan Internet Exchange, Thimphu Techpark, Post Box 633, Wanghcuktaba, Babesa. O segundo, ORG-BIE2-AP, está tipado como Local Internet Registry, traz o endereço Thimphu Techpark, Wangchuktaba, Post Box 633, é mantido pelo APNIC-HM, referencia esse mesmo mantenedor e carrega data de última modificação em 5 de setembro de 2023 às 02:17:38 UTC, com a fonte registrada como APNIC.

Dois objetos de organização para um único ponto de troca não têm nada de incomum: objetos de registro se acumulam conforme endereços são pedidos e contatos mudam, e o objeto mais antigo costuma ficar onde está. O que importa para a responsabilização é qual objeto tem autoridade e o que a tipagem significa. O tipo LIR é o campo decisivo. Um Registro de Internet Local é uma organização que recebe espaço de endereçamento do registro regional e o subaloca aos próprios clientes.

Um ponto de troca tipado como LIR, portanto, não é apenas um switch num prédio: é um ponto de distribuição de recursos de numeração, com as obrigações que decorrem disso — registros, objetos de contato, manutenção das designações.

O campo do mantenedor afina isso. Os dois objetos são mantidos pelo APNIC-HM, que é o mantenedor interno do registro regional para objetos de nível superior. Um ponto de troca que mantém objetos de registro sob o mantenedor da própria casa está ancorado na estrutura administrativa do registro, em vez de atuar como membro de registro plenamente independente. É arranjo comum para organizações pequenas e não é crítica.

Significa apenas que a trilha documental dos recursos de numeração do ponto de troca termina dentro da própria administração do APNIC, exatamente onde um investigador esperaria encontrá-la e exatamente onde um terceiro não pode olhar adiante.

A data de última modificação do segundo objeto é 5 de setembro de 2023. Objetos são modificados quando algo muda; uma data parada é evidência de estabilidade administrativa, não de atividade operacional. Lida ao lado das marcas de tempo do PeeringDB, surge um padrão que vale nomear. O registro pai do ponto de troca foi atualizado pela última vez em 22 de janeiro de 2020. O objeto do APNIC foi modificado pela última vez em setembro de 2023. A ficha da LAN foi atualizada em 30 de junho de 2026, e a da instalação em 26 de setembro de 2025.

Quatro objetos, quatro safras, e o mais recente é o filho técnico, não o pai político. Quem mantém esse registro atualiza a LAN e a instalação enquanto deixa a descrição do ponto de troca — a camada que carregaria condições, níveis de serviço e contatos de política — congelada desde as primeiras semanas de 2020. Isso é um padrão de manutenção, e padrões são evidência. Diz que o mapeamento técnico está vivo e a descrição comercial não está.

Quatro números e a disciplina de não lê-los demais

Os dados de roteamento acrescentam uma terceira camada, de direção completamente diferente. O kit de ferramentas BGP do Hurricane Electric publica uma tabela por país para o Butão. Nela há uma linha que diz, literalmente: AS7615 Bhutan Internet Exchange 2 3 2 3 (visão de país do Hurricane Electric para o Butão). O cabeçalho de coluna acima dessa linha lista, em ordem, o ASN, o nome, adjacências IPv4, rotas IPv4, adjacências IPv6 e rotas IPv6.

A linha estabelece algo que as outras duas camadas não estabelecem: que o ponto de troca tem seu próprio número de sistema autônomo, AS7615, e que esse número é visível numa agregação global de dados de roteamento. O ponto de troca não é apenas uma entrada de registro e um inquilino de instalação; é entidade endereçável do sistema de roteamento, com seu AS próprio numa tabela que engenheiros de rede consultam.

Os quatro dígitos são o ponto em que a disciplina se impõe. Dois, três, dois, três. É tentador traduzir a linha para algo como "o ponto de troca tem dois pares e três rotas", e essa frase estaria errada de um modo que importa. O trecho preserva o cabeçalho e a linha, mas não vincula cada valor a uma coluna de forma inequívoca, e uma linha de quatro valores extraída de uma tabela larga pode perder o alinhamento. A leitura honesta é que a linha carrega quatro valores pequenos diante de colunas que nomeiam adjacências e contagens de rotas, e que os quatro são de um dígito.

O que se pode afirmar sem excesso é que uma contagem de adjacências de um dígito para o sistema autônomo de um ponto de troca nacional é pequena. Um servidor de rotas ou um ponto de troca grande costuma mostrar contagens na casa das dezenas ou centenas. Uma contagem dessa ordem é coerente com poucas redes membros, o que é coerente com as duas redes da ficha da instalação, o que é coerente com duas redes serem toda a história da interconexão doméstica no que estes registros alcançam. Três camadas independentes produzem números pequenos que apontam na mesma direção; cada uma é fraca sozinha, mas a concordância informa.

O que não se pode afirmar é a presença ou ausência de qualquer rede butanesa específica. A existência de uma linha para o AS7615 não diz nada sobre com quais outros sistemas autônomos ele troca rotas, e a tabela de país não enumera os pareamentos. Dizer que a operadora incumbente está no btIX, ou que uma operadora móvel não está, exigiria lista de membros ou dados de sessão, e nenhum dos dois está em mãos.

O campo das condições é o campo da responsabilização

De todos os campos do registro do ponto de troca, os dois que dizem Not Disclosed são os que um conselho deveria notar. Nível de serviço e condições. Ambos vazios no sentido da divulgação.

As condições comerciais de um ponto de troca determinam quem pode se conectar e sob que base. Uma taxa anual fixa por porta, cobrança por megabit, modelo sem liquidação financeira, estrutura em faixas por velocidade de porta — cada um produz um mercado diferente. Um ponto de troca sem liquidação financeira reduz o custo marginal da interconexão doméstica ao preço de um cross-connect, o que favorece entrantes e redes pequenas. Um ponto de troca pago eleva esse custo, o que favorece quem já tem volume e consegue diluir a taxa.

A escolha entre esses modelos é decisão de governança com consequências distributivas, e é invisível num registro que diz Not Disclosed.

Para um comprador, as consequências são práticas. Uma rede que considera uma porta não consegue modelar o custo do peering doméstico a partir do registro público, porque o preço não está lá. Não consegue comparar o btIX com levar esse tráfego ao exterior, porque a comparação exige um número. Não consegue julgar se o nível de serviço do ponto de troca é adequado ao tráfego que moveria, porque o nível de serviço também não está lá. O resultado é que a decisão de entrar se toma com base em relações e conversas em vez de condições publicadas — o que é normal em mercados pequenos e é também exatamente a condição em que os iniciados levam vantagem.

O ajuste de visibilidade IX-F se liga diretamente a isso. Um membro potencial que tenta avaliar se vale a pena entrar gostaria de saber quem já está lá. O ponto de troca marcou essa lista como privada. A combinação — lista de membros privada e condições não divulgadas — significa que um terceiro avaliando o btIX pode confirmar que existe e aproximadamente onde, e não pode confirmar com quem faria peering nem quanto custaria. Essa é uma postura de divulgação concreta e descritível, e a postura é conservadora.

Há uma razão defensável. Listas de membros e preços podem ser comercialmente sensíveis num mercado de dois ou três participantes, porque a publicação revela volumes relativos e posições de negociação. Um ponto de troca que publica sua lista num mercado de duas redes publica a situação competitiva de seus membros. Um operador pequeno pode concluir razoavelmente que a discrição serve melhor aos seus membros do que a transparência serve ao público. O argumento é coerente. Também é uma escolha que troca responsabilização externa por flexibilidade interna, e deve ser descrita como tal, não como acidente.

O bit de multicast e por que campos pequenos carregam grandes consequências

O registro habilita unicast e IPv6 e desabilita multicast. Desses ajustes, o de IPv6 é o que mais importará com o tempo e o de multicast é o que mais revela intenção.

Suporte a IPv6 habilitado significa que o registro afirma que o ponto de troca consegue carregar tráfego IPv6. Para um país com poucas redes, um ponto de troca que carrega IPv6 é o caminho mais barato para a interconexão doméstica em IPv6: sem ele, duas redes butanesas que queiram IPv6 precisam tunelar, ou rotear domesticamente por um provedor de trânsito internacional, ou não se interconectar de modo algum. Um registro com IPv6 habilitado reduz o custo desse caminho ao preço de uma porta.

Multicast desabilitado é afirmação mais específica. Multicast num ponto de troca é o meio pelo qual redes de distribuição de conteúdo e operadoras de televisão por internet entregam um único fluxo a muitas redes de acesso sem replicá-lo por membro. Desabilitá-lo significa que o registro não reivindica essa capacidade. Para um mercado onde a distribuição de vídeo importa — e em todo mercado importa —, a ausência de multicast limita os usos possíveis do ponto de troca. Empurra esse tráfego para unicast, e unicast o devolve ao caminho internacional ou à interconexão privada.

É aqui que o registro deixa de ser entrada de diretório e passa a ser descrição de gargalo. Um ponto de troca nacional que carrega IPv4 e IPv6 em unicast, sobre uma única LAN plana, a 1500 bytes, sem servidor de rotas nomeado e sem multicast, é um ponto de interconexão funcional para tráfego geral. Não é uma malha de distribuição. Essa distinção determina qual dos problemas de tráfego de um país o ponto de troca consegue resolver e qual não consegue, e ela é inteiramente visível em campos que alguém escolheu.

Quem responde, e por quê

Aqui o registro público acaba, e acaba de um modo específico o bastante para ser descrito em vez de apenas lamentado. Dos quatro registros examinados para este artigo, nenhum identifica a forma jurídica do ponto de troca, seus proprietários, seu órgão de governança, suas regras de admissão ou o procedimento pelo qual uma disputa de admissão seria resolvida (consulta Whois do APNIC sobre o ponto de troca).

É uma afirmação delimitada e seus limites devem ser declarados: quatro registros públicos, consultados num único dia, não contêm esses campos. Cobertura anterior deste ponto de troca no diretório do BTW registrou data de fundação, lançamento anunciado, uma instância de servidor raiz hospedada e uma lista de participantes com números de sistemas autônomos (entrada de diretório do BTW sobre o ponto de troca butanês Apenas para Strategic Circle). Esses fatos não são repetidos aqui e não são contraditos por nada nestes quatro registros; situam-se numa camada que este artigo não interrogou.

O que este artigo interrogou é a camada que um terceiro alcança sem relação prévia: a inscrição no registro, o objeto de registro de endereços e a tabela de roteamento. Nessa camada, o ponto de troca é legível como instituição em exatamente dois aspectos — detém um número de sistema autônomo e detém um objeto de Registro de Internet Local. Ambos são reais. Ambos têm consequência administrativa. Nenhum diz quem decide.

Para fins de controle, essa é a descoberta. O registro público descreve o encanamento de um ponto de troca com detalhe mecânico incomum — nome da LAN, MTU, marcação, campo do servidor de rotas, coordenadas da instalação, marcas de criação e atualização ao segundo — e não descreve sua governança de modo algum. Um regulador que perguntasse se o ponto de interconexão doméstica opera no interesse público teria de perguntar ao operador. Uma rede que se pergunta se deve entrar teria de perguntar ao operador. Um pesquisador que pergunta se o tráfego doméstico fica doméstico teria de perguntar ao operador.

Em cada caso, o registro confirma a existência da coisa sobre a qual se pergunta e não fornece nenhuma das respostas.

Há uma questão de desenho que vale nomear para quem administra um regime de divulgação. Os campos preenchidos são os que um engenheiro de rede precisa para configurar uma sessão: nome da LAN, MTU, se a marcação funciona, se há servidor de rotas. Os campos não preenchidos são os que um terceiro precisa para cobrar responsabilidade da instituição: condições, nível de serviço, lista de membros, identidade jurídica. Registros são populados por quem opera infraestrutura, e operadores populam o que precisam. Os campos de responsabilização chegam por último, quando chegam.

O que mudaria esta classificação

Uma classificação só é útil se puder ser atualizada, e esta pode, por mudanças concretas e observáveis.

Se a ficha da LAN passasse a nomear um número de sistema autônomo de servidor de rotas diferente de zero, seria mudança estrutural na arquitetura do ponto de troca, não cosmética. Significaria que existe uma função de roteamento operada pelo ponto de troca, e deslocaria parte significativa do controle da política de roteamento dos pares bilaterais para o próprio ponto de troca.

Se o campo de visibilidade da lista de membros IX-F passasse de Private para Public, a questão dos participantes se tornaria respondível a partir de dados legíveis por máquina em vez de inferência. Essa única mudança converteria a parte mais fraca da base probatória deste artigo na mais sólida, e custaria ao operador apenas uma decisão de divulgação.

Se os campos de nível de serviço e condições deixassem de dizer Not Disclosed, um comprador poderia modelar custo e um regulador poderia avaliar se a estrutura tarifária favorece os incumbentes. Se a marca de atualização do registro pai do ponto de troca avançasse além de janeiro de 2020 — não é o caso na ficha capturada aqui — a descrição comercial apareceria como mantida, não abandonada.

Se um expediente regulatório nacional descrevesse a propriedade do ponto de troca, suas regras de admissão ou seu procedimento de resolução de disputas, a camada de governança existiria num documento citável em vez de no vão entre dois campos de registro. Até lá, o resumo honesto é o que os próprios campos sustentam: o btIX é um ponto de troca real, registrado e endereçável em Thimbu, sobre uma única LAN Ethernet plana, sem servidor de rotas nomeado, sem condições publicadas e sem lista de membros pública. O encanamento está documentado ao segundo. A responsabilização não está documentada em lugar nenhum, e essa assimetria é a história.