NAT64 y DNS64: Conectar Redes Solo IPv6 a IPv4

El Futuro Solo IPv6 #

Dual-stack (ejecutar IPv4 e IPv6 simultáneamente) es el enfoque estándar de migración. Pero mantener dos redes paralelas para siempre no es el objetivo. El punto final es infraestructura solo IPv6 con IPv4 heredado accedido solo cuando sea necesario.

Esta transición ya ocurre en redes móviles. Los principales operadores ejecutan pilas solo IPv6 en smartphones. T-Mobile, AT&T y Verizon eliminaron IPv4 de sus redes LTE/5G hace años. Tu teléfono tiene una dirección IPv6. Cuando accedes a un sitio web solo IPv4, NAT64 y DNS64 manejan la traducción transparentemente.

Las redes empresariales siguen el mismo camino. Solo IPv6 reduce complejidad, elimina preocupaciones de agotamiento de direcciones IPv4 y simplifica enrutamiento. Pero la eliminación completa de IPv4 no es realista todavía: demasiados servicios permanecen solo IPv4. NAT64 y DNS64 cierran esta brecha, permitiendo que redes solo IPv6 accedan Internet IPv4.

TL;DR - Resumen rápido

Puntos clave:

NAT64 traduce paquetes IPv6 a IPv4; DNS64 sintetiza registros AAAA desde registros A
Prefijo conocido 64:ff9b::/96 embebe direcciones IPv4 en espacio IPv6
Las redes móviles usan esto extensivamente (T-Mobile, AT&T, Verizon son solo IPv6)
DNS64 rompe DNSSEC — los registros sintéticos no coinciden con zonas firmadas
Literal de direcciones IPv4 omite DNS64 — algunos clientes necesitan configuración especial

Ir a: Cómo funciona | Configuración | Solución de problemas

Cómo Funcionan Juntos NAT64 y DNS64 #

NAT64 realiza traducción de protocolo en la capa de red. DNS64 sintetiza direcciones IPv6 que activan esta traducción. Funcionan como un par: DNS64 sin NAT64 es inútil, y NAT64 sin DNS64 requiere configuración manual.

El Flujo de Traducción #

Aquí está lo que sucede cuando un cliente solo IPv6 accede un servicio solo IPv4:

┌─────────────────────────────────────────────────────────────────┐
│ 1. Cliente consulta DNS por www.ipv4only.example.com          │
│    Tipo de consulta: AAAA (dirección IPv6)                    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. Servidor DNS64 consulta DNS upstream                        │
│    Recibe: Registro A → 198.51.100.10 (solo IPv4)            │
│    No existe registro AAAA                                     │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64 sintetiza registro AAAA                               │
│    Combina prefijo NAT64 + dirección IPv4                     │
│    Resultado: 64:ff9b::198.51.100.10                         │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. Cliente recibe dirección IPv6 sintetizada                  │
│    Envía paquetes a 64:ff9b::198.51.100.10                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. Gateway NAT64 intercepta paquetes                           │
│    Reconoce prefijo 64:ff9b::/96                              │
│    Extrae IPv4 embebido: 198.51.100.10                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64 traduce IPv6 → IPv4                                   │
│    Cambia cabeceras de paquete                                 │
│    Realiza NAT con estado (rastrea sesión)                    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. Paquete IPv4 enviado a destino                              │
│    Origen: Dirección IPv4 del gateway NAT64                   │
│    Destino: 198.51.100.10                                      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. Tráfico de retorno traducido de vuelta                     │
│    NAT64 busca sesión                                          │
│    Traduce IPv4 → IPv6                                         │
│    Reenvía al cliente                                          │
└─────────────────────────────────────────────────────────────────┘

El cliente ve solo IPv6. El servicio solo IPv4 ve solo IPv4. NAT64 y DNS64 manejan la traducción invisiblemente.

El Prefijo Bien Conocido #

El prefijo NAT64 estándar es 64:ff9b::/96 (RFC 6052). Este prefijo bien conocido le dice a todos «las direcciones IPv4 están embebidas aquí».

El embebido de dirección IPv4 funciona así:

Dirección IPv4:    198.51.100.10
En hex:          C6.33.64.0A
Prefijo NAT64:    64:ff9b::
Combinado:        64:ff9b::c633:640a
Expandido:        64:ff9b::198.51.100.10 (notación común)

