IPv6 Privacy Extensions: qué son, cómo funcionan y qué implican para tu red ISP
Cuando IPv6 se diseñó en los años 90, SLAAC (Stateless Address Autoconfiguration, RFC 4862) era la solución elegante para el problema de la autoconfiguración: los dispositivos derivan su dirección IPv6 a partir de su MAC address usando el formato EUI-64. Resultado: sin DHCP, sin configuración manual, con dirección única y estable de por vida.
El problema que nadie pensó seriamente entonces: una dirección derivada de la MAC address es un identificador único y permanente. Un servidor web puede rastrear a un usuario a través de redes, sesiones y tiempo simplemente correlacionando la parte del identificador de interfaz de la dirección IPv6. Lo que en IPv4 requería cookies o fingerprinting, en IPv6 original era automático e inevitable.
Las Privacy Extensions (RFC 4941) son la respuesta estándar a ese problema. Desde que Windows Vista las adoptó como default en 2006, prácticamente todos los sistemas operativos modernos las tienen activas por defecto. Para los usuarios, el resultado es mejor privacidad. Para los ISPs que operan redes IPv6, el resultado es una complejidad adicional que hay que entender para manejar bien.
Cómo funciona SLAAC: la base del problema
Antes de entender las Privacy Extensions, conviene entender el mecanismo que reemplazan.
En SLAAC clásico con EUI-64, el dispositivo toma su MAC address de 48 bits y la expande a 64 bits para crear el identificador de interfaz:
MAC: 00:1A:2B:3C:4D:5E
EUI-64: 02:1A:2B:FF:FE:3C:4D:5E
→ Dirección IPv6: 2803:9800:cafe:1::21a:2bff:fe3c:4d5e
El bit 7 de la MAC (el bit “U/L”) se invierte, y se insertan FF:FE en el medio. El resultado es una dirección que:
- Es globalmente única (asumiendo MACs únicas, que en la práctica suelen serlo)
- Identifica el hardware inequívocamente
- Es permanente mientras el dispositivo no cambie su interfaz de red
- Sigue al dispositivo independientemente del prefijo de red que use
Un análisis de logs de cualquier servidor web con IPv6 puede correlacionar el mismo identificador de interfaz apareciendo desde diferentes redes a lo largo del tiempo. Es rastreo de hardware gratuito e implícito.
RFC 4941: Privacy Extensions para SLAAC
El RFC 4941 (actualizado por el RFC 8981 en 2021) introduce un mecanismo de generación de identificadores de interfaz temporales y aleatorios. En lugar de derivar el ID de la MAC, el dispositivo genera uno criptográficamente aleatorio que rota con el tiempo.
Cómo genera el dispositivo las direcciones temporales
El proceso simplificado:
- Al iniciar, el dispositivo genera un identificador de interfaz aleatorio de 64 bits
- Con el prefijo /64 del router (obtenido via Router Advertisement), forma una dirección temporal
- Verifica que no haya conflicto (DAD - Duplicate Address Detection)
- Usa esa dirección temporal como dirección de origen para conexiones salientes
- Mantiene también la dirección estable (EUI-64 o la derivada del RFC 7217) como dirección de respaldo
El ciclo de vida de las direcciones temporales
Las Privacy Extensions definen varios timers que controlan la vida útil de las direcciones:
| Parámetro | Valor típico | Descripción |
|---|---|---|
TEMP_VALID_LIFETIME |
7 días | Cuánto tiempo es válida la dirección |
TEMP_PREFERRED_LIFETIME |
24 horas | Cuánto tiempo se usa como origen preferido |
REGEN_ADVANCE |
5 segundos | Margen para generar nueva dirección antes de expirar |
El flujo práctico: el dispositivo genera una dirección temporal que usa activamente durante ~24 horas. Antes de que expire como “preferred”, genera una nueva. La dirección anterior sigue siendo válida (puede recibir tráfico) durante hasta 7 días, lo que permite que las conexiones existentes terminen normalmente sin interrupción.
Resultado: en cualquier momento, un dispositivo con Privacy Extensions puede tener varias direcciones IPv6 activas simultáneamente — la dirección estable (si existe) más varias temporales en diferentes estados del ciclo.
Qué ve el ISP desde el router de acceso
Desde la perspectiva de la red del ISP, Privacy Extensions produce un comportamiento que puede sorprender si no estás preparado:
Rotación de direcciones origen: Un mismo dispositivo cambia su dirección de origen cada ~24 horas. Si un cliente tiene 5 dispositivos, en una semana podés ver decenas de direcciones distintas activas en su prefijo /56 o /48.
Múltiples direcciones simultáneas: Cada dispositivo tiene coexistiendo la dirección estable y una o más temporales. Un router que examina el tráfico de un hogar puede ver 10-20 direcciones IPv6 activas para 3-4 dispositivos.
Duración efectiva de las entradas de log: Si un abuso ocurre y el ISP recibe una queja 48 horas después con la dirección IPv6 origen, la correlación con el cliente requiere buscar en logs de tiempo real — porque esa dirección ya puede no estar activa.
Neighbor Discovery: Los dispositivos generan solicitudes NDP (Neighbor Discovery Protocol) para cada dirección temporal nueva. En redes de acceso con muchos clientes, el volumen de NDP puede ser significativo si no está correctamente controlado.
Impacto operativo para el ISP: tres áreas críticas
1. Logs de abuso y compliance
En IPv4 con CGNAT o direcciones dinámicas, el ISP correlaciona una IP pública + timestamp con un cliente a través de los logs de asignación DHCP o traducción NAT. Con IPv6 nativo, el cliente tiene un prefijo asignado (ej: /56 o /48) y dentro de ese prefijo genera sus propias direcciones.
Para responder a una queja de abuso con una dirección IPv6 específica, el ISP necesita:
- Identificar a qué cliente pertenece el prefijo que contiene esa dirección (esto es sencillo, igual que IPv4)
- Si necesita identificar el dispositivo específico dentro del prefijo (lo que la mayoría de las regulaciones no requiere), necesita los logs de NDP del router de acceso
La regulación de retención de datos en la mayoría de los países LATAM aplica a la asignación de IP pública al cliente, no a las direcciones internas del prefijo del cliente. Identificar el prefijo /56 del cliente es suficiente para casi todos los requerimientos legales.
Recomendación operativa: Los logs de asignación de prefijo DHCPv6-PD (o de asignación estática si aplica) son los registros de compliance relevantes en IPv6. Asegurarse de que esos logs tengan retención adecuada y son consultables por timestamp.
2. Soporte técnico
Cuando un cliente llama porque tiene problemas de conectividad, el técnico de soporte necesita identificar qué dirección está usando. Con Privacy Extensions, el cliente tiene múltiples direcciones y la que usa varía por sesión.
Buenas prácticas para soporte:
- En lugar de trabajar con la dirección IPv6 específica del cliente, trabajar con el prefijo asignado
- Herramientas de gestión que permitan buscar por prefijo y ver todo el tráfico/estado NDP del prefijo
- Si el cliente puede ejecutar
ip -6 addroifconfig, pedir la lista completa de direcciones y verificar la conectividad del prefijo
3. Monitoreo y detección de anomalías
Los sistemas de detección basados en reputación de IP individual (listas negras, sistemas de scoring) funcionan mal con Privacy Extensions porque la dirección rota antes de que la reputación se acumule de forma significativa.
Para IPv6, las detecciones deben basarse en el prefijo del cliente o en comportamiento de tráfico, no en la dirección de origen específica. Esto es en realidad una mejora para el cliente: no puede ser mal categorizado por una dirección anterior de otro usuario que tuvo ese prefijo.
Cómo están configuradas las Privacy Extensions por sistema operativo
Windows (Vista y posteriores)
Activas por defecto. Windows también implementa el RFC 7217 para generar direcciones “estables pero opacas” (no basadas en MAC pero tampoco rotativas). Para deshabilitar:
netsh interface ipv6 set privacy state=disabled
Linux / Android
Configurado en /proc/sys/net/ipv6/conf/*/use_tempaddr:
- 0: deshabilitado
- 1: generado pero no preferido
- 2: generado y preferido (default en la mayoría de las distros modernas)
# Verificar estado actual
sysctl net.ipv6.conf.all.use_tempaddr
# Habilitar para todas las interfaces (permanente via /etc/sysctl.conf)
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
macOS / iOS
Activas por defecto desde OS X 10.7. iOS también usa direcciones MAC aleatorias por red Wi-Fi (MAC randomization), lo que agrega una capa adicional de opacidad.
Routers y dispositivos IoT
Comportamiento variable. Los routers domésticos (que usan SLAAC en su WAN) típicamente no implementan Privacy Extensions — usan la dirección EUI-64 estable en la interfaz WAN. Los dispositivos IoT dependen del firmware.
¿DHCPv6 stateful como alternativa?
Algunos ISPs optan por asignar direcciones IPv6 individuales a dispositivos mediante DHCPv6 stateful (similar a como funciona DHCP en IPv4) en lugar de confiar en SLAAC. Las ventajas:
- Control centralizado de las asignaciones
- Log exacto de qué dirección tiene cada dispositivo en cada momento
- Simplifica el soporte técnico
Las desventajas:
- Requiere infraestructura DHCPv6 escalable
- Muchos dispositivos IoT y algunos sistemas operativos tienen soporte DHCPv6 incompleto o con bugs
- No elimina el problema: muchos dispositivos ignoran la dirección DHCPv6 y generan igual una dirección SLAAC temporal para conexiones salientes
La recomendación de la comunidad de operadores es que DHCPv6-PD para asignación de prefijos al CPE es el mecanismo correcto, pero el manejo de direcciones dentro del prefijo del cliente debería dejarse al SLAAC del dispositivo — incluyendo Privacy Extensions. El ISP necesita solo el prefijo, no las direcciones individuales.
Lista de preparación operativa para IPv6 con Privacy Extensions
Para ISPs que están desplegando o madurando su implementación IPv6:
- ¿Los logs de asignación de prefijos DHCPv6-PD (o estáticos) tienen retención suficiente para cumplir obligaciones de retención de datos?
- ¿Las herramientas de soporte permiten buscar por prefijo, no solo por dirección?
- ¿El sistema de gestión de abuso puede responder a quejas con información de prefijo?
- ¿Los routers de acceso tienen logging NDP habilitado si se necesita identificación de dispositivo?
- ¿El equipo de soporte entiende por qué el cliente tiene “muchas IPs” en IPv6 y sabe cómo trabajar con eso?
- ¿Los sistemas de detección de anomalías trabajan con prefijos en lugar de IPs individuales?
IPv6 es el presente, no el futuro, para cualquier ISP que quiera operar de forma sostenible en Latinoamérica. Las Privacy Extensions son parte del ecosistema y no algo que se pueda o deba desactivar — diseñar las operaciones alrededor de ellas es la práctica correcta.
¿Estás migrando a IPv6 nativo o tenés problemas con los procesos de soporte y compliance en tu red IPv6 actual? Escribinos a [email protected] — acompañamos a ISPs en el diseño operativo de sus despliegues IPv6.