IPv6 MikroTik: dual-stack y DHCPv6-PD para ISP y empresas

Si operas una red de ISP o una infraestructura empresarial en Chile, la pregunta ya no es si vas a habilitar IPv6, sino cuándo tu upstream te delegue el prefijo y tengas que bajarlo ordenadamente hasta el último abonado o hasta el último segmento de la LAN. Con el agotamiento de IPv4 y el CGNAT metiéndose entre tus clientes y el mundo, IPv6 MikroTik deja de ser un experimento de laboratorio y pasa a ser parte del diseño. En esta guía vamos a lo concreto: cómo armar dual-stack en RouterOS, cómo recibir y delegar prefijos con DHCPv6-PD, y qué diferencia hay entre SLAAC y DHCPv6 en la LAN, con comandos reales de RouterOS v7.

Dual-stack: IPv6 al lado de IPv4, no en su reemplazo

Dual-stack significa que cada interfaz relevante habla IPv4 e IPv6 en paralelo, con su propia tabla de ruteo y su propio firewall. No es una migración de golpe: es correr ambos protocolos hasta que el tráfico IPv6 sea mayoritario y el IPv4 quede detrás de CGNAT o se vaya apagando. La ventaja operativa es que no rompes nada de lo que ya funciona —tus rutas IPv4, tu NAT, tus colas— y vas sumando conectividad nativa IPv6 servicio por servicio.

Hay dos decisiones de diseño que conviene fijar temprano. Primero, cómo obtienes direccionamiento IPv6 desde tu proveedor: una dirección para el enlace WAN y —lo importante— un prefijo delegado (PD) que sea tuyo para repartir hacia adentro. Segundo, cómo entregas ese direccionamiento en la LAN o hacia los abonados: SLAAC, DHCPv6 stateful o DHCPv6-PD. En RouterOS todo esto vive bajo el menú /ipv6, e IPv6 es un paquete que debe estar instalado y habilitado.

Recibir en el WAN y delegar hacia adentro con DHCPv6-PD

El cliente DHCPv6 de RouterOS (/ipv6/dhcp-client) hace dos trabajos a la vez: puede pedir una dirección stateful (IA_NA) para el propio enlace y puede pedir un prefijo (IA_PD) que luego repartes hacia abajo. Eso se controla con la propiedad request, que acepta address, prefix o ambos. El caso típico de un borde que necesita direccionar su WAN y además obtener un bloque para la red interna:

/ipv6/dhcp-client
add interface=ether1 request=address,prefix \
    pool-name=isp-pd pool-prefix-length=64 \
    add-default-route=yes use-peer-dns=yes

Con request=prefix, el prefijo que entrega el ISP se deposita automáticamente en un pool IPv6 —el que nombras en pool-name— y desde ahí lo consumes para direccionar interfaces internas o para alimentar un servidor DHCPv6-PD. Puedes verificar el estado con print detail: el cliente debe quedar en status=bound y mostrar el prefijo recibido, por ejemplo prefix=2001:db8:7501:ff04::/62. Ese mismo prefijo aparece en /ipv6/pool print como un pool dinámico, listo para usar.

Un detalle fino de operación: pool-prefix-length define en cuántos trozos vas a cortar lo recibido. Si el ISP te enruta un /62 y fijas pool-prefix-length=64, tienes cuatro /64 para asignar. Y si quieres pedirle a tu upstream un tamaño concreto de bloque, existe prefix-hint para sugerir la longitud de prefijo preferida.

Prefix Delegation (PD) es la pieza que hace escalable IPv6 en un ISP: en lugar de asignar direcciones sueltas, delegas bloques enteros a cada router cliente (CE), que a su vez direcciona su propia LAN sin NAT. El router que recibió el /62 del upstream se convierte en servidor DHCPv6-PD y reparte /64 hacia abajo. Un escenario real: el ISP enruta 2001:db8::/62 hacia tu router R1, y R1 delega /64 a cada router de cliente (CE1, CE2). En R1:

/ipv6/pool
add name=myPool prefix=2001:db8::/62 prefix-length=64

/ipv6/dhcp-server
add name=server1 interface=to-CE-routers \
    prefix-pool=myPool lease-time=3d disabled=no

Y en cada router de cliente, el CE toma el prefijo delegado y lo aplica a su interfaz LAN para anunciarlo a los hosts:

/ipv6/dhcp-client
add interface=to-R1 request=prefix pool-name=my-ipv6

/ipv6/address
add address=::1/64 from-pool=my-ipv6 interface=to-clients advertise=yes

La línea clave es address=::1/64 from-pool=my-ipv6: RouterOS toma un /64 del prefijo delegado, se autoasigna la dirección ::1 dentro de ese bloque y —con advertise=yes— empieza a emitir Router Advertisements para que los equipos de la LAN se autoconfiguren. Del lado del servidor, cada delegación queda registrada en /ipv6/dhcp-server/binding, donde ves el prefijo entregado, el DUID del cliente y el estado bound. Ese binding es tu fuente de verdad cuando tengas que rastrear qué bloque tiene cada abonado.

