Reubicación en BGP: por qué un prefijo IPv4 cambia de ASN de origen
Por qué un prefijo IPv4 puede cambiar de ASN de origen sin cambiar de titular y cómo comprobar el estado de BGP, RPKI, IRR y el registro.
El bloque de direcciones puede seguir siendo el mismo cuando cambia la red que origina su anuncio. El enrutamiento, la autorización y los datos del titular cumplen funciones distintas.
Un prefijo IPv4 puede conservar la misma numeración y, aun así, parecer que se ha trasladado a otra red. En BGP, ese cambio suele manifestarse como un nuevo ASN de origen.
Esto se denomina reubicación en BGP, o BGP rehoming. Es una observación sobre el estado del enrutamiento. Por sí sola, no demuestra que haya cambiado el titular registrado, que el prefijo se haya trasladado a otro país ni que se haya producido una transferencia de direcciones.
Empezar por la ruta
Si un colector de rutas observa 203.0.113.0/24 → AS64500, está viendo que AS64500 origina la ruta en ese momento. Si el mismo prefijo aparece más adelante como 203.0.113.0/24 → AS64550, el ASN de origen ha cambiado.
Aquí, el término ASN de origen se refiere al ASN situado en el extremo de origen de la ruta de sistemas autónomos observada. No debe confundirse con el atributo ORIGIN de BGP, que es un atributo distinto definido en el RFC 4271.
Qué muestran los datos recientes
En su comparación de las instantáneas de enrutamiento de principios de 2025 y principios de 2026, APNIC contabilizó 29.699 prefijos IPv4 cuyo ASN de origen había cambiado. Su tabla comparativa de transferencias recoge 1.991 prefijos reubicados que aparecen en los registros de transferencias y 26.722 que no aparecen en ellos. Esas cifras suman 28.713, es decir, 986 menos que el total de prefijos reubicados indicado. El texto que acompaña a la tabla también menciona cambios de enrutamiento en 2024 y registros de transferencias de 2023–2024, mientras que el texto circundante describe cambios en 2025 y registros de 2024–2025. Por tanto, las cifras y las referencias temporales publicadas no ofrecen un desglose anual plenamente coherente.
La comparación no demuestra que los prefijos sin correspondencia en esos registros se transfirieran de forma indebida. Muestra por qué no debe tratarse el historial de enrutamiento y el historial del registro como si fueran un mismo conjunto de datos. Muchos cambios legítimos en la red no requieren un cambio de titular registrado.
Por qué cambia un ASN de origen
Hay varias explicaciones operativas habituales:
- una empresa cambia de proveedor de tránsito o de alojamiento;
- la infraestructura se traslada a otro centro de datos o a otra red en la nube;
- un cliente comienza a originar anuncios a través de su propio ASN, recién obtenido;
- una red corporativa se fusiona, se divide o se reestructura;
- un titular delega el enrutamiento en otro operador o proveedor de alojamiento; o
- la arquitectura de enrutamiento cambia mientras la relación registral se mantiene estable.
Cada explicación necesita pruebas. La ruta por sí sola muestra qué se está anunciando, pero no por qué ha cambiado ni quién ha autorizado el cambio.
La reubicación y la transferencia de IPv4 responden a preguntas distintas
La reubicación en BGP plantea esta pregunta: ¿qué ASN está originando el anuncio de este prefijo?
Una transferencia de IPv4 plantea esta otra: ¿ha cambiado la relación reconocida por el registro?
Ambos acontecimientos pueden producirse al mismo tiempo. También pueden ocurrir por separado. Un titular puede cambiar de proveedor sin transferir el recurso, y una relación registral puede cambiar mientras el mismo proveedor sigue originando la ruta.
BGP aporta pruebas del enrutamiento, pero no demuestra por completo el control
Observar que AS64550 origina el anuncio de un prefijo no demuestra automáticamente que AS64550 sea su propietario, sea el titular registrado, pueda transferirlo o tenga autorización permanente para anunciarlo. Un arrendamiento, un acuerdo con un cliente, una migración temporal o un error podrían dar lugar a la misma observación.
Para entender quién ejerce el control, hay que contrastar la ruta con los datos del registro, la autorización operativa y las pruebas que explican la relación. Esta es la razón práctica para mantener la distinción entre el control del enrutamiento, el control registral y las relaciones comerciales.
RPKI incorpora la autorización
Una autorización de origen de ruta, o ROA, declara que un ASN concreto está autorizado para originar el anuncio de un prefijo dentro del sistema RPKI. El RFC 9582 define el perfil vigente de las ROA.
Cuando el origen cambia de AS64500 a AS64550, el nuevo estado previsto debe reflejarse en la ROA correspondiente. Una ROA válida no demuestra que la ruta se esté anunciando en ese momento, y una ruta observada no demuestra que el anuncio esté autorizado. BGP y RPKI aportan pruebas complementarias.
El IRR y el DNS inverso forman parte de la migración
Los proveedores pueden utilizar objetos de ruta del IRR para crear filtros. Los clientes pueden depender del DNS inverso, las listas de permitidos, la monitorización y los sistemas de reputación. Por tanto, una migración de enrutamiento puede requerir varias actualizaciones coordinadas, aunque el titular registrado siga siendo el mismo.
Un registro operativo útil identifica cada capa: el estado del registro, el origen BGP, la autorización RPKI, la política del IRR, la responsabilidad sobre el DNS inverso, los contactos y el registro interno del cambio.
Qué comprobar cuando cambia el origen
Antes del cambio
- anotar los prefijos exactos y el ASN de origen actual;
- confirmar el nuevo ASN previsto y el operador autorizado;
- revisar las ROA, los objetos del IRR, el DNS inverso y la preparación del proveedor; y
- conservar las pruebas del estado actual de BGP y del registro.
Durante la migración
- observar la propagación y los cambios de origen desde varias redes;
- comprobar la validación RPKI y los anuncios de prefijos más específicos; y
- comprobar que la ruta anterior desaparezca allí donde el cambio lo requiera.
Después de la migración
- verificar que el ASN previsto esté originando el anuncio del prefijo;
- confirmar que las ROA, el IRR y el DNS inverso se correspondan con el estado previsto;
- comprobar los datos del registro y los contactos; y
- guardar las pruebas para que el siguiente operador pueda reconstruir el cambio.
¿Un origen inesperado implica un secuestro de rutas?
No necesariamente. Merece una investigación, pero la primera pregunta debe ser si el cambio estaba autorizado. Entre las posibles explicaciones se encuentran una migración de proveedor, un mantenimiento temporal, el enrutamiento por parte de un cliente, un nuevo ASN, una delegación operativa, un error de configuración o un anuncio no autorizado.
Antes de atribuir una causa, hay que consultar el historial de BGP junto con los datos del registro, las ROA, la información del IRR, la documentación del proveedor y los registros internos de cambios. Una etiqueta precipitada puede ocultar el verdadero problema operativo.
Por qué esto importa para la portabilidad
Los recursos IPv4 sobreviven cada vez más a cambios de proveedores, centros de datos, estructuras corporativas, ASN y usuarios operativos. Por tanto, la portabilidad va más allá de permitir que la dirección conserve la misma numeración. Los sistemas que la rodean deben preservar la unicidad, la autorización, la exactitud de los registros, la seguridad y la continuidad mientras cambia la red.
La continuidad de la IP pública depende de esta capa práctica. El DNS, los controles de acceso, las listas de permitidos de los socios, las VPN y la monitorización pueden depender de una dirección, aunque los cambios en el registro y el enrutamiento parezcan administrativos.
La red en funcionamiento es la prueba definitiva
Los datos del registro, RPKI, los objetos del IRR y las observaciones de BGP son instrumentos distintos al servicio de una red en funcionamiento. El objetivo de una reubicación legítima es sencillo: realizar el cambio de enrutamiento necesario manteniendo la red accesible, debidamente autorizada y con un funcionamiento que pueda explicarse.