Resumo

  • Na alocação normal, DHCPACK confirma o vínculo no servidor; o cliente só entra em BOUND após a verificação final de conflito. É uso por prazo, não propriedade.
  • O relógio governa a autoridade: em T1 o cliente renova com o servidor original, em T2 tenta rebind com outros e, no vencimento sem novo ACK, precisa parar de usar a configuração.
  • Um DHCPACK enviado em resposta a DHCPINFORM não aloca endereço algum, prova de que o nome da mensagem isolado não revela a natureza do ato.

Quando uma concessão ganha aparência de posse

Um equipamento entra na rede sem configuração IPv4 utilizável. Descobre servidores, recebe ofertas, pede uma delas e enfim obtém DHCPACK. Logo o endereço aparece, os aplicativos funcionam e os registros passam a associá-lo à atividade. Para quem observa a tela, a rede acabou de “dar” um endereço.

A RFC 2131 mantém outra descrição. O servidor selecionado compromete um vínculo entre o cliente e parâmetros de configuração. Mesmo assim, antes do uso o cliente faz uma última verificação de duplicidade no enlace. Se encontrar conflito, envia DHCPDECLINE e reinicia. A resposta positiva da base central não apaga evidência contrária no meio local.

Ralph Droms assina a RFC 2131. Seu perfil no IETF informa também que ele organizou, em 1989, o grupo de trabalho que desenhou o DHCP. É correto atribuir-lhe papel central na padronização dessa conversa com estados e prazos explícitos; não seria correto fazê-lo autor único de extensões posteriores, implementações comerciais e escolhas de cada rede.

A permissão inclui um relógio

O cliente pode sugerir endereço e duração, mas sua solicitação não obriga o servidor. A política do domínio decide o que será aceito, e DHCPACK devolve os parâmetros consentidos. O tempo da concessão é parte da autoridade, não um detalhe de apresentação.

Em T1, normalmente na metade do prazo, o cliente entra em RENEWING e envia DHCPREQUEST diretamente ao servidor original. Se a renovação falhar, T2 costuma chegar em sete oitavos da duração; em REBINDING, qualquer servidor disponível pode responder. São marcos relativos, e o servidor pode informar valores diferentes.

O vencimento é uma borda rígida. Sem novo DHCPACK antes do fim, a RFC 2131 exige que o cliente interrompa imediatamente o processamento de rede com aquele endereço, abandone a configuração e volte a INIT. O endereço poderá ser entregue a outro cliente. Uma autorização com término definido não equivale a posse perpétua.

Infinito continua sem ser escritura

A opção 51 da RFC 2132 admite todos os bits iguais a um como concessão infinita. Na prática, prazos longos ou infinitos proporcionam continuidade, diminuem renovações e podem parecer configuração estática. Durante uma concessão válida, além disso, DHCPACK expressa autoridade real do serviço de configuração daquele domínio.

O valor especial, porém, descreve ausência de vencimento programado. Não autentica a pessoa que opera o dispositivo, não cria direito perante outras redes e não impede o administrador de mudar a infraestrutura. Transformar duração em propriedade adiciona ao protocolo uma afirmação que seus campos não carregam.

A RFC 5227 preserva uma verificação independente. Antes de usar um endereço IPv4, o host sonda o enlace e reage caso encontre conflito. A detecção não substitui o servidor DHCP, mas mostra que o banco de concessões não é conhecimento perfeito do meio. Autorização no plano de controle e disponibilidade observada se complementam.

O ACK que não entrega endereço

DHCPINFORM oferece o teste mais simples contra conclusões baseadas só no tipo da mensagem. Um cliente já configurado por outro meio pede parâmetros locais adicionais. O servidor pode responder com DHCPACK, mas nessa troca não aloca endereço, não procura um vínculo, não preenche yiaddr e não inclui tempo de concessão.

A mesma mensagem participa, portanto, de ações diferentes. No fluxo de alocação ela pode confirmar um vínculo; em INFORM apenas entrega configuração. Um inventário que interpreta todo DHCPACK capturado como prova de atribuição cria uma origem falsa a partir de uma regra aparentemente prática.

A RFC 6842 aperfeiçoa a correspondência das respostas. Nos casos definidos, o servidor devolve o identificador do cliente em DHCPOFFER e DHCPACK, ajudando a reconhecer a qual troca a resposta pertence. O identificador técnico não autentica uma pessoa nem vira credencial de propriedade.

A verdade autorizada pelo servidor

Leasequery, na RFC 4388, expõe o ponto de vista do servidor. Um endereço pode ser ACTIVE, UNASSIGNED ou UNKNOWN e, quando ativo, trazer a duração restante. A consulta lê o estado sem mudar o vínculo. A resposta é autorizada quanto ao banco daquele servidor, não necessariamente quanto a todos os pacotes, equipamentos ou conflitos vistos no segmento.

Em uma investigação, atribuição de endereço e atribuição de conduta são proposições separadas. O histórico pode sustentar que um serviço autorizou certo identificador a usar um endereço durante um intervalo. Sozinho, não prova quem operava a máquina, que todo tráfego partiu dela ou que a conclusão vale fora das datas registradas.

Essa limitação não enfraquece DHCP como evidência. Histórico completo, identificadores, dados do relay, observação da camada de enlace, conflitos e relógios sincronizados formam juntos um relato mais forte. O erro não está em confiar no DHCPACK, mas em fazê-lo responder ao que nunca foi desenhado para afirmar.

Fontes