Resumen

  • ARIN-2026-2 es un Draft Policy en discusión, no una norma adoptada ni implementada.
  • La propuesta reemplazaría fórmulas y umbrales públicos de utilización por planes documentados con unidades de asignación, jerarquía, agregación y crecimiento.
  • BTW recomienda un registro comparable entre plan y decisión; siguen sin conocerse la operación por parte del personal y la carga probatoria para los solicitantes.

El texto de la propuesta tiene fecha del 4 de mayo de 2026 y pasó a ser Draft Policy el 24 de junio de 2026. En el cierre informativo del 5 de septiembre de 2026 seguía en discusión. El índice citado no mostraba revisión del personal o jurídica ni una entrada de presentación comunitaria. Las fuentes no muestran recomendación, consenso, last call, adopción por el Board ni implementación; el texto no está incorporado al NRPM vigente.

El borrador trasladaría las decisiones sobre asignaciones iniciales de LIR fuera de los mecanismos actuales basados en fórmulas y utilización. Cada solicitud describiría los tamaños habituales de asignación para sitios remotos o clientes, la jerarquía y estructura lógica del direccionamiento, y la utilización proyectada de las unidades de direccionamiento aproximadamente a uno, dos y cinco años. ARIN consideraría el número y tipo previstos de asignaciones descendentes, las necesidades de agregación y la capacidad de mantener crecimiento contiguo.

El espacio inicial se dimensionaría para el plan documentado y una expansión eficiente, pero el borrador no publica una nueva fórmula determinista.

Para solicitudes LIR posteriores, el texto propuesto consideraría una implementación coherente con el plan anterior, proyecciones actualizadas y si resulta viable ampliar el bloque existente. Las solicitudes PI también se evaluarían mediante requisitos de sitios, jerarquía y segmentación internas, agregación, crecimiento y evitación de renumeración. Las reasignaciones o redistribuciones a entidades externas de /64 o mayores se registrarían en los servicios de directorio de ARIN conforme al texto propuesto.

El marco implementado actualmente es distinto. El NRPM 6.5.2.1 usa límites de nibble, un suelo predeterminado de /32 con opciones /36 o /40, condiciones de tenencia de IPv4 para /40, un techo de /16 y una fórmula vinculada a los sitios atendidos, el sitio atendido más grande y un estándar del 75 %. El NRPM 6.5.2.2 incluye cualificación IPv4 previa, multihoming IPv6 o justificación técnica, asignaciones proyectadas a uno, dos y cinco años y al menos 50 asignaciones en cinco años. El NRPM 6.5.3 usa, para asignaciones LIR posteriores, un 75 % de utilización total, más del 90 % en un sitio atendido o más del 90 % asignado a sitios atendidos.

El NRPM 6.5.8 establece para usuarios finales /48 para un sitio, /44 para 2–12, /40 para 13–192, /36 para 193–3.072 y /32 por encima de 3.072 sitios.

El problema de gobernanza no es el agotamiento ni la escasez económica de IPv6. Se trata de asignación proporcional, agregación, fragmentación de la tabla de enrutamiento, continuidad y administración repetible. Un plan puede reflejar mejor la arquitectura real de un operador que una ecuación rígida. Sin embargo, al desaparecer varios umbrales públicos, la calidad de las decisiones dependería más de interpretar los planes de forma consistente y comparar la implementación con las proyecciones previas.

Es una inferencia sobre el diseño de la propuesta, no una acusación de conducta arbitraria del personal ni una afirmación de que la discreción sea necesariamente abusiva.

BTW recomienda un registro compacto de decisiones para cada clase de evaluación. Debería contener los supuestos sobre unidades de asignación, la jerarquía, las proyecciones a uno, dos y cinco años, la variación frente al plan anterior, la justificación del crecimiento contiguo y la razón por la que el prefijo emitido es proporcional. Ese registro es una recomendación de este análisis, no un sistema existente o prometido por ARIN.

Nota de publicación: «Publicado» es la fecha editorial programada, el 6 de septiembre de 2026, en Asia/Shanghai. La hora efectiva de publicación en el servidor sigue sin establecerse hasta publish-now.