Resumen

  • El informe de experiencia de AFRINIC de 2018 documentó un caso concreto: un usuario final anónimo no podía recibir un /24 adicional para un segundo centro de datos redundante porque su utilización agregada era inferior al 90 %.
  • AFPUB-2026-IPv4-002-DRAFT02, ahora en Last Call, permitiría omitir el umbral cuando un fin técnico demostrado no pueda atenderse de forma práctica con los recursos existentes. Sin embargo, el estándar común solo exige una justificación debidamente documentada y la reunión descartó una lista única de documentos.
  • La revisión puede conservar flexibilidad sin volverse opaca. Un recibo protegido y versionado puede fijar el cálculo ordinario, la clase de excepción, la custodia de pruebas, las preguntas, los motivos y la apelación, dejando la arquitectura en manos del operador.

AFRINIC ya había visto el conflicto

La evidencia que abre esta historia no es una predicción del autor del borrador. Está en la octava página del Informe de Experiencia de Implementación presentado en AFRINIC-29.

El caso de Hostmaster ocupa pocas líneas. Un miembro End User solicitó un IPv4 /24 adicional para dar redundancia a un centro de datos. La suma de su uso estaba por debajo del 90 %. Según la interpretación de Soft Landing aplicada por AFRINIC, el miembro no era elegible para más recursos y, por tanto, no podría montar el segundo centro.

No conocemos al miembro, el país, la fecha del ticket, el prefijo inicial, la separación eléctrica, los enlaces, las alternativas evaluadas ni el desenlace posterior. Tampoco sabemos si hubo una apelación. Un ejemplo anónimo no prueba que cualquier segundo sitio necesite un bloque nuevo.

Sí prueba una incompatibilidad más estrecha. La utilización mira el estado de direcciones ya entregadas. La redundancia exige que dos funciones estén disponibles a la vez. Si la segunda debe esperar a que la primera esté casi llena, el dominio de fallo alternativo aparece demasiado tarde.

Lo que cambiaría el borrador y lo que conservaría

El rastreador independiente de NOG Alliance indexa AFPUB-2026-IPv4-002-DRAFT02 con la etiqueta más amplia Under discussion. La grabación de AFRINIC-37 conserva la declaración de rough consensus y el paso a Last Call. El borrador 1 se presentó el 6 de mayo de 2026; el segundo está fechado el 16 de junio y fue debatido el 24 de junio. A 23 de agosto sigue siendo una propuesta, no una excepción implementada.

El punto de partida seguiría siendo el 90 %. Durante la Exhaustion Phase, un LIR o End User que pida otra allocation o assignment IPv4 debe demostrar que utiliza al menos el 90 % de todos sus recursos anteriores. La primera solicitud de una entidad nueva sin IPv4 previo continúa exenta.

El texto añadiría una excepción para fines técnicos clave demostrados. El umbral podría no aplicarse cuando esos fines no sean atendibles de forma práctica con el pool actual o cuando creen una restricción técnica sobre él. La redundancia, la alta disponibilidad, los mecanismos de transición a IPv6 y la expansión a nuevos sitios son ejemplos no exhaustivos. A efectos de esta disposición, la petición se trataría como una primera allocation o assignment.

El control cabe en la última frase: la justificación debe estar suficientemente documentada para que AFRINIC verifique su cumplimiento.

La frase obliga a algo más que escribir alta disponibilidad. Hay una carga para el solicitante y una función de comprobación para AFRINIC. Lo que no aporta es la interfaz mínima: qué hecho debe demostrarse, qué relación debe conservarse y qué verá un segundo revisor cuando el ticket ya no esté fresco.

La regla normal tiene porcentaje; la excepción no tiene tipo

El Consolidated Policy Manual vigente se identifica como versión 1.6. Además del umbral, contiene principios generales para la evaluación. Una petición puede apoyarse en planes de ingeniería, subredes, topología y encaminamiento. Las previsiones deben ser realistas y justificables. Las prácticas deben aplicarse de forma justa sin depender del lugar, la nacionalidad o el tamaño. La información comercial que no deba registrarse públicamente tiene que permanecer confidencial.

Ese marco permite una revisión profesional. No define la nueva frontera entre una restricción técnica y una operativa.

Dos organizaciones con la misma utilización pueden usar la palabra redundancia. Una quiere otra ciudad porque un contrato comercial la prefiere. La otra necesita separar alimentación, tránsito y traducción para que una avería no alcance ambas funciones. La etiqueta coincide; el vínculo entre arquitectura, recursos existentes y bloque solicitado no.

