Resumen

  • La versión 2 eliminó de forma consciente la reevaluación amplia, y el proponente aclaró que los titulares existentes no sufren consecuencias mientras sus necesidades no cambien.
  • Si aparece una necesidad mayor, la sección 7.1.2 lleva al siguiente límite nibble o, sin espacio contiguo, a una nueva asignación y la devolución de las anteriores en seis meses.
  • Un comprobante de catorce campos puede unir ese antes y después sin convertir la topología, los clientes o la agenda técnica del titular en información pública.

El reloj que no cabe en una fecha

Una renumeración no se vuelve comprensible por escribir «seis meses» junto a ella. Primero debe saberse qué hecho abrió el plazo. Después hay que identificar qué prefijos entraron en el conjunto antiguo, qué espacio contiguo se examinó, cuál fue la nueva asignación y qué evidencia cerró cada devolución.

La discusión ofrece una escena concreta. Un participante contó en marzo de 2025 que tenía nueve asignaciones PI /48 y quería consolidarlas, si era posible sin renumerar. También aludió a objetos y DNS. Es una declaración atribuida, no un inventario verificado ni una muestra representativa. No autoriza a calificar esos nueve prefijos de abuso, desperdicio o incumplimiento.

Sí muestra por qué el estado anterior importa. Nueve objetos pueden corresponder a años de rutas, zonas inversas, filtros y dependencias locales. Un agregado futuro no contiene por sí solo esa genealogía.

No crecer debe seguir significando no intervenir

En octubre de 2025, el anuncio de la versión 2 explicó dos cambios deliberados: se retiró la definición propuesta de End Site y también la reevaluación de necesidades al pedir una asignación adicional o mayor. El objetivo era reducir y aclarar el texto.

Cuando otro participante planteó el caso exacto de titulares con varias PI pero sin necesidad creciente, el proponente respondió que no habría consecuencias mientras no cambiaran sus necesidades.

Esa respuesta contiene una garantía útil. Una política nueva no debe convertir automáticamente un despliegue antiguo y válido en una tarea de migración. El registro coordina recursos; no administra cada cambio de DNS, cada ACL ni el calendario de mantenimiento de la red.

Por eso el artículo no reclama una campaña de consolidación retrospectiva. Reclama que el evento que pone fin a la quietud quede identificado.

Una petición de crecimiento cambia la pregunta

La sección 7.1.2, tal como se reproduce en la discusión, obliga a mirar el siguiente límite nibble cuando un titular de una o varias PI necesita más espacio. Si la extensión no puede hacerse de forma contigua, se abre la vía de una nueva asignación y de la devolución de las anteriores tras un período de renumeración de seis meses. Un mensaje reprodujo esa cláusula y discutió el plazo, proponiendo doce o 24 meses o una extensión justificada.

El desacuerdo sobre la duración es real; el presente texto no lo resuelve. No hay aquí un caso observado, un plazo incumplido ni una prueba de que seis meses sean inviables. Hay una estructura verificable:

conjunto previo → nueva necesidad → prueba de contigüidad → extensión o sustitución → coexistencia → devolución.

La política puede escoger cualquiera de las ramas. Lo que no debería ocurrir es que la rama solo pueda reconstruirse a partir de correos privados o de la memoria del gestor del caso.

La propuesta todavía no es política aplicada

El 15 de junio de 2026, los copresidentes informaron de ocho apoyos y del acuerdo de avanzar a la fase de revisión. Anunciaron cambios editoriales menores y la futura publicación del borrador y del análisis de impacto.

Eso fija el estado del expediente en la evidencia disponible: intención de avanzar. No prueba que la fase se abriera después, que hubiera consenso, que la propuesta se aceptara o que RIPE NCC la implementara. Cualquier manuscrito que hable ya de «la política» como mandato vigente borraría la incertidumbre central.

La ausencia de un hecho consumado es una ventaja editorial. El análisis de impacto aún puede especificar qué datos, relojes y correcciones acompañarían el paso.

Dos prefijos vivos son una fase, no una anomalía

El RFC 4192 organiza la renumeración IPv6 como una transición sin día de corte: preparar el nuevo espacio, añadirlo, actualizar en varias fases enrutamiento, DNS, DHCP y configuraciones, operar ambos prefijos, probar y retirar el anterior al final.

El RFC 5887 enumera la fricción que persiste. Hay direcciones incrustadas en lugares difíciles de localizar. Las reglas y la monitorización deben funcionar durante el solapamiento. Algunas herramientas no manejan bien la multiplicidad de prefijos, y ciertos problemas solo aparecen cuando un usuario tropieza con ellos.

