Processo DORA (Discover, Offer, Request, Ack)

1. Definição e Visão Geral

O DHCP (Dynamic Host Configuration Protocol, RFC 2131) automatiza a atribuição de endereços IP e outras configurações de rede a hosts clientes. O protocolo é baseado em BOOTP (RFC 951) e usa UDP em duas portas: 67 (servidor) e 68 (cliente). O fluxo clássico de obtenção de um endereço IP pelo cliente é chamado DORA, acrônimo das quatro mensagens trocadas:

1. Discover — cliente envia em broadcast.
2. Offer — servidor responde com proposta.
3. Request — cliente confirma a escolha.
4. Ack — servidor finaliza com configuração completa.

Esse fluxo de quatro passos garante que múltiplos servidores DHCP possam coexistir na mesma rede, com o cliente escolhendo qual oferta aceitar. É um modelo de negociação leve, sem estado persistente até o Ack final.

2. Estrutura da Mensagem DHCP

Cada mensagem DHCP carrega um cabeçalho BOOTP de 236 bytes seguido de opções TLV (Type-Length-Value). Campos principais:

O campo op é o que diferencia mensagem de cliente (BOOTREQUEST) de servidor (BOOTREPLY). O xid identifica a transação — todas as 4 mensagens de uma negociação DORA compartilham o mesmo xid. O yiaddr ("your IP address") é onde o servidor escreve o IP que está oferecendo ao cliente.

3. Opções DHCP (TLV)

A flexibilidade do DHCP vem das opções, formatadas como TLV. As mais importantes:

A opção 53 (Message Type) é obrigatória em toda mensagem DHCP — é o que distingue o DORA.

4. Passo a Passo do DORA

4.1 DISCOVER (Cliente → Broadcast)

O cliente acaba de ligar, não tem IP e não sabe quem são os servidores DHCP disponíveis. Constrói um pacote UDP:

• IP origem: 0.0.0.0 (ainda não tem IP)
• IP destino: 255.255.255.255 (broadcast L2 e L3)
• Porta origem: 68, Porta destino: 67
• MAC origem: o do cliente, MAC destino: FF:FF:FF:FF:FF:FF
• xid: gerado aleatoriamente
• chaddr: MAC do cliente
• Opção 53 = 1 (Discover)
• Opção 55 = lista de parâmetros desejados
• Opção 60 = Vendor class (opcional)

[Cliente 0.0.0.0:68] --DISCOVER broadcast--> [255.255.255.255:67]

4.2 OFFER (Servidor → Cliente)

Cada servidor DHCP na rede recebe o Discover e decide se tem um lease disponível. Se sim, reserva temporariamente o IP e responde:

• IP origem: IP do servidor
• IP destino: varia — se o cliente ainda não tem IP, o servidor pode enviar broadcast 255.255.255.255 (com flag broadcast setada no Discover) ou unicast para o IP oferecido (se o cliente sinalizou que aceita unicast com flag 0).
• yiaddr: IP sendo oferecido
• Opções: máscara (1), gateway (3), DNS (6), lease time (51), server identifier (54)

[Servidor 192.168.1.1:67] --OFFER broadcast/unicast--> [Cliente MAC]

Se múltiplos servidores DHCP responderem, o cliente escolhe normalmente a primeira Offer recebida (ou a do servidor com o Server Identifier preferido).

4.3 REQUEST (Cliente → Broadcast)

O cliente confirma qual oferta aceitou. Importante: envia em broadcast, para que todos os servidores saibam qual foi escolhido e possam liberar reservas temporárias dos IPs que ofereceram mas não foram aceitos.

• Opção 53 = 3 (Request)
• Opção 50 = IP solicitado (o yiaddr da Offer aceita)
• Opção 54 = Server Identifier do servidor escolhido

[Cliente 0.0.0.0:68] --REQUEST broadcast--> [255.255.255.255:67]
# Servidor escolhido: "OK, esse é para mim."
# Servidores não escolhidos: "Liberar reserva temporária."

4.4 ACK (Servidor → Cliente)

O servidor escolhido confirma o lease definitivo:

• yiaddr = IP atribuído
• Opção 51 = lease time em segundos (típico: 86400 = 24h)
• Opção 1, 3, 6 = máscara, gateway, DNS
• Opção 54 = server identifier
• Opções adicionais solicitadas via 55

A partir deste momento, o cliente configura a interface e pode usar o IP normalmente.

4.5 NAK (Servidor → Cliente)

Se o servidor não puder honrar o Request (por exemplo, o IP foi dado a outro cliente no interim), responde com NAK (opção 53 = 6):

