Resumen

  • El objeto aut-num de APNIC para AS2042 —nombre GCT-HK— carga líneas de descripción con servicios comerciales ("Dedicated Server, Virtual Private Server VPN, CDN, MPLS, IPL", "Disaster Recovery", "Cloud, OpenStack, Vmware") y la doble mención "HK Global Cloud DataCenter" y "multimedia pacific limited", bajo la organización ORG-ZL4-AP (zhelet limited), con última modificación el 12 de mayo de 2020.
  • La red observada es de un solo hogar: Hurricane Electric contabiliza 12 prefijos IPv4 y 0 IPv6 (unas 4.096 direcciones), con dos vecinos —AS3491 (PCCW Global) y AS18186 (Nebula Global LLC)—, ambos clasificados como proveedores, sin clientes ni pares libres de liquidación y sin participación conocida en ningún IXP.
  • La higiene de enrutamiento es floja: 7 de los prefijos originados figuran como RPKI inválidos frente a solo 2 válidos, se anuncian prefijos bogon y las rutas observadas incluyen hasta cuatro repeticiones consecutivas de su propio AS.
  • La huella verificable de hospedaje es modesta: unos 540 dominios en unas 57 IP desde la dirección de registro en Kwai Chung (Hong Kong), según IPinfo.
  • Ninguna fuente pública examinada verifica una instalación de centro de datos propia ni un despliegue de OpenStack o VMware; las líneas de descripción son autoafirmaciones del registrante y los recuentos de los agregadores varían con el tiempo.

Un número de red con dos nombres

Todo lo que la evidencia pública puede decir sobre "HK Global Cloud DataCenter" comienza en el objeto aut-num que APNIC publica para el AS2042. El registro asigna al número el nombre de sistema GCT-HK, con país HK, y lo cuelga del identificador de organización ORG-ZL4-AP, que corresponde a zhelet limited; los contactos administrativo y técnico (ZLA5-AP), el punto de abuso (AZ377-AP), el maintainer MAINT-ZHELETLIMITED-HK y el buzón IRT-ZHELETLIMITED-HK remiten todos a la misma organización. El objeto registra una última modificación el 12 de mayo de 2020 a las 16:52:58 UTC (APNIC Whois; rdap.org; IPinfo; espejo whois de ipip; documentación RDAP de APNIC).

Lo que distingue a esta entrada no es su estructura, que es convencional, sino el contenido del campo descr. Junto a la denominación "HK Global Cloud DataCenter" —con su variante "Global Cloud DataCenter"— figura una segunda razón social, "multimedia pacific limited", y tres líneas de marketing de servicios: "Dedicated Server, Virtual Private Server VPN, CDN, MPLS, IPL", "Disaster Recovery" y "Cloud, OpenStack, Vmware". El registro de APNIC no audita lo que el titular escribe en descr: reproduce textualmente su declaración (APNIC Whois). Ese detalle define el marco de todo el expediente: el nombre que encabeza el perfil de la entidad en el directorio de BTW es, literalmente, una cadena que el propio registrante escribió en su objeto de registro.

El campo descr existe para que el titular describa su red y, en la práctica, funciona como la única superficie de marketing que un objeto de registro ofrece. Cuando un titular carga en ella una cartera completa de servicios, el registro la difunde sin filtrar: whois, RDAP y los agregadores que rastrean la base la heredan textualmente. La distancia entre esa superficie y el estado operativo no la mide el registro; la miden la tabla de enrutamiento, la estructura de vecinos y la huella de uso. Es exactamente lo que miden las secciones siguientes.

Dos fechas y una sola asignación

La historia del número añade una capa de cuidado interpretativo que conviene fijar antes de leer cualquier recuento. ARIN, el registro regional para América del Norte, mantiene una ficha del AS2042 bajo la etiqueta "APNIC-2042", con fecha de registro del 31 de julio de 2002 y última actualización del 8 de octubre de 2009, y aclara expresamente que el objeto no está registrado en ARIN: es un número del territorio de APNIC cuyo bloque se remonta a la asignación de la era IANA (ARIN Whois). Los agregadores, por su parte, fechan la asignación vigente a zhelet limited (ORG-ZL4-AP) el 13 de octubre de 2016 (CIDR Report; ipgeolocation.io).

