Resumen

  • La IESG aprobó el 4 de septiembre de 2026 la revisión de NAT64 con estado como Internet Standard. El acto reconoce experiencia e implementación amplias, pero no homologa un producto ni demuestra la capacidad o continuidad de una instalación.
  • NAT64 multiplica clientes IPv6 sobre direcciones y puertos IPv4 escasos. La atribución fiable exige conservar por separado la asociación, la sesión, el filtro, el reloj, la generación de conmutación y el resultado de la aplicación.

El anuncio de la IESG aprobó draft-ietf-v6ops-rfc6146-bis-16 como Internet Standard. El futuro RFC sustituirá a RFC 6146 y se incorporará a STD 103. En el momento de la revisión, Datatracker mostraba el anuncio enviado y la actuación de IANA en curso; todavía no exponía un número RFC final.

La precisión temporal importa. No estamos ante una mera propuesta, pero tampoco ante un RFC ya numerado en las fuentes examinadas. Estamos ante una decisión técnica concluida cuyo procesamiento editorial continúa.

El ascenso reconoce una práctica, no una instalación

La versión 16 conserva el comportamiento esencial de RFC 6146. Corrige dos erratas sin cambio de protocolo, actualiza referencias, aclara la paridad de puertos e incorpora consideraciones operativas no normativas. RFC 6144 sigue aportando el marco general de la traducción IPv4/IPv6.

El documento enumera muchas implementaciones comerciales, abiertas y de nube. También limita el valor de esa lista: procede de información pública, no es un aval de la IETF y no fue confirmada mediante una prueba formal de interoperabilidad para esta publicación. RFC 7942 explica que una sección de estado de implementación ayuda a evaluar el trabajo, no crea una certificación.

Por eso el avance no permite inferir versión desplegada, modo de filtro, tamaño del pool, persistencia de estado, esquema de registro o éxito de conmutación. La tesis de Running-Code Primacy pone el orden correcto: el estándar disciplina la implementación; la operación observada demuestra el servicio.

El objeto escaso incluye el puerto y el tiempo

NAT64 con estado permite que clientes sólo IPv6 alcancen servidores IPv4 mediante UDP, TCP o ICMP. El traductor comparte una o varias direcciones IPv4 públicas. Para hacerlo, asigna una dirección de transporte: dirección más puerto, o dirección más identificador ICMP.

Ese objeto pertenece durante un intervalo a un contexto IPv6. No es propiedad permanente del cliente y tampoco es una identidad completa por sí solo. Cuando vence el estado, puede asignarse de nuevo.

El algoritmo intenta respetar rangos y paridad de puerto cuando hay recursos. Si no encuentra una combinación apropiada puede responder con ICMPv6; la política local puede silenciar el error. Un tiempo de espera visto por el usuario no prueba agotamiento. Es apenas el final visible de varias decisiones posibles.

La eficiencia tiene un costo probatorio. El propio borrador señala que maximizar puertos por dirección reduce el número de IPv4 públicas, pero aumenta el volumen de los registros. RFC 6269 detalla problemas derivados de compartir direcciones; RFC 6888 trata requisitos comunes de registro para traductores de gran escala.

El libro mayor mínimo guarda dirección, puerto o identificador, protocolo, tupla IPv6, hora de alta y baja, precisión temporal, instancia, generación de pool y regla de admisión. “La IP era nuestra” no responde quién tenía el derecho temporal.

BIB y sesión responden preguntas diferentes

Existen tres bases de información de asociaciones: UDP, TCP e ICMP. Una BIB relaciona una dirección de transporte IPv6 con una IPv4. Existen además tres tablas de sesiones, donde aparecen las parejas que realmente intercambian tráfico y, en TCP, el estado correspondiente.

Una asociación independiente del destino puede servir a varias sesiones. Una asociación configurada manualmente puede no tener sesión y permanecer hasta una eliminación explícita. Una sesión puede caducar mientras su asociación continúa. Reducir todo a “entradas NAT” destruye el significado.

Cada BIB y cada sesión necesita identidad propia, enlace entre ambas, generación, política, causa de refresco y causa de retiro. Tras una conmutación, una fila reconstruida no debería fingir que es la fila original: ha cambiado el testigo que responde por ella.

La separación de capas de realidad evita que una etiqueta absorba hechos incompatibles. Configuración, asociación, sesión, paquete traducido y operación empresarial son recibos distintos.

El mapeo no es una autorización de retorno

El estándar requiere mapeo independiente del extremo. Mientras vive la asociación, una tupla IPv6 puede conservar la misma tupla externa al comunicarse con destinos distintos. Sin embargo, la seguridad depende de los filtros.