Los últimos 32 bits de la dirección IPv6 contienen la dirección IPv4. Las aplicaciones nunca ven esto: es puramente interno a la infraestructura de traducción.

Puedes usar prefijos personalizados en lugar del prefijo bien conocido. Opciones comunes incluyen prefijos específicos de organización como 2001:db8:64::/96. Esto permite ingeniería de tráfico (enrutar tráfico NAT64 diferentemente) pero requiere cambios de configuración DNS64.

DNS64 en Profundidad #

DNS64 es un servidor DNS con lógica de traducción especial. Intercepta consultas AAAA y sintetiza respuestas cuando solo existen registros A.

Flujo Lógico DNS64 #

Consulta AAAA para example.com
    ↓
Consultar upstream por AAAA
    ↓
¿Existe registro AAAA? ─ SÍ ─→ Devolver registro AAAA (IPv6 nativo)
    │
    NO
    ↓
Consultar upstream por A
    ↓
¿Existe registro A? ─ NO ─→ Devolver NXDOMAIN
    │
    SÍ
    ↓
Sintetizar AAAA = prefijo + IPv4
    ↓
Devolver AAAA sintetizado

Comportamientos clave:

IPv6 nativo preferido: Si existe AAAA, DNS64 lo devuelve sin cambios. Sin síntesis. NAT64 no involucrado.
Respaldo IPv4 solo: La síntesis ocurre solo cuando no existe AAAA
Preservación de TTL de caché: Los registros sintetizados heredan TTL del registro A
Complejidad DNSSEC: La síntesis rompe validación DNSSEC (más sobre esto después)

Ejemplos de Configuración DNS64 #

BIND 9:

options {
    // ... otras opciones ...
    dns64 64:ff9b::/96 {
        clients { any; };
        mapped { !192.168.0.0/16; !10.0.0.0/8; any; };
        exclude { 64:ff9b::/96; ::ffff:0:0/96; };
        suffix ::;
    };
};

Parámetros:

clients: Qué clientes obtienen DNS64 (usualmente any)
mapped: Qué direcciones IPv4 traducir (excluir direcciones privadas RFC 1918)
exclude: Qué rangos IPv6 nunca sintetizar
suffix: Personaliza dónde se embebe IPv4 en dirección (avanzado)

Unbound:

server:
    module-config: "dns64 validator iterator"
 
dns64:
    dns64-prefix: 64:ff9b::/96
    dns64-synthall: no

dns64-synthall: Si sintetizar incluso cuando existe AAAA (usualmente no)

PowerDNS Recursor:

# En recursor.conf
enable-dns64: yes
dns64-prefix: 64:ff9b::/96

NAT64 en Profundidad #

NAT64 es traducción con estado: mantiene estado de sesión como NAT44 tradicional. Cada conexión de cliente obtiene un mapeo en la tabla de estado del gateway NAT64.

Traducción con Estado #

El gateway NAT64 rastrea:

Dirección y puerto IPv6 de origen
Dirección y puerto IPv4 de destino
Dirección y puerto IPv4 de origen traducidos
Protocolo (TCP/UDP/ICMP)
Temporizadores de sesión

Entrada de Tabla de Sesión:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Lado Cliente IPv6           │  Lado Servidor IPv4
━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234       │  203.0.113.5:6789
  (IPv6 cliente:puerto)     │    (IPv4 NAT:puerto)
                            │        ↕
                            │  198.51.100.10:80
                            │  (IPv4 destino:puerto)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Protocolo: TCP
Estado: ESTABLISHED
Timeout: 7440 segundos

Cuando llega tráfico de retorno a 203.0.113.5:6789, NAT64 busca la sesión y traduce de vuelta a 2001:db8:100::45:1234.

Traducción de Protocolo #

NAT64 traduce más que direcciones: convierte entre formatos de paquete IPv4 e IPv6:

Paquete IPv6:

[ Cabecera IPv6 | Cabecera TCP/UDP/ICMP | Carga Útil ]

Traducido a IPv4:

[ Cabecera IPv4 | Cabecera TCP/UDP/ICMP | Carga Útil ]

La traducción incluye:

