Resumen

  • El Bhutan Internet Exchange aparece en tres capas públicas independientes — una ficha de intercambio en PeeringDB, dos objetos de organización en APNIC y una fila de país de Hurricane Electric para AS7615 — y las tres coinciden en el nombre, la ciudad y el número de sistema autónomo del intercambio.
  • Leído de cerca, el registro describe una única LAN Ethernet plana llamada TTPL-LAN en Thimphu Techpark, con una unidad máxima de transmisión de 1500 bytes, soporte 802.1Q declarado inactivo, un número de sistema autónomo de servidor de rutas igual a cero y campos de nivel de servicio y condiciones que dicen Not Disclosed.

Lo primero que hay que entender sobre el Bhutan Internet Exchange es que su identidad pública es delgada, y que esa delgadez es estructural, no accidental. PeeringDB aloja una ficha de intercambio con el identificador 2355, nombre corto btIX, nombre largo Bhutan Internet Exchange, en Timbu, país BT, región Asia Pacífico, sobre soporte Ethernet (ficha de PeeringDB del intercambio butanés). Toda la geografía cabe ahí. No hay segunda ciudad, ni segunda instalación, ni sitio alternativo. Para un país cuya conectividad internacional ha pasado históricamente por la India, un único punto de intercambio doméstico en la capital no es un detalle: es toda la capa de conmutación nacional, al menos tal como este registro la describe.

El objeto hijo de la ficha es donde vive realmente la ingeniería. La LAN del intercambio se llama TTPL-LAN. Su unidad máxima de transmisión se declara en 1500 bytes. Su campo de soporte 802.1Q dice falso. Su número de sistema autónomo de servidor de rutas dice 0. Se creó el 22 de septiembre de 2018 a las 17:01:27 UTC, en el mismo minuto que la ficha matriz, y su última actualización es del 30 de junio de 2026 a las 01:34:08 UTC. Su estado dice ok.

Esos cinco campos, juntos, describen una arquitectura y no una intención. Una MTU de 1500 es Ethernet corriente: nada aquí sugiere tramas gigantes, nada sugiere una malla ajustada para grandes caudales. La ausencia de soporte 802.1Q significa que la LAN se presenta, en los términos del propio registro, como un único dominio de difusión plano; un operador que lea esta ficha no debería esperar entrega por VLAN como función documentada.

Un número de sistema autónomo de servidor de rutas en cero es el valor de mayor consecuencia de todo el conjunto, y conviene decirlo sin rodeos: el campo que nombraría un servidor de rutas operado por el intercambio no contiene ningún número utilizable.

Ese cero cambia el significado mismo de ser miembro. En un intercambio con servidor de rutas, un miembro configura una sola sesión BGP hacia el intercambio y recibe la tabla colectiva; el intercambio se convierte en parte técnica de las decisiones de encaminamiento de cada miembro, y su competencia operativa entra en el radio de impacto de todos. Sin servidor de rutas, cada par de miembros que quiera intercambiar rutas debe negociar y configurar una sesión bilateral.

El peering bilateral cuesta más trabajo por par, pero mantiene el control en el borde: sin cerebro de encaminamiento compartido, sin un proceso único cuya caída degrade a todos y sin un operador del intercambio sosteniendo la pluma política sobre qué prefijos se anuncian a quién. El cero en ese campo no es un hueco del registro. Es una afirmación sobre dónde está el control.

La correspondencia con la instalación confirma el cuadro físico. PeeringDB vincula el intercambio a una sola instalación, el identificador 5806, llamada Thimphu Techpark, operada por una organización registrada como Bhutan Data Centre Services, con código CLLI TTPL y coordenadas 27,427781 norte y 89,650988 este (ficha de PeeringDB del intercambio butanés). La dirección postal dice Thimphu Techpark, Wangchuktaba, Timbu, estado de Timbu, código postal 11001. La instalación se creó el 22 de septiembre de 2018 a las 16:43:21 UTC — veinte minutos antes que la ficha del intercambio — y se actualizó por última vez el 26 de septiembre de 2025 a las 22:51:32 UTC. Su estado dice ok.

Los contadores de esa instalación ofrecen el contraste más nítido del conjunto. Declara dos redes, un intercambio y cero operadores de transporte. Dos redes en un punto de intercambio nacional, según la ficha del propio intercambio, es un número lo bastante pequeño para retenerlo sin ayuda. Es también el número que vuelve toda pregunta posterior sobre efecto competitivo fácil de plantear y difícil de resolver: con dos redes declaradas en el sitio, el valor marginal del intercambio depende por completo de cuáles sean, de si se interconectarían de otro modo y de cuál es el precio de la interconexión.

