Number Resource Society
Registro IP y rutas BGP: cómo interpretar las diferencias
Que un bloque figure a nombre de una empresa y lo anuncie otra red no demuestra por sí solo un error o un secuestro de rutas. Para entender qué ocurre, hay que distinguir el registro, el anuncio observado, la autorización de origen y los acuerdos de operación.
En esta página
Imagen conservada del artículo original en inglés.
Antes de comparar nombres, identifique qué está comprobando
Una consulta RDAP muestra su empresa; un colector BGP muestra el ASN de un proveedor. Ambas observaciones pueden ser correctas. Administrar un bloque y originar sus anuncios son funciones distintas, y no siempre las desempeña la misma organización. Lo que falta es explicar la relación entre ellas.
Conviene separar cinco planos: la información registrada, el enrutamiento observado, la autorización de origen, las declaraciones en los IRR y lo que la empresa espera de su propia red. Ninguno sustituye a los demás. Al contrastarlos, una diferencia deja de ser una sospecha vaga y se convierte en una cuestión que puede investigarse.
| Fuente | Qué permite comprobar |
|---|---|
Registro / RDAP | Qué entidades, contactos y datos de registro están asociados con el recurso. |
Observación BGP | Qué ASN aparece como origen del prefijo desde un punto y en un momento determinados. |
RPKI / ROA | Qué AS está autorizado a originar anuncios para un prefijo y una longitud determinados. |
IRR | Qué objetos de rutas e información de políticas se han registrado. |
Inventario y cambios internos | Quién debería operar el recurso, con qué acuerdo y quién responde por los cambios o la recuperación. |
RDAP devuelve información de registro sobre IPv4, IPv6 y ASN. Según el objeto, incluye rangos, identificadores, nombres, entidades, estados y eventos. El formato se describe en el RFC 9083. Puede ampliar la explicación en Cómo leer un registro RDAP de una dirección IP. Un estado active no demuestra que el prefijo sea accesible en ese instante.
BGP intercambia información de alcanzabilidad entre sistemas autónomos, como recoge el RFC 4271. En la ruta simplificada del ejemplo, AS64500 es el origen mostrado. Para interpretar un resultado real también hacen falta el colector, los puntos desde los que observa y la hora: una sola vista no representa todo Internet.
Prefijo: 203.0.113.0/24
Ruta AS simplificada observada: AS64496 AS64497 AS64500
Origen mostrado: AS64500Ver un anuncio ayuda a identificar qué red lo origina, pero no acredita por sí solo el registro, los derechos contractuales o la autorización. El procedimiento se desarrolla en Cómo comprobar quién anuncia un prefijo IP en BGP.
Los ejemplos usan direcciones y ASN reservados para documentación, según los RFC 5737 y RFC 5398. Así se evita atribuir a operadores reales un comportamiento inventado para explicar un concepto.
Seis situaciones habituales en las que los nombres no coinciden
El proveedor de conectividad origina el anuncio
La empresa administra las direcciones, pero el operador de tránsito las anuncia desde su propio ASN. El registro y BGP muestran responsabilidades diferentes. Hay que verificar que el acuerdo existe y está autorizado, no exigir que ambos sistemas presenten el mismo nombre.
La operación forma parte del servicio de alojamiento
Un proveedor de alojamiento o de servicios gestionados puede anunciar las direcciones del cliente. Eso no cambia automáticamente la relación de registro. Contrato, autorizaciones y configuración deben explicar quién hace qué.
Se activa la mitigación de un ataque DDoS
Un servicio de limpieza de tráfico puede originar temporalmente el prefijo. El origen pasa, por ejemplo, de AS64500 a AS64501 mientras el registro permanece igual. La transición necesita un acuerdo previo, autorizaciones y filtros adecuados, además de un procedimiento de regreso. Saber que existe un servicio DDoS no basta para dar por correcto cualquier anuncio.
Hay una migración de red en curso
Al cambiar de proveedor o de ASN pueden verse la red antigua y la nueva durante un periodo de transición. La empresa asociada al recurso no ha cambiado; sí lo ha hecho la arquitectura. La ventana de migración, las aprobaciones y el plan de reversión ayudan a interpretar lo observado.
El servicio se presta mediante anycast
Un prefijo puede ofrecer servicio desde varios lugares. La arquitectura puede utilizar un único ASN o más de uno. Anycast no equivale automáticamente a múltiples AS de origen: hay que relacionar las observaciones con el diseño concreto.
Una adquisición cambia la empresa antes que la red
Tras una compra, fusión o reorganización, la infraestructura anterior puede seguir funcionando. Los cambios societarios, administrativos y de enrutamiento no tienen por qué producirse al mismo tiempo. Véase Qué ocurre con las direcciones IP en una fusión o adquisición.
Actualizar el registro y cambiar las rutas son operaciones separadas
Después de una transferencia IPv4, la nueva empresa puede mantener temporalmente al mismo proveedor y el mismo ASN de origen. El registro cambia y BGP no. Puede ser una transición planificada para proteger el servicio, siempre que tenga respaldo documental, autorización vigente y responsables identificados.
Entidad registrada después de la transferencia: Empresa B
Origen previsto durante la transición: AS64500
Origen BGP observado: AS64500
Comprobación aparte: aceptación y autorización de la Empresa BTambién ocurre lo contrario: un nuevo proveedor, otro ASN, la activación de mitigación DDoS, cambios de ingeniería de tráfico, una migración o la externalización pueden modificar BGP sin cambiar la entidad registrada. Que el registro no haya variado no significa que la red siga igual.
Campos como startAddress, endAddress, name, status, entities y events describen el objeto registrado, no el estado BGP en directo. A su vez, que un ASN anuncie un prefijo no permite concluir que sea su titular, que tenga permiso o que actúe de forma maliciosa. Primero delimite lo que sabe; después busque la evidencia que falta.
Qué aportan los ROA y los registros IRR
Un ROA es un objeto firmado que autoriza a un AS a originar anuncios para determinados prefijos; su formato está en el RFC 9582. No valida toda la ruta AS ni acredita derechos contractuales. En estos ejemplos, «longitud máxima efectiva 24» limita la autorización al /24 exacto. Si se omite maxLength, se aplica ese límite; no se recomienda codificar un valor redundante igual a la longitud del prefijo.
Lo previsto, lo autorizado y lo observado coinciden
Entidad registrada: Empresa A
Origen previsto: AS64500
Autorización: 203.0.113.0/24; longitud máxima efectiva 24; AS64500
BGP: 203.0.113.0/24 → AS64500El anuncio concuerda con la autorización indicada. Eso no descarta problemas en otros puntos de la ruta o del reenvío de paquetes. Tampoco exige que la empresa registrada y la red operadora sean la misma entidad.
Cambió el origen, pero no la autorización
Autorización: 203.0.113.0/24; longitud máxima efectiva 24; AS64500
BGP: 203.0.113.0/24 → AS64501
Supuesto: no hay otra autorización validada que coincida con el anuncioCon ese supuesto, el estado es Invalid. Puede deberse a una migración incompleta, a una configuración errónea o a un anuncio sin permiso. El resultado señala una falta de correspondencia; no demuestra por sí solo un secuestro intencional de rutas.
El proveedor anuncia con autorización del titular del recurso
Entidad registrada: Empresa A
Operador previsto: Red B, AS64501
Autorización: 203.0.113.0/24; longitud máxima efectiva 24; AS64501
BGP: 203.0.113.0/24 → AS64501Los nombres difieren, pero existe una relación técnica que puede comprobarse. Hay que contrastarla con el contrato y la aprobación operativa: el ROA no sustituye esos documentos.
Cómo leer Valid, Invalid y NotFound
- Valid: al menos un dato de autorización validado cubre el prefijo anunciado y coincide tanto con el ASN de origen como con la longitud.
- Invalid: hay datos validados que cubren el prefijo, pero ninguno cumple todos los criterios. Puede no coincidir el origen o superarse la longitud permitida.
- NotFound: ningún dato de autorización validado cubre el prefijo. No significa que no existan derechos sobre el recurso ni que el anuncio sea seguro.
Registre cuándo se hizo la comprobación, qué validador se usó y con qué datos. La validación del RFC 6811 no es la política de filtrado que distingue el RFC 8481. Invalid no implica automáticamente una interrupción en todo Internet. El artículo Cobertura ROA y adopción de ROV amplía esta diferencia.
Un objeto IRR puede haberse quedado desactualizado
route: 203.0.113.0/24
origin: AS64500Algunas redes generan filtros a partir de los IRR. Si el objeto sigue indicando AS64500 y BGP ya muestra AS64501, investigue si falta una actualización o si hay un objeto antiguo. El RFC 2622 describe RPSL y el RFC 7454 aporta contexto operativo. Un IRR contiene declaraciones de enrutamiento: no garantiza la configuración actual ni equivale a una autorización RPKI.
Si el inventario, los ROA y el IRR apuntan a AS64500 y aparece AS64502 sin explicación, hay una discrepancia que atender. Revise los cambios internos, las configuraciones del proveedor y el historial. Determine si hay un fallo, un evento de enrutamiento o documentación pendiente antes de atribuirle una causa.
Siete pasos para investigar una discrepancia
1. Defina exactamente qué rango está comparando
Anote el prefijo CIDR y su longitud. Un registro que abarca un /20 y varios anuncios /24 no describen el mismo objeto. Establezca primero la relación entre el bloque y sus subrangos.
2. Documente la respuesta RDAP
Guarde en su expediente el rango, las entidades, el registro responsable, los estados y los eventos disponibles, junto con la fuente y la hora de consulta. No complete con suposiciones los campos que no aparecen.
3. Examine BGP desde puntos identificados
Anote prefijos, orígenes, rutas AS, anuncios más específicos y posibles orígenes múltiples. Incluya lugar y momento de observación. En incidentes importantes, contraste varias vistas: no ver una ruta en un colector no demuestra que no exista en ninguna parte.
4. Compruebe RPKI para el anuncio observado
Evalúe la combinación concreta de prefijo y origen. Además del estado, examine las autorizaciones que cubren el rango, los ASN, las longitudes máximas y la actualidad de los datos. Copiar una etiqueta no explica por qué se obtuvo.
5. Revise los objetos IRR
Localice los objetos route o route6 y su origin. Busque declaraciones obsoletas, contradictorias o que no se hayan actualizado tras el último cambio.
6. Contraste lo observado con el plan de la empresa
Confirme el origen previsto, los proveedores, la arquitectura y las migraciones o mitigaciones temporales. Los datos públicos no siempre explican la intención de la empresa; contratos, inventarios y cambios aprobados completan esa parte.
7. Establezca qué quedó fuera de lo previsto
No dé por sentado que el primer sistema que difiere es el equivocado. Reconstruya qué se acordó, quién lo aprobó, qué se ejecutó y qué queda por corregir. Deje constancia de la conclusión, el responsable y la próxima verificación para que la investigación ayude también en futuras incidencias.
Los subprefijos y el historial pueden explicar lo que una consulta aislada oculta
Un bloque registrado puede contener rutas más específicas
Multiconexión, distribución geográfica, asignaciones a clientes o ingeniería de tráfico pueden dar lugar a distintas relaciones de operación dentro de un bloque. El siguiente ejemplo es solo una división aritmética de direcciones: no recomienda anunciar /25 en Internet ni afirma que se propaguen globalmente.
Rango de ejemplo: 203.0.113.0/24
Primera mitad: 203.0.113.0/25
Segunda mitad: 203.0.113.128/25
La operación de cada subrango debe comprobarse por separadoUn prefijo puede aparecer con varios AS de origen
Observación A: 203.0.113.0/24 → AS64500
Observación B: 203.0.113.0/24 → AS64501Se suele hablar de MOAS, Multiple Origin AS. Puede responder a anycast, una migración, mitigación DDoS, una arquitectura compartida o un anuncio no previsto. Compruebe los tiempos, los puntos de observación, las autorizaciones y los acuerdos operativos. La existencia de dos orígenes no revela por sí sola la causa.
Sitúe el cambio en una línea de tiempo
Si en enero aparecía AS64500 y en octubre aparece AS64501, busque cuándo cambió y qué ocurrió entonces. Una adquisición, una mudanza de centro de datos o la activación de limpieza pueden dar pistas. La coincidencia temporal no sustituye a la documentación que confirma la relación.
Los cambios societarios también dejan huellas
Un cambio de nombre, la reorganización de filiales, una compra o una fusión pueden dejar información de registro pendiente de actualización. Hay que averiguar quién debe corregirla y mediante qué procedimiento. La precisión de esos datos ayuda a recuperar cuentas, tramitar transferencias, realizar diligencias y responder a incidentes.
Distinga los recursos que administra de las direcciones asignadas por el proveedor
Las direcciones que usa una empresa no tienen por qué estar registradas directamente a su nombre. Cuando las asigna el proveedor, este puede aparecer tanto en RDAP como en BGP. Antes de cambiar de servicio, compruebe las condiciones de uso y de migración. Haber utilizado un rango durante años no demuestra que pueda llevarse libremente a otro operador.
Registro, autorización, derechos y control necesitan evidencias distintas
El registro puede ser una pieza importante para acreditar la relación administrativa con el recurso, pero no basta para formular una conclusión jurídica universal sobre su propiedad. También pueden importar contratos, historial de transferencias, documentos societarios, políticas y legislación aplicable. BGP tampoco es un registro de propiedad: muestra comportamiento de enrutamiento.
Un proveedor puede operar el ASN por encargo mientras la empresa mantiene la gestión administrativa. Separe quién figura registrado, quién está autorizado como origen, quién anuncia y quién puede cambiar cuentas o configuraciones. Esa distinción indica a quién acudir y qué capacidad de recuperación tiene realmente la organización.
| Prefijo | Entidad registrada | ASN previsto | ASN observado | RPKI | Origin IRR | Seguimiento |
|---|---|---|---|---|---|---|
203.0.113.0/24 | Empresa A | AS64500 | AS64500 | Valid | AS64500 | Coherencia en los datos mostrados; mantener la vigilancia |
198.51.100.0/24 | Empresa A | AS64500 | AS64501 | Invalid | AS64500 | Investigar el cambio y la autorización |
La segunda fila supone una autorización validada que cubre el prefijo para AS64500 y ninguna que coincida con el anuncio de AS64501. En un inventario real añada hora, validador, proveedor, cambios aprobados, responsables y fecha de revisión. Sin ese contexto, una etiqueta puede transmitir más certeza de la que permite la evidencia.
Convertir la comprobación en una práctica de continuidad
Conviene revisar estas relaciones en la auditoría anual de recursos, adquisiciones, transferencias IPv4, cambios de proveedor o ASN, despliegues RPKI, problemas de conectividad sin explicación, mitigaciones DDoS y reorganizaciones. Mantener una referencia actualizada es más útil que reconstruir todo el historial durante una crisis.
Una transferencia completada puede dejar trabajo técnico pendiente
El cambio administrativo no actualiza por sí solo BGP, RPKI, IRR o DNS. Cada plano necesita responsable, secuencia de trabajo y verificación. El análisis Datos del mercado de transferencias IPv4 en 2026 muestra el contexto de circulación de recursos: cuanto más cambian de organización, más importante es coordinar registro y operación.
Coordinar no significa cambiarlo todo el mismo día
Después de una adquisición puede ser razonable mantener la infraestructura anterior durante meses. Lo necesario es que cada plano esté documentado, responda a la realidad y pueda recuperarse. Forzar cambios simultáneos solo para que todos los nombres coincidan puede introducir riesgos innecesarios.
La red operativa y el registro preciso se necesitan mutuamente
Saber qué recursos existen, qué entidad los administra, qué ASN debería anunciarlos, qué ROA y objetos IRR los respaldan y quién controla las cuentas facilita migraciones, diagnóstico y recuperación. Que el servicio funcione no vuelve irrelevante el registro; que el registro sea correcto no garantiza que el enrutamiento funcione.
Los paquetes los transportan las redes en funcionamiento, no una entrada de base de datos. Una gobernanza responsable debe permitir comprobar las relaciones entre registro, autorización y operación, explicar las diferencias y exigir responsabilidades por los cambios. Ninguna fuente puede responder por todas las demás.
Lista de cierre: ¿la diferencia tiene explicación y alguien puede actuar?
| Ámbito | Pregunta que debe quedar resuelta |
|---|---|
Prefijo | ¿Se compara exactamente el mismo rango CIDR? |
RDAP | ¿Qué organización está asociada al registro? |
BGP | ¿Qué origen se observa, dónde y cuándo? |
RPKI | ¿Hay una autorización validada que coincida con prefijo, longitud y origen? |
IRR | ¿Qué origin se declaró y sigue siendo aplicable? |
Rutas más específicas | ¿Se anuncian subrangos por separado? |
Orígenes múltiples | ¿Aparecen varios y existe una explicación documentada? |
Historial | ¿Cuándo cambió la ruta y qué ocurrió entonces? |
Proveedor | ¿Un tercero se encarga del anuncio o de la operación? |
Inventario interno | ¿La situación coincide con lo previsto por la empresa? |
Documentación | ¿Pueden verificarse los acuerdos y las decisiones? |
Continuidad | ¿Quién puede actualizar, corregir o recuperar cada plano? |
Siete errores que llevan a conclusiones equivocadas
Dar por incorrecta cualquier diferencia: un tercero puede anunciar el bloque según lo acordado.
Confundir coincidencia con seguridad: el mismo ASN en varias fuentes no descarta otros problemas.
Usar RDAP como una vista de BGP en tiempo real: el registro cumple otra función.
Tratar BGP como una base de datos de propiedad: anunciar no acredita todos los derechos.
Ignorar RPKI: se pierde una evidencia importante de autorización de origen.
Prescindir de los registros internos: los datos públicos no explican toda la intención operativa.
No volver a revisar después de un cambio: migraciones, transferencias y adquisiciones pueden dejar tareas sin completar.
En lugar de preguntar qué sistema tiene toda la verdad, pregunte qué describe cada uno y si sus relaciones son explicables. El registro no enruta paquetes, BGP no demuestra permiso, un ROA no describe la red entera y el IRR no garantiza la configuración actual. Comprender esos límites mejora las decisiones al operar, transferir o recuperar recursos.
Preguntas frecuentes
¿Por qué RDAP y BGP muestran organizaciones diferentes?
Porque describen funciones distintas. RDAP presenta la relación de registro; BGP muestra el ASN de origen observado. Un proveedor puede anunciar los recursos de su cliente. Compruebe las autorizaciones y el acuerdo de operación, no solo los nombres.
¿El ASN de origen identifica al titular del prefijo?
No necesariamente. Identifica el origen del anuncio observado, pero no determina por sí solo el registro, los derechos contractuales ni la situación jurídica del recurso.
¿Otra red puede anunciar direcciones registradas a nombre de mi empresa?
Existen acuerdos de ese tipo en conectividad, alojamiento y mitigación DDoS. Para el recurso concreto deben verificarse el acuerdo entre las partes, la autorización de origen y la configuración efectiva; la posibilidad general no valida cualquier caso.
¿RDAP muestra el enrutamiento BGP en tiempo real?
RDAP ofrece principalmente información de registro. El enrutamiento se comprueba con observaciones BGP que incluyan lugar y hora, y se contrasta con las autorizaciones y la documentación interna.
Sobre esta edición
Ann Yong publicó el artículo original en inglés el 16 de octubre de 2026. Esta edición en español organiza sus casos, comprobaciones, tablas y preguntas frecuentes en torno a una investigación operativa. Se conserva el original histórico en inglés. Las aclaraciones sobre el alcance de las observaciones, la validación RPKI y los recursos de ejemplo son aportaciones editoriales del 31 de octubre de 2026, no afirmaciones atribuidas retrospectivamente a la autora. Las direcciones, los ASN y las empresas de los ejemplos son recursos de documentación o nombres ficticios: no describen redes reales ni constituyen configuraciones listas para producción.
De la evidencia verificable a una gobernanza que rinda cuentas
Nota añadida por NRS el 31 de octubre de 2026. Las indicaciones siguientes sobre representación y participación son de NRS y no forman parte del artículo original de Ann Yong.
Quienes utilizan recursos de numeración deben poder entender las decisiones que les afectan, corregir errores y participar en su gobernanza. NRS Shield explica el apoyo disponible ante riesgos relacionados con esos recursos. Si necesita representación de NRS, examine por separado el mandato POA: representante, alcance, duración, facultades de decisión y procedimiento de revocación. El POA es un mandato de representación, no un ROA. No otorga a NRS el control del enrutamiento ni garantiza la continuidad del servicio. Leer, consultar o hacerse miembro no equivale a otorgar ese mandato.
Conocer NRS Shield · Entender el mandato POA · Ver las acciones vigentes