Contenido del artículo

Imagina una escena extraña. Abres en tu teléfono un servicio que verifica tu IP, y te muestra una dirección IPv4. Pero si revisas la configuración de la interfaz de red del mismo dispositivo, verás una larga dirección IPv6. ¿Cómo es posible? El dispositivo vive en el mundo IPv6, pero el sitio web en sus registros anota con seguridad cuatro números decimales separados por puntos. ¿Dónde ocurrió el cambio?

No es un error ni magia. Es un sistema de traducción cuidadosamente diseñado que los operadores de telefonía móvil han estado implementando en todo el mundo durante más de una década. Y si trabajas con proxies móviles, scraping, gestión de múltiples cuentas o simplemente quieres entender qué pasa con tu tráfico, es fundamental que comprendas esta mecánica.

En esta guía, recorreremos todo el camino del paquete desde la aplicación en el teléfono hasta el sitio web de destino. Analizaremos 464XLAT por componentes, entenderemos el papel de NAT64 y DNS64, veremos exactamente dónde nace la dirección IPv4 de salida y aprenderemos a diagnosticar la pila de conexión por ti mismo. No es una visión superficial. Es una inmersión profunda para quienes quieren saber no solo qué ocurre, sino cómo y por qué.

Introducción: por qué el teléfono recibe IPv6 pero el sitio ve IPv4

Empecemos con la esencia de la paradoja. Un smartphone moderno en la red móvil de un gran operador casi con certeza está conectado por IPv6. Más aún, a menudo ni siquiera tiene una dirección IPv4 real en la interfaz de radio. El operador simplemente no la asigna. Y esta es una decisión consciente, dictada por la grave escasez de espacio de direcciones.

Pero internet no es homogéneo. Una cantidad enorme de sitios web, API y servicios siguen siendo accesibles solo por IPv4. No tienen un registro AAAA en DNS, sus servidores no escuchan en IPv6. Si el teléfono solo pudiera hablar IPv6, no podría abrir la mitad de internet. Surge una contradicción: el dispositivo habla un nuevo idioma, pero el interlocutor solo entiende el antiguo.

La solución a esta contradicción es el tema principal de nuestra conversación. La tecnología llamada 464XLAT, junto con los mecanismos NAT64 y DNS64, crea un puente invisible. El dispositivo envía paquetes por IPv6, y en algún lugar profundo de la red del operador, esos paquetes se convierten en IPv4 y viajan al servidor de destino con una dirección IPv4 real. El servidor responde, y la ruta de retorno pasa por la misma transformación en orden inverso.

Es por esto que el sitio web de destino ve IPv4. Es por esto que un proxy móvil, construido sobre un teléfono real o un módem de operador, muestra hacia afuera una dirección IPv4, aunque dentro del dispositivo reine IPv6. El cambio no ocurre en el teléfono ni en el sitio. Ocurre en un nodo intermedio de la red del operador llamado PLAT.

Qué aprenderás al leer hasta el final:

  • Cómo es la escasez de direcciones IPv4 y por qué obligó a los operadores a migrar a IPv6
  • Qué son los tipos de APN y en qué se diferencia IPv4v6 de IPv6 puro
  • Cómo funciona 464XLAT paso a paso, dónde reside CLAT y dónde PLAT
  • Cómo NAT64 y DNS64 hacen accesible un sitio sin registro AAAA
  • De dónde proviene la dirección IPv4 de salida de un proxy móvil
  • Cómo happy eyeballs hace que el servicio de verificación muestre a veces IPv4 y a veces IPv6
  • Comandos prácticos para diagnosticar la pila de conexión
  • Por qué la subred /64 se percibe como un solo cliente y qué significa para las cuentas

Acordemos los límites de inmediato. Hablamos exclusivamente de mecánica de red. No discutimos qué es más rentable comprar ni qué protocolo es mejor desde el punto de vista comercial. Esta es una guía de ingeniería, no un análisis de mercado.

Fundamentos: escasez de IPv4, transición a IPv6 y tipos de APN

Para entender toda la estructura, empecemos por los cimientos. Y el cimiento aquí es uno solo: la catastrófica falta de direcciones IPv4.

Por qué se acabó IPv4

El protocolo IPv4 utiliza direcciones de 32 bits. Esto da alrededor de 4.300 millones de combinaciones únicas. En 1981, cuando se estandarizó el protocolo, parecía un número astronómico. ¿Quién podría haber imaginado que habría más dispositivos que personas en el planeta?

La realidad resultó dura. Smartphones, tabletas, relojes inteligentes, refrigeradores, cámaras, automóviles... todo requiere una dirección. A principios de la década de 2010, los registros regionales de internet comenzaron a agotar los bloques libres. Hoy en día, obtener un bloque grande de direcciones IPv4 públicas es prácticamente imposible, y en el mercado secundario se comercializan a decenas de dólares cada una.

Para un operador móvil con decenas de millones de suscriptores, esto es un problema fundamental. Asignar a cada smartphone una dirección IPv4 pública individual no es físicamente realista. Simplemente no hay suficientes direcciones.

Cómo IPv4 resuelve el problema

El protocolo IPv6 utiliza direcciones de 128 bits. La cantidad de combinaciones posibles es tan grande que la mente humana se niega a comprenderla: aproximadamente 340 undecillones de direcciones. En términos simples, se podrían asignar varias direcciones a cada átomo en la superficie de la Tierra y aún sobrarían.

El operador recibe del registrador un enorme bloque de IPv6 y lo distribuye a los suscriptores con un margen colosal. La práctica típica es asignar a cada dispositivo de suscriptor una subred completa /64. Eso son, ni más ni menos, 18 quintillones de direcciones para un solo teléfono. Recuerda este hecho; jugará un papel importante en la sección sobre múltiples cuentas.

Qué es APN y por qué son importantes sus tipos

APN significa Access Point Name, es decir, nombre de punto de acceso. Es un perfil de configuración que le indica al teléfono cómo conectarse a la red de datos del operador. Cuando el smartphone establece la transmisión de datos, solicita a la red la creación de una sesión con un determinado tipo de protocolo.

