Resumen

  • El borrador vigente de V6OPS vincula IPv6-Only al uso nativo efectivo dentro de un ámbito declarado; no lo equipara con el soporte instalado ni con el estado homogéneo de toda una red.
  • Una capa puede ser solo IPv6 aunque IPv4 continúe como servicio traducido o encapsulado, en otra interfaz, en el plano de control, en la administración o en destinos que el usuario todavía necesita.
  • Para convertir el rótulo en evidencia hace falta un registro que conserve objeto, vocabulario, observación, dependencias restantes, excepciones, responsable y condición de sustitución.

La red que cabe dentro de una frase

Las migraciones se cuentan con palabras que parecen estados finales: terminado, retirado, nativo, solo. En la práctica, una gran red cambia por zonas. El acceso residencial puede dejar de encaminar IPv4 de manera nativa mientras el núcleo continúa en doble pila. Un centro de datos puede asignar únicamente IPv6 a sus nodos, pero aceptar clientes IPv4 a través de un relé. Un teléfono puede usar un contexto IPv6 y ofrecer a sus aplicaciones una experiencia compatible con IPv4 mediante traducción.

El borrador IPv6-Only and IPv6-Mostly Terminology Definitions intenta que esas diferencias no se pierdan. La revisión 02 se publicó el 11 de septiembre de 2026; el anuncio de I-D confirma que es trabajo del grupo V6OPS. El Datatracker lo sitúa ahora en última llamada del grupo de trabajo. Esa etapa no es una aprobación del IESG ni una RFC definitiva. El historial y la comparación entre las revisiones 01 y 02 muestran un instrumento todavía sujeto a cambio.

La contribución esencial del texto 02 consiste en exigir un ámbito. El término describe la funcionalidad que se usa realmente allí, no todos los protocolos que un equipo sabe ejecutar. Un nodo puede tener implementadas ambas familias, pero una de sus interfaces puede transportar nativamente solo IPv6. IPv4 puede cruzar ese mismo enlace encapsulado o traducido. Por eso la frase exacta es una afirmación sobre el enlace, no un acta de defunción de IPv4.

La precisión evita una transferencia silenciosa de autoridad. Quien opera un enlace puede atestiguar su configuración. No por ello conoce cada dependencia de aplicaciones, proveedores, clientes, servicios externos o recuperación. Si un informe elimina el sustantivo —enlace, segmento, servicio, plano—, también elimina el límite de quien podía responder por la afirmación.

Retirar el protocolo de un plano no retira su función

En la terminología propuesta, IPv6-Only significa que solo IPv6 es nativo en el ámbito indicado. IPv4 no se configura ni gestiona allí, aunque pueda viajar sobre IPv6. IPv6-Only-Strict designa un estado más fuerte: tampoco hay IPv4 transportado, encapsulado o traducido dentro de ese ámbito.

Esa separación reconoce dos decisiones distintas. La primera cambia la forma de transportar tráfico. La segunda elimina la necesidad de conservar compatibilidad con IPv4 en el objeto descrito. Una organización puede tomar la primera para simplificar el acceso y ahorrar direcciones sin estar preparada para la segunda. Llamar éxito a la primera no es propaganda; presentarla como prueba de la segunda sí sería una inferencia indebida.

Los componentes técnicos enseñan dónde queda el control. RFC 6877 define 464XLAT para combinar traducción con y sin estado y sostener aplicaciones IPv4 sobre acceso IPv6. RFC 6146 define NAT64 con estado, y RFC 6147 DNS64. RFC 8585 recoge requisitos de los routers de cliente que participan en modalidades IPv4-as-a-Service.

La compatibilidad no desaparece: cambia de lugar y, con ello, de propietario. El traductor concentra capacidad y fallos. DNS64 introduce una dependencia de resolución. CLAT desplaza una parte de la función al equipo cliente. El servicio de asistencia debe distinguir problemas de aplicaciones, síntesis de nombres y traducción. La etiqueta breve registra la ausencia de IPv4 nativo, pero no identifica a quienes sostienen la experiencia IPv4 que queda.

En centros de datos, RFC 7755 describe SIIT-DC. Los nodos interiores pueden ser solo IPv6 y seguir atendiendo comunicaciones entrantes IPv4 mediante relés de borde. El perímetro interior ha cambiado de manera verificable. Los mapeos, el relay y la demanda exterior siguen siendo parte del servicio. La migración ha reducido una superficie y creado una frontera más visible.

El ámbito no es una etiqueta secundaria

El borrador ofrece ejemplos con enlaces de acceso, segmentos, hosts, APIs, planos de datos y control, redes de gestión, servicios y upstreams. Una empresa puede reunir VLAN solo IPv6, VLAN de doble pila y segmentos «IPv6-mostly». Un operador móvil puede dar transporte solo IPv6 al terminal y conectividad de doble pila a sus aplicaciones. Un data center puede tener cómputo IPv6 y upstream de doble pila.