El registro no responde nada a la primera pregunta, nada a la segunda y responde a la tercera con la frase Not Disclosed.

El problema del nombre, que en realidad es un problema de detección

La pieza más instructiva de este conjunto no trata de Bután. Es la diferencia entre dos consultas a la misma API. Una consulta filtrada por la cadena literal bhutan internet exchange devolvió un arreglo de datos vacío y metadatos vacíos (respuesta del filtro por nombre en PeeringDB). Una consulta filtrada por país BT devolvió una ficha cuyo nombre largo es Bhutan Internet Exchange y cuyo nombre corto es btIX (ficha de PeeringDB del intercambio butanés).

Ambas respuestas son correctas. La ficha se llama btIX, y su nombre largo es un campo distinto que el filtro por nombre evidentemente no consultó en la forma de la cadena suministrada. Quien buscara el intercambio por su nombre inglés completo —es decir, un investigador, un periodista o un operador extranjero— recibió una negativa limpia. Quien buscara por país lo encontró de inmediato.

En términos de riesgo esto importa más de lo que parece. El valor de un registro para el público reside en su función de detección: es así como un tercero establece que un intercambio existe, quién está en él y para qué sirve. Cuando una búsqueda por nombre falla contra una ficha que existe, el registro no sufre una rareza de indexación: ha producido un falso negativo para exactamente el público que depende de él. El modo de fallo es asimétrico. Un actor de la comunidad de red butanesa conoce el nombre corto local, porque así se llama la cosa. Un actor externo, no.

El registro funciona, por tanto, para los iniciados y falla para los demás, que es lo contrario de la misión de un registro de divulgación.

La ficha de la LAN contiene una señal vecina. Su campo de visibilidad de la URL de la lista de miembros en formato IX-F dice Private, mientras que su campo de importación IX-F dice true. IX-F es el formato de intercambio normalizado mediante el cual los puntos de intercambio publican listas de miembros legibles por máquina, para que otros registros y herramientas las repliquen. Una visibilidad privada sobre la URL de la lista, con la importación activa, describe un intercambio dispuesto a ingerir el formato pero que ha elegido no publicar su propia lista por ese canal.

La lista de miembros no solo está sin publicar: está marcada como deliberadamente retenida.

Esa distinción merece conservarse, porque separa dos explicaciones muy distintas de un registro público delgado. La primera es la negligencia: nadie se ocupó. La segunda es una política: el operador decidió que la lista no era pública. La primera es un problema de mantenimiento, con remedio obvio y ninguna justificación defendible. La segunda es una decisión de gobernanza, y las decisiones de gobernanza se pueden interrogar. Una visibilidad privada es un ajuste que alguien seleccionó. Significa que el intercambio, o quien mantiene su ficha, tomó posición sobre la divulgación de la lista de miembros, y que esa posición es: no por este canal.

La consecuencia práctica es directa. Un tercero que quiera saber qué redes están presentes en btIX solo tiene una vía en el nivel del registro: leer las fichas de participantes de cada red en PeeringDB, o pasar por los datos de encaminamiento. Ambas vías son más débiles que una lista de miembros, porque describen lo que las redes dicen de sí mismas y no lo que el intercambio confirma de su propia composición.

Qué confirma la capa de registro y qué no puede confirmar

PeeringDB no es un regulador y no pretende serlo. Sus fichas se mantienen de forma colaborativa y las editan los operadores, lo que las hace valiosas para el mapeo e insuficientes para la verificación. Un estado ok significa que la ficha está intacta, no que la instalación tenga energía ni que la LAN esté pasando tramas. Un intercambio puede estar listado, actualizado y en estado ok mientras transporta un tráfico que nadie fuera de Timbu ha medido jamás.

Por eso importa la capa de APNIC. El registro regional no es autodeclarado del mismo modo; es un objeto formal de asignación, con un mantenedor y una pista de auditoría. El servicio Whois de APNIC devuelve dos objetos de organización bajo el nombre Bhutan Internet Exchange (consulta Whois de APNIC sobre el intercambio). El primero, ORG-BIE1-AP, lleva el país BT y una dirección que dice Bhutan Internet Exchange, Thimphu Techpark, Post Box 633, Wanghcuktaba, Babesa. El segundo, ORG-BIE2-AP, está tipado como Local Internet Registry, lleva la dirección Thimphu Techpark, Wangchuktaba, Post Box 633, lo mantiene APNIC-HM, referencia a ese mismo mantenedor y porta una fecha de última modificación del 5 de septiembre de 2023 a las 02:17:38 UTC con la fuente registrada como APNIC.