TTL/Hop Limit: Decrementado y copiado
Fragmentación: Fragmentación IPv6 → fragmentación IPv4 (con consideraciones MTU)
ICMP: ICMPv6 → ICMPv4 (mapeo de tipo de mensaje)
Checksums: Recalculados para nuevas cabeceras de protocolo

Opciones de Implementación #

Existen múltiples implementaciones de software NAT64, desde ligeras hasta grado de operador.

TAYGA: Espacio de Usuario Ligero #

TAYGA es un daemon NAT64 simple de espacio de usuario para Linux. Bueno para despliegues pequeños y pruebas.

Instalación:

apt-get install tayga
 
# Crear interfaz TUN
ip tuntap add name nat64 mode tun
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip addr add 2001:db8:ffff::1/96 dev nat64

Configuración (/etc/tayga.conf):

tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24
data-dir /var/lib/tayga

Iniciar y enrutar:

systemctl start tayga
 
# Enrutar prefijo NAT64 a través de TAYGA
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64
 
# Habilitar reenvío
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

Pros: Simple, ligero, configuración fácil Contras: Rendimiento limitado (espacio de usuario), sin clustering, características mínimas

Jool: Módulo de Kernel #

Jool implementa NAT64 como módulo de kernel Linux, ofreciendo mejor rendimiento.

Instalación:

# Añadir repositorio (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools
 
# Cargar módulo
modprobe jool

Configuración:

# Crear instancia NAT64
jool instance add "default" --netfilter --pool6 64:ff9b::/96
 
# Añadir pool de direcciones IPv4
jool -i "default" pool4 add --tcp 203.0.113.5 1024-65535
jool -i "default" pool4 add --udp 203.0.113.5 1024-65535
jool -i "default" pool4 add --icmp 203.0.113.5 1024-65535
 
# Habilitar
jool -i "default" global update enabled true

Enrutamiento:

ip route add 64:ff9b::/96 via 2001:db8::1

Pros: Alto rendimiento (espacio de kernel), desarrollo activo, buena documentación Contras: Complejidad del módulo de kernel, problemas ocasionales de compatibilidad con actualizaciones de kernel

464XLAT: Habilitar Aplicaciones Solo IPv4 #

NAT64/DNS64 funciona transparentemente para aplicaciones dual-stack. Pero algunas apps codifican direcciones IPv4 o usan protocolos que DNS64 no puede interceptar. 464XLAT resuelve esto.

Cómo Funciona 464XLAT #

464XLAT añade traducción del lado del cliente (CLAT) antes de NAT64 (PLAT):

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  App IPv4   │      │              │      │              │
│             │      │ Red Solo     │      │ Servidor     │
│ 192.0.0.10  │      │ IPv6         │      │ IPv4         │
│             │      │              │      │198.51.100.10 │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (local)                                PLAT (ISP)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── Red IPv6 ─────────────────────┘

Pasos:

App envía paquete IPv4 a 192.0.0.10 (interfaz virtual CLAT)
CLAT traduce IPv4 → IPv6 usando prefijo local (ej., 64:ff9b::c000:0a)
Paquete IPv6 atraviesa red a PLAT (gateway NAT64)
PLAT traduce IPv6 → IPv4
Paquete IPv4 alcanza destino

La app ve conectividad IPv4 local. La red es solo IPv6. La traducción ocurre en ambos extremos.

464XLAT en Móviles #

Android e iOS implementan CLAT automáticamente cuando se conectan a redes solo IPv6 con NAT64:

CLAT de Android:

Detecta NAT64 consultando ipv4only.arpa (devuelve AAAA sintetizado si existe NAT64)
Crea interfaz clat4 con direcciones 192.0.0.0/29
Enruta tráfico de app IPv4 a través de CLAT
Traduce a IPv6 usando prefijo NAT64 detectado

CLAT de iOS:

Mecanismo de detección similar
Transparente para apps y usuarios

Por esto apps solo IPv4 funcionan en T-Mobile, AT&T y otras redes móviles solo IPv6.

Limitaciones y Trampas #

NAT64/DNS64 no es perfecto. Entender limitaciones previene fallos de despliegue.

1. DNSSEC Se Rompe #

DNS64 sintetiza registros AAAA que no existen en la zona autoritativa. Las firmas DNSSEC no cubren estos registros sintéticos, por lo que la validación falla.

Soluciones:

