Number Resource Society

IPv4 legacy: cómo comprobar su historia, sus derechos y las condiciones de transferencia

Un bloque histórico puede sostener una red moderna y arrastrar décadas de cambios administrativos. Qué verificar sobre la asignación original, la sucesión empresarial, los acuerdos y la continuidad de los servicios antes de comprometerte.

Ann YongPrimera publicación 27 de octubre de 2026Actualizado 28 de octubre de 2026

En esta página

Esta edición se ha reelaborado a partir del artículo de Ann Yong y conserva su fecha de publicación original. La revisión del 28 de octubre de 2026 distingue las reglas vigentes de las reformas que propone NRS; las fuentes se comprobaron ese mismo día.

Un bloque IPv4 puede haber pasado por varias adquisiciones, nombres de empresa y equipos de administración sin dejar de funcionar. Sus registros no siempre han seguido el mismo camino. Antes de comprarlo, transferirlo o apoyar servicios críticos sobre él, necesitas reconstruir el vínculo entre quien lo recibió originalmente y quien lo controla hoy. Legacy describe una historia particular del recurso. No elimina la necesidad de acreditar derechos, entender las reglas aplicables y preparar el siguiente cambio.

Legacy describe el origen, no simplemente la antigüedad

Suele hablarse de recursos IPv4 legacy, o históricos, cuando se obtuvieron antes de la estructura jerárquica moderna de los RIR, o fuera de ella. El registro del espacio IPv4 de IANA identifica como LEGACY determinados espacios procedentes de los primeros mecanismos centrales, hoy administrados por registros regionales. La definición del RIPE NCC también remite a un origen ajeno al sistema actual de asignación. El tratamiento de un bloque concreto debe comprobarse con su registro responsable.

Que una dirección lleve muchos años en uso no basta para clasificarla como legacy. Tampoco la edad de la empresa o de sus equipos. Lo relevante es cómo se obtuvo el recurso y qué estado tiene hoy.

Las primeras asignaciones siguen formando parte de Internet

La estructura de los RIR se desarrolló gradualmente a medida que crecía Internet. Empresas, universidades y otras organizaciones ya habían recibido recursos mediante mecanismos centrales anteriores. Cuando ARIN se creó en diciembre de 1997, en su región ya existían recursos asignados. La reorganización del sistema no hizo desaparecer esas asignaciones.

La dirección, la red que la utiliza y el organismo que conserva sus registros pueden tener historias distintas. Analizar un recurso legacy consiste en relacionarlas. No se trata de una modalidad técnicamente obsoleta del protocolo IPv4.

Lo que cambia frente a recursos asignados más recientemente

No existen paquetes IP de tipo legacy. Las diferencias afectan principalmente al origen de la asignación, las pruebas de titularidad, los acuerdos de servicio y los procedimientos. Un recurso reciente suele estar vinculado al marco vigente cuando lo entrega el RIR. Un recurso histórico puede ser anterior a ese marco, por lo que hay que examinar su relación contractual concreta.

En ARIN, ciertos recursos legacy sin acuerdo pueden seguir recibiendo servicios básicos, como mantenimiento de registros y DNS inverso. Para acceder a los servicios RPKI e IRR prestados por ARIN se requiere un acuerdo adecuado. No tener ese acuerdo no significa automáticamente que el recurso esté sin registrar o no pueda anunciarse.

El RIPE NCC contempla varias relaciones: afiliación, un LIR patrocinador, un contrato de servicio para no miembros o actualizaciones del registro sin relación formal. Esta última opción no obliga a proporcionar todos los servicios nuevos. La continuidad de prestaciones existentes y el acceso a otras nuevas deben distinguirse. No hay una condición contractual única que pueda atribuirse a todos los recursos históricos.

Histórico no significa ajeno a los registros

Muchos recursos legacy tienen datos WHOIS o RDAP, una organización identificada, contactos y configuraciones de DNS inverso o seguridad del enrutamiento. IANA también permite identificar el RIR responsable de grandes conjuntos de direcciones. La cuestión útil no es si el recurso está «fuera del sistema», sino si sus registros explican correctamente la historia, el titular actual y las facultades necesarias para administrarlo.

Cruza los datos públicos con los documentos de la organización

