Resumen

  • Entre 2003 y abril de 2005, RIPE NCC gestionó asignaciones IPv4 para países africanos al norte del ecuador y dejó de asignar en la región; AFRINIC, incorporada en Mauricio en 2004 y reconocida por ICANN como quinto registro regional de Internet (RIR) en abril de 2005, asumió la función registral.
  • El proyecto AFRINIC-ERX transfirió objetos inetnum y aut-num, números de sistema autónomo y espacio independiente del proveedor desde la base de datos RIPE a la base de datos AFRINIC; los objetos DOMAIN asociados se eliminaron y la redelegación del DNS inverso pasó a depender de la parte receptora.
  • La política ICP-2 exige que un RIR mantenga procedimientos de continuidad, redundancias y compartición de registros para que otro RIR pueda prestar sus servicios si fuera necesario, pero no se localizó ningún instrumento que convirtiera esa exigencia en una garantía activable de forma independiente sobre los datos, las delegaciones o los expedientes de miembros.
  • La auditoría interna de AFRINIC, encargada en julio de 2019 y pública hacia enero de 2021, cuantificó 2.371.584 direcciones IPv4 mal atribuidas del fondo libre y 1.799.168 direcciones IPv4 heredadas comprometidas.
  • La prueba observable de continuidad es operativa, no institucional: si el WHOIS y el RDAP responden y están completos, si las delegaciones de DNS inverso siguen resolviendo y si los miembros pueden recuperar sus registros. Ninguna de esas condiciones quedó confirmada por las fuentes examinadas.

Lo que se transfirió, y lo que no

Antes de que existiera un registro africano propio, los operadores de red del continente obtenían recursos numéricos de APNIC, ARIN y RIPE NCC. RIPE NCC gestionó asignaciones y cesiones de IPv4 para los países africanos al norte del ecuador entre octubre de 2003 y abril de 2005, y cesó la asignación en la región africana en abril de ese año (documentación de RIPE NCC sobre el fin de las asignaciones). El reconocimiento formal llegó con un calendario que conviene precisar: AFRINIC se incorporó en Mauricio en 2004, el consejo de ICANN dio aprobación provisional el 30 de septiembre de 2004, y el reconocimiento como quinto RIR se produjo en abril de 2005 bajo los criterios de ICP-2; AFRINIC se convirtió en el quinto miembro de la NRO el 27 de abril de 2005 (registro de reconocimiento y aprobación; criterios y proceso de ICP-2).

La transición no fue solo un cambio de nombre en una base de datos. RIPE NCC dio por terminados los Acuerdos de Servicio Estándar con sus miembros africanos, AFRINIC suscribió nuevos contratos con ellos y, como parte del proceso, AFRINIC firmó un acuerdo de confidencialidad que cubría la información de los registros locales de Internet (términos del traspaso de membresía). El proyecto AFRINIC-ERX transfirió objetos inetnum y aut-num —además de números de sistema autónomo y espacio independiente del proveedor— desde la base de datos RIPE a la base de datos AFRINIC, y todos los objetos referenciados se transfirieron o copiaron; AFRINIC también heredó registros de ARIN y APNIC (descripción del proyecto de transferencia de datos; resumen de la transferencia de registros).

El punto más fino, y el más frecuentemente pasado por alto, está en el DNS inverso. Cuando los recursos se trasladaron de RIPE NCC a otro RIR, los objetos DOMAIN asociados en la base de datos RIPE se eliminaron y la responsabilidad de solicitar una nueva delegación de DNS inverso recayó de inmediato sobre la parte receptora (condiciones de la transferencia de objetos; nota sobre delegaciones y registros). No se trataba de una migración automática con verificación de que el destino estuviera resuelto, sino de una supresión seguida de una obligación de volver a solicitar. Ese detalle importa porque convierte la continuidad en una tarea del receptor, no en una condición del traspaso.

Cuatro puntos de control

Un traspaso de función registral se puede auditar en cuatro lugares: quién decide, quién custodia el dato, quién puede detectar que algo se rompió y quién puede repararlo. La documentación disponible permite reconstruir los dos primeros con precisión y deja los dos últimos notablemente abiertos.

