Resumo

  • Um lease dinâmico DHCPv4 contém três fronteiras: T1 inicia RENEWING com o servidor que fez a concessão, T2 inicia REBINDING por broadcast e o vencimento obriga o cliente a abandonar o endereço se nenhum DHCPACK tiver criado um novo período.
  • A revinculação aumenta a disponibilidade, mas não concede poder a qualquer servidor alcançável. Um servidor alternativo só pode estender o lease quando possui autoridade administrativa local e estado coerente sobre a vinculação.

A conexão continua; a autorização, não necessariamente

Um computador pode chegar a T1 sem produzir qualquer sintoma para seu usuário. As páginas abrem, a rota padrão responde e sessões antigas permanecem ativas. A mudança acontece no plano de controle: o cliente já começou a perguntar se poderá conservar sua configuração.

Se a primeira pergunta falhar, ele não descarta o endereço. Se o tempo apertar, também não insiste na mesma máquina até o último segundo. O conjunto de possíveis respondentes muda em etapas. Essa mudança é o mecanismo histórico que a expressão “renovação automática” costuma esconder.

O DHCP construiu tolerância a falhas sem transformar ausência de resposta em consentimento. Durante o período válido, o lease protege a continuidade. Depois do prazo, a mesma ausência produz o resultado oposto: não há mais permissão a preservar.

Endereços reutilizáveis precisavam de custódia temporária

O RFC 1541, de outubro de 1993, descreveu a alocação dinâmica do DHCP como a cessão de um endereço por tempo limitado ou até sua liberação explícita. A associação entre um cliente, um endereço e outros parâmetros é uma vinculação administrada pelos servidores.

O caráter revogável permitiu que um conjunto finito de IPv4 servisse clientes diferentes ao longo do tempo. A reutilização serial só funciona se uma entrega anterior não for confundida com propriedade permanente.

O RFC 2131, publicado em março de 1997, manteve alocação automática, dinâmica e manual. A automática pode ser permanente; a manual transporta uma escolha administrativa; a dinâmica depende do relógio do lease. É nesse terceiro modelo que os estados de renovação e revinculação definem como a configuração pode continuar.

Assim, o endereço não é um objeto isolado que o cliente “possui”. Ele participa de uma decisão temporária de configuração, regida por política local e conservada por um serviço.

O lease não tinha apenas um relógio

O RFC 2132 separa três opções. A 51 contém o tempo de lease do endereço; a 58, o Renewal Time Value T1; e a 59, o Rebinding Time Value T2. Todas representam segundos contados desde a atribuição, não datas civis.

Quando T1 e T2 válidos não são fornecidos, o RFC 2131 usa, como padrão, metade e sete oitavos do lease. Também recomenda alguma variação aleatória para que muitos clientes não tentem recuperar suas configurações no mesmo instante. São valores de contingência do protocolo, não uma recomendação universal para operadores.

A sequência expressa uma distribuição de riscos. T1 reserva bastante tempo para conversar com quem tomou a decisão original. T2 guarda uma última faixa para buscar outra autoridade. O vencimento não abre uma terceira forma de consulta: ele encerra a vinculação vigente.

Em T1, o cliente volta a quem conhece a decisão

Ao alcançar T1, o cliente em BOUND entra em RENEWING. Se conhece o endereço do servidor locador, envia a ele um DHCPREQUEST e coloca o endereço em uso no campo ciaddr. Não está comparando novas ofertas; está pedindo continuidade de uma decisão anterior.

Dar a primeira resposta ao locador conserva a responsabilidade pelo estado. Esse servidor conhece a vinculação que criou, as regras do conjunto de endereços e as alterações de configuração que devem acompanhar uma extensão. Pode responder com DHCPACK, mudar parâmetros ou não prolongar o lease conforme a política administrativa.

Uma tentativa sem resposta não revoga o endereço. Enquanto o período atual for válido, o cliente pode seguir usando-o e retransmitir de maneira limitada. Essa distinção evita que uma falha breve do servidor se torne uma queda imediata de tráfego. Ao mesmo tempo, o relógio continua correndo: silêncio não é uma extensão.

Em T2, o broadcast encontra alternativas — não cria autoridade

Sem DHCPACK até T2, o cliente entra em REBINDING. Ele transmite DHCPREQUEST por broadcast, conserva seu endereço em ciaddr e omite o identificador do servidor. Uma máquina diferente pode agora ouvir o pedido quando o locador original não consegue recebê-lo.