Deshabilitar validación DNSSEC en resolvedor DNS64 (no ideal)
Usar DNS64 que soporte manejo DNSSEC RFC 6147 (implementación limitada)
Aceptar que dominios solo IPv4 firmados con DNSSEC no validarán

Este es el mayor desafío operacional con DNS64.

2. Direcciones IPv4 Codificadas #

Aplicaciones con IPs codificadas eluden DNS, así que DNS64 nunca ve la consulta. NAT64 no puede ayudar porque solo reconoce el prefijo NAT64.

Soluciones:

Desplegar 464XLAT (maneja todo tráfico IPv4)
Actualizar aplicaciones para usar nombres DNS
Usar gateways de capa de aplicación (raro, complejo)

3. Literales IPv4 en URLs #

Apps web pasando http://192.0.2.1/api en URLs o configuración. Los navegadores no realizan búsquedas DNS para literales IP, así que DNS64 no sintetiza.

Soluciones:

Usar nombres de host en lugar de literales IP
Proxies de capa de aplicación que reescriben literales
464XLAT

4. FTP y Otros ALGs #

Protocolos que embeben direcciones IP en datos de aplicación (modo activo FTP, SIP, etc.) a menudo fallan a través de NAT64. La dirección en la carga útil no coincide con la cabecera del paquete.

Solución:

Usar modo pasivo FTP (sin direcciones embebidas)
Desplegar NAT64 consciente de protocolo con soporte ALG (complejo)
Moverse a protocolos modernos que no embeben IPs

5. Problemas de Fragmentación #

Las diferencias de MTU de ruta entre IPv4 e IPv6 pueden causar problemas de fragmentación. IPv6 tiene un MTU mínimo de 1280 bytes; IPv4 permite 576 bytes.

Solución:

Asegurar que MTU sea consistente a través de infraestructura
Habilitar Path MTU Discovery (PMTUD)
Monitorear y alertar sobre mensajes ICMP Packet Too Big

No es un Reemplazo para Dual-Stack

NAT64/DNS64 es una herramienta para que redes solo IPv6 alcancen recursos IPv4. No es una estrategia de migración por sí sola. Dual-stack permanece como el camino recomendado para la mayoría de redes. Usa NAT64/DNS64 donde solo IPv6 tenga sentido arquitectónico (móvil, cloud-native, greenfield).

Monitoreo y Resolución de Problemas #

NAT64/DNS64 añade capas de traducción que pueden oscurecer problemas. El monitoreo adecuado es esencial.

Verificación DNS64 #

Probar si DNS64 funciona:

# Consultar por dominio conocido solo IPv4
dig AAAA ipv4.google.com @2001:db8::53
 
# Debe devolver AAAA sintetizado con prefijo NAT64
# Ejemplo: 64:ff9b::8.8.8.8

Si no obtienes registro AAAA, DNS64 no está funcionando.

Prueba de Conectividad NAT64 #

Usar el dominio de prueba especial ipv4only.arpa:

# Desde cliente solo IPv6
ping6 ipv4only.arpa
 
# Debe recibir respuesta vía NAT64
# El dominio resuelve a 192.0.0.170, sintetizado a 64:ff9b::192.0.0.170

Si ping falla, el gateway NAT64 no es alcanzable o no está traduciendo.

Inspección de Tabla de Sesión #

Verificar estado de sesión NAT64:

Jool:

jool -i "default" session display
 
# Muestra sesiones activas
# Buscar: IPv6 cliente, IPv4 traducido, destino

TAYGA:

cat /var/lib/tayga/dynamic.map
 
# Muestra mapeos de direcciones

Conteos altos de sesión indican uso pesado o problemas potenciales (fugas de conexión).

Consideraciones de Seguridad #

NAT64 introduce implicaciones de seguridad más allá de NAT típico.

Escaneo de Espacio de Direcciones #

El prefijo NAT64 hace predecibles las direcciones IPv4 en IPv6. Los atacantes pueden escanear 64:ff9b::/96 para descubrir qué servicios IPv4 estás accediendo.

Mitigación: Usar prefijos NAT64 específicos de red en lugar del prefijo bien conocido, limitando exposición.

Eludir Controles de Acceso #

Los controles de acceso IPv4 (reglas de firewall, ACLs) pueden no contabilizar tráfico traducido por NAT64 llegando desde orígenes IPv6 inesperados.

