Resumo

  • O cliente DHCPv6 envia Confirm ao perceber uma mudança de rede para saber se os endereços que já possui ainda são adequados ao enlace atual. Ele não escolhe o servidor que concedeu esses endereços.
  • Uma resposta Success abrange todos os endereços enviados, mas ignora T1, T2 e os tempos de vida preferencial e válido. Ela não repõe um segundo sequer na concessão.
  • O desenho documentado por Tomek Mrugalski e os demais autores do RFC 9915 separa três provas: pertinência ao enlace, autoridade sobre a concessão e funcionamento do caminho. Juntá-las num único sinal verde cria uma promessa que o protocolo nunca fez.

A mudança de rede abre uma pergunta estreita

Um computador fecha a tampa no escritório, acorda em outra rede e ainda conserva endereços IPv6 recebidos anteriormente. As informações do enlace mudaram. Antes de abandonar o que tem, o cliente DHCPv6 pode emitir uma mensagem Confirm.

O verbo convida a uma leitura ampla demais. A pergunta real não é “minha configuração inteira continua válida?”. É “estes endereços são apropriados para o enlace em que estou agora?”. A diferença decide o significado de qualquer resposta.

O RFC 9915 reserva Confirm a clientes que possuem endereços, mas não prefixos delegados. A mensagem inclui o identificador do cliente e as associações de identidade com todos os endereços relevantes. Não inclui um identificador de servidor. Se o cliente tentar dirigir a consulta a um servidor específico, o servidor deve descartá-la.

Essa ausência é parte do protocolo. O cliente não está voltando ao emissor original para negociar tempo; está apresentando um conjunto de endereços a quem tenha conhecimento suficiente dos prefixos válidos naquele enlace. Qualquer servidor apto pode responder.

Há três resultados operacionais. Se todos os endereços forem apropriados, chega Success. Se ao menos um não for, chega NotOnLink. Se o servidor não tiver informação para decidir, ou se a mensagem não trouxer endereço, ele permanece em silêncio. Tempo esgotado não é uma terceira forma de aprovação: é falta de veredito.

Os relógios viajam na mensagem para não governar a resposta

O detalhe mais revelador está nos campos de tempo. O RFC orienta o cliente a colocar zero em T1 e T2 nas opções IA_NA e zero nos tempos preferencial e válido das opções IA Address, porque o servidor os ignorará.

Não se trata de preencher um formulário incompleto. É uma fronteira de autoridade. Os endereços estão ali como elementos de uma prova topológica; os prazos não estão sendo submetidos a renovação. Um servidor pode conhecer o prefixo correto do enlace sem possuir o registro que concedeu aquela associação ao cliente.

Renew faz outra coisa. Quando T1 chega, o cliente procura o servidor que lhe forneceu a concessão. Esse servidor consulta o vínculo e pode devolver novos T1, T2 e tempos preferencial e válido. Se não houver resposta até T2, Rebind abre a tentativa a servidores disponíveis capazes de assumir a prorrogação.

Os códigos de mensagem registrados pela IANA — 4 para Confirm, 5 para Renew e 6 para Rebind — não são sinônimos numerados. Cada operação distribui a decisão de modo diferente:

  • Confirm permite que um servidor informado sobre o enlace julgue a adequação dos endereços.
  • Renew pede ao servidor concedente uma nova decisão sobre a duração.
  • Rebind busca outra autoridade quando o primeiro caminho de renovação falhou.

Reconhecer um código prova apenas que remetente e receptor usaram o mesmo vocabulário. Não prova que o respondente detinha o vínculo, que os prazos foram alterados ou que a rede transportou um pacote de aplicação.

O endereço continua; a ampulheta também

Depois de Success, o cliente pode continuar usando os endereços. Ele o faz com os últimos tempos de vida conhecidos. Nenhum prazo recomeça.

A mesma ação imediata pode ocorrer sem resposta. Encerrada a tentativa de Confirm sem um Reply válido, o RFC manda continuar usando concessões e demais parâmetros segundo os tempos já conhecidos. Portanto, ver o endereço ainda configurado não revela se houve aprovação ou silêncio.

Suponha que restassem trinta minutos de validade antes da consulta. Um Success não cria outros trinta minutos; ele apenas remove a dúvida sobre a presença do endereço naquele enlace. O relógio da concessão continua a partir da evidência anterior até que um Renew ou Rebind forneça novos valores.

O RFC 4862 mostra o que esses relógios produzem. Um endereço passa de preferencial a depreciado e, depois, a inválido. No estado depreciado, pode sustentar comunicações existentes, mas deve ser evitado para novas conexões. Quando inválido, deixa de servir como origem e de ser aceito como destino. Confirm não apaga essa sequência.

Há uma elegância operacional nessa regra. O cliente não sofre uma interrupção só porque nenhum servidor conseguiu avaliar a mudança naquele instante. Ao mesmo tempo, o protocolo não inventa uma extensão que ninguém autorizou. Continuidade provisória e renovação são fatos diferentes.

Um sim pode prevalecer sem transformar a resposta em votação

Como a solicitação não aponta um servidor, vários podem responder. O cliente pode usar os endereços se qualquer Reply válido trouxer Success, ignorando respostas NotOnLink. Só reinicia a descoberta quando recebe uma ou mais respostas e todas dizem NotOnLink.