Mas ouvir o pacote não basta. O RFC 2131 admite que outro servidor estenda o lease somente se tiver autoridade administrativa local. O desenho pressupõe que uma instalação com vários servidores mantenha sua custódia e seu estado de leases consistentes.

Essa condição impede um atalho perigoso. Rebinding amplia o alcance do pedido para proteger disponibilidade, sem transformar alcançabilidade em delegação. Um servidor alternativo desatualizado pode acreditar que um endereço está livre enquanto o original o considera ocupado. O broadcast revela a divergência; não a resolve.

ACK, NAK e ausência de resposta produzem destinos distintos

Um DHCPACK recebido em RENEWING ou REBINDING estabelece a continuidade. O cliente registra os valores devolvidos e inicia novos temporizadores T1 e T2. Como a resposta pode alterar outros parâmetros, a renovação não é apenas somar segundos a uma data.

Um DHCPNAK informa que a configuração atual não é aceitável. O cliente precisa interromper o uso do endereço e voltar à inicialização. Persistir após essa negativa faria de uma lembrança local uma reivindicação concorrente contra o sistema que controla o conjunto.

O silêncio, enquanto ainda existe tempo, não é nenhum dos dois. Ele mantém o lease existente e provoca retransmissões limitadas. Se o vencimento chegar antes de um ACK, porém, o RFC 2131 exige retorno a INIT, interrupção do restante do processamento de rede e nova solicitação como cliente não configurado.

É possível que a porta continue ativa, vizinhos em cache respondam e roteadores encaminhem pacotes. Tais observações mostram que um caminho de dados ainda existe. Não demonstram que o cliente ainda tem autorização. O prazo separa uma recuperação malsucedida de um uso não autorizado.

Um endereço lembrado depois da reinicialização continuava sendo um pedido

Um cliente pode reiniciar lembrando o endereço anterior e acreditando estar na mesma rede. O caminho INIT-REBOOT permite solicitá-lo, mas não transforma memória persistida em direito vigente.

Como o cliente não sabe se o antigo servidor ou a antiga rede ainda são relevantes, envia a solicitação por broadcast. Um servidor pode confirmar com DHCPACK ou rejeitar com DHCPNAK. Na ausência de contato, o RFC 2131 só permite usar a configuração anterior durante a parte ainda não vencida do lease.

A continuidade após o reinício, portanto, precisa ser julgada. O protocolo tenta preservar uma configuração útil, mas recusa deduzir autoridade presente de um valor guardado pelo próprio interessado.

FORCERENEW deu ao servidor uma forma controlada de antecipar T1

No desenho original, os temporizadores do cliente acionavam a maior parte das mudanças. O RFC 3203 introduziu depois o FORCERENEW unicast, com o qual um servidor pode fazer o cliente entrar no fluxo normal de RENEW antes de T1, por exemplo para revisar uma configuração.

FORCERENEW não instala novos valores diretamente. Ele provoca um DHCPREQUEST comum. Se a intenção for retirar o endereço, o servidor ainda responde com DHCPNAK e conduz o cliente de volta à descoberta.

Como uma mensagem falsificada poderia interromper sessões repetidamente, o RFC 3203 exige autenticação segundo o RFC 3118. Mesmo a autoridade que deseja adiantar a revisão precisa provar a origem e usar uma transição reconhecível, em vez de reescrever silenciosamente o estado local.

A autorização do servidor não limpava a evidência do enlace

Um DHCPACK legítimo também não prova que nenhum outro host esteja usando o endereço no segmento local. A decisão do serviço de configuração e a observação do enlace são camadas de evidência diferentes.

O RFC 5227 determina que um host IPv4 sonde o endereço recém-configurado antes de começar a usá-lo. Ao detectar conflito, um cliente DHCP envia DHCPDECLINE. Uma evidência local contrária pode, assim, derrubar o plano de alocação do servidor.

O alcance probatório do lease é limitado: um serviço administrado associou aquele endereço ao cliente por um intervalo. Isso não autentica a pessoa por trás do equipamento, não demonstra propriedade jurídica, não garante conectividade ponta a ponta e não exclui uma duplicação no enlace.

Fontes e limites da evidência

As afirmações históricas e de protocolo vêm dos RFCs 1541, 2131, 2132, 3118, 3203 e 5227:

Eles definem um contrato DHCPv4. Não comprovam padrões atuais, desenho de failover, correção do cliente ou participação de mercado de produto ou rede específicos. DHCPv6 é outro protocolo. As frações padrão de T1 e T2 também não provam que todo servidor as envie ou todo cliente as adote.