Quién decide. ICP-2 establece que las propuestas de reconocimiento o desreconocimiento de un RIR se originan en el Consejo Ejecutivo de la NRO tras una votación mayoritaria, con ICANN como autoridad final; IANA, administrada por ICANN, conserva la responsabilidad última sobre el espacio IPv4, IPv6 y de números de sistema autónomo asignado y no asignado, y delega bloques a los RIR (proceso de reconocimiento y autoridad de IANA; marco institucional).

Quién custodia el dato. Durante la transición, el custodio pasó de ser RIPE NCC a ser AFRINIC. Íntegramente. Los objetos, los objetos referenciados, los contratos de membresía y la autoridad de DNS inverso quedaron del lado receptor. ICP-2 exige que un RIR mantenga registros auditables y archivos de la información de los registros locales de Internet, precisamente para demostrar una operación responsable y neutral (requisitos de registro y auditoría).

Quién detecta. ICP-2 pide procedimientos de continuidad, redundancias y compartición de registros «para permitir que otro RIR pueda prestar sus servicios si fuera necesario». Es una exigencia de diseño, no un mecanismo de detección: no hay en el texto un disparador automático, ni una auditoría independiente periódica del contenido del registro, ni una señal pública obligatoria cuando el custodio deja de poder operar. La única vía de apelación documentada es la del artículo 9 del MoU de la NRO, que crea un Panel Asesor de Apelaciones para quejas sobre fallos en el proceso documentado de desarrollo de políticas globales; ese panel informa al Consejo Ejecutivo y es un recurso de proceso político, no una custodia de datos ni un mecanismo de conmutación por error (cláusulas del MoU de la NRO).

Quién repara. ICP-2 sí prevé un proceso de desreconocimiento y traspaso: un RIR desreconocido debe cooperar con ICANN y con los demás RIR para garantizar una transferencia ordenada de sus operaciones a una entidad sucesora o interina designada. La cláusula existe, y es más fuerte de lo que sugiere su lenguaje administrativo. El problema es que presupone un RIR en condiciones de cooperar. En un escenario de insolvencia o de control judicial, la entidad que debe cooperar es precisamente la que ya no controla sus propias decisiones.

La auditoría de 2019: el registro se puede romper por dentro

La continuidad no solo se prueba con el colapso institucional. Se prueba también con la integridad del contenido. Una auditoría de AFRINIC encargada en julio de 2019 y hecha pública hacia enero de 2021 encontró que 2.371.584 direcciones IPv4 del fondo libre de AFRINIC habían sido mal atribuidas; unas 1.060.864 fueron recuperadas y colocadas en cuarentena de doce meses, mientras 1.310.720 vinculadas a dos organizaciones seguían pendientes de recuperación por diligencia debida en curso. A eso se sumó un segundo bloque: 1.799.168 direcciones IPv4 heredadas comprometidas, de las cuales 394.496 se consolidaron, cambios no justificados sobre 467.968 fueron revertidos y 936.704 quedaron en disputa sobre su titularidad legítima. Entre las medidas correctivas figuró la incorporación de capas adicionales de verificación (hallazgos y remedios de la auditoría; cobertura del proceso de auditoría).

Las cifras importan menos por su magnitud que por lo que demuestran sobre el modelo de custodia. El único mecanismo que detectó la desviación fue una auditoría disparada por una circunstancia externa, no por un control ordinario del propio registro; y la reparación dependió de que el custodio todavía existiera, tuviera acceso a sus registros y pudiera revertir cambios. Un diseño que confía la integridad a la buena salud del custodio no tiene una respuesta preparada para el caso en que el custodio sea el problema.

2024–2025: la continuidad puesta a prueba

AFRINIC y Cloud Innovation Ltd litigan desde mediados de 2019. El 19 de julio de 2022 la Corte Suprema de Mauricio falló a favor de Cloud Innovation y dejó sin efecto la objeción preliminar de AFRINIC. AFRINIC fue puesta bajo administración judicial; el 15 de octubre de 2024 la Corte de Apelaciones Civiles conoció una apelación sobre la orden de administración, y el 10 de febrero de 2025 la División de Quiebras terminó el nombramiento del administrador oficial inicial y designó a Gowtamsingh Dabee, ampliando el plazo para las elecciones de la junta hasta el 25 de abril de 2025 (cronología del litigio y la administración; desarrollos del proceso).

