Resumen

  • APNIC sitúa en el tercer trimestre de 2026 una iniciativa para automatizar la alineación entre gestión de rutas, tenencia de recursos, Whois y RPKI cuando hay transferencias, desasignaciones o cambios de sistema.
  • Cada superficie responde a una pregunta distinta. La tenencia establece autoridad administrativa; el objeto de ruta IRR declara política; la ROA autoriza un origen; BGP muestra una ruta observada cuya aceptación depende de cada red.
  • La ficha pública no explica la precedencia, el límite de la transacción, el estado de un éxito parcial, las notificaciones ni la vuelta al último estado seguro. No es prueba de que APNIC carezca de un diseño interno, sino de que el contrato público sigue incompleto.
  • Una matriz por tipo de registro y un recibo versionado de cada tarea permitirían reducir la reconciliación manual sin convertir diferencias legítimas en datos que el sistema borra por error.

La escena que una casilla verde no puede describir

El titular de un bloque acaba de cambiar. El objeto Whois del registro de origen debe retirarse. La nueva organización piensa conservar durante unas horas el mismo AS y migrar después a otra procedencia. Una ROA ha sido preparada, otra sigue visible en algunos cachés y los filtros de varios proveedores aún reflejan el IRR anterior. Ningún elemento aislado describe mal la realidad; cada uno ocupa un momento y una función diferentes.

No se trata de un incidente observado en APNIC. Es un escenario analítico que muestra lo que encierra la expresión “Route management alignment” de su hoja de ruta. La iniciativa pertenece al equipo Registry, menciona ARMS, RPKI y Whois y tiene como objetivo el T3 de 2026. APNIC propone automatizar la coordinación con la tenencia de recursos para reducir tareas manuales tediosas y propensas a errores después de transferencias, desasignaciones y cambios de sistema.

El beneficio es claro. Introducir la misma intención en varias superficies genera retrasos y equivocaciones. Pero la palabra alinear puede esconder dos proyectos opuestos. Uno reconoce que los registros tienen significados diferentes y coordina sus transiciones. El otro escoge una base como maestra y fuerza a las demás a parecerse. El primero reduce trabajo conservando la semántica. El segundo produce orden visual a costa de información.

La ficha estructurada capturada contiene año, trimestre, equipo, productos, resumen y solución propuesta. Su changelog está vacío. No nombra una jerarquía para resolver conflictos, un perímetro transaccional, un estado de fallo parcial, una regla de rollback, un aviso al operador, ni los límites frente a un National Internet Registry o un IRR externo. APNIC podría tener esos elementos en documentación no pública. La observación legítima es más pequeña: todavía no acompañan a la promesa visible.

El mapa contiene cuatro clases de autoridad

La tenencia de recursos pertenece al registro. Responde quién está reconocido para controlar un conjunto de direcciones o un ASN y, por tanto, quién puede solicitar determinadas operaciones. Cambiar la tenencia puede revocar credenciales anteriores. No revela por sí mismo el origen que debe anunciar una ruta ni cuándo hacerlo.

Un objeto route o route6 en un Internet Routing Registry cumple otra función. APNIC describe el IRR como una red distribuida de bases donde los operadores publican políticas y anuncios para que otros puedan construir filtros y configuraciones. RFC 2725 exige autorización tanto sobre el prefijo como sobre el AS de origen. También admite que un mismo prefijo tenga varios orígenes por multihoming y que existan más específicos superpuestos, cambios de proveedor y periodos de renumeración.

La pluralidad puede ser diseño, no suciedad. Una empresa puede autorizar dos orígenes para resiliencia. Un proveedor puede conservar un objeto durante una transición pactada. Una red puede anunciar sólo una parte de lo que su política preparada permite. Resolver toda diferencia con una regla de unicidad sería una “reparación” peligrosa.

RPKI responde a una tercera pregunta. RFC 9582 define la ROA como un objeto firmado por el titular del espacio que autoriza a un AS a originar rutas para unos prefijos. Si se quieren autorizar varios AS, se emiten varias ROA. La firma aporta integridad y vincula la autorización a la cadena de recursos. No certifica que la ruta esté anunciándose ahora, que tenga conectividad o que un router concreto la prefiera.

BGP aporta la cuarta clase: observación operativa. RFC 6483 toma el prefijo y el origen de una ruta recibida y los contrasta con las ROA válidas para producir los estados Valid, Invalid o Unknown. El propio RFC deja a la política local la decisión sobre qué hacer con Unknown e Invalid. APNIC puede gestionar autorizaciones y objetos de política; no controla la decisión final de cada red.

El mismo RFC advierte que la propagación de los objetos RPKI puede tener un ritmo diferente al de las rutas. Por eso un intervalo de diferencia no demuestra automáticamente una incoherencia que deba borrarse. Puede mostrar un despliegue en curso, un respaldo preparado o un caché pendiente de actualización.

El predecesor de 2017 ya separaba intención y publicación