Las dos fechas describen hechos distintos. La de 2002 pertenece al ciclo histórico del bloque y a su paso por la asignación IANA previa a la estructura actual de registros regionales; la de 2016 pertenece a la titularidad operativa contemporánea. Confundirlas produce dos errores simétricos: atribuir a la red actual casi un cuarto de siglo de operación continua, o suponer que un número con antigüedad de 2002 implica un operador consolidado. Ninguna de las dos inferencias tiene soporte en el expediente.

Qué anuncia AS2042 en la tabla global

Las vistas públicas de enrutamiento coinciden en el perfil y divergen en los recuentos, y las divergencias son en sí mismas informativas. Hurricane Electric reporta que AS2042 origina 12 prefijos IPv4 y ningún prefijo IPv6, unas 4.096 direcciones IPv4, con dos pares BGP observados: AS3491 (PCCW Global) y AS18186 (Nebula Global LLC) (Hurricane Electric). bgp.tools, en su captura, cuenta 7 prefijos —el equivalente a 14 prefijos /24—, un único upstream (AS3491) y clasifica el tipo de red como "Content" (bgp.tools). La vista AS6447 de CIDR Report muestra también un único upstream, ningún cliente aguas abajo y unas 3.584 direcciones repartidas en 7 prefijos (CIDR Report). IPinfo, por último, contabiliza 3.072 direcciones, una cifra que contradice las ~4.096 de Hurricane Electric (IPinfo).

Las divergencias no anulan la conclusión; la acotan. Entre capturas de fuentes distintas, el espacio anunciado se mueve en una banda de 3.072 a 4.096 direcciones y los prefijos entre 7 y 12. Cualquiera que sea el recuento exacto en un momento dado, el orden de magnitud es estable: unos pocos miles de direcciones IPv4, espacio IPv6 nulo y un conjunto de prefijos que una operación media de hosting administraría sin dificultad. Para los servicios que la descripción anuncia —CDN con demanda, recuperación ante desastres empresarial, nube multiusuario—, ese orden de magnitud es por sí mismo un límite material.

El IPv6 merece mención aparte porque su ausencia es estructural y no un artefacto de captura. Ninguna de las vistas examinadas registra un solo prefijo IPv6 originado por AS2042. Para una operación tradicional de hosting, carecer de IPv6 en 2026 es una limitación menor; para una plataforma de nube con ambiciones declaradas es un marcador de ausencia, porque las redes de servicio de los despliegues OpenStack y VMware orientados a clientes externos se provisionan típicamente en modo dual-stack. El dato no prueba nada por sí solo, pero no contradice la tesis de una red cuyo catálogo declarado excede con mucho a su despliegue.

Dos proveedores, cero clientes y ningún IXP

La estructura de vecinos es el dato estructural más elocuente del expediente. bgpthingy clasifica los dos vecinos IPv4 de AS2042 como proveedores —cero clientes y cero pares libres de liquidación— y señala que la red no participa en ningún IXP conocido (bgpthingy). La vista de CIDR Report coincide en la ausencia de descendencia y muestra además rutas con hasta cuatro repeticiones consecutivas del propio número en el AS path —por ejemplo, la secuencia "7018 3491 2042 2042 2042 2042"—, una práctica típica de manipulación de la preferencia de tránsito que los operadores experimentados leen como la firma de una red pequeña y poco pulida (CIDR Report).

Traducido a arquitectura: AS2042 depende de tránsito comprado para toda su alcanzabilidad, no vende tránsito a nadie y no intercambia tráfico directamente con pares en ningún punto de intercambio documentado. En una ciudad con uno de los ecosistemas de interconexión más densos del mundo —Hong Kong, con el HKIX como principal punto de encuentro—, carecer de presencia en IXP es una decisión de diseño o una limitación de recursos.

Para un proveedor de CDN o de recuperación ante desastres con demanda real, la interconexión no es un lujo sino la materia prima del producto; su ausencia observable es una de las distancias más grandes entre la descripción registrada y el estado desplegado.