Dos objetos de organización para un solo intercambio no tienen nada de insólito: los objetos de registro se acumulan a medida que se piden direcciones y cambian los contactos, y el objeto más antiguo suele quedarse. Lo que importa para la rendición de cuentas es qué objeto tiene autoridad y qué significa su tipificación. El tipo LIR es el campo determinante. Un registro de internet local es una organización que recibe espacio de direccionamiento del registro regional y lo subasigna a sus propios clientes.

Un intercambio tipado como LIR no es, por tanto, solo un conmutador en un edificio: es un punto de distribución de recursos de numeración, con las obligaciones que ello conlleva — registros, objetos de contacto, mantenimiento de las asignaciones.

El campo del mantenedor lo precisa. Ambos objetos los mantiene APNIC-HM, que es el mantenedor interno del registro regional para los objetos de nivel superior. Un intercambio que tiene objetos de registro bajo el mantenedor de la casa está anclado a la estructura administrativa del registro en lugar de actuar como miembro de registro plenamente independiente. Es un arreglo habitual para organizaciones pequeñas y no es una crítica.

Significa que el rastro documental de los recursos de numeración del intercambio termina dentro de la propia administración de APNIC, exactamente donde un investigador esperaría encontrarlo y exactamente donde un tercero no puede mirar más allá.

La fecha de última modificación del segundo objeto es el 5 de septiembre de 2023. Los objetos se modifican cuando algo cambia; una fecha congelada es evidencia de estabilidad administrativa más que de actividad operativa. Leída junto a las marcas de tiempo de PeeringDB, aparece un patrón que merece nombrarse. La ficha matriz del intercambio se actualizó por última vez el 22 de enero de 2020. El objeto de APNIC se modificó por última vez en septiembre de 2023. La ficha de la LAN se actualizó el 30 de junio de 2026, y la de la instalación el 26 de septiembre de 2025.

Cuatro objetos, cuatro añadas, y la más reciente es el hijo técnico y no el padre político. Quien mantiene este registro actualiza la LAN y la instalación mientras deja la descripción del intercambio —la capa que portaría las condiciones, los niveles de servicio y los contactos de política— congelada desde las primeras semanas de 2020. Eso es un patrón de mantenimiento, y los patrones son evidencia. Dice que la cartografía técnica está viva y que la descripción comercial no lo está.

Cuatro números y la disciplina de no sobreinterpretarlos

Los datos de encaminamiento añaden una tercera capa, desde una dirección por completo distinta. La caja de herramientas BGP de Hurricane Electric publica una tabla por país para Bután. En ella hay una fila que dice, literalmente: AS7615 Bhutan Internet Exchange 2 3 2 3 (vista de país de Hurricane Electric para Bután). El encabezado de columna sobre esa fila enumera, en orden, el ASN, el nombre, las adyacencias IPv4, las rutas IPv4, las adyacencias IPv6 y las rutas IPv6.

La fila establece algo que las otras dos capas no establecen: que el intercambio tiene su propio número de sistema autónomo, AS7615, y que ese número es visible en una agregación mundial de datos de encaminamiento. El intercambio no es solo una entrada de registro y un inquilino de instalación; es una entidad direccionable del sistema de encaminamiento, con su propio número de sistema autónomo en una tabla que consultan los ingenieros de red.

Los cuatro dígitos son el punto donde la disciplina se impone. Dos, tres, dos, tres. Es tentador traducir esa fila a una frase como «el intercambio tiene dos pares y tres rutas», y esa frase sería falsa de una manera que importa. El extracto conserva el encabezado y la fila, pero no vincula cada valor a una columna de forma inequívoca, y una fila de cuatro valores extraída de una tabla ancha puede perder su alineación. La lectura honesta es que la fila lleva cuatro valores pequeños frente a columnas que nombran adyacencias y recuentos de rutas, y que los cuatro son de un solo dígito.

Lo que puede afirmarse sin exceso es que un recuento de adyacencias de un dígito para el sistema autónomo de un intercambio nacional es pequeño. Un servidor de rutas o un intercambio grande suele mostrar recuentos en decenas o centenas. Un recuento de ese orden es coherente con un número pequeño de redes miembro, lo que es coherente con las dos redes de la ficha de la instalación, lo que es coherente con que dos redes sean toda la historia de interconexión nacional según estos registros. Tres capas independientes producen números pequeños que apuntan en la misma dirección; cada una es débil por sí sola, pero su coincidencia informa.