Existen tres tipos principales de contexto PDN o PDP:

  • IPv4: al dispositivo se le asigna solo una dirección IPv4. Esquema clásico obsoleto. Funciona, pero requiere direcciones que no existen.
  • IPv6: al dispositivo se le asigna solo un prefijo IPv6. No hay ninguna dirección IPv4 en la interfaz. Máximo ahorro para el operador.
  • IPv4v6: pila doble. El dispositivo solicita ambos tipos de direcciones en una misma sesión.

Aquí surge un matiz. Incluso si el teléfono solicita IPv4v6, el operador puede asignar solo la parte IPv6 y denegar la parte IPv4, o asignar una dirección privada mediante un mecanismo de traducción. Muchos operadores grandes están configurados para que el suscriptor reciba por defecto IPv6 puro, y la compatibilidad con internet IPv4 se garantiza mediante la tecnología 464XLAT ya descrita.

Una analogía que ayuda. Imagina que todo el mundo ha adoptado un nuevo idioma de comunicación, pero muchas instituciones antiguas solo aceptan documentos en el idioma antiguo. El Estado no puede entregar a cada ciudadano un pasaporte antiguo individual porque no hay suficientes. Por lo tanto, entrega a todos documentos nuevos y coloca un traductor en la entrada de las instituciones antiguas. Ese traductor es 464XLAT.

Inmersión profunda: 464XLAT por componentes

Ahora estamos listos para diseccionar la tecnología en sí. El nombre 464XLAT se lee four-six-four translation. Los números reflejan la esencia: el paquete comienza su vida como IPv4 dentro de la aplicación, viaja por la red como IPv6 y luego vuelve a ser IPv4 a la salida. XLAT es la abreviatura de translation, traducción.

La base es el estándar de traducción de direcciones entre protocolos descrito en las especificaciones de la IETF. Pero 464XLAT agrega una arquitectura de dos componentes que trabajan en pareja.

CLAT: el traductor en el dispositivo

CLAT significa Customer-side translator, es decir, traductor del lado del cliente. Reside directamente en tu smartphone, integrado en el sistema operativo. En Android, esta función la realiza un demonio especial; en otros sistemas, módulos similares.

La tarea de CLAT es una, pero importante. Cuando una aplicación en el teléfono quiere enviar un paquete por IPv4 – por ejemplo, porque usa un socket IPv4 de manera forzada o se conecta directamente a una dirección IP – CLAT intercepta ese paquete IPv4 y lo encapsula en IPv6. Técnicamente, realiza una traducción de encabezados según un algoritmo de traducción sin estado (stateless), convirtiendo las direcciones IPv4 de origen y destino en direcciones IPv6 correspondientes utilizando un prefijo conocido de antemano.

CLAT crea en el dispositivo una interfaz de red virtual a la que se le asigna una dirección IPv4 privada. Las aplicaciones ven esta dirección y piensan que viven en un entorno IPv4 normal. Ni siquiera sospechan que, bajo el capó, todo se ha mudado a IPv6 hace tiempo.

PLAT: el traductor en la red del operador

PLAT significa Provider-side translator, traductor del lado del proveedor. Es un nodo potente en algún lugar del núcleo de la red del operador que implementa la función NAT64. Aquí ocurre la transformación final.

PLAT recibe los paquetes IPv6 que llegaron del dispositivo y extrae de ellos la información sobre el destino IPv4 original. Luego realiza una traducción con estado (stateful): convierte el paquete IPv6 de vuelta a IPv4, coloca como dirección de origen una de las direcciones IPv4 públicas del operador desde su pool y envía el paquete a la internet IPv4 habitual.

La palabra clave es stateful, es decir, con mantenimiento de estado. PLAT mantiene una tabla de correspondencias para que los paquetes de respuesta del servidor regresen correctamente al dispositivo que inició la conexión. Es, en esencia, el mismo principio que en el NAT clásico, pero entre diferentes protocolos.

Por qué se necesitan dos traductores

Surge la pregunta lógica: ¿para qué sirve CLAT en el dispositivo si PLAT igual va a traducir todo? La respuesta está en las aplicaciones que no saben usar IPv6.

Muchas aplicaciones están escritas con un uso forzado de IPv4. Solicitan sockets IPv4, trabajan con literales de direcciones IPv4, algunos protocolos como implementaciones antiguas transmiten direcciones IP dentro de la carga útil. Si en el dispositivo solo hubiera IPv6 puro, esas aplicaciones simplemente se romperían. CLAT les da la ilusión de un entorno IPv4 completo, permaneciendo invisible.

Por lo tanto, el dúo funciona así: CLAT resuelve el problema de compatibilidad en el dispositivo, PLAT resuelve el problema de compatibilidad en internet. Juntos forman un puente sin fisuras.

NAT64 y DNS64: cómo cobra vida un sitio sin registro AAAA

Ya entendimos la traducción de paquetes. Pero hay otro problema fundamental: ¿cómo sabe el dispositivo a dónde enviar el paquete IPv6 si el sitio web de destino solo existe en el mundo IPv4 y no tiene ningún registro IPv6?

Aquí entra en escena el dúo NAT64 y DNS64. Trabajan en estrecha colaboración y es imposible entender uno sin el otro.

El problema de la falta de registro AAAA

En el sistema de nombres de dominio, las direcciones de diferentes protocolos se almacenan en diferentes tipos de registros. La dirección IPv4 se almacena en un registro tipo A. La dirección IPv6 se almacena en un registro tipo AAAA, que se pronuncia quad-A.

Cuando un dispositivo puramente IPv6 quiere abrir un sitio, solicita al DNS un registro AAAA. Pero si el sitio no tiene infraestructura IPv6, tampoco tiene registro AAAA. Solo tiene un registro A con una dirección IPv4. El dispositivo recibe una respuesta vacía y, en teoría, debería decir: sitio inaccesible. Pero esto no ocurre gracias a DNS64.

Cómo funciona DNS64

