Concessões e Renovação (Lease Time)

1. Definição de Lease Time

Um lease (concessão) no DHCP é o contrato temporário que atribui um endereço IP a um cliente por um período determinado. O lease time é a duração desse contrato em segundos. Quando o tempo expira sem renovação, o servidor pode reatribuir o IP a outro cliente. Esse mecanismo evita o esgotamento do pool de IPs em redes onde hosts entram e saem constantemente (redes Wi-Fi corporativas, hotéis, aeroportos).

O lease não é apenas o IP — junto vêm todas as opções DHCP (máscara, gateway, DNS, NTP, etc.). Renovar o lease renova todas essas configurações, permitindo ao administrador alterar, por exemplo, o DNS da rede e ver todos os clientes migrando em até T1 segundos.

2. Valores Típicos e Estratégia

Cenário	Lease time típico	Justificativa
Rede corporativa fixa (desktops)	24 horas (86400s)	hosts estáveis, pool grande
Rede Wi-Fi corporativa	8 horas (28800s)	rotatividade moderada
Hotspot público / aeroporto	30 minutos (1800s)	alta rotatividade
Café / restaurante	1-2 horas	clientes de passagem
Datacenter / servidores	∞ ou IP estático	servidores não móveis
ISP residencial via DHCP	24h a 7 dias	modem raramente desliga
Pool escasso (IPv4 ISP)	1-2 horas	reaproveitamento rápido

Por que não usar lease infinito?

• IP não é mais recuperado até Release explícito — esgota o pool rapidamente em redes dinâmicas.
• Mudanças de configuração (DNS, gateway) demoram a propagar.
• Perde-se a flexibilidade operacional.

Por que não usar lease muito curto (1 minuto)?

• Aumenta tráfego DHCP (renovações constantes).
• Em queda temporária do servidor DHCP, todos os clientes perdem IP em minutos.
• Maior carga de CPU nos servidores.

O ponto ótimo é o equilíbrio entre rotatividade do pool e estabilidade dos clientes. Para uma rede Wi-Fi de empresa típica, 4-8 horas é o padrão.

3. Timeline de Renovação: T1 e T2

O RFC 2131 define dois marcos temporais dentro de cada lease:

T0 (Ack) -------- T1 (50%) -------- T2 (87.5%) -------- T_exp (100%)
   |                  |                    |                  |
   | Renovação unicast| Rebind broadcast   | Libera IP        |
   | (com servidor    | (qualquer servidor)| e recomeça DORA  |
   |  original)       |                    |                  |

T1 = 0.5 × Lease Time (Renew)

No tempo T1, o cliente inicia a renovação enviando uma mensagem DHCPREQUEST unicasting diretamente ao servidor que originalmente concedeu o lease (identificado pela opção 54 Server Identifier). O servidor pode:

• Responder DHCPACK com o mesmo IP e lease time renovado (renovação bem-sucedida). O timer reinicia em T0.
• Responder DHCPNAK indicando que o IP não pode mais ser renovado (por exemplo, foi movido para outra subnet). O cliente libera o IP imediatamente.
• Não responder. Nesse caso, o cliente tenta novamente em intervalos crescentes até atingir T2.

T2 = 0.875 × Lease Time (Rebind)

Se T1 falhou (servidor original indisponível), no tempo T2 o cliente muda de estratégia: envia DHCPREQUEST em broadcast, endereçado a qualquer servidor DHCP na rede. Outro servidor pode assumir o lease:

• Renovando o mesmo IP se tiver jurisdição sobre aquela subnet (DHCP failover ou DHCP relay com pool compartilhado).
• Oferecendo novo IP via DHCPNAK seguido de Discover completo.

Expiração (T_exp)

Se nenhuma renovação for bem-sucedida até T_exp, o cliente deve liberar o IP e voltar ao estado inicial: enviar DHCPDISCOVER para começar um novo processo DORA. Em implementações modernas (Linux NetworkManager, Windows), o cliente mantém a conexão durante a janela de tolerância se possível, mas tecnicamente está em uso ilegítimo do IP.

