IPv6 Privacy Extensions: o que são, como funcionam e o que significam para sua rede ISP
Quando o IPv6 foi projetado nos anos 90, o SLAAC (Stateless Address Autoconfiguration, RFC 4862) era a solução elegante para o problema da autoconfiguração: os dispositivos derivam seu endereço IPv6 a partir do seu MAC address usando o formato EUI-64. Resultado: sem DHCP, sem configuração manual, com endereço único e estável por toda a vida.
O problema que ninguém pensou seriamente na época: um endereço derivado do MAC address é um identificador único e permanente. Um servidor web pode rastrear um usuário através de redes, sessões e tempo simplesmente correlacionando a parte do identificador de interface do endereço IPv6. O que no IPv4 requeria cookies ou fingerprinting, no IPv6 original era automático e inevitável.
As Privacy Extensions (RFC 4941) são a resposta padrão a esse problema. Desde que o Windows Vista as adotou como padrão em 2006, praticamente todos os sistemas operacionais modernos as têm ativas por padrão. Para os usuários, o resultado é melhor privacidade. Para os ISPs que operam redes IPv6, o resultado é uma complexidade adicional que precisa ser compreendida para ser bem gerenciada.
Como funciona o SLAAC: a raiz do problema
Antes de entender as Privacy Extensions, convém entender o mecanismo que elas substituem.
No SLAAC clássico com EUI-64, o dispositivo pega seu MAC address de 48 bits e o expande para 64 bits para criar o identificador de interface:
MAC: 00:1A:2B:3C:4D:5E
EUI-64: 02:1A:2B:FF:FE:3C:4D:5E
→ Endereço IPv6: 2803:9800:cafe:1::21a:2bff:fe3c:4d5e
O bit 7 do MAC (o bit “U/L”) é invertido, e FF:FE é inserido no meio. O resultado é um endereço que:
- É globalmente único (assumindo MACs únicos, que na prática geralmente são)
- Identifica o hardware de forma inequívoca
- É permanente enquanto o dispositivo não trocar sua interface de rede
- Segue o dispositivo independentemente do prefixo de rede que use
Uma análise de logs de qualquer servidor web com IPv6 pode correlacionar o mesmo identificador de interface aparecendo a partir de diferentes redes ao longo do tempo. É rastreamento de hardware gratuito e implícito.
RFC 4941: Privacy Extensions para SLAAC
O RFC 4941 (atualizado pelo RFC 8981 em 2021) introduz um mecanismo de geração de identificadores de interface temporários e aleatórios. Em vez de derivar o ID do MAC, o dispositivo gera um criptograficamente aleatório que rotaciona com o tempo.
Como o dispositivo gera os endereços temporários
O processo simplificado:
- Ao iniciar, o dispositivo gera um identificador de interface aleatório de 64 bits
- Com o prefixo /64 do roteador (obtido via Router Advertisement), forma um endereço temporário
- Verifica que não há conflito (DAD - Duplicate Address Detection)
- Usa esse endereço temporário como endereço de origem para conexões de saída
- Mantém também o endereço estável (EUI-64 ou o derivado do RFC 7217) como endereço de backup
O ciclo de vida dos endereços temporários
As Privacy Extensions definem vários timers que controlam a vida útil dos endereços:
| Parâmetro | Valor típico | Descrição |
|---|---|---|
TEMP_VALID_LIFETIME |
7 dias | Quanto tempo o endereço é válido |
TEMP_PREFERRED_LIFETIME |
24 horas | Quanto tempo é usado como origem preferido |
REGEN_ADVANCE |
5 segundos | Margem para gerar novo endereço antes de expirar |
O fluxo prático: o dispositivo gera um endereço temporário que usa ativamente durante aproximadamente 24 horas. Antes de expirar como “preferred”, gera um novo. O endereço anterior continua válido (pode receber tráfego) por até 7 dias, permitindo que as conexões existentes terminem normalmente sem interrupção.
Resultado: em qualquer momento, um dispositivo com Privacy Extensions pode ter vários endereços IPv6 ativos simultaneamente — o endereço estável (se existir) mais vários temporários em diferentes estágios do ciclo.
O que o ISP vê a partir do roteador de acesso
Da perspectiva da rede do ISP, as Privacy Extensions produzem um comportamento que pode surpreender se você não estiver preparado:
Rotação de endereços de origem: Um mesmo dispositivo muda seu endereço de origem a cada ~24 horas. Se um cliente tem 5 dispositivos, em uma semana você pode ver dezenas de endereços distintos ativos no seu prefixo /56 ou /48.
Múltiplos endereços simultâneos: Cada dispositivo tem coexistindo o endereço estável e um ou mais temporários. Um roteador que examina o tráfego de uma residência pode ver 10-20 endereços IPv6 ativos para 3-4 dispositivos.
Duração efetiva das entradas de log: Se um abuso ocorre e o ISP recebe uma queixa 48 horas depois com o endereço IPv6 de origem, a correlação com o cliente requer buscar nos logs em tempo real — porque esse endereço pode já não estar ativo.
Neighbor Discovery: Os dispositivos geram solicitações NDP (Neighbor Discovery Protocol) para cada novo endereço temporário. Em redes de acesso com muitos clientes, o volume de NDP pode ser significativo se não estiver corretamente controlado.
Impacto operacional para o ISP: três áreas críticas
1. Logs de abuso e compliance
No IPv4 com CGNAT ou endereços dinâmicos, o ISP correlaciona um IP público + timestamp com um cliente através dos logs de atribuição DHCP ou tradução NAT. Com IPv6 nativo, o cliente tem um prefixo atribuído (ex: /56 ou /48) e dentro desse prefixo gera seus próprios endereços.
Para responder a uma queixa de abuso com um endereço IPv6 específico, o ISP precisa:
- Identificar a qual cliente pertence o prefixo que contém esse endereço (isso é simples, igual ao IPv4)
- Se precisar identificar o dispositivo específico dentro do prefixo (o que a maioria das regulamentações não exige), precisa dos logs de NDP do roteador de acesso
A regulamentação de retenção de dados na maioria dos países LATAM se aplica à atribuição do IP público ao cliente, não aos endereços internos do prefixo do cliente. Identificar o prefixo /56 do cliente é suficiente para quase todos os requerimentos legais.
Recomendação operacional: Os logs de atribuição de prefixo DHCPv6-PD (ou de atribuição estática se aplicável) são os registros de compliance relevantes em IPv6. Certifique-se de que esses logs tenham retenção adequada e sejam consultáveis por timestamp.
2. Suporte técnico
Quando um cliente liga porque tem problemas de conectividade, o técnico de suporte precisa identificar qual endereço está usando. Com Privacy Extensions, o cliente tem múltiplos endereços e o que está em uso varia por sessão.
Boas práticas para suporte:
- Em vez de trabalhar com o endereço IPv6 específico do cliente, trabalhar com o prefixo atribuído
- Ferramentas de gestão que permitam buscar por prefixo e ver todo o tráfego/estado NDP do prefixo
- Se o cliente puder executar
ip -6 addrouifconfig, pedir a lista completa de endereços e verificar a conectividade do prefixo
3. Monitoramento e detecção de anomalias
Os sistemas de detecção baseados em reputação de IP individual (listas negras, sistemas de scoring) funcionam mal com Privacy Extensions porque o endereço rotaciona antes que a reputação se acumule de forma significativa.
Para IPv6, as detecções devem ser baseadas no prefixo do cliente ou no comportamento de tráfego, não no endereço de origem específico. Isso é na verdade uma melhoria para o cliente: não pode ser mal categorizado por um endereço anterior de outro usuário que teve esse prefixo.
Como as Privacy Extensions são configuradas por sistema operacional
Windows (Vista e posteriores)
Ativas por padrão. O Windows também implementa o RFC 7217 para gerar endereços “estáveis mas opacos” (não baseados em MAC mas tampouco rotativos). Para desabilitar:
netsh interface ipv6 set privacy state=disabled
Linux / Android
Configurado em /proc/sys/net/ipv6/conf/*/use_tempaddr:
- 0: desabilitado
- 1: gerado mas não preferido
- 2: gerado e preferido (padrão na maioria das distros modernas)
# Verificar estado atual
sysctl net.ipv6.conf.all.use_tempaddr
# Habilitar para todas as interfaces (permanente via /etc/sysctl.conf)
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
macOS / iOS
Ativas por padrão desde o OS X 10.7. O iOS também usa endereços MAC aleatórios por rede Wi-Fi (MAC randomization), o que adiciona uma camada adicional de opacidade.
Roteadores e dispositivos IoT
Comportamento variável. Os roteadores domésticos (que usam SLAAC na sua WAN) tipicamente não implementam Privacy Extensions — usam o endereço EUI-64 estável na interface WAN. Os dispositivos IoT dependem do firmware.
DHCPv6 stateful como alternativa?
Alguns ISPs optam por atribuir endereços IPv6 individuais a dispositivos mediante DHCPv6 stateful (similar a como funciona o DHCP no IPv4) em vez de confiar no SLAAC. As vantagens:
- Controle centralizado das atribuições
- Log exato de qual endereço cada dispositivo tem em cada momento
- Simplifica o suporte técnico
As desvantagens:
- Requer infraestrutura DHCPv6 escalável
- Muitos dispositivos IoT e alguns sistemas operacionais têm suporte DHCPv6 incompleto ou com bugs
- Não elimina o problema: muitos dispositivos ignoram o endereço DHCPv6 e geram igualmente um endereço SLAAC temporário para conexões de saída
A recomendação da comunidade de operadores é que DHCPv6-PD para atribuição de prefixos ao CPE é o mecanismo correto, mas o gerenciamento de endereços dentro do prefixo do cliente deveria ser deixado ao SLAAC do dispositivo — incluindo Privacy Extensions. O ISP precisa apenas do prefixo, não dos endereços individuais.
Lista de preparação operacional para IPv6 com Privacy Extensions
Para ISPs que estão implantando ou amadurecendo sua implementação IPv6:
- Os logs de atribuição de prefixos DHCPv6-PD (ou estáticos) têm retenção suficiente para cumprir obrigações de retenção de dados?
- As ferramentas de suporte permitem buscar por prefixo, não apenas por endereço?
- O sistema de gestão de abuso pode responder a queixas com informação de prefixo?
- Os roteadores de acesso têm logging NDP habilitado se for necessária identificação de dispositivo?
- A equipe de suporte entende por que o cliente tem “muitos IPs” em IPv6 e sabe como trabalhar com isso?
- Os sistemas de detecção de anomalias trabalham com prefixos em vez de IPs individuais?
IPv6 é o presente, não o futuro, para qualquer ISP que queira operar de forma sustentável na América Latina. As Privacy Extensions são parte do ecossistema e não algo que se possa ou deva desativar — projetar as operações em torno delas é a prática correta.
Está migrando para IPv6 nativo ou tem problemas com os processos de suporte e compliance na sua rede IPv6 atual? Escreva para [email protected] — acompanhamos ISPs no design operacional dos seus deploys IPv6.