Resumen

  • RIPE Atlas permite a un mismo anfitrión hasta dos sondas de software tras una IP y cuatro dentro de un prefijo visible en BGP; entre todos los anfitriones, el máximo es 32 en un prefijo IPv4 y 64 en uno IPv6.
  • La política explica el coste, la escasa información marginal de despliegues densos, las excepciones y la posibilidad de cambiar los máximos. Falta la prueba que une un estado BGP fechado con el grupo contado en una espera concreta.
  • Un recibo privado y respetuoso con la seguridad debería fijar hora, vista de enrutamiento, prefijo resuelto, recuentos, umbral activado, condición de salida y revisión; la rendición pública puede hacerse con agregados.

Una regla de cuatro cifras

RIPE Atlas necesita evitar dos derroches distintos. Cada sonda conectada ocupa recursos del sistema y varias sondas de software en la misma red y ubicación pueden aportar resultados muy parecidos. A la vez, los anfitriones reciben créditos por mantenerlas activas. La red de medición quiere más diversidad, no simplemente más procesos idénticos acumulando incentivos.

El anuncio del 29 de abril de 2026 convirtió ese criterio en límites concretos. Cada anfitrión puede conectar dos sondas desde una misma dirección IP. Puede conectar cuatro desde un mismo prefijo IP «tal como se ve en BGP». Sin importar el anfitrión, el sistema admite como máximo 32 sondas desde un prefijo IPv4 o 64 desde uno IPv6. Quien llegue después del límite no podrá conectarse hasta que salgan otras sondas.

No son cuatro escalones intercambiables. El dos combina cuenta y dirección. El cuatro combina cuenta y prefijo de enrutamiento. El 32 y el 64 cuentan todas las cuentas dentro de un prefijo y distinguen familias de direcciones. Decir únicamente «violación por farming» no permite saber qué población ni qué límite produjeron la espera.

RIPE NCC también reconoció que la regla debe ajustarse a casos reales. Los máximos pueden cambiar. Un anfitrión cuyas sondas estén geográficamente dispersas pero parezcan salir de la misma red puede escribir y explicar el despliegue para que se considere una relajación. En aquel momento se calculaban 71 sondas de 13 anfitriones afectadas. Ese número pertenece al instante del anuncio: no es un censo de septiembre ni demuestra que las 71 terminaran esperando.

La precisión conceptual está en la frase «tal como se ve en BGP». El sistema no toma como frontera definitiva una asignación registral, un ASN entero ni una descripción escrita por el usuario. Mira el enrutamiento observado. Sin embargo, esa frontera puede cambiar. Aparece un anuncio más específico, se retira una ruta, se agrega un bloque, cambia el origen o divergen los puntos de observación. La máquina y su ubicación siguen iguales mientras cambia el conjunto con el que se la compara.

Eso es una posibilidad técnica, no la reconstrucción de un incidente. Las fuentes no muestran una sonda concreta retenida o liberada sólo por un cambio BGP. Tampoco identifican la fuente de rutas, los recolectores, el umbral de visibilidad, la hora de observación o la regla usada cuando hay varios prefijos relevantes. El análisis debe detenerse en esa frontera.

Un prefijo grande puede contener experiencias distintas

La conversación pública probó enseguida el supuesto de similitud. Robert Scheck preguntó por AS3209 y AS3320. Recordó una investigación en la que distintas sondas dentro del mismo prefijo visible en BGP habían mostrado comportamientos diferentes.

El ejemplo no convierte toda redundancia en diversidad. Sí demuestra que «misma ruta global» y «mismo punto de observación» no son equivalentes por definición. Un gran acceso residencial puede contener rutas internas, agregadores, políticas y dominios de fallo diferentes bajo un solo prefijo anunciado.

La contestación de RIPE NCC, incluida en el registro oficial de respuestas, evitó promesas excesivas. Los límites se habían elegido para no afectar el número habitual de sondas en esas redes. Se vigilaría la situación y el algoritmo podría dar más margen a los prefijos grandes en el futuro. Es el reconocimiento de una variable de diseño, no la concesión automática de excepciones a dos ASN concretos.