Lo que no puede afirmarse es la presencia o ausencia de una red butanesa concreta. La existencia de una fila para AS7615 no dice nada sobre con qué otros sistemas autónomos intercambia rutas, y la tabla de país no enumera los emparejamientos. Afirmar que el operador histórico está en btIX, o que un operador móvil no lo está, exigiría una lista de miembros o datos de sesiones, y ni una ni otros están a mano.

El campo de las condiciones es el campo de la responsabilidad

De todos los campos de la ficha del intercambio, los dos que dicen Not Disclosed son los que una junta directiva debería notar. Nivel de servicio y condiciones. Ambos vacíos en el sentido de la divulgación.

Las condiciones comerciales de un intercambio determinan quién puede conectarse y sobre qué base. Una cuota anual plana por puerto, un cobro por megabit, un modelo sin liquidación económica, una estructura por tramos según la velocidad del puerto: cada uno produce un mercado distinto. Un intercambio sin liquidación económica reduce el coste marginal de la interconexión nacional al precio de un empalme físico, lo que favorece a los nuevos entrantes y a las redes pequeñas. Un intercambio de pago lo eleva, lo que favorece a quien ya tiene volumen y puede absorber la cuota.

La elección entre esos modelos es una decisión de gobernanza con consecuencias distributivas, y es invisible en un registro que dice Not Disclosed.

Para un comprador, las consecuencias son prácticas. Una red que considera un puerto no puede modelar el coste del peering nacional a partir del registro público, porque el precio no está. No puede comparar btIX con llevar ese tráfico a nivel internacional, porque la comparación exige un número. No puede juzgar si el nivel de servicio del intercambio es adecuado para el tráfico que movería, porque el nivel de servicio tampoco está.

El resultado es que la decisión de adherirse se toma sobre la base de relaciones y conversaciones en lugar de condiciones publicadas, lo que es normal en mercados pequeños y es también exactamente la condición en la que los iniciados llevan ventaja.

El ajuste de visibilidad IX-F se conecta directamente con esto. Un miembro potencial que intenta evaluar si vale la pena adherirse querría saber quién está ya allí. El intercambio ha marcado esa lista como privada. La combinación —lista de miembros privada y condiciones no divulgadas— significa que un tercero que evalúa btIX puede confirmar que existe y aproximadamente dónde, y no puede confirmar con quién se emparejaría ni cuánto costaría. Eso es una postura de divulgación concreta y descriptible, y la postura es conservadora.

Hay una razón defendible. Las listas de miembros y los precios pueden ser comercialmente sensibles en un mercado de dos o tres participantes, porque su publicación revela volúmenes relativos y posiciones de negociación. Un intercambio que publica su lista de miembros en un mercado de dos redes publica la situación competitiva de sus miembros. Un operador pequeño podría concluir razonablemente que la discreción sirve mejor a sus miembros que la transparencia al público. Ese argumento es coherente. También es una elección que cambia responsabilidad externa por flexibilidad interna, y hay que describirla como tal en lugar de como un accidente.

El bit de multicast y por qué los campos pequeños tienen grandes consecuencias

La ficha habilita unicast e IPv6 y deshabilita multicast. De esos ajustes, el de IPv6 es el que más importará con el tiempo y el de multicast es el que más revela la intención.

El soporte de IPv6 habilitado significa que la ficha afirma que el intercambio puede transportar tráfico IPv6. Para un país con pocas redes, un intercambio que transporta IPv6 es la vía más barata a la interconexión nacional en IPv6: sin él, dos redes butanesas que quieran ambas IPv6 tienen que encapsular, o encaminar a nivel nacional a través de un proveedor de tránsito internacional, o no interconectarse en absoluto. Un intercambio con IPv6 habilitado reduce el coste de esa vía al precio de un puerto.

El multicast deshabilitado es una afirmación más específica. El multicast en un intercambio es el medio por el cual las redes de distribución de contenido y los operadores de televisión por internet entregan un flujo único a muchas redes de acceso sin replicarlo por miembro. Deshabilitarlo significa que la ficha no reclama esa capacidad. Para un mercado donde la distribución de vídeo importa —y en todos los mercados importa—, la ausencia de multicast limita los usos posibles del intercambio. Empuja ese tráfico hacia unicast, y unicast lo devuelve a la vía internacional o a la interconexión privada.

Aquí es donde el registro deja de ser una entrada de directorio y se convierte en la descripción de un cuello de botella. Un intercambio nacional que transporta IPv4 e IPv6 en unicast, sobre una sola LAN plana, a 1500 bytes, sin servidor de rutas nombrado y sin multicast, es un punto de interconexión funcional para tráfico general. No es una malla de distribución. Esa distinción determina cuál de los problemas de tráfico de un país puede resolver el intercambio y cuál no, y es visible por completo en campos que alguien eligió.

