AFRINIC y la economía de la fragilidad de la base de datos IRR

Cuando varios registros responden la misma ruta

El trabajo del servidor de rutas se ejecuta antes del amanecer porque el intercambio quiere tener sus filtros listos antes de que comience el día laboral. Extrae de varias fuentes del Registro de Enrutamiento de Internet, actualiza los datos reflejados, expande los AS-SET de los miembros, construye listas de prefijos y verificaciones de origen, y emite una configuración que decidirá qué anuncios acepta el intercambio. La mayoría de las mañanas transcurren sin incidentes. Esta mañana, el trabajo se detiene en un prefijo IPv4 administrado por AFRINIC cuya historia cambia según la fuente consultada.

Una fuente IRR tiene un objeto de ruta para el prefijo con un AS de origen que pertenece a un antiguo proveedor de tránsito. Otra tiene un objeto más nuevo para una red de cliente que dice haberse trasladado a un centro de datos regional. Una tercera fuente refleja una entrada más antigua que aún parece plausible porque el nombre del mantenedor se parece al titular del recurso. Un AS-SET suministrado por el cliente se expande de manera diferente según el orden de las fuentes. En una expansión, el prefijo está cubierto a través del cono de clientes de un revendedor. En otra, desaparece porque un conjunto de rutas hace referencia a un AS-SET que existe en un repositorio diferente. Una verificación pública de RPKI ayuda con parte de la pregunta, pero no explica por qué las vistas del IRR difieren o qué relación operativa es actual. El ingeniero del intercambio puede rechazar la ruta, aceptarla, hacer una excepción manual, pedir cartas o retrasar el ticket. Ninguna de esas opciones es gratuita.

Esa es la escena práctica detrás de la fragilidad del Registro de Enrutamiento de Internet. El problema no es solo que un único objeto de ruta pueda estar equivocado, obsoleto o ser difícil de corregir. El problema más amplio es que los datos de política de enrutamiento están distribuidos en múltiples repositorios con diferentes historias, reglas de actualización, prácticas de autenticación, horarios de replicación, hábitos de limpieza y reputaciones sociales. Un operador o IXP rara vez consume "el IRR" como una sola base de datos. Consume un conjunto seleccionado de fuentes, en un orden seleccionado, a través de herramientas que hacen suposiciones sobre duplicados, recursividad, pertenencia a conjuntos de rutas y preferencia de fuente. Cuando esas suposiciones chocan con registros contradictorios, el diseño de la base de datos se convierte en un evento económico.

Las partes afectadas son más amplias que los ingenieros de redes. Un proveedor de tránsito necesita saber en qué fuente confiar antes de aprovisionar. Un proveedor de nube necesita confianza antes de anunciar el espacio del cliente. Un servidor de rutas de IXP necesita filtros que protejan a los participantes sin excluir redes locales legítimas. Un corredor debe explicar por qué los registros IRR obsoletos no reducirán el precio ni retrasarán la transferencia. Un comprador, prestamista o asegurador necesita saber si la aceptación operativa sobrevivirá a la debida diligencia. A un cliente que compra conectividad no le importa la sintaxis de RPSL, pero sentirá el costo si las rutas no son aceptadas rápidamente.

AFRINIC es la prueba de estrés útil porque su entorno institucional hace visible el costo oculto. La región ha enfrentado una larga crisis de gobernanza, litigios, cuestiones de administración judicial, turbulencias electorales y preocupación pública sobre la integridad de los registros históricos de direcciones. La escasez de IPv4 ha hecho que cada bloque enrutable sea más relevante económicamente. En ese contexto, los datos de enrutamiento adyacentes al registro no son un apéndice administrativo. Se convierten en parte de la infraestructura de confianza del mercado. Si los datos son coherentes, terceros pueden decir que sí a un costo menor. Si están fragmentados, cada participante debe decidir cuánto riesgo legal, operativo y reputacional absorber.

El marco correcto no es la lealtad institucional. No se trata de que AFRINIC, ni ningún otro RIR, deba ser confiable porque reclama un mandato comunitario. Tampoco se trata de que los IRR privados deban ser confiables porque los operadores los han utilizado durante años. La pregunta es más difícil: cuando varias bases de datos dan respuestas plausibles pero contradictorias sobre la política de enrutamiento en torno a un recurso numérico escaso, ¿en qué respuesta debe basarse un upstream, intercambio, plataforma de nube, corredor, comprador, prestamista o cliente, y quién paga cuando la respuesta es incorrecta?

RPSL hizo legible la política de enrutamiento, no autovalidable

El sistema del Registro de Enrutamiento de Internet surgió de una necesidad operativa razonable. BGP permite a las redes anunciar rutas, pero no proporciona, por sí mismo, una explicación pública completa de lo que una red pretende originar, transitar o aceptar. La política de enrutamiento es demasiado importante para dejarse solo en configuraciones de enrutadores privados e hilos de correo electrónico. RPSL, definido en el RFC 2622, dio a los operadores un lenguaje estructurado para expresar esa política. Incluye objetos como route, route6, aut-num, as-set, route-set y mntner. Estos no son instrumentos legales. Son objetos de base de datos diseñados para que las relaciones de enrutamiento puedan describirse de una forma que el software pueda consultar.

Esa distinción suele ser la primera víctima de la automatización. Un objeto route asocia un prefijo con un sistema autónomo de origen. Un objeto route6, descrito en la extensión multiprotocolo del RFC 4012, desempeña el papel comparable para IPv6. Un objeto mntner identifica al mantenedor que puede autenticar cambios en otros objetos. Los AS-SET y route-sets permiten a los operadores describir colecciones de redes o rutas, a menudo de forma recursiva. A partir de estas piezas, una red puede generar filtros para un cliente o par. La sintaxis es estrecha, pero las consecuencias son amplias porque la salida se convierte en política del enrutador.

La promesa inicial era la coordinación. Si los operadores publicaban sus políticas de enrutamiento previstas en registros públicos o semipúblicos, otros operadores podían tomar decisiones más seguras. Los filtros podían generarse en lugar de construirse manualmente. Los cambios podían revisarse contra un modelo de política visible. Los errores serían más fáciles de detectar. La coordinación a nivel de Internet tendría una gramática común. El RFC 2725, escrito a medida que aumentaban las preocupaciones de seguridad en torno al IRR, capturó el cambio: a medida que los datos del IRR se volvían más útiles para las operaciones, sus requisitos de integridad y seguridad se hicieron más fuertes. Una base de datos de coordinación mantenida de forma flexible es una cosa. Una base de datos que alimenta filtros es otra.

RPSL no hizo que los datos fueran autovalidables. Los hizo legibles. Esa diferencia es importante en cada disputa fragmentada del IRR. Si un objeto de ruta existe en un repositorio, el objeto puede ser analizado. Puede ser reflejado. Puede ser comparado con un anuncio. Puede ser incluido en una lista de prefijos. Pero la existencia del objeto no prueba que el titular del recurso lo haya autorizado, que el AS de origen siga vigente, que el mantenedor aún represente a la parte relevante, que un duplicado en otro lugar sea falso, o que una expansión de conjunto de rutas a través de fuentes refleje las relaciones comerciales presentes. El formato hace que una afirmación sea legible por máquina. No hace que la afirmación sea verdadera.

Esa limitación alguna vez importó menos porque lo que estaba en juego era menor y la cultura operativa estaba más basada en relaciones. El mercado moderno es menos indulgente. IPv4 es escaso; la automatización es más profunda; la incorporación a la nube, los servidores de rutas, los servicios de seguridad administrados, el peering remoto y las transferencias de direcciones dependen de evidencia externa repetible. Un registro que antes ayudaba a los ingenieros a coordinarse ahora influye en si el capital, la conectividad y las relaciones con los clientes pueden moverse.

La lección institucional es simple pero incómoda. Una base de datos de registro que afecta los filtros no puede gobernarse como si fuera solo un tablón de anuncios conveniente. Sin embargo, tampoco debe convertirse en un punto de control discrecional amplio sobre la actividad del mercado. La legitimidad de la base de datos proviene de la estrechez y fiabilidad de su función de libro mayor. Debe registrar, autenticar y exponer declaraciones operativas de manera que reduzcan la incertidumbre. No debe pretender que cada entrada de política de enrutamiento es un juicio de propiedad, un plebiscito comunitario o un instrumento de soberanía institucional.

