Resumen

  • La política de APNIC puede demostrar que la titularidad registrada de un ASN pasó del origen al receptor, pero no demuestra por sí sola el estado de cada superficie de enrutamiento o autorización que usa ese número.
  • El registro de entrega debe separar hechos registrales, actos autenticados, objetos publicados y observaciones BGP, y enlazarlos con tiempos y huellas anteriores y posteriores.
  • Las fuentes públicas no prueban que todo ASN transferido esté activo en BGP, tenga un objeto IRR aut-num o aparezca en una ROA; hacen falta estados explícitos de «no aplica», «no observado» y «desconocido».

Un ASN parece una etiqueta portátil: se ve como un número y puede consultarse sin observar los routers que lo usan. Sin embargo, su significado operativo no es meramente numérico. La RFC 1930 define un sistema autónomo como un grupo conectado de prefijos operado bajo una política de enrutamiento única y claramente definida. El número identifica ese dominio de política ante el resto de Internet.

La diferencia importa cuando cambia el titular registrado. La política vigente de APNIC permite transferir ASN entre titulares de recursos de APNIC y, cuando el registro contraparte mantiene una política compatible, entre regiones. En una transferencia dentro de APNIC, el origen debe ser el titular registrado y no estar inmerso en una disputa sobre el recurso. El receptor queda sujeto a las reglas vigentes y debe satisfacer los criterios para recibir un ASN.

APNIC describe la transferencia como el movimiento de recursos numéricos de una entidad jurídica a otra y afirma que actualiza su base Whois para reflejar el resultado. Su procedimiento entre cuentas separa dos actos: el origen inicia la solicitud en MyAPNIC y el receptor la reconoce. Esos actos sostienen una decisión registral importante. No prueban automáticamente que políticas, credenciales, objetos y rutas hayan cambiado de forma coordinada.

El límite de la evidencia debe quedar visible. Un ASN puede transferirse sin estar anunciado. No todos tienen necesariamente un objeto aut-num en un registro de enrutamiento. Una ROA la emite el titular de un prefijo para autorizar un ASN de origen, de modo que recibir el ASN no concede autoridad sobre el espacio de direcciones. Una ruta observada demuestra uso en un momento y punto de medición; no demuestra titularidad ni autorización.

La primera sección del registro de entrega corresponde a la decisión del registro. Conserva un identificador estable, el ASN exacto, las cuentas de origen y receptor reconocidas, la versión de política, los recibos de inicio y aceptación, el estado y la hora efectiva. En una transferencia inter-RIR añade el registro contraparte, la base de compatibilidad y las referencias de cierre de ambas regiones. Los términos comerciales pueden ser confidenciales sin eliminar este expediente de control.

La segunda sección es una pareja de instantáneas registrales. La RFC 9082 define la consulta RDAP autnum para datos de registro de sistemas autónomos. Una lectura inmediatamente anterior y otra posterior pueden mostrar qué devolvía el servicio público. Cada una debe preservar consulta, hora de observación, identidad del servicio y huella de la respuesta. Una corrección posterior crea una nueva observación; no sustituye silenciosamente la prueba usada en la entrega.

La tercera sección describe la identidad de política. El receptor declara si mantendrá la política externa, aplicará una transición o retirará el ASN. Si existe un objeto IRR aut-num, el registro identifica base fuente, clave, mantenedores y huellas de la versión anterior y posterior. No marca «actualizado» sin un recibo atribuible y una lectura de control. Si el objeto no existe, la respuesta honesta es «no observado» o «no aplica».

La cuarta sección inventaría las autorizaciones de origen que mencionan el ASN. Los titulares de los prefijos conservan la autoridad sobre sus ROA. La RFC 6907 recomienda una secuencia de preparación antes de ruptura para crear y revocar objetos RPKI durante transferencias. La RFC 8206 muestra que una migración de ASN puede exigir nuevas ROA para las rutas que pasan al número de reemplazo. Por ello, cada dependencia conocida necesita autoridad responsable, estado anterior y posterior, prueba de publicación y observación de validación.

La quinta sección registra operación observada. Si el ASN seguirá activo, observaciones BGP acotadas pueden conservar su presencia como origen, caminos relevantes y ventanas de transición. Siguen siendo observaciones: la ausencia en un colector no prueba inactividad global y la presencia no prueba autorización. Mantener separadas esas afirmaciones hace que el registro sea comprobable.

Un modelo de estados simple ordena la secuencia. REQUESTED indica recepción de la solicitud. SOURCE_CONFIRMED y RECIPIENT_ACKNOWLEDGED son actos atribuibles. REGISTRY_EFFECTIVE representa el cambio de titular registrado. DEPENDENCIES_IN_TRANSITION mantiene abiertos los objetos, contactos o permisos identificados. HANDOVER_OBSERVED significa que el estado operativo previsto fue contrastado con un plan definido. EXCEPTION_OPEN conserva una diferencia material con responsable y siguiente acción.

El criterio de cierre depende del caso. Para un ASN sin uso, la actualización registral y de contactos puede bastar, dejando las dependencias de enrutamiento como no aplicables. Para uno activo, el cierre puede requerir política declarada, custodia de credenciales, conciliación de objetos IRR utilizados, revisión de dependencias ROA y una ventana de observación. Fijar el criterio antes del cierre evita convertir después una prueba ausente en un éxito supuesto.

Este diseño no pide al registro certificar todo el sistema de enrutamiento. APNIC sigue siendo autoridad de su decisión; los titulares de prefijos, de sus ROA; los operadores IRR, de los objetos que publican; las redes, de sus routers; y los colectores, de sus observaciones. El registro de entrega conecta esas autoridades sin confundirlas: quién afirmó qué, cuándo se observó y qué continúa desconocido.

Fuentes