Resumen

  • La IESG aprobó la revisión 16 de NAT64 con estado como Internet Standard, y el propio texto separa el comportamiento de mapeo de la configuración de filtrado.
  • Una evidencia útil debe registrar por separado la reutilización de la tupla, las fuentes admitidas, el protocolo, la dirección de interfaz y el resultado de pruebas positivas y negativas.

El error puede nacer en una prueba bien hecha. Un equipo envía tráfico desde la misma dirección y puerto IPv6 a dos servidores IPv4. El traductor conserva la misma dirección y puerto IPv4 externos durante la vida del enlace. El resultado confirma un mapeo independiente del punto final.

En la reunión de cambio, alguien resume: «el mapeo es independiente, por tanto el retorno está restringido al servidor contactado». La segunda mitad no se desprende de la primera. Nadie ha enviado un paquete desde una tercera dirección IPv4, leído la acción predeterminada ni comprobado las reglas instaladas. La tabla de control ha unido dos verbos diferentes: representar y permitir.

La aprobación reciente del estándar ofrece una ocasión para corregir esa costumbre. El 4 de septiembre de 2026, la IESG aprobó la revisión 16 de Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers como Internet Standard. También pidió al RFC Editor incorporarla a STD 103. El anuncio describe NAT64 con estado como una tecnología ampliamente implementada y desplegada, destinada a sustituir la RFC 6146.

La decisión todavía no equivale a una RFC nueva ya publicada. En la fecha de corte, la ficha de Datatracker mostraba la revisión 16 en la cola editorial y bloqueada a la espera de información de los autores. El historial conserva la secuencia del proceso. Citar un número sucesor inexistente convertiría una expectativa razonable en un hecho falso.

Tampoco se aprobó un cambio sorpresivo de conducta. El anuncio señala que las discusiones sobre las erratas 4756 y 8416 concluyeron que eran aclaraciones editoriales sin efectos de compatibilidad. El apéndice A de la revisión 16 dice que ninguna altera el protocolo. La RFC 6146 permite ver el punto de partida. La noticia importante no es una supuesta función nueva, sino la precisión con la que el estándar distingue controles que los inventarios suelen mezclar.

Mapear es escoger una representación externa

NAT64 con estado mantiene bases de enlaces y tablas de sesiones. Para TCP o UDP, asocia una dirección y un puerto IPv6 con una dirección y un puerto IPv4. Esa tupla externa puede liberarse después de un temporizador y volver al conjunto limitado de recursos públicos.

Un mapeo independiente del punto final reutiliza la misma tupla externa cuando la misma fuente interna habla con destinos distintos dentro de la ventana del enlace. La RFC 4787 exige esa conducta para NAT UDP y explica su razón: facilita métodos de recorrido y aplicaciones entre pares. Pero el mismo documento advierte que las alternativas de mapeo no determinan las propiedades de seguridad; esas dependen del filtrado.

La RFC 5382 aplica la idea a TCP. Una aplicación puede aprender y anunciar la dirección externa de forma consistente, pero el contacto del par sigue sujeto a la política del NAT. Así, «mapeo independiente» responde a qué representación recibe la fuente. No responde qué origen externo tiene autoridad para usarla.

La revisión 16 obliga a ofrecer ese mapeo y permite además mapeos dependientes de la dirección. En ningún caso el modo elegido sustituye la lectura de las reglas entrantes. Un certificado de capacidad puede decir qué soporta el equipo. Una evidencia de operación debe decir qué opción se aplicó en ese instante.

Filtrar es decidir quién atraviesa la representación

El texto aprobado ofrece el contraste de manera directa. Si existe un mapeo independiente y no hay filtrado, cualquier nodo IPv4 que acierte la tupla externa puede enviar tráfico a la dirección de transporte IPv6 asociada. No es una acusación contra NAT64: es el efecto de combinar estado existente con ausencia de filtro.

Con el mismo mapeo, una política dinámica dependiente de la dirección puede aceptar solamente fuentes IPv4 a las que el host IPv6 haya enviado tráfico antes. Otras fuentes se descartan por una prohibición expresa o por la acción predeterminada. Cambia la superficie efectiva sin cambiar la forma en que se asigna la tupla.

La selección implica costes reales. La RFC 4787 recomienda filtrado independiente cuando prima la transparencia de las aplicaciones, y dependiente de la dirección cuando prima una restricción mayor. La decisión puede ser configurable. En TCP, la RFC 5382 incluso permite que el filtrado difiera del configurado para UDP. Por eso una sola etiqueta para todo el traductor es demasiado amplia.

ICMP tiene su propia semántica. La RFC 5508 utiliza identificadores de consulta, no puertos TCP o UDP. La revisión 16 aclara mediante la errata 4756 que ICMP no tiene una regla de filtrado dependiente de la dirección análoga en ese punto del procesamiento. Copiar automáticamente la matriz de UDP a ICMP produce uniformidad documental, no exactitud.

Lo estático exige una prueba más precisa

El capítulo de seguridad observa que un filtro basado únicamente en la quíntupla puede resultar adivinable en algunos mapeos estáticos. El traductor puede seguir números de secuencia TCP para validar mejor SYN y FIN. Ese mecanismo es opcional. Un ping de traducción correcto no revela si existe, si quedó instalado tras una actualización o si cubre la interfaz examinada.

También hay límites físicos: direcciones y puertos IPv4, memoria para enlaces, sesiones y fragmentos, y capacidad de enlace. El documento trata la protección ante agotamiento y la necesidad de configurar qué lado se considera externo para ciertas decisiones sobre duración del estado. Sin dirección, temporizadores y origen del enlace —estático, dinámico o creado mediante PCP— el resultado de una prueba queda separado de su contexto de autoridad.

La RFC 7269 aporta experiencia de despliegue, incluida alta disponibilidad y seguridad. La RFC 8683 añade directrices para NAT64/464XLAT. Son recordatorios de que la función vive dentro de rutas, redundancia y operación. No son atajos que permitan inferir un filtro a partir de una tupla.

Un recibo para conservar la diferencia

Daniel Kade propone un recibo de decisión de mapeo y filtrado. Su cabecera identifica traductor, versión, interfaz, dirección y protocolo. Después registra por separado el modo de mapeo, el modo de filtrado, la acción predeterminada, el origen del enlace, los temporizadores, la versión de política, el aprobador, los topes de recursos y la caducidad de las excepciones.

La parte ejecutada contiene dos familias de pruebas. La primera verifica la tupla externa ante destinos distintos. La segunda envía tráfico desde fuentes permitidas y no permitidas. La salida de reglas instaladas, contadores, alarmas y resultado después de una conmutación unen la intención con el comportamiento real.

No es una certificación eterna ni una promesa de invulnerabilidad. Es una afirmación limitada: esta versión, en esta interfaz y protocolo, asignó así y filtró de este modo. Un cambio de software, rol de interfaz, política, temporizador, conmutación o enlace estático invalida la evidencia afectada.

The Policy Mirror obliga a ubicar el punto donde cada regla adquiere fuerza. Running-Code Primacy exige resultados observables en ambos puntos. Reality, Not Advocacy mantiene el límite editorial: un estándar aprobado permite analizar controles; no permite inventar el fallo de un operador.

Fuentes