Qué es IPv6 (en claro) y por qué no es “IPv4 con esteroides”
Si tuviera que resumir IPv6 en una frase, sería esta que repito en cada curso: “IPv6 no es IPv4 con direcciones más largas; es un cambio de paradigma.” El objetivo no es solo ampliar el número de direcciones (aunque pasamos de 32 a 128 bits y eso se nota), sino recuperar la conectividad extremo a extremo, simplificar la red y quitarle al NAT la estelaridad que nunca debió tener.
En la práctica, IPv6 trae tres ideas que te cambian el modelo mental:
Direccionamiento abundante y jerárquico: dejas de rascar direcciones y empiezas a planificar con /48, /56 y /64 sin miedo.
Autoconfiguración real (SLAAC/DHCPv6): los hosts pueden configurarse solos con anuncios del router, manteniendo control centralizado donde lo necesitas.
ICMPv6 crítico para que la red “respire”: Neighbor Discovery, Router Advertisements y Path MTU Discovery dependen de él.
Cuando empecé a auditar despliegues, encontré empresas pagando $60 USD por cada IPv4 en mercados de transferencia. Ese coste se vuelve absurdo en cuanto entiendes que con IPv6 el direccionamiento deja de ser el cuello de botella. Y, sí, “El NAT no es seguridad, es una complicación heredada.” Lo digo así, literal, porque la “seguridad por NAT” fue siempre un espejismo; la seguridad real vive en políticas explícitas de firewall, segmentación y visibilidad.
Ventajas reales: rendimiento, escalabilidad y seguridad bien entendida
La ventaja más tangible que veo en campo es rendimiento. En móvil, donde IPv6 es nativo, hemos medido hasta un 15% de mejora en latencia tras quitar el procesamiento extra del NAT. Menos traducciones, menos estados, menos dolor. En IoT industrial, la escalabilidad ya no se discute: a un solo sensor le asignamos un /64 y el cliente se quedó helado al ver la holgura que eso le daba para crecer sin remiendos.
En seguridad, la conversación madura cuando abandonas el fetiche del NAT. Con IPv6 no “escondes” hosts tras una única IP: los proteges con reglas claras (inbound/outbound), listas de control y segmentación. Y surge otra realidad que muchos pasan por alto: “En IPv6, el escaneo de puertos por fuerza bruta es estadísticamente imposible.” No porque la máquina sea invulnerable, sino porque el espacio de direcciones hace inviable barrer la red a ciegas. Tus riesgos reales estarán en exposiciones accidentales, servicios mal configurados y políticas de firewall incompletas.
Espacio de direcciones y notación (AAAA, 128 bits, ULA/GUA)
Trabajar con direcciones AAAA y notación hexadecimal comprimida asusta dos días; al tercero lo agradecerás. Planifica GUA para lo enrutado en Internet y ULA para espacios internos que no deben salir. Consejo práctico: documenta alias legibles (DNS bien cuidado) y define bloques por dominios de fallo (sitio, edificio, VLAN crítica).
Latencia y movilidad: por qué en móvil “vuela” sin NAT
En itinerancia y redes móviles, eliminar NAT y mantener rutas limpias reduce hops y estados. Además, los flujos directos end-to-end simplifican el troubleshooting y rebajan fenómenos raros que ves cuando los middleboxes “tocan” paquetes.
Antes de tocar nada: modelo mental y arquitectura
Te dejo el marco que uso antes de abrir el primer ticket de cambio:
Conectividad end-to-end por diseño; el firewall hace de guardián, no el NAT.
Dual-stack bien gobernado (sí, en 2026 sigue siendo lo habitual): cada política que apliques en v4 tiene su equivalente en v6 desde el día 0.
Observabilidad obligatoria: “Si no estás monitoreando tu tráfico IPv6 hoy, tienes la mitad de tu red a ciegas.”
Dual-stack sin sustos: reglas mínimas de firewall IPv6
Mi “mínimo razonable” para un arranque seguro:
Entrante (WAN→LAN): denegar por defecto; permitir solo servicios publicados (TCP/443, 80 si procede, 22/3389 solo si hay control estricto y MFA/VPN); ICMPv6 esencial permitido (tipos de PMTUD y NDP donde corresponda).
Saliente (LAN→WAN): permitir estados “established/related”; bloquear salidas innecesarias; aplicar egress filtering por segmento.
Lateral (LAN↔LAN): segmentación por VLAN/subred; niega por defecto y abre lo mínimo (DNS, NTP, directorio, app-specific).
Inserción de experiencia: he visto puertas traseras sin querer porque el equipo solo vigilaba IPv4. En dual-stack, si olvidas el firewall v6, has dejado el portón abierto mientras cierras la mirilla.
ICMPv6 es oxígeno: NDP, RA/RS y PMTUD sin bloqueos
Esto es dogma: no bloquees ICMPv6 a ciegas. En una auditoría me encontré un equipo que copió la política “bloquear ICMP” de IPv4. Resultado: NDP roto, vecinos invisibles, PMTUD pegándose tiros y sesiones “fantasma” que parecían caerse al azar. Permite Router Advertisements, Neighbor Solicitation/Advertisement y los mensajes de “Packet Too Big”.
Cómo desplegar IPv6 paso a paso (checklist operativa)
Plan de direccionamiento (/48, /56, /64) y naming
Pide a tu ISP un /48 si tienes múltiples sitios o un /56 si es una sede mediana; asigna /64 por VLAN (no racanees).
Define un esquema jerárquico: sitio (12–16 bits) → edificio/planta → VLAN.
Estándar de nombres: dns-interno legible, evita depender de IPs en documentación de ops.
Router, DHCPv6/SLAAC y DNS (A/AAAA) verificados
Activa RA en los segmentos de usuario y decide si complementas con DHCPv6 (útil para opciones y control).
Publica registros AAAA donde existan A; evita asimetrías de resolución (aplicaciones que resuelven AAAA pero backend sin v6).
Aplica RA Guard/first-hop security en switches para cortar anuncios falsos.
Validación con test de conectividad y pruebas de MTU/fragmentación
Pasa pruebas básicas (resolución AAAA, conectividad v6, preferencia de rutas).
Verifica PMTUD: genera tráfico con tamaños grandes y confirma recepción de “Packet Too Big” si corresponde; ajusta MTU en túneles y enlaces WAN.
Errores que he visto (y cómo evitarlos)
El espejismo del NAT66 y la “seguridad por NAT”
NAT66 aparece por inercia mental. Te da falsa sensación de “ocultar” cuando lo que necesitas es política explícita y observabilidad. Además, complica el troubleshooting. Repetido porque importa: “El NAT no es seguridad, es una complicación heredada.”
El bloqueo de ICMPv6 que rompe todo
Ya lo viví: bloquear ICMPv6 “por seguridad” rompe NDP y PMTUD. La red pasa a respirar por una pajita. Corrige permitiendo los tipos necesarios y tus “caídas misteriosas” desaparecerán.
PMTUD mal y “mi banca no carga”
Clásico de terror: Google abre (carga en v4/v6 con CDNs tolerantes) pero la banca queda colgada. El culpable: fragmentación en v6 la hace el host, los routers no fragmentan. Si PMTUD no funciona, el host insiste en tamaños imposibles y la sesión muere. Solución: deja pasar “Packet Too Big”, y revisa MTU en túneles, PPPoE y enlaces híbridos.
Operación continua: monitoreo, logs y adopción interna
Define KPIs desde el día 1:
% de tráfico en v6 vs v4 (objetivo: tender a v6 en móvil/edge).
Latencia y pérdida por protocolo.
Eventos PMTUD y ICMPv6 anómalos.
Servicios publicados en v6: inventario y posture de seguridad.
Entrena al equipo: Wireshark con filtros v6, lectura de cabeceras, prácticas de RA/RS. Y ten un “plan B” para legados: NAT64/DNS64 como puente cuando un servicio solo habla v4.
FAQs rápidas de IPv6 para 2026
¿Necesito dual-stack sí o sí? Hoy, en la mayoría de entornos, sí. Te evita sorpresas con legados mientras avanzas la adopción.
¿Puedo bloquear ICMPv6? No en bloque. Permite los tipos críticos (RA/RS, NDP, PTB).
¿Cómo evito que me “escaneen” todo? El espacio de direcciones ya lo dificulta; céntrate en no exponer servicios por error y en políticas de firewall.
¿Qué gano realmente respecto a IPv4? Menos complejidad por NAT, mejor rendimiento, direccionamiento sobrado y una arquitectura más limpia.
Conclusión
IPv6 no es un proyecto: es un estándar de operación. Si cambias el modelo mental, escribes políticas de firewall claras, dejas vivir a ICMPv6 y observas la red, el despliegue es más sencillo de lo que parece. Y cuando lo hagas, notarás lo mismo que yo: menor latencia, menos rarezas y una plataforma lista para crecer sin parches.