Resumo

  • O RFC 9686 amplia a visibilidade da infraestrutura DHCPv6 sobre endereços IPv6 autogerados por SLAAC ou configurados estaticamente. O dispositivo escolhe o endereço; segundo o RFC 9915, o servidor cria uma lease para representar o ciclo de vida do registro, sem que isso transforme o endereço em uma atribuição DHCPv6.
  • A cobertura depende de capacidade anunciada no enlace, suporte do cliente, entrega das mensagens e conservação dos dados. Depois que o suporte é descoberto, o comportamento de registro é normativamente definido; ainda assim, um dispositivo malicioso ou comprometido pode omitir a mensagem.
  • Para SLAAC, calcular NextAddrRegRefreshTime com base em 80% da Valid Lifetime e fator de 0,9 a 1,1 não agenda, por si só, uma atualização. O agendamento ocorre quando a rede altera a Valid Lifetime em mais de 1%; se a expiração esperada apenas continuar sua contagem regressiva, talvez nenhum refresh seja enviado.
  • O ADDR-REG-REPLY confirma somente o recebimento do ADDR-REG-INFORM e encerra retransmissões. Não comprova binding, retenção, validade, identidade, alcance, uso contínuo, tráfego observado ou autoridade para agir.

O preço de enxergar endereços que o servidor não escolheu

A autoconfiguração sem estado permite que um dispositivo forme endereços IPv6 a partir das informações anunciadas no enlace, sem pedir a um servidor DHCPv6 que selecione cada endereço. Essa independência é parte do desenho do IPv6, mas retira do servidor uma visibilidade que operações de rede aprenderam a esperar dos arquivos de leases IPv4.

O RFC 9686, publicado em dezembro de 2024 como Standards Track do IETF, reduz essa lacuna. Um dispositivo pode informar à infraestrutura DHCPv6 que usa um endereço formado por SLAAC ou configurado estaticamente. Ferramentas e processos construídos ao redor do DHCPv6 passam, assim, a receber informação sobre endereços cuja seleção ocorreu fora do servidor.

A terminologia precisa ser exata. A seção 6.6 do RFC 9915, que substituiu o RFC 8415, diz que o servidor cria uma lease, que o dispositivo realiza ações periódicas relacionadas à sua renovação e que a lease pode expirar. A mesma seção ressalta a característica específica do mecanismo: quem seleciona o endereço é o dispositivo, não o servidor DHCPv6.

Há, portanto, uma lease no servidor, mas não uma atribuição daquele endereço pelo DHCPv6. A lease representa o ciclo de vida do registro. Ela não muda a origem da seleção do endereço nem prova que o servidor o concedeu. Essa lease também deve ser distinguida do binding entre Client Identifier e endereço IPv6 descrito pelo RFC 9686: criar o binding é uma recomendação normativa, um SHOULD, e não uma obrigação absoluta.

A diferença afeta o uso da evidência. Uma lease originada no registro de uma declaração do cliente não deve ser interpretada como se o servidor tivesse escolhido, oferecido e atribuído o endereço por DHCPv6 stateful. O RFC 9686 amplia a observação centralizada sem retirar do SLAAC sua lógica distribuída.

A capacidade de registro tem geografia

O registro não começa por presunção. O cliente solicita a opção OPTION_ADDR_REG_ENABLE nas trocas DHCPv6 pertinentes. Um servidor configurado para oferecer o mecanismo inclui essa opção em Advertise ou Reply. Se não receber o sinal, o cliente não deve enviar registros, evitando multicast desnecessário.

Essa regra cria uma dimensão de cobertura que precisa ser contabilizada. O cliente descobre o suporte em cada interface e repete a descoberta quando se conecta a uma rede ou detecta mudança de enlace. Saber que a organização ativou o recurso em algum lugar não permite concluir que todos os enlaces, caminhos de relay e dispositivos estejam cobertos.

Depois de descobrir o suporte, o cliente deve iniciar o registro, salvo se estiver configurado para não fazê-lo, e registrar imediatamente endereços já em uso. Uma vez iniciado o processo naquele enlace, não deve interrompê-lo apenas porque mensagens posteriores deixaram de conter OPTION_ADDR_REG_ENABLE. Não se trata, portanto, de qualificar todo o protocolo como voluntário: há requisitos claros após a descoberta da capacidade. A limitação de segurança é outra — um host malicioso ou comprometido pode desobedecer e simplesmente não informar seus endereços.

O cliente envia um ADDR-REG-INFORM separado para cada endereço válido de escopo global gerado por SLAAC ou configurado estaticamente, inclusive Unique Local Addresses. Endereços link-local ficam fora do mecanismo, assim como endereços atribuídos pelo próprio DHCPv6. Cada mensagem contém Client Identifier e exatamente uma opção IA Address.