Las frases no son intercambiables. «Plano de datos solo IPv6» deja abierta la tecnología del control y la recuperación. «Nodo solo IPv6» deja abierta la llegada de clientes externos. «Acceso solo IPv6» deja abierta la LAN del abonado. «Nube solo IPv6» es demasiado amplia si diferentes subredes tienen condiciones distintas.

Por eso el ámbito pertenece al dato. No basta con almacenarlo en una nota que se pierde cuando el resultado se copia a otra presentación. Si se quita, la proposición cambia. Y cuanto más cerca está la frase de un consejo de administración, una auditoría o un contrato, más costosa puede resultar esa ampliación no documentada.

La carta de V6OPS favorece orientación operativa para contextos concretos: proveedores, empresas, centros de datos y otras redes. La función del vocabulario común es permitir que esos casos se entiendan, no imponer una única arquitectura. La idea coincide con Minimum Initial Specification, Localized Future Decision, Voluntary Adoption de Heng Lu: un mínimo compartido debe dejar las decisiones futuras en manos de quienes operan cada entorno.

«Mayormente» tampoco es una cuota de tráfico

El proyecto no define IPv6-Mostly como «más del 50 %» ni por una proporción observada. Lo describe como un ámbito de doble pila con NAT64 y DHCPv4 opción 108, con DNS64 opcional, en el que conviven hosts IPv4, de doble pila y solo IPv6. IPv4 se entrega bajo demanda.

RFC 8925 concreta el intercambio. El cliente capaz solicita la opción 108. Si la red devuelve un valor válido, puede no pedir la dirección IPv4 ofrecida y detener DHCPv4 durante un intervalo o hasta un nuevo evento de conexión. La capacidad se evalúa por interfaz; una máquina no adquiere para siempre una identidad «solo IPv6».

Esta reversibilidad limita las conclusiones. Menos concesiones DHCPv4 pueden indicar ahorro de direcciones, pero no ausencia de destinos IPv4. Un porcentaje de tráfico IPv6 no identifica los traductores de los que depende el resto. Una prueba de conectividad no demuestra que la recuperación fuera de banda haya migrado. El indicador solo adquiere sentido cuando declara qué pregunta responde.

El registro mínimo que impide exagerar

No hace falta publicar direcciones, topología, clientes ni reglas internas. Hace falta conservar una unión duradera entre la palabra y su objeto. Un registro de ámbito y dependencias puede contener:

  1. el servicio, interfaz, segmento, cohorte, plano o red exactamente descritos;
  2. el término empleado y la versión del vocabulario;
  3. los protocolos nativos y el método que los observó;
  4. la versión de configuración y el periodo de validez;
  5. el IPv4 que aún se transporta, traduce, encapsula o alcanza fuera del ámbito;
  6. las funciones NAT64, DNS64, CLAT, SIIT-DC, proxy o CDN necesarias;
  7. las excepciones de aplicación, dispositivo, control y emergencia;
  8. el dueño operativo de cada dependencia y la autoridad que aprueba el rótulo;
  9. el fallo esperado y la ruta de reversión;
  10. la evidencia que permitiría adoptar un estado más fuerte y quién puede sustituir el registro.

El registro no emite un certificado. Conserva una decisión local, fechada y corregible. Puede mostrar una secuencia: primero el acceso, después ciertos hosts, luego los servicios de gestión, quizá finalmente un ámbito estricto. Las fases no tienen que obedecer a una autoridad mundial; sí deben poder atribuirse a quienes las decidieron.

También debe permitir desacuerdo. Operaciones puede considerar NAT64 una plataforma estable; seguridad, un nuevo punto de concentración; finanzas, un intercambio entre coste de direcciones y coste de servicio; producto, una protección para clientes antiguos. En The Policy Mirror, Heng Lu sostiene que la política debe reflejar sistemas e incentivos reales. Hacer visibles esas lecturas es más honesto que comprimirlas en un color verde.

Qué no puede concluirse

Las fuentes no prueban que un operador concreto haya exagerado su estado. El borrador no es una auditoría y no contiene métricas de adopción, rendimiento o coste. Su situación de última llamada puede cambiar. Incluso una RFC informativa futura definiría lenguaje; no certificaría una red.

Tampoco se desprende que las traducciones deban suprimirse cuanto antes. Pueden ser la condición de una transición gradual que no excluya usuarios. La pregunta de gobierno es si la institución sabe dónde están, quién responde por ellas y qué parte del resultado dejaría de existir si fallaran.

«Solo IPv6» es valioso cuando conserva su modestia: indica qué es nativo en un lugar y momento determinados. La retirada de IPv4 es otra decisión, con otra evidencia. Separarlas permite reconocer el progreso sin inventar una finalidad.

Fuentes