Empieza por el IPv4 Address Space Registry de IANA para identificar el espacio de nivel superior y el organismo responsable. Después consulta los datos autoritativos del RIR mediante RDAP, WHOIS y el expediente del recurso. Comprueba el prefijo exacto, la organización, el estado, los contactos y los eventos. La marca LEGACY de un /8 orienta la investigación; no demuestra por sí sola el estado actual de todos sus bloques.

Contrasta lo encontrado con cartas de asignación, registros antiguos, documentos de constitución y cambio de nombre, contratos de adquisición o cesión y comunicaciones con el registro. Las pruebas administrativas, jurídicas y operativas deben encajar entre sí. Ninguna cuenta toda la historia por separado.

El registro aporta evidencia, pero no resuelve todos los derechos

El titular inscrito, quien opera la red y quien puede reclamar derechos conforme a la ley no son conceptos necesariamente idénticos. El registro identifica, entre otras cosas, a la organización que reconoce y a quienes pueden solicitar cambios. Esa información importa, pero no sustituye automáticamente el análisis de cualquier controversia.

Puede ser necesario revisar la asignación original, los contratos, la sucesión entre entidades, las cesiones, la legislación aplicable y decisiones judiciales. Esto resulta especialmente relevante cuando el recurso precede a los acuerdos actuales. En una operación importante o una situación disputada, conviene contar con asesoramiento competente en la jurisdicción correspondiente.

Reconstruye la cadena antes de que una operación la ponga a prueba

Una empresa cambia de nombre, otra la compra y, años después, una actividad pasa a una tercera entidad. Mientras tanto, los administradores se marchan, los correos antiguos dejan de existir y los documentos se dispersan. El tráfico puede continuar sin revelar esas discontinuidades.

«Llevamos treinta años usando las direcciones» no demuestra por sí solo la relación entre la entidad solicitante actual y la organización inscrita originalmente. Una transferencia legacy en RIPE NCC puede requerir documentación de constitución, cambios de nombre y transmisión. Cada cambio empresarial debería dejar pruebas que permitan enlazar al titular anterior con el siguiente.

Prepara un expediente por recurso, no una colección de correos sueltos

Reúne la documentación de asignación y registro, estados históricos de WHOIS o RDAP, documentos de constitución y cambio de nombre, contratos de fusión o cesión, comunicaciones con el registro y facultades de representación. Documenta también contactos actuales, responsables de recuperación de acceso, enrutamiento, DNS inverso y gestión de ROA y objetos IRR cuando proceda.

No todas las gestiones exigirán las mismas piezas. La organización sí debería poder explicar cómo recibió y conserva el recurso. Las credenciales y claves deben permanecer en sistemas de seguridad adecuados, no en un expediente compartido de forma indiscriminada. Una captura de un registro público no sustituye los contratos ni acredita por sí sola una sucesión empresarial.

Una transferencia admitida en una región puede tener otras condiciones fuera de ella

Algunos marcos permiten transferir recursos legacy. En una transferencia interna del RIPE NCC, la identificación del titular y las verificaciones requeridas permiten actualizar el registro manteniendo el estado LEGACY. Una transferencia entre RIR debe cumplir las reglas de origen y destino; no se puede extrapolar sin más el resultado de un procedimiento interno.

Antes de firmar, identifica al registro responsable, al titular reconocido, el estado del bloque, la vía de transferencia, la elegibilidad del receptor y la documentación necesaria. Confirma expresamente qué ocurrirá con el estado legacy después. Un precio acordado no demuestra que el registro aceptará la operación ni que los servicios pasarán correctamente al receptor.

Algunas conversiones de estado no tienen vuelta atrás

El RIPE NCC permite solicitar la conversión de espacio legacy en una asignación PA o PI y advierte que esa conversión es irreversible. Desde entonces se aplican las políticas del nuevo estado. No siempre estamos ante una modificación administrativa sin consecuencias.

Analiza antes los efectos sobre contratos, tarifas, acceso a servicios y futuras transferencias. Comprueba también si obtener un servicio exige realmente cambiar el estado histórico o si son decisiones separadas. Una consecuencia irreversible no debería descubrirse después de ejecutar el trámite.

Lee qué servicio recibes y qué compromisos aceptas

Los acuerdos difieren entre registros y pueden cambiar dentro de una misma organización. ARIN distingue, por ejemplo, determinadas situaciones cubiertas por acuerdos legacy antiguos de otras incorporadas posteriormente, con efectos sobre las tarifas. No cabe deducir que todos los recursos históricos sean gratuitos o disfruten de las mismas condiciones.

