Resumen

  • draft-ietf-v6ops-framework-md-ipv6only-underlay-28 plantea conversión IPv4/IPv6 sin estado en los bordes de una red IPv6-only multi-AS, guiada por reglas distribuidas.
  • Autenticar una regla no prueba que Pref6 aún resuelva al egreso originador, que todos los PE la hayan importado ni que el servicio haya terminado bien.
  • El recibo operativo debe unir acuerdo, autoridad, regla, importación local, ruta IPv6, validación de origen, retirada, egreso IPv4, retorno y aplicación.

El controlador muestra una regla válida, firmada por un participante autorizado. El MR-DB la conserva. Sin embargo, la ruta IPv6 hacia Pref6(PE) cambió y ya no termina en el PE que originó el vínculo. El dato es auténtico y la decisión es insegura.

La revisión 28, su página, el historial y el registro actual describen un Internet-Draft informativo de V6OPS, fechado el 28 de septiembre de 2026 y en IESG Evaluation. No es RFC, protocolo de distribución completo ni evidencia de despliegue.

El PE de entrada busca el destino IPv4 por prefijo más largo en su MR-DB. La regla aporta el Pref6 del egreso y un Conversion Type. Con RFC 6052 construye direcciones IPv4-embebidas en IPv6 y con RFC 7915 traduce paquetes e ICMP. El núcleo solo reenvía IPv6; el egreso reconstruye IPv4.

No existe tabla de sesión por flujo. Sí existe estado compartido: acuerdos bilaterales, asignación de prefijos, autoridad sobre bloques, versiones de reglas, políticas de importación y rutas recursivas. El marco presupone confianza previa, reglas ICMP coordinadas y entradas fiables. El dominio limitado del RFC 8799 delimita alcance, pero no crea esas condiciones.

Un PE solo puede originar reglas específicas para bloques de los que es egreso autorizado o agregador. No puede apropiarse de rutas externas de tránsito. El mecanismo futuro debe preservar los campos, limitar propagación, autenticar origen y rechazar vínculos fuera del alcance autorizado.

La autenticación responde quién afirmó, no si la afirmación sigue siendo utilizable. No demuestra control actual del bloque, implementación del modo, aceptación por cada receptor ni llegada al egreso. Por eso el borrador exige que Pref6 resuelva recursivamente al originador correcto. Si se pierde esa ruta, la regla debe retirarse o desactivarse y no puede seguir enviando tráfico.

Ese requisito separa base de datos y ejecución. Dos PE pueden conservar la misma regla y resolverla mediante rutas distintas. Un resumen MR-DB idéntico no sustituye el recibo FIB observado en el lugar que actuará.

Cuando falta una regla específica, 0.0.0.0/0: Pref6(PE) lleva el paquete al egreso predeterminado. La continuidad aparente tiene precio: concentra tráfico, oculta la ausencia y crea un objetivo catch-all. Su uso entre administraciones requiere acuerdo explícito y debe tener capacidad, límites y contadores propios.

También puede crear un bucle. El IPv4 restaurado no recuerda que cruzó el marco. Si la mejor ruta IPv4 del egreso vuelve hacia otro PE participante, el paquete se mapea otra vez. TTL limita duración, no evita consumo. El egreso necesita una vista IPv4 completa para lo que atrae y prohibición de reentrada.

La retirada ocurre por etapas. Para nuevas conversiones, la regla debe desaparecer de inmediato; un período breve puede cubrir paquetes ya encaminados; después entra el default o el descarte. Origen, distribución, MR-DB, FIB y reenvío en curso pueden discrepar. Sin versión, hora efectiva y motivo, la reconstrucción posterior será conjetura.

La validación de origen añade otra frontera: prefijo de entrada autorizado, IPv4 embebida compatible y llegada desde la red esperada. RFC 2827 aporta la disciplina anti-spoofing. Superarla no concede derecho comercial ni confirma recepción final.

MTU e ICMP completan la advertencia. La traducción aumenta cabecera y, con fragmentos, todavía más. Políticas distintas pueden bloquear Packet Too Big y crear un agujero negro PMTUD. RFC 6791 ayuda a construir la fuente del error, pero no obliga a transportarlo entre operadores.

El espacio que cubre el draft está entre trabajos previos: RFC 6992 trata OSPFv3 en un AS; RFC 8950, NLRI IPv4 con next hop IPv6; RFC 5565, Softwire Mesh con límites multi-AS. RFC 8585 y RFC 9313 cubren IPv4aaS de acceso, no un MR-DB entre operadores.

El recibo útil conserva acuerdo y frontera, alcance IPv4, asignación Pref6, regla autenticada, decisión de importación, versión local, ruta recursiva, validación, conversión, retirada, default, no reentrada, retorno y resultado de aplicación.

Las capas de realidad separan contrato, anuncio, instalación y resultado. La especificación inicial mínima fija el contrato verificable más pequeño. La primacía del código en ejecución exige mirar versiones, rutas, contadores, errores y servicio real.

Fuentes