AFRINIC y la economía de la visibilidad de subasignación

El ticket de abuso parecía rutinario hasta que todos intentaron identificar al responsable. Un ISP regional había recibido quejas sobre tráfico de relleno de credenciales desde un pequeño /27 utilizado por uno de sus clientes comerciales. El titular registrado del bloque IPv4 principal era visible en el registro de AFRINIC. El AS de origen era visible en BGP. Un revendedor se ubicaba en algún punto de la cadena comercial. Un proveedor de firewall gestionado manejaba el dispositivo de borde. El cliente cuyos servidores generaban el tráfico deseaba privacidad, en parte porque las máquinas podrían haber sido comprometidas y en parte porque no quería que sus acuerdos de alojamiento quedaran expuestos a la competencia. El proveedor ascendente quería responsabilidad. El banco que presentó la queja quería una persona que pudiera detener el ataque. El libro mayor del registro nombraba al titular, no al pequeño usuario operativo.

Esa brecha es el tema de la visibilidad de la subasignación. La palabra "subasignación" tiene un significado formal en la política de AFRINIC: un LIR puede distribuir espacio a ISP descendentes para su distribución posterior, sujeto a reglas de tamaño, documentación y registro. El problema económico es más amplio que la etiqueta formal. El IPv4 escaso ahora se utiliza a través de titulares, LIR, ISP descendentes, revendedores, proveedores de alojamiento, proveedores de servicios gestionados, plataformas en la nube, intermediarios, acuerdos de arrendamiento, clientes empresariales y, a veces, usuarios delegados ulteriormente. Parte de ese uso es legítimo y ordinario. Parte es sensible a la privacidad. Parte es confidencial comercialmente. Parte es donde realmente surgen el abuso, el fraude, el filtrado de sanciones, las solicitudes de aplicación de la ley, los errores de geolocalización, los errores de enrutamiento y el daño a la reputación.

El registro público a menudo solo ve la primera capa. Internet opera a través de muchas más capas. Un prefijo puede estar registrado a una parte, originado por otra, delegado en DNS inverso a una tercera, listado en un objeto IRR mantenido por el contacto de un intermediario, cubierto por un ROA creado por el titular formal, y utilizado por clientes cuyos nombres nunca aparecen en RDAP o WHOIS. Nada de esto es automáticamente sospechoso. La división del trabajo es normal en las operaciones de red. El problema comienza cuando cada tercero debe asumir el costo de descubrir al operador responsable después de que algo ya ha salido mal.

AFRINIC es un caso de prueba útil porque la capa descendente ya está integrada en las reglas operativas con las que las redes deben convivir, mientras que su historia institucional reciente muestra por qué la visibilidad por debajo del titular es importante. El African Network Information Centre sirve a África y parte del Océano Índico como registro regional de Internet. Se apoya en los servicios que convierten el uso de recursos en evidencia pública: WHOIS, RDAP, DNS inverso, un Registro de Enrutamiento de Internet y RPKI. Las reglas operativas pertinentes exigen que las asignaciones, las asignaciones y las subasignaciones se registren en la base de datos de AFRINIC, y dicen que los datos de registro, como nombres, bloques, contactos y estado, deben permanecer correctos. También vinculan la delegación inversa a las asignaciones o subasignaciones registradas. Esas reglas no son ornamentales. Son los puntos estrechos donde se supone que la realidad operativa descendente debe volverse legible.

La presión sobre esos puntos ha aumentado. AFRINIC entró en la Fase 2 de Aterrizaje Suave de IPv4 el 13 de enero de 2020, con tamaños de asignación y asignación de IPv4 nuevos ordinarios limitados a bloques pequeños, incluido un mínimo de /24 y un máximo de /22. Los informes públicos han descrito acusaciones de manipulación de registros de direcciones que involucran espacio IPv4 africano inactivo, la disputa de alto valor entre AFRINIC y Cloud Innovation sobre el uso y la comercialización de recursos, una congelación judicial de fondos de AFRINIC en 2021, la administración judicial a partir de 2023, la discontinuidad de la junta y las elecciones, un intento de elección de 2025 anulado, la restauración posterior de la junta y las continuas preguntas sobre la recuperación en 2026. Estos eventos no deben convertirse en una fábula genérica de moralidad de gobernanza. Para la visibilidad de la subasignación, su importancia es más limitada: cuando el propio registro está bajo estrés, los mercados dependen aún más de la evidencia clara de quién está utilizando direcciones escasas, con quién se puede contactar y qué incertidumbre es real en lugar de rumor.

La pregunta correcta no es si cada cliente debe ser nombrado públicamente. Eso sería peligroso y económicamente insensato. La pregunta correcta es cuánto detalle descendente debería ser visible, para quién, con qué nivel de certeza y con qué efecto en el costo del enrutamiento, la respuesta a abusos, las transferencias, el arrendamiento, la contratación pública y la responsabilidad del registro. Un libro mayor público no es una lista privada de clientes. Pero si solo expone al titular formal mientras el usuario práctico está a tres contratos de distancia, deja que el mercado ponga precio a la opacidad.

El cliente invisible es ahora el hecho costoso

En la era de la abundancia, un cliente descendente oculto era a menudo una molestia más que un problema de precios. Si el abuso provenía de una subred de clientes, el proveedor podía rastrearlo dentro de sus propios sistemas. Si un contacto estaba desactualizado, otra asignación podría estar disponible. Si un rango pequeño estaba mal configurado, la renumeración era dolorosa pero no un evento de capital. La escasez de IPv4 cambió esa aritmética. Un bloque pequeño puede soportar ingresos por alojamiento, infraestructura de pago, portales gubernamentales, clientes SaaS, acceso VPN, sistemas antifraude, reputación de correo y continuidad de la red. El cliente detrás de la dirección ya no es solo un detalle operativo. Es una fuente de riesgo, valor y responsabilidad.

La opacidad tiene un camino económico medible. Aumenta el costo de búsqueda, porque un reclamante, un proveedor ascendente, un comprador, un banco, una aseguradora o un investigador debe dedicar tiempo a determinar si el titular listado, el AS de origen, el revendedor, el proveedor de servicios gestionados o el cliente final pueden resolver el problema. Aumenta el costo de error, porque si el /27 responsable no puede identificarse rápidamente, las contrapartes bloquean de más un /24, un /22 o toda la reputación de un titular. Aumenta el costo de contratación, porque los clientes y las contrapartes exigen garantías, indemnizaciones, depósitos en garantía, contactos de emergencia, créditos de servicio y diligencia adicional cuando el registro público no les brinda suficiente información. Aumenta el costo de capital, porque un prestamista o comprador descuenta los ingresos vinculados a direcciones cuya responsabilidad operativa no puede reconstruirse de forma independiente.

El cliente invisible también cambia los incentivos dentro de la cadena. Un titular que puede cobrar ingresos mientras deja al usuario descendente sin registrar puede invertir menos en la respuesta a abusos y en la verificación de clientes. Un revendedor que puede transferir la responsabilidad hacia arriba puede vender a clientes más riesgosos. Un proveedor gestionado que no aparece en el registro puede evitar daños a su reputación cuando su configuración falla. Un cliente que no puede ser nombrado públicamente por razones legítimas de privacidad aún puede necesitar proporcionar responsabilidad autenticada al titular, al registro o a un solicitante legal en condiciones definidas. Si nadie sabe qué capa tiene qué deber, todos tienen un incentivo para mantener visible la parte rentable y privada la parte riesgosa.