SLAAC vs. DHCPv6 stateful en la LAN

Una vez que tienes el /64 en la interfaz interna, hay que decidir cómo obtienen dirección los hosts. IPv6 ofrece dos mecanismos que en RouterOS se controlan desde el Neighbor Discovery (/ipv6/nd) y el servidor DHCPv6. La confusión más común en equipos que recién empiezan con IPv6 es tratar DHCPv6 como si fuera el DHCP de IPv4: no lo es. En IPv6, el default gateway siempre lo aprende el host desde el Router Advertisement, nunca desde DHCPv6.

Mecanismo	Quién asigna la dirección	Gateway	Cuándo conviene
SLAAC (RA, advertise=yes)	El propio host, a partir del prefijo anunciado	Desde el RA	LAN simple; el router publica el /64 y los equipos se autoconfiguran
DHCPv6 stateful (IA_NA)	El servidor DHCPv6 (pool /128)	Desde el RA	Cuando necesitas control y registro por dirección, tipo lease de IPv4
DHCPv6-PD (IA_PD)	Se delega un bloque a otro router, no a un host	N/A (ruteo)	ISP entregando /64//56 a cada CE

Para SLAAC puro basta con el advertise=yes del ejemplo anterior. Si en cambio quieres DHCPv6 stateful, el servidor toma direcciones de un pool cuyo prefix-length debe ser /128 (una dirección por cliente), y sigues necesitando el RA para el gateway. Un matiz útil de RouterOS: al crear una dirección desde el pool puedes usar la opción without-acquire para generar la dirección SLAAC del router sin reservar el prefijo, de modo que ese mismo router opere a la vez como servidor DHCPv6 sobre la misma subred.

PPPoE con IPv6-PD para redes de abonados

Si tu operación es un ISP con PPPoE como método de acceso, no necesitas montar DHCPv6 sobre Ethernet: la delegación viaja sobre la sesión PPP. En el perfil PPP (/ppp/profile) tienes las propiedades que atan IPv6 a cada abonado. La dirección del enlace del cliente sale de remote-ipv6-prefix-pool, y el prefijo que se delega —vía un servidor DHCPv6-PD creado dinámicamente por sesión— sale de dhcpv6-pd-pool. Además, use-ipv6 debe permitir IPv6 (queda habilitado por defecto si el paquete IPv6 está instalado).

Esto significa que cada cliente PPPoE que se conecta obtiene automáticamente su prefijo delegado sin que tengas que preconfigurar nada por abonado, y la asignación puede además centralizarse en RADIUS con atributos como Delegated-IPv6-Prefix y Mikrotik-Delegated-IPv6-Pool. Es el mismo modelo de gestión de abonados que ya usas para IPv4, extendido a IPv6.

Firewall IPv6: dual-stack también significa doble superficie

El error más caro al habilitar IPv6 es asumir que el firewall IPv4 te cubre. No lo hace: IPv6 tiene su propia cadena en /ipv6/firewall/filter y, si la dejas vacía, expusiste toda tu red a Internet con direcciones globales enrutables y sin NAT de por medio. El filtrado IPv6 correcto acepta más cosas que su equivalente IPv4, porque ICMPv6 y el propio DHCPv6-PD son parte esencial del protocolo:

/ipv6/firewall/filter
add action=accept chain=input protocol=icmpv6 \
    comment="accept ICMPv6"
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input protocol=udp dst-port=546 \
    src-address=fe80::/10 comment="DHCPv6-Client PD"
add action=drop chain=input in-interface-list=!LAN \
    comment="drop all not coming from LAN"

Presta atención a la regla del puerto 546 con origen fe80::/10: es la que permite que tu cliente DHCPv6-PD reciba el prefijo. Si la omites o la dejas mal, verás el cliente colgado en searching sin llegar nunca a bound. Y en el borde de acceso, considera RA Guard a nivel de bridge: valida los Router Advertisements contra los puertos de confianza y descarta RAs de un router no autorizado que un cliente conecte por error o de un ataque de RA rogue —un problema que en IPv6 puede secuestrar el gateway de todo un segmento.

Conversemos tu despliegue IPv6 MikroTik

Dual-stack y DHCPv6-PD bien hechos son la diferencia entre un IPv6 que escala solo a medida que crece tu base de clientes y uno que se convierte en tickets de soporte y prefijos perdidos. El diseño de pools, la longitud de prefijo por abonado, el firewall IPv6 y la delegación sobre PPPoE o Ethernet son decisiones que conviene cerrar antes de encender el primer cliente. En MikroTik Chile diseñamos, implementamos y documentamos despliegues IPv6 sobre RouterOS para ISPs y empresas con infraestructura de misión crítica. Si estás planificando dual-stack o quieres revisar una configuración que ya tienes en producción, conversemos tu caso con un ingeniero.