Ninguno de los dos RFC gobierna la propuesta de RIPE ni fija su plazo. Ambos demuestran que el acto registral y la ejecución en la red son capas distintas. Un comprobante debe enlazarlas sin fingir que el registro controla la segunda.

Un modelo para el punto de cruce

Sea P0 el conjunto ordenado de PI anteriores en un instante concreto; N0, la necesidad documentada hasta entonces; y q, la solicitud posterior. H identifica el texto aplicable. C(q, P0) es el resultado de reserva y contigüidad; T, la rama elegida; P1, el nuevo estado de recursos; D, el solapamiento, el vencimiento y el cierre.

Entonces:

E = G(P0, N0, q, H, C, T, P1, D).

Es un modelo de auditoría de Theo March, no el esquema de RIPE NCC. Antes de q, P0 puede seguir intacto. Después, el resultado solo es explicable si la solicitud y las pruebas permanecen unidas a ambos conjuntos.

El comprobante de catorce campos

  1. Identidad. ID estable y versión del esquema del comprobante.
  2. Regla. Propuesta o política, versión, huella del texto, estado y fecha efectiva.
  3. Corte previo. Momento exacto y zona horaria del inventario anterior.
  4. Titular y solicitud. Referencia pública mínima, ID de caso y hora autenticada, sin datos privados de contacto.
  5. Clase de disparador. Consulta sin cambios, petición adicional, petición mayor o corrección, con la razón para activar o no la sección 7.1.2.
  6. Conjunto PI anterior. Identidades ordenadas, longitudes, estados y huellas de los objetos.
  7. Necesidad evaluada. Aprobada, denegada o indeterminada, unidad objetivo y código público acotado; la topología detallada puede quedar protegida.
  8. Objetivo nibble. Límite pedido, límite evaluado y motivo de la diferencia.
  9. Contigüidad. Instantánea de reservas, rango adyacente probado, hora y resultado determinista sin revelar recursos ajenos.
  10. Rama seleccionada. Extender, sustituir, mantener, denegar o pedir más pruebas.
  11. Recurso resultante. Identidad, prefijo, versión del objeto y momento de activación.
  12. Reloj de coexistencia. Inicio del solapamiento, fecha límite, zona horaria e identidad de una pausa o ampliación autorizada.
  13. Devolución y cierre. Lista de asignaciones anteriores, estado individual, prueba de cierre y excepción pendiente.
  14. Corrección. Autoridad decisora, vía de revisión, comprobante sustituido y estado final.

La forma pública puede usar identificadores y códigos limitados. Los documentos de utilización, diagramas, clientes y contactos permanecen dentro del expediente autorizado.

Cinco vectores, antes del primer caso vivo

  1. Varias PI sin crecimiento. Resultado: no hay disparador ni fecha de devolución.
  2. Crecimiento contiguo. Resultado: extensión y enlace verificable con la reserva utilizada.
  3. Crecimiento no contiguo. Resultado: nueva asignación, conjunto explícito de devolución y reloj de solapamiento.
  4. Solicitud retirada. Si se retira antes de activar el nuevo recurso, el caso termina sin iniciar el plazo.
  5. Dato corregido. Un prefijo anterior o una fecha incorrectos producen una sustitución anexada, no una reescritura silenciosa.

Los vectores permiten implementaciones distintas. Lo común es la semántica de la salida, no el software del registro ni el del titular.

Compartir el mínimo y devolver el control

La Nota 64 de HENG.LU pide especificar únicamente lo necesario para identidad, interoperabilidad y seguridad compartida. Aquí son comunes las identidades antigua y nueva, la versión de regla, el disparador, la prueba de contigüidad, la decisión, el reloj, el cierre y la corrección.

Permanecen locales o protegidos la topología, el tráfico, los clientes, las pruebas de utilización, el inventario y el orden de la migración. La comunidad decide la regla; RIPE NCC aplica y registra; el titular dice la verdad y opera; un tercero verifica, pero no asigna ni invalida.

La misma división impide convertir el comprobante en una obligación de moverse. Sin necesidad nueva, no hay transición que documentar. Con una transición, la prueba común viaja y el diseño de red queda en casa.

Fuentes

Límites de la evidencia

Verificado: la versión 2 retiró la reevaluación amplia; el proponente excluyó los casos sin crecimiento; el texto discutido contiene la rama de extensión o sustitución y seis meses; los copresidentes pretendían avanzar; renumerar exige estados operativos superpuestos.

Inferencia: el estado final no basta para reconstruir el disparador, la contigüidad, el conjunto de devolución y el reloj.

Recomendación: comprobante de catorce campos y cinco vectores antes de implementar.

Desconocido: texto de revisión, análisis de impacto, plazo definitivo, comienzo del reloj, excepciones, esquema interno, número de titulares y cualquier despliegue en producción.