Es por eso que la fragmentación es tan costosa. Si el mismo vocabulario RPSL aparece en muchos repositorios, cada uno con un modelo de autoridad diferente, entonces el mercado recibe declaraciones que parecen comparables pero descansan sobre bases diferentes. El objeto de ruta en una fuente puede estar estrechamente vinculado a un registro de titular de RIR. El objeto de ruta en otra puede haber sido creado por un operador de red hace años bajo una práctica de mantenedor menos restrictiva. Un objeto reflejado puede estar rezagado respecto a la fuente o preservar una vista eliminada. Un conjunto de rutas puede hacer referencia a objetos que existen solo si la herramienta consulta los repositorios adecuados. La gramática común enmascara la diferencia institucional subyacente.

La fragmentación convierte una herramienta de coordinación en un peaje de mercado

La fragmentación a veces se describe como una molestia para las herramientas de filtrado. Eso es demasiado suave. En un mercado de direcciones escasas, los datos fragmentados del IRR son un sistema de peajes. Cobra a cada parte que debe investigar, explicar, conciliar, anular, documentar o asegurar en torno a registros contradictorios. El peaje no se paga a un único recaudador. Se paga en trabajo, retraso, descuentos por riesgo, incorporaciones fallidas, peering bloqueado, excepciones manuales, revisión legal y desconfianza entre contrapartes.

El primer costo es la búsqueda. Un operador no puede simplemente preguntar si un prefijo tiene un objeto IRR. Debe preguntar qué fuentes reconoce su política, si esas fuentes son autorizadas para la región del recurso, si las copias reflejadas están actualizadas, si los duplicados deben colapsarse o tratarse como conflicto, y si un objeto en una fuente privada o no RIR debe permitirse anular una entrada faltante u obsoleta en una fuente vinculada al RIR. Una red pequeña solo ve un ticket. Un operador grande ve un conjunto de reglas. Entre ambos se sitúa un costo de transacción que a menudo decide si la red pequeña recibe servicio rápidamente.

El segundo costo es la explicación. Cuando un cliente dice: "el objeto de ruta está allí", el upstream debe preguntar dónde. Si el objeto está en RADB pero no en el IRR del RIR relevante, ¿es suficiente? Si está en una fuente de AFRINIC pero un duplicado en otra fuente apunta a un origen diferente, ¿qué objeto gana? Si el cliente tiene un AS-SET que se expande a través de varios repositorios, ¿acepta el upstream todas las fuentes o solo aquellas en una lista preferida? Si el proveedor anterior del cliente creó objetos en su propio mantenedor, ¿debe el cliente eliminarlos antes de que un nuevo proveedor acepte la ruta? Cada pregunta es razonable. Juntas hacen que la conectividad se sienta como un litigio con otro nombre.

El tercer costo es la competencia asimétrica. Los operadores grandes pueden mantener equipos de registro, construir políticas específicas de fuente, ejecutar verificaciones regulares de objetos obsoletos, monitorear diferencias de filtros y saber a quién contactar. Los ISP africanos más pequeños, universidades, agencias públicas y empresas pueden no tener esa capacidad. Pueden heredar registros antiguos de contratistas. Pueden depender de los upstreams para crear objetos. Pueden no saber que un duplicado en un IRR distante afectará a un servidor de rutas en un mercado diferente. La fragmentación, por lo tanto, favorece a los actores con suficiente escala para gestionar la ambigüedad. Castiga a aquellos para quienes la alcanzabilidad de Internet debería ser infraestructura ordinaria.

El cuarto costo es el poder de negociación. Si un comprador de espacio IPv4 descubre que el bloque tiene entradas IRR conflictivas, puede exigir un descuento o una retención en depósito. Si un prestamista ve que el servicio dependiente de direcciones de un prestatario depende de excepciones manuales en los operadores, puede tratar el activo como garantía menos fiable. Si un proveedor de nube requiere limpieza antes de la incorporación, el titular puede perder tiempo de migración o negociar desde una posición de debilidad. Los registros fragmentados no tienen que ser maliciosos para cambiar el precio. Solo necesitan hacer que el activo sea más difícil de confiar.

El quinto costo es la seguridad. Los duplicados obsoletos pueden preservar viejas reclamaciones de origen. Las fuentes débilmente autenticadas pueden dar legitimidad aparente a rutas que deberían ser desafiadas. Los AS-SET demasiado amplios pueden incluir downstreams que ya no pertenecen. El retraso del espejo puede hacer que un registro corregido parezca no resuelto. Si los operadores reaccionan ignorando los datos del IRR por completo, pierden una capa defensiva útil. Si reaccionan confiando en cada fuente indiscriminadamente, amplían la superficie de ataque. Si reaccionan confiando solo en una lista de fuentes estrecha, las redes legítimas con registros incompletos pueden ser excluidas. La fragmentación obliga a la política de seguridad a elegir entre daños imperfectos.

El sexto costo es la confianza institucional. En un entorno de registro estable, los operadores toleran cierto desorden porque saben cómo funciona la corrección. Bajo estrés, cada ambigüedad se lee de manera más oscura: ¿objeto obsoleto, control de registro débil, brecha administrativa, bloqueo del titular, o elusión del libro mayor regional? La historia reciente de AFRINIC hace que esas preguntas sean más difíciles de descartar. El problema de datos se convierte en un problema de gobernanza porque los terceros no separan las bases de datos de las instituciones que las mantienen o no las mantienen.

La fragmentación, por lo tanto, cambia el significado económico de un registro IRR. En un entorno unificado y bien gobernado, el registro reduce el costo de la confianza en el enrutamiento. En un entorno fragmentado, el registro puede desplazar el costo hacia afuera. El servidor de rutas, el upstream, la plataforma de nube, el corredor y el comprador se convierten en adjudicadores no remunerados de conflictos de bases de datos. No están bien situados para hacer ese trabajo, pero el sistema de enrutamiento no les da escapatoria. Los paquetes necesitan una decisión.

La selección de fuentes es una decisión económica disfrazada de ingeniería

El RFC 7454, el documento de Operaciones y Seguridad de BGP, trata la selección de fuentes como una preocupación práctica para los operadores. Discute el filtrado de prefijos, filtros de clientes derivados de registros de enrutamiento, recursividad de AS-SET, la necesidad de actualizar filtros y la dificultad de elegir qué fuentes IRR utilizar. El texto es operativo, pero la implicación económica es grande: una regla de selección de fuentes es una política de confianza. Decide qué afirmaciones de la base de datos son lo suficientemente baratas como para confiar en ellas y qué afirmaciones requieren escalación manual o rechazo.

Considere un operador que acepta objetos de AFRINIC, RIPE, APNIC, ARIN y RADB al construir filtros. Esa política maximiza la inclusividad. Reduce los tickets de soporte de clientes cuyos datos residen en fuentes más antiguas o no regionales. También aumenta la exposición a duplicados obsoletos, historiales de autorización más débiles y sorpresas de recursividad entre fuentes. Ahora considere un operador que prefiere solo la fuente RIR relevante para cada prefijo e ignora los IRR privados donde existe un IRR de RIR. Esa política puede mejorar la alineación de autoridad, pero puede romper clientes legítimos cuyos registros fueron mantenidos históricamente en otro lugar o cuyos objetos creados por el proveedor viven fuera de la fuente regional. Un tercer operador puede usar un orden de preferencia de fuentes, aceptando el primer objeto coincidente. Esa regla es eficiente hasta que la fuente preferida está obsoleta y una fuente menos preferida está actualizada.

Estas elecciones parecen técnicas porque están codificadas en scripts. Son económicas porque asignan el costo de la incertidumbre. Una política de fuente estricta hace que los clientes limpien sus registros antes de recibir servicio. Eso puede mejorar la base de datos, pero desplaza la mano de obra al cliente y puede excluir redes más pequeñas. Una política flexible acepta rutas más rápido, pero desplaza el riesgo a la red del operador y sus pares. Una política de excepción manual preserva la flexibilidad, pero crea ventajas para los internos y cuellos de botella de soporte. No existe una política de fuente neutral. Solo hay diferentes formas de asignar el costo.

Para los prefijos administrados por AFRINIC, la selección de fuentes es inusualmente sensible porque los registros de la región pueden contener múltiples historias a la vez. Un prefijo puede tener un antiguo objeto de ruta en un IRR comercial porque un upstream lo creó mucho antes de que el titular usara las herramientas IRR propias de AFRINIC. Puede tener un objeto vinculado a AFRINIC creado durante una limpieza posterior. Puede tener referencias a conjuntos de rutas que asumen herramientas al estilo RIPE porque un proveedor de tránsito europeo mantenía la política del cliente. Puede tener entradas de IRR privadas utilizadas por un proveedor de nube o DDoS. Cada fuente puede ser plausible desde la perspectiva de la parte que la creó. La plausibilidad no es lo mismo que la autoridad actual.

