Resumen

  • La propuesta IPv6 PI Update publicada el 28 de marzo de 2018 fue AFPUB-2018-V6-004-DRAFT01. AFPUB-2018-V6-003 correspondía a otra iniciativa, IPv6 Initial Allocation Update, dirigida a la lógica de asignaciones de los LIR. Confundir los identificadores borra precisamente la diferencia entre una puerta para usuarios finales y una regla para intermediarios de registro.
  • Draft 1 eliminó la dependencia que obligaba a mirar el pasado IPv4 PI de una organización antes de considerar su necesidad actual de direccionamiento IPv6 independiente. Conservó, sin embargo, pruebas sobre identidad, membresía, sitios, necesidad, tamaño, despliegue y agregación que deben juzgarse una por una según el interés técnico que protegen.
  • La portabilidad reduce la dependencia del proveedor y el coste de renumerar, pero no garantiza que todos los operadores de Internet acepten o anuncien un prefijo. Ese límite técnico justifica información clara y dimensionamiento coherente; no convierte a AFRINIC en regulador del diseño de red.
  • AFRINIC es un registrador y coordinador técnico privado. Puede mantener direcciones únicas, registros exactos y evidencia interoperable; no puede fabricar soberanía, castigar modelos comerciales, confiscar recursos ni resolver controversias como si fuera un tribunal. La solución durable es una regla fina, objetiva, motivada y corregible que preserve la continuidad del operador.

L3 — La puerta IPv6 que dejó de exigir un pasado IPv4

Pensemos en el responsable de red de una universidad, un hospital o una empresa regional que ya publica servicios sobre IPv6. Hoy recibe direcciones agregables de su proveedor. Mañana quiere añadir una segunda conexión para resistir una avería, negociar mejor el tránsito o cambiar de operador. La dificultad no consiste solo en introducir una ruta nueva. Si la identidad pública de sus sistemas está incrustada en el bloque del proveedor, la salida exige modificar direcciones en servidores, DNS, listas de acceso, filtros de socios, herramientas de vigilancia, registros de incidentes, certificados y configuraciones de clientes.

Cada dependencia convierte una decisión de compra en un proyecto de continuidad.

Un prefijo independiente del proveedor cambia la naturaleza de esa decisión. La organización conserva una identidad de red reconocible aunque sustituya un enlace o combine varios. No obtiene por ello una promesa universal de encaminamiento, ni un título soberano sobre una parcela de Internet. Obtiene una asignación registrada que puede reducir la necesidad de renumerar y, con ella, el poder de retención del proveedor. La diferencia importa porque en 2018 la puerta de entrada a esa independencia todavía arrastraba una condición histórica: el solicitante de IPv6 PI debía venir acompañado por una situación previa en IPv4 PI.

Tras el agotamiento de IPv4, hacer depender una arquitectura nueva de esa genealogía antigua era confundir evidencia con herencia.

El acto exacto que debe reconstruirse es la publicación, el 28 de marzo de 2018, de IPv6 PI Update, versión 1, con el identificador AFPUB-2018-V6-004-DRAFT01. La precisión no es decorativa. AFPUB-2018-V6-003 identificaba otra propuesta publicada en la misma jornada, IPv6 Initial Allocation Update. Aquella se ocupaba de criterios de asignación inicial y posterior para registros locales de Internet, los LIR. V6-004, en cambio, abordaba la vía de las organizaciones usuarias finales que buscaban espacio IPv6 independiente. Llamar V6-003 al borrador PI desplaza el sujeto, mezcla dos poblaciones solicitantes y atribuye a un instrumento el problema del otro.

Los archivos históricos de AFRINIC y su lista de políticas permiten fijar esa identidad; las actas y el informe anual la corroboran desde momentos posteriores. Tales documentos prueban que la organización publicó, discutió, ratificó o describió esos textos. No prueban que el registro adquiriera potestad pública por haberlos inscrito en su propio proceso. Tampoco convierten la publicación de marzo en una norma ya operativa. Conviene mantener el calendario separado porque cada fecha responde a una pregunta institucional distinta.