Revisa el alcance del servicio, las obligaciones, las tarifas, la terminación, las controversias, los cambios de estado y las transferencias. Que un servicio requiera contrato no demuestra que todos los derechos anteriores desaparezcan. Del mismo modo, una asignación antigua no permite ignorar los compromisos que sí sean aplicables hoy.

Que el bloque sea accesible no sustituye las verificaciones de control

El estado legacy no impide por sí solo anunciar un prefijo. Aun así, comprueba quién lo anuncia, si el ASN de origen es el previsto, si existen anuncios inesperados o más específicos y si los ROA y objetos IRR coinciden con la red real. Verifica también quién gestiona el DNS inverso.

El registro describe relaciones administrativas; BGP propaga información de alcance; RPKI aporta autorizaciones verificables de origen; las cuentas determinan quién puede tramitar cambios. Son capas relacionadas, no equivalentes. La conectividad de hoy no garantiza que puedas realizar la siguiente modificación.

Resuelve la seguridad del enrutamiento antes de transferir

Comprueba la elegibilidad del recurso para el servicio RPKI concreto, quién administra los ROA actuales y qué objetos deberán modificarse o volver a emitirse. La relación entre acuerdo contractual y elegibilidad en ARIN es un caso que examinar, no una regla universal de los RIR. Acceder a un servicio de certificación tampoco es lo mismo que desplegar validación de origen de rutas en una red.

El plan de transferencia debe contemplar ROA, objetos IRR y permisos de gestión, además de los posibles cambios de validación durante la transición. Actualizar el nombre del titular en la base de datos no completa por sí solo la continuidad de la seguridad.

No basta con entregar una configuración de DNS: hay que entregar su gestión

Comprueba la delegación, los servidores de nombres, el servicio PTR y los permisos para modificarlos. ARIN incluye el DNS inverso entre los servicios básicos para determinados titulares legacy sin acuerdo correspondiente; para cada bloque hay que verificar el organismo y la relación efectiva.

En una venta, adquisición o cambio de proveedor, el receptor necesita mantener y modificar el servicio. Unos archivos que continúan funcionando no resuelven una cuenta que sigue en manos de alguien inaccesible. La gestión efectiva debe formar parte de la entrega.

El registro no puede adivinar cómo se ha estructurado una adquisición

Una compra de acciones, una fusión jurídica y una cesión de activos pueden tener efectos diferentes. Determina si la entidad titular sigue existiendo, si solo cambian sus accionistas o si los recursos pasan a otra persona jurídica. Identifica las actualizaciones necesarias y las pruebas que sustentan esos cambios.

La operación empresarial, la tramitación del registro y la transición técnica pueden tener calendarios distintos. No esperes al cierre para descubrir que las direcciones figuran a nombre de una sociedad disuelta o que la cuenta depende de un antiguo empleado. Los recursos de numeración deben entrar en las comprobaciones previas a la operación.

Nueve riesgos que el funcionamiento diario puede ocultar

Los recursos históricos no son inseguros por naturaleza. Su trayectoria puede esconder nueve problemas: documentación incompleta; registros o contactos obsoletos; sucesiones empresariales mal acreditadas; acceso o recuperación de cuentas inciertos; cambios de estado no previstos; condiciones de transferencia distintas entre organismos; dependencia de servicios de seguridad; DNS inverso sin continuidad de gestión; y reclamaciones difíciles de resolver por falta de pruebas.

Detectarlos a tiempo permite actuar antes de que una urgencia fuerce decisiones apresuradas. El resultado debe ser un conjunto de hechos, responsables y medidas concretas. Ni confiar ciegamente en que siempre ha funcionado ni anunciar una caída inevitable sustituye ese trabajo.

Ocho comprobaciones antes de comprometerte

Registro: ¿qué RIR administra el prefijo, con qué estado y a nombre de quién? Documentación: ¿pueden demostrarse la asignación, los cambios de nombre, las sucesiones y las transferencias? Acceso: ¿quién está autorizado, cómo se protege la autenticación y cómo se recupera la cuenta? Enrutamiento: ¿coinciden el ASN de origen y los anuncios con la explotación prevista?

Seguridad: ¿quién gestiona ROA y objetos IRR y cómo se mantiene su coherencia durante la transición? DNS inverso: ¿quién controla la delegación y podrá actuar el receptor? Contratos: ¿qué acuerdos, tarifas y obligaciones rigen y cómo afectan al estado? Transferencia: ¿existe un procedimiento aplicable, cumple el receptor los requisitos, intervienen dos RIR y se conservará el carácter histórico?