La preferencia de fuente conflictiva también afecta la competencia entre proveedores. Si la política de un upstream dominante acepta un conjunto más amplio de fuentes, puede incorporar clientes más rápidamente que un proveedor más pequeño con filtros más estrictos. Si una plataforma de nube exige un tipo de limpieza y un proveedor de tránsito exige otro, el cliente puede elegir el camino de menor fricción administrativa en lugar del mejor servicio técnico. Si un servidor de rutas de IXP usa reglas de fuente conservadoras, los miembros con registros desordenados pueden evitar el peering multilateral y seguir dependiendo del tránsito. La política de base de datos moldea entonces la estructura del mercado indirectamente.

La selección de fuentes también puede convertirse en una forma oculta de elección jurisdiccional. Un objeto de ruta para un prefijo administrado por AFRINIC en un repositorio no AFRINIC puede ser más fácil de crear o preservar que uno vinculado a los registros de titulares de AFRINIC. Un operador que acepta ese objeto no está transfiriendo formalmente la autoridad lejos de AFRINIC, pero está decidiendo que una fuente no AFRINIC puede soportar la confianza operativa. En casos normales, eso puede ser inofensivo. En casos controvertidos, importa. El mercado puede enrutar según la base de datos que es más fácil de usar, no según la base de datos que mejor refleja el libro mayor de recursos.

La solución no es exigir una lista de fuentes universal. Los operadores tienen diferentes tolerancias al riesgo, bases de clientes y entornos legales. La solución es la transparencia y expectativas más estrechas. Los operadores y operadores de servidores de rutas deben publicar cómo usan las fuentes, cómo manejan los duplicados, con qué frecuencia actualizan los espejos, cómo tratan los conflictos entre datos RIR y no RIR, y qué evidencia se necesita para excepciones. Los registros deben publicar suficientes metadatos para que los operadores distingan la autoridad de la fuente en lugar de adivinar. Los clientes deben poder saber de antemano si su postura IRR pasará los filtros de una red determinada. Una regla de selección de fuentes oculta es una regla de mercado oculta.

En el caso de AFRINIC, la prioridad institucional debería ser hacer que la fuente vinculada a AFRINIC sea lo suficientemente predecible como para que los operadores tengan menos razones para buscar en todas las bases de datos la respuesta que prefieren. Eso no significa hacer de AFRINIC un gobernador del mercado. Significa fortalecer la función de libro mayor para que la fuente regional se convierta en un punto de referencia de bajo costo. Proteger el libro mayor, no el guardián: el valor del registro radica en hacer que la confianza sea más barata, no en convertir la preferencia de fuente en poder discrecional.

El retraso del espejo y los duplicados obsoletos crean falsa continuidad

Los datos del IRR a menudo viajan a través de espejos. El mirroring es útil porque los operadores necesitan acceso local, rápido y resistente a la información del registro. También crea una nueva clase de fragilidad. Un espejo puede quedar rezagado respecto a la fuente autorizada. Puede preservar una vista después de una corrección. Puede fallar silenciosamente. Puede actualizar una fuente mientras otra permanece obsoleta. Puede dar a la automatización la impresión de que un registro todavía existe o todavía tiene cierto origen cuando el repositorio subyacente ha seguido adelante.

El retraso del espejo es fácil de subestimar porque la mayoría de los retrasos son inofensivos. Si una actualización de filtro se retrasa unas horas respecto a una actualización rutinaria de conjunto de rutas, no sucede nada dramático. El problema no es el retraso promedio. Es el retraso durante cambios controvertidos o económicamente significativos. Un titular elimina un objeto obsoleto después de dejar un antiguo proveedor. El conjunto de rutas del antiguo proveedor todavía hace referencia al objeto a través de un espejo. Un servidor de rutas de IXP se actualiza desde una copia rezagada y continúa aceptando una ruta que el titular cree que ha sido retirada. O un cliente crea un nuevo objeto para una migración, pero el espejo elegido por el proveedor de tránsito no se ha puesto al día, por lo que el ticket se estanca. La diferencia entre una vista actual y una obsoleta se convierte en una interrupción del negocio.

Los duplicados obsoletos son más duraderos que el retraso del espejo. Un objeto duplicado puede permanecer en otra fuente mucho después de que la relación comercial original terminó. El antiguo upstream puede haberlo creado para un cliente y nunca limpiarlo. El cliente puede no saber que existe. El mantenedor puede ser inalcanzable. La fuente puede tener pocos incentivos para eliminarlo porque el objeto no está vinculado al libro mayor de recursos de esa fuente. Años después, los filtros automatizados todavía ven una afirmación plausible de prefijo-origen. Si el titular actual quiere cambiar de proveedor, puede tener que explicar por qué el objeto antiguo no debe gobernar la aceptación. Si un actor malicioso quiere cobertura, el objeto antiguo puede proporcionar suficiente ambigüedad para retrasar el rechazo.

La falsa continuidad es el peligro económico. Un objeto obsoleto hace que una relación pasada parezca presente. Un objeto reflejado hace que una vista corregida parezca no resuelta. Un AS-SET recursivo que incluye un antiguo downstream hace que un antiguo cliente parezca parte del cono actual. La base de datos no necesita decir "esto es autoritativo". Solo necesita ser consumida por suficientes herramientas para crear dependencia. En un mercado donde la velocidad importa, la continuidad aparente es valiosa. Permite a una parte decir: "los datos siempre han lucido así", incluso cuando la supervivencia de los datos es un fallo de mantenimiento.

El contexto de AFRINIC aumenta el precio de la falsa continuidad. Las preocupaciones históricas sobre la integridad de los registros significan que los datos inactivos u obsoletos no son simplemente desorden. Pueden convertirse en una sombra probatoria alrededor del escaso espacio IPv4. Un comprador que revisa un bloque de la región AFRINIC puede preguntar si los antiguos objetos IRR sobreviven en fuentes no regionales. Un proveedor de nube puede preguntar si un origen anterior todavía aparece en algún lugar que consuma. Un corredor puede necesitar limpiar antiguas referencias de conjuntos de rutas antes de cerrar. Un upstream puede negarse a aceptar un nuevo origen hasta que el antiguo sea eliminado. Cada paso es racional, pero juntos convierten la limpieza fragmentada de la base de datos en una condición previa del mercado.

Los duplicados obsoletos también crean incentivos perversos. Una parte que se beneficia de la ambigüedad puede tener pocas razones para eliminar datos antiguos. Un antiguo proveedor puede no priorizar la limpieza para un cliente perdido. Un revendedor puede preferir AS-SET amplios porque facilitan la incorporación. Una fuente débil puede preferir el volumen y la conveniencia sobre las verificaciones rigurosas de autoridad. Una fuente estricta puede eliminar registros pero no tener poder sobre las copias en otros lugares. El resultado es una externalidad negativa: el costo de los datos obsoletos es soportado por el titular actual, el nuevo proveedor y las redes que deben filtrar de manera segura, no necesariamente por la parte que dejó el registro obsoleto.

La respuesta práctica debería ser la disciplina del ciclo de vida. Los registros utilizados para filtros de enrutamiento necesitan marcas de tiempo, procedencia de la fuente, visibilidad de eliminación, estado de mirroring e indicadores de conflicto que las herramientas puedan entender. Los operadores necesitan informes de objetos obsoletos que muestren cuándo un par prefijo-origen aparece en múltiples fuentes con diferentes orígenes o mantenedores. Los registros y los principales operadores de IRR deben facilitar la limpieza a los titulares que puedan demostrar autoridad actual, preservando suficiente historial de auditoría para evitar reescrituras sigilosas. El software del servidor de rutas debería exponer los conflictos en lugar de ocultarlos detrás de reglas de primera coincidencia. Nada de esto requiere convertir el IRR en un tribunal de propiedad. Requiere admitir que los datos obsoletos no son neutrales cuando los filtros los consumen.

También hay un punto cultural. Los ingenieros a menudo toleran registros desordenados porque Internet siempre ha funcionado con una mezcla de datos formales y soluciones informales. Esa tolerancia era útil en una red en crecimiento. Es menos útil cuando los escasos bloques IPv4, la incorporación a la nube y la diligencia financiera dependen de registros que los externos no pueden interpretar fácilmente. En ese entorno, un duplicado obsoleto no es solo un objeto antiguo. Es una reclamación sobre el costo de confianza de otra persona.

