Resumo

  • Um LEASEQUERY-REPLY bem-sucedido pode trazer dados, apontar para novas consultas ou vir vazio; ele descreve conhecimento do servidor, não presença do dispositivo.
  • A decisão defensável precisa registrar o conjunto de servidores, cada variante de resposta, a reconciliação, o estado local e o efeito observado de forma independente.

Uma linha verde chega ao painel antes da decisão: a consulta DHCPv6 terminou com sucesso. Se o sistema traduz a linha para “dispositivo presente”, ele responde a uma pergunta que o protocolo não recebeu.

O RFC 5007 define Leasequery para recuperar, de maneira leve, informações de vínculo em um servidor DHCPv6. O texto diz expressamente que a mensagem só consulta; ela não altera endereço, prefixo ou vínculo. Portanto, a resposta é uma representação do estado mantido pelo servidor.

No exemplo sob demanda, um concentrador observa um pacote IPv6 e quer atualizar o vínculo do cliente ao qual o endereço foi alugado. O pacote aciona a consulta. A resposta não transforma esse pacote em tráfego legítimo nem garante que o terminal continue acessível.

Há três êxitos. OPTION_CLIENT_DATA fornece vínculos para atualizar a memória local. OPTION_LQ_CLIENT_LINK informa vários links e exige novas consultas para cada um. A ausência de ambas as opções significa que aquele servidor não encontrou vínculo, ainda que a troca tenha sido bem-sucedida. Dados, lista de trabalho e vazio não cabem honestamente no mesmo indicador.

Erros também não equivalem a ausência. A política local pode escolher outro servidor, corrigir a consulta, consultar vários ou encerrar. O solicitante deve procurar o servidor reconhecido como autoritativo; se não souber qual é, deve consultar todos os conhecidos ou configurados. Encerrar cedo pode proteger recursos, mas não produz concordância entre autoridades.

As respostas podem ser complementares ou conflitantes. Dados diferentes, como endereço e prefixo delegado, devem ser combinados. O mesmo valor vindo de servidores distintos é sobreposição e conflito; o RFC recomenda preferir o OPTION_CLT_TIME mais recente.

Os errata verificados corrigem uma armadilha. O erratum técnico 3763 remove a orientação original de descartar dados sem OPTION_CLT_TIME. Um parceiro de failover pode conhecer o vínculo sem ter realizado a última transação com o cliente. Havendo outra resposta com tempo, ela é preferível; sendo a única resposta, a versão sem tempo ainda pode ser aceita. O erratum editorial 4816 corrige OPTION_CLIENT_LINK para OPTION_LQ_CLIENT_LINK.

Esse tempo mede quanto passou desde a última transação conhecida pelo servidor quando ele gera a resposta. Não é um pulso do equipamento, uma credencial da pessoa, um atestado da origem do pacote ou a saída de uma autorização. Ser o dado mais recente entre os recebidos não significa estar online agora.

A delegação de prefixos mostra o custo da dependência circular. Depois de reiniciar, o concentrador talvez não consiga anunciar a rota; sem rota, não chega o tráfego que iniciaria a consulta sob demanda. O RFC 5007 cita uma reconstrução antecipada, mas não a especifica. O RFC 5460 define depois Bulk Leasequery, e o RFC 7653, Active Leasequery. Uma consulta pontual não herda recuperação integral nem atualização contínua.

Autenticação reduz o universo de participantes, não prova o conteúdo. Relés confiáveis podem carregar consultas de origem não confiável; servidores podem restringir consultas retransmitidas ou omitir dados até para solicitantes confiáveis. Um servidor malicioso pode devolver vínculos ou rotas incorretos.

O cache negativo também é política de carga. Ele memoriza que uma consulta recente não retornou dados para evitar repetição e negação de serviço. Tem prazo e escopo; não prova que não existe dispositivo, vínculo ou usuário autorizado.

Um comprovante de visão de vínculo deve guardar:

  1. gatilho, tipo de consulta, endereço ou DUID e link;
  2. conjunto autoritativo pretendido e servidores realmente contatados;
  3. solicitações, respostas, autenticação, retransmissão, tentativas e motivo de parada;
  4. variante exata da resposta e campos restringidos;
  5. expansão de links e consultas pendentes;
  6. combinação de dados distintos e resolução de conflitos;
  7. presença de OPTION_CLT_TIME e regra usada;
  8. cache negativo e revisão do estado local;
  9. decisão de rota, filtro ou acesso e o resultado observado à parte.

É uma recomendação de governança, não uma exigência oculta do RFC. A disciplina de camadas da realidade de Heng Lu mantém separados registro do servidor, troca, estado local, ato de controle e efeito.

O RFC 7513 mostra Leasequery apoiando recuperação de vínculos SAVI sem transformar vínculo em identidade humana. O contexto está nos RFC 3315, RFC 3633 e no antecedente IPv4 RFC 4388. Os RFC 8415 e RFC 9915 não apagam o limite probatório da troca capturada.

Fontes