La consecuencia operativa del perfil de un solo hogar es directa: toda la alcanzabilidad de la red pasa por el tránsito de AS3491, con AS18186 como segunda vía observada en algunas capturas. Un problema en el upstream, un filtro mal aplicado aguas arriba o una escalada de la reputación del espacio anunciado se propagan al conjunto de los dominios alojados sin capa de amortiguación. Es exactamente la clase de riesgo que una red con interconexión propia diluye y que una red comprada hereda íntegro.

Higiene de enrutamiento: ROAs publicados, prefijos inválidos y bogons

El estado de RPKI es, en términos operativos, el punto más flojo del expediente. Hurricane Electric clasifica 7 de los prefijos originados por AS2042 como RPKI inválidos y solo 2 como válidos, y marca además la red por anunciar prefijos bogon, rangos que no deberían aparecer nunca en la tabla global (Hurricane Electric). bgpthingy registra objetos ROA publicados bajo el TAL de APNIC para 103.235.172.0/22 y 150.242.216.0/22 (bgpthingy). La coexistencia de ROAs publicados con una mayoría de prefijos invalidados sugiere un estado de RPKI mantenido a medias: parte del espacio dispone de objetos de autorización de origen y el resto se anuncia sin una cadena de validación que lo sostenga.

Whisper Security añade la dimensión de reputación: unos 14 de las ~4.096 direcciones IPv4 anunciadas figuran en sus listas de amenazas, con una reputación "NEUTRAL" internamente inconsistente —16,2 frente a 57,5 en la misma captura— (Whisper Security). La cifra absoluta es pequeña, cerca del 0,3% del espacio anunciado, pero una métrica que se contradice a sí misma dentro de la misma captura subraya cuánto ruido acumula este conjunto de direcciones y cuánta cautela exige cualquier lectura automática de su reputación.

Prefijos con nombres de terceros

Varios prefijos que AS2042 origina llevan descripciones de registro que nombran a terceros: CNISP-Union Technology Beijing, Dongguan JUXUN Network Technology y QY Network Maoming (Hurricane Electric; CIDR Report). ipgeolocation.io, además, atribuye 103.30.200.0/23 —un bloque del conjunto anunciado— a AS133115 (HK Kwaifong Group Limited) en lugar de a AS2042 (ipgeolocation.io); la consulta whois capturada para AS133549 (APNIC Whois AS133549) ilustra cómo reproducir esta comprobación contra los objetos de registro originales. La propia atribución de los agregadores oscila entre capturas: las mediciones contabilizan 756 y 759 rutas observadas en momentos distintos (Hurricane Electric; CIDR Report).

Tres explicaciones son compatibles con estos datos y el registro público no permite elegir entre ellas: subasignación legítima del espacio a terceros, alquiler de rutas —originar prefijos cuyo anuncio se vende a otros— o atribución errónea por parte de los agregadores. La indeterminación importa para cualquier contraparte que evalúe a la red: parte del espacio que AS2042 anuncia puede pertenecer a otros operadores o estar bajo control operativo ajeno. En cualquiera de los tres casos, mientras el prefijo salga del origen de AS2042, la responsabilidad operativa del anuncio —y su exposición a bloqueos y filtrados— sigue siendo de esta red.

La huella de hospedaje en Kwai Chung

La pieza empírica más concreta del expediente procede de la clasificación de uso. IPinfo clasifica AS2042 como red de tipo "Hosting" y reproduce la dirección de registro "UNIT 2 7/F TRANS ASIA CTR 18 KIN HONG ST KWAI CHUNG NT", en Kwai Chung, en los Nuevos Territorios de Hong Kong (IPinfo). La página de prefijos del mismo servicio reproduce el inetnum de APNIC para 150.242.216.0/22 (netname ZHELETLIMITED-HK, estado "ALLOCATED PORTABLE", con el objeto de ruta modificado por última vez el 15 de agosto de 2024) y contabiliza unos 540 nombres de dominio alojados en unas 57 IP, con una latencia dentro de la región de Hong Kong de aproximadamente 1,5 ms (IPinfo).

Este es el retrato verificable de la red: una operación de hospedaje pequeña pero real, con cientos de dominios servidos desde un puñado de direcciones en un edificio de Kwai Chung y latencias de zona coherentes con una presencia local única. Nada en el recuento sugiere la infraestructura de una nube multiusuario, de una plataforma de recuperación ante desastres empresarial o de una red de entrega CDN: esas categorías de producto dejan huella en interconexión, espacio direccionable y diversidad de ubicaciones, y esa huella no aparece.