La autenticación sin autorización no resuelve la confianza

Las discusiones de seguridad del IRR a menudo comienzan con la autenticación. ¿Controlaba el usuario la credencial del mantenedor? ¿Era válida la contraseña, clave PGP, cuenta del portal u otro método? ¿Se envió la actualización a través del canal adecuado? Esas preguntas importan. Una base de datos que no puede autenticar actualizaciones no es lo suficientemente confiable para la generación de filtros. Pero la autenticación no es autorización. El RFC 2725 llamó la atención sobre esa separación hace más de dos décadas, y la distinción sigue siendo central para la economía fragmentada del IRR.

La autenticación prueba el control de una credencial. La autorización pregunta si el titular de la credencial tenía el derecho de hacer esta declaración de política de enrutamiento particular para este recurso particular en este momento particular. Un antiguo contratista aún puede controlar un mantenedor. Un proveedor de tránsito puede haber sido autorizado para crear un objeto de ruta para un cliente durante el servicio, pero no para preservarlo después de la terminación. Un revendedor puede tener autoridad para incluir un downstream en un AS-SET para un producto, pero no para autorizar un nuevo AS de origen. Un buzón corporativo puede existir después de que el empleado que lo usaba se haya ido. Una cuenta de registro puede ser técnicamente válida mientras la autoridad corporativa subyacente está en disputa. Los controles de inicio de sesión sólidos reducen la suplantación; no responden al mandato.

La fragmentación multiplica el problema porque cada fuente puede trazar la línea autenticación-autorización de manera diferente. Un repositorio puede vincular estrechamente la creación de objetos de ruta a un titular de recursos o un modelo de autorización jerárquico. Otro puede permitir la creación basada en el control del mantenedor y la confirmación del AS de origen. Un tercero puede preservar objetos antiguos bajo prácticas heredadas. Un cuarto puede permitir que los mantenedores de proveedores creen objetos de cliente por conveniencia operativa. Cuando los filtros consumen todos ellos como datos RPSL comparables, el mercado pierde de vista los diferentes supuestos de autoridad detrás de los registros.

Para los prefijos de la región AFRINIC, la distinción no es teórica. El estrés de gobernanza, los litigios y las preocupaciones sobre la integridad de los registros hacen que las preguntas sobre el mandato sean más probables de surgir. ¿Quién puede actuar por una empresa en administración judicial, liquidación o disputa de la junta directiva? ¿Quién puede actualizar registros durante un período supervisado por el tribunal? ¿Qué sucede cuando una asignación histórica está vinculada a una institución pública cuyas operaciones de red actuales han sido subcontratadas? ¿Cómo debe un registro u operador tratar a un mantenedor controlado por un proveedor de servicios que ya no tiene al cliente? Estas son preguntas de autorización. Una contraseña de mantenedor válida no puede responderlas por sí sola.

La economía de esta distinción es severa porque los mercados aman las credenciales. Las credenciales son rápidas. Encajan en el software. Permiten cerrar tickets. La autorización es más lenta. Implica contratos, cartas, autoridad corporativa, registros de registro, contexto histórico y a veces la ley. Un mercado bajo presión se sentirá tentado a aceptar la autenticación como sustituto de la autorización porque el retraso es costoso. Esa tentación crea una superficie de ataque para quien pueda preservar u obtener credenciales sin autoridad actual. También crea una barrera para los titulares legítimos que carecen de credenciales antiguas pero pueden probar el derecho actual.

El error inverso también es costoso. Si cada actualización del IRR requiere una reprobación completa de la autoridad del recurso, los cambios rutinarios de enrutamiento se vuelven demasiado costosos. Los operadores pequeños evitarán actualizar registros. Los proveedores mantendrán AS-SET amplios para reducir la fricción. Los clientes dependerán de cartas privadas y excepciones manuales. Los filtros se volverán menos precisos porque el costo de la publicación precisa es demasiado alto. El objetivo no es la documentación máxima. Es la autorización proporcional: más evidencia para cambios que alteran el riesgo o el significado económico, menos fricción para el mantenimiento rutinario estable, corrección rápida donde la autoridad obsoleta es evidente, y aviso claro donde las partes pueden verse afectadas.

En la práctica, esto significa que las fuentes IRR deben exponer el contexto de autoridad, no solo el contenido del objeto. Un objeto de ruta creado bajo autenticación directa del titular del recurso debe ser distinguible de uno creado por un mantenedor de proveedor. Un registro vinculado a la confirmación del AS de origen debe ser distinguible de un objeto heredado histórico. Un objeto disputado o recientemente corregido debe llevar un estado lo suficientemente visible para que los operadores lo traten con cuidado. La evidencia privada no necesita ser publicada. Pero la base de datos no debe obligar a cada usuario downstream a inferir la autoridad a partir de la sintaxis del objeto y los nombres de los mantenedores.

Aquí es donde importa el principio de continuidad estrecha. Los registros deben actuar como utilidades de continuidad, no como gobernadores discrecionales de cada uso del mercado. Deben mantener el libro mayor lo suficientemente confiable como para que terceros puedan interpretar las declaraciones operativas. Deben resistir el blanqueo de mandato, donde una amplia invocación de comunidad o administración convierte la coordinación técnica en control institucional sobre los resultados comerciales. Pero también deben resistir el fracaso opuesto, donde una higiene de autenticación débil permite que viejas credenciales y fuentes fragmentadas gobiernen la alcanzabilidad presente. Una utilidad estrecha aún necesita procedimientos sólidos. Solo usa el procedimiento para proteger la confianza, no para acumular poder discrecional.

La recursividad de AS-SET hace que los pequeños errores viajen lejos

Los AS-SET son una de las partes más útiles y peligrosas del ecosistema IRR. Permiten a una red publicar un conjunto de ASN que deben ser tratados como parte de su cono de clientes o política de enrutamiento. Un proveedor de tránsito puede pedir a un cliente un AS-SET, expandirlo recursivamente, encontrar los ASN dentro, y luego construir filtros para los prefijos asociados con esos ASN. Sin esta maquinaria, el mantenimiento de filtros de clientes sería mucho más manual. Con ella, un solo servidor de rutas u operador puede procesar muchas relaciones de enrutamiento automáticamente.

El peligro es la recursividad. Un AS-SET puede incluir otros AS-SET. Esos AS-SET pueden residir en diferentes fuentes. Pueden incluir ASN de clientes obsoletos, revendedores downstream, route-sets, u objetos mantenidos bajo diferentes estándares de autoridad. La expansión puede depender de la fuente. Una herramienta que busca en todas las fuentes puede producir un conjunto más grande que una herramienta que se restringe a las fuentes preferidas. Una herramienta que se detiene en la primera coincidencia puede tratar una base de datos como decisiva. Una herramienta que falla cerrado puede rechazar clientes legítimos. Una herramienta que falla abierto puede aceptar rutas a través de una cadena que nadie ha auditado recientemente. La advertencia del RFC 7454 sobre la recursividad de AS-SET y los filtros derivados del IRR no es una nota académica al pie. Es el punto operativo en el que la fragmentación de la base de datos se convierte en configuración del enrutador.

En un caso de la región AFRINIC, el problema de recursividad puede estar disfrazado por la estratificación comercial ordinaria. Un pequeño ISP compra tránsito de un operador regional. El AS-SET del operador incluye un revendedor. El revendedor incluye ASN de clientes. Algunos de esos clientes tienen prefijos de AFRINIC, otros de otras regiones, algunos arrendados o delegados, algunos trasladados a proveedores de nube o DDoS. Los objetos fueron creados a lo largo de muchos años por diferentes mantenedores. Cuando un servidor de rutas de IXP expande el AS-SET de nivel superior, puede importar toda una historia de relaciones comerciales, no meramente la política actual del miembro. Si la expansión es demasiado amplia, los clientes obsoletos pueden permanecer enrutables. Si es demasiado estrecha, los downstreams legítimos pueden desaparecer.

El efecto económico es de escala. Un solo objeto de ruta obsoleto afecta una afirmación de prefijo-origen. Un miembro de AS-SET obsoleto puede afectar muchos prefijos. Un route-set amplio puede afectar todos los prefijos asociados con varios ASN. Un objeto recursivo en una fuente confiable puede importar datos menos confiables de otra fuente. El radio del error crece con cada capa de indirección. Eso hace que la higiene de AS-SET sea un problema de mercado. El costo de un conjunto inexacto no solo lo soporta el mantenedor, sino cada upstream, servidor de rutas, cliente y par que depende de su expansión.

