Resumen
- El Registration Data Access Protocol (RDAP) de RIPE identifica exactamente AS200427 y registra a Proximity Data Centres Limited.
activees el estado administrativo del objeto, no una medición de rutas o servicios. - PeeringDB devuelve una fila exacta para ASN 200427 con el nombre
nLighten - IX ASN. El número enlaza los registros técnicos, pero no demuestra una relación corporativa u operativa entre las dos etiquetas. - La respuesta congelada del Routing Information Service (RIS) de RIPE, consultada a las 00:00 UTC del 7 de agosto de 2026, muestra 0/325 para IPv4 y 0/320 para IPv6. Los ceros pertenecen a ese producto, momento y conjunto de colectores.
La pregunta correcta viene antes que la fuente
Un sistema autónomo reúne una red o varias redes que presentan una política de enrutamiento común hacia internet. Mediante el Border Gateway Protocol (BGP), los sistemas autónomos intercambian información sobre los bloques de direcciones que pueden alcanzar. El ASN aporta un identificador único al dominio de enrutamiento.
AS200427 sirve aquí para fijar el sujeto. Permite comprobar que el directorio, el objeto de RIPE, la ficha de PeeringDB y la respuesta del colector se refieren al mismo número, incluso cuando los nombres visibles no coinciden. Eso evita atribuir datos a una organización parecida o a otro dominio de enrutamiento.
Sin embargo, la pregunta define qué fuente hace falta. “¿Qué objeto administrativo es?” se responde con un registro. “¿Qué publicó el participante?” se examina en PeeringDB. “¿Qué devolvió un producto de observación en una fecha concreta?” exige conservar el método y el tiempo de RIS. Ninguna de esas preguntas equivale a “¿funcionaba un servicio?” o “¿quién es propietario de la empresa?”.
RIPE registra el recurso numérico
RDAP ofrece una forma estructurada de consultar datos públicos de los registros de recursos de internet. La respuesta de RIPE empieza y termina en 200427, por lo que abarca un solo sistema autónomo. Usa el handle AS200427, el nombre de objeto PROXIMITY-AS y registra a Proximity Data Centres Limited como entidad registrante.
El objeto tiene estado active. La respuesta conserva tanto el evento de alta como el último cambio en el 19 de diciembre de 2022 a las 15:15:02 UTC. Estos campos proporcionan identidad administrativa y una historia revisable.
No describen el sistema en ejecución. active no confirma que un router esté encendido, que una ruta sea visible, que un anuncio esté autorizado ni que una aplicación responda. El registro funciona como libro mayor: mantiene números únicos, asociaciones administrativas y datos de coordinación. Cuando la pregunta pasa al comportamiento operativo, hay que cambiar de evidencia.
PeeringDB conserva una declaración con otro nombre
La captura de PeeringDB contiene una única fila para ASN 200427, con id 31834 y nombre nLighten - IX ASN. El perfil tiene estado ok, tipo Enterprise, política general declarada Selective y fecha de actualización del 28 de marzo de 2024 a las 13:05:57 UTC.
El nombre no coincide con Proximity Data Centres Limited. Compartir ASN permite enlazar las fichas técnicas; no explica el motivo de la diferencia. Sin documentación corporativa específica, no se puede afirmar que exista una compra, fusión, nueva marca, propiedad o continuidad de operaciones. La formulación responsable mantiene ambas etiquetas visibles.
La ficha declara cero prefijos IPv4, cero prefijos IPv6, un AS-set de IRR vacío y ninguna fila netixlan. También incluye una banda de tráfico y un sitio web introducidos por el participante. Son declaraciones del perfil, no mediciones independientes.
Cero filas de LAN de intercambio no demuestra ausencia de toda presencia en intercambios, sesiones bilaterales o conexiones privadas. Cero prefijos declarados no demuestra que el ASN no origine espacio de direcciones. Selective tampoco confirma una sesión ni decide una solicitud concreta, y ok no es un indicador de salud de la red.
Una respuesta con ceros necesita fecha y denominador
La respuesta routing-status quedó congelada con query_time a las 00:00 UTC del 7 de agosto de 2026. Devuelve cero de 325 pares RIS IPv4 listados con rutas que cumplieran el método y cero de 320 pares IPv6. Los campos de espacio anunciado indican cero prefijos y direcciones IPv4, cero prefijos y equivalentes /48 IPv6, además de cero vecinos observados.
El denominador impide presentar el resultado como una verdad universal. La respuesta describe lo que devolvió un producto para su conjunto de observación y su hora. No prueba que no hubiera una ruta en ningún punto de internet, que AS200427 estuviera caído o que un sistema fuese inaccesible. Tampoco resuelve autorización de origen, tráfico, latencia, capacidad, topología, resiliencia o experiencia del cliente.
Los campos históricos tienen otro significado. first_seen identifica 185.94.255.0/24, origen 200427, a las 00:00 UTC del 18 de diciembre de 2017. last_seen muestra el mismo prefijo y origen a las 16:00 UTC de ese día. La consulta del producto corresponde a 2026.
Esas horas no forman por sí solas un intervalo de actividad o de caída. No demuestran que el ASN funcionara únicamente durante dieciséis horas, que dejara de anunciar después de 2017 ni que permaneciera ausente hasta 2026. Para estudiar continuidad haría falta una serie histórica diseñada para esa pregunta, con cobertura y umbrales explícitos.
Cómo avanzar sin rellenar los huecos
El primer paso es verificar identidad: número exacto, rango RDAP, handle y entidad registrada. Después se debe leer PeeringDB como un conjunto de declaraciones. La diferencia entre los nombres debe convertirse en una pregunta documental, no en una equivalencia supuesta.
Si el interés es el enrutamiento, hay que conservar producto, hora de consulta, familia de direcciones y denominador. Una investigación de continuidad necesita historia de rutas. Una investigación de autorización necesita registros de origen aplicables. Una pregunta sobre una sesión o un servicio exige telemetría autorizada o pruebas de extremo a extremo alineadas en el tiempo.
El registro de RIPE, el perfil de PeeringDB mantenido por el participante y la respuesta congelada de RIPE RIS son capas de evidencia distintas; ninguna demuestra por sí sola una sesión de peering activa, la ausencia de rutas, continuidad empresarial, alcance universal, autorización de rutas, capacidad, resiliencia ni servicio al cliente.
Límites de la evidencia admitida
Estas fuentes no establecen propiedad, adquisición, cambio de marca ni continuidad entre Proximity Data Centres Limited y nLighten - IX ASN. Tampoco documentan servicios, clientes, instalaciones, equipos, proveedores, escala comercial, geografía operativa o posición de mercado.
No confirman una presencia activa en un intercambio, una sesión con servidor de rutas, volumen de tráfico, rendimiento, capacidad, diversidad física, disponibilidad ni resultados para clientes. La conclusión sostenible es más estrecha: RIPE registra Proximity Data Centres Limited con AS200427; PeeringDB publica una fila para el mismo número bajo otra etiqueta; y el RIS congelado devuelve ceros dentro de un alcance temporal y de colectores definido.
Qué vigilar
- cambios en el rango, handle, registrante, estado o historial administrativo de AS200427 en RIPE RDAP;
- cambios en el nombre, política, recuentos de prefijos o filas de intercambio del perfil de PeeringDB;
- una fuente corporativa explícita que explique, si existe, la relación entre las dos etiquetas;
- observaciones de rutas que indiquen claramente producto, hora, familia de direcciones y denominadores;
- evidencia específica de historia, autorización, sesión o servicio cuando la decisión dependa de esas preguntas.