Resumen

  • IRR Auto-Manager puede crear o enlazar un objeto de ruta IRR al generar un ROA, pero permite que después ambos registros tengan ciclos de vida independientes.
  • ACSP 2026.9 solicita para IRR un registro de acciones semejante al que ya existe para los ROA. Dos historiales comparables, no obstante, aún necesitan una identidad común para explicar una sola operación.
  • Un recibo acotado entre registros puede conservar intención, estado previo, decisiones y correcciones sin presentar una autorización ROA y una declaración RPSL como si fueran el mismo dato.

La comodidad que ofrece ARIN es fácil de entender. Antes, un titular de recursos podía crear una Route Origin Authorization y, por separado, mantener un objeto de ruta en el Internet Routing Registry. Dos sistemas, dos modelos de datos y dos ocasiones para que una tarea pendiente dejara los registros desalineados. IRR Auto-Manager permite generar el objeto coincidente al crear el ROA y mantener un vínculo entre ambos.

No conviene minimizar ese avance para construir una crítica. La automatización quita duplicación sin quitar elección. El ajuste puede apagarse para un Org ID, y el usuario puede rechazar la creación del objeto IRR en una operación concreta. Si ya existe un objeto coincidente no administrado, puede reemplazarlo con uno administrado automáticamente o conservarlo. La herramienta Sync Up permite crear o enlazar objetos para ROA existentes. Es una ayuda operativa, no una apropiación de la política de rutas del titular.

La arquitectura también permite deshacer el vínculo de manera deliberada. Un objeto IRR puede borrarse sin afectar el ROA. Cuando se elimina el ROA, el usuario ve los objetos vinculados y puede suprimirlos o dejarlos como no administrados. Un ROA con varios prefijos puede crear un objeto IRR por cada prefijo. El resultado no siempre es una pareja estable de uno a uno, y esa flexibilidad responde a casos reales de operación.

Hay además una diferencia semántica que el producto preserva. Un ROA es una autorización firmada del AS de origen y puede incluir maxLength, el límite de especificidad autorizado. Un objeto de ruta IRR es una declaración RPSL construida sobre prefijo y origen. Auto-Manager usa la entrada de prefijo y no reproduce maxLength como una colección de objetos más específicos. La relación facilita coherencia; no convierte una declaración en la otra.

Por eso el punto de partida correcto es favorable: ARIN automatizó una coordinación estrecha, mantuvo salidas y evitó borrar la distinción entre registros. Lo que queda incompleto es la prueba visible de la operación que atraviesa ambos.

La mitad ROA ya tiene una historia útil

La documentación vigente describe un Origin AS/Prefix Pair Change Log para los ROA nuevos y modificados de una organización durante los 365 días anteriores. Cuando supera cien elementos, el registro se pagina. Las columnas incluyen marca de tiempo, operación Added o Removed, fuente Web User, API User o ARIN System, AS de origen, prefijo, longitud máxima y Changed By. El usuario puede solicitar por ticket un CSV completo; ARIN indica que revisará y responderá en dos días hábiles y que la descarga estará disponible durante 90 días.

Es una superficie bastante más valiosa que una lista del estado actual. Permite distinguir una acción en la web de una llamada de API o de una acción del sistema. Para una modificación, las filas de elementos retirados y añadidos describen el cambio sin inventar una etiqueta pública separada de “Modified”. Vinculan tiempo, origen y par AS/prefijo.

La documentación pública consultada no ofrece una descripción equivalente para las acciones sobre objetos IRR. El 11 de mayo de 2026, Randal Kohutek presentó esa observación mediante la sugerencia ACSP 2026.9. La redacción importa: el sistema IRR “no parece” incluir un registro comparable. No es una afirmación de que ARIN carezca de logs internos, historial de base de datos o controles de seguridad.