La recursividad también crea opacidad. Un cliente puede no saber por qué el filtro de un upstream incluye o excluye una ruta. La respuesta puede estar enterrada en una regla de selección de fuentes varios niveles profunda. El ticket de soporte puede decir "desajuste IRR" cuando el problema real es que el AS del cliente falta en un conjunto downstream, o que un AS-SET duplicado en otra fuente está siendo preferido, o que una antigua entrada de revendedor todavía se está expandiendo. Las partes discuten sobre el prefijo visible mientras la causa se encuentra en una cadena oculta de objetos RPSL.

Para los proveedores de nube y grandes redes de contenido, el problema de AS-SET se cruza con la escala de incorporación. Necesitan verificar muchos clientes y evitar convertirse en puntos de origen para espacio cuestionable. El manejo estricto de AS-SET reduce el riesgo de abuso pero aumenta la fricción con el cliente. El manejo flexible mejora la velocidad de incorporación pero puede importar políticas obsoletas o demasiado amplias. Para corredores y compradores, la dispersión de AS-SET es ruido de diligencia debida. Un bloque puede parecer limpio en los registros del titular pero aparecer en route-sets asociados con antiguos proveedores, revendedores o clientes. Antes de que el dinero se mueva, alguien debe determinar si esas referencias son operativamente significativas, obsoletas o dañinas.

La política correcta no es abandonar los AS-SET. Siguen siendo prácticos y ampliamente utilizados. La política es tratar la expansión recursiva como una cadena de confianza con eslabones débiles visibles. Las herramientas deben informar rutas de fuente, nombres de conjuntos duplicados, referencias entre fuentes, antigüedad de la expansión, crecimiento inusual y conflictos con datos conocidos del titular u origen. Los operadores deben evitar aceptar recursividad arbitraria a través de todas las fuentes sin considerar la autoridad. Los registros deben ayudar a los titulares a encontrar dónde aparecen sus prefijos y ASN en conjuntos que no controlan. Los principales IXP y operadores deben publicar cómo manejan la recursividad entre fuentes. Cuanto más dependa un mercado de la automatización, más debe la automatización explicar sus suposiciones.

Para AFRINIC, la recursividad de AS-SET tiene una dimensión de desarrollo regional. El peering local y el tránsito regional se vuelven más baratos cuando los filtros pueden construirse de manera predecible. Si las redes pequeñas no pueden hacer que sus AS-SET funcionen a través de intercambios y upstreams, pueden seguir dependiendo de unos pocos proveedores que ya entienden los rituales. Si los conjuntos obsoletos o demasiado amplios crean preocupaciones de seguridad, los operadores de servidores de rutas pueden endurecer las reglas de manera que excluyan a las mismas redes pequeñas. Una buena gobernanza de AS-SET no es, por lo tanto, solo una conveniencia de seguridad. Es parte de reducir el costo de participación en la economía de enrutamiento.

AFRINIC convierte la ambigüedad de la base de datos en riesgo institucional

Todos los RIR enfrentan datos IRR fragmentados. AFRINIC no es único porque tenga objetos de ruta, registros obsoletos u operadores que discrepen sobre la política de fuentes. Es distintivo porque la ambigüedad de la base de datos se asienta sobre un estrés institucional que ya ha hecho que las contrapartes sean sensibles a la continuidad. Una crisis de gobernanza cambia cómo se valoran los defectos técnicos ordinarios. En una institución tranquila, un duplicado IRR obsoleto puede tratarse como mantenimiento. En una institución estresada, el mismo duplicado puede interpretarse como evidencia de que el libro mayor no puede vigilar sus bordes.

La historia reciente de AFRINIC incluye litigios, gobernanza disputada, incertidumbre relacionada con la administración judicial, turbulencia electoral, una elección anulada en 2025 tras preocupaciones reportadas de irregularidades, y esfuerzos posteriores para restaurar la función de la junta. También incluye preocupación pública sobre la integridad histórica de los registros IPv4 y la apropiación indebida de direcciones. Esos hechos no deben usarse para condenar cada registro o cada operador en la región. No prueban que un objeto IRR dado sea falso. Pero sí cambian el costo de la prueba. Un tercero que mira un prefijo administrado por AFRINIC puede hacer más preguntas porque la institución alrededor del libro mayor ha estado visiblemente tensa.

Ahí es donde los datos IRR fragmentados se convierten en riesgo institucional. Si un prefijo tiene un origen en una fuente vinculada a AFRINIC, otro en un IRR comercial, y una referencia obsoleta en un AS-SET mantenido por un antiguo proveedor, el conflicto técnico también es una señal de gobernanza. Dice que el mercado no puede ver fácilmente qué institución, qué fuente y qué cadena de autoridad debe resolver la reclamación operativa. En una región donde las direcciones son escasas y el registro ha estado bajo presión, esa incertidumbre atrae primas de riesgo.

El peligro no son solo los malos actores. Las redes legítimas sufren el mismo descuento. Una universidad pública con registros antiguos puede ser tratada como sospechosa cuando cambia de proveedor. Un pequeño ISP puede perder una oportunidad de tránsito porque su AS-SET se expande de manera inconsistente. Una agencia gubernamental puede enfrentar semanas de revisión porque los contactos históricos ya no responden. Un centro de datos puede tener dificultades para traer espacio de cliente a un intercambio local porque otra fuente todavía apunta a un operador internacional. Estos no son necesariamente fallos del personal de AFRINIC o de ningún operador de IRR. Son fallos de un sistema de confianza fragmentado para hacer que la legitimidad ordinaria sea barata.

El estrés institucional también fomenta la expansión del mandato. Un registro bajo crítica puede verse tentado a demostrar vigilancia afirmando un control más amplio sobre los datos de enrutamiento, el uso de direcciones o el comportamiento del mercado. El lenguaje de soberanía comunitaria puede hacer que esa expansión suene natural: porque el registro sirve a una región, debería decidir más preguntas en nombre de la región. Pero la coordinación técnica no se vuelve legítima simplemente invocando a la comunidad. Si el registro se convierte en un gobernador de mercado discrecional, eleva lo que está en juego de la captura, el litigio y el conflicto político. Si se retira a un mantenimiento pasivo de registros mientras los datos fragmentados gobiernan la alcanzabilidad, falla al mercado de otra manera. El camino estrecho es una mayor fiabilidad del libro mayor sin un control de acceso más amplio.

Ese camino requiere reconocer las capas separadas. El registro de recursos numéricos de AFRINIC es el libro mayor duradero. Los datos IRR son publicación de política de enrutamiento adyacente a ese libro mayor. RPKI y ROAs proporcionan evidencia criptográfica de origen de ruta a través de un mecanismo diferente. Los anuncios BGP muestran el enrutamiento observado, no la autoridad. Los contratos y órdenes judiciales pueden decidir derechos entre las partes, pero necesitan traducción en señales operativas. Confundir estas capas produce extralimitación o negligencia. Mantenerlas separadas permite que cada una haga su trabajo.

Por ejemplo, si un prefijo disputado de la región AFRINIC tiene entradas IRR conflictivas, el registro no debería tener que decidir cada disputa comercial antes de que cualquier registro operativo pueda cambiar. Pero debería proporcionar procedimientos claros para la autoridad de la fuente, avisos, etiquetas de estado, informes de conflictos y corrección. Si un titular muestra que un objeto obsoleto en una fuente controlada por AFRINIC ya no refleja su delegación, el camino de corrección debería ser rápido y auditable. Si un duplicado persiste en otro lugar, los operadores deberían tener suficientes metadatos de fuente para saber que la fuente AFRINIC tiene una postura de autoridad diferente. Si una orden judicial afecta quién puede actuar por el titular, el registro debe mapear esa orden al libro mayor cuidadosamente en lugar de convertir los filtros de ruta en instrumentos legales ad hoc.

El objetivo institucional es la continuidad. Las redes no deberían tener que esperar una calma perfecta en la gobernanza antes de que sus datos de enrutamiento se vuelvan utilizables. Tampoco se debe permitir que la turbulencia de la gobernanza convierta los registros IRR ambiguos en palanca privada. Un registro que es estrecho, procedimental y transparente reduce el valor de la captura institucional. Cuanta menos discreción se adjunte a la ambigüedad de la base de datos, menos premio hay en controlar la institución.

La escasez de IPv4 convierte la ambigüedad en una prima