DNS64 es un resolvedor DNS especial del operador con una supercapacidad. Cuando el dispositivo solicita un registro AAAA para un dominio y no existe un registro AAAA real, DNS64 no se rinde. Hace lo siguiente:

  1. Solicita al servidor autoritativo el registro A normal y obtiene la dirección IPv4 del sitio
  2. Toma esa dirección IPv4 y sintetiza un registro AAAA artificial
  3. Para la síntesis, incrusta los 32 bits de la dirección IPv4 en un prefijo IPv6 especial
  4. Devuelve este registro AAAA sintetizado al dispositivo como si nada

El dispositivo recibe una dirección IPv6 válida y felizmente envía paquetes hacia ella. No sabe, ni debe saber, que esa dirección es artificial.

El prefijo sintetizado 64:ff9b::/96

Aquí llegamos a uno de los artefactos más reconocibles de todo el sistema. Para sintetizar direcciones, se utiliza un prefijo especialmente reservado 64:ff9b::/96. Se llama Well-Known Prefix, es decir, prefijo bien conocido, y está estandarizado precisamente para la traducción NAT64.

La mecánica es simple y elegante. El prefijo ocupa los primeros 96 bits de la dirección. Los 32 bits restantes son exactamente el tamaño de una dirección IPv4. DNS64 simplemente agrega la dirección IPv4 del sitio al final del prefijo.

Por ejemplo, si el sitio tiene una dirección IPv4 expresada como cuatro números, la dirección IPv6 sintetizada se verá como el prefijo 64:ff9b seguido, en los últimos 32 bits, de esos cuatro números codificados. Cuando ese paquete llega a PLAT, el nodo ve el prefijo conocido, entiende que se trata de una traducción NAT64, extrae los últimos 32 bits y obtiene la dirección IPv4 real de destino. Luego envía un paquete IPv4 normal.

Algunos operadores, en lugar del prefijo bien conocido, utilizan su propio prefijo de red dentro de su espacio de direcciones. La lógica es la misma, solo cambia el valor concreto de los primeros bits.

Cómo funciona el dúo en conjunto

Armemos el rompecabezas. DNS64 se encarga de que el dispositivo reciba una dirección IPv6 para acceder a internet IPv4. NAT64, en la persona de PLAT, se encarga de que el paquete con esa dirección llegue realmente al servidor IPv4. Uno sin el otro es inútil: DNS64 crea una dirección que solo NAT64 sabe procesar, y NAT64 solo procesa las direcciones que DNS64 sintetizó.

¿Y qué pasa con los sitios que tienen un registro AAAA real? Aquí es más simple. DNS64 ve un registro AAAA real y lo entrega sin sintetizar nada. El dispositivo se conecta al sitio directamente por IPv6, sin pasar por toda la maquinaria de traducción. Este es el camino óptimo de extremo a extremo.

El camino del paquete desde la aplicación hasta el sitio con 464XLAT: esquema en palabras

Ha llegado el momento de reunir toda la mecánica en un esquema paso a paso. Sigamos un paquete desde que nace en la aplicación hasta que llega al servidor IPv4 de destino y de regreso. Esta es la ruta que recorre el tráfico de un proxy móvil.

Camino de ida: del teléfono al sitio

  1. Paso 1. La aplicación quiere conectarse. La aplicación en el teléfono decide abrir un sitio que solo tiene IPv4. Consulta al DNS para obtener la dirección.
  2. Paso 2. DNS64 sintetiza la dirección. El resolvedor del operador no encuentra un registro AAAA real, toma el registro A, incrusta la dirección IPv4 en el prefijo 64:ff9b::/96 y devuelve un registro AAAA sintetizado.
  3. Paso 3. La aplicación envía el paquete. Hay dos variantes. Si la aplicación funciona sobre IPv6, envía directamente un paquete IPv6 a la dirección sintetizada. Si la aplicación está fuertemente atada a IPv4, envía un paquete IPv4 a la interfaz virtual de CLAT.
  4. Paso 4. CLAT traduce IPv4 a IPv6. En el caso de una aplicación IPv4, el demonio CLAT intercepta el paquete y, según las reglas de traducción sin estado, lo convierte en un paquete IPv6 utilizando el mismo prefijo NAT64.
  5. Paso 5. El paquete viaja por la red de radio. Ahora es un paquete IPv6 puro. Atraviesa la estación base y el núcleo de la red móvil del operador. Dentro de toda la parte de radio solo vive IPv6.
  6. Paso 6. El paquete llega a PLAT. En el núcleo de la red hay un nodo PLAT con la función NAT64. Ve un paquete con destino que comienza con el prefijo NAT64.
  7. Paso 7. PLAT traduce IPv6 a IPv4. El nodo extrae los últimos 32 bits de la dirección de destino: esa es la dirección IPv4 real del sitio. Luego coloca como origen una dirección IPv4 pública de su pool, registra la correspondencia en la tabla de estados.
  8. Paso 8. El paquete sale a internet. Ahora es un paquete IPv4 normal. Viaja por la red global hacia el servidor de destino.
  9. Paso 9. El sitio ve IPv4. El servidor recibe la conexión desde la dirección IPv4 pública del operador. En sus registros, anota exactamente esa IPv4. Aquí está el momento de la verdad: el sitio nunca sabrá que el paquete nació originalmente en un entorno IPv6.

Camino de regreso: del sitio al teléfono

  1. Paso 10. El servidor responde. El sitio envía un paquete IPv4 de respuesta a la dirección pública que vio.
  2. Paso 11. PLAT encuentra la correspondencia. El nodo NAT64 consulta su tabla de estados, determina a qué dispositivo pertenece la conexión y restaura la dirección IPv6.
  3. Paso 12. Traducción inversa a IPv6. PLAT convierte la respuesta IPv4 en un paquete IPv6 y lo envía a través del núcleo de la red de vuelta al teléfono.
  4. Paso 13. CLAT devuelve IPv4 a la aplicación. Si originalmente la aplicación trabajaba por IPv4, CLAT en el dispositivo traduce la respuesta IPv6 de vuelta a IPv4 y la entrega a la aplicación a través de la interfaz virtual.
  5. Paso 14. La aplicación recibe la respuesta. Para la aplicación, todo se ve como un intercambio IPv4 normal. El círculo se cierra.