El lenguaje de la política de AFRINIC apunta hacia la distinción correcta. Las subasignaciones y las asignaciones deben registrarse porque la unicidad, la resolución de problemas y la continuidad requieren más que el nombre del titular. Al mismo tiempo, el manual no exige un dossier público sobre cada usuario descendente. El punto intermedio útil es la visibilidad de la responsabilidad: suficiente información pública y autenticada para identificar la capa operativa responsable, sin exponer la identidad de cada cliente a todo Internet.

El costo de equivocarse en esto es más alto para las redes más pequeñas. Las grandes plataformas pueden construir canales de confianza privados con los principales bancos, proveedores de tránsito, proveedores de seguridad y autoridades públicas. Los pequeños ISP y las empresas de alojamiento regionales no pueden. Dependen de registros públicos y semipúblicos para ser creídos por extraños. Si la evidencia pública es escasa, pagan con retrasos, filtrado más estricto, pérdida de clientes y menor poder de negociación. La opacidad de la subasignación se convierte así en un impuesto regresivo sobre las redes menos capaces de absorberlo.

La capa descendente ya forma parte de la economía de asignación

El manual de políticas de AFRINIC no describe la distribución de direcciones como una transacción de un solo paso entre el registro y el usuario final. Define una jerarquía. Un LIR recibe asignaciones de un registro regional y asigna principalmente espacio de direcciones a los usuarios finales. Una subasignación es la distribución de un LIR a un ISP para su posterior distribución. Una asignación es un bloque otorgado por un LIR a un ISP o usuario final para un uso específico dentro de la infraestructura que opera dicha parte. El espacio agregable por el proveedor se puede asignar o subasignar a redes descendentes como espacio no portátil, mientras que las asignaciones independientes del proveedor no son para subasignación posterior. Esto ya es un sistema en capas.

El manual luego asigna responsabilidades a esa estratificación. Dice que toda asignación, asignación PI, asignación PA, subasignación y otra asignación de recursos debe registrarse en la base de datos de AFRINIC, y que los recursos no registrados se considerarán inválidos. Requiere que los datos de registro sean correctos en todo momento. Establece la subasignación IPv4 formal mínima en /24. Requiere que los LIR realicen subasignaciones dentro de sus ventanas de subasignación o busquen la aprobación de AFRINIC por encima de esas ventanas. Hace responsables a los LIR de garantizar que el espacio que se les asigna y que posteriormente se subasigna se utilice de acuerdo con las políticas y directrices de la comunidad. Aconseja un inicio lento para los ISP descendentes. Trata el espacio de ISP descendente como no portátil dentro del bloque agregable del LIR.

Esas reglas revelan la lógica institucional. AFRINIC no tiene que conocer al usuario de cada paquete, pero no puede permanecer indiferente a la estructura descendente. Si un ISP descendente recibe un /24, la base de datos del registro no debería permanecer ciega. Si el espacio de direcciones públicas de un usuario final no es meramente infraestructura punto a punto, el manual dice que debe registrarse con los contactos del usuario final, con una adaptación de privacidad para individuos. Si se solicita DNS inverso para un /24, el manual dice que al menos una asignación o subasignación debe estar registrada para ese /24 específico. Los propios servicios de registro asumen hechos descendentes registrados.

La dificultad moderna es que la realidad comercial crea capas que no siempre coinciden con las antiguas categorías. Una empresa de alojamiento puede asignar /29s, /28s o /27s dentro de un /24 registrado. Un proveedor de firewall puede operar dispositivos de seguridad para muchos clientes dentro del agregado de un proveedor. Un revendedor puede vender servidores privados virtuales sin recibir una subasignación /24 formal. Un intermediario puede ayudar a organizar el uso sin aparecer como operador técnico. Una plataforma de arrendamiento puede coordinar el acceso del cliente mientras el titular registrado permanece sin cambios. Un proveedor de servicios gestionados puede controlar la remediación de abusos pero no la originación de rutas. La capa descendente es más granular que la unidad de política.

Esa falta de coincidencia no debería llevar a dos malas respuestas. La primera es pretender que el registro público puede ignorar todo lo que está por debajo del titular registrado. Eso hace que la resolución de problemas, la respuesta a abusos, la diligencia y el enrutamiento de las fuerzas del orden sean demasiado costosos. La segunda es exigir que cada pequeño rango de cliente y cada nombre de cliente sean públicos. Eso crea daños a la privacidad y la seguridad y puede empujar a los operadores legítimos a acuerdos privados que revelan menos, no más.

Una mejor respuesta comienza desde la visibilidad funcional. El registro debe distinguir el espacio operado por el titular de la asignación al cliente, la subasignación a ISP descendentes, el espacio gestionado por revendedores, la operación de servicios gestionados, la operación soportada por arrendamiento, el uso de usuario final protegido por privacidad y el estado en disputa o desactualizado. No siempre necesita publicar el nombre legal del cliente. Debe publicar lo suficiente para mostrar qué capa es responsable de la respuesta operativa y cuánto peso se le da a esa declaración. El titular sigue siendo responsable de la relación con el registro. El operador descendente se vuelve localizable para asuntos operativos. El cliente puede permanecer protegido cuando la ley, la seguridad o la confidencialidad comercial lo justifiquen.

Esa lógica de registro ya respalda un mapa de responsabilidad. El registro existe para garantizar la unicidad y proporcionar información para la resolución de problemas. En un mercado de escasez de IPv4, la resolución de problemas ahora incluye la accesibilidad para abusos, la explicación del origen de la ruta, la coherencia del DNS inverso, la evidencia de subdelegación, la diligencia en las transferencias, la contratación del sector público y la capacidad de los extraños para distinguir un cliente oculto de un registro abandonado.

Un libro mayor público no es una lista privada de clientes

El límite institucional es simple de enunciar y difícil de implementar. Un libro mayor de registro público no debe convertirse en una lista de clientes. Debe convertirse en un mapa de responsabilidad. La distinción es importante. Una lista de clientes revela quién compra servicios a quién. Un mapa de responsabilidad revela qué rol es responsable de un segmento de recursos, qué canal de contacto está activo, qué evidencia respalda el rol y cuánta confianza deben asignarle los terceros.

Para los usuarios públicos, el registro mínimo útil no es la identidad completa del cliente. Es el rol y la accesibilidad. Un registro público puede mostrar que un /24 es operado por el titular, asignado a una organización, subasignado a un ISP descendente, utilizado a través de un servicio gestionado, delegado a un usuario final con privacidad protegida, arrendado o delegado comercialmente bajo la responsabilidad del titular, o sujeto a disputa o confirmación desactualizada. Puede publicar contactos de rol: contacto del titular, contacto técnico, contacto de abuso, contacto de enrutamiento y contacto de DNS inverso. Puede exponer marcas de tiempo: primer registro, última validación, última actualización material y vencimiento de la validación. Puede mostrar si el rol descendente fue auto-atestiguado por el titular, validado por AFRINIC, inferido de la evidencia de enrutamiento, confirmado por delegación de DNS inverso o redactado por privacidad.

Para contrapartes autenticadas, puede ser apropiado un mayor detalle. Un proveedor de tránsito que evalúa una ruta, un comprador que realiza la diligencia de transferencia, un registro que maneja una revisión o un organismo público con una solicitud legal pueden necesitar la identidad legal del operador descendente, una carta de autorización, evidencia contractual, contactos de emergencia, geografía operativa, categoría de cliente, plazos de escalamiento y prueba de que el titular puede obligar a la cooperación. Esos detalles no necesitan ser legibles para todo el mundo. Pueden ser retenidos por el titular, depositados en el registro de forma limitada, compartidos bajo confidencialidad o divulgados mediante orden judicial o requerimiento legal.