La escasez de IPv4 es la fuerza que convierte la fragilidad del IRR de una molestia de ingeniería en un problema económico. Cuando las direcciones eran abundantes, un bloque desordenado a veces podía ser reemplazado, renumerado o ignorado. El agotamiento cambió eso. Un bloque IPv4 enrutable ahora conlleva dependencias de clientes, historial de reputación, listas blancas de firewalls, suposiciones de geolocalización, expectativas de DNS inverso, mapeos en la nube y valor de activo. La capacidad de hacer que ese bloque sea aceptado por upstreams, IXPs y plataformas de nube es parte de lo que vale el bloque.

Un bloque de direcciones no es valioso meramente porque aparece en un registro. Es valioso porque las contrapartes creen que puede ser utilizado. La usabilidad depende de una pila de evidencia: registros de titulares de registro, autoridad contractual, historial de enrutamiento, objetos IRR, AS-SET, estado RPKI, reputación de abuso, DNS inverso, aprobaciones de incorporación a la nube y filtros de operadores. Los datos IRR fragmentados se sitúan en medio de esa pila. Están lo suficientemente cerca de las operaciones para afectar la alcanzabilidad y lo suficientemente cerca del registro para influir en las percepciones de legitimidad. Cuando entran en conflicto, el bloque se vuelve menos líquido.

Un comprador ve esto como riesgo de limpieza. Si adquiere el bloque, ¿permanecerán los antiguos objetos de ruta? ¿Aparecerá todavía un origen anterior en los filtros? ¿Podrá el vendedor eliminar los duplicados obsoletos de las fuentes que no controla? ¿Aceptarán los proveedores de nube rápidamente el nuevo origen? ¿Considerará un prestamista que financia el acuerdo la postura de enrutamiento como estable? Cada respuesta incierta puede cambiar el precio, los términos de depósito o el cronograma de cierre. El mercado no necesita creer que los registros IRR son documentos de título. Solo necesita creer que los malos registros IRR pueden retrasar el valor.

Un corredor lo ve como riesgo de ejecución. Los corredores venden confianza tanto como venden presentaciones. Un bloque con datos de registro limpios pero un historial IRR desordenado requiere más explicación. Si el corredor no puede mostrar que el prefijo será aceptado por los principales proveedores de tránsito y plataformas, el comprador puede descontarlo. Si el corredor se basa en un objeto obsoleto para mostrar la enrutabilidad, el comprador puede descubrir más tarde que la aceptación operativa se basaba en evidencia frágil. Los datos IRR fragmentados convierten el corretaje en una forma de diligencia debida de enrutamiento.

Un prestamista lo ve como incertidumbre de garantía. Los negocios dependientes de direcciones pueden no pignorar bloques IPv4 directamente de una manera simple, pero los prestamistas aún se preocupan por si los activos de red que respaldan el flujo de caja son estables. Si la capacidad de una empresa para servir a los clientes depende de prefijos que requieren excepciones manuales de ruta, el activo es más débil. Si los registros IRR conflictivos pudieran permitir que un antiguo proveedor o reclamante cree confusión, el riesgo es mayor. Si el entorno del registro está estresado, el prestamista puede pedir más controles. Los datos de enrutamiento ambiguos se convierten en un costo de financiamiento.

Un cliente lo ve como fiabilidad del servicio. Las empresas, agencias públicas y usuarios de la nube no quieren aprender la diferencia entre RADB, AFRINIC, recursividad de AS-SET y RPKI. Quieren que la red de su proveedor funcione. Cuando una migración falla porque un servidor de rutas rechaza un prefijo, el cliente experimenta retraso y desconfianza. El proveedor puede culpar al registro, al antiguo proveedor, al nuevo upstream o a una fuente de base de datos. El cliente solo escucha que el activo de dirección era más difícil de usar de lo prometido.

La escasez intensifica el problema distributivo. Las redes más ricas pueden comprar experiencia. Las redes más pequeñas pueden pagar con retraso. Los operadores africanos que intentan construir interconexión local pueden enfrentar escepticismo de plataformas globales que están acostumbradas a una documentación más estricta. Las redes del sector público con asignaciones antiguas pueden tener dificultades para modernizarse porque los registros antiguos no coinciden con las estructuras de adquisición actuales. Las universidades y redes de investigación pueden heredar registros de una era más informal. La prima de mercado por datos IRR limpios no es, por lo tanto, solo una recompensa por buena higiene. También es una penalización por complejidad histórica.

La conclusión política debería ser modesta. AFRINIC no debería erigirse en árbitro de cada precio de transferencia, arrendamiento, prenda o decisión de incorporación a la nube. Eso convertiría un registro en un supervisor del mercado. Pero debería entender que los datos de enrutamiento adyacentes al registro afectan esas decisiones. Si la fuente regional es predecible, si los registros obsoletos pueden ser encontrados y corregidos, si la autoridad de la fuente es visible, y si los operadores pueden confiar en procedimientos claros, la prima de escasez asociada a la ambigüedad cae. Una buena gobernanza del IRR hace que los mercados IPv4 sean menos feudales. Una mala gobernanza del IRR permite que aquellos con conocimiento privado extraigan valor de la incertidumbre de todos los demás.

RPKI ayuda, pero no disuelve la dependencia del IRR

RPKI y las Autorizaciones de Origen de Ruta se presentan a menudo como la alternativa más limpia al IRR. Son más limpios para una pregunta específica. Un ROA permite a un titular de recursos, dentro del sistema de certificados de recursos, establecer qué AS puede originar un prefijo hasta una longitud máxima definida. Las redes que realizan validación de origen de ruta pueden clasificar los anuncios como válidos, inválidos o no encontrados. Esa es una mejora poderosa sobre los registros de texto no autenticados o débilmente autenticados. Reduce una clase de incertidumbre en torno a la autoridad de origen.

Pero RPKI no disuelve el problema del IRR. Los operadores todavía usan datos del IRR para filtros de clientes, expansión de AS-SET, política de route-set, expectativas de máximo prefijo y documentación de política de enrutamiento. Un ROA puede decir que un AS está autorizado para originar un prefijo. No describe el cono completo de clientes detrás de un AS de tránsito. No limpia AS-SET obsoletos. No elimina objetos de ruta duplicados de IRR privados. No explica por qué un repositorio dice que un antiguo upstream todavía origina el bloque. No le dice a un corredor si las viejas referencias IRR retrasarán la incorporación del operador del comprador. No decide si un objeto creado por un proveedor debe ser eliminado después de la terminación del contrato.

RPKI es, por lo tanto, un comparador y una alternativa parcial, no el centro del problema de fragmentación de fuentes. Puede proporcionar evidencia más fuerte para las afirmaciones de prefijo-origen. Puede ayudar a los operadores a rechazar anuncios inconsistentes con los ROA. Puede reducir la dependencia de datos IRR débiles para un subconjunto de decisiones. Sin embargo, la economía de enrutamiento sigue siendo plural. Algunas redes aplican ROV estrictamente. Algunas monitorean. Algunas usan filtros IRR más intensamente que RPKI. Algunas requieren ambos. Algunas aceptan RPKI para origen pero aún requieren AS-SET para filtrado de cono de clientes. El mercado no se gobierna por un solo interruptor de validación.

En el caso de AFRINIC, el valor de RPKI puede ser especialmente alto porque el estrés institucional hace atractiva la evidencia de origen verificable por máquina. Un ROA puede tranquilizar a un upstream de que un titular ha publicado una autorización de origen actual. Puede ayudar a un proveedor de nube a distinguir un nuevo origen legítimo de un objeto IRR obsoleto. Puede dar a un comprador un elemento de diligencia más limpio. Pero no responde a todas las preguntas de fragmentación de fuentes. Un prefijo puede tener un ROA válido y aún aparecer en viejos AS-SET. Un servidor de rutas puede usar filtros derivados del IRR que rechazan la ruta antes de que RPKI siquiera importe. Un upstream puede requerir registro IRR para el aprovisionamiento incluso si RPKI es válido. Las culturas operativas cambian lentamente.

También hay una economía política de sustitución. Si un registro o comunidad de estándares dice: "usen RPKI e ignoren el IRR", puede subestimar las dependencias operativas existentes. Si los operadores dicen: "el IRR funciona suficientemente bien", pueden preservar cadenas de autoridad débiles. El camino realista es la estratificación. RPKI debería reducir la carga puesta en el IRR para la validación de origen. El IRR debería seguir siendo útil para la política de enrutamiento y la expresión del cono de clientes. Donde los dos entren en conflicto, los operadores deberían tener políticas claras para qué señal gobierna qué decisión. Un ROA válido no debería limpiar automáticamente cada AS-SET obsoleto. Un objeto IRR obsoleto no debería derrotar automáticamente una fuerte evidencia de origen actual. Cada señal tiene un trabajo.