Quién responde y de qué

Aquí el registro público se agota, y se agota de una manera lo bastante concreta para describirla en lugar de lamentarla. De los cuatro registros examinados para este artículo, ninguno identifica la forma jurídica del intercambio, sus propietarios, su órgano de gobierno, sus reglas de admisión ni el procedimiento por el cual se resolvería una disputa de admisión (consulta Whois de APNIC sobre el intercambio).

Es una afirmación acotada y sus límites deben enunciarse: cuatro registros públicos, consultados en un solo día, no contienen esos campos. Una cobertura anterior de este intercambio en el directorio de BTW registró una fecha de fundación, un lanzamiento anunciado, una instancia de servidor raíz alojada y una lista de participantes con números de sistemas autónomos (entrada de directorio de BTW del intercambio butanés). Esos hechos no se repiten aquí y no los contradice nada de estos cuatro registros; se sitúan en una capa que este artículo no interrogó.

Lo que este artículo interrogó es la capa a la que un tercero llega sin relación previa: la inscripción en el registro, el objeto de registro de direcciones y la tabla de encaminamiento. En esa capa, el intercambio es legible como institución en exactamente dos aspectos: tiene un número de sistema autónomo y tiene un objeto de registro de internet local. Ambos son reales. Ambos tienen consecuencias administrativas. Ninguno dice quién decide.

A efectos de control, ese es el hallazgo. El registro público describe la fontanería de un intercambio con un lujo inusual de detalle mecánico —nombre de la LAN, MTU, etiquetado, campo del servidor de rutas, coordenadas de la instalación, marcas de creación y actualización al segundo— y no describe en absoluto su gobernanza. Un regulador que preguntara si el punto de interconexión nacional actúa en interés público tendría que preguntar al operador. Una red que se pregunta si debe adherirse tendría que preguntar al operador. Un investigador que pregunta si el tráfico nacional se queda en el país tendría que preguntar al operador.

En cada caso el registro confirma la existencia de la cosa sobre la que se pregunta y no aporta ninguna de las respuestas.

Hay una cuestión de diseño que merece nombrarse para cualquiera que administre un régimen de divulgación. Los campos que se llenan son los que un ingeniero de red necesita para configurar una sesión: el nombre de la LAN, la MTU, si el etiquetado funciona, si hay servidor de rutas. Los campos que no se llenan son los que un tercero necesita para exigir cuentas a la institución: condiciones, nivel de servicio, lista de miembros, identidad jurídica. Los registros se pueblan con quienes operan la infraestructura, y los operadores pueblan lo que necesitan. Los campos de rendición de cuentas llegan al final, cuando llegan.

Qué cambiaría esta clasificación

Una clasificación solo es útil si puede actualizarse, y esta puede, mediante cambios concretos y observables.

Si la ficha de la LAN pasara a nombrar un número de sistema autónomo de servidor de rutas distinto de cero, sería un cambio estructural de la arquitectura del intercambio, no cosmético. Significaría que existe una función de encaminamiento operada por el intercambio, y trasladaría una parte significativa del control de la política de encaminamiento de los pares bilaterales al propio intercambio.

Si el campo de visibilidad de la lista de miembros IX-F pasara de Private a Public, la cuestión de los participantes se volvería respondible a partir de datos legibles por máquina en lugar de por inferencia. Ese único cambio convertiría la parte más débil de la base probatoria de este artículo en la más sólida, y no le costaría al operador más que una decisión de divulgación.

Si los campos de nivel de servicio y condiciones dejaran de decir Not Disclosed, un comprador podría modelar el coste y un regulador podría evaluar si la estructura tarifaria favorece a los actores establecidos. Si la marca de actualización de la ficha matriz del intercambio se moviera más allá de enero de 2020 —no es el caso en la ficha capturada aquí— la descripción comercial aparecería como mantenida y no abandonada.

Si un expediente regulatorio nacional describiera la propiedad del intercambio, sus reglas de admisión o su procedimiento de resolución de disputas, la capa de gobernanza existiría en un documento citable en lugar de en el hueco entre dos campos de registro. Hasta entonces, el resumen honesto es el que los propios campos sostienen: btIX es un intercambio real, registrado y direccionable en Timbu, sobre una sola LAN Ethernet plana, sin servidor de rutas nombrado, sin condiciones publicadas y sin lista de miembros pública. La fontanería está documentada al segundo.

La rendición de cuentas no está documentada en ninguna parte, y esa asimetría es la historia.