El 28 de marzo hubo publicación de Draft 1. El 6 de junio, durante AFRINIC-28, el autor explicó el problema que pretendía resolver: el agotamiento de IPv4 hacía ilógico que el acceso a IPv6 PI dependiera de disponer de IPv4 PI. Las actas recogen preguntas sobre el plazo de doce meses, el principio de ratio de densidad y la posibilidad de vigilar anuncios. También registran una objeción favorable a conservar la cualificación IPv4 hasta definir mejor la cualificación IPv6. Los copresidentes decidieron llevar V6-004 a última llamada al no observar movimiento hacia cambios de texto.

Esa decisión fue un paso del procedimiento; no fue la publicación inicial, no fue ratificación y no fue implementación.

El 7 y 8 de agosto, la Resolución 201808.449 dejó constancia de la ratificación del borrador por el Consejo y encargó al personal implementarlo. Solo en noviembre aparece el siguiente tramo: el historial de revisión del manual consolidado situó los cambios en las secciones 6.8 a 6.8.4, y el aviso de 29 de noviembre comunicó una implementación parcial, con determinadas automatizaciones todavía pendientes. La secuencia, por tanto, no admite atajos: propuesta publicada en marzo, discusión y última llamada en junio, ratificación en agosto, incorporación e implementación parcial comunicada en noviembre.

Decir que el texto ya regía plenamente al publicarse borraría tanto el proceso como las limitaciones de la prueba.

¿Qué puerta intentó abrir V6-004? La pieza central fue reconocer que una organización usuaria final podía acreditar una necesidad IPv6 propia sin exhibir primero un pasado IPv4 PI. No se trataba de transformar al usuario final en LIR ni de trasladar a este artículo la discusión sobre asignaciones iniciales a intermediarios. Se trataba de evaluar la red que existía o se proyectaba en IPv6. El solicitante debía ser una organización de usuario final, no un LIR, y entrar o permanecer en la relación de membresía de usuario final con AFRINIC.

Debía justificar sus sitios y la necesidad de direccionamiento, aportar un plan y prever el despliegue dentro de doce meses.

Esa arquitectura contenía varias capas que no deben tratarse como un bloque indivisible. Identificar a la organización ayuda a saber quién controla la solicitud y quién responderá por la exactitud de los datos. Distinguir al usuario final del LIR evita aplicar una categoría de asignación a otra. Contar sitios y describir necesidad permite calcular un tamaño sin entregar rangos duplicados o incoherentes. Establecer un horizonte de despliegue puede servir para separar un proyecto real de la acumulación puramente especulativa.

Ninguna de esas funciones, por sí sola, autoriza a evaluar si el negocio del solicitante es digno, si su topología agrada al registrador o si su elección de proveedor merece aprobación.

La lógica de tamaño merece especial atención porque muestra cómo puede operar una coordinación fina. La arquitectura posteriormente consolidada empleó al menos un /48 por sitio final. Para una organización con varios sitios conectados, contempló un prefijo alineado en límites de nibble; una solicitud de un prefijo más corto debía justificarse. El cálculo atendía al número de sitios, procuraba crecimiento contiguo cuando fuera posible y dejaba al registro usar asignación dispersa para conservar espacio de expansión.

No conviene afirmar que cada palabra del manual posterior aparecía de manera idéntica en Draft 1: el texto consolidado incorpora evolución posterior. Sí puede afirmarse que los documentos sellados trazan esos elementos como la arquitectura derivada del cambio y que las actas contemporáneas discutieron su dimensionamiento.

Un criterio de tamaño no es necesariamente una forma de dominación. La longitud del prefijo tiene efectos en las reservas, en la agregación y en las expectativas operativas. Un /48 por sitio ofrece una base inteligible; la alineación facilita planificación; la justificación de una petición mayor permite conservar un registro explicable. El problema aparece cuando una regla calculable se convierte en discreción no acotada.

