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.
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.