Exemplo Numérico

Para um lease de 24 horas (86400s):

• T0 = 0s — Ack recebido, lease começa.
• T1 = 43200s (12h) — primeira tentativa de renovação unicast.
• T2 = 75600s (21h) — tentativa de rebind broadcast.
• T_exp = 86400s (24h) — expiração se nada funcionou.

Para um lease de 1 hora (3600s):

• T1 = 1800s (30 min)
• T2 = 3150s (52 min e 30s)
• T_exp = 3600s (60 min)

4. DHCPRELEASE

Cliente pode liberar o lease antes de expirar enviando DHCPRELEASE (opção 53 = 7) ao servidor. Isso é feito:

• Ao desligar o sistema operacional normalmente (NetworkManager em Linux envia Release).
• Ao desconectar a interface (ip link set eth0 down).
• Ao executar dhclient -r eth0 manualmente.

Não é obrigatório: a maioria dos sistemas móveis não envia Release ao suspender ou hibernar. O lease expira naturalmente em T_exp.

# Liberar lease explicitamente (ISC dhclient)
sudo dhclient -r eth0

# Em systemd-networkd
sudo networkctl renew eth0

5. Tabela de Leases no Servidor

O servidor DHCP mantém uma tabela de leases ativos em memória (e persistida em disco para sobreviver a reinícios). Cada entrada contém:

• IP atribuído
• MAC do cliente (chaddr)
• Client-ID (se diferente do MAC)
• Hostname (se o cliente forneceu)
• Início do lease (timestamp)
• Duração do lease (T_exp)
• Estado: active, free, abandoned, backup, expired
• Identificador do servidor que concedeu (em configurações failover)

ISC DHCPd: dhcpd.leases

O arquivo /var/lib/dhcpd/dhcpd.leases é a persistência oficial:

lease 192.168.1.100 {
  starts 4 2024/01/15 12:00:01;
  ends 4 2024/01/16 12:00:01;
  cltt 4 2024/01/15 12:00:01;
  binding state active;
  next binding state free;
  hardware ethernet aa:bb:cc:11:22:33;
  uid "\001\253\273\314\021\"3";
  client-hostname "laptop-maria";
}
lease 192.168.1.101 {
  starts 4 2024/01/15 13:00:00;
  ends 4 2024/01/15 14:00:00;
  binding state free;
  next binding state active;
}

Quando o servidor reinicia, ele lê esse arquivo e reconstrói o estado dos leases. Importante: o arquivo é reescrito periodicamente; nunca editar manualmente enquanto o daemon estiver rodando.

Kea DHCP

O Kea (sucessor do ISC DHCPd pela ISC) usa banco de dados MySQL, PostgreSQL ou memfile (CSV):

SELECT address, hwaddr, valid_lft, expire, state
FROM lease4
WHERE state = 0;  -- 0 = active

ISC DHCPd Failover

Em cenários críticos, dois servidores DHCP operam em failover. Eles mantêm estados:

• Normal: ambos ativos, sincronizam leases.
• Communications-interrupted: um servidor perde contato com o parceiro; continua atendendo localmente com pool reduzido (MCLT - Maximum Client Lead Time, default 1h).
• Partner-down: um servidor confirma que o outro está offline e assume o pool completo.
• Recover: servidor retornando sincroniza do parceiro ativo.

6. Inspeção de Lease no Cliente

# Linux com dhclient
cat /var/lib/dhcp/dhclient.leases
cat /var/lib/dhcp/dhclient.eth0.leases

# Linux com NetworkManager (mais moderno)
nmcli -f IP4 connection show "Wired connection 1"

# Windows
ipconfig /all
# Mostra lease obtido e quando expira

