Number Resource Society
ROA y ROV en 2026: de publicar autorizaciones a filtrar rutas
Una cobertura ROA elevada no garantiza una validación extendida. Cómo leer las mediciones de APNIC y comprobar la cadena operativa de su propia red.
En esta página
Publicar permisos no equivale a filtrar rutas
Un ROA indica qué ASN puede anunciar un prefijo. ROV contrasta las rutas con esas autorizaciones y permite aplicar una política. En la muestra de APNIC de febrero de 2026, el 60,3 % de las rutas IPv4 y el 60,9 % de las IPv6 eran Valid; la protección mediante ROV se observaba en aproximadamente el 26,6 % de los puntos medidos. Son denominadores distintos: restarlos no calcula una brecha de seguridad exacta. El reto es convertir la autorización disponible en decisiones de encaminamiento.
Qué significa la cobertura ROA
Un ROA es un objeto RPKI firmado con el que el titular autoriza a un sistema autónomo a originar determinados prefijos, según la RFC 9582. La cobertura relaciona las rutas visibles con la información de autorización. Los estados Valid, Invalid y Not Found no dicen, por sí solos, qué política aplica cada red. Las direcciones y los ASN de los ejemplos son ilustrativos.
Prefix: 203.0.113.0/24
Origin ASN: AS64500
Cómo interviene ROV
La red compara el origen BGP y la longitud del prefijo con los datos RPKI validados. AS64500 coincide en el ejemplo; AS64501 no, si ninguna otra autorización lo permite. La política puede rechazar rutas Invalid, reducir su prioridad o empezar observándolas. Hay que considerar todas las autorizaciones que cubren la ruta, no una sola elegida arbitrariamente.
203.0.113.0/24 → AS64500
203.0.113.0/24 → AS64500
203.0.113.0/24 → AS64501
La fotografía mundial de febrero de 2026
Las tablas recogen aquella medición de APNIC, no valores en directo. Frente a febrero de 2025, la proporción Valid había aumentado unos seis puntos en IPv4 y siete en IPv6. Publicar más autorizaciones es un avance, pero no demuestra que el filtrado se haya generalizado.
IPv4: un 60,3 % Valid
El mismo conjunto incluía un 37,7 % Not Found y un 2,0 % Invalid. Una parte considerable seguía sin una autorización que la cubriera.
| Estado RPKI | Proporción de rutas observadas |
|---|---|
Valid | 60.3% |
Not Found | 37.7% |
Invalid | 2.0% |
IPv6: un 60,9 % Valid
Not Found representaba el 36,1 % e Invalid el 3,0 %. IPv6 también necesita autorizaciones mantenidas y políticas de validación; ser un protocolo más reciente no evita errores de origen.
| Estado RPKI | Proporción de rutas observadas |
|---|---|
Valid | 60.9% |
Not Found | 36.1% |
Invalid | 3.0% |
Los porcentajes ROV necesitan contexto
APNIC estimó un 26,6 % mundial en febrero y citó un 26,92 % a finales de julio en su análisis sobre India. No son un censo de ASN que hayan configurado ROV por sí mismos: el filtrado de un proveedor puede proteger puntos de observación aguas abajo. La tabla regional corresponde a febrero y no debe mezclarse con la medición de julio.
| Región / medición RIR | ROV medido |
|---|---|
ARIN | 61.3% |
RIPE | 35.3% |
Global | 26.6% |
APNIC | 13.2% |
Publicar y aplicar son decisiones diferentes
Crear un ROA exige definir prefijo, ASN de origen y longitud permitida. ROV afecta a rutas recibidas de clientes, pares, proveedores de tránsito y servidores de rutas. Rechazar, relegar, observar o admitir una excepción temporal tiene consecuencias operativas y requiere responsables claros.
Por qué cuesta dar el paso
Temor a cortar tráfico legítimo, sistemas antiguos, ROA desactualizados, automatización desigual y excepciones difíciles de gestionar son obstáculos reales. Justifican preparar el despliegue, no descartarlo. Si el origen cambia de AS64500 a AS64501 y el ROA permanece igual, una ruta legítima puede pasar a Invalid.
Original routing:
203.0.113.0/24 → AS64500
ROA:
203.0.113.0/24 → AS64500
203.0.113.0/24 → AS64501
Conectar registro, autorización y realidad
Quién administra el recurso, qué ASN está autorizado, qué anuncia BGP y qué ha cambiado son preguntas relacionadas pero distintas. Un ROA no es un anuncio BGP; un registro tampoco prueba la autorización actual. Los cambios de proveedor, ASN o longitud deben mantener alineadas estas capas.
El avance del sudeste asiático
En febrero, APNIC situaba las rutas IPv4 Valid del sudeste asiático en el 92,4 %, frente al 31,0 % de Asia oriental. Comunidades técnicas, formación, incentivos y participación de grandes redes influyen en la adopción. La disponibilidad de tecnología no basta. Los redondeos pueden impedir que cada fila sume exactamente 100 %.
| Subregión de Asia-Pacífico | Valid | Not Found | Invalid |
|---|---|---|---|
Sudeste asiático | 92.4% | 7.2% | 0.4% |
Asia meridional | 89.9% | 9.8% | 0.3% |
Oceanía | 73.6% | 26.3% | 0.2% |
Asia oriental | 31.0% | 68.4% | 0.6% |
IPv6 tampoco avanza al mismo ritmo en todas partes
Oceanía y Asia meridional se acercaban a la cobertura IPv6 completa, mientras Asia oriental quedaba rezagada. Desplegar IPv6 no implanta automáticamente las prácticas necesarias para proteger su origen.
| Subregión de Asia-Pacífico | Cobertura IPv6 Valid |
|---|---|
Oceanía | 97.1% |
Asia meridional | 96.6% |
Sudeste asiático | 78.7% |
Asia oriental | 21.9% |
Indonesia: coordinación con efectos prácticos
Según APNIC, la cobertura ROA IPv4 pasó de algo más del 60 % al 90,6 % aproximadamente a finales de 2025; la medición ROV rondaba el 22 % a comienzos de 2026. IIX adoptó el rechazo de Invalid en su entorno de reflectores de rutas, incentivando ROA correctos. La publicación y su aplicación siguieron avanzando a ritmos diferentes.
India: mucha cobertura, poca validación observada
El análisis publicado por APNIC en agosto cita datos de finales de julio: cobertura válida del 88,04 % para IPv4 y del 97,91 % para IPv6, con ROV medido del 0,99 %. La misma metodología daba 3,14 % en Asia meridional y 26,92 % mundial. No permite juzgar cada red india, pero sí muestra que publicar autorizaciones no garantiza su uso.
Del ROA a la decisión de encaminamiento
El titular publica el ROA; los datos se recuperan y validan; la red comprueba las rutas y aplica una política. Sin esa cadena, una autorización correcta puede no cambiar cómo se trata un anuncio. El esquema describe el principio, no una arquitectura obligatoria.
Titular del recurso
↓ Publica el ROA
Obtención y validación de datos RPKI
↓ Autorización validada
La red verifica el origen
↓
Aplicación de la políticaQué acredita Valid
Basta con que una autorización validada que cubra la ruta permita tanto el origen como la longitud. Valid no acredita un camino óptimo, la autenticidad de todo el AS_PATH, la ausencia de fugas, la reputación de las direcciones ni la seguridad general de la red.
ROA:
203.0.113.0/24 → AS64500
BGP:
203.0.113.0/24 → AS64500
Invalid exige investigar
Hay autorizaciones que cubren la ruta, pero ninguna permite la combinación observada de origen y longitud. Puede deberse a un anuncio no autorizado, una migración mal reflejada, un maxLength demasiado restrictivo o un error de configuración. El estado no demuestra por sí solo una intención maliciosa.
Not Found no significa malicioso
No existe información validada que cubra el anuncio. Falta la referencia para esta comprobación, no una prueba de ataque. En febrero, el 37,7 % de las rutas IPv4 y el 36,1 % de las IPv6 estaban en este caso. Mejorar cobertura y validación sigue siendo necesario.
Una autorización antigua puede causar una interrupción
Cambios de proveedor, migraciones de ASN, transferencias, fusiones, desagregación y recuperación ante desastres pueden desajustar ROA y BGP. Terminar la transferencia registral no completa la transición de seguridad: también hay que coordinar el nuevo origen y la publicación o retirada de autorizaciones.
Ajustar maxLength a lo necesario
maxLength establece la longitud máxima permitida; si se omite, solo se autoriza el prefijo exacto. Un ROA limitado a /24 puede dejar Invalid un anuncio /25 aunque el ASN sea correcto. Ampliarlo sin criterio autoriza anuncios más específicos que quizá nunca se pretendieron. Es mejor declarar la necesidad real y actualizarla al cambiar la red.
Prefix: 203.0.113.0/24
Origin: AS64500
maxLength: /24
203.0.113.0/25
Validar el origen no valida todo el camino
ROV pregunta si ese ASN puede originar el prefijo. No autentica todas las relaciones del AS_PATH. Fugas, manipulación del camino, atributos anómalos y errores de política requieren controles adicionales. Un origen Valid no descarta cualquier modalidad de secuestro.
AS64510 → AS64520 → AS64530 → AS64500
RPKI e IRR tienen funciones complementarias
RPKI aporta autorización de origen verificable criptográficamente. IRR recoge políticas y relaciones de encaminamiento más amplias. Ambos pueden ayudar al filtrado y a las auditorías, pero ninguno describe por sí solo la red en funcionamiento. Deben contrastarse con BGP y los registros internos.
ROV es una responsabilidad de operación
Hay que decidir dónde validar, cómo llegan los datos a los routers, qué hacer con Invalid, cómo tratar excepciones y fallos, y quién atiende las alertas. Los equipos de encaminamiento, seguridad y recursos deben coordinarse. Crear ROA no cierra ese trabajo.
Importa la posición de cada red
Un gran proveedor de tránsito, un ISP importante o un punto de intercambio puede afectar a las rutas que ven muchos usuarios. El número de ASN que valida no cuenta toda la historia: su posición en la topología también determina el alcance de la protección.
Qué pueden aportar los IXP
Sus servidores de rutas pueden compartir la validación y aplicar políticas que reduzcan el coste de adopción para los participantes. Indonesia muestra ese efecto. Cada miembro sigue necesitando comprender sus anuncios, sus autorizaciones y sus excepciones.
Auditar primero los recursos propios
Los porcentajes globales ofrecen contexto; la continuidad del negocio depende de sus prefijos, orígenes, autorizaciones y permisos de administración. Estas ocho preguntas deben tener pruebas y responsables.
1. ¿Qué prefijos anunciamos?
Inventariar los prefijos IPv4 e IPv6 importantes, incluidos los usados en contingencias, sin limitarse a las rutas más visibles.
2. ¿Cuál debe ser el ASN de origen?
Documentar la relación entre cada prefijo y el ASN previsto. Esa intención operativa permite interpretar lo que se observa después.
Prefix → Intended Origin ASN
3. ¿Coinciden las autorizaciones?
Revisar prefijo, ASN, maxLength y validez, considerando todos los registros pertinentes para no pasar por alto una autorización que sí permite el anuncio.
4. ¿Qué se ve realmente en BGP?
Contrastar las rutas visibles en Internet con la intención, no solo con la configuración o las solicitudes de cambio.
5. ¿Está actualizado el IRR?
Buscar objetos route y route6 antiguos, contradictorios o vinculados todavía a un origen anterior.
6. ¿Quién administra RPKI?
Comprobar permisos, suplencias y recuperación de acceso. El control no debe depender de que una sola persona conserve sus credenciales.
7. ¿Los cambios activan una revisión?
Vincular cambios de proveedor, ASN, longitud y arquitectura con comprobaciones de ROA antes y después, incluidas las secuencias de publicación y retirada.
8. ¿Detectamos los Invalid?
Vigilar Invalid y orígenes inesperados, asignando recepción de alertas, investigación y vencimiento de las excepciones.
Una comprobación por cada capa
La tabla reúne registro, inventario, ASN, autorizaciones, políticas, accesos y continuidad. Conservar pruebas por fila es más útil que afirmar simplemente que RPKI está habilitado.
| Capa | Qué comprobar |
|---|---|
Registro | Recursos y organización correctos |
Prefijos IP | Inventario completo de recursos anunciados |
ASN | Origen previsto documentado |
ROA | Prefijo y origen correctamente autorizados |
maxLength | Sin exceder la necesidad operativa |
BGP | Anuncios acordes al encaminamiento previsto |
ROV | Política de validación donde corresponda |
IRR | Objetos coherentes con la intención operativa |
Supervisión | Detección de Invalid y orígenes inesperados |
Acceso | Administración RPKI recuperable |
Cambios | Las modificaciones activan una revisión de ROA |
Continuidad | Documentación útil tras cambios de personal o proveedor |
Siete conclusiones de los datos de 2026
Las observaciones muestran avances y tareas pendientes. Sirven para mejorar cada capa, no para certificar la seguridad de una red concreta.
1. Se ha superado un umbral de cobertura
Más del 60 % de las rutas IPv4 e IPv6 de la muestra de febrero eran Valid. Más titulares ofrecen autorizaciones verificables.
2. Queda una gran parte sin cubrir
Más de un tercio seguía Not Found. Sin autorización disponible, falta la referencia necesaria para validar el origen.
3. Falta extender la aplicación
Tener ROA no implica usarlos. Las políticas de producción necesitan configuración, supervisión y gestión de excepciones.
4. No hay un único ritmo regional
La diferencia entre el sudeste asiático y Asia oriental muestra cuánto puede ocultar una media mundial. El despliegue debe responder al contexto operativo local.
5. La cobertura no garantiza filtrado
India ilustra esa distinción. Las evaluaciones deben separar el estado de las autorizaciones del comportamiento de filtrado medido.
6. La precisión importa tanto como la cantidad
Un ROA desactualizado puede convertir una ruta legítima en Invalid. Añadir objetos no sustituye su mantenimiento.
7. La disciplina operativa sigue siendo necesaria
Inventarios fiables, BGP correcto, ROA al día, políticas adecuadas, seguimiento y gestión de cambios deben funcionar juntos.
La autorización debe acompañar a la red real
Una firma sólida no corrige una relación de autorización equivocada. Prefijo, origen, longitud y administración del recurso deben reflejar las operaciones. Esto conecta con la cuestión de gobernanza de NRS: quién puede cambiar esos datos y cómo participan los operadores. Estado técnico, control administrativo y mandato de representación son conceptos distintos.
Convertir autorizaciones correctas en protección efectiva
Crear ROA precisos, sincronizarlos con BGP, desplegar validación con cuidado y vigilar Invalid debe continuar durante transferencias y migraciones. Shield puede ofrecer apoyo ante riesgos de recursos. La representación mediante POA exige una decisión separada sobre alcance, duración, facultades y revocación.
Preguntas frecuentes
¿En qué se diferencian cobertura ROA y adopción ROV?
La primera describe las autorizaciones asociadas a las rutas. La segunda intenta medir su uso al validar y tratar anuncios. Sus denominadores difieren; restarlos no calcula una brecha exacta de protección.
¿Qué parte de IPv4 era Valid en 2026?
En la observación mundial de APNIC de febrero, aproximadamente 60,3 %, frente a 37,7 % Not Found y 2,0 % Invalid. Son cifras de aquella muestra.
¿Y en IPv6?
El mismo análisis indicaba 60,9 % Valid, 36,1 % Not Found y 3,0 % Invalid.
¿Hasta dónde llegaba ROV?
La medición mundial de febrero rondaba el 26,6 %; el análisis posterior cita 26,92 % para el 29 de julio. El filtrado aguas arriba influye, por lo que no cuenta directamente los ASN que configuran ROV por sí mismos.
¿Son comparables directamente ambos porcentajes?
Ayudan a estudiar el despliegue, pero uno describe autorización y el otro infiere comportamiento de filtrado. Hay que conservar fechas, muestras y metodología.
Cómo interpretar las mediciones
Nota editorial del 13 de octubre de 2026. Las cifras proceden de observaciones de APNIC de febrero y finales de julio de 2026; no son datos en directo. La cobertura de rutas y el comportamiento ROV medido tienen denominadores distintos. El filtrado aguas arriba puede proteger puntos situados aguas abajo, por lo que no se trata de un censo de ASN que configuran ROV por sí mismos. Se conservan los redondeos regionales y las fechas originales de publicación y actualización.
Fuentes y lecturas relacionadas
Elegir apoyo con conocimiento del riesgo
NRS Shield ofrece apoyo a los miembros ante riesgos relacionados con los recursos. Un mandato POA es una decisión separada: hay que comprender su alcance, duración, decisiones delegadas y revocación. Leer este artículo o solicitar ayuda no concede representación.
Conocer NRS Shield · POA y representación · Acciones actuales