Este enfoque estratificado también evita convertir RPKI en un instrumento de propiedad demasiado amplio. Un ROA no es una escritura, así como un objeto de ruta no es una escritura. Es una autorización de enrutamiento criptográfica con un significado operativo definido. La tentación en un mercado escaso es dejar que el artefacto más fuerte se convierta en la respuesta general a todas las disputas. Eso sería un error. RPKI puede reducir la ambigüedad de origen de ruta, pero los contratos, los registros de registro, la autoridad corporativa, las órdenes judiciales, las delegaciones de clientes y la limpieza del IRR todavía importan. El hecho de que una capa sea más fuerte no elimina la necesidad de coherencia entre capas.

Para la automatización de servidores de rutas y tránsito, la mejora práctica es una política consciente de conflictos. Un sistema debería poder decir: el ROA valida este origen, la fuente IRR vinculada a AFRINIC lo respalda, un IRR no regional tiene un duplicado obsoleto, y un AS-SET en otra fuente todavía hace referencia al antiguo proveedor. Esa es una mejor señal de mercado que un aceptar o rechazar binario. Permite al operador aceptar la ruta mientras abre un ticket de limpieza, o rechazar solo si el conflicto alcanza un umbral de riesgo definido. El objetivo no es más datos por sí mismos. El objetivo es un juicio más barato y consistente.

El auge de RPKI debería, por lo tanto, hacer que la gobernanza del IRR sea más disciplinada, no irrelevante. A medida que la evidencia de origen más fuerte esté disponible, los datos restantes del IRR deberían usarse para lo que mejor hacen y limpiarse donde causan confusión. El desafío de AFRINIC es apoyar esa transición sin usarla para expandir la discreción. Una seguridad de enrutamiento más fuerte debería proteger la fiabilidad del libro mayor. No debería dar al operador del libro mayor un mandato más amplio para gobernar las relaciones de mercado por implicación.

La cuestión de la confianza es diferente para cada contraparte

La frase "¿en qué base de datos se puede confiar?" suena singular. En la práctica, la confianza depende de la contraparte y de la decisión. Un upstream, un IXP, un proveedor de nube, un corredor, un comprador, un prestamista y un cliente hacen preguntas diferentes a los datos del IRR. La fragmentación es costosa porque el mismo conflicto debe traducirse en cada contexto de decisión.

Un upstream pregunta si puede aceptar de manera segura el anuncio de un cliente. Le importa prevenir secuestros, evitar fugas de rutas, satisfacer la política interna, limitar la carga de soporte y aprovisionar ingresos. Puede aceptar una mezcla de evidencia IRR y RPKI si la relación con el cliente es fuerte. Puede ser más estricto para clientes nuevos o pequeños. Para el upstream, la confianza en la base de datos es un filtro de riesgo del cliente. Si las fuentes entran en conflicto, la respuesta conservadora puede ser retrasar el servicio hasta que el cliente limpie los registros. El costo recae en el cliente.

Un servidor de rutas de IXP hace una pregunta más comunal. Debe proteger a muchos participantes a la vez. Una mala ruta puede propagarse a través del peering multilateral. Una ruta rechazada puede reducir el valor del intercambio para un miembro legítimo. El servidor de rutas suele estar más basado en reglas porque no puede negociar privadamente cada caso sin socavar la previsibilidad. Para el IXP, la confianza en la base de datos es una política de riesgo compartido. La fragmentación de fuentes puede reducir el valor del peering local o aumentar el riesgo aceptado por todos los miembros.

Un proveedor de nube pregunta si puede anunciar espacio de cliente a escala sin convertirse en un canal de lavado para prefijos cuestionables. Necesita incorporación estandarizada. Puede preferir evidencia fuerte de registro y RPKI, pero aún encuentra registros IRR durante la diligencia debida y el filtrado operativo. Para la nube, la confianza en la base de datos es parte del riesgo de la plataforma. Un prefijo desordenado de la región AFRINIC puede no ser rechazado por prejuicio; puede ser retrasado porque la plataforma no puede resolver contradicciones de manera barata a escala. El efecto económico sobre el titular es el mismo.

Un corredor pregunta si el bloque de direcciones puede ser vendido, arrendado o presentado sin sorpresas. Le importa la confianza, el precio y el cronograma de cierre. Los datos IRR fragmentados son un defecto a revelar, limpiar o descontar. Para el corredor, la confianza en la base de datos es comerciabilidad. Los duplicados obsoletos y los orígenes conflictivos reducen la promesa de que el comprador pueda usar el bloque rápidamente. El corredor puede no controlar ninguna base de datos, pero debe vender alrededor de los defectos de las bases de datos.

Un comprador pregunta si recibirá un activo que funcione operativamente después del cierre. La transferencia de registro por sí sola no es suficiente si los antiguos objetos de ruta, referencias de AS-SET o conflictos de fuente bloquearán el despliegue. El comprador puede exigir remediación antes del pago o retener fondos hasta que los operadores acepten el nuevo origen. Para el comprador, la confianza en la base de datos es usabilidad post-cierre. La ambigüedad se convierte en un término de precio.

Un prestamista pregunta si los ingresos dependientes de direcciones son resilientes. Puede no entender cada objeto RPSL, pero su asesor técnico traducirá el conflicto de base de datos en riesgo operativo. Si los prefijos de un prestatario dependen de excepciones manuales del operador o disputas de registro no resueltas, el prestamista ve fragilidad. Para el prestamista, la confianza en la base de datos es soporte del flujo de caja. Afecta al crédito incluso cuando el préstamo no está garantizado directamente por direcciones.

Un cliente hace la pregunta más simple: ¿funcionará el servicio? Puede no saber qué base de datos usó un servidor de rutas. Solo ve que una migración se estanca, un prefijo es rechazado, o un proveedor no puede explicar por qué la aceptación difiere entre redes. Para el cliente, la confianza en la base de datos es credibilidad del servicio. Cuando los proveedores se esconden detrás de "cuestiones de IRR" sin una explicación clara, los clientes aprenden que la plomería invisible del mercado no es confiable.

Estas diferencias importan para AFRINIC porque una respuesta centrada solo en el registro no satisfará todas las necesidades de confianza. El registro puede hacer su fuente más limpia, proporcionar vías de corrección, publicar metadatos de conflicto y mejorar la continuidad bajo estrés. Cada contraparte seguirá eligiendo cómo usar los datos. El objetivo no es una confianza uniforme, sino hechos coherentes: lo que la fuente prueba, lo que no prueba, cómo se etiquetan los conflictos, cómo se corrigen los datos obsoletos y cómo los terceros pueden hacer políticas sin adivinar. La confianza no se ordena. Se hace más barata.

Un estándar estrecho para la confianza en la región AFRINIC

Un estándar práctico para la confianza en el IRR de la región AFRINIC debería comenzar con humildad sobre lo que prueba cualquier artefacto. Un objeto de ruta prueba que existe una declaración de prefijo-origen en una fuente bajo las reglas de esa fuente. Un objeto route6 hace lo mismo para IPv6. Un mntner prueba quién puede autenticar ciertos cambios en la base de datos, no quién tiene cada mandato subyacente. Un AS-SET describe relaciones de enrutamiento previstas, pero puede importar datos obsoletos o de fuentes cruzadas. Un ROA proporciona evidencia criptográfica de origen más fuerte, pero no un mapa completo de conos de clientes, autoridad comercial o limpieza de base de datos. El BGP observado muestra lo que está sucediendo, no necesariamente lo que está autorizado.

De esa humildad sigue una jerarquía. Para los recursos administrados por AFRINIC, el registro vinculado a AFRINIC y la fuente de política de enrutamiento deben tener un alto peso probatorio cuando estén actualizados, sean procedimentalmente limpios y transparentes. Las entradas IRR no AFRINIC deben seguir siendo utilizables, pero los operadores no deben pretender que cada objeto RPSL descansa sobre la misma base de autoridad. RPKI debe fortalecer la garantía de origen. La expansión de AS-SET debe tratarse como una cadena cuyas fuentes, antigüedades y referencias entre fuentes importan. Las excepciones manuales deben ser temporales y registradas. Los duplicados obsoletos deben ser visibles y corregibles.