A mensagem deve sair do endereço registrado e pela interface à qual ele está atribuído. Sem relay, a IA Address precisa coincidir com a origem do pacote. Com relay, deve coincidir com o peer-address do Relay-forward mais interno. Essa correspondência confronta o conteúdo declarado com o contexto de chegada. Quando a rede também aplica controles adequados de camada 2, a confiança pode aumentar; a regra isolada, contudo, não autentica uma pessoa ou um equipamento incorruptível.

A cobertura observada continua diferente da população real. Um endereço registrado demonstra participação no mecanismo. A falta de registro pode decorrer de ausência de suporte, configuração administrativa, incompatibilidade, perda de pacotes ou omissão deliberada. Transformar silêncio em prova de ausência seria superestimar o alcance da coleta.

As obrigações do servidor não têm todas o mesmo peso

O servidor deve descartar mensagens que não contenham Client Identifier, tragam Server Identifier ou Option Request indevidos, omitam IA Address ou apresentem divergência entre o endereço declarado e a origem relevante.

Se a mensagem não tiver sido descartada nesses testes, o servidor deveria verificar se o endereço é apropriado ao enlace ou pertence a um prefixo delegado ao cliente por DHCPv6 Prefix Delegation. Essa verificação é SHOULD. Se for executada e falhar, a mensagem deve ser descartada, e o servidor deveria registrar a falha.

Para um registro aceito, o RFC 9686 estabelece resultados com forças normativas distintas:

  • o servidor deve registrar o evento, salvo se estiver configurado para não fazê-lo;
  • deveria criar um binding entre Client Identifier e endereço IPv6;
  • deveria marcar o endereço como indisponível para atribuições futuras;
  • deve enviar um ADDR-REG-REPLY.

O servidor deveria registrar também o DUID e, quando disponível, o endereço da camada de enlace. Se já existir um binding para o mesmo cliente e endereço, deve atualizar sua vida útil. Se o endereço estiver associado a outro cliente, deveria registrar o conflito e atualizar o binding.

Essas diferenças impedem que o reply seja usado como atalho interpretativo. A resposta é obrigatória para uma mensagem aceita, mas o binding continua sendo SHOULD e o log obrigatório admite configuração contrária. Logo, um ADDR-REG-REPLY não comprova que exista associação persistente consultável nem que o evento permanecerá retido.

O significado da resposta é deliberadamente estreito: o servidor recebeu o ADDR-REG-INFORM, e o cliente deve parar de retransmiti-lo. O reply não atesta validade do endereço e não é necessário para que ele seja usado. Relays ou outros equipamentos que observem a resposta não devem criar nem alterar estado de encaminhamento ou segurança com base nela.

O relógio do SLAAC não funciona como um timer periódico simples

O tratamento temporal dos endereços SLAAC é mais sutil do que uma leitura apressada da fórmula de 80% sugere. Ao registrar ou atualizar um endereço, o cliente calcula NextAddrRegRefreshTime a partir de 80% da Valid Lifetime corrente, multiplicados por um fator aleatório entre 0,9 e 1,1. Essa variação reduz sincronização entre clientes.

O cálculo, porém, não agenda inicialmente um refresh. Ele estabelece uma referência temporal. Quando a rede altera a Valid Lifetime em mais de 1%, o cliente recalcula o intervalo e agenda a atualização para o menor valor entre o novo momento calculado e o NextAddrRegRefreshTime anterior. Se o instante de expiração esperado não mudar — por exemplo, quando os lifetimes anunciados apenas diminuem acompanhando a passagem do tempo — não há necessidade de atualização, e nenhum refresh pode ser enviado.

Assim, a passagem do ponto correspondente a 80% não demonstra que uma atualização deveria ter aparecido nem que sua ausência representa perda. A pergunta correta é se a rede alterou o vencimento esperado do endereço de modo a acionar o agendamento. A tolerância de 1% evita reagir a pequenas diferenças causadas por atraso de transmissão ou desalinhamento de relógios.

Endereços configurados estaticamente seguem outra regra. Como têm Valid Lifetime infinito no modelo, seu próximo refresh é programado segundo StaticAddrRegRefreshInterval, cujo padrão é quatro horas e deveria ser configurável. O cliente também pode informar que deixou de usar um endereço enviando Preferred Lifetime e Valid Lifetime iguais a zero; o servidor deve então tratá-lo como expirado.

Quando o binding entre Client Identifier e endereço expira, o servidor deve removê-lo e considerar o endereço novamente disponível. Isso é expiração do estado operacional. Não determina, por si só, o prazo de retenção de logs históricos. Confundir as duas coisas cria um falso dilema: ou manter para sempre um binding ativo, ou perder toda evidência. A base operacional pode remover estado vencido enquanto um repositório controlado conserva eventos pelo período definido na política de retenção.

Rotação de endereços muda a unidade de custo