Si dos organizaciones con la misma topología reciben respuestas distintas porque el personal prefiere un modelo empresarial, una forma de interconexión o una narrativa de crecimiento, el registrador ya no está resolviendo unicidad y tamaño: está otorgándose una licencia sobre el diseño.

Draft 1 también atendió el error inicial de cálculo. Las actas de AFRINIC-28 dicen que añadió una vía para rectificar una asignación IPv6 PI cuando el tamaño original dejara de encajar con el plan posterior de la red. La posibilidad es importante porque los sistemas vivos cambian. Una empresa abre sedes, separa dominios de seguridad, adquiere otra operación o descubre que su modelo de subredes era demasiado estrecho. Sin rectificación, la equivocación del primer día puede convertir la independencia en otra obligación de renumerar.

Con rectificación, el registro puede corregir su asiento y, cuando sea técnicamente viable, sostener crecimiento contiguo.

Pero tampoco la rectificación equivale a un derecho ilimitado del registrador a imponer renumeración. Su fin razonable es adaptar un registro que ya no refleja una necesidad objetivamente demostrada, procurando continuidad. Si el remedio habitual destruye configuraciones, contratos y controles sin demostrar una exigencia de unicidad o una imposibilidad técnica, el supuesto arreglo reproduce el daño que justificaba la portabilidad. El diseño correcto compara el coste de continuidad con la precisión que se busca, ofrece alternativas y explica por qué una modificación es imprescindible.

La reconstrucción deja ver la virtud y la tensión de V6-004. La virtud fue dejar de usar la posesión previa de IPv4 PI como sustituto de una evaluación actual. Una organización nueva, una institución que había dependido siempre de un proveedor o un operador nacido directamente en IPv6 ya no quedaba excluido por falta de historia. La tensión fue conservar una colección de condiciones —necesidad, despliegue, anuncio, agregación, tamaño— capaces de servir a la coordinación o de convertirse en filtros de mérito según cómo se redactaran y aplicaran.

La respuesta a esa tensión no está en negar toda comprobación. Un registro sin identidad verificable ni control documentado permitiría duplicidades, solicitudes fraudulentas y asientos inútiles. Tampoco está en fingir que cualquier longitud de prefijo produce el mismo efecto sobre el sistema de rutas. Está en asignar a cada pregunta un objeto limitado. ¿Quién es la organización? ¿Controla la red y los datos que declara? ¿Existe ya una asignación incompatible? ¿Qué número de sitios sostiene el tamaño? ¿Qué consecuencia de agregación debe conocer? Son preguntas técnicas.

¿Nos gusta su modelo, debería anunciar globalmente, merece operar así, conviene disciplinarla? Son preguntas que un registrador privado no tiene mandato para convertir en condiciones punitivas.

La evidencia disponible termina antes de algunas respuestas tentadoras. No ofrece un recuento empírico de nuevas rutas globales causadas por V6-004. No identifica una empresa a la que se negara o retirara espacio bajo el borrador. No demuestra que cada prefijo PI asignado fuera aceptado por todas las redes del mundo. Por eso la importancia del acto no puede venderse como un resultado cuantificado ni como una historia de víctima concreta. Radica en el cambio de la puerta institucional: dejar de mirar un activo IPv4 heredado, mirar una necesidad IPv6 actual y decidir si las pruebas exigidas protegían el registro o invadían la autonomía.

El contrafactual aclara lo que estaba en juego. Sin la reforma, un usuario final sin IPv4 PI debía seguir con direcciones del proveedor o satisfacer una cualificación heredada que nada decía sobre su red IPv6. La primera opción preservaba el riesgo de renumeración y la ventaja negociadora del proveedor; la segunda premiaba la antigüedad. Con una vía fina, la organización demuestra identidad, control, no duplicidad y tamaño, conoce las implicaciones de encaminamiento y conserva para sí la elección posterior de tránsito, multihoming o uso privado. Esa es la promesa que debe medirse en las capas siguientes.