En el mismo hilo apareció la pregunta más inmediata para un operador: ¿la web explicaría la causa o mostraría sólo una desconexión? RIPE NCC prometió una etiqueta específica y contacto previo con los 13 anfitriones estimados. Las notas de la versión web del 15 de julio dicen que el resumen de la sonda ya avisa cuando está en espera por una infracción de farming.

Nombrar el estado es importante. Una espera deliberada deja de confundirse con un cortafuegos, una caída local o una pérdida del controlador. Pero la etiqueta no conserva el razonamiento. No revela si se activó dos, cuatro, 32 o 64; qué prefijo se resolvió; cuál era el recuento; o cuándo se comprobará de nuevo.

Estado descriptivo frente a procedencia de una decisión

La guía actual para gestionar una sonda reproduce los cuatro límites, la referencia BGP y la vía para justificar una dispersión geográfica. La FAQ sobre sondas y anfitriones completa los incentivos: la actividad genera créditos, RIPE Atlas busca diversidad topológica y quiere impedir el cultivo de créditos.

La API pública de sondas documenta los campos prefix_v4 y prefix_v6. Son útiles para describir la sonda, pero en el material revisado no existe un contrato público que una esos campos con una espera, un recuento y una instantánea de enrutamiento. Tampoco sería sensato volcar toda la lógica antiabuso. Direcciones exactas, asociaciones de cuentas y detalles que permitan ensayar evasiones deben quedar protegidos.

Por eso hay dos productos de transparencia. El anfitrión afectado y RIPE NCC necesitan un recibo privado reproducible. La comunidad necesita estadísticas agregadas que muestren el impacto sin señalar despliegues. Confundir ambos niveles lleva a elegir entre secreto total y exposición excesiva, cuando no hace falta ninguno.

La documentación de BGP State en RIPEstat sirve como vocabulario. Una observación de rutas puede anotar recurso, instante, recolectores seleccionados, identificadores de fuente y hora de consulta. No hay prueba de que RIPE Atlas use RIPEstat, RIS, todos sus recolectores ni el mismo cálculo para aplicar los límites. El ejemplo sólo muestra cuánta precisión cabe detrás de «visto en BGP».

Cómo sería un recibo útil

El registro privado empieza con la hora de decisión, la familia de direcciones y una representación protegida de la IP de origen. Incluye el prefijo que el sistema resolvió, la hora del estado BGP y el límite de observación usado. Si había rutas competidoras o varias coberturas, conserva la regla de elección.

Después identifica el nivel. ¿Era la tercera sonda del anfitrión tras una IP, la quinta del mismo anfitrión en el prefijo, la número 33 del grupo IPv4 o la 65 del grupo IPv6? El recuento anterior y el máximo aplicable deben viajar juntos. Si varias conexiones llegan simultáneamente, también importa el orden estable que decide quién queda dentro.

La tercera parte es la salida. «Hasta que otras se desconecten» comunica la idea general, pero no dice cuándo se recalcula el grupo, si un cambio de ruta provoca revisión, si hay cola o qué evento devolvió el servicio. Las excepciones deberían registrar solicitud, categoría del motivo, resolución, revisor y caducidad sin publicar el relato sensible del anfitrión.

Para el público bastan series agregadas: esperas y liberaciones por nivel y familia; tiempo hasta la conexión; solicitudes de excepción y resultado; cambios atribuibles a una revisión de límites; y reevaluaciones ligadas a fronteras BGP. Los datos escasos pueden agruparse o retrasarse para evitar la identificación.

La propuesta de Theo March no supone que RIPE NCC carezca de registros internos. Pide que la transición entre observación y autoridad tenga un formato reconocible. Tampoco acusa a quien supera un umbral: «farming violation» es el nombre de un estado del producto, no una prueba sobre la intención del anfitrión.

Fuentes