Mitigación: Aplicar políticas de seguridad al gateway NAT64, no solo endpoints.

Cuándo Usar NAT64/DNS64 vs. Dual-Stack #

Marco de decisión:

┌─────────────────────────────────────────────────┐
│ ¿Puedes ejecutar dual-stack?                   │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         SÍ                     NO
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ Usar        │     │ ¿Por qué no?        │
   │ Dual-Stack  │     │                     │
   │             │     │ • Agotamiento IPv4  │
   │ (más simple,│     │ • Simplificación    │
   │  menos      │     │   arquitectónica    │
   │  problemas) │     │ • Red móvil         │
   └─────────────┘     │ • Cloud native      │
                       └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ Usar NAT64/DNS64   │
                         │                    │
                         │ Añadir 464XLAT si: │
                         │ • Apps solo IPv4   │
                         │ • IPs codificadas  │
                         └────────────────────┘

NAT64/DNS64 tiene sentido cuando:

El agotamiento de direcciones IPv4 es una restricción real
Estás construyendo nueva infraestructura (greenfield)
Red móvil o arquitectura cloud-native
Los beneficios operacionales de pila única superan la complejidad de traducción

Dual-stack tiene sentido cuando:

Las direcciones IPv4 están disponibles
Infraestructura mixta heredada y moderna
La compatibilidad es máxima prioridad
Familiaridad del equipo con dual-stack

Comienza Pequeño y Prueba #

No despliegues NAT64/DNS64 en producción sin pruebas exhaustivas:

Entorno de laboratorio: Configurar TAYGA o Jool en red de prueba
Configurar DNS64: Usar BIND o Unbound
Probar aplicaciones: Verificar que tus apps específicas funcionen a través de traducción
Monitorear rendimiento: Medir sobrecarga de latencia y rendimiento
Documentar problemas: Anotar qué apps o servicios tienen problemas
Planificar soluciones: Dual-stack para servicios problemáticos, 464XLAT para otros

Solo después de pruebas exitosas deberías considerar despliegue en producción, y aún así, comienza con redes o segmentos de usuarios no críticos.

NAT64/DNS64 es poderoso pero añade complejidad. Úsalo donde resuelva problemas reales, no porque sea tecnología novedosa.

Preguntas Frecuentes #

¿Necesito NAT64 si tengo dual-stack?

No. Las redes dual-stack no necesitan NAT64 porque existe conectividad tanto IPv4 como IPv6 nativamente. NAT64 es específicamente para redes solo IPv6 accediendo destinos solo IPv4. Si tienes dual-stack, los clientes usan IPv4 para alcanzar servidores IPv4 e IPv6 para alcanzar servidores IPv6 directamente.

¿Puedo usar NAT64 sin DNS64?

Técnicamente sí, pero es impráctico. Sin DNS64, los clientes necesitan construir manualmente direcciones IPv6 sintetizadas embebiendo direcciones IPv4 en el prefijo NAT64. Esto requiere que aplicaciones o usuarios conozcan el prefijo NAT64 y realicen traducción manual. DNS64 automatiza esto, haciendo NAT64 transparente. Siempre despliégalos juntos.

¿Por qué falla mi validación DNSSEC con DNS64?

DNS64 sintetiza registros AAAA que no existen en la zona DNS autoritativa. Estos registros sintéticos no tienen firmas DNSSEC, causando que la validación falle. Puedes deshabilitar validación DNSSEC en el resolvedor DNS64, usar una implementación DNS64 que maneje DNSSEC cuidadosamente (opciones limitadas), o aceptar que dominios solo IPv4 firmados con DNSSEC no validarán. Esta es una limitación conocida sin solución perfecta actualmente.

¿Cuál es la diferencia entre NAT64 y NAT44?

NAT44 traduce IPv4 a IPv4 (cambiando direcciones de origen, como hacen los enrutadores domésticos). NAT64 traduce entre IPv6 e IPv4 (cambiando protocolos completamente). Ambos mantienen estado de sesión y enfrentan problemas similares de agotamiento de puertos. NAT64 es más complejo porque debe convertir formatos de paquete, manejar mapeo de tipo ICMP y lidiar con diferencias MTU entre IPv4 e IPv6.