LACNIC Blog > Enrutamiento > Martians, Bogons e Invalids: por qué las organizaciones deberían filtrarlos
Martians, Bogons e Invalids: por qué las organizaciones deberían filtrarlos
28/07/2026
Imagen asistida/creada por IA
Por Sergio Kleiman, IP Network Architect and Manager en Telefónica
En Internet hay prefijos que no deberían propagarse, y sin embargo ahí están. Todos sabemos que las direcciones privadas como las del RFC 1918 (192.168.0.0/16, 172.16.0.0/12 y 10.0.0.0/8) no deben anunciarse ni recibirse por BGP, pero forman parte de un conjunto más amplio: los llamados bogons, prefijos que no deberían aparecer en la tabla global de enrutamiento (DFZ).
Dentro de los bogons se encuentran los martians, prefijos que nunca deberían aparecer en la DFZ por tener un uso especial definido por estándares o por IANA. Además del RFC 1918, este conjunto incluye los espacios definidos en RFC 6890 y otros registrados por IANA. Hay un excelente video de LACNIC en detallando el tema.
El resto de los bogons corresponde principalmente a espacio de direcciones que aún no ha sido delegados ni asignados (allocated) para su uso en Internet. A diferencia de los martians, los prefijos no asignados cambian constantemente, ya que en cuanto un RIR delega o asigna un prefijo a uno de sus miembros, este deja de ser bogon y pasa a poder anunciarse legítimamente. Mientras permanece sin asignar, sin embargo, puede ser anunciado por error o de forma maliciosa a través de BGP, generando incidentes que afectan la estabilidad del sistema global de enrutamiento.
(Acceso libre, no requiere suscripción)
El caso de un anuncio clasificado como RPKI Invalid (inválido) es distinto: aquí el prefijo existe, está asignado y el ASN originador también existe. Sin embargo, el anuncio observado en BGP no coincide con la autorización publicada por el titular del recurso mediante RPKI (ROA). Esto se puede deber a un error de creación de ROA o bien a un intento de secuestro de ruta. El MANRS Observatory en julio 2026 detectó más de 4200 prefijos inválidos en Internet.
Una analogía sencilla es:
Concepto
Analogía
Martian
El domicilio no existe en el mapa.
No asignado
El domicilio existe, pero nadie debería ocuparlo todavía.
RPKI Invalid
El domicilio existe y está ocupado, pero el nombre del ocupante no coincide con el registro oficial.
Aunque estos conceptos parecen teóricos, continúan observándose diariamente en Internet y generan miles de incidentes operativos cada año.
El caso de un anuncio clasificado como RPKI Invalid (inválido) es distinto: aquí el prefijo existe, está asignado y el ASN originador también existe. Sin embargo, el anuncio observado en BGP no coincide con la autorización publicada por el titular del recurso mediante RPKI (ROA). Esto se puede deber a un error de creación de ROA o bien a un intento de secuestro de ruta. El MANRS Observatory en julio 2026 detectó más de 4200 prefijos inválidos en Internet.
Una analogía sencilla es:
Concepto
Analogía
Martian
El domicilio no existe en el mapa.
No asignado
El domicilio existe, pero nadie debería ocuparlo todavía.
RPKI Invalid
El domicilio existe y está ocupado, pero el nombre del ocupante no coincide con el registro oficial.
Aunque estos conceptos parecen teóricos, continúan observándose diariamente en Internet y generan miles de incidentes operativos cada año.
Incidentes
En un estudio detallado publicado por LACNIC sobre incidentes de enrutamiento observados entre octubre de 2023 y octubre de 2024, se registraron más de 300 anuncios bogon en América Latina y el Caribe. Lejos de ser un problema histórico, los bogons continúan apareciendo regularmente. Durante el primer semestre de 2026, el MANRS Observatory identificó más de 800 incidentes relacionados con este tipo de anuncios.
Un anuncio bogon puede provocar tráfico hacia destinos inalcanzables, generar desvíos de tráfico, dificultar la operación de la red y facilitar actividades maliciosas. Suele ser indicador de errores de configuración o de una higiene deficiente del sistema de enrutamiento.
Los RIRs y sus prefijos reservados
Los RIRs no publican directamente una lista de bogons. En cambio, publican periódicamente la información sobre recursos delegados, asignados, reservados y disponibles. A partir de esos datos es posible identificar los prefijos que aún no han sido delegados o asignados y que, por lo tanto, no deberían aparecer en la tabla global de enrutamiento. Herramientas como Team Cymru Fullbogons construyen listas dinámicas a partir de esa información y las ponen a disposición de la comunidad.
Los ROAs AS0 también están siendo utilizados por algunos RIRs como mecanismo para proteger recursos que no deben ser originados en Internet. LACNIC y APNIC publican recursos protegidos mediante AS0 dentro de sus respectivas infraestructuras RPKI.
En AFRINIC existe una política para el uso de AS0 en recursos no asignados, ratificada en 2022. Sin embargo, al momento de escribir este artículo aún no ha sido implementada.
Buenas prácticas operativas
Filtrar en BGP los prefijos no deseados es complejo por su constante cambio, y debe hacerse tanto en entrada (inbound) como en salida (outbound). Los filtros de entrada evitan que martians, no asignados o prefijos inválidos ingresen a la red desde proveedores, peers o clientes; los de salida evitan que errores internos propaguen estos prefijos hacia el resto de Internet. Ambos son igual de importantes: los filtros de entrada protegen la infraestructura de la organización, mientras que los filtros de salida protegen al resto de Internet de errores originados internamente o por redes de clientes.
Cuando se detecta un bogon, una ruta RPKI Invalid u otro incidente, contactar rápidamente al operador responsable acelera la resolución. Por ello conviene mantener actualizados los contactos en WHOIS e IRR, verificar la información publicada en PeeringDB, y asegurar que los correos publicados estén monitoreados. Muchas incidencias se resuelven en minutos cuando el canal de comunicación es claro.
Cinco recomendaciones básicas
Estas son recomendaciones básicas para proteger la red de prefijos indebidos:
Filtrar de manera estática los martians usando los registros de espacio especial de IANA, y aplicar filtros a los anuncios de clientes y peers, permitiendo solo los prefijos autorizados.
Utilizar validación RPKI (por ejemplo, con FORT) para filtrar anuncios RPKI Invalid y prefijos cubiertos por ROAs AS0.
Opcionalmente utilizar servicios como Team Cymru Fullbogons para recibir actualizaciones dinámicas de prefijos bogon y automatizar su filtrado.
Mantener actualizados y validar periódicamente los datos de contacto en WHOIS, IRR y PeeringDB.
Participar en la iniciativa MANRS y utilizar su observatorio para monitorear el estado de seguridad y cumplimiento de los ASNs de la organización.
Conclusiones
Los bogons y rutas RPKI Invalid continúan apareciendo diariamente en las tablas de enrutamiento globales. Aunque la mayoría de estos incidentes provienen de errores operativos y no de actividades maliciosas, sus efectos pueden extenderse mucho más allá de la red donde se originan.
Filtrar prefijos, implementar validación RPKI, utilizar ROAs AS0 y utilizar fuentes actualizadas de información sobre bogons son medidas relativamente simples que contribuyen a mejorar la higiene del enrutamiento global. En Internet, un prefijo que no debería ser propagado nunca debería anunciarse.
Ya sea un bogon o un prefijo RPKI Invalid, la mejor manera de evitar incidentes es impedir su propagación desde el origen.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