Para los tribunales y las fuerzas del orden, el umbral debe ser más alto pero la información más profunda. Cuando una solicitud legal busca la identidad detrás de una asignación protegida por privacidad, el sistema no debe obligar a los investigadores a adivinar a través de cinco intermediarios. El titular debe poder rastrear la cadena. El registro debe saber si el titular afirma dicha trazabilidad. El registro público debe mostrar que existe un usuario descendente protegido por privacidad y que el escalamiento legal tiene un camino definido, no que el cliente es invisible para todos.

Las etiquetas de evidencia son esenciales, pero deben usarse con moderación y claridad. El mismo hecho visible tiene un valor diferente según cómo se obtuvo. Un ISP descendente atestiguado por el titular no es lo mismo que uno validado por el registro. Un origen observado por enrutamiento no es lo mismo que un usuario operativo registrado. Una delegación de DNS inverso no es prueba de responsabilidad por abuso. Un usuario con privacidad redactada no es lo mismo que un usuario desconocido. Un registro actualizado el mes pasado no es lo mismo que uno tocado por última vez en 2014. Un registro que expone estas diferencias reduce el costo de interpretación sin pretender saber más de lo que sabe.

La misma estructura protege al registro de extralimitaciones. Al publicar el rol, la capacidad de contacto, el estado de la evidencia y la incertidumbre, AFRINIC puede mejorar la confianza pública sin afirmar el derecho a inspeccionar a cada cliente para verificar la conformidad con las políticas. Puede decir: este es el titular reconocido; este bloque es operado por un descendente; el canal operativo responsable está aquí; la identidad legal se oculta a la vista pública pero es rastreable en condiciones definidas; la última fecha de validación es actual o está desactualizada. Tal libro mayor es más delgado que una base de datos de clientes y más grueso que un registro de titular desnudo. Ese es el punto medio económicamente útil.

El IPv4 escaso convierte la opacidad en un descuento de mercado

La opacidad de la subasignación no es solo un problema de seguridad. Es un descuento de mercado. Cuando un recurso escaso no puede rastrearse desde el titular hasta la responsabilidad operativa real, cada contraparte valora la brecha. El comprador de un bloque quiere saber si los usuarios descendentes no revelados se resistirán a la migración. El arrendatario quiere saber si el arrendador puede soportar cambios de ruta, DNS inverso y abuso a través de cada revendedor intermedio. El banco quiere saber si los ingresos respaldados por direcciones dependen de clientes cuyos contratos no pueden verificarse. El comprador público quiere saber si un servicio crítico se asienta sobre direcciones cuya cadena de autoridad es ambigua. El proveedor ascendente quiere saber si puede aceptar la ruta sin convertirse en la primera parte localizable para cada queja.

Los hechos de escasez de AFRINIC hacen concreto el descuento. Su aviso de agotamiento decía que la Fase 2 comenzó cuando no quedaba más de un /11 de espacio no reservado en el /8 final. En la Fase 2, el rango de asignación o asignación ordinaria es pequeño, con un mínimo de /24 y un máximo de /22. Dichos límites no eliminan la demanda; trasladan la demanda a la reutilización, las transferencias, el arrendamiento, la oferta de alojamiento, la reasignación de clientes y la delegación operativa. Cuanta más demanda se mueve a través de los titulares existentes, más importante se vuelve saber qué está sucediendo por debajo de esos titulares.

La opacidad también hace que los registros antiguos sean más peligrosos. KrebsOnSecurity informó en 2019 sobre acusaciones de que valioso espacio IPv4 africano asociado con organizaciones inactivas o desaparecidas había sido desviado o vendido a través de empresas vinculadas a una antigua figura senior de AFRINIC; el investigador Ron Guilmette estimó el espacio afectado en más de 50 millones de dólares en valor de mercado. La importancia para la visibilidad de la subasignación no es solo la presunta corrupción. Es que los registros inactivos y los rastros de autoridad débiles se vuelven valiosos cuando el IPv4 tiene un precio. Un registro que no revela claramente quién puede hablar por el uso descendente invita tanto al fraude como al descuento defensivo.

La disputa de Cloud Innovation muestra el borde opuesto del mismo problema. Los análisis públicos describieron un conflicto sobre millones de direcciones IPv4, arrendamiento comercial, uso real comparado con el uso registrado o esperado, y la supuesta capacidad de AFRINIC para revisar o terminar el reconocimiento de recursos. Cloud Innovation cuestionó la teoría de AFRINIC y el litigio escaló. Para la visibilidad de la subasignación, la lección no es que cada arrendamiento sea malo o que cada consulta del registro sea legítima. La lección es que cuando el uso descendente real es opaco, el registro puede verse tentado a solicitar información amplia del cliente, mientras que el titular puede resistirse alegando privacidad comercial. Ambas partes pueden tener parte de razón y aún así producir un mal equilibrio.

En un buen equilibrio, los titulares revelan responsabilidad estructurada sin entregar listas de clientes en bruto. En un mal equilibrio, revelan poco, el registro exige demasiado, comienzan los litigios y el mercado descuenta toda la cartera. El IPv4 escaso hace que ese descuento sea lo suficientemente grande como para cambiar el comportamiento. Un titular con poca visibilidad descendente enfrenta una menor confianza del comprador, un mayor costo legal, una peor reputación después del abuso y una aceptación más débil en el sector público. Un registro con poca visibilidad enfrenta presión para usar revisiones amplias porque no hay evidencia más específica disponible. La ausencia de visibilidad crea así el argumento a favor de la discreción.

El objetivo económico debería ser hacer que el uso responsable sea más barato que el uso oculto. Un titular que mantenga registros validados de roles descendentes, contactos activos, clientes protegidos por privacidad rastreables y etiquetas claras de incertidumbre debería enfrentar menos fricción en transacciones e incidentes. Un titular que no pueda explicar quién está usando su espacio debería pagar a través de descuentos, aprobaciones más lentas y un escrutinio más estricto. Eso no es un castigo. Es poner precio a la calidad de la información.

La pila de evidencia es plural y cada superficie tiene límites

Ninguna fuente de datos única puede responder a la pregunta de la responsabilidad descendente. RDAP y WHOIS proporcionan datos del titular y contacto registrados. BGP muestra qué sistema autónomo origina una ruta. Los objetos IRR expresan políticas de enrutamiento y convenciones de autorización de rutas. RPKI y ROA pueden validar la autoridad de origen. El DNS inverso puede revelar patrones de nombres, delegaciones de clientes e historial operativo. Las bases de datos de geolocalización, traceroute, latencia, certificados TLS, historiales de abusos, zonas DNS, reputación de correo, banners de alojamiento, registros corporativos y contratos de clientes pueden agregar pistas cada uno. Ninguno es concluyente por sí solo.

Esa pila de evidencia plural es útil y peligrosa a la vez. Es útil porque la responsabilidad descendente a menudo aparece solo cuando se combinan las señales. Un /24 registrado a un titular, originado por un ASN de alojamiento, cubierto por un ROA para ese ASN, nombrado con un patrón de DNS inverso de revendedor, listado en un objeto IRR mantenido por un tercero y con un historial de abusos vinculado a clientes de VPS probablemente no es operado por el titular en el sentido simple. Pero es peligroso porque la inferencia puede superar a la prueba. Una etiqueta de DNS inverso puede estar desactualizada. Un objeto IRR puede no estar autorizado. Una base de datos de geolocalización puede estar equivocada. Un ROA puede probar la autoridad de origen de la ruta, no la identidad del cliente. Un AS de origen puede ser un operador de tránsito o de servicios gestionados, no el usuario final.

