IPv6 es una de esas cosas que en homelab divide bastante. Hay quien lo activa y lo trata como una evolución natural. Hay quien lo desactiva en todas partes porque una vez le rompió algo raro y desde entonces lo mira como si fuese culpa del universo. Los dos bandos tienen algo de razón y algo de trauma.
Mi postura es bastante pragmática: IPv6 merece entenderse, pero no lo activaría a ciegas en una casa donde ya tengo servicios críticos, DNS interno, VPN, firewall, IoT y varios cacharros que no siempre se comportan como deberían.
No porque IPv6 sea malo. No lo es. De hecho, cuando está bien diseñado, muchas cosas son más limpias que en IPv4. El problema es que en una red doméstica real solemos tener una mezcla preciosa de routers de operadora, switches gestionables, puntos WiFi, dispositivos IoT, servidores, contenedores, VPNs y aplicaciones que fueron pensadas con una mentalidad IPv4 muy cómoda.
Y ahí IPv6 no perdona tanto las suposiciones.
Lo primero: IPv6 no es “IPv4 con números más largos”#
La trampa mental es pensar que IPv6 es lo mismo que IPv4, pero con direcciones horribles. No. Cambian varias ideas importantes.
En IPv4 doméstico solemos vivir detrás de NAT. Los dispositivos tienen direcciones privadas, como 192.168.1.x, y el router traduce hacia fuera. Eso crea una falsa sensación de seguridad. Falsa, pero útil: por defecto, desde internet no se puede entrar directamente a cada dispositivo.
En IPv6, lo normal es que cada dispositivo tenga una dirección global enrutable. Eso no significa que quede abierto. El firewall sigue mandando. Pero desaparece esa manta psicológica llamada NAT. Si el firewall está mal, el dispositivo puede estar más expuesto de lo que esperabas.
También cambia la forma de recibir direcciones. En IPv4 piensas en DHCP casi siempre. En IPv6 entran Router Advertisements, SLAAC, DHCPv6, prefijos delegados, direcciones temporales y direcciones link-local. Todo tiene sentido, pero no si lo activas un martes por la noche y esperas que se comporte como tu LAN de siempre.
Por eso mi primer consejo sería aburrido: antes de activar IPv6 en toda la red, entiende cómo lo entrega tu operador y cómo lo maneja tu firewall.
Cuándo sí me interesa IPv6 en casa#
Hay escenarios donde IPv6 tiene sentido claro.
El primero es aprendizaje. Si tienes homelab, tarde o temprano deberías entender IPv6. Internet se mueve hacia ahí aunque llevemos años diciendo “ya casi”. Saber diagnosticarlo es útil. Saber cuándo está rompiendo algo también.
El segundo es evitar capas raras de NAT. Si tu conexión vive detrás de CG-NAT en IPv4, IPv6 puede darte conectividad directa real. Para algunos servicios, laboratorios y accesos remotos, esto cambia mucho. No siempre elimina la necesidad de VPN o túneles, pero abre opciones.
El tercero es tener una red más limpia para ciertos casos. Sin NAT, cada host puede tener identidad propia. Los servicios pueden ser accesibles con reglas claras de firewall. Las conexiones entrantes y salientes dejan de depender de traducciones.
El cuarto es probar servicios modernos tal como van a vivir fuera. Si trabajas con redes, servidores o Kubernetes, ignorar IPv6 eternamente es mala idea. Muchas piezas ya lo soportan y algunas infraestructuras lo esperan.
Pero que algo sea útil no significa que tenga que tocar toda la casa desde el minuto uno.
Cuándo lo dejaría quieto#
No activaría IPv6 a lo bruto si mi red actual ya es frágil. Si el DNS interno está cogido con pinzas, si no tengo claro qué reglas de firewall existen, si hay servicios familiares importantes sin backup o si cada cambio de red acaba en una tarde de pequeñas averías, IPv6 puede esperar.
Tampoco lo activaría si el router de la operadora lo implementa de forma opaca y no puedo controlar bien firewall, prefijos o delegación. Algunas operadoras lo hacen bien. Otras lo hacen de aquella manera. Y en homelab, “de aquella manera” suele significar que terminarás depurando comportamientos raros sin documentación decente.
Me daría especial respeto en redes con mucho IoT barato. No porque IPv6 sea peor para IoT, sino porque muchos dispositivos baratos ya son dudosos en IPv4. Darles una dirección global sin revisar reglas de firewall no mejora mi tranquilidad.
También sería prudente si dependo mucho de split DNS, reverse proxies internos y certificados. Todo puede funcionar con IPv6, claro. Pero hay que comprobarlo. No asumirlo.
El firewall pasa a ser todavía más importante#
Con IPv6, el firewall doméstico deja de ser una pieza “buena idea” y pasa a ser obligatorio. Quiero reglas claras para tráfico entrante desde internet. Por defecto, bloqueo. Luego abro solo lo que necesito.
Esto es lo que revisaría:
- Política entrante desde WAN hacia redes internas.
- Reglas entre VLANs si las tengo.
- Exposición de servidores.
- Acceso a dispositivos IoT.
- Tráfico ICMPv6.
- Logs de bloqueos relevantes.
ICMPv6 merece mención aparte. En IPv4 mucha gente bloquea ICMP por costumbre, a veces sin pensarlo. En IPv6, romper ICMPv6 rompe cosas importantes como descubrimiento de vecinos y Path MTU Discovery. No lo bloquearía a lo bruto. Filtraría con cabeza.
La regla mental es sencilla: IPv6 no necesita miedo, necesita firewall bien entendido.
Si no sé responder qué entra desde internet hacia mi LAN por IPv6, no estoy listo. Y si el panel del router no me deja verlo con claridad, menos todavía.
DNS: donde empiezan las confusiones#
El DNS en dual stack puede dar sorpresas. Un nombre puede resolver a IPv4, a IPv6 o a ambos. El cliente decide qué usar. Y de pronto algo que creías que iba por IPv4 intenta salir por IPv6.
Esto explica muchos “no funciona” raros. El servicio está vivo en IPv4, pero el cliente prefiere IPv6. O el DNS publica un registro AAAA que apunta a una dirección vieja. O el reverse proxy escucha en IPv4 pero no en IPv6. O el firewall permite una familia de direcciones y bloquea la otra.
En una casa con homelab, yo haría pruebas muy concretas:
- Resolver nombres internos y externos.
- Comprobar si hay registros AAAA.
- Probar acceso desde móvil, portátil y servidor.
- Ver qué ruta se usa realmente.
- Confirmar que el proxy escucha donde debe.
- Revisar certificados si el nombre expuesto cambia.
También evitaría publicar AAAA externos hasta tener claro qué servicio quiero exponer. Tener IPv6 no obliga a anunciar todo por IPv6. Puedes ir por fases.
Privacidad y direcciones temporales#
IPv6 tiene otra rareza para quien viene de IPv4 doméstico: las direcciones pueden ser estables, temporales o generadas de varias formas. Los sistemas modernos suelen usar direcciones temporales para conexiones salientes, lo que ayuda a no exponer siempre el mismo identificador.
Para servidores, en cambio, necesitas direcciones o nombres estables. No quieres que el servicio cambie de dirección y el DNS se quede mirando al pasado.
Esto crea una separación sana:
- Clientes con privacidad y direcciones temporales.
- Servidores con direcciones previsibles.
- DNS solo para lo que necesita nombre estable.
- Firewall con reglas por red o host, no por magia.
En IPv4 doméstico muchas veces no piensas tanto en esto porque el NAT tapa parte del asunto. En IPv6 conviene ser más explícito.
VPN, Tailscale y túneles#
IPv6 no elimina automáticamente la necesidad de VPN. Para acceso remoto a servicios internos sigo prefiriendo una VPN o una red mesh bien controlada en muchos casos. No porque exponer por IPv6 sea imposible, sino porque no todo merece estar en internet con una regla de firewall.
Para paneles administrativos, NAS, Proxmox, Home Assistant o servicios familiares, mi instinto sigue siendo acceso privado. Tailscale, WireGuard o una VPN clásica son aburridos y eficaces.
IPv6 puede ayudar si tu IPv4 está detrás de CG-NAT o si quieres conectividad directa entre ubicaciones. Pero una cosa es conectividad y otra autorización. Que algo pueda tener una dirección global no significa que deba aceptar tráfico desde cualquier sitio.
Cloudflare Tunnel, reverse proxy y VPN siguen teniendo sitio. IPv6 no invalida esas decisiones. Solo añade otra ruta posible.
Cómo lo probaría sin romper la casa#
Mi enfoque sería por fases.
Primero, laboratorio aislado. Una VLAN o red de pruebas con IPv6 activado, un par de clientes y un servidor de prueba. Nada familiar. Nada crítico.
Segundo, comprobar prefijo y firewall. Quiero saber si el operador entrega un prefijo estable o cambiante, cómo delega, qué hace el router y qué reglas entrantes se aplican.
Tercero, DNS controlado. Nombres internos de prueba, registros AAAA solo para laboratorio y pruebas desde varios clientes.
Cuarto, servicios no críticos. Un dashboard, una web interna o un servicio de pruebas. Algo que pueda caer sin drama.
Quinto, documentación mínima. Qué prefijo recibo, dónde se configura, qué reglas existen, qué servicios escuchan en IPv6 y cómo desactivar si algo se tuerce.
Sexto, ampliar si aporta algo real. Si después de probar no gano nada, no pasa nada. IPv6 puede quedarse en laboratorio hasta que haya una razón.
El objetivo no es poner una medalla de “red moderna”. El objetivo es que la red funcione mejor o que yo aprenda algo sin romper lo que ya funcionaba.
Problemas típicos que esperaría#
Hay varios problemas que miraría desde el principio.
El primero: clientes que prefieren IPv6 aunque el servicio esté peor configurado por IPv6. Esto genera fallos intermitentes y bastante molestos.
El segundo: firewall entrante más abierto de lo que pensabas. En IPv4 el NAT ocultaba. En IPv6 el firewall debe bloquear de verdad.
El tercero: DNS con registros AAAA incorrectos. Un nombre bonito apuntando al sitio equivocado arruina cualquier diagnóstico.
El cuarto: contenedores y servicios que escuchan solo en IPv4. No es grave, pero conviene saberlo.
El quinto: prefijos dinámicos. Si tu operador cambia el prefijo, necesitas que DNS, reglas y servicios lo toleren.
El sexto: dispositivos IoT que hacen cosas raras. Sorpresa de nadie.
Nada de esto hace que IPv6 sea mala idea. Solo significa que hay que probarlo como una pieza de red seria, no como un checkbox del router.
Mi decisión práctica#
En un homelab doméstico, yo no empezaría activando IPv6 en toda la casa. Empezaría aprendiendo en una zona controlada. Si aporta valor, lo extendería. Si no, lo dejaría preparado y documentado.
Lo activaría antes si tengo CG-NAT, si quiero aprender redes de verdad, si mi firewall es decente y si puedo controlar prefijos y reglas. Lo dejaría para más adelante si mi red ya está demasiado cargada de dependencias o si el router no me deja ver qué está pasando.
IPv6 no es una amenaza. Lo peligroso es activarlo sin cambiar el modelo mental. En IPv4 doméstico mucha gente se apoya en NAT, direcciones privadas y costumbres heredadas. En IPv6 hay que pensar en firewall, DNS y exposición con más claridad.
Esa claridad es buena. Incómoda, pero buena.
Si mañana montara una red doméstica desde cero, la diseñaría preparada para IPv6. Pero preparada no significa desplegada sin filtro. Significa firewall capaz, DNS limpio, documentación mínima y pruebas por fases.
Porque en homelab hay pocas frases más caras que “esto debería funcionar”. IPv6 funciona. Lo que no siempre funciona es nuestra arquitectura alrededor.