El antiguo Route Management Guide de APNIC permite reconstruir cómo se planteaba antes el problema. El documento data de 2017 y no debe presentarse como la especificación actual de la iniciativa 2026. Su valor está en que hace visible una decisión de diseño que podría perderse con una automatización demasiado ambiciosa.

En aquella interfaz, una “ruta” de MyAPNIC era una plantilla para crear un objeto de ruta real en Whois. Las dos entidades podían existir por separado. Podía haber plantilla sin objeto público u objeto público sin plantilla gestionada. Si el objeto Whois cambiaba por otra vía, la plantilla no absorbía la modificación. El sistema mostraba un conflicto y el usuario decidía entre aceptar el cambio o devolver el objeto a lo indicado por MyAPNIC.

La discrepancia funcionaba como señal. Informaba de que otro canal, posiblemente legítimo, había actuado sobre el registro público. Preservaba la intención anterior el tiempo suficiente para compararla con la nueva. Ese gesto es más importante que el diseño concreto de la pantalla: evita que la reconciliación destruya el hecho de que hubo una decisión.

El manual también describe estados pending al sincronizar varios objetos. Permite crear ROA coincidentes cuando el usuario tiene permisos y activa la opción. En una operación concreta, deshabilitar una subruta gestionada cuya ROA estaba activa eliminaba también esa ROA. Es decir, ya entonces había distintos dominios de permisos, ejecución en segundo plano, acoplamiento opcional y consecuencias cruzadas.

No sabemos cuáles de esas reglas conserva el nuevo trabajo. La hoja de ruta no lo dice. Sí sabemos que el problema histórico no era sólo mantener dos cadenas idénticas. Era decidir qué hacer cuando la intención gestionada y el objeto publicado tomaban caminos distintos.

La API reconoce que no todo cabe en una transacción

En 2024 APNIC anunció una Registry API capaz de consultar información de delegación y gestionar Whois, DNS inverso, ROA y objetos de ruta. Como ejemplo, describió la creación automática de una ROA y un objeto de ruta al añadir un anuncio BGP, en lugar de repetir el proceso manualmente en MyAPNIC.

El anuncio matiza el mecanismo. Whois permite recuperar y actualizar objetos individuales. La gestión abstracta de rutas y DNS inverso admite lotes que se aplican “transactionally where possible”. Todas las actualizaciones son tareas asíncronas: se recibe un enlace, se consulta el estado y al final se obtienen detalles del resultado.

La frase “donde sea posible” es la frontera que una futura ficha de alineación debe dibujar. Dos escrituras en la misma base pueden compartir commit. Publicar un objeto RPKI y esperar a que lo vean caches independientes no es lo mismo. Un IRR externo, el sistema de otro RIR y la política BGP de una red quedan fuera de la transacción local.

Por tanto, una tarea puede tener varios finales parciales. Si Whois cambia y la publicación RPKI prevista no concluye, repetir toda la petición sin saber qué commit sobrevivió puede duplicar, retirar o contradecir información. Un estado genérico Error no ofrece base suficiente para operar. Hacen falta resultados por etapa, una clave de repetición segura, el último estado coherente y, cuando corresponda, una acción compensatoria.

No se ha probado aquí un fallo de la API. La evidencia de 2024 sirve para otra cosa: demuestra que APNIC ya habla públicamente de lotes, transacciones condicionadas, tareas asíncronas y resultados. Es un vocabulario adecuado para explicar el nuevo control.

La transferencia no entrega automáticamente una política de rutas

Las condiciones vigentes de APNIC especifican que, en una transferencia inter-RIR saliente, se eliminan de la base Whois los objetos asociados al recurso, incluidos subasignaciones, objetos de ruta y objetos de dominio. Cuando el proceso termina, la entidad de origen deja de tener derechos y los recursos quedan registrados para el receptor.

La cláusula citada no menciona qué ocurre con las ROA. No es correcto añadir esa afirmación. La ausencia es útil porque separa dos actos: retirar la autoridad y los objetos Whois del lado de origen no basta para definir la autorización RPKI que desea el nuevo titular.

Supongamos que el receptor conserva el mismo origen. Cambia la autoridad registral, no necesariamente la intención de enrutamiento. Supongamos que cambia de AS: quizá convenga publicar la nueva autorización antes de apagar el camino anterior. Supongamos que el destino está en otro RIR: el borrado del registro de origen y la aparición de los objetos de destino obedecen a relojes y controles distintos. Son posibilidades de diseño, no denuncias de sucesos reales.

Una política que borre primero todo lo dependiente puede crear un periodo Invalid o NotFound evitable. Una política que conserve indefinidamente la configuración anterior mantiene residuos de autoridad. Una política que copie el BGP observado convierte una ruta presente en autorización futura sin una decisión del titular. Cada atajo confunde una clase de prueba con otra.

El sistema necesita distinguir al menos prepared, committed, published, observed y expired. Prepared indica que existe un cambio autorizado aún no efectivo. Committed marca la modificación dentro del registro. Published dice que el objeto está disponible en su superficie. Observed confirma una comprobación independiente. Expired retira la confianza del estado antiguo. Llamar a todos simplemente aligned borra información operativa.

