Resumen

  • El borrador 2 conserva la base del 90 % y propone una exención para fines técnicos clave demostrados.
  • Un expediente debería mostrar topología, tamaño solicitado, cálculo de utilización, alternativas y controles contra el fraude.
  • El consenso aproximado de AFRINIC 37 y el estado Last call no equivalen a ratificación ni implementación.

Nota de publicación: Publicado es la fecha editorial programada, 7 de septiembre de 2026. La hora efectiva de publicación en el servidor está sin definir.

La sección 5.4.6.1 del CPM vigente exige que un LIR o usuario final que solicite otra distribución o asignación IPv4 durante la fase de agotamiento haya utilizado al menos el 90 % de sus recursos anteriores. La primera solicitud de un LIR o usuario final nuevo sin recursos previos está exceptuada.

AFPUB-2026-IPv4-002-DRAFT02, fechado el 16 de junio de 2026 tras el borrador inicial del 6 de mayo, mantendría esa regla. Permitiría una exención cuando AFRINIC verifique un fin técnico clave demostrado que no pueda atenderse prácticamente con el conjunto de recursos existente, o que genere limitaciones técnicas para él. Los ejemplos no exhaustivos son redundancia y alta disponibilidad, mecanismos de transición a IPv6 y expansión a nuevos sitios.

El texto exige una justificación suficientemente documentada para comprobar el cumplimiento, pero no establece un esquema público de pruebas, un expediente mínimo, un registro de decisión ni una obligación de publicar los casos.

La diferencia importa porque una “finalidad técnica clave” podría confundirse con una preferencia operativa. Los ejemplos de ampliación de un centro de datos y de un ISP con varios puntos de presencia BGP que utiliza 464XLAT y NAT64 pertenecen al autor de la propuesta; no prueban que un miembro concreto cumpla. El autor atribuye además la ausencia de riesgo inmediato para el pool a unos tres millones de direcciones IPv4 recuperadas. Es un argumento de política atribuido, no un inventario medido de forma independiente en este expediente.

El personal de AFRINIC considera que el 90 % sigue siendo la condición de referencia y que la excepción debe limitarse a restricciones técnicas, no operativas. Señala que los hostmasters necesitarían una política documentada y que los procedimientos deben identificar solicitudes fraudulentas. Habría que actualizar procedimientos y preguntas frecuentes de Member Services; no se identifican cambios en WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP o RPKI.

El personal estima que la implementación podría encajar en el calendario del CPM, con un objetivo de 30 días después de la ratificación: es una evaluación y un plan, no prueba de ratificación o implementación.

En AFRINIC 37, el 24 de junio de 2026, se debatió la dificultad de alcanzar el 90 % en varios sitios y la diferencia entre uso eficiente y topología operativa. La decisión formal de los presidentes registró consenso aproximado y anunció una definición de utilización durante Last Call. En el micrófono abierto, una intervención dijo primero que la propuesta no había pasado; el copresidente del PDWG aclaró después que sí había alcanzado consenso aproximado. Al cierre informativo, la página de propuestas la marca Last call. Esa fase de revisión comunitaria sigue separada de una recomendación al Board, su ratificación y su implementación.

Análisis BTW: expediente probatorio propuesto. Debería incluir topología, sitios y funciones de servicio; justificación del tamaño del prefijo; cálculo actual y previsto de utilización; alternativas consideradas; necesidad limitada en el tiempo; controles antifraude; identidad del revisor; fecha de decisión; condiciones y revisión posterior. Un recibo debería registrar la regla aplicada, las pruebas decisivas, los motivos y las condiciones. Es una recomendación de BTW, no un producto ni requisito adoptado por AFRINIC.