Detente un segundo y aprecia la elegancia de esta construcción. El paquete cambió de identidad de protocolo cuatro veces, pasó por dos traductores, y los puntos finales (la aplicación y el sitio) ni siquiera lo sospechan. Cada uno ve solo su mundo IPv4 familiar.

Qué significa todo esto para los proxies: dónde nace la dirección de salida

Ahora apliquemos toda la teoría a la práctica de los proxies móviles. Esta es la sección más importante para quienes trabajan con tráfico.

Dónde nace la dirección de salida

Un proxy móvil es, en esencia, un punto de entrada a la red a través de un dispositivo móvil real o un módem conectado al operador. Cuando diriges tu tráfico a través de ese proxy, sale a internet de la misma manera que lo haría el tráfico desde un teléfono.

Y ya sabemos qué pasa con ese tráfico. Pasa por 464XLAT, llega a PLAT, y allí se le asigna una dirección IPv4 pública del pool del operador. Esa dirección IPv4 de PLAT se convierte en la dirección de salida de tu proxy. No nace en el dispositivo, ni en el módem, sino en el nodo NAT64 en el núcleo de la red del operador.

Por eso la salida móvil suele ser IPv4. El dispositivo mismo vive en IPv6, pero el punto desde donde el tráfico sale a internet global hacia sitios IPv4 es PLAT, que entrega IPv4.

Qué ve finalmente el sitio de destino

El sitio de destino ve la dirección IPv4 pública del operador. Es la dirección de un nodo CGN o NAT64, detrás del cual pueden ocultarse muchos suscriptores. El sitio no ve ni la dirección IPv6 interna del dispositivo ni la IPv4 virtual de la interfaz CLAT. Solo la IPv4 externa de PLAT.

Este es un punto fundamental. Los proxies móviles son valorados porque sus direcciones IPv4 parecen direcciones de suscriptores reales, porque técnicamente lo son. Muchos usuarios reales comparten la misma IPv4 pública a través de un mismo PLAT. Desde el punto de vista del sitio de destino, esa dirección es indistinguible de la de un cliente móvil común.

Cuándo el sitio puede ver IPv6

Pero no siempre la dirección de salida será IPv4. Si el sitio de destino tiene un registro AAAA real y una infraestructura IPv6 completa, el dispositivo se conectará a él directamente por IPv6, sin pasar por PLAT. En ese caso, el sitio verá una dirección IPv6 de la subred asignada al suscriptor por el operador.

Es por esto que un mismo proxy móvil puede entregar a diferentes sitios diferentes tipos de direcciones. Al sitio sin IPv6: una IPv4 pública a través de NAT64. Al sitio con IPv6: una IPv6 real directamente. No es un fallo, sino el comportamiento normal del sistema de pila doble.

Lista de verificación para entender la dirección de salida

  • Dispositivo en red IPv6: sí, casi siempre en los grandes operadores
  • Dirección de salida hacia un sitio IPv4: IPv4 pública del nodo PLAT del operador
  • Dirección de salida hacia un sitio IPv6: IPv6 real de la subred del suscriptor
  • Dónde ocurre la traducción: en PLAT, en el núcleo de la red, no en el dispositivo
  • Qué ve un sitio IPv4: una dirección IPv4 compartida del operador, utilizada por múltiples suscriptores

Pila doble y happy eyeballs: por qué la verificación muestra a veces IPv4 y a veces IPv6

Seguro te ha pasado que un servicio de verificación de IP muestra diferentes direcciones en solicitudes repetidas: a veces IPv4, a veces IPv6. Esto desconcierta. Analicemos por qué ocurre.

Qué es la pila doble

Pila doble significa que el dispositivo posee simultáneamente una dirección IPv4 y una IPv6, y puede usar ambos protocolos. En el entorno móvil, esto se implementa a menudo mediante un APN IPv4v6 o mediante una combinación de IPv6 nativo más CLAT, que proporciona una IPv4 local.

Cuando el cliente tiene la opción de dos protocolos, surge la pregunta: ¿cuál usar para una conexión concreta? Antes, esto se resolvía de manera tosca y provocaba retrasos. Si la ruta IPv6 estaba rota, el navegador esperaba mucho tiempo un tiempo de espera antes de retroceder a IPv4. Los usuarios sufrían cargas lentas.

El algoritmo happy eyeballs

Para resolver este problema, se inventó el algoritmo happy eyeballs, que podría traducirse como ojos felices. Su esencia no es adivinar de antemano qué protocolo es mejor, sino organizar una competencia.