Los servicios públicos de AFRINIC se sitúan en gran parte de esta pila. El registro proporciona servicios relacionados con WHOIS, RDAP, DNS inverso, IRR y RPKI. Su manual de políticas conecta la delegación inversa con las asignaciones o subasignaciones registradas. Su política de contacto de abuso crea un lugar para la información de abuso al tiempo que reconoce que el objeto, como otros objetos, enfrenta el problema de la precisión de los datos. La franqueza importa. Un campo puede crear un canal sin probar que el canal es correcto. Un ROA puede autorizar un origen sin probar el cliente descendente. Una asignación puede identificar un rango de usuario final sin probar cada detalle operativo posterior.

Por lo tanto, el registro público debe exponer el tipo de evidencia. Un rol descendente puede estar registrado, atestiguado por el titular, validado por el registro, observado por enrutamiento, consistente con DNS inverso, depositado contractualmente, rastreable por escalamiento legal, desactualizado, en disputa o redactado por privacidad. Estas etiquetas pueden sonar burocráticas si se usan en exceso. Bien usadas, son económicamente valiosas. Evitan que una señal débil sea tratada como una señal fuerte y evitan que la ausencia de identidad pública sea tratada como ausencia de responsabilidad.

Las etiquetas de evidencia también reducen el incentivo para la mitología privada. En mercados opacos, los intermediarios y las contrapartes llenan los vacíos con afirmaciones: bloque limpio, respaldado por tribunales, de primera parte, compatible con África, sin abusos, totalmente autorizado, seguro para uso del sector público. Algunas afirmaciones pueden ser ciertas. Algunas pueden ser marketing. Un registro que expone evidencia estructurada brinda a los compradores y operadores una forma de probar las afirmaciones sin convertir a AFRINIC en un árbitro comercial. El registro puede decir lo que ha validado y lo que no. El mercado puede poner precio al resto.

Esto es especialmente importante bajo estrés institucional. Durante la administración judicial, las disputas electorales o los litigios, los rumores se convierten en sustitutos de los registros. Si la base de datos pública no puede distinguir la operación descendente ordinaria de la delegación en disputa, o la protección de la privacidad del uso desconocido, las contrapartes inferirán a partir de los titulares. Una etiqueta de evidencia delgada puede evitar una reacción excesiva costosa. El registro no necesita garantizar cada hecho descendente. Necesita revelar el estado de los hechos que contiene.

La pila de evidencia debe leerse como un mapa de probabilidad. Cuanto más fuerte sea la combinación de subasignación registrada, contacto validado, origen de ruta coincidente, ROA actual, DNS inverso coherente y confirmación reciente, menor será el impuesto a la ambigüedad. Cuanto más débil sea la combinación, más precaución estará justificada. Así es como los mercados ya se comportan informalmente. AFRINIC puede mejorar el mercado haciendo que el mapa de probabilidad informal sea más explícito.

La accesibilidad para abusos es una consecuencia, no toda la historia

Las quejas por abuso son a menudo donde la opacidad de la subasignación se hace visible. Un banco ve ataques. Un proveedor de seguridad ve retrollamadas de malware. Un operador de correo ve spam. Un reclamante de derechos de autor ve alojamiento. Un organismo público ve escaneos contra un servicio gubernamental. El reclamante consulta el registro y envía un correo al contacto listado. Si el titular listado no es el operador real, el ticket comienza a moverse lateralmente: del titular al revendedor, del revendedor al proveedor de alojamiento, del proveedor de alojamiento al proveedor de firewall gestionado, del proveedor al cliente. Cada salto agrega demora y error.

Es tentador hacer del contacto de abuso todo el tema. Eso sería demasiado limitado. La accesibilidad para abusos es un resultado de la visibilidad descendente, no toda la economía. La misma visibilidad afecta la aceptación de enrutamiento, la diligencia en las transacciones, la continuidad del cliente, la contratación pública, el filtrado de sanciones, la respuesta de las fuerzas del orden, la geolocalización, el DNS inverso, el mantenimiento de RPKI y la gestión de la reputación. Un ticket de abuso es simplemente el momento en que la estructura oculta se vuelve lo suficientemente costosa como para notarla.

La política de contacto de abuso de AFRINIC es una evidencia útil de este rol limitado. Especifica un objeto dedicado como el lugar preferido para publicar información pública de contacto de abuso, referenciado en objetos inetnum, inet6num y aut-num. Su objetivo es ayudar a que los informes de abuso lleguen al contacto de red correcto. También reconoce una desventaja: el objeto enfrenta el mismo problema de precisión de datos que otros objetos y por sí solo no mejora la precisión de la base de datos. Ese es exactamente el punto. Un buzón de correo no resuelve la opacidad descendente si el buzón pertenece a la capa equivocada o si el titular no puede obligar al operador descendente a actuar.

Una estructura mejor vincula la accesibilidad para abusos con la visibilidad del rol. Si un bloque es operado por el titular, el equipo de abuso del titular debe ser el canal público principal. Si está subasignado a un ISP descendente, el canal de abuso validado del ISP descendente debe ser visible, con el escalamiento al titular preservado. Si se asigna a un cliente empresarial cuya identidad está protegida por privacidad, el registro público debe publicar un equipo operativo responsable o un proxy más una vía de escalamiento legal. Si es gestionado por un firewall o proveedor de alojamiento, el registro público debe mostrar qué capa operativa recibe el abuso primero. Si la responsabilidad está en disputa o desactualizada, el registro debe decirlo.

Esto evita dos fallos comunes. El primero es el problema del equipo equivocado, donde las quejas llegan al titular legal pero no al operador capaz de remediar. El segundo es el problema del cliente sin rendición de cuentas, donde el titular reclama privacidad o distancia del revendedor y ninguna parte localizable actúa. En ambos casos, el costo se traslada a terceros. Los bancos bloquean de más. Los proveedores ascendentes amenazan con suspender. Los servicios de reputación marcan el espacio vecino. Las fuerzas del orden escalan a través de canales más lentos. Los usuarios inocentes comparten la penalización.

La visibilidad del abuso también protege a los titulares. Un titular que puede mostrar responsabilidad descendente validada puede reducir su propia exposición. Puede decirle a un reclamante: este rango es operado por este rol descendente; aquí está el canal de abuso; el titular permanece disponible para escalamiento si el equipo descendente falla. Eso es mejor que recibir cada ticket, perder algunos y ser tratado como negligente. También es mejor que publicar identidades de clientes en bruto de una manera que cree riesgos de privacidad o seguridad.

Por lo tanto, la economía no se trata de hacer que cada titular tenga un gran departamento de abusos. Se trata de hacer que el camino hacia la responsabilidad sea lo suficientemente corto como para que los costos fijos de los incidentes no recaigan en terceros aleatorios. La visibilidad de la subasignación es la infraestructura más amplia que hace que la política de contacto de abuso funcione.

La redacción responsable es el trato de privacidad

La objeción más fuerte a la visibilidad descendente es la privacidad. Merece ser tomada en serio. Un registro público que nombre a cada cliente descendente podría exponer a organizaciones vulnerables, operaciones de seguridad, infraestructura de denunciantes, grupos políticos, contratistas del sector público, instituciones financieras, proveedores de salud y empresas comunes. También podría convertir el registro en una herramienta de reconocimiento. Los atacantes podrían mapear clientes, inferir relaciones de adquisición, identificar proveedores de seguridad gestionada, apuntar a ventanas de migración o presionar a los proveedores de servicios. Los competidores comerciales podrían saber quién aloja a quién. Una política de visibilidad que ignore estos daños se derrotaría a sí misma.