ARIN respondió el 19 de mayo. Aceptó que la función beneficiaría a los clientes que necesitan seguir acciones sobre objetos IRR, añadió la sugerencia a su hoja de ruta de seguridad de enrutamiento y la remitió a su proceso interno de priorización y planificación de implementación. Después cerró la sugerencia. Esa respuesta reconoce el problema con rapidez. No publica fecha, versión, esquema ni garantía de entrega, y no demuestra que la función ya esté disponible.

La igualdad de columnas no resuelve la procedencia

Un futuro registro IRR con fecha, fuente, usuario y acción eliminaría una asimetría evidente. Aun así, obligaría al operador a mirar dos secuencias y adivinar qué filas proceden de una sola intención.

Pensemos en la creación. El sistema puede descubrir un objeto coincidente que ya existía y dejarlo intacto o reemplazarlo. Un ROA con varios prefijos produce varios objetos. Pensemos luego en la salida. El objeto IRR puede borrarse de forma independiente. Si se borra el ROA, los objetos pueden desaparecer con él o permanecer como no administrados. Sync Up puede crear lo que falta o enlazar lo que ya está. En cada bifurcación, el mismo estado final puede tener más de una historia plausible.

La proximidad temporal ayuda a buscar, pero no prueba causalidad. Dos cambios simultáneos pueden pertenecer a operaciones distintas; una diferencia de varios minutos puede ser parte de un solo proceso. La ausencia posterior de un objeto no revela por sí sola quién eligió borrarlo ni si la otra mitad debía conservarse.

Esta incertidumbre tiene efectos profesionales aunque no exista un incidente conocido. Las ROA sirven como entradas firmadas para la validación del origen. Los datos IRR pueden alimentar generadores y revisiones de filtros de política. Ninguno de los registros demuestra qué ruta circuló en BGP ni qué filtro aplicó una red. Pero cuando sus estados divergen, el ingeniero necesita clasificar la diferencia: elección explícita, objeto previo, borrado independiente, correspondencia múltiple, resultado parcial o corrección.

No hace falta convertir esa necesidad en vigilancia pública. El objeto adecuado es un recibo de operación para la organización autorizada, con un esquema público y una divulgación limitada.

Seguir la operación en lugar de fusionar los registros

El recibo debería usar un identificador opaco y una marca de tiempo. Nombraría la superficie de inicio — ARIN Online, API RPKI, API IRR, Sync Up o ARIN System — y una clase de actor sin publicar innecesariamente un nombre. También registraría la organización autorizada y la intención: crear o modificar ROA, eliminarlo, crear o enlazar objeto IRR, reemplazar un objeto no administrado, borrar el objeto IRR, conservarlo sin administración o resincronizar.

La siguiente parte uniría los estados anterior y posterior. En el lado ROA: identificador, AS de origen, prefijo y maxLength. En el lado IRR: clave route o route6, prefijo, origen, condición administrada o no administrada y estado del vínculo. Cuando un ROA tenga varios prefijos, aparecería la cardinalidad. Cuando ya existiera un objeto, el recibo diría si se reutilizó, se reemplazó o se dejó intacto.

La decisión de salida debe ser explícita. Borrar ROA y objetos vinculados no es lo mismo que borrar el ROA y conservar los objetos. El sistema no debería exigir que un operador infiera esa elección a partir de una ausencia. Un resultado fallido o parcial tendría su propia clase. Una corrección apuntaría al recibo sustituido para que el estado actual no destruya la explicación histórica.

ARIN podría guardar internamente campos más sensibles. El titular autorizado no necesita ver credenciales ni el historial de otra organización, y el público no necesita identidades personales permanentes. Basta con un recibo estructurado para la parte legitimada, reglas de conservación y exportación conocidas y un esquema versionado que permita interpretar el registro en el futuro.

La virtud del diseño actual consiste en coordinar sin confundir y automatizar sin encerrar. ACSP 2026.9 señala con precisión el próximo paso. La implementación más útil no se limitaría a duplicar las columnas del historial ROA: ofrecería una identidad operacional común para demostrar cuándo dos cambios nacieron de una sola decisión y cuándo siguieron caminos independientes.

Fuentes