Así funciona en términos generales:

  1. El cliente solicita para el dominio tanto el registro A como el AAAA simultáneamente
  2. Al obtener direcciones de ambos protocolos, comienza a establecer conexiones casi en paralelo
  3. El intento IPv6 suele comenzar primero con una pequeña ventaja de varias decenas o cientos de milisegundos
  4. Si la conexión IPv6 se establece rápido, se usa esa
  5. Si IPv6 se retrasa o no responde, el cliente cambia casi instantáneamente a IPv4
  6. El ganador de la carrera se utiliza para la transmisión de datos; la conexión perdedora se cierra

    7. El algoritmo favorece a IPv6 cuando funciona bien, pero no permite que IPv4 retrase el trabajo si algo sale mal. De ahí el nombre: los ojos permanecen felices porque no hay demoras.

    Por qué la verificación muestra diferentes direcciones

    Ahora está claro de dónde viene la inconstancia. Cuando abres un servicio de verificación de IP, ocurre lo siguiente:

    • Si el servicio tiene registros A y AAAA, se activa happy eyeballs
    • Dependiendo de qué conexión gane la carrera en ese momento concreto, verás ya sea IPv4 o IPv6
    • El estado de la red, la carga, la caché de conexiones: todo influye en el resultado de la carrera
    • En la siguiente solicitud, la carrera puede terminar de otra forma y la dirección cambiará

    Esto no es un error del proxy ni una inestabilidad de la conexión. Es el comportamiento esperado de la pila doble bajo el control de happy eyeballs. Si necesitas un resultado predecible, debes forzar una versión del protocolo: de esto hablamos en la siguiente sección.

    Perspectiva práctica

    Muchos creen erróneamente que un proxy móvil es inestable al ver direcciones que saltan en el servicio de verificación. En realidad, es un comportamiento saludable de una red moderna. Si quieres ver solo la salida IPv4, accede a servicios sin registro AAAA o fuerza IPv4 a nivel de cliente. Entonces la imagen se estabilizará.

    Práctica: cómo ver qué pila tiene tu conexión

    La teoría sin práctica es muerta. Equipémonos con comandos concretos para ver con tus propios ojos lo que sucede con tu conexión. Todas las herramientas son estándar y están disponibles en la mayoría de los sistemas.

    Mirar las direcciones de la interfaz

    Lo primero que debes hacer es ver qué direcciones están asignadas a las interfaces de red. Para IPv6, usa el comando:

    • ip -6 addr: muestra todas las direcciones IPv6 en todas las interfaces
    • ip -4 addr: análogo para IPv4
    • ip addr: muestra todo junto

    Presta atención a los tipos de direcciones. Las direcciones IPv6 globales suelen comenzar con 2000::/3. Las direcciones link-local comienzan con fe80 y no se enrutan hacia afuera. Si ves una IPv6 global, el dispositivo tiene conectividad IPv6 completa. Si también ves una IPv4 privada en una interfaz separada, probablemente sea la interfaz de CLAT.

    Verificar la accesibilidad con ping

    Para comprobar si un protocolo específico funciona, ayuda el ping:

    • ping6 dirección o ping -6 dirección: verifica conectividad por IPv6
    • ping -4 dirección: verifica conectividad por IPv4

    Si el ping por IPv6 a un nodo global funciona, entonces tienes conectividad IPv6 operativa. Si solo funciona IPv4, entonces IPv6 no está configurado o no funciona.

    Forzar el protocolo en curl

    La herramienta más potente para diagnosticar tráfico web es curl con indicadores de selección de protocolo:

    • curl -4 dirección: fuerza el uso solo de IPv4
    • curl -6 dirección: fuerza el uso solo de IPv6
    • curl -v dirección: modo detallado, muestra a qué dirección real te conectaste

    Combinando los indicadores, puedes saber exactamente qué dirección ve el sitio remoto. Envía una solicitud con el indicador -4 a un servicio que devuelva tu IP y verás la salida IPv4 pura. Envía con -6 y verás IPv6, si está disponible. Así separas la influencia de happy eyeballs y ves la imagen real para cada protocolo.

    Prueba en un endpoint solo IPv6

    Un truco especialmente valioso es acceder a un servicio que solo esté disponible por IPv6, sin ningún registro A. Si esa conexión se establece, tienes garantizada conectividad IPv6 nativa, no solo traducción. Si la conexión no funciona ni siquiera forzando -6, entonces no hay salida IPv6 real hacia afuera y toda tu actividad IPv6 gira en torno al prefijo NAT64.

    Escenario práctico de prueba:

    1. Ejecuta curl -6 en un endpoint solo IPv6: verificas conectividad IPv6 nativa
    2. Ejecuta curl -4 en un servicio de detección de IP: ves la IPv4 de salida a través de PLAT
    3. Compara las direcciones: si la IPv6 de salida proviene de la subred del suscriptor y la IPv4 del pool del operador, entonces tienes una pila doble completa con 464XLAT

    Cómo determinar la presencia del prefijo NAT64

    Para saber si tu red usa NAT64, puedes observar las direcciones sintetizadas. Solicita un registro AAAA para un dominio que seguramente no tenga IPv6 y mira la respuesta. Si devuelve una dirección que comienza con 64:ff9b, es una señal clara de que DNS64 y NAT64 están funcionando. Algunos sistemas tienen mecanismos integrados para detectar el prefijo NAT64 que funcionan exactamente así: solicitan un nombre conocido y analizan la estructura de la respuesta.

    Lista de verificación para diagnóstico de pila

    • ip -6 addr: ¿hay IPv6 global?
    • ip -4 addr: ¿hay IPv4 y no es una dirección privada de CLAT?
    • ping -6 a un nodo global: ¿funciona la conectividad IPv6?
    • curl -4 a un servicio de IP: ¿qué IPv4 ve el sitio?
    • curl -6 a un endpoint solo IPv6: ¿hay IPv6 nativo?
    • Solicitud AAAA para un dominio solo IPv4: ¿se ve el prefijo 64:ff9b?

    Compatibilidad: por qué la subred /64 se percibe como un solo cliente

    Pasemos a una pregunta de enorme importancia práctica para quienes trabajan con múltiples cuentas. Se trata de cómo las plataformas ven las conexiones IPv6.

    Por qué algunas plataformas tratan peor a IPv6

    Históricamente, muchas plataformas grandes construyeron sus sistemas antifraude y de reputación de direcciones en torno a IPv4. Las bases de datos acumuladas, los puntajes de reputación, las reglas de limitación de frecuencia: todo estaba ajustado para direcciones de 32 bits. IPv6 llegó después y no todos los sistemas se adaptaron igual de bien.

    También hay una razón estructural. En IPv4, cada dirección es un recurso escaso, detrás del cual suele haber un solo nodo o un nodo detrás de NAT. En IPv6, hay tantas direcciones que un cliente puede cambiar fácilmente su dirección mil veces por hora dentro de su subred. Esto rompe la lógica habitual donde dirección = identificador de cliente.

    Por lo tanto, las plataformas han desarrollado un enfoque especial para IPv6, y entenderlo es crítico.

    Cómo se interpreta la subred /64

    Recuerda lo que dijimos en la sección de fundamentos: el operador asigna a cada suscriptor una subred completa /64. Es una cantidad gigantesca de direcciones para un solo dispositivo.

    Los sistemas de reputación inteligentes lo entienden. En lugar de evaluar cada dirección IPv6 individual, agregan toda la subred /64 y la consideran como un único identificador. La lógica es simple: como toda esta subred pertenece a un solo suscriptor, debe tratarse como un solo cliente.

    Esto significa que cambiar la dirección IPv6 dentro de una misma /64 no crea un nuevo identificador para esas plataformas. Puedes barajar los últimos bits de la dirección todo lo que quieras, pero desde el punto de vista de la plataforma sigue siendo el mismo cliente, porque el prefijo /64 no cambia.

    Qué significa esto para trabajar con múltiples cuentas

    De aquí se desprende una conclusión práctica importante. Si intentas separar cuentas usando diferentes direcciones IPv6 dentro de una misma subred /64, para las plataformas avanzadas parecerán un solo cliente. Diferentes direcciones no proporcionan separación si el prefijo común coincide.

    Compara esto con el comportamiento de IPv4 a través de NAT64. La IPv4 pública del nodo PLAT es compartida por muchos suscriptores diferentes del operador. Desde el punto de vista de la plataforma, detrás de una IPv4 hay decenas de personas reales. Esto da una imagen de mezcla de tráfico completamente diferente.

    Conclusiones clave para la gestión de múltiples cuentas:

    • Cambiar los últimos bits de IPv6 dentro de una misma /64 no cambia el identificador para las plataformas inteligentes
    • La unidad significativa para IPv6 es el prefijo /64, no la dirección individual
    • La separación debe ocurrir a nivel de diferentes subredes /64, no de direcciones dentro de una misma
    • IPv4 a través de NAT64 te mezcla con otros suscriptores del operador, lo que da una dinámica de reputación diferente
    • Siempre entiende qué protocolo se usa realmente para conectarse a una plataforma específica

    Recomendación práctica para controlar el protocolo

    Teniendo todo esto en cuenta, es sensato controlar por qué protocolo va tu conexión con la plataforma de destino. Si sabes con certeza que necesitas una salida IPv4 a través del operador móvil, fuerza IPv4 a nivel de cliente. Así obtendrás garantizadamente la dirección pública compartida de PLAT, no la subred IPv6 vinculada a tu dispositivo.

    Errores típicos al trabajar con IPv6 en redes móviles

    Ahora reunamos en un solo lugar los malentendidos y errores más comunes. Estúdialos con atención: cada uno puede arruinar tu trabajo o llevarte a conclusiones equivocadas.

    Error uno: pensar que una dirección IPv6 en el teléfono significa salida IPv6

    Muchos ven una IPv6 global en la interfaz y concluyen que todo el tráfico va por IPv6. En realidad, el tráfico hacia sitios IPv4 se convierte en IPv4 en PLAT. IPv6 en el dispositivo es el transporte dentro de la red del operador, no una garantía de salida IPv6 hacia un sitio específico.

    Error dos: confundir la dirección de salida con la dirección de la interfaz

    La dirección en la interfaz de red del dispositivo y la dirección que ve el sitio son cosas diferentes. Entre ellas están CLAT y PLAT con traducción y NAT. Nunca juzgues la dirección de salida por lo que muestra ip addr. Siempre verifica con un servicio externo real.

    Error tres: entrar en pánico por direcciones que saltan en la verificación

    Ya analizamos que happy eyeballs hace que la pila doble muestre a veces IPv4 y a veces IPv6. Es normal. No lo consideres una señal de que el proxy está roto. Si necesitas estabilidad, fuerza el protocolo.

    Error cuatro: pensar que cambiar la IPv6 dentro de /64 da un nuevo identificador

    Este es uno de los errores más costosos en la gestión de múltiples cuentas. Las plataformas inteligentes agregan toda la /64. Cambiar los últimos bits de la dirección no tiene sentido para separar cuentas. La unidad significativa es el prefijo.

    Error cinco: ignorar el tipo de APN

    El tipo de APN (IPv4, IPv6 o IPv4v6) determina directamente qué pasará con el tráfico. Sin saber qué tipo se usa, trabajas a ciegas. Siempre averigua la configuración de la sesión.

    Error seis: probar la conectividad solo con un protocolo

    Verificar solo IPv4 o solo IPv6 te da una imagen incompleta. El diagnóstico real requiere probar ambos protocolos por separado con los indicadores -4 y -6, además de acceder a un endpoint solo IPv6.

    Error siete: confundir el prefijo NAT64 con un sitio IPv6 real

    Una dirección sintetizada con el prefijo 64:ff9b parece IPv6, pero detrás hay un servidor IPv4. Si te conectas a esa dirección, en realidad estás yendo a través de NAT64 hacia un servidor IPv4, no comunicándote con un nodo IPv6 real. No saques conclusiones sobre la presencia de IPv6 nativo en un sitio por el hecho de tener una dirección sintetizada.

    Error ocho: pensar que CLAT y PLAT son lo mismo

    CLAT vive en el dispositivo y hace traducción sin estado para las aplicaciones. PLAT vive en la red del operador y hace traducción con estado con NAT. Son componentes diferentes con tareas diferentes. Confundirlos impide entender dónde nace exactamente la dirección de salida.

    Herramientas y recursos para trabajar con la pila de protocolos

    Reunamos un arsenal de herramientas que te ayudarán a diagnosticar y entender la pila de red en el entorno móvil. Todas son estándar y no requieren exotismos.

    Línea de comandos

    • ip addr y sus variantes ip -4 addr, ip -6 addr: herramienta básica para ver direcciones de interfaces
    • ping y ping6: verificar conectividad por un protocolo específico
    • curl con indicadores -4 y -6: la herramienta principal para diagnosticar conexiones web y verificar la dirección de salida
    • traceroute y traceroute6: trazar la ruta, ayuda a ver por qué nodos pasa el tráfico
    • dig y nslookup: consultas DNS para verificar registros A y AAAA, detectar direcciones sintetizadas
    • ip route: ver la tabla de enrutamiento para ambos protocolos

    Servicios en línea de verificación

    • Servicios de detección de IP externa: muestran lo que ve el sitio remoto
    • Endpoints de prueba solo IPv6: verifican la presencia de conectividad IPv6 nativa
    • Servicios que muestran por separado IPv4 e IPv6: ayudan a ver la pila doble
    • Herramientas para verificar el soporte IPv6 de un dominio: muestran si tiene registro AAAA

    Diagnóstico de DNS

    Las consultas DNS ayudan a entender si DNS64 está funcionando. Solicita un registro AAAA para un dominio que no tenga IPv6 y mira la estructura de la respuesta. La presencia del prefijo 64:ff9b delata el trabajo de síntesis. Esta es la forma más directa de confirmar la presencia del mecanismo NAT64 en la red.

    Marco de diagnóstico sistémico de la pila

    Propongo un marco paso a paso que deberías ejecutar al conocer cualquier red móvil nueva:

    1. Inventario de direcciones. Ejecuta ip addr, determina la presencia de IPv6 global y la naturaleza de la IPv4
    2. Identificación de CLAT. Busca una interfaz virtual con IPv4 privada: es señal de 464XLAT
    3. Verificación de NAT64. Solicita AAAA para un dominio solo IPv4, busca el prefijo 64:ff9b
    4. Prueba de IPv6 nativo. curl -6 a un endpoint solo IPv6
    5. Determinación de la IPv4 de salida. curl -4 a un servicio de detección de IP
    6. Determinación de la IPv6 de salida. curl -6 a un servicio que soporte IPv6
    7. Análisis del comportamiento de pila doble. Solicitud normal sin forzar protocolo, observación de happy eyeballs

    Al completar los siete pasos, obtendrás una imagen exhaustiva: qué tipo de conectividad tiene la red, si funciona la traducción, qué direcciones ven diferentes tipos de sitios y cómo se comporta la pila doble. Este es tu auditoría estándar.

    Casos y resultados: análisis de escenarios reales

    La mecánica abstracta se asimila mejor con ejemplos concretos. Analicemos varios escenarios típicos que se encuentran en la práctica.

    Caso uno: el sitio ve en sus registros una misma IPv4 para muchos clientes

    Situación. Un analista revisa los registros de un sitio y nota que desde una misma dirección IPv4 llega una enorme cantidad de usuarios diferentes con comportamientos distintos. El primer pensamiento: es un proxy o una botnet.

    Análisis. En realidad, se trata de la clásica IPv4 pública de un nodo NAT64 o CGN de un gran operador móvil. Detrás de esa dirección realmente hay decenas y cientos de suscriptores reales. Su tráfico sale a través de un mismo PLAT. No es una anomalía, sino el funcionamiento normal de 464XLAT en condiciones de escasez de IPv4.

    Conclusión. Evaluar a los clientes móviles solo por su dirección IPv4 no es efectivo. Una dirección no equivale a un usuario en el entorno móvil. Esta característica es la que hace que las direcciones IPv4 móviles sean tan distintivas: alta densidad de usuarios reales detrás de una misma dirección.

    Caso dos: respuesta inconsistente del servicio de verificación

    Situación. Un operador de proxy móvil se queja de que el servicio de verificación de IP muestra a veces IPv4 y a veces IPv6, y concluye que el proxy es inestable.

    Análisis. El servicio de verificación tiene registros A y AAAA. El cliente opera en pila doble. Cada solicitud ejecuta happy eyeballs y, según el resultado de la carrera de conexiones, se devuelve un tipo de dirección diferente. El proxy funciona perfectamente estable; solo cambia el protocolo seleccionado por el algoritmo.

    Solución. Forzar el protocolo con curl -4 o configuraciones de cliente correspondientes. Al fijar IPv4, la dirección se volvió predecible. El problema de inestabilidad resultó ser imaginario.

    Caso tres: cuentas vinculadas a pesar de usar diferentes IPv6

    Situación. Trabajo con múltiples cuentas a través de IPv6, a cada cuenta se le asigna una dirección IPv6 diferente. Sin embargo, la plataforma relaciona las cuentas entre sí.

    Análisis. Todas las direcciones asignadas estaban dentro de una misma subred /64, asignada por el operador al dispositivo. Un sistema de reputación avanzado agregó toda la /64 y la trató como un solo identificador. Diferentes direcciones dentro del mismo prefijo no proporcionaron ninguna separación.

    Conclusión. Para IPv6, la unidad significativa es el prefijo /64, no la dirección individual. La separación requiere diferentes prefijos. En este caso, era más sensato trabajar a través de la salida IPv4 de NAT64, donde el tráfico se mezcla con otros suscriptores del operador.

    Caso cuatro: una aplicación que no sabe usar IPv6

    Situación. Una aplicación antigua se conecta directamente a un literal IPv4 y debería romperse en una red solo IPv6. Pero funciona.

    Análisis. En el dispositivo está funcionando CLAT. La aplicación envía un paquete IPv4 a la interfaz virtual, CLAT lo traduce a IPv6, luego el paquete pasa por PLAT hacia internet IPv4. La aplicación vive en la ilusión de un IPv4 completo y no sospecha que hay traducción. Esta es exactamente la tarea para la que existe CLAT.

    Conclusión. 464XLAT garantiza la compatibilidad con aplicaciones heredadas de forma transparente. Es por eso que la migración de los operadores a IPv6 no rompió el ecosistema de software IPv4.

    Preguntas frecuentes

    ¿Por qué mi teléfono muestra IPv6 pero el sitio web registra IPv4?

    Porque el cambio ocurre en el nodo PLAT en el núcleo de la red del operador. El dispositivo envía tráfico por IPv6, pero al salir hacia un sitio IPv4, el nodo NAT64 traduce el paquete a IPv4 y coloca una dirección pública del operador. El sitio ve esa IPv4 de salida, no la IPv6 interna del dispositivo.

    ¿Qué es el prefijo 64:ff9b y de dónde viene?

    Es un prefijo bien conocido y estandarizado para la traducción NAT64. DNS64 lo utiliza para sintetizar direcciones IPv6 artificiales a partir de direcciones IPv4 de sitios sin registro AAAA. Los últimos 32 bits de esa dirección contienen la IPv4 real que PLAT extrae al traducir.

    ¿Cuál es la diferencia entre CLAT y PLAT?

    CLAT funciona en el dispositivo y realiza traducción sin estado de IPv4 a IPv6 para las aplicaciones que necesitan IPv4. PLAT funciona en la red del operador y realiza traducción con estado de IPv6 a IPv4 con NAT, colocando una dirección pública. CLAT resuelve la compatibilidad en el dispositivo; PLAT, la compatibilidad con internet IPv4.

    ¿Por qué el servicio de verificación de IP muestra diferentes direcciones al actualizar?

    Debido al algoritmo happy eyeballs en un entorno de pila doble. Si el servicio de verificación está disponible tanto por IPv4 como por IPv6, el cliente inicia una carrera de conexiones y en diferentes momentos gana un protocolo diferente. Es un comportamiento normal, no un fallo. Fuerza el protocolo con un indicador para obtener un resultado estable.

    ¿Cómo saber si tengo una salida IPv6 real y no solo NAT64?

    Accede a un endpoint que solo esté disponible por IPv6 usando el comando curl -6. Si la conexión se establece, tienes conectividad IPv6 nativa. Si no funciona ni siquiera forzando -6, entonces no hay salida IPv6 real y toda la actividad IPv6 gira en torno al prefijo NAT64 sintetizado.

    ¿Por qué cambiar la dirección IPv6 no ayuda a separar cuentas?

    Porque el operador asigna al dispositivo una subred completa /64, y las plataformas avanzadas agregan toda esa subred como un único identificador. Cambiar los últimos bits de la dirección no altera el prefijo, por lo que para la plataforma sigue siendo el mismo cliente. La unidad significativa es la /64, no la dirección individual.

    ¿Por qué un proxy móvil suele tener una IPv4 de salida y no una IPv6?

    Porque la mayoría de los sitios de destino no tienen infraestructura IPv6, y el tráfico hacia ellos pasa por NAT64. El nodo PLAT traduce los paquetes a IPv4 y asigna una dirección pública del operador. Esa dirección se convierte en la de salida. Hacia sitios con un registro AAAA real, el proxy puede salir directamente por IPv6.

    ¿Cómo forzar a un cliente a usar una versión específica del protocolo?

    A nivel de curl, usa los indicadores -4 para IPv4 y -6 para IPv6. Muchas aplicaciones y bibliotecas tienen configuraciones similares de preferencia de protocolo. También se puede gestionar a través de la configuración del sistema de prioridad de políticas de direcciones. Esto desactiva la no determinación de happy eyeballs y proporciona una salida predecible.

    ¿Qué ve el sitio de destino cuando se conecta a través de una red móvil?

    Si el sitio solo tiene IPv4, ve la dirección IPv4 pública del nodo NAT64 del operador, compartida por muchos suscriptores. Si el sitio tiene IPv6 real, ve una dirección IPv6 de la subred asignada al suscriptor. El sitio nunca ve las direcciones internas del dispositivo ni la dirección virtual de CLAT.

    ¿El tipo de APN influye en qué dirección ve el sitio?

    Indirectamente, sí. El tipo de APN determina qué protocolos están disponibles para el dispositivo. Con IPv4v6 o IPv6 puro con CLAT, funciona toda la mecánica de traducción descrita. Con un APN IPv4 puro, la traducción no es necesaria, pero esa opción es rara en los grandes operadores debido a la escasez de direcciones.

    Conclusión: lo principal sobre la mecánica de IPv6 en redes móviles

    Hemos recorrido un largo camino. Empezamos con el enigma – el teléfono en IPv6, pero el sitio ve IPv4 – y lo resolvimos por completo. Repasemos las conclusiones clave.

    Primero y principal. La escasez de direcciones IPv4 obligó a los operadores a migrar a IPv6. Los dispositivos viven en un entorno IPv6, a menudo sin ninguna IPv4 pública en la interfaz de radio. La compatibilidad con la vieja internet IPv4 la proporciona la tecnología 464XLAT.

    Segundo. 464XLAT consta de dos traductores. CLAT en el dispositivo convierte el tráfico IPv4 de las aplicaciones en IPv6. PLAT en la red del operador convierte IPv6 de vuelta a IPv4 y asigna una dirección pública. Es en PLAT donde nace la dirección IPv4 de salida que ve el sitio.

    Tercero. NAT64 y DNS64 trabajan en pareja. DNS64 sintetiza direcciones IPv6 a partir de IPv4 para sitios sin registro AAAA, usando el prefijo 64:ff9b. NAT64, en la persona de PLAT, entrega los paquetes a esas direcciones hasta los servidores IPv4 reales. Juntos hacen que todo internet IPv4 sea accesible para un dispositivo puramente IPv6.

    Cuarto. La pila doble y happy eyeballs explican por qué la verificación muestra a veces un protocolo y a veces otro. El cliente organiza una carrera de conexiones y elige al ganador. Para estabilidad, fuerza el protocolo con los indicadores -4 o -6.

    Quinto. Para la gestión de múltiples cuentas es crítico entender que la subred /64 es percibida por las plataformas inteligentes como un solo cliente. Cambiar la dirección dentro de una misma /64 es inútil para la separación. IPv4 a través de NAT64, por el contrario, te mezcla con otros suscriptores del operador.

    ¿Cuáles son los siguientes pasos? Acostúmbrate a realizar un diagnóstico sistémico de la pila en cualquier red móvil nueva siguiendo nuestro marco de siete pasos. Domina curl con los indicadores -4 y -6 como herramienta principal. Siempre verifica la dirección de salida en un servicio externo real, no en la interfaz del dispositivo. Y ten presente la diferencia entre dónde vive el dispositivo y desde dónde sale realmente el tráfico a internet.

    Comprender esta mecánica te transforma de un usuario que se pregunta por las direcciones que saltan a un ingeniero que sabe exactamente qué sucede con cada paquete. Y el conocimiento, como sabemos, es control. Que este artículo se convierta en tu guía de consulta sobre el funcionamiento de IPv6 en redes móviles. Vuelve a él cada vez que te enfrentes a otro enigma de red, y dejará de ser un enigma.

    Sobre el autor

    Andrey Kokh

    Andrey Kokh

    Leading Expert and Business Consultant

    Experiencia laboral: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
    Formación académica: Higher School of Economics. Faculty of Economics, Master's Program
    Especialización:
    Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

    Comparte el artículo: