Resumen

  • El borrador individual fechado el 2 de septiembre aplica 100 % y 50 % a dos magnitudes acotadas; no demuestra que el riesgo empresarial se reduzca a la mitad.
  • Un transporte exclusivamente IPv6 puede conectar equipos que siguen procesando IPv4. La afirmación de retirada necesita un alcance verificable.

La frase «hemos retirado IPv4» puede describir correctamente una red y no describir las aplicaciones que la utilizan. Esa diferencia adquiere precisión en el Internet-Draft individual de Charles C. Sun. La revisión vigente -01, fechada el 2 de septiembre, identifica Alliance for Universal Computing como afiliación del autor. No es una norma respaldada por IETF ni una medición de resultados de una migración.

Los porcentajes exigen conservar sus respectivos denominadores. El 100 % se refiere a la clase definida de ataques que necesitan la ruta de procesamiento IPv4 de capa 3 eliminada para ejecutarse. El 50 % cuenta el paso de dos pilas de protocolo expuestas simultáneamente a una. El texto excluye explícitamente la lectura como reducción del tráfico de ataque, los incidentes, las pérdidas financieras o el riesgo total de una organización.

Una frontera técnica con consecuencias de gestión

Según el borrador, IPv4 solo está retirado dentro del ámbito elegido si allí no queda ninguna ruta activa de procesamiento de ese protocolo. Un traductor, extremo de túnel o componente de compatibilidad que conserve o reintroduzca ese procesamiento invalida la premisa para ese ámbito.

El RFC 9099 de 2021 permite entender por qué importa. Su descripción de 464XLAT combina traducción de IPv4 a IPv6 en el equipo con traducción inversa en el proveedor. Así, una aplicación que solo utiliza IPv4 puede alcanzar un servidor IPv4 atravesando una red exclusivamente IPv6. La red intermedia y el sistema que incluye sus extremos no tienen el mismo inventario de procesamiento.

De ello no se deduce que un operador concreto haya certificado mal su migración. Sí se deduce una diferencia entre pruebas: aceptar el transporte dentro de su contrato no certifica también los terminales ni los servicios de compatibilidad. Ampliar el alcance cambia lo que debe probarse.

La cuenta no valora el daño

Cada pila pesa una unidad en el cálculo, pero las consecuencias de los fallos restantes no tienen por qué pesar lo mismo. El autor tampoco niega el código y los recursos compartidos. Preservar los mecanismos propios de IPv6 no garantiza llegar a destinos que necesiten IPv4. Son límites reconocidos en el borrador, no promesas incumplidas descubiertas aquí.

Mantener menos rutas de procesamiento puede aportar una mejora operativa. Cuánto vale frente al coste de migrar y conservar compatibilidad depende de pruebas del sistema afectado. La formalización no sustituye ese análisis económico ni demuestra superioridad intrínseca de seguridad de IPv6.

La lectura sigue la explicación de Lu Heng sobre describir la realidad sin hacer campaña. Es un criterio editorial, no una fuente de validación técnica.