En 2025 el conflicto se volvió un problema de supervisión del proceso electoral. ICANN escribió el 6 de junio de 2025 al administrador judicial designado por el tribunal exigiendo transparencia y equidad en las elecciones de la junta, presentó una solicitud ante la Corte Suprema de Mauricio el 19 de junio de 2025, obtuvo una orden para que el administrador emitiera un comunicado a los miembros sobre un registro erróneo, y volvió a escribir el 25 de junio de 2025 advirtiendo de una posible revisión de cumplimiento por presunta conducta fraudulenta. La elección fue suspendida el 23 de junio de 2025 y finalmente se celebró del 10 al 12 de septiembre de 2025 (intervenciones y advertencia de ICANN; seguimiento del proceso electoral).

El 25 de julio de 2025 el presidente de Mauricio declaró a AFRINIC «declared company» bajo la sección 230 de la Ley de Sociedades, tras una petición de liquidación presentada por Cloud Innovation Ltd. La declaración suspende los casos judiciales existentes en los que AFRINIC es parte y activa una investigación encargada por el gobierno sobre sus asuntos (declaración bajo la sección 230; contexto de la medida).

Es el escenario exacto para el que un traspaso bien diseñado habría escrito una respuesta. La cláusula de cooperación de ICP-2 —transferir operaciones a una entidad sucesora o interina— depende de la voluntad y la capacidad de la entidad bajo administración. Mientras tanto, la autoridad de DNS inverso, la relación con los miembros y la copia autoritativa de los datos siguen vinculadas al mismo custodio que atraviesa el proceso de insolvencia.

El traspaso no escrivió la custodia

Este es el hallazgo central y debe formularse con precisión. No se localizó ningún instrumento público que inscribiera en el traspaso de 2004–2005 un depósito de datos activable de forma independiente, una garantía de continuidad del DNS inverso o un derecho de portabilidad de los expedientes de miembros. Las obligaciones de continuidad aparecen únicamente como requisitos generales de ICP-2 sobre el RIR receptor, y hoy la compañía bajo administración judicial es el sujeto de esas obligaciones, no su ejecutor (límites del marco de continuidad; alcance de la transferencia; tratamiento de los objetos y delegaciones).

Conviene distinguir tres cosas que suelen confundirse. La primera es la legitimidad del reconocimiento: que AFRINIC fuera reconocida conforme a ICP-2 está documentado. La segunda es la titularidad de los recursos: IANA delega bloques a los RIR, y esa cadena no se rompe formalmente porque un RIR entre en dificultades. La tercera es la continuidad operativa: quién conserva la copia autoritativa, quién puede reponer una delegación de DNS inverso y quién puede certificar a un miembro qué direcciones le corresponden. Las dos primeras están razonablemente cubiertas por instrumentos públicos; la tercera no lo está.

Lo que probaría lo contrario

Una conclusión de este tipo debe poder ser refutada. La prueba de continuidad es operativa. Se refutaría si el WHOIS y el RDAP de AFRINIC permanecen consultables y completos bajo administración judicial y durante la investigación gubernamental; si las delegaciones de DNS inverso de los recursos transferidos siguen resolviendo sin intervención del custodio en dificultades; si un miembro puede obtener de forma verificable el expediente completo de sus recursos, incluida la porción heredada; y si existe un rol de respaldo de RIPE NCC para algún subconjunto de lo transferido. Ninguna de esas cuatro condiciones quedó confirmada por las fuentes examinadas (estado del registro y las delegaciones; condiciones del traspaso; obligaciones del receptor).

El registro público del objeto cubierto por este análisis está en RIPE NCC to AFRINIC Transition.

Qué queda abierto

Este artículo no localizó el acuerdo exacto del traspaso de 2004–2005 entre RIPE NCC y AFRINIC, ni las especificaciones de transferencia de datos del proyecto AFRINIC-ERX en forma primaria, ni los términos de terminación de los Acuerdos de Servicio Estándar y las obligaciones que pudieran haberse debido a los miembros africanos. Tampoco estableció qué custodia conserva hoy AFRINIC sobre los datos del registro, las delegaciones de DNS inverso y los expedientes de miembros durante la administración judicial y el proceso de «declared company», ni si RIPE NCC retuvo alguna obligación de respaldo.

Son huecos de evidencia, no indicios de irregularidad; y son, en sí mismos, parte del hallazgo sobre el diseño del traspaso.