Contactos: a quién se le pregunta

Los contactos del registro remiten, otra vez, a zhelet limited. El contacto administrativo y técnico figura como "zhelet limited administrator" (los datos de contacto completos se reproducen en la sección del Círculo Estratégico), y el buzón de abuso del IRT-ZHELETLIMITED-HK lleva una observación de APNIC que indica que la dirección fue validada el 11 de agosto de 2026; para denuncias de alcance RIR, el contacto "APNIC Whois Contact" es el canal registrado (APNIC Whois). Un registro público de interconexión de origen PeeringDB que los agregadores reproducen lista un teléfono de interconexión con formato de marcador de posición (reproducido en la sección del Círculo Estratégico) (CIDR Report; ipgeolocation.io), un valor que se lee como marcador de posición antes que como línea operativa.

Para un comprador, la capa de contacto es la primera prueba de estrés de cualquier proveedor de infraestructura. Un buzón de abuso validado por el registro es una señal mínima de operatividad; un teléfono de interconexión con formato de marcador no es una señal. El contraste entre ambos resume bien el nivel de madurez que la evidencia pública permite documentar en esta capa.

Qué exigiría una nube de verdad

Una operación con el catálogo que descr anuncia —OpenStack multiusuario, VMware, recuperación ante desastres, CDN, MPLS e IPL— deja huella en la tabla de enrutamiento casi siempre antes que en cualquier material comercial: multiconexión con varios tránsitos, sesiones de peering en puntos de intercambio, espacio IPv6, un cono de clientes propio y un estado RPKI estable. AS2042 no muestra ninguno de esos marcadores en las capturas examinadas: dos vecinos comprados, cero clientes, cero IPv6, ningún IXP conocido y una mayoría de prefijos con validación RPKI fallida.

Esta ausencia no demuestra que no existan servicios desplegados detrás de las direcciones de la red. Los servicios pueden operar sin la interconexión que la tabla hace visible, y un operador pequeño puede gestionar OpenStack para una cartera reducida sin necesitar peering. Lo que la ausencia fija es el techo de lo verificable: con la evidencia pública disponible, AS2042 es una red pequeña de hospedaje con tránsito comprado, y la carga de la prueba de cualquier papel de mercado mayor recae en evidencia de despliegue que, a la fecha de este informe, no es pública.

Límites de la evidencia

Tres fronteras delimitan lo anterior. La primera: las líneas descr son autoafirmaciones del registrante; el registro reproduce la declaración, no la audita, y la cartera de servicios anunciada no es, por sí misma, un hecho de mercado. La segunda: los recuentos de los agregadores varían con el tiempo y entre fuentes —7 frente a 12 prefijos, 3.072 frente a ~4.096 direcciones, 756 frente a 759 rutas entre capturas— y ninguna vista individual constituye un censo.

La tercera: ningún documento público examinado nombra una instalación concreta; el expediente del directorio no contiene afirmaciones legales, de control o de eventos verificables, y la atribución de varios prefijos a terceros sigue sin resolverse.

La lectura honesta es estrecha y específica. AS2042 es, según la evidencia observable a 26 de septiembre de 2026, una red de hospedaje pequeña, de un solo hogar, con sede registrada en Kwai Chung (Hong Kong), que carga en su descripción de registro un catálogo de servicios que su estado de enrutamiento no corrobora. Si el papel de mercado que la descripción reclama existe, deberá demostrarse con despliegue: instalación, interconexión, espacio y validación. Hasta entonces, la descripción es marketing; la tabla es el hecho.

Notas de fuentes

El objeto whois de APNIC para el recurso asociado AS133549, capturado para este análisis, está disponible en https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS133549; APNIC documenta el acceso machine-readable al registro vía RDAP en https://whois.ipip.net/AS2042. La consulta whois directa de APNIC para AS133549 está reproducida en https://wq.apnic.net/apnic-bin/whois.pl?object_type=aut-num&searchtext=AS133549, y la documentación de APNIC sobre RDAP está en https://www.apnic.net/about-apnic/whois_search/about/rdap/.