Resumen

  • draft-ietf-v6ops-ipv6-app-testing-03 separa IPv4 exclusivo, doble pila, IPv6 con NAT64 e IPv6 estricto sin un camino IPv4 relevante. Un éxito en doble pila puede ser solo un repliegue exitoso y no demuestra el caso estricto.
  • Instalación, interfaz, gestión y actualización son superficies independientes. Una declaración útil debe identificar los flujos importantes, el escenario aplicable, la prueba de que el banco creó esa condición y los resultados de transporte y aplicación.

Un indicador resumió rutas que nunca se ejecutaron

Un recorrido de usuario suele tocar una parte del sistema. Puede atravesar frontal, identidad y API sin invocar activación, repositorios, telemetría, soporte remoto, copia de seguridad o recuperación. Convertir ese recorrido en un sello de producto permite que la evidencia de una ruta responda por las rutas ausentes.

Las cuatro condiciones del borrador se aplican a flujos dirigidos, no al producto como bloque. La unidad defendible combina versión, emisor, receptor, función del ciclo de vida, intermediario, condición de red, resultado esperado y resultado observado. Una fila que no existe es desconocida, no aprobada.

Una aplicación de nube transforma una prueba extremo a extremo en un grafo. Balanceadores, pasarelas, autenticación, autorización, bases de datos y registros crean enlaces distintos. El mismo componente actúa como cliente en un enlace y servidor en otro. El éxito final no demuestra que todos usaron IPv6 ni que los enlaces no activados funcionen.

No hace falta ejecutar un producto cartesiano ciego. Una arquitectura controlada permite excluir combinaciones, pero la exclusión requiere versión, responsable y razón verificable. Ese límite mantiene la especificación del ensayo delgada sin borrar el riesgo local.

La doble pila puede ocultar el fallo que resolvió

Happy Eyeballs protege al usuario, pero cambia el significado de la prueba. IPv6 puede fallar después de TCP y antes de TLS; IPv4 completa después la operación. RFC 8305 reduce la demora entre candidatos, no certifica el candidato perdedor.

DNS64 de RFC 6147, el formato de RFC 6052 y 464XLAT de RFC 6877 pueden hacer alcanzable una dependencia IPv4. Eso es válido en una prueba de transición; contamina una prueba que se llama IPv6-only-strict. CLAT, DNS64, prefijo NAT64, VPN, túnel y relevo necesitan comprobación explícita.

El recibo debe conservar respuestas DNS, candidatos, familia elegida, intentos fallidos, tiempos de repliegue, proxy o traductor, resultado de transporte y resultado funcional. Guardar solo el éxito final destruye el hallazgo.

También puede fallar el banco. Desactivar IPv4 puede cortar la administración de una máquina virtual o el inicio de sesión corporativo. La salud del entorno y la del producto son evidencias distintas.

El ciclo de vida tiene más de una puerta

El documento distingue instalación, interfaz, gestión y actualización. El instalador puede depender de licencias o paquetes; la gestión de API, SNMP, syslog y monitoreo; el actualizador de procesos, certificados, espejos y rollback diferentes.

Una UI correcta no prueba la instalación. Un API correcto no demuestra que los registros preserven una fuente IPv6. Una actualización manual no cubre necesariamente la automática. La cobertura debe organizarse por flujo y dueño, no por pantalla.

Un proxy añade otra pierna: IPv6 hasta el proxy no prueba IPv6 desde el proxy al origen. TURN añade candidatos; RFC 8656 define el relevo, no la exhaustividad de una campaña concreta. Los servicios compartidos hacen recursiva la revisión: publicar AAAA puede enviar tráfico IPv6 a consumidores cuyas listas y registros aún no están listos.

Una dirección también es dato y política

RFC 4291 define direcciones y RFC 5952 su representación recomendada, pero una aplicación puede aceptar solo decimal con puntos, truncar texto o separar formas equivalentes.

Las listas de acceso exponen la diferencia. Tras publicar AAAA, un cliente puede llegar por IPv6 y ser rechazado porque la regla solo conoce IPv4. Happy Eyeballs no repara una autorización evaluada después del transporte. Recibir IPv6 sin poder buscar su origen en auditoría o respuesta a abuso tampoco completa el soporte operativo.

Una traza solo demuestra lo observado

Cuando el aislamiento estricto no es viable, registros y capturas sostienen una conclusión más estrecha. La ausencia de IPv4 vale para la interfaz, filtros, ventana e inventario conocidos. No excluye trabajos tardíos, ramas condicionales o dependencias futuras. Por eso el borrador llama al trazado de red la alternativa más propensa a errores.

La frase correcta es: «todos los flujos del manifiesto X fueron observados sobre IPv6 en la ejecución Y». No: «no existe ninguna dependencia IPv4 oculta».

Last Call no es producción

La fuente es la revisión 03 del 29 de septiembre de 2026, con vencimiento el 2 de abril de 2027. Datatracker la muestra activa, I-D Exists, en Last Call del grupo V6OPS. La portada propone Best Current Practice; el campo intended-status está vacío. No es todavía RFC ni BCP.

El texto normaliza preguntas, no ejecuta pruebas. RFC 8504 fija requisitos de nodos, no cobertura funcional de una aplicación. RFC 8585 describe despliegues empresariales, no certifica dependencias.

La primacía del código en ejecución conserva el orden: guía, manifiesto, banco, observación, resultado y producción. Ninguna capa crea la siguiente por declaración.

Fuentes