# Renovar manualmente
# Linux:
sudo dhclient -r eth0 && sudo dhclient eth0
# Windows:
ipconfig /release && ipconfig /renew

Verificar lease no servidor (ISC DHCPd)

# Listar leases ativos
sudo cat /var/lib/dhcpd/dhcpd.leases | grep -A 8 "binding state active"

# Estatísticas do pool
sudo dhcpd -t -cf /etc/dhcp/dhcpd.conf  # testa config
dhcp-lease-list

7. Persistência e Reinício do Servidor

Quando o servidor DHCP reinicia, ele precisa saber quais IPs já foram atribuídos. Há duas estratégias:

A) Persistência em disco

O servidor escreve leases em arquivo/DB. Ao reiniciar, lê o arquivo e reconstrói a tabela. Se o servidor cair e voltar em segundos, nenhum lease é perdido. Se o disco corromper, todos os leases ativos podem ser perdidos — cliente perde IP em T_exp.

B) Redundância (Failover)

Dois servidores DHCP sincronizam leases em tempo real. Se um cai, o outro assume. É a estratégia para ambientes críticos.

8. Conflitos de IP e Abandoned Leases

Quando um servidor DHCP oferece um IP e o cliente recebe Ack, o cliente deve verificar (via ARP) se o IP já está em uso. Se sim, envia DHCPDECLINE e o servidor marca o IP como abandoned temporariamente, retirando-o da pool por um período (default 1h). Isso evita loops de oferta de IP conflitante.

lease 192.168.1.200 {
  binding state abandoned;
  next binding state free;
}

9. Tabela Resumo

Marco	Tempo	Ação
T0	0%	Ack recebido, lease começa
T1	50%	REQUEST unicast ao servidor original
T2	87.5%	REQUEST broadcast para qualquer servidor
T_exp	100%	IP liberado, recomeça DORA
Release	A qualquer momento	Cliente libera explicitamente

10. Boas Práticas Operacionais

Calibragem por Cenário

• Escritório fixo: 24h é suficiente; pool estável.
• Wi-Fi dinâmico: 4-8h equilibra rotatividade e estabilidade.
• Hotspot público: 30min-1h; subnets maiores podem compensar.
• Pool escasso: 1-2h para reaproveitamento rápido.

Reservas Estáticas para Dispositivos Críticos

Impressoras, servidores, câmeras, equipamentos médicos: usar host block com fixed-address para garantir o mesmo IP sempre. Isso evita mudanças de IP que quebram portais, integrações e regras de firewall.

Monitorar Pool DHCP

# Estatísticas de uso
dhcp-lease-list
# Ou script simples:
grep "binding state active" /var/lib/dhcpd/dhcpd.leases | wc -l
# Comparar com tamanho do pool definido no dhcpd.conf

Se o uso ultrapassar 80% consistentemente, é hora de expandir o pool (aumentar range, dividir subnet) ou encurtar o lease time.

Sincronização de Tempo

O servidor DHCP deve rodar NTP. Sem horário preciso, timestamps de lease ficam incorretos, causando comportamentos estranhos (leases expirando antes do tempo ou nunca expirando).

Backup do dhcpd.leases

# Cron diário
0 2 * * * tar -czf /backup/dhcp-leases-$(date +\%F).tar.gz /var/lib/dhcpd/dhcpd.leases

11. Conclusão

O lease time é o coração operacional do DHCP. Ajustá-lo corretamente é o que diferencia uma rede estável de uma rede com IPs conflitantes e pools esgotados. Os timers T1 (50%) e T2 (87,5%) garantem que clientes tenham duas janelas de renovação antes da expiração, fornecendo resiliência contra quedas temporárias do servidor DHCP. Compreender a persistência em disco, o estado dos leases no servidor e os ciclos de renovação é essencial para qualquer engenheiro que opere redes de médio e grande porte — desde redes Wi-Fi corporativas até provedores de internet com milhões de clientes.