Gracias por la respuesta y por aclarar la situación real de la fase beta.
Entiendo perfectamente la opción del túnel 6in4 y probablemente recurra a Hurricane Electric de momento para salir del paso, pero me gustaría destacar que la falta de IPv6 nativo en el mercado residencial ya no es solo un inconveniente para desarrolladores o entornos de pruebas aislados.
Hoy en día, las arquitecturas modernas de hogar inteligente (Smart Home) y el nuevo estándar de la industria, Matter (que funciona sobre Thread y redes Wi-Fi locales), dependen intrínsecamente de IPv6 para el direccionamiento y la comunicación nativa entre dispositivos. Depender de túneles externos para estas infraestructuras añade latencia, problemas con el tráfico multicast/mDNS local y una complejidad innecesaria para tecnologías de consumo que ya están en la calle.
Es una lástima que el despliegue en la red fija esté tan estancado por la incompatibilidad de los routers antiguos (CPE) de la base general de clientes. Ojalá Movistar se plantee a corto plazo permitir la activación de Dual-Stack bajo petición (u opt-in) para aquellos usuarios que sí disponemos de equipamiento propio compatible o gestionamos nuestra propia red.
Un saludo y gracias de nuevo por la información.
Buenas jumager
Eventualmente, imagino y espero, que exista una opción como dices de opt-in para aquellos que sepan realmente lo que quieren hacer, eso por descontando.
No obstante, sobre lo que dices del hogar inteligente, difiero enormemente en lo que comentas, es más, IPv6 en entornos doméstico no es nada aconsejable, es contraproducente, y no afecta absolutamente (las IPv6 globales) a Thread/Matter. Una cosa es tener una conectividad global IPv6, otra totalmente diferente que no se pueda usar IPv6 en local.
1º. Actualmente, todos los HGU de Movistar levantan IPv6 en local, cualquier dispositivo en la red puede comunicarse con otro por medio de IPv6 tanto con ULA como por LinkLocal. Es decir... que cualquier dispositivo WIFI Matter funcionará perfectamente con independencia de que el Router asigne o no IPv6 globales
2º. En Thread es más de lo mismo, con independencia de tener el TBR,
3º. Con IPv6 Dual Stack en el Router, toda la red puede recibir IPv6 globales, y esto que suena bonito, puede ser un enorme problema si no se tiene en cuenta gran cantidad de matices:
a) La seguridad ya no recae en el Router, sino en el dispositivo. Para un PC o dispositivo moderno con FW configurable OK, para dispositivos domóticos o sabe dios de que padre y madre, te puedes ver rápidamente con dispositivos expuestos totalmente a Internet sin la seguridad de NAT... sí, NAT no se creó para dar seguridad, pero implícitamente lo hace
b) Lo anterior implica no solo problemas importantes de seguridad y privacidad, sino un aumento importante en el consumo de batería, empezando por móviles y tablets cuando estos están expuestos y no existe una contramedida. Tanto en la red de datos donde Movistar ya usa IPv6, como conectado por WIFI con Dual Stack real, sin un FW real en el dispositivo (cosa que a menos que uses Root en Android o JB en iOS no puedes tener), la batería va a sufrir. Ejemplo simple de esto usando el APN normal de Movistar (que tiene IPv6 habilitado)
ping -6 2a02:9130:...
Haciendo ping a 2a02:9130:... con 32 bytes de datos:
Respuesta desde 2a02:9130:...: tiempo=159ms
Respuesta desde 2a02:9130:...: tiempo=23ms
Respuesta desde 2a02:9130:...: tiempo=45ms
Respuesta desde 2a02:9130:...: tiempo=159ms
nmap -6 2a02:9130...
Starting Nmap 7.98 ( https://nmap.org ) at 2026-06-07 20:02 +0200
Nmap scan report for 2a02-9130....
Host is up (0.030s latency).
Not shown: 1000 closed tcp ports (reset)
C) La única forma de evitar lo anterior es un Firewall aplicado a nivel de Router, que en esencia hace la función indirecta de seguridad que hace NAT, generalmente bloqueando cualquier conexión IPv6 externa no solicitada. No obstante esto también provocar que para cualquier conexión externa tengamos que abrir el Firewall para un puerto/IP concreta. Pero el problema real no es esto, esto puede implementarse bien, el problema es que una enorme cantidad de Router actuales no permiten habilitar dicho Firewall para IPv6, o está activado por defecto y no permite crear reglas a mano para crear "agujeros", o crean otros problemas, sin contar ya con las redes móviles por supuesto, donde ni siquiera tienes control.
El uso de túneles como lo que te he aconsejado no afecta absolutamente en nada en lo tocante a la domótica/IoT si se usa IP4 pelado y mondado. Sí puede afectar si se realizan conexiones IPv6 a los servidores remotos, pero no hay motivo para ello, no es necesario, pueden seguir usando IPv4 sin ningún problema.
Obviamente IPv6 es el futuro... y eso se lleva diciendo ya no años, sino décadas. Y la gran realidad es que seguimos en un punto donde no hay demasiada voluntad por parte de nadie... todos dan por sentado que el otro es quien tiene que implementar medidas para que todo funcione perfectamente. No es que IPv6 sea malo ni mucho menos, el problema es el cambio de paradigma que supone, un cambio de mentalidad que la inmensa mayoría no comprende bien y de sus repercusiones. Repito, no porque IPv6 falle o tenga un problema, sino porque el usuario medio generalmente desconoce el peligro subyacente, donde la seguridad ahora recae realmente en el propio dispositivo, dispositivos que a día de hoy (sobre todo domóticos, móviles y otros) tienen aun un largo camino que recorrer si quieren que sea entornos "seguros".
Saludos.
PD: Tengo IPv6 deshabilitado en el APN de mis terminales y te aseguro que no es por gusto, y eso que mis dispositivos portátiles todos están con Root y con FW reales que permiten únicamente el acceso a Internet a aplicaciones concretas... pues aun así. Y en la red fija, que sí me apunté hace años a la Beta, uso principalmente mi propio Router configurado al más mínimo detalle para evitar problemas potenciales. Mi Router si lo puedo controlar y manejar, no puedo hacer eso con la red móvil. Futuro sí, inmediato... no, y además es un dardo envenenado.
Tienes toda la razón en cuanto a Matter; admito que fue un mal argumento por mi parte, ya que efectivamente opera con direccionamiento local (ULA/Link-Local) y no necesita salida global.
Sin embargo, mi escenario no es el de un usuario residencial común que busca seguridad perimetral clásica. Soy un firme defensor de la arquitectura **Zero Trust**. Para mí, el concepto de que el router actúe como un "muro" y el uso de NAT como seguridad es un paradigma obsoleto. En mi red, la seguridad recae al 100% en el host y en el cifrado de extremo a extremo (mTLS, SSH con llaves criptográficas, HTTPS robusto).
Mi necesidad de IPv6 real (GUA) se debe a que gestiono una infraestructura híbrida y multi-sitio: cuento con servidores en la nube (VMs) y otra residencia principal en Alemania donde disfruto de IPv6 nativo desde hace años.
El problema de no tener IPv6 nativo con Movistar es el siguiente:
1. **Rompe el principio End-to-End:** NAT me obliga a realizar mapeos de puertos complejos o a depender de proxies inversos centralizados en IPv4, creando cuellos de botella artificiales entre mis nodos de Alemania, la nube y España.
2. **Despliegue de Docker y Caddy (vía DNS Challenge):** Utilizo la validación DNS-01 para mis certificados de Caddy, lo que me permite mantener el puerto 80 totalmente cerrado a internet y protegido de escaneos masivos. Con IPv6 global, puedo asignar una IP pública única a contenedores específicos. Así puedo exponer directamente solo el puerto 443 o SSH en hosts aislados, eliminando la necesidad de un proxy inverso central que multiplexe el tráfico IPv4 y evitando conflictos de puertos.
3. **Rendimiento:** El uso de túneles 6in4 (como Hurricane Electric) introduce una latencia añadida que degrada el rendimiento de la sincronización de mis servicios en producción.
Entiendo perfectamente el riesgo del "usuario medio" y los escaneos de puertos que mencionas con nmap (el tema del consumo de batería por mDNS/solicitudes de vecino es real si el firewall del dispositivo está mal configurado). Pero precisamente por eso, los usuarios avanzados que asumimos la seguridad en el endpoint deberíamos tener una opción de *opt-in* para activar Dual-Stack nativo.
Un saludo y gracias por el debate técnico, da gusto hablar con gente que domina el tema.
Hola jumager
Agradecemos a Theliel por su aporte.
No hemos vuelto a recibir más respuesta por tu parte. ¿Nos puedes confirmar si con la información proporcionada por Theliel se ha resuelto tu consulta? De ser así, ¿te podemos ayudar en algo más? Por otro lado si no tienes ninguna consulta adicional, te agradeceríamos que puedas dar por finalizado este hilo, para cerrarlo, pincha en el botón “Marcar como solución” del post.
Quedamos atentos a tu respuesta.
Un saludo.
Dayana.
Theliel hizo una excelente contribución a la discusión; sin embargo, eso no ha cambiado mi deseo de tener IPv6 nativo en mi conexión. La única solución provisional hasta ahora es iniciar sesión remotamente desde otra computadora. Eso es casi absurdo, la verdad.
Buenas jumager
A ver, como es natural no podemos ni mucho menos depender de NAT como un muro, simplemente es un efecto secundario de la, hasta ahora, necesidad de NAT. El problema es que NAT se ha convertido de facto para la inmensa mayoría de fabricantes precisamente como una medida de seguridad, haciendo que les importe poco o nada que los dispositivos se expongan a Internet. El problema no son dispositivos que hasta cierto punto podemos controlar, sino los que no. En mi móvil puedo permitirme hacer root y tener un FW real que permite o no permite el tráfico, en PCs, NAS... perfecto. El problema llega precisamente cuando conectas dispositivos mucho más ópacos, pero incluso un móvil/tablet como digo a menos que sea con root/JB tampoco tienes control sobre él. El problema aquí no recae en en criptografía, que realmente ya a día de hoy es casi obligado y directo, sino a la exposición de dichos dispositivos a Internet, exploits y otros, dispositivos que como digo no podemos controlar, sobre todo tipo domóticos/IoT.
Respecto a los 3 puntos que comentas, obviamente no es lo mismo el rendimiento de una doble pila real a un túnel, aunque sea bueno, no estará nunca a la altura, no puede competir. Como te decía vale para pruebas, afinar todo y prepararlo todo, dependiendo ya de a que nivel se quiera hacer el despliegue, puede o no ser adecuado.
Evitar proxy inverso con IPv6? Sí, totalmente, tienes que seguir bregando de todos modos con el FW, pero es cierto que puedes exponer directamente el mismo puerto sin proxy inverso o sin usar mapeos de puertos externos arbitrarios. Pero esto no sale gratis, y aquí entraríamos ya a que tipo de uso o servicio se está dirigiendo uno, que es donde veo más problema en dicho planteamiento, no porque sea erróneo.
Me explico, si es para uso relativamente particular (amigos, familia, conocidos...) el uso de un proxy inverso o mapeos de puertos externos altos, es personalmente la mejor opción, no es muy elegante pero es totalmente funcional, universal, y por lo general cero problemas. Para este escenario es totalmente indiferente que para acceder a SSH use el puerto 22 o el 45622, sea el 443 o sea el 30443. Si el enfoque es más empresa/pyme/global, una solución IPv6 es mucho más amigable y limpia, por descontado... pero dejas fuera cualquier red que no sea IPv6te das de bruces entonces con que automáticamente vas a dejar fuera un % importante que no tienen conectividad IPv6.
Es decir... que se entra en una paradoja un tanto peculiar. Desde el punto de vista de un entorno totalmente controlado y no muy abierto IPv6 es perfecto y no vas a tener problemas... pero es precisamente este entorno en el que una solución con IPv4 y mucho menos elegante no causa el mayor problema. Por otro lado, desde el punto de vista de un entorno más "global" pasa al contrario, la solución es mucho más bonita dejando fuera IPv4, lo cual no es muy factible. No sé si me explico correctamente... vamos, que sobre el papel lo que debería de ser la forma más limpia y correcta de forma global no puede hacerse porque dejas fuera a media humanidad, incluso a ti mismo si conectas desde ubicaciones o líneas que no son IPv4.
IPv6 es ineludible, esto no es muy discutible... pero esa realidad choca de bruces con la otra, y es que hasta que todo el mundo no sea doble pila (o túneles u otros), el "purismo" tecnológico se pierde por desgracia con la necesidad de compatibilidad. Pero es que la propia Beta está en ese punto, no pasó mucho tiempo que los problemas empezasen a multiplicarse como la espuma... incluso varios de los HGU que ahora mismo hay rondando no están preparados de forma adecuada para entornos IPv6 (no quiere decir que no funcionen, es diferente).
Y sí... llevo mucho tiempo diciendo por aquí que espero en algún momento que permitan como digo desde la App o panel de control la posibilidad bajo responsabilidad propia le habilitarlo o no, pero imagino que no lo deben de tener nada nada nada claro. La red de Movistar por otro lado funciona perfectamente desde hace tiempo, ese escollo lo solucionaron hace ya 2-3 años por lo menos, no tengo datos, pero en mi experiencia, que la red ipv6 de Movistar es casi al 100% funcional. Otra cosa totalmente diferente son los 1001 problemas que hace que emergen, pero casi todos ellos debido a dispositivos finales, Router propios de muchos, y los propios equipos de Movistar tb.
Saludos compañero. Y ya te digo, soy el primero que sigue abogando por, en algún momento, ver esa posibilidad, aunque sea con un enorme warning en rojo.