Pero la privacidad no justifica la opacidad total. Internet ya impone externalidades a los extraños. Los paquetes de un rango pueden atacar un banco, escanear un hospital, alojar páginas de phishing, contaminar la reputación del correo, desencadenar una revisión de sanciones o afectar un servicio público. Si la parte responsable está oculta detrás del lenguaje de privacidad y no existe un canal rastreable, la privacidad se convierte en una forma de exportar costos. El problema de diseño es preservar la confidencialidad preservando al mismo tiempo la rendición de cuentas.

La respuesta práctica es la divulgación escalonada. Los registros públicos deben llevar el rol, la capacidad de contacto, el estado, la fecha de validación y la solidez de la evidencia. No necesariamente deben publicar cada nombre legal del cliente. Las contrapartes autenticadas pueden recibir más detalles bajo contrato o necesidad operativa. El registro puede retener o verificar evidencia limitada sin divulgarla públicamente. Las fuerzas del orden y los tribunales pueden obtener información de identidad más profunda a través de una demanda legal. Pueden existir canales de emergencia para daños inminentes sin hacer rutinaria la divulgación de emergencia. Las personas pueden recibir una redacción más fuerte que los ISP descendentes corporativos. Las agencias públicas pueden usar contactos de seguridad designados en lugar de exponer a cada contratista.

La redacción debe etiquetarse, no ser silenciosa. "Identidad del cliente retenida por privacidad; el titular mantiene contacto rastreable; proxy de abuso validado" es económicamente diferente de "sin información descendente". Le dice a los terceros que hay una estructura responsable incluso si el nombre no es público. También crea responsabilidad para el titular: si el titular afirma tener trazabilidad protegida por privacidad, debe poder rastrear. La incapacidad de rastrear en condiciones definidas debería tener consecuencias, porque de lo contrario la privacidad se convierte en un estado falso.

La etiqueta también debe separar la privacidad del secreto comercial. La infraestructura sensible de un banco, un grupo de derechos humanos y la lista de clientes de un revendedor pueden merecer protección, pero por diferentes razones y contra diferentes niveles de divulgación. Un ISP descendente que recibe una subasignación formal /24 no está en la misma posición que un cliente individual que recibe una pequeña asignación. El interés público en identificar una red operativa es mayor que el interés público en nombrar a cada usuario final. El manual de políticas de AFRINIC ya contiene una adaptación de privacidad limitada cuando el usuario final es un individuo: el espacio puede registrarse con la información de contacto del proveedor mientras se hace referencia al usuario final en el objeto de la base de datos. Esa lógica puede extenderse cuidadosamente.

La prueba institucional es si el sistema puede responder una pregunta concreta: si surge daño, disputa o demanda legal, ¿quién puede actuar? No necesita responder a todas las curiosidades. No necesita publicar a todos los clientes. No debe permitir que la privacidad borre la responsabilidad. En un mercado de IPv4 escaso, el diseño de privacidad que funciona no es el secreto. Es la redacción responsable.

El enrutamiento, IRR y RPKI prueban la autoridad, no el uso

La evidencia de enrutamiento es poderosa porque es observable. Si un prefijo es originado por un AS particular, Internet operativo puede verlo. Si existe un objeto de ruta IRR, las redes pueden inferir una política de enrutamiento afirmada. Si un ROA autoriza un AS de origen, las partes confiadas pueden validar la autoridad de origen de la ruta. Estas señales son importantes para la visibilidad descendente, pero no deben confundirse con un relato completo del uso.

El origen BGP identifica la red que anuncia la ruta, no necesariamente al cliente que usa las direcciones. Un proveedor de alojamiento puede originar espacio para muchos clientes. Un proveedor de servicios gestionados puede anunciar un prefijo en nombre de una empresa. Un arrendador puede autorizar el AS de un arrendatario mientras el arrendatario atiende a miles de pequeños usuarios. Un proveedor de tránsito puede aparecer en la evidencia debido al manejo de rutas en lugar de la responsabilidad del cliente. El AS de origen es una pista sobre el control operativo, no una identidad legal para cada usuario descendente.

Los objetos IRR tienen límites similares. Pueden ayudar a los proveedores ascendentes y pares a construir filtros. Pueden mostrar que alguien ha creado un objeto de ruta o conjunto de rutas consistente con un origen afirmado. Pero los datos IRR pueden estar desactualizados, duplicados, creados en diferentes bases de datos con diferentes estándares de autenticación, o mantenidos por una parte que ya no es operativamente responsable. Un objeto IRR mantenido por el contacto técnico de un intermediario puede ayudar a explicar cómo se aceptó la ruta, pero no prueba quién maneja el abuso o los contratos de los clientes.

RPKI y ROA son más fuertes para la autoridad de origen, pero más limitados para la responsabilidad. Un ROA válido puede decir que un AS especificado está autorizado para originar un prefijo. No puede decir por qué el AS está usando el espacio, quién es el cliente descendente, si el uso es regional, si hay un revendedor involucrado, si los informes de abuso llegan al equipo correcto o si existe una asignación de cliente por debajo del prefijo cubierto. RPKI es una herramienta de seguridad de origen de ruta, no un sistema de identidad del cliente.

Esta distinción es importante para AFRINIC porque los servicios RPKI e IRR se encuentran cerca del reconocimiento del registro. Un titular puede crear un ROA para el AS de un arrendatario. Eso hace que la ruta parezca legítima en un sentido de seguridad. No hace visible la cadena descendente. Por el contrario, la ausencia de un ROA puede reflejar un retraso operativo o una baja adopción en lugar de un uso no autorizado. Si el registro público trata a RPKI como la única prueba, perderá el problema real de responsabilidad.

El uso correcto de la evidencia de enrutamiento es la triangulación. Un registro de rol descendente puede decir que el titular registrado ha autorizado al AS X a originar el prefijo Y; que existe o no un ROA; que existe un objeto IRR y está actual o desactualizado; que el contacto de abuso para el rol operativo es accesible; y que la identidad del cliente es pública, solo para autenticados o redactada por privacidad. Esto combina la autoridad de enrutamiento con la visibilidad de la responsabilidad. No sobrecarga un artefacto criptográfico o de política de enrutamiento con hechos que no puede probar.

La recuperación institucional de AFRINIC se beneficiaría de esta precisión. El registro no necesita convertirse en un juez omnisciente del uso descendente. Necesita dejar de permitir que una superficie de evidencia se haga pasar por otra. El enrutamiento dice accesibilidad. RPKI dice autoridad de origen. IRR dice afirmación de política. RDAP y WHOIS dicen reconocimiento y contactos registrados. El DNS inverso dice delegación de nombres. La visibilidad descendente dice quién es responsable por debajo del titular y qué tan seguro se puede estar.

El DNS inverso es una pista, no una prueba

El DNS inverso a menudo se trata como un servicio técnico secundario, pero en la visibilidad descendente tiene un peso práctico desproporcionado. Un registro PTR puede revelar una marca de alojamiento, un patrón de revendedor, una etiqueta de cliente, una pista de país, una identidad de servicio de correo o un uso antiguo que debería haberse eliminado hace años. Los sistemas de correo, las herramientas de seguridad, los equipos de soporte al cliente y los investigadores miran rutinariamente el DNS inverso porque ofrece una pista legible por humanos cuando el registro del registro es demasiado abstracto.

El manual de políticas de AFRINIC le da al DNS inverso un vínculo formal con el registro descendente. Dice que AFRINIC acepta solicitudes de delegación inversa de LIR activos y que no se permite la delegación inversa de espacio de direcciones IP administrado o asignado a menos que una asignación o subasignación de la asignación específica esté registrada apropiadamente en la base de datos de AFRINIC. Para una delegación inversa de /24, se debe registrar al menos una asignación o subasignación para ese /24 específico. Esa regla es un reconocimiento silencioso de que el DNS inverso no debe flotar libre de los hechos descendentes registrados.

La pista aún puede ser engañosa. El DNS inverso a menudo está desactualizado después de que un cliente se va. Las convenciones de nomenclatura pueden usar etiquetas genéricas que ocultan al operador real. Un titular puede delegar el DNS inverso a un revendedor cuyo cliente controla el servicio. Un proveedor de seguridad puede usar nombres neutrales para evitar exponer a los clientes. Un operador de correo puede establecer nombres para la capacidad de entrega en lugar de la identidad. Un usuario malicioso puede crear nombres engañosos. Por lo tanto, el DNS inverso no puede tratarse como prueba de identidad descendente.

Sin embargo, el DNS inverso desactualizado u opaco tiene consecuencias económicas. Los sistemas de reputación de correo pueden desconfiar de un rango. Los clientes pueden preguntar por qué los nombres apuntan a un proveedor anterior. Los equipos de seguridad pueden enviar quejas a la organización equivocada. Los proveedores de geolocalización e inteligencia de alojamiento pueden absorber etiquetas antiguas en los sistemas de riesgo. Un cliente del sector público puede fallar una revisión de adquisición o seguridad porque el nombre de la dirección no coincide con el servicio declarado. Un comprador puede exigir concesiones de precio si el control del DNS inverso parece poco claro. Un arrendatario puede descubrir que el arrendador no puede actualizar los nombres rápidamente porque el rastro de asignación registrado está incompleto.

La respuesta no es forzar nombres significativos en cada registro PTR. La nomenclatura operativa tiene compensaciones de seguridad y privacidad. La respuesta es tratar el DNS inverso como una superficie de evidencia. Un mapa de responsabilidad pública puede decir si el DNS inverso está controlado por el titular, delegado a un descendente, gestionado por el cliente, desactualizado, neutral en cuanto a privacidad o inconsistente con el rol registrado. Eso es más útil que tratar de inferir todo de los nombres en sí.

El DNS inverso también ilustra por qué la visibilidad de la subasignación no puede resolverse solo en RDAP o WHOIS. La base de datos del registro puede mostrar un titular y una subasignación. El árbol inverso puede mostrar una historia operativa diferente. La ruta puede mostrar una tercera. El contacto de abuso puede mostrar una cuarta. Un régimen serio de visibilidad reconcilia estas superficies. Señala inconsistencias sin asumir que cada inconsistencia es una mala conducta. Pregunta si la inconsistencia es importante para la accesibilidad, la reputación, el escalamiento legal o la confianza del mercado.

Para AFRINIC, una mejora limitada sería valiosa: cuando una delegación inversa está vinculada a una asignación o subasignación registrada, el registro público debe hacer legible el vínculo. Si un /24 tiene DNS inverso delegado porque existe una asignación de ISP descendente, los terceros deben poder ver que la delegación inversa no es aleatoria. Si el DNS inverso permanece bajo el titular mientras el uso operativo es descendente, el registro debe decir quién maneja los cambios de nombre y el escalamiento de abuso. Esto no expone a los clientes. Expone la responsabilidad de un servicio que ya les afecta.

Las afirmaciones de uso regional requieren humildad

La región de AFRINIC le da a la visibilidad de la subasignación una carga política especial. El registro sirve a África y parte del Océano Índico. Sus materiales de agotamiento y el manual de políticas enmarcan los recursos en torno a la región de servicio de AFRINIC. Su política de Aterrizaje Suave incluye un lenguaje de uso regional para los recursos durante el período de agotamiento. Los análisis públicos de la disputa de Cloud Innovation describieron las preocupaciones de AFRINIC sobre las discrepancias entre las descripciones de uso registradas y los países reales de uso, y sobre los servicios que se originan dentro de la región. Cloud Innovation y críticos alineados cuestionaron esa interpretación y argumentaron que la operación de la red global no puede reducirse a una simple regla geográfica.

Para la visibilidad descendente, el punto clave es que el uso regional no siempre es directamente visible. La geografía del enrutamiento no es la geografía del cliente. Un prefijo originado por un AS en Europa puede servir a usuarios africanos a través de una plataforma de contenido o seguridad. Un servidor en Johannesburgo puede soportar clientes en todo el mundo. Un titular registrado en Seychelles puede arrendar direcciones a una red con clientes en China, Nigeria y Sudáfrica. Una base de datos de geolocalización puede ubicar un bloque en un país debido a los datos del registro, en otro debido al enrutamiento y en un tercero debido a los informes de los usuarios. El DNS inverso puede usar códigos de país por conveniencia operativa. La latencia puede indicar dónde entra el tráfico a la red, no dónde se entrega el servicio económico.

Esto no significa que la evidencia de uso regional sea inútil. Significa que debe expresarse como confianza, no como certeza. Un registro de responsabilidad puede distinguir la región de servicio declarada, el origen de ruta observado, el consenso de geolocalización, la categoría del cliente, la dependencia africana, la operación fuera de la región y el estado desconocido. Puede decir si un titular ha auto-atestiguado que el uso respalda la conectividad con la región de AFRINIC, si el registro ha validado una afirmación específica de uso regional, si la evidencia es solo observada por enrutamiento o si la cuestión está en disputa. Eso es más honesto que pretender que un solo campo de país resuelve el asunto.

La humildad también es económicamente eficiente. Si el registro trata la inferencia débil como prueba, los titulares se resistirán a la divulgación y litigarán. Si los titulares tratan la geografía como incognoscible, el registro y las partes interesadas públicas asumirán evasión. Un registro basado en la confianza le da a ambas partes un vocabulario menos explosivo. Permite a AFRINIC ver patrones sin exigir listas de clientes en bruto para cada bloque. Permite a los titulares revelar la relevancia regional sin exponer a cada cliente. Permite a los mercados poner precio a la incertidumbre en lugar de inventar un binario de cumplimiento e incumplimiento.

La inferencia del uso regional también es importante para las afirmaciones de desarrollo. Algunos argumentan que el IPv4 emitido en África debería respaldar la conectividad africana. Otros argumentan que los mercados globales y la demanda entre regiones serán más importantes que proteger el remanente del stock regional. El libro mayor público no debe decidir ese debate a través de campos oscuros. Debe proporcionar evidencia: dónde se encuentra la responsabilidad descendente, qué uso se declara, qué se observa, qué se valida y qué sigue siendo incierto. Una buena evidencia puede informar la política. Una mala inferencia se convierte en control de capital por conjetura.

El estándar debe ser frío y práctico. Publicar el rol y la región declarados con el nivel de detalle adecuado. Etiquetar las señales observadas. Preservar la privacidad cuando esté justificado. Escalar solo cuando la evidencia entre en conflicto material con la política o la confianza pública. En una región donde el registro ya ha enfrentado litigios por el uso y el control, esa humildad no es debilidad. Es gestión de riesgos.

Los intermediarios necesitan etiquetas de responsabilidad

La cadena descendente moderna rara vez es una línea recta. Un titular puede trabajar con un intermediario. El intermediario puede presentar a un revendedor. El revendedor puede empaquetar direcciones en productos VPS, correo, VPN o firewall gestionado. Un proveedor de alojamiento puede operar el AS de origen. Un cliente puede controlar el servidor. Un proveedor de abuso de terceros puede clasificar las quejas. Un proveedor de DNS gestionado puede controlar las zonas inversas. El registro público puede mostrar solo al titular y quizás el AS de origen. Cuando surgen problemas, cada capa puede decir que otra capa tiene los hechos operativos.

Los intermediarios y revendedores no son inherentemente malos. Reducen los costos de búsqueda, emparejan la capacidad no utilizada con la demanda, proporcionan incorporación técnica, reúnen documentación y ayudan a las redes más pequeñas a obtener direcciones que de otro modo no podrían encontrar. Los proveedores de servicios gestionados también resuelven problemas reales. Muchos clientes no quieren ejecutar enrutamiento, DNS inverso, equipos de abuso o RPKI. La externalización puede mejorar la calidad. El problema de visibilidad no es la intermediación. Es la intermediación sin etiquetar.

Una etiqueta de responsabilidad es una divulgación limitada del rol. No dice que el intermediario sea dueño del bloque o que el revendedor sea el cliente final. Puede decir que hay un intermediario comercial involucrado pero no es el contacto operativo. Puede decir que un revendedor es responsable de la investigación de clientes. Puede decir que un operador de servicios gestionados recibe los abusos primero. Puede decir que el titular sigue siendo responsable de los cambios en el registro. Puede decir que un ISP descendente controla las asignaciones de clientes. Puede decir que la identidad del cliente está redactada por privacidad pero es rastreable a través del operador. Las etiquetas les dicen a los terceros dónde no enviar la solicitud equivocada.

Dichas etiquetas reducirían los fallos comunes. Un proveedor ascendente que evalúa una ruta sabría si el AS de origen está actuando como arrendatario, operador gestionado o red del titular. Un reclamante sabría si el buzón de abuso público llega al operador más cercano al cliente. Un comprador sabría si los revendedores no revelados pueden tener reclamos de continuidad del cliente. Un comprador público sabría si el suministro de direcciones de un contratista depende de una cadena intermediada. El registro sabría si un titular que reclama privacidad al menos ha mapeado su cadena de responsabilidad.

Las etiquetas de responsabilidad también ayudan a distinguir los arrendamientos de la visibilidad de la subasignación sin hacer de los arrendamientos el marco principal. El arrendamiento es un canal a través del cual aparece la opacidad. La pregunta relevante aquí no son los remedios privados del arrendamiento o su precio comercial. Es si el arrendamiento u otra delegación comercial cambia quién está usando el espacio y con quién se puede contactar. Un arrendamiento con etiquetas de responsabilidad claras puede ser menos riesgoso que una asignación de alojamiento ordinaria sin trazabilidad. Una venta con clientes descendentes ocultos puede ser más problemática que una delegación transparente por tiempo limitado.

La misma lógica se aplica a la privacidad del cliente. Una etiqueta puede decir "usuario final protegido por privacidad, rastreable por el titular" sin nombrar al usuario final. Puede decir "contacto para fuerzas del orden disponible a través del escalamiento del titular" sin publicar canales sensibles. Puede decir "lista de clientes controlada por el revendedor" para que las contrapartes sepan que el titular puede no tener registros inmediatos. Esto no es una lista de clientes. Es un mapa de quién tiene qué deber operativo.

Los intermediarios se vuelven económicamente más seguros cuando sus roles son legibles. Si se resisten a toda divulgación de roles, los mercados asumirán lo peor. Si el registro exige la divulgación completa del cliente, los intermediarios legítimos se resistirán. Las etiquetas ofrecen una alternativa de menor costo: responsabilidad visible, identidad protegida e incertidumbre con precio.

La dependencia del sector público convierte la opacidad en un riesgo para la capacidad estatal

La opacidad de la subasignación se vuelve más grave cuando los sistemas del sector público dependen de la cadena de direcciones. Un ministerio puede alojar servicios ciudadanos con un proveedor local que utiliza direcciones de un titular regional. Un hospital público puede comprar seguridad gestionada a un proveedor cuyos nodos de firewall se encuentran dentro de un bloque arrendado o subasignado. Una unidad de ciberdelincuencia policial puede necesitar información de suscriptores o clientes después de un incidente. Una red educativa nacional puede depender de proveedores descendentes para los campus. Un tribunal puede necesitar preservar evidencia mientras un servicio permanece en línea. En cada caso, el organismo público puede no saber que su continuidad depende de una cadena de direcciones de varias capas de profundidad.

Para los clientes comerciales ordinarios, la opacidad es un problema de asignación de riesgos. Para los clientes del sector público, puede convertirse en un problema de capacidad estatal. Un portal de impuestos que pierde la capacidad de entrega de correo porque el DNS inverso está desactualizado, una plataforma de adquisiciones que se bloquea porque las direcciones vecinas son abusivas, o un proveedor de servicios de emergencia que no puede probar la autoridad de la ruta no solo enfrenta un inconveniente de TI. El costo recae sobre los ciudadanos y las instituciones públicas que no eligieron la estructura de direcciones oculta.

Las necesidades de las fuerzas del orden también son específicas. Los investigadores a menudo comienzan con una dirección IP, una marca de tiempo y un puerto. Si el registro público nombra solo al titular, el investigador debe recorrer la cadena: titular, revendedor, proveedor gestionado, cliente, usuario final. NAT, CGNAT, arrendamiento de VPS y alojamiento a corto plazo hacen que el tiempo sea crítico. Si el titular no mantiene la trazabilidad o si el revendedor no está registrado, las solicitudes legales pueden llegar demasiado tarde o a la parte equivocada. La divulgación pública excesiva no es la respuesta, pero una vía de escalamiento estructurada sí lo es.

La historia de crisis de AFRINIC eleva las apuestas porque las autoridades públicas ya pueden estar mirando al registro como institución. Los informes en torno a la administración judicial mauriciana describieron un mandato para preservar las operaciones y restaurar la gobernanza, mientras que la cobertura posterior describió la continua presión judicial, los mecanismos electorales fallidos, las preguntas sobre la restauración de la junta, las demandas y las disputas sobre el tratamiento de los recursos de numeración. En tal entorno, los usuarios del sector público necesitan evidencia de que la continuidad de las direcciones no depende de acuerdos privados no registrados que colapsen bajo litigios o cambios de gobernanza.

Un estándar de adquisición del sector público podría ser simple. Los proveedores que utilicen IPv4 administrado por AFRINIC para servicios públicos deben poder mostrar el titular registrado, la red operativa, la autoridad de origen de la ruta, el control del DNS inverso, los contactos de abuso y seguridad, las etiquetas de responsabilidad descendente, los acuerdos de privacidad, el escalamiento de solicitudes legales y cualquier disputa que afecte al espacio. La versión pública no necesita revelar a todos los clientes. El archivo orientado al comprador debe ser lo suficientemente completo como para respaldar la continuidad y la rendición de cuentas.

Por lo tanto, la dependencia del sector público cambia el equilibrio de la privacidad. El público no necesita el nombre de cada cliente. Sí necesita la seguridad de que los servicios críticos tienen una responsabilidad de dirección rastreable. Un registro que ayuda a crear esa seguridad no se está convirtiendo en un organismo de vigilancia. Está reduciendo el riesgo de adquisición pública en un mercado donde la escasez de direcciones y la inestabilidad institucional han hecho visible la capa de direcciones.

La recuperación se juzgará por debajo de la línea del titular

AFRINIC no necesita un régimen de transparencia máxima. Necesita un pacto de visibilidad que establezca para qué sirve la visibilidad descendente: unicidad, resolución de problemas, accesibilidad para abusos, diligencia de autoridad de ruta, consistencia del DNS inverso, escalamiento legal, confianza en las transacciones y continuidad para los clientes que dependen del IPv4 escaso. También debe establecer para qué no sirve la visibilidad: publicar listas de clientes en bruto, juzgar cada acuerdo comercial, exponer a usuarios sensibles o utilizar campos de registro como palanca en disputas no relacionadas.

El pacto podría comenzar con algunos tipos de registro. Las subasignaciones formales en o por encima del mínimo de la política deberían ser públicamente visibles con la identidad del ISP descendente, contactos, estado, fecha de validación y escalamiento al titular. Las asignaciones de usuario final que requieren responsabilidad operativa pública deberían identificar al usuario final o a un proxy protegido por privacidad con etiquetas de rol claras. Los rangos de clientes más pequeños por debajo de los umbrales de subasignación pública no necesitan ser nombrados públicamente, pero los titulares deben mantener la trazabilidad y publicar etiquetas de responsabilidad cuando el abuso, el enrutamiento, el DNS inverso o las solicitudes legales hagan que el rol sea material.

Cada registro debe llevar el estado de la evidencia: validado por el registro, atestiguado por el titular, confirmado por la contraparte, observado por enrutamiento, redactado por privacidad pero rastreable, desactualizado, en disputa o limitado por orden judicial. Estas etiquetas evitarían que un campo público pretenda ser más seguro de lo que es. También permitirían que los mercados recompensaran una mejor evidencia. Un bloque con responsabilidad descendente actual debería ser más barato de enrutar, transferir, arrendar, financiar y adquirir que un bloque con datos desactualizados solo del titular.

El pacto debería incluir ciclos de validación. Los contactos y las etiquetas de rol deben caducar a menos que se actualicen. Los cambios materiales, como un nuevo ISP descendente, un nuevo AS de origen, una adquisición de servicios gestionados, un cambio de delegación de DNS inverso o una gran migración de clientes, deberían desencadenar obligaciones de actualización. La falta de actualización debería producir primero incertidumbre visible y procedimientos de subsanación, no un deterioro inmediato de los recursos. Los remedios severos deberían reservarse para declaraciones falsas, uso de alto riesgo no rastreable, fraude, órdenes judiciales o negativa reiterada a mantener la responsabilidad mínima.

También debería haber una capa de evidencia privada. Los titulares deben mantener registros de las asignaciones de clientes, autorizaciones, contratos de revendedores, escalamiento de abusos, permisos de enrutamiento y justificaciones de privacidad. AFRINIC no debería necesitar todos los documentos por defecto. Debería poder solicitar evidencia proporcionada cuando una subasignación formal, una dependencia del sector público, una transferencia, una disputa, un patrón de abuso importante o un conflicto de DNS inverso/RPKI haga que el rol descendente sea material. La solicitud debe ser específica, limitada en el tiempo y más limitada que una auditoría de todos los clientes, a menos que la evidencia justifique más.

El pacto debería recompensar la corrección. Si un titular actualiza voluntariamente la responsabilidad descendente desactualizada, la respuesta predeterminada debería ser la corrección del registro, no la aplicación generalizada. De lo contrario, los titulares racionales se esconderán. El fraude y la falsedad intencional requieren un tratamiento diferente, pero la corrección ordinaria debe alentarse. Un registro que se recupera de un historial de corrupción de registros debe ser firme contra la falsedad y seguro para la verdad.

La recuperación pública de AFRINIC a menudo se discute a través de juntas, presupuestos, administración judicial, órdenes judiciales, intervención de la ICANN y legitimidad institucional. Esos asuntos son reales. Pero para muchos operadores, la prueba práctica se situará por debajo de la línea del titular. ¿Puede un cliente, un proveedor ascendente, un comprador, un organismo público, un equipo de aplicación de la ley o un informante de abusos entender quién es responsable de un uso específico del IPv4 escaso cuando ese uso no es del titular registrado? Si no, la recuperación de la gobernanza sigue siendo demasiado abstracta.

El registro puede preservarse legalmente y aún dejar la responsabilidad descendente opaca. Puede elegir una junta y aún así exponer solo registros a nivel de titular. Puede operar RDAP, WHOIS, DNS inverso, IRR y RPKI y aún así no conectar esas superficies en un mapa de responsabilidad. Puede anunciar políticas y aún así hacer que los mercados adivinen si un prefijo enrutado es operado por el titular, operado por un revendedor, arrendado, subasignado, asignado, protegido por privacidad o en disputa. En un mercado de escasez, esa adivinanza es costosa.

La historia reciente de AFRINIC le da tanto razón como obligación de hacerlo mejor. Los informes de robo de direcciones muestran el peligro de una autoridad de registro débil. La disputa de Cloud Innovation muestra el peligro de la colisión entre la delegación comercial opaca y la amplia discreción del registro. La administración judicial muestra la necesidad de continuidad cuando falla la gobernanza corporativa. La discontinuidad electoral muestra que la autoridad de los miembros y la legitimidad institucional pueden convertirse en hechos de mercado. Los litigios continuos muestran que las afirmaciones públicas sobre arrendamiento, comercialización y reconocimiento judicial pueden mover la confianza. La visibilidad de la subasignación no resolverá todo eso. Reducirá una incertidumbre importante que de otro modo alimenta el resto.

La postura institucional correcta es modesta. AFRINIC no debe pretender conocer a todos los clientes. No debe convertirse en el regulador económico de todos los servicios descendentes. No debe exigir listas de clientes como sustituto de una política clara. No debe utilizar la visibilidad para castigar acuerdos comerciales impopulares sin las debidas salvaguardas. Pero debe insistir en que los titulares registrados puedan explicar y evidenciar la responsabilidad descendente al nivel en que los terceros confían en el registro de direcciones. Esa es la diferencia entre un libro mayor y una niebla privada.

El beneficio es práctico: informes de abuso más precisos, filtrado menos burdo, cambios de DNS inverso y RPKI más limpios, menos diligencia dependiente de intermediarios, adquisiciones públicas más sólidas y clientes protegidos con trazabilidad responsable. Los mercados valorarían la responsabilidad verificada en lugar de los rumores.

El pacto también disciplinaría a los titulares. Un titular que alquila, asigna, subasigna o delega capacidad IPv4 escasa no debería poder decir simplemente: el libro mayor público me nombra, por lo tanto, todos los demás deben confiar en mí. El titular es el ancla, no toda la historia. Si se beneficia del uso descendente, protege a los clientes o utiliza intermediarios, debe saber quién puede actuar. Si no puede, el mercado tiene razón al descontar el bloque.

AFRINIC es un caso de prueba porque el registro de África ha vivido la colisión total de la escasez, la integridad de los registros, la delegación comercial, los litigios y la recuperación institucional. La lección no es que todos los usuarios descendentes deban ser públicos. Es que la responsabilidad no puede permanecer privada cuando los costos de su ausencia son públicos. Un libro mayor de registro útil no expone la lista de clientes. Expone lo suficiente de la cadena de responsabilidad para que los extraños actúen sin unirse a la lucha.