IPv4 tiene un ciclo de vida: qué pueden y qué no pueden mostrar los datos del registro
Una guía en lenguaje sencillo sobre el ciclo de vida de IPv4: transferencias, reutilización, enrutamiento, RPKI, arrendamiento, historial y lo que los datos del registro no pueden mostrar.
El titular registrado, el usuario operativo, la ruta y el historial son distintas perspectivas de un mismo recurso de direcciones. Ningún registro individual cuenta toda la historia.
La escasez de IPv4 ya no lo explica todo. La pregunta más útil es qué le ocurre a un bloque de direcciones después de haber sido asignado.
Un bloque puede transferirse, dividirse, ser anunciado por otra red, quedar cubierto por una autorización de enrutamiento distinta, arrendarse a otro operador y volver a transferirse. El número puede seguir siendo el mismo mientras cambian las organizaciones, las redes, la geografía y las pruebas que lo rodean.
Este artículo ofrece una forma de interpretar ese cambio. Separa cuatro preguntas que a menudo se reducen a una: quién figura en el registro, quién opera el recurso, qué ASN origina su ruta y qué pruebas explican si el estado actual está autorizado y mantiene la continuidad.
Empiece por cuatro preguntas distintas
Un asiento del registro responde a una pregunta registral: ¿qué organización está reconocida para este recurso según las reglas del registro? Por sí solo, no responde a quién utiliza hoy el recurso, adónde se enruta el tráfico ni qué red está autorizada para originarlo.
- Estado del registro: el titular que figura en el registro y su relación con el recurso.
- Estado operativo: la organización, el proveedor o el cliente que utiliza realmente el bloque.
- Estado del enrutamiento: el ASN que se observa actualmente como origen del prefijo en BGP.
- Autorización e historial: las ROA, los objetos IRR, los registros de transferencias y el historial de cambios que explican el estado.
Estas capas pueden cambiar juntas, pero no tienen por qué hacerlo. Mantenerlas separadas es el primer paso para comprender los datos.
Qué muestran los datos de 2026
Las cifras de 2026 de este artículo son observaciones acumuladas en lo que va de un año todavía incompleto. Las cifras mensuales publicadas por RIPE NCC de enero a julio suman aproximadamente 16,72 millones de direcciones IPv4 transferidas en su región de servicio. Un solo mes con mucho volumen puede cambiar el total, de modo que esto demuestra que el movimiento continúa, no constituye una previsión para el año completo.
La perspectiva a más largo plazo es igual de importante. El análisis de APNIC de los datos mundiales de los RIR contabilizó 33,4 millones de direcciones IPv4 en 5619 operaciones de transferencia registradas en 2025. Estimó que alrededor de 342 millones de direcciones habían aparecido en los registros de transferencias de los RIR desde 2012. Algunas direcciones aparecen más de una vez, lo que demuestra por sí mismo que una dirección puede tener más de una transición registrada.
Por tanto, el historial de transferencias cuenta una historia de movimiento después del agotamiento. No cuenta toda la historia del uso actual.
La asignación ha dado paso a la reutilización
Cuando era fácil obtener espacio sin utilizar, el modelo mental era sencillo: un registro asignaba un bloque y una red lo ponía en servicio. En un mercado IPv4 maduro, un bloque existente puede, en cambio, pasar de una organización a otra y adquirir una nueva vida operativa.
Un prefijo de veinte años de antigüedad puede tener ahora un titular, un proveedor, un ASN de origen, una organización del DNS inverso, un contacto de abuso y una configuración RPKI distintos de los asociados a su asignación original. El número de la dirección es estable, pero la infraestructura que lo rodea no lo es.
Por eso el asiento actual necesita su historial. El titular presente es importante, pero solo constituye un momento en la vida del recurso.
Un bloque grande puede dar lugar a varios historiales
Las transferencias también pueden cambiar la unidad que se gestiona. Un bloque que comenzó como un /16 puede aparecer después como recursos más pequeños, como /18, /18, /19 y /20. Cada prefijo resultante puede adquirir su propio titular, ruta, ROA, DNS inverso, usuario operativo e historial posterior de transferencias.
Los registros de transferencias publicados son útiles porque preservan el recurso documentado y su transición. Deben leerse como un historial de cambios de estado, no como una promesa de que la asignación original siga siendo la única unidad operativa relevante.
La geografía del registro no es la geografía del enrutamiento
Una dirección puede pasar de una región de registro a otra sin que los paquetes se trasladen inmediatamente a un nuevo país. Una transferencia en el registro cambia la relación administrativa reconocida. BGP describe cómo se anuncia la accesibilidad. La geolocalización IP describe otra inferencia distinta.
Esas tres descripciones pueden apuntar en direcciones diferentes sin que ninguna sea errónea. Tratar como intercambiables el país que figura en el registro, la sede de una empresa, la ubicación de un centro de datos y el origen de una ruta genera una falsa certeza.
El arrendamiento y la delegación añaden otra capa
Un arrendamiento o una delegación operativa pueden permitir que otra organización utilice y anuncie un bloque mientras el titular registrado permanece sin cambios. Un registro de transferencias puede no mostrar ningún nuevo titular aunque hayan cambiado el usuario operativo, el proveedor, el DNS inverso, los contactos y la reputación.
Por eso los datos de transferencias miden transiciones registrales documentadas, no todos los cambios de uso. Una investigación completa necesita reunir el asiento del registro, la autorización operativa y las pruebas de enrutamiento.
RPKI da a la ruta su propio estado de seguridad
Cuando cambia el ASN de origen previsto, deben revisarse las autorizaciones de origen de ruta pertinentes. Un registro puede documentar correctamente a un titular mientras la ROA correspondiente sigue reflejando una autorización de enrutamiento antigua. A la inversa, una ROA válida no demuestra que la ruta se esté anunciando en ese momento.
Lea las capas en orden: el registro declara la relación reconocida, RPKI declara una autorización y BGP muestra la ruta que observan las redes. Cada una responde a una pregunta distinta.
Qué no pueden demostrar los datos del registro
Un registro de transferencia no revela el precio de la operación, el motivo comercial del cambio, todos los arrendamientos, todas las delegaciones ni el historial completo del enrutamiento. Los RIR también publican datos con definiciones y calendarios distintos.
La conclusión prudente es, por tanto, más acotada y más sólida: los datos del registro ofrecen una perspectiva verificada de transiciones de estado importantes que han quedado documentadas. BGP, RPKI, los registros IRR, los contratos y los registros operativos ofrecen otras perspectivas. La confianza surge de compararlas, no de forzar a un único conjunto de datos a responder todas las preguntas.
Una documentación práctica del ciclo de vida
Para un prefijo importante para un negocio en funcionamiento, mantenga una documentación que otro operador pueda comprobar:
- el titular actual en el registro y el historial de transferencias pertinente;
- el usuario operativo, el proveedor y los contactos actuales;
- el ASN de origen y los cambios históricos de ruta;
- las ROA, los objetos IRR y la responsabilidad sobre el DNS inverso;
- los cambios sustanciales, las aprobaciones y las pruebas de control; y
- el plan de continuidad o de salida si la relación vuelve a cambiar.
Esto es gestión del ciclo de vida. Es la respuesta práctica a una Internet en la que identificadores antiguos siguen pasando por nuevas organizaciones y redes.
Continúe por las tres capas
El siguiente artículo sigue la capa del registro a través de los límites entre RIR. El tercero sigue un tipo de cambio distinto: un prefijo que conserva su número mientras cambia su ASN de origen en BGP.