Resumen

  • El manual vigente de AFRINIC separa las direcciones de peering de las de gestión, reserva un bloque para los IXP y contempla un /24 adyacente para que cada uno pueda crecer hasta un /23. En la AFRINIC-37, el personal también informó que algunos miembros intercambiaban prefijos entre esos usos, en contra de la política.
  • Andrew Owens, de NAPafrica, describió la instalación de Johannesburgo: dos bloques /23, un /22 cerca de la utilización completa y la posible necesidad de otros dos /23 para llegar a un /21. Dijo que una renumeración iniciada ocho años antes seguía incompleta. Es el relato de un operador, no un cálculo de la demanda africana ni una duración habitual.
  • Antes de pasar de una reserva /16 a una /15, la comunidad necesita datos de consumo y de miembros afectados, además de un diseño para el crecimiento contiguo y la transición. Un bloque mayor puede aliviar la escasez; por sí solo, no garantiza que la siguiente asignación encaje donde la red la necesita.

Análisis

«¿De qué tamaño?» no es la única pregunta

La página vigente del Consolidated Policy Manual identifica la versión 1.6 como actual y consigna como fecha de publicación el 17 de noviembre de 2020. La sección 11 de ese manual no se limita a fijar una cifra. Distingue la LAN de peering —el bloque contiguo donde los miembros intercambian tráfico— de la red de gestión, que sostiene la supervisión, las estadísticas, el correo y otros servicios. Indica que las direcciones de gestión no deben salir del bloque de peering. Describe un bloque específico y publicado para peering, junto con un /24 adyacente reservado para que el punto de intercambio pueda crecer hasta un /23 sin obtener otro bloque y renumerar. La sección propone una reserva de /16 para peering y otra /16 equivalente, separada, para gestión. El manual

Durante la reunión, un participante preguntó si el /16 reservado bastaba para toda la región o si un /15 sería más adecuado. Un /15 contiene el doble de direcciones que un /16, pero esa cuenta no indica cuántas asignaciones contiguas quedan, a qué ritmo se consume el espacio ni qué solicitantes pueden quedarse sin respuesta. El personal de AFRINIC dijo que aportaría estadísticas de consumo para que la comunidad pudiera deliberar con mejores datos. Otro participante pidió conocer cuántos miembros resultaban afectados antes de valorar la urgencia. El acta de AFRINIC-37

Pedir esos datos no es un detalle de procedimiento. Una reserva funciona a la vez como regla de inventario y como regla de asignación. El tamaño indica cuánto espacio se aparta. La unidad de asignación y la regla de adyacencia determinan si un operador puede ampliar su red. Los registros que muestran quién recibió direcciones, para qué uso y con cuánto margen constituyen una tercera cuestión. Decidir solo sobre la primera puede aumentar el inventario y dejar sin resolver el siguiente escalón de crecimiento.

La infracción descrita no explica por sí sola su causa

El acta recoge que algunos miembros estaban intercambiando prefijos de peering y de gestión fuera de lo previsto en la política, y que el personal trabajaba con ellos para alinear su uso. Es un problema de aplicación. El documento no explica por qué se produjeron esos cambios, cuántos miembros participaron ni si la causa principal estaba en la regla, en los registros, en el proceso administrativo o en la práctica operativa. La diferencia importa: reescribir la política antes de identificar el modo de fallo puede mover el texto sin corregir el uso.

Las secciones 5.6.4 y 11 del manual están relacionadas, pero regulan superficies distintas. La primera describe asignaciones IPv4 para infraestructura crítica, por lo general de hasta /24, aunque permite varias en ciertas circunstancias. La segunda trata los bloques reservados para peering y gestión de los IXP; su /24 adyacente pretende permitir el paso a /23 sin renumeración. El manual define un IXP como una infraestructura física de capa 2 operada por una sola entidad, con al menos tres proveedores conectados y una política abierta a nuevos participantes. Los criterios públicos de AFRINIC también piden acreditar presencia legal, AS y contactos de pares o memorandos firmados, que el intercambio sea público y abierto y una licencia cuando las reglas del país la exijan. Criterios de AFRINIC

Esos requisitos ayudan a determinar quién puede solicitar recursos, pero no cuantifican la demanda futura ni aseguran que los bloques disponibles sirvan para la trayectoria de crecimiento de cada intercambio. Y saber que hay prefijos empleados para otra finalidad tampoco aclara si el personal cuenta con datos y herramientas para detectar ese desvío antes de que se convierta en una dependencia operativa.