Los campos comunes no tienen que decidir el caso mediante una fórmula. Deben conservar la materia del juicio. Así se evita que flexibilidad signifique memoria privada.

No imponer el mismo expediente no equivale a renunciar a un formato común

En la grabación de AFRINIC-37, una participante preguntó qué documentación técnica tendría que compartir un miembro que necesitara varias asignaciones sin llegar al 90 %. El autor respondió que no debía existir una lista única: una transición a IPv6 y un despliegue multisede necesitan pruebas distintas. Describió el proceso como un diálogo de entrada y salida con el personal.

La respuesta evita una falsa uniformidad. Un diagrama de centro de datos no dimensiona necesariamente un pool de traducción. Una orden de compra no demuestra separación de fallos. Una proyección de tráfico no acredita por sí sola independencia de rutas.

Otro participante apoyó el principio, pero advirtió que un texto tan amplio permitiría alegar alta disponibilidad en casi cualquier petición y complicaría una aplicación justa. El autor rechazó enumerar todos los ejemplos, porque excluiría casos legítimos y microgestionaría al personal. El responsable de Member Services señaló entonces la distinción decisiva: las restricciones técnicas pueden activar la excepción; las restricciones operativas no.

La reunión dejó claro lo que no quiere. Un catálogo universal sería rígido. Una palabra sin estructura sería difícil de auditar. Falta la capa intermedia: nombres de campo estables con valores distintos para cada diseño.

Los copresidentes declararon rough consensus en la sesión y enviaron el texto a Last Call. La grabación también señala que el Secretariado compartiría una definición de utilización durante esa fase. El rastreador neutral mantiene su etiqueta más amplia y ninguna fuente pública usada aquí establece ratificación, implementación o un esquema de excepción por campos. Eso no demuestra que nunca se haya distribuido una definición en otro canal; delimita lo que el lector no puede reconstruir del proyecto y de la reunión.

La salvaguarda quedó dentro de la correspondencia

La presentación del proyecto y su debate colocan la salvaguarda en la expresión «debidamente documentada». La necesidad técnica tendría que demostrarse; el espacio existente tendría que resultar impracticable; AFRINIC tendría que poder verificar el nexo.

La relación puede escribirse así:

función técnica → imposibilidad práctica con los recursos actuales → segmento IPv4 adicional

Cada flecha requiere hechos. ¿Qué función se despliega? ¿Qué bloques actuales se examinaron? ¿Por qué no sirven la reutilización, la renumeración, otra agregación o una ubicación distinta? ¿Qué sitio o dominio de fallo recibe el nuevo segmento? ¿Durante cuánto tiempo coexistirán ambos? ¿Qué evidencia invalidaría la explicación?

Si esas respuestas no tienen nombres estables, la salvaguarda existe solamente dentro del ticket. El solicitante del momento puede entender el resultado; el revisor posterior recibe anexos distintos sin una relación preservada.

Discreción no es lo mismo que motivos ni que apelación

La grabación de la reunión describe la revisión como un diálogo, no como un expediente universal. No establece que la decisión sea final ni acredita un derecho jurídico concreto de apelación. El juicio profesional, los motivos registrados y cualquier vía aplicable de corrección o revisión son, por tanto, decisiones de diseño distintas.

La discreción es el margen para valorar hechos que no admiten un test automático. Los motivos son el registro de cómo se usó ese margen. La apelación comprueba si hechos, regla y motivos se enlazaron correctamente.

Conservar la discreción no obliga a eliminar los otros dos elementos. Sin un registro de decisión, una corrección o revisión solo repite la conversación. Hace falta saber si falló la arquitectura, la imposibilidad de reutilizar, el tamaño, la calidad de la evidencia, la clasificación o la versión normativa.

Un ejemplo multi-PoP no crea un derecho automático

La presentación del proyecto usa un despliegue 464XLAT multi-PoP como ejemplo motivador. Es un escenario de diseño, no una auditoría de un miembro, un derecho automático a nuevo espacio ni una topología universal. Su valor es más estrecho: una función técnica puede tener que existir a la vez en varios dominios de fallo antes de que la utilización agregada alcance un umbral secuencial.

La arquitectura 464XLAT del RFC 6877 combina traducción con estado en el núcleo y traducción sin estado en el borde para ofrecer conectividad IPv4 limitada a través de una red IPv6-only. Es un RFC Informational. No prescribe cuatro PoP, dos dispositivos por sitio ni un tamaño determinado de prefijo público.

La política no necesita elegir equipo ni topología. La interfaz común puede preguntar qué función y qué dominio de fallo atiende el recurso, por qué el pool actual no puede hacerlo y cómo se calculó la demanda. El operador conserva la implementación.

