La migración a IPv6 no es un proyecto técnico puntual, sino un proceso que requiere planificación, pruebas y vías claras de retroceso. La palabra clave foco IPv6‑Migration aparece pronto, porque muchos responsables y operadores subestiman la transición: conceptos de direccionamiento, comportamiento del proveedor (p. ej. Prefix Delegation), reglas de firewall y constelaciones VPN deben sincronizarse para que la operación y la seguridad se mantengan. Este artículo le guía en cinco pasos claros a través del procedimiento práctico, con secuencias de verificación, configuraciones de ejemplo y notas de troubleshooting.
Por qué es necesaria una migración a IPv6 estructurada
IPv6 resuelve la escasez de direcciones y aporta mejoras en el enrutamiento y la autoconfiguración; al mismo tiempo altera supuestos operativos centrales. Muchas herramientas, pipelines de monitoring y firewalls esperan direcciones IPv4; protocolos como Neighbor Discovery (ND) y SLAAC (Stateless Address Autoconfiguration) funcionan de forma distinta a ARP y DHCPv4. Una migración incorrecta puede causar problemas de alcanzabilidad, tráfico IPv6 inesperado o huecos de seguridad.
Resumen: Los cinco pasos
- Paso 1: Planificación y toma de inventario
- Paso 2: Fundamentos de Dual‑Stack y pruebas
- Paso 3: Configurar Prefix‑Delegation (PD) con el proveedor
- Paso 4: Estrategias de fallback y rollback
- Paso 5: Operación, monitoring e integración de VPN
Paso 1 — Planificación y toma de inventario
Una buena planificación reduce las sorpresas. Registre dispositivos, software y dependencias, así como la capacidad IPv6 de los componentes en uso.
Inventario y comprobación de compatibilidad
Elabore un inventario de todos los routers, firewalls, load‑balancers, gateways VPN, servidores y servicios de red relevantes (DNS, DHCP, monitoring). Revise las versiones de firmware y del sistema operativo: no todos los equipos antiguos soportan IPv6 al completo, o presentan bugs en el manejo de ND/RA. Anote proveedor, modelo y versión: esa información es la base para decisiones de actualización y pruebas.
Plan de direcciones y requisitos de PD
Los planes de direccionamiento claros son más importantes que en IPv4: los prefijos IPv6 se diseñan de forma jerárquica. Decida si espera de su proveedor un /48, /56 o /64; en general se utilizan /48 para B2B de mayor escala, y /56 o /60 para sitios más pequeños. La Prefix Delegation (PD) es el procedimiento mediante el cual el proveedor delega un prefijo a sus routers —más adelante se detalla.
Dependencias de seguridad y cumplimiento
Inventarice qué logs, IDS/IPS, reglas SIEM o controles de cumplimiento no soportan IPv6. Planifique un funcionamiento en paralelo y defina qué políticas de seguridad deben ajustarse: reglas de firewall, segmentación de red, listas de acceso y filtros de monitoring.
Secuencia de verificación antes del despliegue en producción
Antes de iniciar las pruebas, defina métricas: alcanzabilidad (ICMPv6), resolución DNS mediante registros AAAA, pruebas de aplicaciones (HTTP/S sobre IPv6), comportamiento de MTU y conexiones VPN. Establezca ventanas de prueba, responsabilidades y métricas que determinen éxito/fracaso.
Paso 2 — Introducir y probar Dual‑Stack
Dual‑Stack significa que hosts y componentes de red hablan tanto IPv4 como IPv6 en paralelo. Es el método de transición recomendado porque permite validar aplicaciones y rutas de forma individual.
SLAAC vs. DHCPv6 — tomar una decisión
SLAAC (StateLess Address AutoConfiguration) genera direcciones automáticamente a partir de Router‑Advertisements (RA). DHCPv6 ofrece asignación centralizada, comparable con DHCPv4. Elija SLAAC si desea subredes simples y configuradas de forma autónoma; elija DHCPv6 para control central, reservas y opciones más detalladas. A menudo es sensato un modo de operación híbrido: RA para la puerta de enlace predeterminada + DHCPv6 para DNS y otras opciones.
Ejemplo de Router‑Advertisements (radvd)
Un fragmento sencillo de radvd (Router‑Advertisement Daemon) para una subred /64:
# /etc/radvd.conf
interface eth1
{
AdvSendAdvert on;
prefix 2001:db8:1:0::/64
{
AdvOnLink on;
Adv autonomous on; # aktiviert SLAAC
};
};Esta configuración hace que los hosts en la subred formen una dirección SLAAC a partir del prefijo indicado. Si utiliza DHCPv6, establezca „Adv autonomous off“ y distribuya las direcciones mediante DHCPv6.
Comprobación de la conectividad IPv6
Ejemplos de comprobaciones para Linux y Windows:
# Linux: Prüfen ob eine Route und RA empfangen werden
ip -6 route show
rdisc6 eth1 # zeigt Router Advertisements (Teil von ndisc6-Tools)# Windows: IPv6 Konfiguration prüfen
Get-NetIPAddress -AddressFamily IPv6
Test-NetConnection -ComputerName example.com -InformationLevel Detailed -TraceRouteDNS y registros AAAA
Asegúrese de que las zonas DNS admitan registros AAAA y de que la estrategia de TTL esté ajustada a los cambios previstos. Los servidores DNS internos deben responder correctamente a consultas en dual‑stack; compruebe la configuración del resolvedor (p. ej., systemd-resolve, Unbound o BIND).
Paso 3 — Delegación de prefijo (PD) del proveedor
La delegación de prefijos es el método por el cual su ISP asigna dinámicamente un prefijo de subred a su router cliente, típicamente a través de DHCPv6‑PD (DHCPv6 Prefix Delegation). Esto es importante en ubicaciones con WAN dinámico, donde el prefijo asignado por el proveedor puede cambiar.
Cómo funciona la PD y qué puede fallar
Con DHCPv6‑PD, su router CPE solicita un prefijo al servidor DHCP del ISP. El router utiliza este prefijo localmente (p. ej., como varios /64 para VLAN). Surgen problemas cuando el proveedor cambia los prefijos con frecuencia, los dispositivos no mantienen la PD de forma estable o las configuraciones de RA/DHCPv6 entran en conflicto (p. ej., cuando SLAAC genera direcciones locales que están fuera del rango delegado).
Ejemplo: ISC dhcpd6.conf para PD
Un ejemplo sencillo para el servidor DHCPv6 (lado del proveedor) o para ilustrar la asignación PD:
# /etc/dhcp/dhcpd6.conf (Provider/Server-Seite Beispiel)
subnet6 2001:db8:100::/48 {
range6 2001:db8:100:1:: 2001:db8:100:ffff:ffff::;
}
# Delegation: weist /56 an anfragenden Client mit duid "client-duid"
pd 2001:db8:200::/56 {
prefix6 2001:db8:200::/56;
pool6 2001:db8:200::/56;
}
host client-router {
host-identifier option dhcp6.client-id 00:01:00:01:...
fixed-address6 2001:db8:100:1::1;
pd 2001:db8:200::/56;
}
En centros de datos o en sus propios servidores DHCP, esta configuración sirve como referencia. En la práctica, los proveedores emplean sistemas propietarios; consulte la documentación del proveedor y solicite garantías de estabilidad (p. ej., duración del arrendamiento PD y frecuencia de cambios).
Configuración del router: aplicar el prefijo delegado a las interfaces internas
El router CPE debe aplicar el prefijo delegado de forma dinámica en los VLANs/subredes internas. En routers Linux, por ejemplo, un script puede leer el prefijo PD recibido y configurar las interfaces. Verifique cómo su router gestiona las actualizaciones de PD: los rebindings no deberían provocar flapping de direcciones internas.
Migración a IPv6: plan de despliegue y comunicación con las partes interesadas
Una migración técnica solo tiene éxito con responsabilidades claras. Defina roles: operador de red, seguridad, responsables de aplicaciones, propietarios de pruebas y de rollback. Planifique puntos de comunicación: anuncio, fin de pruebas, decisión Go/No‑Go, revisión posterior al despliegue.
Calendario típico para el despliegue en un sitio
Un marco de mini‑proyecto recomendado por sitio:
- Día 0–7: inventario, comprobación de firmware, aclaración con el proveedor (PD / Lease‑Time)
- Día 8–14: pruebas de laboratorio (Dual‑Stack, PD, VPN) y plantillas de firewall
- Día 15–16: piloto en VLAN no crítica, monitorización activa
- Día 17: ventana Go/No‑Go, despliegue a producción
- Día 18–30: fase de observación, revisión y estabilización
Criterios de aceptación
Defina criterios medibles: accesibilidad IPv6 de todos los servicios críticos, sin aumento de logs de error, túneles VPN operativos sobre IPv6, sin caídas significativas de rendimiento (latencia/MTU).
Paso 4 — Estrategia de fallback y reversión
Un plan de fallback claro es imprescindible. Dual‑Stack facilita esto: ante problemas puede desactivar IPv6 de forma selectiva o retirar rutas IPv6 sin afectar IPv4.
Desactivación rápida de IPv6
Linux (sysctl) para desactivar temporalmente todo IPv6 en un host:
# Temporär: für diese Sitzung
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
# Permanent: /etc/sysctl.d/99-disable-ipv6.conf
echo 'net.ipv6.conf.all.disable_ipv6=1' | sudo tee /etc/sysctl.d/99-disable-ipv6.conf
sudo sysctl --systemWindows (para pruebas rápidas) vía PowerShell: desactivar interfaces IPv6 individuales:
# Beispiel: IPv6 auf Interface 'Ethernet' deaktivieren
Set-NetAdapterBinding -Name 'Ethernet' -ComponentID ms_tcpip6 -Enabled $falseAviso: desactivar completamente IPv6 en Windows no se recomienda, porque algunas funcionalidades de Windows (p. ej. Teredo, IPHTTPS) dependen de ello. Use esta medida solo para aislamiento de fallos y tras consultar con los equipos de aplicaciones.
Fallback de enrutamiento y control de preferencias
IPv6 no tiene una equivalencia directa a «Policy‑Based Routing» para preferencias de protocolo; los sistemas operativos suelen elegir IPv6 sobre IPv4 cuando existen ambas direcciones. Puede controlar esto con políticas de dirección de origen o la política RFC6724 (preferencia de direcciones), por ejemplo ajustando las tablas de políticas en clientes o balanceadores de carga. Alternativamente, configure el DNS de modo que los registros AAAA se introduzcan con retardo hasta que las rutas estén estables.
Lista de verificación para rollback
- Desactivar IPv6 (si es necesario) y comprobar la conectividad
- Retirar registros AAAA del DNS o reducir la TTL
- Eliminar/neutralizar reglas de firewall y NAT en IPv6
- Contactar al proveedor (cambios PD/RA) y revisar logs
- Documentar la reversión e incorporar las lecciones aprendidas en la revisión
Paso 5 — Operación, monitorización y especificidades de VPN
Tras un despliegue exitoso estabilice la operación y amplíe el monitoring. Para VPNs (p. ej. IPsec o WireGuard) se aplican reglas específicas, ya que las configuraciones de túnel a menudo emplean políticas basadas en IP.
Monitorización y métricas
Agregue comprobaciones IPv6 a su monitorización: latencia ICMPv6, errores de Neighbor Discovery, estado de túneles, número de sesiones IPv6 (conntrack), errores AAAA en DNS, errores de MTU (ICMPv6 Packet Too Big). Ajuste el parsing del SIEM para que los logs indexen y correlacionen correctamente las direcciones IPv6.
Reglas de ejemplo de nftables para IPv6
Un ejemplo minimalista que permite ICMPv6 para Neighbor Discovery (ND) y acepta conexiones establecidas:
# /etc/nftables.conf (Auszug für IPv6)
table inet filter {
chain input {
type filter hook input priority 0;
policy drop;
# Allow loopback
iif lo accept;
# Allow established/related
ct state established,related accept;
# Neighbor Discovery / ICMPv6
ip6 nexthdr icmpv6 icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem, echo-request, echo-reply, nd-router-advert, nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } accept;
# SSH for admins (example)
tcp dport 22 accept;
}
}
ICMPv6 no es un protocolo de „solo ping“, sino parte de la funcionalidad (Neighbor Discovery). No bloquee ICMPv6 de forma general; permita los tipos necesarios.
VPN e IPv6 — pasos concretos de verificación y solución de problemas
IPsec: Verifique con el conjunto de herramientas IPsec local (p. ej. strongSwan), si hay Security Associations (SAs) para IPv6. PRESTe atención a los Traffic-Selectors, ya que determinan qué prefijos IPv6 pueden transportarse por el túnel. WireGuard: compruebe AllowedIPs y MTU; WireGuard enruta todos los prefijos especificados a través de la interfaz.
# strongSwan Status (Linux)
sudo ipsec statusall
# WireGuard Status
sudo wg show
# PMTU Test (IPv6) - sendet große Pakete, 'do' erzwingt kein Fragmentieren
sudo ping6 -c 3 -s 1400 -M do example.comPatrones de fallo: Si el túnel está establecido pero no existe conectividad extremo a extremo, compruebe primero MTU/ICMPv6 Packet Too Big; muchos túneles (IPsec ESP) requieren ajuste de MTU o MSS-clamping. Si solo algunos prefijos no son alcanzables, compruebe los Traffic-Selectors/AllowedIPs y las rutas Provider‑PD.
Herramientas prácticas y pruebas
Pruebas de rendimiento y de ruta con iperf3 sobre IPv6:
# Server starten (hört IPv6)
iperf3 -s -6
# Client auf entfernten Host testen
iperf3 -c 2001:db8::1 -6 -t 10Una medición exitosa de iperf3 confirma el trayecto TCP/UDP y el comportamiento de MTU; las pruebas fallidas suelen indicar problemas de enrutamiento, firewall o MTU.
Automatización y gestión de la configuración
La automatización reduce errores humanos en rollouts y rollbacks. Utilice Configuration Management (Ansible, Salt, Puppet) para radvd, hooks de cliente DHCPv6 y plantillas de nftables. Asegúrese de que las tareas sean idempotentes para que ejecuciones repetidas sean seguras.
# Beispiel: Ansible-Task zum Deployen eines radvd-Configs (Auszug)
- name: Deploy radvd configuration
ansible.builtin.copy:
dest: /etc/radvd.conf
content: |
interface eth1
{
AdvSendAdvert on;
prefix 2001:db8:1:0::/64
{
AdvOnLink on;
Adv autonomous on;
};
};
notify: RESTart radvd
- name: RESTart radvd
ansible.builtin.service:
name: radvd
state: RESTarted
enabled: yesVersione las configuraciones en Git y utilice revisiones de playbook como control de cambios. Pruebe los playbooks contra un entorno similar a laboratorio antes de desplegar en producción.
Casos prácticos, errores habituales y comprobaciones rápidas
Aquí una lista condensada de las fuentes de error más importantes y cómo probarlas rápidamente:
- Sin IPv6 por parte del proveedor: compruebe la interfaz WAN con
ip -6 addry si RA/PD llega realmente. - DNS devuelve AAAA, pero la conexión falla: pruebe con iperf3 y verifique MTU/Firewall.
- Fallo de Neighbor Discovery: compruebe con tcpdump ICMPv6‑ND.
- VPN cae tras la activación de IPv6: compruebe AllowedIPs/TrafficSelectors y Firewall‑Policies.
- Hosts prefieren IPv6 y no alcanzan servicios: compruebe la política RFC6724‑Policy o introduzca AAAA de forma gradual.
Lista de verificación para un despliegue seguro
- Actualizar el inventario y comprobar el soporte IPv6.
- Acordar el plan de direcciones y los requisitos de PD con el proveedor.
- Pruebas de laboratorio: validar Dual‑Stack en una VLAN aislada.
- Crear y probar reglas de Firewall e IDS para IPv6 (tener en cuenta ICMPv6).
- Definir casos de prueba VPN: IPsec, WireGuard, accesos cliente.
- Ajustar la monitorización: ICMPv6, ND, conntrack, comprobaciones DNS AAAA.
- Documentar el procedimiento de rollback y disponerlo probado.
Conclusión
Una migración a IPv6 exitosa es planificable: comience con una inventario fiable, implemente Dual‑Stack de forma controlada, utilice Provider‑Prefix‑Delegation (PD) correctamente y disponga de mecanismos claros de fallback. En el día a día de la operación, la monitorización y las pruebas VPN específicas forman parte de la rutina. La profundidad técnica, como se muestra aquí, garantiza que los cambios sean previsibles y que la operación productiva permanezca segura. Priorice pasos pequeños y medibles, automatización y procedimientos de reversión documentados — así minimiza el riesgo y crea las condiciones para una operación IPv6 estable.
Para este tema también son importantes Ra Slaac. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que centrarse en la práctica.