Johannesburgo muestra la geometría, no la demanda continental

Owens dijo que NAPafrica tenía dos bloques /23 en Johannesburgo, que se acercaba a utilizar por completo un /22 y que, si necesitaba más direcciones, harían falta otros dos /23 para llegar a un /21. También afirmó que la renumeración de esa instalación, iniciada ocho años antes, todavía no había terminado. El acta presenta un caso concreto: no ofrece un denominador, una muestra de otros IXP, una estimación independiente del coste ni una cronología que explique la duración.

Aun así, el ejemplo sirve porque deja ver lo que oculta un total de direcciones. Cuatro bloques /23 solo forman un /21 si son contiguos y están alineados en el límite adecuado. Un IXP que haya crecido con asignaciones separadas puede necesitar más que una cantidad de direcciones: necesita una secuencia viable de bloques adyacentes, un método para mantener el servicio durante el cambio y tiempo suficiente para coordinar a sus participantes. El /24 adyacente del manual está pensado expresamente para un primer salto, hasta /23.

El caso que relata Owens plantea el siguiente: ¿cómo puede avanzar un intercambio que ya completó ese crecimiento inicial? No demuestra que la política haya fallado, pero sí que conviene diseñar el paso posterior.

En la reunión también se mencionó la RFC 8950 como posible pieza de una operación dual stack. El estándar del IETF permite anunciar rutas IPv4 con un next hop IPv6 cuando los pares BGP negocian la capacidad correspondiente. Es una opción técnica, no una prueba de que todos los servidores de rutas y participantes estén preparados para usarla ni de que la LAN IPv4 reservada deje de ser necesaria. RFC 8950

Publicar la evidencia antes de elegir una cifra mayor

El acta establece que la comunidad planteó dos preguntas diferentes: cuánto espacio necesita la reserva regional y cómo puede crecer un intercambio sin renumeraciones repetidas. El personal reconoció la petición de cifras sobre el consumo y los miembros afectados, y se comprometió a compartir datos relevantes en la lista de correo. La documentación pública revisada para este artículo no permite confirmar si el compromiso se cumplió ni cuándo. Es un límite de esta investigación, no prueba de que las cifras nunca circularan.

El siguiente documento útil debería poner las preguntas en una sola página, pero separadas. Para los bloques de peering y de gestión, mostraría el tamaño inicial, las asignaciones, las devoluciones y el espacio restante; el número de solicitudes limitadas; el tamaño de los bloques y si son contiguos. También tendría que distinguir las asignaciones aprobadas de la demanda prevista y explicar si «uso» significa asignado, desplegado, anunciado en el sistema de rutas o simplemente retenido. Una tabla fechada y con metodología aporta más que un porcentaje aislado.

A ese inventario debe añadirse un mapa de transición: qué escalones de crecimiento admite la política, cómo se conservan los bloques adyacentes, qué sucede cuando ya no puede asignarse un bloque contiguo, quién coordina una renumeración y qué salvaguardas o excepciones operativas existen. No se trata de garantizar que siempre habrá un bloque adyacente disponible. Se trata de hacer visible el coste de conservar recursos frente a imponer una migración evitable antes de que cada caso llegue a manos del personal y del operador.

Si los datos muestran que el /16 reservado se acerca al límite para las asignaciones /23, una reserva mayor podría justificarse. Si la demanda se concentra en unos pocos intercambios que requieren incrementos contiguos mayores, la misma evidencia podría apuntar a otra geometría de reserva o a una transición por etapas. Si el problema predominante son los prefijos intercambiados entre categorías, mejorar los registros y la asistencia para cumplir la política podría aportar más que duplicar el inventario. El acta, por sí sola, no permite elegir entre esas respuestas.

El orden responsable es sencillo: publicar cuánto queda en cada pool, decir qué solicitudes no puede atender y mostrar las rutas de crecimiento y migración que permite la política. Con ese registro, la comunidad podrá decidir si necesita más IPv4, otra forma de reserva, mejores datos o una combinación. El caso de NAPafrica permite imaginar el coste de elegir mal el orden. Solo una evidencia pública más amplia puede mostrar a AFRINIC con qué frecuencia podría repetirse.

Fuentes