[Servidor] --NAK--> [Cliente]
# Cliente: reinicia o processo DORA do zero

5. Diagrama Completo

Cliente                            Servidor DHCP
  |                                     |
  | ---- DISCOVER (broadcast) --------> |
  |                                     | (reserva IP temporariamente)
  | <--- OFFER (yiaddr, options) ----- |
  |                                     |
  | ---- REQUEST (broadcast) ---------> |
  |     (Server Identifier = X)         |
  |                                     | (confirma reserva)
  | <--- ACK (configuração final) ---- |
  |                                     |
  | == Cliente configura interface ==   |

6. Casos Especiais

6.1 DHCP Inform

Cliente já tem IP (configurado estaticamente), mas quer apenas opções (DNS, NTP). Envia Inform:

[Cliente 192.168.1.50] --INFORM--> [Servidor]
[Servidor] --ACK--> [Cliente com apenas opções, sem lease]

6.2 DHCP Decline

Cliente recebeu Ack, mas faz dupla-verificação com ARP para garantir que o IP não está em uso. Se o ARP responder, o cliente envia Decline (opção 53 = 8) e reinicia o processo.

6.3 DHCP Release

Cliente libera explicitamente o lease antes de expirar (opção 53 = 7). Não é obrigatório — sem Release, o lease expira naturalmente quando atinge o tempo. Mas é boa prática ao desligar uma VM, por exemplo, para liberar o IP na pool.

6.4 Renovação (T1 e T2)

Após 50% do lease time (T1), o cliente envia unicast REQUEST ao servidor para renovar. Se o servidor não responder até 87,5% (T2), o cliente envia broadcast REQUEST tentando qualquer servidor.

7. Captura Prática com tcpdump

sudo tcpdump -ni eth0 -vvv 'port 67 or port 68'

# Saída típica de um DORA:
12:00:01.123456 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:11:22:33, length 300, xid 0x12345678, Discover
12:00:01.234567 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x12345678, Offer, Flags [Broadcast], yiaddr 192.168.1.100
12:00:01.345678 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:11:22:33, length 300, xid 0x12345678, Request
12:00:01.456789 IP 192.168.1.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x12345678, Ack, Flags [Broadcast], yiaddr 192.168.1.100

Acompanhe o campo xid — deve ser o mesmo nas 4 mensagens.

8. Configuração de Servidor (ISC DHCPd)

# /etc/dhcp/dhcpd.conf
default-lease-time 86400;       # 24h
max-lease-time 172800;          # 48h
authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.200;
    option routers 192.168.1.1;
    option domain-name-servers 1.1.1.1, 8.8.8.8;
    option domain-name "exemplo.com.br";
    option broadcast-address 192.168.1.255;
    option ntp-servers 192.168.1.1;
}

# Reserva estática (host específico)
host impressora-3o-andar {
    hardware ethernet aa:bb:cc:dd:ee:ff;
    fixed-address 192.168.1.50;
}

9. Problemas Comuns

Dois Servidores DHCP na Mesma Rede

Acidentalmente (ex: roteador doméstico + servidor Windows DHCP). O cliente recebe duas Offers e pode pegar IP de qualquer um. Solução: desativar um dos dois, ou configurar DHCP snooping no switch para bloquear respostas DHCP de portas não autorizadas.

IP Conflitante (Already in Use)

Cliente recebeu IP que está em uso por máquina configurada estaticamente. O Ack foi enviado, mas o ARP de verificação responde. Cliente envia Decline e recomeça. Solução: excluir ranges estáticos da pool DHCP.

Cliente Não Recebe Endereço

• Verificar conectividade L2 (cabo, VLAN).
• Verificar se servidor DHCP está ouvindo na VLAN correta.
• Verificar se há relay agent (ip helper-address) configurado se cliente e servidor estão em VLANs diferentes.

10. Tabela Resumo

11. Conclusão

O processo DORA é elegante na sua simplicidade: quatro mensagens, com o cliente como iniciador e os servidores competindo pela oferta. Apesar de quase 30 anos de idade (RFC 2131 é de 1997), o DHCP continua sendo a forma padrão de atribuir IPs em redes IPv4. Entender os campos da mensagem (xid, yiaddr, chaddr), as opções (especialmente 53, 54, 50, 51) e o fluxo broadcast/unicast é essencial para diagnosticar qualquer problema de conectividade em rede corporativa — desde um notebook que não pega IP até impressoras com IPs conflitantes. As extensões modernas (opção 82 em relays, classless static routes, prefix delegation em DHCPv6) são construídas sobre a mesma base DORA.