Resumo

  • Reconfigure é um gatilho autenticado para o cliente iniciar Renew, Rebind ou Information-request; o envio não prova uma nova configuração.
  • A chegada ao servidor da solicitação pedida satisfaz a solicitação Reconfigure, mas Reply, instalação e consequência operacional continuam sendo recibos diferentes.

O verbo “enviado” costuma carregar mais certeza do que merece. Pela RFC 9915, o servidor emite Reconfigure para levar o cliente a iniciar uma das três trocas posteriores. Não está enviando o resultado dessa troca. Quando um relatório salta de “mensagem emitida” para “cliente atualizado”, apaga as verificações que o protocolo mantém em aberto.

Primeiro há a disposição do cliente e a validação. Reconfigure Accept informa ao servidor se o cliente aceita Reconfigure; na ausência dessa opção, o padrão é não aceitar. O cliente também deve descartar uma mensagem que não seja unicast, que não tenha os identificadores exigidos, a opção de mensagem adequada, um tipo válido ou autenticação válida. Logo, o log do servidor registra uma ação sua; não comprova que o destinatário recebeu uma mensagem utilizável.

Depois de receber uma Reconfigure válida, o cliente entra num passo distinto. A opção escolhe Renew, Rebind ou Information-request. O cliente inicia a troca indicada e descarta Reconfigure adicionais enquanto ela está em curso. O termo usado pela RFC — trigger — é deliberado: a mensagem aciona uma transação subsequente; não instala diretamente endereço, prefixo, resolvedor ou outro parâmetro.

O servidor pode obter uma confirmação mais limitada e ainda útil. Ao receber o Renew, Rebind ou Information-request que solicitou, ele interpreta que sua solicitação Reconfigure foi satisfeita. Isso autoriza a frase “o servidor recebeu o tipo de mensagem pedido”. Não autoriza “o cliente foi reconfigurado”. A mensagem recebida é a solicitação de outra troca, cujo processamento e Reply têm seus próprios fatos.

Renew, Rebind e Information-request tampouco produzem a mesma conclusão. Os dois primeiros têm regras próprias de binding e seleção; o último pede informação sem pedir endereços ou prefixos. O Reply é o objeto que pode carregar informação de configuração em cada troca. Um relatório sobre uma mudança específica precisa desse Reply e das opções/IA correspondentes. Um relatório sobre instalação no sistema, rota escolhida, uso de DNS, tráfego ou aplicação exige também uma observação onde esse resultado ocorreu.

A autenticação da Reconfigure protege um limite específico. A RFC 9915 a exige pelo risco de negação de serviço. A RFC 9096, também com Volz entre os autores, oferece contexto de segurança e privacidade para DHCPv6. Isso não transforma uma mensagem autenticada em prova de disponibilidade ou êxito de ponta a ponta.

Um registro auditável mantém DUID do cliente, identificador do servidor, envio e validação, msg-type pedido, solicitação correspondente recebida pelo servidor, Reply e campos relevantes. Se houver alegação operacional, junta-se uma observação independente de instalação ou execução. O registro da IANA identifica códigos DHCPv6; não confirma automaticamente as etapas que vêm depois deles.

As notas de Heng Lu sugerem a disciplina adequada: guardar o menor fato realmente visto. “O servidor enviou Reconfigure” e “o servidor recebeu a solicitação pedida” são afirmações úteis. Chamar ambas de “cliente configurado” substitui evidência por expectativa. Volz aparece como coautor de um padrão coletivo, não como responsável por uma frota real de clientes, servidores ou redes.

Fontes