Resumen

  • ACSP 2023.1 dice que AS13335:AS-CUSTOMERS, enviado mediante la API XML de ARIN, se publicó como RPSL con numerosos miembros en una sola línea física members:.
  • El proponente mostró una consulta recursiva a un espejo que creía basado en IRRd v3; la respuesta completa contenía solo siete ASN. ARIN coincidió en que limitar los elementos por línea mejoraría los resultados y dejó la sugerencia abierta hasta su implementación.
  • La membresía lógica, la estructura RPSL, los bytes exportados, el objeto importado, el resultado recursivo y el filtro generado son estados diferentes. La validez del primero no certifica la integridad de los demás.
  • Un recibo de serialización entre espejos debería enlazar recuento y huella canónicos con bytes, límites de línea, identidad de importación, recuento analizado y huella de la consulta, además de señalar explícitamente rechazo o truncamiento.

Siete ASN después de una lista mucho mayor

En la sugerencia ACSP 2023.1 de ARIN, Joe Abley explicó que Cloudflare actualizaba AS13335:AS-CUSTOMERS de forma automatizada mediante cargas XML. ARIN convertía esa entrada en RPSL y reunía los miembros en una única línea members:. La página enseña una porción extensa, abrevia la parte central y termina con varios ASN altos; no es una copia completa que permita recalcular hoy toda la colección.

El expediente incluye después la salida de !iAS-CLOUDFLARE,1 en otro servidor. El autor dijo creer que era una instancia IRRd v3 y presentó la respuesta como completa, no como una captura visual recortada: siete ASN seguidos del terminador del protocolo. Este artículo no ha repetido aquella consulta ni afirma que el servidor histórico continúe disponible.

La respuesta de ARIN fue prudente. El 7 de febrero de 2023 reconoció que reducir los elementos de cada línea produciría mejores resultados en consultas de AS-SET, anunció que investigaría los requisitos y mantendría la sugerencia abierta hasta implementarla. La ficha pública aún aparece Open. Eso demuestra el estado público de la solicitud, no que el serializador actual siga produciendo los mismos bytes.

Tampoco demuestra un incidente de BGP. No hay aquí prueba de un filtro actual de Cloudflare, de una ruta descartada, de una fuga o de una interrupción. Lo que sí existe es un registro oficial de una discrepancia de interoperabilidad y una respuesta de ARIN que relaciona líneas más cortas con mejores resultados.

Colección, atributo y línea no son lo mismo

El RFC 2622 define members como un atributo opcional y multivaluado. Cada valor puede contener una lista de números de AS o nombres de otros AS-SET. El estándar distingue dos ejes: una lista tiene varios elementos dentro de un valor; un atributo multivaluado puede repetirse.

La representación textual añade las líneas físicas. Cada par atributo-valor comienza en una línea, pero un valor puede continuar cuando la siguiente empieza con espacio, tabulador o signo más. También es posible repetir members:. Por tanto, una misma colección lógica puede expresarse con una línea muy larga, varias apariciones del atributo o continuaciones, y seguir siendo RPSL válido.

Esa equivalencia semántica no obliga a todos los lectores a tratar los bytes de igual forma. Un programa moderno puede aceptar líneas enormes; otro más antiguo puede tener un búfer, un límite de campo o una regla de recuperación distintos. Una descarga puede llegar completa y aun así perder datos al analizarse. Una importación puede fallar y dejar visible una versión anterior.

ACSP 2023.1 no identifica cuál de esas posibilidades produjo la salida observada. Sería irresponsable atribuirla a un búfer concreto o a un defecto específico de IRRd. Sí justifica medir la forma física como parte del intercambio.

La conversión XML–RPSL también es una interfaz

La documentación actual del IRR de ARIN explica que un objeto sencillo enviado en XML se convierte internamente a RPSL. El manual de la API REST permite representaciones XML y RPSL y describe members como los ASN u otros conjuntos que integran el AS-SET.

El editor decide la colección enviada. ARIN decide la forma física de la conversión. Según la sugerencia, el esquema XML no ofrecía un control para repartir los elementos entre líneas; esa decisión pertenecía al código de ARIN.

Dividir la línea es una mejora razonable porque reduce la presión sobre lectores heredados. Sin embargo, no prueba por sí sola la integridad final. El portal puede mostrar saltos que no existen en la exportación. El espejo puede aceptar todas las líneas pero aplicar un límite de miembros. La consulta recursiva puede seguir otra selección de fuentes. Una reparación real debe comparar el conjunto normalizado antes y después.

El espejo no es una ventana transparente

ARIN ofrece actualmente NRTM, archivos descargables y Whois, y señala que su servidor usa IRRd Version 4. La documentación de espejado de IRRd describe un proceso que obtiene instantáneas o actualizaciones, analiza y valida objetos y los guarda en una base local.

En ese momento cambia la custodia. El espejo tiene versión de software, configuración, política de fuentes, historial de series y tratamiento de errores propios. Haber recibido una actualización no demuestra que el objeto almacenado conserve todos los miembros. Haber almacenado el objeto no demuestra que una consulta derivada use las fuentes y la profundidad esperadas.

Conviene comprobar tres uniones: bytes publicados frente a bytes recibidos; miembros normalizados en origen frente a miembros analizados y almacenados; y estado almacenado frente al resultado de la consulta con opciones explícitas. Sin el paso intermedio, una respuesta corta no dice si la pérdida ocurrió durante el transporte, el análisis o la resolución.

La atomicidad de una recarga moderna evita que los usuarios vean una transacción a medias. No convierte automáticamente en completo cualquier objeto aceptado. Tampoco permite proyectar el comportamiento actual de IRRd sobre un espejo heredado de 2023.

Una expansión recursiva es un resultado calculado

El manual de consultas Whois de IRRd señala que !i produce datos procesados. Con la opción recursiva sigue conjuntos anidados y devuelve miembros resueltos separados por espacios. No es una reproducción del objeto RPSL bruto.

La consulta directa del objeto local sirve para ver qué guardó el espejo. La consulta recursiva sirve para observar qué deriva su grafo local. El generador de filtros puede luego buscar prefijos de esos ASN y compilar reglas. Cada salida depende de la anterior, pero ninguna es idéntica a ella.

Por eso un código de éxito no basta. Un resultado parcial puede estar correctamente terminado y parecer apto para la automatización. Antes de usarlo como entrada de filtros, el consumidor necesita una prueba de que el universo resuelto coincide con la versión que esperaba.

Un recibo para seguir la pérdida

Un recibo de serialización entre espejos convertiría la compatibilidad en algo comprobable. Es una recomendación editorial, no una promesa de ARIN ni de IRRd.

El emisor registraría la clave del conjunto, la versión o serie, el recuento de miembros normalizados y una huella calculada con un orden documentado. Añadiría el nombre y versión del serializador, la huella exacta del RPSL exportado, el total de bytes, el número de líneas y la longitud máxima.

El espejo identificaría origen, instantánea o rango NRTM, hora de importación, analizador y resultado. Compararía la huella recibida y publicaría el recuento y la huella de miembros almacenados. El estado tendría que distinguir completo, rechazado, truncado, parcialmente analizado o desactualizado tras un fallo.

El recibo de consulta incorporaría cadena consultada, fuentes, profundidad o marca de recursión, exclusiones, hora, cantidad y huella del resultado. Un generador podría enlazar la huella de su filtro sin divulgar la configuración.

Así no se centraliza la decisión de enrutamiento. Se hace visible el primer límite en el que dos sistemas dejan de conservar el mismo significado.

Fuentes