La alternativa tentadora es la centralización: hacer que una fuente sea decisiva y exigir que todos los actores del mercado se sometan. Eso respondería a la fragmentación convirtiendo un libro mayor en un guardián. AFRINIC debe evitar ese camino. Su valor no está en aprobar cada transferencia, arrendamiento, incorporación a la nube o cambio de proveedor. Su valor está en proteger un libro mayor de continuidad estrecho para que otros puedan tomar sus propias decisiones de enrutamiento y comerciales de manera barata. El lenguaje de mandato no debe blanquear un rol de coordinación técnica en control discrecional del mercado.

Estrechez no significa debilidad. Una fuente confiable aún puede tener autenticación fuerte, verificaciones de autorización proporcionales, vías claras de corrección, etiquetas de conflicto, métricas públicas y procedimientos de continuidad. Las actualizaciones rutinarias por mantenedores estables deben ser fáciles. Los cambios que alteran el AS de origen, eliminan un antiguo proveedor, agregan conos de clientes amplios, afectan bloques IPv4 escasos, o surgen durante disputas corporativas o de gobernanza deben requerir más evidencia y aviso. La prueba es la proporcionalidad: muy poca evidencia invita al abuso; demasiada evidencia congela las operaciones ordinarias.

El aviso debe ser parte de esa proporcionalidad. Si un cambio desplazaría un origen existente o eliminaría un objeto utilizado por filtros, los contactos afectados deben ser notificados cuando sea factible: titular del recurso, mantenedor existente, origen propuesto, origen actual y contactos operativos relevantes. El aviso no debe convertirse en un veto. Es una forma de sacar a la superficie errores antes de que se conviertan en cortes. Donde la urgencia requiera acción de emergencia, la acción debe ser temporal, registrada y revisada.

Las métricas harían creíble el estándar. AFRINIC y los principales operadores deberían poder medir con qué frecuencia los prefijos administrados por AFRINIC tienen objetos route o route6 conflictivos entre fuentes, con qué frecuencia las expansiones de AS-SET difieren según el orden de fuente, qué tan antiguos son los duplicados obsoletos, qué tan frescos están los espejos, cuánto tardan las correcciones y cuántos clientes requieren excepciones manuales. Estos números no necesitan exponer archivos privados de clientes. Le dirían al mercado si la fragmentación es una anécdota, un impuesto crónico o una condición que mejora.

La misma disciplina debería aplicarse a las herramientas. Los sistemas de filtrado deben exponer las rutas de fuente: qué fuente, objeto, cadena de AS-SET y regla de recursividad produjo la aceptación o el rechazo. Los titulares deben poder descubrir dónde aparecen sus prefijos y ASN en las principales fuentes IRR y route-sets. Los servidores de rutas deben informar categorías de rechazo que sean inteligibles para los miembros. Los registros históricos deben preservarse para auditoría, pero la guía del estado actual debe ser lo suficientemente clara para que los operadores la usen. El objetivo no es una base de datos perfecta. Es un entorno de base de datos en el que la incertidumbre está etiquetada, acotada y es barata de reducir.

Este estándar haría la vida más fácil al ingeniero del servidor de rutas que enfrenta el trabajo de filtros al amanecer. Si varias fuentes dieran respuestas contradictorias, la herramienta mostraría frescura, postura de autoridad, ruta de fuente y antigüedad del conflicto. Un ROA válido se ponderaría para la garantía de origen pero no se usaría para ignorar AS-SET obsoletos. La fuente vinculada a AFRINIC sería confiable porque sus procedimientos eran visibles, no porque la institución exigiera deferencia. Las fuentes externas se considerarían con sus limitaciones. El cliente recibiría una vía clara de limpieza en lugar de un rechazo misterioso. Todavía se requeriría juicio, pero sería más barato.

El costo de no arreglar la fragmentación

Si la fragmentación del IRR permanece sin gestionar, el mercado aún encontrará formas de enrutar. Internet es bueno para enrutar alrededor de la debilidad institucional. Esa resiliencia no debe confundirse con salud. El camino de la solución alternativa es predecible: los grandes operadores construyen sistemas privados de confianza, las plataformas imponen incorporaciones más estrictas, las redes pequeñas dependen de los incumbentes, los corredores valoran el riesgo de limpieza, los servidores de rutas endurecen las políticas, y los clientes aprenden que los servicios dependientes de direcciones en algunas regiones requieren más explicación. Los paquetes aún pueden fluir, pero la participación se vuelve más costosa y menos igual.

Para AFRINIC, ese resultado sería perjudicial porque la región necesita costos de coordinación más bajos, no más altos. La interconexión local, la localización en la nube, los servicios digitales del sector público, las redes universitarias, la entrega de contenido regional y la competencia de pequeños proveedores dependen de una aceptación de enrutamiento predecible. Si cada migración o incorporación puede ser ralentizada por fuentes de base de datos contradictorias, la región paga un impuesto silencioso. El impuesto aparece como proyectos retrasados, mayor dependencia del tránsito, posiciones de negociación más débiles, valores de activos más bajos y mayor dependencia de intermediarios fuera de la región.

La seguridad no necesariamente mejoraría. Las políticas demasiado estrictas pueden reducir algunas malas rutas, pero también empujan a los operadores legítimos a excepciones manuales. Las políticas demasiado flexibles mantienen viva la autoridad obsoleta. Las soluciones privadas hacen que el sistema sea menos transparente. El mejor resultado de seguridad proviene de evidencia coherente: datos vinculados al titular actual, AS-SET limpios, RPKI donde sea apropiado, conflicto de fuente visible y corrección rápida. La fragmentación sin gestión no produce ni apertura ni seguridad. Produce opacidad selectiva.

El costo institucional sería igualmente grave. Un registro que se recupera de la turbulencia de gobernanza necesita mostrar que sus funciones básicas de utilidad son confiables. La coherencia del IRR es una de esas funciones porque está cerca de las operaciones diarias. Si AFRINIC puede hacer que los datos de política de enrutamiento sean más limpios, más transparentes y más fáciles de corregir, fortalecerá la confianza en el libro mayor sin pedir al mercado una confianza ciega. Si no puede, las contrapartes crearán sus propios sistemas de confianza. Una vez que esos sistemas se endurezcan, la función pública del registro regional se vuelve menos central y los guardianes privados se vuelven más poderosos.

El costo de mercado aumentará a medida que persista la escasez de IPv4. La escasez eleva el valor de cada ambigüedad que puede afectar el uso: un objeto de ruta obsoleto, una entrada faltante en un AS-SET, un retraso del espejo, una preferencia de fuente o una disputa de gobernanza. Los datos IRR fragmentados convierten pequeños defectos técnicos en opciones económicas en manos de quien pueda explotarlos o resolverlos.

La respuesta no es una nueva y dramática reclamación de soberanía sobre el enrutamiento. Es una reducción disciplinada de la ambigüedad. AFRINIC debe ser una utilidad de continuidad estrecha para los recursos que administra, con soporte de política de enrutamiento que sea lo suficientemente confiable para que terceros lo usen y lo suficientemente limitado para no convertirse en mando del mercado. Los operadores deben publicar cómo consumen fuentes y manejan conflictos. Las principales fuentes IRR deben mejorar el descubrimiento de objetos obsoletos y el contexto de autoridad. Los IXP y operadores deben hacer que las decisiones del servidor de rutas y los filtros de clientes sean explicables. Los compradores, corredores y prestamistas deben tratar la postura IRR como diligencia, no como folklore.

El trabajo del servidor de rutas al amanecer no debería tener que decidir el futuro institucional de la numeración de Internet en África. Debería tener que decidir si una ruta es segura para aceptar bajo una política clara. Eso ya es suficientemente difícil. Los datos IRR fragmentados lo hacen más difícil al presentar varios pasados plausibles como si fueran presentes iguales. En un mercado construido sobre números escasos e interconexión voluntaria, esa confusión tiene un precio.

La oportunidad de AFRINIC es reducir ese precio. No convirtiéndose en un guardián de cada uso comercial de IPv4. No pidiendo a los operadores que ignoren las fuentes no regionales. No fingiendo que RPKI elimina las bases de datos de política de enrutamiento. La oportunidad es más estrecha y más valiosa: hacer que el libro mayor vinculado a AFRINIC y la fuente de política de enrutamiento sean confiables, exponer conflictos, preservar la historia, acelerar la corrección, separar la autenticación de la autorización, y ayudar a los operadores a ver qué afirmación de base de datos descansa sobre qué fundamento institucional. Si eso sucede, los datos IRR vuelven a su papel económico adecuado. Se convierten en una forma de hacer la confianza más barata, en lugar de una razón por la que cada red debe comprar su propio mapa privado de dudas.