Tres pruebas que deberían fallar de forma controlada

La primera prueba introduce una caída entre Whois y RPKI. La tarea intenta modificar ambos, pero sólo una escritura concluye. El resultado correcto no es esconder el estado híbrido; es aislarlo, impedir una repetición destructiva, avisar al operador y mostrar la acción de recuperación.

La segunda conserva dos orígenes legítimos. El motor debe reconocer que multiplicidad y conflicto no son sinónimos. Debe comprobar autoridad y alcance de prefijo sin reducir por defecto la política a un único AS. La prueba pasa si las diferencias permitidas quedan declaradas, no si todos los campos terminan iguales.

La tercera atraviesa una frontera. Un NIR, otro RIR o un IRR externo mantiene parte de la información. APNIC puede registrar su propia operación y verificar observaciones, pero no puede fingir un commit distribuido que controle a todas las partes. El recibo debe decir qué quedó fuera, quién es responsable y cuál es el plazo de espera antes de escalar.

Una cuarta prueba temporal debería invertir el orden de propagación: primero se observa la ruta y después llega la ROA, o viceversa. El sistema no debe perseguir el desfase reescribiendo autorizaciones. Debe esperar según una política publicada y distinguir demora de contradicción persistente.

Estas pruebas son más informativas que una demostración ideal. Una pantalla sin errores demuestra que el camino feliz funciona una vez. Un fallo inducido revela si el sistema sabe preservar autoridad, evidencia y capacidad de reversión cuando las capas dejan de avanzar juntas.

No hay una sola fuente de verdad, sino una fuente para cada pregunta

La expresión single source of truth suele esconder la decisión que debería exponer. La tenencia puede ser fuente de verdad para saber quién está facultado. Una solicitud autenticada y autorizada puede ser fuente de intención. El objeto IRR publica política. La ROA acredita permiso de origen. BGP muestra comportamiento. Elegir una de ellas como maestra absoluta equivaldría a responder cuatro preguntas con el mismo dato.

APNIC podría publicar una matriz breve. Para cada disparador —transferencia, desasignación, edición directa de Whois, cambio en la plantilla de rutas, modificación de ROA o migración técnica— indicaría actor autorizado, precondiciones, registros afectados, diferencias permitidas, pasos automáticos, motivos de revisión y ventana de oposición.

La matriz debería tener una columna de atomicidad. Allí constaría qué escrituras comparten transacción, cuáles se publican después, cuáles dependen de terceros y qué significa una tarea incompleta. Otra columna definiría la precedencia por tipo: la tenencia puede retirar capacidad de gestión; no debe inventar el AS elegido por el receptor. Un BGP visible puede disparar una alerta; no debe crear por sí solo una ROA.

También es imprescindible el aviso. La automatización ahorra clics precisamente porque toma decisiones en nombre del usuario. Cuando esas decisiones cambian objetos utilizados para filtros o validación, el ahorro no justifica el silencio. La persona o función responsable debe recibir el estado anterior, el estado propuesto, la autoridad invocada, el motivo y la vía de revisión. Las urgencias pueden acortar el plazo, no eliminar la constancia.

Un recibo que sobreviva a la vuelta atrás

El recibo de alineación empezaría con un identificador de evento y tarea, el tipo de disparador y el instante relevante. Incluiría la fotografía de tenencia con la que se verificó al solicitante. Después mostraría, por separado, la plantilla de rutas, los objetos Whois y las ROA antes y después de la operación.

Cada modificación llevaría un código de regla y una explicación de precedencia. El recibo declararía el límite transaccional: qué commits fueron conjuntos, qué publicación seguía pendiente y qué sistema estaba fuera del control de APNIC. Si sólo una etapa terminó, identificaría la última posición segura, la condición de reintento, la cuarentena y la acción compensatoria.

Los tiempos de visibilidad no deberían reducirse a la hora de envío. Harían falta la primera consulta Whois correcta, la publicación RPKI y una observación independiente de validación. BGP podría figurar como evidencia contextual, nunca como mandato. Transferencias, desasignaciones, NIR e IRR externos serían indicadores explícitos de alcance.

El aviso enviado, la recepción, la ruta de revisión, el propietario del servicio y el rollback quedarían registrados. Volver al estado anterior no borraría la tarea; añadiría un nuevo resultado conectado con el original. Así la reversión corrige el servicio sin destruir la historia.

Este recibo es una recomendación de este artículo, no una función que APNIC haya prometido. Puede omitir claves, credenciales y datos personales. Su cometido es más limitado: demostrar qué autoridad se usó, qué cambió, qué no cambió, qué falló y cómo puede revisarse.

La automatización no es el adversario. La opacidad de su criterio sí lo es. APNIC puede eliminar trabajo manual y, al mismo tiempo, reconocer que una base ordenada no basta para demostrar una decisión correcta. Antes de alinear los registros, debe publicar el orden de los conflictos.

Fuentes