Sin filtrado, cualquier fuente IPv4 que alcance una asociación viva puede atravesarla. Con filtrado dependiente de la dirección, sólo se admite retorno desde direcciones contactadas por el cliente IPv6. RFC 4787 define el comportamiento de UDP; RFC 5382 hace lo propio con TCP y sus temporizadores.

Por tanto, una ficha que marque “endpoint-independent mapping” no dice qué puede entrar. La prueba debe adjuntar modo de filtro, regla por defecto, excepciones, asociaciones estáticas, versión de configuración y tráfico de ensayo desde orígenes admitidos y rechazados.

También debe demostrar qué interfaz se considera externa. La especificación permite que el tráfico procedente del lado Internet no prolongue una sesión, evitando que un tercero mantenga recursos indefinidamente. Si el despliegue señala el lado equivocado, la defensa se aplica contra el origen equivocado.

Los temporizadores reparten continuidad y recursos

Una entrada UDP, TCP o ICMP no vive para siempre. TCP pasa por estados transitorios, establecidos y de cierre. Los fragmentos ocupan memoria durante un intervalo acotado. El vencimiento devuelve puerto y memoria al conjunto común.

Un plazo corto sacrifica sesiones legítimas que permanecen inactivas. Uno largo conserva continuidad, pero retiene recursos y amplía la oportunidad de abuso. El apartado operativo advierte que QUIC necesita vidas UDP razonables y que sus Connection IDs no deben emplearse como claves de estado NAT.

Las métricas necesitan distinguir altas, refrescos internos y externos, expiraciones normales, borrados tempranos, sesiones por estado, fragmentos almacenados y fallos de asignación. Una caída brusca puede ser limpieza o pérdida; sólo la causa y el resultado de aplicación resuelven la ambigüedad.

La concentración debe soportar agotamiento y cambio de testigo

La especificación reconoce recursos finitos: direcciones y puertos IPv4, memoria, CPU y enlace. Fuentes IPv6 variadas pueden agotar tuplas; fragmentos y SYN pueden consumir memoria; paquetes periódicos pueden intentar conservar entradas. Esto no demuestra que haya ocurrido un ataque concreto. Define la superficie que una operación responsable debe medir.

RFC 9693 aporta una metodología para comparar pasarelas NAT con estado. Una cifra sólo vale para la plataforma, versión, configuración, mezcla de tráfico, tamaño de paquetes y método probados. No puede copiarse a otra red como promesa de capacidad.

La especificación inicial mínima ofrece una buena división de trabajo. El estándar fija la interoperabilidad necesaria; el operador conserva la decisión sobre topología, capacidad, filtro y tolerancia al fallo. Esa libertad exige responsabilidad local, no una casilla genérica de conformidad.

La réplica debe heredar derechos, no sólo rutas

RFC 7269 y RFC 8683 recogen experiencia de despliegue y alta disponibilidad. Ninguno puede probar que un clúster concreto replica todas sus BIB, sesiones y relojes.

Antes de una conmutación hay que registrar generaciones, marca de agua de réplica, retraso, filas ausentes, diferencia de temporizadores y dueño del pool. Después se ensayan flujos UDP, TCP e ICMP ya establecidos, y se observa cuál continúa, cuál se recrea y cuál falla.

Existe además un conflicto entre continuidad y unicidad. Dos nodos que creen poseer el mismo pool pueden emitir asociaciones incompatibles. Un secundario que evita ese riesgo descartando estado desconocido protege la unicidad a costa de las sesiones. La dirección debe fijar el límite de pérdida aceptable y la regla de aislamiento.

Una dirección pública no identifica a una persona

RFC 8158 ofrece elementos IPFIX para consumo de recursos y eventos NAT. Son piezas útiles, no una cadena completa. Para atribuir un evento hacen falta protocolo, tupla externa, intervalo, instancia, generación, BIB, sesión, tupla interna, contexto de abonado y relojes conciliados.

La consulta debe funcionar de fuera hacia dentro y de dentro hacia fuera. Si los recorridos producen respuestas diferentes, el sistema debe conservar la incertidumbre. Añadir un identificador de cuenta tampoco prueba qué humano actuó ni qué orden aceptó la aplicación.

El Internet Standard normaliza la traducción. No homologa los registros del operador, no resuelve las obligaciones jurídicas de conservación, no certifica un nodo de respaldo y no convierte un paquete en resultado empresarial.

Esa frontera no disminuye la aprobación; la vuelve utilizable. Un estándar común permite exigir pruebas locales comparables. El pool, el reloj y el historial siguen bajo control del operador. Por eso necesitan propietario, versión y recibo.

Fuentes