Resumen

  • RFC 5211 propuso preparación, transición y una fase posterior desde enero de 2012, orientada a una conectividad predominantemente IPv6. También declaró que era un plan posible, informativo y sin obligación para ninguna parte.
  • Un plazo y un MUST aclaran una expectativa. No certifican que IPv6 se pudiera contratar, estuviera provisionado, tuviera ida y vuelta, fuese el camino elegido o sostuviera la aplicación.

La fecha coordinaba, no observaba

En julio de 2008, RFC 5211 intentó poner un ritmo común a una migración que ninguna autoridad podía ejecutar por sí sola. La preparación llegaría hasta diciembre de 2009; la transición ocuparía 2010 y 2011; la postransición empezaría en enero de 2012. Los proveedores pasarían de pilotos a servicio de producción y las organizaciones añadirían IPv6 a sus servidores públicos.

El documento delimitó su poder. Lo llamó «un posible plan», admitió alternativas y dijo que no creaba obligaciones. Las palabras de RFC 2119 se usaban para describir la propuesta sin ambigüedad. La nota del IESG añadió que no era candidato a ningún nivel de estándar de Internet ni un producto de la revisión técnica ordinaria de consenso IETF.

Ese estatus permitía coordinar conversaciones, no confirmar hechos operativos. A medianoche cambiaba la fecha. La oferta comercial, el presupuesto, la configuración, las rutas y el resultado del usuario seguían bajo control de sistemas y actores distintos.

Una oferta no es un único estado

TRANS1 y POST1 dicen que el proveedor debe ofrecer Internet IPv6. Para comprobarlo hay que abrir la palabra «ofrecer»: catálogo, cobertura, producto de acceso, elegibilidad, pedido, asignación, equipo de borde, ruta de ida, ruta de vuelta, DNS, vigilancia y soporte.

La ficha de producto puede existir mientras el pedido falla. El prefijo puede estar asignado mientras falta la ruta. La ruta puede verse mientras la selección de dirección prefiere IPv4. Un sondeo puede responder aunque el inicio de sesión, el pago, el correo o una dependencia externa no completen el recorrido.

En el sitio del cliente, publicar AAAA sólo demuestra una entrada DNS. La resolución, la elección de camino, la conexión, la transacción y la continuidad generan recibos diferentes. Un éxito desde una ubicación no representa a todas las redes, aplicaciones ni horas. Sin denominador, «predominante» es una descripción sin posibilidad de auditoría.

MUST no designó a un inspector

La mayúscula de RFC 5211 daba nitidez al escenario, pero el propio texto negó que impusiera deberes. No definió un censo de proveedores, un método de prueba, un evaluador común ni una sanción. Convertir cada MUST en cumplimiento exigible sería atribuir al documento una autoridad que rechazó.

La deformación suele ocurrir en los traspasos. «Los proveedores MUST ofrecer» entra en una hoja de compras y sale como «la transición global se completó». Por el camino se pierden sujeto, mercado, servicio, cliente, momento y comprobación.

La solución es mantener la fuerza del verbo y registrar sus condiciones. Oferta exige producto y pedido aceptado. Activación exige configuración y rutas. Producción exige transacciones, alarmas y soporte. Predominio exige métrica, población y ventana. Retirada de IPv4 exige inventario, excepción y vuelta atrás.

POST4 conservó la coexistencia

La fase posterior no equivalía a apagar IPv4. POST4 permitía a los proveedores seguir ofreciéndolo y a las organizaciones seguir usándolo. El objetivo era una Internet en la que IPv6 tuviera el papel principal, no una frontera binaria que borrara el protocolo anterior.

Los trabajos posteriores sobre doble pila, traducción, equipos del cliente, contenido, empresas, seguridad e IPv4 como servicio reflejan esa composición. Un núcleo IPv6-only puede transportar IPv4aaS; un portal puede ser dual; una aplicación adquirida puede continuar en IPv4. Cada componente tiene su propia fase.

También hay dos riesgos. Retirar IPv4 antes de conocer las dependencias puede interrumpir el servicio. Mantenerlo sin revisión perpetúa coste y superficie de ataque. El año del plan no sustituye esa decisión.

Publicar otra RFC no desplegó la anterior

RFC 6144 señaló en 2011 que el agotamiento de direcciones IPv4 podía adelantarse a una adopción significativa de IPv6. RFC 6180 habló de una cola larga. RFC 6540 convirtió el soporte de IPv6 en una buena práctica vigente para nodos con capacidad IP. Otros documentos detallaron contenido, equipos de borde y despliegue empresarial.

La documentación avanzó; eso no demuestra implementación. Estatus normativo, código compatible, opción habilitada, camino desplegado y resultado observado siguen siendo capas independientes. Tampoco una fecha incumplida demuestra un fallo del protocolo: sólo demuestra que la fecha no creó el estado. Para explicar la brecha hacen falta pruebas sobre compras, incentivos, legado, capacidades y riesgo local.

La cadena que debe sobrevivir al programa

Un registro útil une plan, responsable, presupuesto, oferta, pedido, provisión, dirección, DNS, rutas en ambos sentidos, selección, tráfico, resultado de aplicación, continuidad, excepciones y retirada. Cada pieza declara alcance, hora, actor y procedencia.

No se necesita una base central que gobierne a todos. Basta una forma mínima común de describir la evidencia y dejar que cada red decida umbrales. Así la coordinación voluntaria produce afirmaciones comparables sin apropiarse de las decisiones locales.

El plazo recupera entonces su función correcta: abrir una revisión. Si el sistema ejecutado contradice al plan, se corrige el plan; no se cambia el nombre del sistema.

Fuentes

  1. Información de RFC 5211
  2. RFC 5211 en HTML
  3. RFC 5211 en texto
  4. Datatracker IETF: RFC 5211
  5. Historial de RFC 5211
  6. Referencias de RFC 5211
  7. Erratas de RFC 5211
  8. RFC 3932 — documentos independientes
  9. RFC 2119 — palabras de requisito
  10. RFC 8174 — actualización de BCP 14
  11. RFC 6144 — traducción IPv4/IPv6
  12. RFC 6180 — guía de transición IPv6
  13. RFC 6540 — soporte IPv6 requerido
  14. RFC 6589 — transición de contenido
  15. RFC 7084 — equipos de borde del cliente
  16. RFC 7381 — despliegue empresarial
  17. RFC 8170 — escenarios de despliegue
  18. RFC 9099 — seguridad operacional IPv6
  19. RFC 9313 — IPv4 como servicio
  20. Heng Lu — capas de realidad y poder simbólico
  21. Heng Lu — especificación inicial mínima
  22. Heng Lu — primacía del código en ejecución