Esse critério favorece continuidade, mas não significa que a maioria venceu. Dois servidores podem discordar porque enxergam revisões distintas da configuração, contextos diferentes de relay ou escopos administrativos incompletos. O protocolo aceita uma afirmação positiva utilizável; não declara que as demais observações eram falsas.

Para a operação, a discordância é mais valiosa que o total verde. Se um servidor disser Success e dois disserem NotOnLink, o registro deve conservar os três DUIDs, o caminho de relay, a interface, o conjunto de endereços, a base de prefixos de cada resposta e a decisão aplicada pelo cliente. Reduzir tudo a “Confirm concluído” apaga justamente o indício de uma configuração divergente.

O resultado também vale para o conjunto inteiro. Basta um endereço inadequado para a resposta ser NotOnLink; o status não identifica sozinho qual elemento falhou. Sem guardar o conjunto submetido, a equipe perde a unidade sobre a qual o servidor decidiu.

Cinco ausências que o painel precisa respeitar

Adequação ao enlace não é unicidade. Um endereço pode pertencer ao prefixo correto e falhar na Detecção de Endereço Duplicado.

Adequação ao enlace não é alcançabilidade do vizinho. A Detecção de Inalcançabilidade de Vizinho, definida no RFC 4861, observa outro estado e usa outras mensagens.

Adequação ao enlace não é roteamento fim a fim. O servidor pode reconhecer um prefixo mesmo quando uma rota ascendente está ausente, filtrada ou mal anunciada.

Adequação ao enlace não é continuidade da aplicação. Uma concessão válida não reabre uma sessão de transporte nem garante resposta do destino.

E adequação ao enlace não é prova do vínculo original. O servidor que responde pode saber onde o prefixo pertence sem ter o registro da atribuição que outro servidor realizou.

Essas negativas preservam a utilidade da mensagem. Uma função pequena, compartilhada entre implementações, responde com precisão a uma questão. Unicidade, vizinhança, rota, aplicação e tempo permanecem sob seus próprios mecanismos.

Tomek Mrugalski entre o texto e o código em execução

O RFC 9915, hoje Internet Standard STD 102, foi escrito por Tomek Mrugalski, Bernie Volz, Michael C. Richardson, Sheng Jiang e Timothy Winters, com contribuição de uma comunidade maior. A autoria ajuda a localizar a história técnica; não dá a nenhum autor controle sobre a implementação de um fabricante ou a configuração de uma operadora.

Mrugalski é um ponto de observação especialmente útil porque sua trajetória pública atravessa especificação e implementação. O IETF Datatracker registra sua participação em vários RFCs de DHCP. O perfil escrito da ISC relata como o projeto acadêmico Dibbler se transformou numa implementação DHCPv6 e como, mais tarde, ele trabalhou no desenvolvimento do Kea. É contexto profissional datado, não certificado de conformidade para cada versão de software.

A separação feita pelo protocolo se aproxima da ideia de Heng Lu sobre uma Especificação Inicial Mínima: padronizar o menor fato necessário à coordenação e deixar decisões posteriores com quem possui o contexto local. Aqui, o fato comum é a adequação dos endereços ao enlace. O vínculo e seus prazos continuam em outro domínio.

A Primazia do Código em Execução acrescenta uma exigência ao observador. O nome Confirm não basta; importa qual ramo o cliente realmente percorreu. Success, somente respostas NotOnLink e ausência de resposta podem produzir telas parecidas por algum tempo, mas conduzem a estados posteriores diferentes.

O problema de agência aparece quando cada participante controla apenas um pedaço do recibo. O fabricante pode expor uma métrica barata de sucesso. A operadora administra os prefixos do enlace e o relay. O serviço DHCP conserva o vínculo. O usuário absorve a interrupção quando a validade termina. Se a métrica mais simples representar todos esses compromissos, quem menos arca com a falha passa a definir a promessa.

Seis recibos para uma permanência honesta

O primeiro recibo registra a mudança: interface, informações antigas e novas de roteador ou enlace, estado do cliente e instante. Sem ele, a consulta fica separada do evento que a justificou.

O segundo congela a concessão anterior: DUID do servidor concedente, IAID, endereço, momento da obtenção, T1, T2, tempos preferencial e válido e segundos restantes. Esse é o relógio que continua correndo.

O terceiro registra a solicitação: DUID do cliente, identificador da transação, todos os endereços, interface e ausência do Server Identifier. A ausência mostra que se tratava de uma pergunta sobre o enlace.

O quarto conserva cada resposta: DUID do respondente, relay, contexto do enlace, status e revisão dos prefixos consultados. Nenhuma resposta deve aparecer como expiração da tentativa, nunca como Success presumido.

O quinto explica a decisão agregada: existiu ao menos um Success, todas as respostas recebidas foram NotOnLink, ou não houve Reply válido. Registra também se o cliente continuou ou reiniciou a descoberta.

O sexto mantém as autoridades posteriores separadas: Renew ou Rebind, novos tempos, depreciação, invalidação, Detecção de Endereço Duplicado, vizinhança, rota e alcance. Esses fatos podem compor um serviço saudável, mas nenhum nasce retroativamente da palavra Success.

Uma descrição operacional fiel cabe numa linha: “endereços considerados adequados ao enlace pelo servidor S no instante T; prazos originais inalterados”. A linha é menos reconfortante que um selo verde e muito mais útil quando a concessão se aproxima do fim.

Fontes