Una especificación mínima es estricta en lo poco que comparte

La Minimum Initial Specification de Lu Heng propone que la capa común contenga solo reglas deterministas necesarias para coordinar, y que las decisiones posteriores permanezcan con quienes operan la red cuando no alteran un invariante compartido.

AFRINIC administra un pool IPv4 finito. Verificar necesidad, conservar unicidad, mantener el registro y aplicar una regla equitativa son funciones legítimas. El proveedor del centro de datos, la plataforma NAT64, el encaminamiento interno y el orden de construcción no se convierten por ello en invariantes del registro.

La salida no es una política de topología ni una palabra abierta. Se fijan los campos mínimos comunes; cada operador aporta pruebas adecuadas a su diseño; los anexos sensibles permanecen protegidos; solo se publican la versión del esquema y estadísticas que no identifiquen la red.

Una capa común vaga no es ligera. Obliga a cada solicitante y a cada Hostmaster a inventar en privado la especificación. La interfaz mínima hace explícita la parte compartida y mantiene local el resto.

Dieciocho campos para el recibo de excepción

La siguiente propuesta pertenece a este artículo. No describe un formulario vigente de AFRINIC.

  1. ID de solicitud o ticket. Vincula una petición con sus pruebas, su diálogo y su resultado.
  2. Identidad de la regla. Conserva política, borrador o versión implementada y el párrafo aplicado.
  3. Solicitante y tipo de petición. Distingue LIR o End User, allocation o assignment, inicial o adicional.
  4. Base ordinaria. Congela el portfolio y el cálculo exacto del 90 % que se aplicaría sin excepción.
  5. Clase de excepción. Nombra redundancia, alta disponibilidad, transición IPv6, nuevo sitio u otro fin técnico.
  6. Unidades funcionales. Identifica sitios, PoP o funciones en el expediente protegido, usando seudónimos en cualquier salida pública.
  7. Segmentos solicitados. Asocia cada prefijo o cantidad con un sitio o una función.
  8. Ventana de concurrencia. Explica por qué las funciones deben desplegarse juntas y cuánto coexistirán los recursos.
  9. Relación de impracticabilidad. Registra el motivo topológico, de ruta, traducción o dominio de fallo por el cual el espacio actual no sirve.
  10. Plan de direcciones. Guarda uso actual y previsto, unidad y horizonte de cada segmento pertinente.
  11. Análisis del espacio sin usar. Inventaría los recursos libres y justifica descartar reutilización, renumeración u otra ubicación.
  12. Custodia de evidencia. Lista archivos, hashes, responsable, acceso y retención sin publicar topología confidencial.
  13. Historial del diálogo. Añade preguntas, respuestas y marcas temporales sin sobrescribir el razonamiento anterior.
  14. Clasificación y motivos. Registra tratamiento técnico, operativo o mixto mediante códigos estables y explicación natural.
  15. Decisión y condiciones. Conserva aprobación o rechazo, tamaño concedido, condiciones, vencimiento y revisión posterior.
  16. Corrección y apelación. Identifica aviso, canal para corregir hechos, plazo y vía aplicable.
  17. Sustitución de versión. Enlaza la norma posterior que modifica el test y mantiene la aplicada al decidir.
  18. Agregados públicos. Publica cantidades, clases, intervalos de proceso, resultados y correcciones sin exponer miembro ni topología.

El recibo no decide si el diseño de cuatro PoP es auténtico. Hace repetible la valoración. Otro examinador verá el mismo portfolio, la misma restricción y la misma pregunta pendiente. El solicitante corregirá un hecho sin borrar la historia. AFRINIC podrá observar diferencias no explicadas entre clases, tamaños o etapas.

La excepción necesita una interfaz antes de convertirse en puerta

La dirección del borrador es defendible. Esperar a que el primer dominio de fallo esté casi lleno antes de crear el segundo convierte la redundancia en una tarea posterior a la avería. El informe de 2018 demuestra que el problema llegó a la evaluación real de AFRINIC.

El borrador también conserva una disciplina útil: el fin técnico debe demostrarse, no anunciarse. La debilidad no es que exista juicio profesional. Es que la regla común no define qué sobrevive después de ese juicio.

«Debidamente documentado» puede iniciar el diálogo, pero no es el archivo duradero de una excepción sobre un recurso escaso. Antes de implementar la exención, AFRINIC debería publicar los campos mínimos, la protección de pruebas y los códigos de motivo. El registro podría conservar el pool sin diseñar la red; el operador podría diseñar la red sin inventar su propia norma de prueba.

Fuentes