Para cada respuesta, registra pruebas, responsables y asuntos pendientes. Marcar una casilla de «revisado» no equivale a resolver una incertidumbre. Las cuestiones relevantes deben aclararse antes de la firma y de la ejecución técnica.

Un registro exacto debe conectar la historia con la realidad actual

Incluso un expediente histórico sólido pierde utilidad si el registro sigue identificando una entidad desaparecida hace décadas. El servicio debe permitir reconocer sucesiones, corregir datos mediante pruebas y conservar una trazabilidad verificable. Respetar la historia y actualizar el presente no son objetivos incompatibles.

La inscripción forma parte de la historia del recurso, pero no es toda su historia. También cuentan la asignación inicial, la explotación, las sucesiones y los acuerdos. NRS defiende registros más exactos, transparentes y útiles para comprobar el control y tramitar cambios, sin suponer que una base de datos creó por sí sola todas esas relaciones.

El carácter histórico no debería convertirse en una herramienta de bloqueo

Internet necesita unicidad, datos exactos, contactos fiables, información de seguridad y trazabilidad, tanto si una dirección se obtuvo en 1992 como en 2026. Otra cuestión es si acceder al servicio que mantiene esos datos debe obligar al titular a abandonar su situación anterior o aceptar restricciones comerciales adicionales.

En la sexta parte de su Note 71, «The Policy Mirror», Lu Heng propone que incorporarse a un nuevo servicio de registro no haga perder automáticamente el estado legacy o equivalente. El cambio debería responder a una decisión expresa y separada del titular. Es una propuesta de reforma, no una norma común ya adoptada por todos los RIR.

NRS defiende derechos más sólidos para los titulares, reglas transparentes que puedan cuestionarse y vías de salida utilizables. Una empresa debe entender las consecuencias del marco que acepta antes de invertir o transferir recursos, no descubrir después una dependencia de la que no puede salir.

Haz que la historia, los registros y la red cuenten lo mismo

Los IPv4 legacy son una parte histórica de la infraestructura de Internet, no simplemente «direcciones viejas». Pueden sostener redes modernas cuando su origen es trazable, las sucesiones se acreditan, los registros son coherentes y quienes administran los servicios están efectivamente autorizados.

Establece primero los hechos y, con ellos, aborda la operación y las cuestiones de gobernanza. La accesibilidad no sustituye las verificaciones; el cambio de inscripción no sustituye la transición operativa. Un sistema fiable debe facilitar ambas cosas sin obligar a elegir entre continuidad del negocio y conservación de la situación histórica.

Preguntas frecuentes

¿Qué recursos se consideran IPv4 legacy?

Generalmente, los obtenidos antes del sistema jerárquico moderno de los RIR o fuera de él. Los años de uso no bastan: hay que verificar el origen y el estado actual del bloque con su organismo responsable.

¿Se pueden seguir utilizando las direcciones históricas?

Su estado no las invalida ni impide por sí solo su enrutamiento. La operación también depende de los registros, los anuncios, los objetos de seguridad y las facultades para administrar los servicios.

¿Quién mantiene hoy sus registros?

Muchos recursos históricos están administrados por RIR. El registro de IANA orienta la búsqueda; el prefijo concreto y su titular deben comprobarse después en los datos del organismo responsable.

¿Se puede transferir un bloque legacy?

Algunos marcos lo permiten con procedimientos y comprobaciones específicos. Las condiciones y los efectos sobre el estado y los servicios pueden diferir entre una transferencia interna y otra entre RIR. Hay que revisar las reglas de todos los organismos implicados.

De las verificaciones a una voz en las reglas

Si una incertidumbre sobre registros, acceso o servicios afecta a tu actividad, conoce primero el alcance de NRS Shield. Para participar en la reforma, consulta las acciones vigentes. Si quieres confiar una representación a NRS, lee por separado la explicación del poder de representación, o POA: representante, objeto, duración, revocación y responsabilidades deben quedar claros. Solicitar ayuda, hacerse miembro y otorgar un poder son decisiones distintas. Una POA no garantiza la seguridad de los recursos, no concede automáticamente derecho a voto y no sustituye los procedimientos de representación o elección de cada organismo.