Um dispositivo pode usar vários endereços IPv6 no mesmo prefixo, inclusive endereços de privacidade que se sucedem ao longo do tempo. Cada endereço relevante gera seu próprio registro. A unidade observada deixa de ser “um equipamento, um endereço” e passa a ser uma coleção temporal de endereços, lifetimes, interfaces e identificadores.

Isso aumenta armazenamento e trabalho de reconciliação. Também eleva o custo de uma política mal desenhada. Preservar somente o endereço sem Client Identifier, tempo, enlace e contexto de relay economiza bytes, mas elimina relações úteis. Conservar todos os identificadores indefinidamente preserva mais possibilidades de correlação, mas aumenta exposição e capacidade de rastreamento.

O RFC 9686 observa que mensagens de registro contêm identificadores únicos, como DUID, que podem permitir a correlação de endereços com o mesmo cliente, inclusive quando há endereços MAC aleatórios. Retenção precisa, portanto, ter finalidade, duração e controle de acesso definidos. O objetivo não é maximizar a memória institucional da rede, mas manter contexto suficiente durante uma janela justificada.

Volume sem reconciliação é uma falsa economia

Amostragem e agregação podem reduzir o custo de telemetria. O RFC 9099 reconhece o valor do IPFIX e de sua capacidade de agregar fluxos. Ainda assim, toda redução precisa ser avaliada pela pergunta que permanecerá respondível depois dela.

Uma lease de registro indica que o servidor criou estado de ciclo de vida para um endereço declarado pelo dispositivo. Não prova que determinado pacote passou por um sensor. Um registro de fluxo mostra tráfego observado em certo ponto, mas não identifica sozinho quem controlava o dispositivo. Se a amostragem omitir o fluxo relevante, a lease não recria essa observação. Se a retenção eliminar o contexto do registro, o fluxo preservado perde parte de sua capacidade de atribuição.

O RFC 9099 recomenda combinar fontes como logs de aplicações, IPFIX, dados de gerenciamento, histórico do Neighbor Cache, DHCPv6, SAVI, tabelas de switches, firewall, autenticação e RADIUS. O formato canônico dos endereços também é importante, porque um mesmo IPv6 admite diferentes representações textuais e pode escapar de correlações literais.

O Neighbor Cache relaciona endereços IPv6 a identificadores da camada de enlace, mas é dinâmico e precisa ser coletado de modo que não exaura recursos do roteador. Arquivos DHCPv6 podem conter DUIDs opacos ou ligados a uma interface diferente da usada no evento. Registros de autenticação aproximam uma sessão de uma credencial, sem provar necessariamente autoria humana. O valor aparece quando as fontes são reconciliadas no tempo, preservando as limitações de cada uma.

Um esquema probatório proporcional deveria incluir, conforme a finalidade:

  • endereço IPv6 em formato canônico e forma de configuração;
  • Client Identifier, DUID e endereço de camada 2, quando disponíveis;
  • criação da lease, atualizações, expiração e eventual encerramento;
  • binding efetivamente criado, distinguindo-o da simples resposta;
  • Preferred Lifetime, Valid Lifetime e mudanças relevantes;
  • transaction ID e timestamps da troca;
  • relay, peer-address, interface e contexto do enlace;
  • verificações realizadas, descartes e conflitos;
  • fonte independente que observou o tráfego;
  • associações posteriores com porta, ativo, sessão ou assinante;
  • proveniência, sincronização temporal, acesso e retenção de cada conjunto.

A pergunta orçamentária útil deixa de ser “quantos eventos cabem?” e passa a ser “quais relações ainda poderão ser demonstradas quando surgir a investigação?”.

Sobrecarga e valor marginal dos registros

O desenho reduz sobrecarga ao exigir descoberta prévia de capacidade, dessincronizar os cálculos de SLAAC, estabelecer intervalo para endereços estáticos e permitir a consolidação de atualizações próximas. Isso não elimina flooding.

Um atacante pode registrar muitos endereços rapidamente para sobrecarregar o servidor ou ocupar arquivos de log. Um cliente defeituoso pode produzir efeito semelhante. O custo inclui processamento, armazenamento e deterioração da qualidade analítica quando a equipe não consegue separar comportamento legítimo, falha e abuso.

Controles de capacidade e taxa podem proteger o serviço, mas precisam deixar evidência de seus próprios descartes. Caso contrário, o sistema parece completo justamente quando a pressão reduziu sua cobertura. O mesmo vale para amostragem: a economia só é mensurável se a organização souber que dados deixou de conservar e quais conclusões ficaram indisponíveis.

Contar ADDR-REG-INFORM ou ADDR-REG-REPLY mede atividade do protocolo, não valor probatório. Volume alto pode refletir numerosos endereços, mudanças de lifetime ou ataque. Volume baixo pode indicar estabilidade, baixa adoção, perda de mensagens ou hosts silenciosos. Sem informação sobre enlaces habilitados, clientes capazes, falhas de validação e retenção efetiva, o total bruto é uma métrica pobre.

Fontes